· Apr 13, 2023 6m read

Recovering an accidentally deleted global

InterSystems FAQ rubric

In this article, we will introduce how to deal with the situation: "I accidentally deleted a global!"

Backup files and journals are used to recover specific globals that have been accidentally deleted. Restoration is performed by specifying conditions and restoring journal records using the ^ZJRNFILT utility. In this way, you can apply a point-in-time backup of the database up to and including deleting a specific global for journal records that contain deletions. For more information on the ^ZJRNFILT utility, please refer to the document below:

Filter Journal Records Using ^ZJRNFILT [IRIS]
Filter Journal Records Using ^ZJRNFILT


  - A backup as of 2020/10/14 exists (assuming that the backup was executed at 2020/10/15 0:30)
     Journal: 1 day of 2020/10/15 exists (2020/10/15) After the backup on 10/14)
  ・Target global: ^TEST1

The image is below.

Global ^TEST1 will be populated from 10/14.
The global ^TEST1 was accidentally deleted with a KILL statement at 15:30 on October 15th.
At this stage, we want to restore the global ^TEST1 just before the KILL statement was issued.
 In the execution example, ^TEST1(1) to ^TEST1(100) are restored using the global journal created by the command below.

USER>for i=1:1:100 set ^TEST1(i)=$ZTIMESTAMP

USER>for i=1:1:100 set ^TEST2(i)=$ZTIMESTAMP

USER>kill ^TEST1   // ← Processing up to here to recover using the journal file for ^TEST1


[Recovery procedure]

  1. Backup/restore or copy (mount) backed up database files (CACHE.DAT/IRIS.DAT) to another system
  2. Copy journals after backup acquisition to another system
  3. Identify killed journal records for the last journal file
    • Note 1: Viewing the journal record in the Management portal ( Management portal > [System Operations] > [Journals] > click the [Browse] link for the target file  ) (In the example shown, the journal record for KILL  9060180 can be seen)  
    • Note 2: You can also check journal records using the system routine SELECT^JRNDUMP .
  4. Restoring journal files in order, only globals to be restored are OK.
  5. Use ZJRNFILT only for last journal file
  6. Export recovered global, copy & import to original system

Below is an example of the 5th ZJRNFILT routine (created with the routine name: ZJRNFILT in the %SYS namespace).

ZJRNFILT (pid,dir,glo,type,restmode,addr,time) 
set  restmode =1
// If TEST1 is included in the global variable name 
// and the journal record is 9060180 or later, set restmode=0 (=do not restore) 
if  ( glo  [ "TEST1" ) & ( addr >=9060180) { 
   set  restmode =0

An example of restoring the last journal file using ZJRNFILT is shown below (inputs are in bold blue letters).

  1. %SYS>do ^JRNRESTO
  3. This utility uses the contents of journal files
  4. to bring globals up to date from a backup.
  6. Restore the Journal? Yes => Yes
  7. Use current journal filter (ZJRNFILT)? yes
  8. Use journal marker filter (MARKER^ZJRNFILT)? no
  9. Apply filter to every selected file? Yes => yes
  10. Process all journaled globals in all directories? no
  11. Are journal files imported from a different operating system? No => no
  13. Directory to restore [? for help]: c:\intersystems\hscv\mgr\user\   c:\intersystems\hscv\mgr\user\
  14. Redirect to Directory: c:\intersystems\hscv\mgr\user\
  15.  => c:\intersystems\hscv\mgr\user\--> c:\intersystems\hscv\mgr\user\
  16. Process all globals in c:\intersystems\hscv\mgr\user\? No => no
  18. Global ^TEST1
  19. Global ^
  21. Directory to restore [? for help]:
  23. Processing globals from the following datasets:
  24.  1. c:\intersystems\hscv\mgr\user\   Selected Globals:
  25.           ^TEST1
  27. Specifications correct? Yes => yes
  28. Are journal files created by this IRIS instance and located in their original
  29. paths? (Uses journal.log to locate journals)? no
  30. If you have a copy of the journal history log file from the Cache or IRIS
  31. instance where the journal files were created, enter its full path below;
  32. otherwise, press ENTER and continue.
  33. Journal history log:
  34. Specify range of files to process (names in YYYYMMDD.NNN format)
  36. from:     <20201012.002> [?] => 20201015.001
  38. through:  <20201015.001> [?] =>
  41. Provide or confirm the following configuration settings:
  43. Journal File Prefix: [?] =>
  45. Files to dejournal will be looked for in:
  46.      c:\intersystems\hscv\mgr\journal\
  47. in addition to any directories you are going to specify below, UNLESS
  48. you enter a minus sign ('-' without quotes) at the prompt below,
  49. in which case ONLY directories given subsequently will be searched
  51. Directory to search: <return when done>
  52. Here is a list of directories in the order they will be searched for files:
  53.      c:\intersystems\hscv\mgr\journal\
  54. Prompt for name of the next file to process? No => no
  56. The following actions will be performed if you answer YES below:
  58. * Listing journal files in the order they will be processed
  59. * Checking for any missing journal file on the list ("a broken chain")
  61. The basic assumption is that the files to be processed are all
  62. currently accessible. If that is not the case, e.g., if you plan to
  63. load journal files from tapes on demand, you should answer NO below.
  64. Check for missing journal files? Yes => no
  66. You may disable journaling of updates for faster restore for all
  67. databases other than mirrored databases. You may not want to do this
  68. if a database to restore is being shadowed as the shadow will not
  69. receive the updates.
  70. Do you want to disable journaling the updates? Yes => yes
  71. Updates will NOT be journaled
  72. Before we job off restore daemons, you may tailor the behavior of a
  73. restore daemon in certain events by choosing from the options below:
  75.      DEFAULT:    Continue despite database-related problems (e.g., a target
  76.      database is not journaled, cannot be mounted, etc.), skipping affected
  77.      updates
  79.      ALTERNATE:  Abort if an update would have to be skipped due to a
  80.      database-related problem (e.g., a target database is not journaled,
  81.      cannot be mounted, etc.)
  83.      DEFAULT:    Abort if an update would have to be skipped due to a
  84.      journal-related problem (e.g., journal corruption, some cases of missing
  85.      journal files, etc.)
  87.      ALTERNATE:  Continue despite journal-related problems (e.g., journal
  88.      corruption, some missing journal files, etc.), skipping affected updates
  90. Would you like to change the default actions? No => no
  93. Start the restore? Yes => yes
  97. c:\intersystems\hscv\mgr\journal\20201015.001
  98. 100.00%
  99. ***Journal file finished at 15:43:05
  101. [journal operation completed]
  102. Do you want to delete your journal filter? yes
  103. Journal filter ZJRNFILT deleted
  105. %SYS>

When restoring a global by journal restore, **for safety** we recommend replicating the database and journal in an environment other than the production environment. Therefore, export the restored global and transfer (copy) it to the production environment.

For details on the messages displayed during journal restore, please also refer to the documentation.

Discussion (2)1
Log in or sign up to continue

So much easier with journalling switched on!

In February 2000 we had to "undelete" a global containing all the cash transaction records at a large investment management institution when one of our colleagues accidentally deleted it near the end of the day. No journals, no backup, no option to re-input a whole day's work. Luckily the data was still there, albeit with no block pointers. It was a DSM system so we modified a program called ^BLCKDMP to read every block on the disk and write every node from our lost global out to an O/S file in %GO format. Took 15 hours to run and we had the system back by 9am the next day.

Needless to say, everything changed from then with regards to journalling and backups and programmer access.

It was an interesting experience in emergency firefighting and a nice learning experience in how the data is stored using the "common characters" space saving mechanism. M is really quite brilliant.