誤って削除したグローバルを復旧させる方法
これはInterSystems FAQ サイトの記事です。
この記事では「グローバルを誤って削除してしまった!」という場合の対処方法をご紹介します。
誤って削除してしまった特定のグローバルを復旧するためには、バックアップファイルとジャーナルを使用します。
復旧は、^ZJRNFILTユーティリティによるジャーナルリストアで条件を指定してジャーナルレコードをリストアする方法で行います。
この方法で、ある時点のデータベースのバックアップに対して、削除が含まれるジャーナルレコードについて特定グローバルを削除するまでのものを適用することができます。
^ZJRNFILTユーティリティの詳細については、以下のドキュメントをご参照ください。
^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理について【IRIS】
^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理について
【実施例】
・2020/10/14 時点のバックアップが存在している(バックアップは2020/10/15 0:30に実行したとします)
ジャーナル:2020/10/15 の1日分が存在している(2020/10/14のバックアップ以降のもの)
・対象のグローバル:^TEST1
イメージは以下の通りです。
- グローバル ^TEST1 は 10/14 よりデータが作成される。
- グローバル ^TEST1 が 10/15 の 15:30 に KILL 文にて誤って削除された。
- この段階でKILL文が発行される直前のグローバル ^TEST1 を復旧したい。
実行例では、以下コマンドで作成したグローバルをジャーナルを利用して ^TEST1(1)~^TEST1(100) を復旧します。
USER>for i=1:1:100 set ^TEST2(i)=$ZTIMESTAMP
USER>kill ^TEST1 // ← ここまでの処理の ^TEST1 に対してジャーナルファイルを利用して復旧します
【復旧手順】
- 別システムに、バックアップリストアまたはバックアップしたデータベースファイル(CACHE.DAT/IRIS.DAT)をコピー(マウント)
- バックアップ取得以降のジャーナルを別システムにコピー
- 最後のジャーナルファイルについてKillしたジャーナルレコードを特定
- メモ1:管理ポータルのジャーナルレコードの表示(管理ポータル > [システムオペレーション] > [ジャーナル] > 対象ファイルの[参照]のリンクをクリック )
(図例の場合だと、KILLのジャーナルレコードは 9060180 ということがわかります)
- メモ2:システムルーチン SELECT^JRNDUMP を使用してジャーナルレコードを確認する方法もあります。
- メモ1:管理ポータルのジャーナルレコードの表示(管理ポータル > [システムオペレーション] > [ジャーナル] > 対象ファイルの[参照]のリンクをクリック )
- ジャーナルファイルを順番にリストア、リストア対象は復旧したいグローバルのみでOK
- 最後のジャーナルファイルのみ ZJRNFILT を使用
- 復旧したグローバルをエクスポートし、元システムにコピー&インポート
以下、5番の ZJRNFILT ルーチン例です(%SYSネームスペースにルーチン名:ZJRNFILT で作成します)。
ZJRNFILT(pid,dir,glo,type,restmode,addr,time) set restmode=1 // グローバル変数名に TEST1 が含まれいる // かつ ジャーナルレコードが9060180以降は restmode=0 に設定(=リストアしない) if (glo [ "TEST1") & (addr>=9060180) { set restmode=0 } quit
最後のジャーナルファイルのZJRNFILTを使用したリストア例は以下の通りです(青太文字が入力内容です)。
- %SYS>do ^JRNRESTO
- This utility uses the contents of journal files
- to bring globals up to date from a backup.
- Restore the Journal? Yes => Yes
- Use current journal filter (ZJRNFILT)? yes
- Use journal marker filter (MARKER^ZJRNFILT)? no
- Apply filter to every selected file? Yes => yes
- Process all journaled globals in all directories? no
- Are journal files imported from a different operating system? No => no
- Directory to restore [? for help]: c:\intersystems\hscv\mgr\user\ c:\intersystems\hscv\mgr\user\
- Redirect to Directory: c:\intersystems\hscv\mgr\user\
- => c:\intersystems\hscv\mgr\user\--> c:\intersystems\hscv\mgr\user\
- Process all globals in c:\intersystems\hscv\mgr\user\? No => no
- Global ^TEST1
- Global ^
- Directory to restore [? for help]:
- Processing globals from the following datasets:
- 1. c:\intersystems\hscv\mgr\user\ Selected Globals:
- ^TEST1
- Specifications correct? Yes => yes
- Are journal files created by this IRIS instance and located in their original
- paths? (Uses journal.log to locate journals)? no
- If you have a copy of the journal history log file from the Cache or IRIS
- instance where the journal files were created, enter its full path below;
- otherwise, press ENTER and continue.
- Journal history log:
- Specify range of files to process (names in YYYYMMDD.NNN format)
- from: <20201012.002> [?] => 20201015.001
- through: <20201015.001> [?] =>
- Provide or confirm the following configuration settings:
- Journal File Prefix: [?] =>
- Files to dejournal will be looked for in:
- c:\intersystems\hscv\mgr\journal\
- in addition to any directories you are going to specify below, UNLESS
- you enter a minus sign ('-' without quotes) at the prompt below,
- in which case ONLY directories given subsequently will be searched
- Directory to search: <return when done>
- Here is a list of directories in the order they will be searched for files:
- c:\intersystems\hscv\mgr\journal\
- Prompt for name of the next file to process? No => no
- The following actions will be performed if you answer YES below:
- * Listing journal files in the order they will be processed
- * Checking for any missing journal file on the list ("a broken chain")
- The basic assumption is that the files to be processed are all
- currently accessible. If that is not the case, e.g., if you plan to
- load journal files from tapes on demand, you should answer NO below.
- Check for missing journal files? Yes => no
- You may disable journaling of updates for faster restore for all
- databases other than mirrored databases. You may not want to do this
- if a database to restore is being shadowed as the shadow will not
- receive the updates.
- Do you want to disable journaling the updates? Yes => yes
- Updates will NOT be journaled
- Before we job off restore daemons, you may tailor the behavior of a
- restore daemon in certain events by choosing from the options below:
- DEFAULT: Continue despite database-related problems (e.g., a target
- database is not journaled, cannot be mounted, etc.), skipping affected
- updates
- ALTERNATE: Abort if an update would have to be skipped due to a
- database-related problem (e.g., a target database is not journaled,
- cannot be mounted, etc.)
- DEFAULT: Abort if an update would have to be skipped due to a
- journal-related problem (e.g., journal corruption, some cases of missing
- journal files, etc.)
- ALTERNATE: Continue despite journal-related problems (e.g., journal
- corruption, some missing journal files, etc.), skipping affected updates
- Would you like to change the default actions? No => no
- Start the restore? Yes => yes
- c:\intersystems\hscv\mgr\journal\20201015.001
- 100.00%
- ***Journal file finished at 15:43:05
- [journal operation completed]
- Do you want to delete your journal filter? yes
- Journal filter ZJRNFILT deleted
- %SYS>
ジャーナルリストアによりグローバルを復旧する場合は ** 安全の為 ** 本番環境とは別の環境に、データベース、ジャーナルを複製して実施することをお勧めします。
そこで復旧したグローバルをエクスポートし本番環境に転送(コピー)するようにしてください。
ジャーナルリストア時に表示されるメッセージ詳細については、ドキュメントもご参照ください。