Skip to main content

This documentation is for an older version of this product. See the latest version of this content.Opens in a new tab

ジャーナリング

グローバル・ジャーナリングは、データベースで実行されるすべてのグローバルな更新処理を記録します。また、バックアップと組み合せて使用すると、障害またはクラッシュ発生直前の状態にデータベースをリストアできます。

バックアップは物理的なリカバリの基礎ですが、これが常に正しい方法であるとは限りません。バックアップからデータベースをリストアしても、そのバックアップ以後に行われたグローバルな更新は回復されません。バックアップは、物理的な整合性が失われた時点の数時間前に作成されていた場合があります。これらのバックアップ後の更新は、データベースをバックアップからリストアした後に、ジャーナル・ファイルからデータベースにリストアできます。こうして、データベースを最新状態にできます。障害発生時に開いていたトランザクションはロールバックされ、トランスポートの整合性が確保されます。

ジャーナリングの概要

InterSystems IRIS® の各インスタンスはジャーナルを保持します。ジャーナルとは、最後のバックアップ以後にデータベースに対して行われた更新を時間順で保持している一連のファイルです。その処理は冗長性があり、論理的で、InterSystems IRIS ライト・デーモンを使用しません。InterSystems IRIS のトランザクション処理は、障害の後にデータの論理的整合性を維持するために、ジャーナリングと共に機能します。

また、バックアップとジャーナリングにより、データベースを再作成することが可能になります。データベースが破損する、アクセスできない、または使用不可能になるような障害が発生した場合、最新のバックアップをリストアし、ジャーナル内の変更を適用して、障害発生時点のデータベースを再作成できます。物理的整合性の損失を回復するこの技術は、“ロール・フォワード” リカバリと呼びます。また、ジャーナルは不完全なトランザクションをロールバックするためにも使用されます。

ジャーナル状態は、個々のグローバルのプロパティではなく、データベースのプロパティです。データベースのグローバル・ジャーナル状態は、Yes または No のいずれかになります。既定では、作成するすべてのデータベースがジャーナリングされます ([グローバルジャーナル状態][Yes])。新規にインストールされた InterSystems IRIS インスタンスでは、IRISAUDITIRISSYS、および USER の各データベースはジャーナリングされます。IRISLIBIRISTEMP、および IRISLOCALDATA の各データベースはジャーナリングされません。IRISTEMP 内のグローバルに対する操作は、ジャーナリングされません。InterSystems IRIS 一時データベースである IRISTEMP一時グローバルをマッピングしてください。

Important:

ジャーナリングされないデータベースのリカバリの制限に関する重要な情報については、"データベースをジャーナリングしない場合の影響" を参照してください。

InterSystems IRIS を起動すると、最後のライト・デーモン・パス以降のすべてのジャーナル・エントリが再適用されます。ユーザは、ライト・デーモンを使用せずにジャーナルの更新を同時に処理するので、この方法によりクラッシュ前の更新の保存を保証します。

ジャーナリングされるデータベースに対するすべての更新を記録するだけでなく、ジャーナルにはトランザクションの一部であるジャーナリングされないデータベースに対するすべての更新も含まれます (主 Set 操作と Kill 操作)。これによって、システムの信頼性が大きく向上します。つまり、回復後、グローバルの更新の中にジャーナルに記録されていないものがあったり、トランザクションの対象にならないものがあったりするために発生する矛盾を防止できます (ローカルでの Set および Kill の操作、およびプロセス・プライベート変数はジャーナルに記録されません)。

クラスタにマウントされたデータベースのグローバル処理をジャーナリングするかどうかは、データベース設定によって決まります。ローカル InterSystems IRIS インスタンスでは、リモート・ノードのグローバルのトランザクション処理はジャーナルしません。ネットワーク構成の場合、ジャーナリングは、グローバルが実際に格納されているノードをサポートしますが、Set または Kill コマンドを要求したノードはサポートしません。したがって、ノード B がノード A の要求で Set コマンドを実行する場合、ジャーナル・エントリは、ノード A ではなく、ノード B のジャーナルに表示されます。

以下の項目で、ジャーナルの機能を詳しく説明します。

ジャーナリングとライト・イメージ・ジャーナリングの違い

InterSystems IRIS ジャーナルライト・イメージ・ジャーナル (WIJ) とを混同しないでください。WIJ の詳細は、"ライト・イメージ・ジャーナリングとリカバリ" を参照してください。ジャーナリングとライト・イメージ・ジャーナリングでは、以下のように機能が異なります。

  • ジャーナリングでは、データベースに既に書き込まれているデータベースの変更がすべて記録されます。一部の変更が (例えば、リカバリされたデータベースの最新のバックアップ後に行われたために) 消失した場合は、ジャーナル・ファイルの内容をリストアすることで、データベースに変更をリストアします。

  • ライト・イメージ・ジャーナリングでは、データベースにまだ書き込まれていないデータベースの変更がすべて記録されます。システム・クラッシュが発生すると、ライト・イメージ・ジャーナルの内容は、再起動時に自動的にデータベースに書き込まれます。

データベースの整合性の保護

インターシステムズのリカバリ・プロセスは、最大限の保護機能を提供するよう設計されています。

  • これには、“ロール・フォワード” 技術が使用されています。システム障害が発生した場合、実行途中の更新はリカバリ機能によって最後まで実行されます。対照的に、他のシステムの中には、回復のために更新を元に戻す、“ロール・バック” 方法を採用するシステムもあります。どちらの方法も内部整合性を保護しますが、InterSystems IRIS は、ロール・フォワード技術を使用することで、データの損失を減少させます。

  • 更新順序を保護します。リカバリ後のデータベースに更新が存在する場合、先行するすべての更新も実行されます。更新順序を適切に保護しない他のシステムは、内部的な一貫性を保っていますが、論理的には無効なデータベースになります。

  • データベースだけでなく、インクリメンタル・バックアップ・ファイル構造を保護します。クラッシュ後のリカバリに続き、有効なインクリメンタル・バックアップを実行できます。

トランザクションの自動ジャーナリング

InterSystems IRIS アプリケーションでは、トランザクションと呼ばれる作業ユニットを定義できます。InterSystems IRIS のトランザクション処理では、ジャーナルを使用してトランザクションを格納します。InterSystems IRIS では、影響を受けるグローバルが含まれるデータベースのグローバル・ジャーナル状態設定に関係なく、トランザクションに含まれるグローバルの更新がすべてジャーナルされます。

以下の目的で、コマンドを使用します。

  • トランザクションの開始を指示

  • トランザクションが通常に終了した場合、トランザクションをコミット

  • トランザクション中にエラーが発生した場合、トランザクションをロールバック

InterSystems IRIS は、多くの SQL トランザクション処理コマンドをサポートします。これらのコマンドの詳細は、"ObjectScript の使用法" の “トランザクション処理” の章を参照してください。

不完全トランザクションのロールバック

トランザクションが完了していない場合、ジャーナル・エントリを使用してトランザクションはロールバックされ、関連するグローバルはトランザクション実行前の値に戻ります。InterSystems IRIS は、データベース更新の一環として、ジャーナルに変更を適用してジャーナル・リストアを実行し、不完全なトランザクションをロールバックします。これは以下の条件で発生します。

  • システム・クラッシュ後の InterSystems IRIS 起動で発生するリカバリ中

  • トランザクション進行中にプロセスを一時停止した場合

  • 管理ポータルの [プロセス] ページ ([システム処理][プロセス]) から [終了] オプションを使用してプロセスを終了した場合。Job コマンドによって開始されたプロセスを終了した場合、その中の不完全なトランザクションは自動的にロールバックされます。ユーザ・プロセスを終了すると、システムはユーザにメッセージを送信し、不完全なトランザクションをコミットするかロールバックするかを尋ねます。

アプリケーションにロールバック・コードを記述できます。アプリケーションそのものが問題を検出し、ロールバックを要求します。普通、これはアプリケーション・エラーに続くエラー処理ルーチンで実行します。

詳細は、"ObjectScript の使用法" の “トランザクション処理” の章で、"アプリケーションでのトランザクション管理" のセクションを参照してください。

データベースをジャーナリングしない場合の影響

ジャーナリングされないデータベースは、InterSystems IRIS の起動時にジャーナル・リカバリおよびトランザクション・ロールバックに参加しません。結果として、障害、バックアップ・リストア、および再起動後に以下の条件が適用されます。

  • ジャーナリングされないデータベースに対する最新の更新が失われる可能性があります。これらのデータベース内のデータは、ジャーナリングされたデータベース内のデータより前の時点を表します。

  • ジャーナリングされないデータベース内のトランザクションまたはトランザクションの一部が、部分的にコミットされた状態になる可能性があります。同期コミット・トランザクションにより提供される持続性は、ジャーナリングされないデータベースには適用されません。

  • トランザクションの一部であるジャーナリングされないデータベースに対する更新がジャーナリングされると、これらのジャーナル・レコードは通常の操作中にトランザクションをロールバックするためにのみ使用されます。これらのジャーナル・レコードは、起動時にトランザクションをロールバックする手段にはならず、起動時またはバックアップ・リストア後にデータを回復するために使用することもできません。

ジャーナル書き込みサイクル

ジャーナル・バッファの内容をジャーナル・ファイルに書き込む操作は、ジャーナル同期と呼ばれます。ジャーナル同期により、現在ジャーナル・バッファ内にあるすべての操作が現在のジャーナル・ファイルに確実に書き込まれます。

ジャーナルが同期される頻度は、関連する InterSystems IRIS インスタンスの動作状況によって異なります。ジャーナル同期は、次の場合にトリガされる可能性があります。

  • システムがアイドルの場合 2 秒ごとに 1 回トリガされる。

  • ECP ベースの分散キャッシュ・クラスタでは、アプリケーション・サーバからの特定の要求 (例えば、$Increment) に応答して ECP のセマンティックスを保証する場合にデータ・サーバによってトリガされる。

  • InterSystems IRIS トランザクションを使用している場合、TCOMMIT によってトリガされる (同期コミット・モードであるため、このトランザクションに関連するデータがディスクにフラッシュされる)。

  • 各データベース書き込みサイクルの一部として書き込みデーモンによってトリガされる。

  • ジャーナル・バッファがフルの場合にトリガされる。

ジャーナル・ファイルとジャーナル履歴ログ

ジャーナル・ファイルは プライマリ・ジャーナル・ディレクトリ (既定では、install-dir\Mgr\journal) に格納され、ジャーナル履歴ログ・ファイルである install-dir\Mgr\journal.log に記録されます。このログ・ファイルには、インスタンスで管理されているすべてのジャーナル・ファイルのリストが含まれています。ジャーナルに関連するすべての機能、ユーティリティ、および API では、このログを使用してジャーナル・ファイルを探します。

ジャーナル履歴ログ・ファイルは以下のように更新されます。

  • 新規のジャーナル・ファイルが作成されると、エントリがログに追加されます。

  • エントリで識別されるジャーナル・ファイルが存在しなくなっていて、エントリの経過日数が 30 日以上の場合、エントリは定期的にファイルの先頭から順に削除されます。エントリがこの 2 つの条件に該当しない場合、削除は行われません。

Caution:

journal.log ファイルは変更しないでください。ジャーナル・ユーティリティを使用せずにこのファイルを変更すると、ファイルは破損していると見なされ、ジャーナリングが無効になる可能性があります。このファイルが破損している場合は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。ジャーナリングが無効になっている場合 (InterSystems IRIS が journal.log ファイルを更新できない場合) は、破損したログ・ファイルの名前を変更してジャーナリングを再開します。

バックアップからのリストアに続いて実行するジャーナルのリストアで必要になったときに必ず利用できるように、journal.log ファイルをバックアップ方針に取り入れることをお勧めします。バックアップとリストアの方針および手順に関する詳細は、このドキュメントの “バックアップとリストア” の章を参照してください。

journal.log ファイルが存在しない場合 (例えば、破損によりファイル名を変更した場合)、システムでは新規ジャーナル・ファイル作成の際に新しいログ・ファイルが作成されますが、このログ・ファイルにはその作成時点以後に作成されたジャーナル・ファイルのみが記録されるので、以前のジャーナル・ファイルについての情報は失われます。journal.log ファイルを使用するジャーナル関連の機能、ユーティリティ、および API では、このログ・ファイルに記録されていないジャーナル・ファイルは利用できません。一方、ジャーナルをリストアするとき、journal.log が存在しない場合または既存のログ・ファイルを使用しない場合は、手動でジャーナル・ファイルを指定できます (この章の “^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア” のセクションを参照してください)。

また、journal.log ファイルを使用して、以下のように別の場所へのジャーナル・ファイルの移行やリストアも可能です。

  1. ターゲットとしている InterSystems IRIS インスタンスで、install-dir\Mgr ディレクトリ以外の場所に、ジャーナル・ファイルおよび journal.log ファイルをコピーします。

  2. ターゲット・システム上で ^JRNRESTO ルーチンを実行し、ジャーナル・ファイルの元のパスに関するプロンプトへの応答で「No」を入力します。

  3. 表示されるプロンプトに従って、コピーしたジャーナル・ファイルおよび journal.log ファイルのターゲット・システム上での格納場所を指定します。^JRNRESTO では、このログ・ファイルを使用して、ターゲット・システムへ移行またはリストアするジャーナル・ファイルの範囲を検証します。

  4. この章の “^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア” セクションの説明に従って、プロセスを完了します。

Note:

InterSystems IRIS インスタンスがミラーのメンバとなった場合、以下のミラーリング・サポート用のジャーナル変更が発生します。

  • プライマリになる際、MIRROR-mirror_name が先頭に付く新規ジャーナル・ファイル (MIRROR-MIR21-20180921.001 など) に対してのジャーナル切り替えが発動します。その時点より、すべてのジャーナル・ファイルはミラー・ジャーナル・ファイルとして書き込まれ、mirrorjrn-mirror_name.log (mirrorjrn-MIR21-20180921.log など) および journal.log にログが記録されます。

  • バックアップまたは非同期になる際には、プライマリより受信したミラー・ジャーナル・ファイルがローカル・インスタンスの標準ジャーナル・ファイルと共に、構成されたジャーナル・ディレクトリに書き込まれて、プライマリのミラー・ジャーナル・ログ (mirrorjrn-mirror_name.log) のコピーが install-dir\Mgr に作成された後に、継続的に更新されます。

ミラーリングにおけるジャーナル・ファイルの役割の詳細は、"高可用性ガイド" の “ミラーリング” の章にある "ミラー同期" を参照してください。

一時グローバルと IRISTEMP の使用

IRISTEMP データベースにマップされているものはジャーナルされません。

ネームスペース内のグローバルはそれぞれ別々のデータベースにマッピングされている可能性もあるため、一部はジャーナルに記録され、他は記録されないということもあります。グローバルがマップされているデータベースのジャーナル・プロパティによって、InterSystems IRIS がそのグローバル処理をジャーナルするかどうかが決まります。IRISTEMP とジャーナル・プロパティが [No] に設定されているデータベースとの違いは、IRISTEMP では、トランザクションの更新も含めて何もジャーナルされないことです。

Note:

データベースの構成で [ジャーナルグローバル] プロパティを [No] に設定すると ("システム管理ガイド" の “InterSystems IRIS の構成” の章にある "ローカル・データベースの作成" を参照)、ジャーナル・トランザクションのグローバル Set/Kill 処理のジャーナルが継続されます。これにより、ジャーナル・ファイルが非常に大きくなる可能性があります。しかし、IRISTEMP はジャーナル・トランザクション中であっても、Set/Kill 処理のジャーナルを行いません。

ジャーナリングから新規 z/Z* グローバルを除外する必要がある場合は、それらのグローバルを、ジャーナル・プロパティを [No] に設定してデータベースにマップします。ジャーナリングから z/Z* グローバルを常に除外するには、すべてのネームスペース内の z/Z* グローバルを IRISTEMP データベースにマップする必要があります。

"グローバルの使用法" の付録 “一時グローバルと IRISTEMP データベース” も参照してください。

ジャーナル管理のクラスとグローバル

ジャーナリングで使用できるメソッドとクエリの詳細は、"インターシステムズ・クラス・リファレンス" の "%SYS.Journal.SystemOpens in a new tab" クラスに関するドキュメントを参照してください。これは %SYS.Journal パッケージに収められています。

また、InterSystems IRIS では、^%SYS(“JOURNAL”) グローバル・ノードを使用してジャーナル・ファイルに関する情報を格納します。以下に例を示します。

  • ^%SYS("JOURNAL","ALTDIR") は、代替ジャーナル・ディレクトリ名を格納します。

  • ^%SYS("JOURNAL","CURDIR") は、現在のジャーナル・ディレクトリ名を格納します。

  • ^%SYS("JOURNAL","CURRENT") は、ジャーナルの状態とジャーナル・ファイル名を格納します。

この情報は、管理ポータルの [グローバル] ページ ([システム・エクスプローラ][グローバル]) で表示できます。

ジャーナリングの構成

ジャーナリングの計画および構成にあたって考慮すべき要素は多くあります。このセクションは、以下のトピックで構成されています。

ジャーナリングの有効化

既定では、IRISSYSIRISAUDIT、および USER の各 InterSystems IRIS データベースのジャーナリングが有効になります。管理ポータルの [ローカルデータベース] ページ ([システム管理][構成][システム構成][ローカルデータベース]) からデータベースごとにジャーナリングを有効または無効にすることができます。目的のデータベースに該当する行で [編集] をクリックし、[グローバル・ジャーナル状態] ボックスで [Yes] または [No] をクリックします。

新しいデータベースのジャーナル状態の既定の設定は Yes です。旧リリースの InterSystems IRIS のデータベースを初めてマウントするときに、この値は Yes に設定されます。新規グローバルの以前の設定値およびそのデータベースにある個々のグローバルの以前の設定は無視されます。

実行中のシステムで、データベースのグローバル・ジャーナル設定を変更できます。これを実行すると、何らかの影響が発生する可能性があることが警告されます。また、監査が有効になっていると変更に対する監査が実行されます。

ジャーナル・ファイルの名前付け

ジャーナル・ファイルの名前は、オプションのユーザ定義の接頭語、その後に続く yyyymmdd の形式で作成された日付と時刻で構成される基本名、ピリオド (.)、そして最後に 1 暦日内に作成されたジャーナル・ファイルをインクリメンタルに番号付けするために使用される 3 桁の接尾語で構成されます。ジャーナル・ファイルが一杯になると、システムは、同じ接頭語と基本名を使用し、接尾語を 1 だけ増加させた新しいファイルに自動的に切り替えます。基本名は、ジャーナル・ファイルの使用中に新しい暦日が始まった場合にのみ変更されます。

例えば、2018 年 4 月 27 日にアクティブである最初のジャーナル・ファイルには、20180427.001 という名前が付けられます。ファイルが一杯になると、システムは 20180427.002 という新しいファイルを開始します。ただし、ジャーナル・ファイルの使用中に真夜中を過ぎて日付が変わると、そのファイルの名前は 20180428.001 に変更されます。

ジャーナリングの最善の使用方法

ジャーナリングを計画および構成する際の重要な考慮事項を以下に示します。

  • ジャーナル・ファイルは、プライマリ・ジャーナル・ディレクトリと代替ジャーナル・ディレクトリ (プライマリ・ディレクトリが何らかの理由で書き込み不能になった場合に使用) の両方に保存されます。

    パフォーマンスと復元可能性の両方を高めるために、プライマリおよび代替ジャーナル・ディレクトリは、それぞれ異なるストレージ・デバイスに配置し、データベースやライト・イメージ・ジャーナル (WIJ) が使用しているストレージ・デバイスとも異なるストレージ・デバイスに配置することをお勧めします。運用上の理由から、同じ SAN (Storage Area Network) 上の論理ユニット番号 (LUN) が異なるデバイスに配置することもできますが、一般的にはなるべく独立したデバイスに配置するようにします。物理ドライブの個別のセットを使用することを強くお勧めします。このようにデータベース/WIJ ストレージとプライマリ/代替ジャーナル・ストレージを分離することには、以下の主要な利点があります。

    • データベースまたは WIJ に発生する可能性がある障害からジャーナル・ディレクトリを分離することにより、そのような障害後にデータベースをリストアするためにジャーナル・ファイルを使用できるようになります。

    • プライマリおよび代替ジャーナル・ディレクトリを分離することで、プライマリ・ディレクトリが配置されたデバイスで停止が発生した場合も、ジャーナリングを続行できます。

    • ジャーナル入出力パスを分離することは、ほとんどのアプリケーションで必要となる入出力並行処理を実現するための重要な要素です。

    簡便性のために、InterSystems IRIS インストールではディレクトリ install-dir\Mgr\journal を作成し、それをプライマリおよび代替ジャーナル・ディレクトリとして構成して、そのディレクトリ内に既定のジャーナリングされるデータベースの最初のジャーナル・ファイルを作成します。ただし、プライマリおよび代替ジャーナル・ディレクトリ用に別個のストレージ・デバイスを特定して準備し、インストール後できるだけ早くにこれらの設定を再構成する ("ジャーナル設定の構成" の説明に従って) ことをお勧めします。

    Note:

    ジャーナル・ファイルは、このドキュメントの “バックアップとリストア” の章の説明に従って、常にデータベース・ファイルと共にバックアップしておく必要があります。プライマリ・データ・センタにおける複数のストレージ・デバイスを含む障害からの復旧が可能になるよう、災害復旧目的でジャーナル・ファイルをオフサイトで複製することを検討してください。この目的には、InterSystems IRIS ミラーリング、ディスクレベル複製、またはその他のメカニズムを使用できます。

  • ジャーナリングがすべてのデータベースに対して有効化されていることを確認します (一時的なデータのみを含むデータベースを除く)。

    Important:

    ジャーナリングされないデータベースのリカバリの制限に関する重要な情報については、"データベースをジャーナリングしない場合の影響" を参照してください。

  • ジャーナルの [エラー発生時に凍結する] オプションを [はい] に設定することを検討してください。障害によりプライマリおよび代替ジャーナル・デバイスの両方に書き込みできなくなった場合、この設定によりシステムが凍結し、ユーザがシステムを使用できなくなるため、データが失われることがなくなります。もう 1 つの選択肢として、[エラー発生時に凍結する] オプションを [いいえ] に設定し、システムを続行させてジャーナリングを無効にします。これにより、システムは引き続き利用可能になりますが、データの整合性と回復性が損なわれます。[エラー発生時に凍結する] の詳細については、"ジャーナル入出力エラー" を参照してください。

  • バックアップ検証手順で、ジャーナル・ファイルが最後の良好なバックアップの前に閉じたと判断される場合以外は、削除しないでください。ジャーナル・ファイルを保持する日数および、ジャーナル・ファイルに保持する成功したバックアップの回数を適切に設定します。

  • ジャーナル・リストア時に最適なパフォーマンスを実現するには、共有メモリ・ヒープ (gmheap) のサイズを増加させることを検討してください。詳細は、"ジャーナル・ファイルのリストア" を参照してください。

  • ジャーナル・ファイルが占有する領域を最小限に抑えるために、ジャーナル・ファイルの圧縮が有効になっていることを確認します。このオプションは、CompressFiles CPF 設定で制御され、新規の InterSystems IRIS インストールでは既定で有効になっています。

ジャーナル設定の構成

InterSystems IRIS のジャーナリングを構成するには、管理ポータルの [ジャーナル設定] ページ ([システム管理][構成][システム構成][ジャーナル設定]) に移動します。

以下の設定が編集可能です。

  • [主ジャーナルディレクトリ] — ジャーナル・ファイルを格納するディレクトリの名前を入力します。ディレクトリ名の最大長は 214 文字です。

  • [二次ジャーナルディレクトリ] — ジャーナリングの際に、現在のディレクトリのディスクが何らかの理由で書き込みできなくなったときに使用する代替ディレクトリの名前を入力します。("ジャーナル・ディレクトリの切り替え" の説明に従って、ジャーナル・ディレクトリを手動で切り替えることもできます。)ディレクトリ名の最大長は 214 文字です。

    Important:

    パフォーマンスと復元可能性の両方を高めるために、プライマリおよび代替ジャーナル・ディレクトリは、それぞれ異なるストレージ・デバイスに配置し、データベースやライト・イメージ・ジャーナル (WIJ) が使用しているストレージ・デバイスとも異なるストレージ・デバイスに配置することをお勧めします。詳細は、"ジャーナリングの最善の使用方法" を参照してください。

  • [次のサイズに達すると新規ジャーナルに切り替える] — ジャーナル・ファイルの最大サイズをメガバイト単位で入力します。このサイズに到達すると次のジャーナル・ファイルに切り替わります。既定のサイズは 1024 MB です。最大サイズは、4096 – 1 – (ジャーナル・バッファのサイズ) MB に制限されます。既定のジャーナル・バッファ・サイズ 64 MB を使用した場合、ジャーナル・ファイルの最大サイズは 4031 MB になります。ジャーナル・バッファの最小サイズは 16 MB のため、ジャーナル・ファイルの絶対最大サイズは 4079 MB になります。

  • [ジャーナルファイル接頭語] (オプション) — ジャーナル・ファイル名の英数字接頭語を入力します。

  • [ジャーナルファイルを削除するタイミング] — 以下の 2 つのオプションのいずれか、または両方を設定できます。両方の設定にゼロ以外の数値を入力すると、ジャーナル・ファイルは、どちらかの条件を先に満たしたときに削除されます。一方を 0 (ゼロ) に設定し、もう一方をゼロ以外の値に設定すると、ゼロ以外の設定によって削除が判定されます。両方が 0 の場合、ジャーナル・ファイル (およびジャーナル履歴) の自動削除は行われません。

    • [この日数後] — 何日後に削除するかを入力します (有効な値は 0 ~ 100)。

      Note:

      ジャーナル・ファイルを削除するまでの日数を設定する場合、削除期限の前の日の最後のジャーナル・ファイルも保持されます。例えば、[この日数後]1 に設定され、削除が 4 月 1 日の午前 0 時に実行されると、3 月 30 日に作成された最後のジャーナル・ファイルが、3 月 31 日に作成されたファイルと共に保持されます。

    • [この回数のバックアップ成功後] — バックアップが何回連続して成功した後に削除するかを入力します (有効な値は 0 ~ 10)。

      これには、オンライン・バックアップ、$$BACKUP^DBACK("","E") を使用した外部バックアップ、または Backup.General.ExternalSetHistory()Opens in a new tab メソッドを使用したバックアップ履歴への追加が含まれます。

    Note:

    [この日数後]0 (時間を基準にして削除しない) に設定し、[この回数のバックアップ成功後]1 に設定している場合は、正常なバックアップを 2 回実行するまでジャーナル・ファイルは削除されません。つまり、“連続” の条件を満たすには、2 回の正常なバックアップが必要です。

    ^JRNOPTS ルーチンを使用するか、または ^JOURNAL ルーチン・メニューからオプション 7 の [ジャーナル・プロパティの編集] を選択することで、これらの設定を更新することもできます。詳細は、"^JRNOPTS を使用したジャーナル設定の更新" を参照してください。

    Note:

    ジャーナル・ファイルは、削除の設定の条件を満たしていても保持される場合があります。この場合、イベントはメッセージ・ログに記録され、理由 (例えば、ジャーナル・ファイルに開いているトランザクションが含まれているなど) が示されます。

  • [エラー発生時に凍結する] — この設定は、ジャーナルへの書き込み中にエラーが発生した場合の動作を制御します。既定値は、[いいえ] です (選択されていません)。この設定の詳細は、"ジャーナル入出力エラー" を参照してください。

    Note:

    InterSystems IRIS インスタンスがミラーのプライマリ・フェイルオーバー・メンバの場合 ("高可用性ガイド" の “ミラーリング” の章を参照)、インスタンスの [エラー発生時に凍結する] の構成が自動的にオーバーライドされ、現在の設定に関係なくジャーナル入出力エラー発生時にすべてのジャーナリングされたグローバル更新がフリーズされます。現在の設定が [いいえ] の場合、インスタンスがプライマリ・フェイルオーバー・メンバでなくなったときに動作がこの設定に戻ります。

  • [ウェブセッションをジャーナルする] — この設定によって、Web サーバ・ページ・セッションのジャーナリングを有効にするかどうかが制御されます。既定値は、[いいえ] です (選択されていません)。

  • [Compress journal files] — この設定によって、ジャーナル・ファイルを圧縮するかどうかが制御されます。既定値は、[はい] です (選択されています)。詳細は、"CompressFiles" を参照してください。

    Note:

    ジャーナルの圧縮とジャーナルの暗号化 ("ENCRYPT^JOURNAL を使用したジャーナルの暗号化" を参照) の両方が有効な場合、ジャーナル・データは常に、圧縮されてから暗号化されます。暗号化されたデータは圧縮されることはありません。

  • [ライト・イメージ・ジャーナル・エントリ] — ライト・イメージ・ジャーナル (WIJ) ファイルの場所を入力します。この設定の詳細は、このドキュメントの “ライト・イメージ・ジャーナリングとリカバリ” の章の "ライト・イメージ・ジャーナリング" セクションを参照してください。

  • [WIJ のターゲット・サイズ (MB) (0 = 未設定)] — WIJ ファイルのターゲット・サイズを入力します。

Note:

このページの設定はすべて、インスタンスの iris.cpf ファイルに含まれています。ジャーナル設定の詳細は、"構成パラメータ・ファイル・リファレンス" の "[Journal]" を参照してください。WIJ 設定の詳細は、このドキュメントの “ライト・イメージ・ジャーナリングとリカバリ” の章の "ライト・イメージ・ジャーナル (WIJ) 設定"、および "構成パラメータ・ファイル・リファレンス" の [config] セクションの "targwijsz" と "wijdir" を参照してください。

特に指示がない限り、これらの設定のほとんどでは変更後に InterSystems IRIS を再起動する必要はありませんが、どの設定を変更した場合でも新しいジャーナル・ファイルが開始されます。

以下に示す 2 つの追加構成設定は、ジャーナリングに影響します。

  • [jrnbufs] — ジャーナル・バッファに割り当てるメモリの量を指定します。既定値は 64 MB で、最大値は 1024 MB です。最小値は Unicode インスタンスの場合は 16 MB、8 ビット・インスタンスの場合は 8 MB です。この設定値を増やすと、メモリに保管できるジャーナル・データの容量が増大するため、ジャーナリングのパフォーマンスが向上しますが、システム障害時に失われる可能性があるジャーナル・データの最大容量も増大します。データは最後のジャーナル同期の後にバッファに書き込まれているためです ("ジャーナル書き込みサイクル" を参照)。

    [jrnbufs] の設定を変更するには、管理ポータルの [メモリ詳細設定] ページに移動します ([システム管理][構成][追加設定][詳細メモリ])。[jrnbufs] の設定は、iris.cpf ファイルを編集することで変更することもできます。詳細は、"構成パラメータ・ファイル・リファレンス" の "jrnbufs" を参照してください。

  • [SynchCommit]TCOMMIT コマンドがトランザクションに関連するジャーナル・データのディスクへのフラッシュを要求するタイミングを指定します。この設定を true に設定すると、ジャーナル・データの書き込み処理が完了するまで TCOMMIT は待機します。false (既定値) に設定すると、TCOMMIT は書き込み処理の完了を待機しなくなります。

    [SynchCommit] の設定を変更するには、管理ポータルの [互換性設定] ページに移動します ([システム管理][構成][追加設定][互換性])。[SynchCommit] の詳細は、"構成パラメータ・ファイル・リファレンス" の "SynchCommit" と "ObjectScript リファレンス" の "TCOMMIT" を参照してください。

ジャーナリング処理タスク

ジャーナルを構成しておくと、以下のタスクを実行できるようになります。

ジャーナリングの開始

ジャーナリングが停止しているときは、^JRNSTART ルーチンを使用するか、または ^JOURNAL ルーチン・メニューからオプション 1 の [ジャーナリングの開始] を選択して、ジャーナリングを開始できます。詳細は、"^JRNSTART を使用したジャーナリングの開始" を参照してください。

Note:

管理ポータルからジャーナリングは開始できません。

ジャーナリングを開始すると、監査が有効になっている場合は InterSystems IRIS によって変更に対する監査が実行されます。

ジャーナリングの停止

システム全体のジャーナリングを停止すると、"ジャーナルの [エラー発生時に凍結する] 設定が [いいえ] の場合" セクションで説明するように、多くの望ましくない結果が発生します。

ジャーナルを停止すると、トランザクション処理も中断します。ジャーナリングを停止したときにトランザクションが進行中の場合、ジャーナルには不完全なトランザクションが格納されます。この問題を避けるため、ジャーナルを停止する前に、すべてのユーザがシステムから切断されていることを確認してください。

ジャーナリングを停止した状態で InterSystems IRIS がクラッシュすると、ジャーナリングを停止する前に始まっていたトランザクションが不完全な状態になっていても、起動時のリカバリ・プロセスではそのトランザクションはロールバックされません。これは、トランザクションはコミットされていてもジャーナリングされていないからです。

一方、ジャーナル・ファイルを切り替えても、トランザクションには影響がありません。ジャーナルの切り替えで複数のジャーナル・ファイルが生成され、それらにトランザクションが分散しても、ロールバックは正確に実行されます。したがって、可能であれば、ジャーナリングを停止するよりもジャーナル・ファイルを切り替えることをお勧めします。

ジャーナリングを停止するには、^JRNSTOP ルーチンを使用するか、または ^JOURNAL ルーチン・メニューからオプション 2 の [ジャーナリングの停止] を選択します。詳細は、"^JRNSTART を使用したジャーナリングの停止" を参照してください。

Note:

管理ポータルからジャーナリングは停止できません。

ジャーナリングを停止すると、監査が有効になっている場合は InterSystems IRIS によって変更に対する監査が実行されます。

ジャーナル・ファイルの表示

ジャーナル・ファイルは、管理ポータルの [ジャーナル] ページ ([システム処理][ジャーナル]) で表示できます。

  1. [ジャーナル] ページでは、必要に応じて [フィルタ] ボックスを使用して、ジャーナル・ファイルのリストの件数を絞り込むことができます。

    インスタンスがミラー・メンバとして構成されている場合、既定では、ミラーリングされるものとミラーリングされないものを含めて、すべてのジャーナル・ファイルが表示されます。必要に応じて、ミラー名を含むリンク (例 : Mirror Journal Files Of 'MUNDANE') をクリックして、ミラー・ジャーナル・ファイルのみのリストを表示します。インスタンスが複数のミラーのレポート非同期メンバとして構成されている場合、ミラーごとにジャーナル・ファイル用の個別のリンクがあります。すべてのジャーナル・ファイルの表示に戻るには、[すべてのジャーナル・ファイル] リンクをクリックします。

    Note:

    ミラー・ジャーナル・ファイルの詳細は、この章の "ジャーナル・ファイルとジャーナル履歴ログ" および "高可用性ガイド" の “ミラーリング” の章の "ミラー同期" を参照してください。

  2. ジャーナル・ファイルを表示するには、表示するジャーナル・ファイルの行で [表示] をクリックします。ジャーナル・ファイルは、[ジャーナル表示] ページにレコードごとに表示されます。以下のフィールドがあります。

    • オフセット — ジャーナル・ファイル内のレコードのオフセット番号。

    • 時間 — ジャーナル・レコードを含むバッファが作成された時間 (レコードに記述された操作が発生した時間ではありません)。

    • プロセス — レコードを作成したプロセスの ID。

    • タイプ — レコードに記述された操作のタイプ ([タイプ] 列に示される値についての情報は、"^JRNDUMP を使用したジャーナル・レコードの表示" のセクションの "ジャーナル・ファイルの処理" テーブルで提供されています)。

    • トランザクション中 — 操作がトランザクションの一部として発生したかどうか。

    • グローバルノード — 操作によって変更されたグローバル・ノード。

    • データベース — 変更が発生したデータベース。

  3. 以下を実行できます。

    1. レコードの [オフセット] 列をクリックし、レコードの詳細を含むダイアログ・ボックスを表示します。

    2. 以下の項目ごとにレコードを色分けするかどうかを選択します。バッファ作成時刻、ジャーナルに記録された処理を実行したプロセス、処理のタイプ、処理がトランザクションの一部かどうか、処理に関与したグローバル、処理に関与したデータベース。

    3. [一致] ボックスおよび [検索] ボタンを使用して、レコードの特定のレコード・セットを検索します。

      1. 手動検索の場合、最初のドロップダウンを検索基準にする列に設定し、“等しい” や “等しくない” などの演算子を選択し、比較する値を最も右のボックスに入力し、[検索] をクリックします。

      2. 列の 1 つの特定のセルを比較するには、単にそのセルをダブルクリックします。例えば、KILL 処理を含むすべてのジャーナル・レコードを検索するには、[KILL] を含む [タイプ] 列の任意のセルをダブルクリックします。演算子ドロップダウンは自動的に “等しい” に設定されますが、[検索] を押す前に変更できます。

^JRNDUMP ユーティリティを使用してジャーナル全体を表示したり、SELECT^JRNDUMP のエントリ・ポイントを使用して、選択したエントリを表示したりすることもできます。詳細は、"^JRNDUMP を使用したジャーナル・レコードの表示" を参照してください。

ジャーナル・ファイルの切り替え

システムは、以下の状況でジャーナル・ファイルを自動的に切り替えます。

  • InterSystems IRIS データベースのバックアップ実行後。

  • 現在のジャーナル・ファイルのサイズが最大許容量 ([ジャーナル設定] ページで設定可能) に達したとき。

  • 代替ディレクトリが指定されている場合に、ジャーナル・ディレクトリが使用不可能になったとき。

  • 管理ポータルの [ジャーナル設定] ページ ([システム管理][構成][システム構成][ジャーナル設定]) での設定の更新後。

ジャーナリングを停止して開始するより、ジャーナル・ファイルを切り替える方が望ましい選択です。これは、前者のプロセスでは、停止後、再開するまでに発生したグローバル操作はジャーナリングされないためです。

ジャーナル・ファイルを手動で切り替えるには、以下の手順に従います。

  1. 管理ポータルの [ジャーナル] ページ ([システム処理][ジャーナル]) に移動します。

  2. データベース・ジャーナル・ファイルのリストの上にある [ジャーナルの切り替え] をクリックします。

  3. [OK] をクリックして、ジャーナルの切り替えを確定します。

^JRNSWTCH ルーチンを使用するか、または ^JOURNAL ルーチン・メニューからオプション 3 の [ジャーナル・ファイルの切り換え] を選択することで、ジャーナル・ファイルを切り替えることもできます。詳細は、"^JRNSWTCH を使用したジャーナル・ファイルの切り替え" を参照してください。

ジャーナル・ディレクトリの切り替え

"ジャーナル設定の構成" の説明のように、ジャーナリングは、プライマリ・ディレクトリが何らかの理由で書き込みできなくなった場合、自動的にセカンダリ・ジャーナル・ディレクトリに切り替わります (構成されていることが前提)。ジャーナル・ディレクトリを手動で切り替えるには、以下を実行します。

  1. 管理ポータルの [ジャーナル] ページ ([システム処理][ジャーナル]) に移動します。

  2. データベース・ジャーナル・ファイルのリストの上にある [ディレクトリの切り替え] をクリックします。

  3. [OK] をクリックして、ジャーナルの切り替えを確定します。

^JOURNAL ルーチン・メニューからオプション 13 の [ジャーナルのセカンダリ/プライマリ・ディレクトリへの切り替え] を選択することで、ジャーナル・ディレクトリを切り替えることも可能です。詳細は、"SWDIR^JOURNAL を使用したジャーナル・ディレクトリの切り替え" を参照してください。

ジャーナル・ファイル・プロファイルの表示

[ジャーナル] ページでは、ジャーナル・ファイルのグローバル・プロファイルを表示できます。このプロファイルには、ファイルのレコードに表示されるグローバルおよびそれぞれのレコード数が示されます。

  1. [ジャーナル] ページでは、必要に応じて [フィルタ] ボックスを使用して、ジャーナル・ファイルのリストの件数を絞り込むことができます。

  2. ジャーナル・ファイルのプロファイルを表示するには、該当のジャーナル・ファイル行の [プロファイル] をクリックします。[ジャーナルプロファイル] ページにプロファイルが表示されます。ジャーナル・ファイルに多数のレコードがある場合、プロファイルの構築に時間がかかる場合があります。

  3. ジャーナル・プロファイルは、グローバルごと、または各グローバルが表示されるすべてのレコードの累積サイズごと (バイト単位) にソートすることができます。

  4. ジャーナル・ファイルが現在使用中のものの場合、一定の時間経過後に [再計算] ボタンを使用してプロファイルを再構築できます。

ジャーナル・ファイルの整合性のチェック

[ジャーナル] ページでは、ジャーナル・ファイルの整合性をチェックできます。この処理では、ジャーナル・ファイルが想定された場所で終了していることを確認し、ファイルの終わりからレコードの欠落がないことを確認します。

  1. [ジャーナル] ページでは、必要に応じて [フィルタ] ボックスを使用して、ジャーナル・ファイルのリストの件数を絞り込むことができます。

  2. ジャーナル・ファイルの整合性チェックを実行するには、該当のジャーナル・ファイル行の [整合性チェック] をクリックします。[ジャーナル整合性チェック] ページが表示されます。

  3. [詳細確認] を選択し、ジャーナル・ファイルのレコードをレコードごとに最初からスキャンし、潜在的な欠落レコードを検出します。

  4. [OK] をクリックすると、[バックグラウンドタスク] ページ ([システム処理][バックグラウンドタスク]) へのリンクが表示され、整合性チェックのステータスおよび結果を表示できます。

ジャーナル・ファイルの要約の表示

[ジャーナル・ファイルの要約] ページでは、ジャーナル・ファイルに関する要約を表示できます。例えば、ジャーナル・ファイルが暗号化されているかどうか、ジャーナル・ファイルに記録されている操作の影響を受けるのはどのデータベースか、などを確認できます。

  1. ホーム ページの [システム処理] メニューで [ジャーナル] をクリックし、インスタンスのジャーナル・ファイルを一覧表示します。必要に応じて、[フィルタ] ボックスを使用してリストの件数を絞り込みます。

  2. ジャーナル・ファイルに関する情報を表示するには、該当のジャーナル・ファイル行の [要約] をクリックします。[ジャーナル・ファイルの要約] ページが表示されます。

ジャーナル・ファイルの削除

使用しなくなったジャーナル・ファイルを削除するタスクを定期的に実行するようにスケジュールできます。新しい InterSystems IRIS インスタンスには、事前にスケジュールされたジャーナルの削除タスクがあります。このタスクは、毎日午前 0 時に実行するジャーナルの切り替えタスクの後に実行するようにスケジュールされています。ミラー・ジャーナル・ファイルの削除に関する詳細は、"ミラー・ジャーナル・ファイルの削除" を参照してください。

この削除プロセスでは、[ジャーナル設定] ページの [ジャーナルファイルを削除するタイミング] の設定に基づいてジャーナル・ファイルを削除します。詳細は、この章の "ジャーナルの設定の構成" を参照してください。

Note:

ジャーナル・ファイルは、削除の設定の条件を満たしていても保持される場合があります。この場合、イベントはメッセージ・ログに記録され、理由 (例えば、ジャーナル・ファイルに開いているトランザクションが含まれているなど) が示されます。

PURGE^JOURNAL ルーチンを使用するか、または ^JOURNAL ルーチン・メニューからオプション 6 の [ジャーナル・ファイルの削除] を選択することで、ジャーナル・ファイルを削除することもできます。詳細は、"PURGE^JOURNAL を使用したジャーナル・ファイルの削除" を参照してください。

Note:

構成されているジャーナル削除設定は %ZJRNPURGE ルーチンでオーバーライドできます。詳細は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

ミラー・ジャーナル・ファイルの削除

ミラー・ジャーナル・ファイルは、プライマリ・フェイルオーバー・メンバによって他のミラー・メンバに正しく配布され、それぞれでデジャーナルされて、ミラーリングされるデータベースと同期する必要があるため、追加の削除条件に従います (このプロセスの詳細は、"高可用性ガイド" の “ミラーリング” の章にある "ミラー同期" を参照してください)。ミラーが通常動作しているときには、ファイルのバックアップへの転送は同期的に実行され、常に高速ですが、非同期メンバへの転送には時間がかかり、非同期メンバがミラーから切断されているときには遅延する場合があります。バックアップ・メンバおよび DR 非同期メンバは、フェイルオーバーまたは災害復旧の状況ではプライマリになる資格があるため、プライマリと同じポリシーにも従う必要があります。したがって、ミラー・ジャーナル・ファイルは以下のように削除されます。

  • プライマリ・フェイルオーバー・メンバでは、ローカル・ジャーナル・ファイルの削除条件が満たされたとき ("ジャーナル設定の構成" を参照) およびバックアップ・メンバ (存在する場合) とすべての非同期メンバに受信されたとき、ファイルは削除されます (いずれか長時間要する方)。ただし、非同期メンバがミラーから 14 日間以上切断されたままの場合、その非同期メンバがファイルを受信していなくてもそのファイルは削除されます。

  • バックアップ・フェイルオーバー・メンバ (存在する場合) およびすべての災害復旧 (DR) 非同期メンバでは、そのメンバで完全にデジャーナルされたとき、ローカル・ジャーナル・ファイルの削除条件が満たされたとき、およびすべての非同期メンバに受信されたとき、ファイルは削除されます。ただし、非同期メンバが 14 日間よりも長く切断されたままの場合には同じ例外が適用されます。

  • レポート非同期メンバでは、ミラー・ジャーナル・ファイルは、既定ではデジャーナルされた直後に削除され、非同期ミラー・メンバが領域を使い果たさないようにします (特に、非同期メンバが複数のミラーからジャーナル・ファイルを受け取っている場合)。必要に応じて、レポート非同期メンバを構成して、代わりにファイルを保持し、ローカル・ジャーナル・ファイルの削除条件に従って削除するようにできます。“ミラーリング” の章の "非同期メンバの編集または削除" を参照してください。

現在開いているトランザクションを含むミラー・ジャーナル・ファイルはどのミラー・メンバでも削除されません。

Note:

ローカル・ジャーナル・ファイルの削除条件の規定時間よりも長くミラー・ジャーナル・ファイルが保持されると、メンバのメッセージ・ログにこれが記録され、その理由が示されます。

SYS.Mirror.JrnPurgeDefaultWait()Opens in a new tab メソッドを使用すると、ミラー・ジャーナル・ファイルを削除するための既定の設定を変更できます。

ジャーナル・ファイルのリストア

システム・クラッシュあるいはディスク・ハードウェア障害の後、バックアップ・コピーをリストアして、データベースを再生成します。ジャーナリングが有効になっていてジャーナル・ファイルにアクセスできる場合は、最後のバックアップ以降にジャーナルに記録された変更をデータベースに適用することで、さらにデータベースをリストアできます。

ジャーナル・ファイルをリストアする手順は以下のとおりです。

  1. まず、すべてのユーザが InterSystems IRIS を終了していることを確認します。

  2. ジャーナリングがインスタンスについて有効になっている場合、^JRNSTOP を使用してジャーナリングを停止します ("^JRNSTOP を使用したジャーナリングの停止" を参照)。

  3. データベースの最新バックアップをリストアします。

  4. ジャーナル・リストア・ユーティリティを実行します。詳細は、"^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" を参照してください。

  5. ジャーナリングが無効の場合、再開します。

Note:

管理ポータルからジャーナル・リストア・プロセスを実行することはできません。

ジャーナリング・ユーティリティ

InterSystems IRIS には、ジャーナリング・タスクを実行するためのユーティリティが用意されています。^JOURNAL ユーティリティには、いくつかの一般的なジャーナリング・ユーティリティを実行するためのメニュー項目があります。これらのユーティリティは、単独で実行することも可能です。また、%SYS ネームスペースから実行するジャーナリング・ユーティリティもいくつかあります。

以下のセクションでは、ジャーナリング・ユーティリティについて詳しく説明します。

以下のセクションでは、サンプル・プロシージャは、C:\MyIRIS を InterSystems IRIS インストール・ディレクトリとして示します。

^JOURNAL を使用したジャーナリング・タスクの実行

以下の例は、^JOURNAL ルーチンを呼び出すことによって使用できるメニューを示しています。以下の例ではフル・メニューは繰り返し説明しません。

%SYS>Do ^JOURNAL
 
 1) Begin Journaling (^JRNSTART)
 2) Stop Journaling (^JRNSTOP)
 3) Switch Journal File (^JRNSWTCH)
 4) Restore Globals From Journal (^JRNRESTO)
 5) Display Journal File (^JRNDUMP)
 6) Purge Journal Files (PURGE^JOURNAL)
 7) Edit Journal Properties (^JRNOPTS)
 8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
 9) Display Journal status (Status^JOURNAL)
10) -not available-
11) -not available-
12) Journal catch-up for mirrored databases (MirrorCatchup^JRNRESTO)
13) Switch Journaling to Secondary Directory (SWDIR^JOURNAL)

Option?
Note:

オプション 11) 保留中または処理中のトランザクション・ロールバックの管理 (Manage^JRNROLL) は、^STURECOV ルーチン (システムの起動時) または ^MIRROR ルーチン (プライマリ・ミラー・メンバの起動時) を実行したときに、保留中または処理中のトランザクション・ロールバックが検出された場合に表示されます。詳細は、この節の "Manage^JRNROLL を使用したトランザクション・ロールバックの管理" を参照してください。

特定のルーチンを開始するには、該当するメニューのオプション番号を入力します。ユーティリティを終了するには、オプションの番号を入力せずに Enter キーを押します。以下のサブセクションでは、^JOURNAL ユーティリティで使用可能なオプションについて説明します。

^JRNSTART を使用したジャーナリングの開始

ジャーナリングを開始するには、以下の例に示すように、^JRNSTART を実行するか、または^JOURNAL メニューのオプション・プロンプトで「1」を入力します。

^JRNSTART を直接実行する例

%SYS>Do ^JRNSTART

^JOURNAL メニューからジャーナリングを開始する例

%SYS>Do ^JOURNAL
 
 1) Begin Journaling (^JRNSTART)
 ...
Option? 1

このオプションを選択したときにジャーナリングを実行している場合、以下のようなメッセージが表示されます。

Already journaling to C:\MyIRIS\mgr\journal\20181113.001 

^JRNSTOP を使用したジャーナリングの停止

ジャーナリングを停止するには、以下の例に示すように、^JRNSTOP を実行するか、または^JOURNAL メニューのオプション・プロンプトで「2」を入力します。

Note:

[エラー発生時に凍結する] フラグ (この章の "ジャーナル設定の構成" を参照) が [はい] に設定されている場合、ジャーナリングの停止が許可されます (ただし、データ損失のリスクがあります)。インスタンスは凍結されません。

^JRNSTOP を直接実行する例

%SYS>Do ^JRNSTOP
 
Stop journaling now? No => Yes


^JOURNAL メニューからジャーナリングを停止する例

%SYS>Do ^JOURNAL
 
 ...
 2) Stop Journaling (^JRNSTOP)
 ...
Option? 2
Stop journaling now? No => Yes

このオプションを選択したときにジャーナリングを実行していない場合、以下のようなメッセージが表示されます。

Not journaling now.

^JRNSWTCH を使用したジャーナル・ファイルの切り替え

ジャーナル・ファイルを切り替えるには、^JRNSWTCH を実行するか、または以下の例に示すように、^JOURNAL メニューのオプション・プロンプトで「3」を入力します。

%SYS>Do ^JOURNAL
 
 ...
 3) Switch Journal File (^JRNSWTCH)
 ...
Option? 3
Switching from: C:\MyIRIS\mgr\journal\20181113.002
To:             C:\MyIRIS\mgr\journal\20181113.003

このユーティリティでは、以前のジャーナル・ファイル名および現在のジャーナル・ファイル名が表示されます。

SWDIR^JOURNAL を使用したジャーナル・ディレクトリの切り替え

"ジャーナル設定の構成" の説明に従ってセカンダリ・ディレクトリが構成されているものとして、ジャーナル・ディレクトリを切り替えるには、SWDIR^JOURNAL を実行するか、または以下の例に示すように ^JOURNAL メニューの [オプション] プロンプトで 13 と入力します。

%SYS>Do ^JOURNAL
 
 ...
13) Switch Journaling to Secondary Directory (SWDIR^JOURNAL)

Option? 3
Option? 13
Journaling to \\remote\MyIRIS\journal_secondary\MIRROR-MIRRORONE-20180720.007

切り替えの後、現在のジャーナル・ディレクトリとジャーナル・ファイルの名前が表示されます。

^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア

InterSystems IRIS ^JRNRESTO ルーチンは、バックアップからデータベースをリストアした後で使用して、ジャーナル・ファイルのデータベース更新内容を適用することで、データベースを障害発生の直前の状態に戻します。これは、ジャーナル・リストアと呼ばれています。また、更新の適用プロセスは、デジャーナリングと呼ばれています。ジャーナル・リストアでは、バックアップの作成と障害発生の間に作成されたすべてのジャーナル・レコードをデジャーナルします。例えば、データベースのバックアップを火曜日の早朝に作成し、データベースが水曜日の午後にクラッシュした場合は、火曜日のバックアップをリストアした後で、火曜日と水曜日に作成されたジャーナル・ファイルから更新をリストアできます。

使用可能なシステム・リソースが十分にある場合は、1 つのジャーナル・リストア操作の中で最大 16 のデジャーナリング・ジョブで並列して更新を実行できます ("並列デジャーナリングのシステム要件" を参照)。これにより、操作のパフォーマンスが向上します。これは、並列デジャーナリングと呼ばれます。複数のアップデータで同時に同じデータベースを更新することはできますが、同じグローバルを更新することはできません。これにより、少数のデータベースに更新を適用する場合は、各グローバル内のデータの論理的な整合性を確保しつつ、スループットを向上させられます。

並列デジャーナリングは、ホスト・システムに並列デジャーナリングをサポートするために十分な CPU が搭載されていて、この目的に割り当て可能な共有メモリ・ヒープ (gmheap) を InterSystems IRIS インスタンスが十分に確保している場合にのみ有効になります。実際には、gmheap が増加されている場合を除き、ほとんどの InterSystems IRIS インスタンスでジャーナル・リストアに並列デジャーナリングが使用されることはありません。並列デジャーナリングのジョブ数は、gmheap のサイズを 200 MB で除算した数を超過することはできません。例えば、同時に 4 つのデジャーナリング・ジョブが実行されているとすると、800 MB 以上の gmheap が必要になります (並列デジャーナリングをサポートするにはメモリが不足している場合でも、共有メモリ・ヒープのサイズを既定値よりも増やすと、デジャーナリングのスループットが向上することがあります)。

Note:

共有メモリ・ヒープまたは gmheap (共有メモリヒープや SMH とも呼びます) のサイズを変更するには、[メモリ詳細設定] ページ ([システム管理][構成][追加設定][メモリ詳細]) に移動します。詳細は、"システム管理ガイド" の “InterSystems IRIS の構成” の章にある "メモリと開始設定" を参照してください。

並列デジャーナリングは、InterSystems IRIS のミラーリングでも使用されることがあります。"高可用性ガイド" の “ミラーリング” の章にある "並列デジャーナリングの構成" を参照してください。

^JRNRESTO でリストアされるデータベースは、ジャーナルをリストアする時点でジャーナル状態が Yes になっているもののみです。各データベースが初めて検出されたときに、このルーチンによってデータベースのジャーナル状態の検査が行われ、記録されます。リストアのプロセスでは、ジャーナル状態が No であるデータベースのジャーナル・レコードは無視されます。ジャーナル記録対象として指定されているデータベースがない場合、リストアを終了するかどうかを尋ねるメッセージが表示されます。ここで、特定のデータベースについてデータベースのジャーナル状態を Yes に変更し、^JRNRESTO を再起動できます。

Note:

リストアの時点でのデータベースのジャーナル状態によって、実行するアクションが決まります。InterSystems IRIS では、指定されたジャーナル・レコードを書き込むときに、データベースの現在のジャーナル状態に関しては何もジャーナルに保存しません。つまり、ジャーナル状態が Yes のデータベースに対する変更は永続的ですが、それ以外のデータベースの場合は変更は永続的ではありません。InterSystems IRIS では、物理的な整合性は保証されますが、トランザクションに関与するデータベースのジャーナル状態が No の場合は、アプリケーションの整合性が必ずしも保証されるとは限りません。

^JRNRESTO では、以下のように、ジャーナルのリストアに関するいくつかの決定を行うことができます。

  • ルーチンを実行している InterSystems IRIS インスタンスのデータベース、または別の InterSystems IRIS インスタンスのデータベースへのグローバル更新のリストア。現在のインスタンスですべてのデータベースにすべてのグローバルの更新をリストアするように選択したり、現在のインスタンスまたは別のインスタンスで個別データベースを選択できます。また、必要に応じて、それぞれにリストアするグローバルを指定できます。

  • ミラーリングされるデータベースへのミラー・ジャーナル・ファイルのリストア (ミラーリングされるデータベースのキャッチアップ) またはミラーリングされないデータベースへのミラー・ジャーナル・ファイルのリストア。以下の手順に示すように、ミラー・メンバでは、ミラーリングされるデータベースをキャッチアップするかどうかを示すように求めるプロンプトが表示されます。これを行う場合、手順は ^JRNRESTO への MirrorCatchup^ エントリ・ポイントにリダイレクトされます ("MirrorCatchup^JRNRESTO を使用したミラーリングされるデータベースへのジャーナルのリストア" を参照)。

  • 既存のジャーナル・フィルタ ("^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理" を参照) をリストアに適用します。

  • リストア元のジャーナル・ファイルの範囲を選択します。

  • リストア中に更新のジャーナリングを無効にし、処理を高速化します。

  • 以下に示すエラー発生時の処理を選択します。

    • データベース関連の問題があってもジャーナル・リストアを続行する。例えば、ターゲット・データベースをマウントできない場合や、更新の適用時にエラーが発生した場合です。この設定では、影響を受けたデータベースの更新はスキップされます。これらのデータベースは、操作後に他のデータベースとの整合性がない状態になっていたり、整合性のないグローバルが含まれていたりする場合があり (ただし、各グローバル内のデータの論理的な整合性は保証されています)、個別にリカバリする必要があります。

    • データベース関連の問題のために更新をスキップしなければならない場合は、ジャーナルを中止する。この設定では、データベースと、データベースに含まれるグローバルは、リストアが中止される原因となったレコードまでは、お互いに整合性があります。この設定では、並列デジャーナリングは無効になります。

Caution:

プロンプトに応じてジャーナル・リストア・スクリプトを使用する場合には、最新のリリース以降に変更されているプロンプトが存在する可能性があるため、スクリプトを更新する必要があります。

ジャーナル・ファイルからグローバル更新をリストアするには、以下の手順を実行します。

  1. %SYS ネームスペースで ^JRNRESTO ルーチンを実行し、Restore the Journal? プロンプトで <Enter> キーを押して続行します。

  2. ミラー・メンバでこのルーチンを実行している場合は、以下のプロンプトが表示されます。

    Catch-up mirrored databases? No =>
    
    
    • ミラー・ジャーナル・ファイルが作成されたミラー内のミラーリングされるデータベースにこのミラー・ジャーナル・ファイルをリストアする場合、yes と入力します。このプロシージャは ^JRNRESTO への MirrorCatchup^ エントリ・ポイントにリダイレクトされます ("MirrorCatchup^JRNRESTO を使用したミラーリングされるデータベースへのジャーナルのリストア" を参照)。

    • ミラー・ジャーナル・ファイルをミラーリングされないデータベースにリストアするか、またはミラー・ジャーナル・ファイルをリストアしない場合は、no と入力するかまたは <Enter> キーを押して、ここで説明する手順を引き続き使用します。

  3. 既にジャーナル・フィルタが存在する場合 ("^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理" を参照)、これらのフィルタを使用するかどうかを指定します。

    Use current journal filter (ZJRNFILT)? 
    Use journal marker filter (MARKER^ZJRNFILT)? 
    
    
  4. ジャーナリングされているグローバルのすべてを現在の InterSystems IRIS インスタンスのすべてのデータベースにリストアするか、または 1 つ以上のデータベースを指定し、必要に応じて、それぞれのデータベースにリストアするグローバルを指定するかを選択します。

    Process all journaled globals in all directories? 
    
    
    • 現在のインスタンスのすべてのデータベースにすべてのグローバルをリストアする場合、「Yes」と入力します。

    • 現在のインスタンスまたは別のインスタンスの選択したデータベースのみにリストアする場合、「No」と入力するか、<Enter> キーを押します。以下の手順を実行します。

      • 現在のシステムのオペレーティング・システムと異なるオペレーティング・システムでジャーナル・ファイルを作成したかどうかを示します。リストア先のデータベースに指定するディレクトリ・パスはジャーナル・ファイルのパス (キャノニック形式) と正確に一致している必要があるため、これは重要なことです。「No」と応答した場合、^JRNRESTO は、入力したディレクトリ・パスがジャーナル・ファイルのパスと一致するように、ディレクトリ・パスを現在のオペレーティング・システムのキャノニック形式にします。「Yes」と応答した場合、^JRNRESTO は、ジャーナル・ファイルのキャノニック形式と現在のシステムのキャノニック形式が異なるため、入力したパスを正規化しません。後者の場合、注意深くジャーナル・ファイルのオペレーティング・システムに対して適切なキャノニック形式でディレクトリ・パスを入力し、両方が一致するようにする必要があります。

        以下はその例です。

        • Windows システムで作業をしていて、このプロンプトで「No」を入力し、パス c:\intersystems\iris\mgr\user を入力すると、^JRNRESTO は、これを自動的に c:\intersystems\iris\user\ に正規化し、Windows システムで作成されたジャーナル・ファイルと一致させます。

        • Unix® システムで作業していて、ジャーナル・ファイルを Windows システムで作成したためにこのプロンプトで「Yes」と入力した場合、キャノニック形式のパス c:\intersystems\iris\mgr\user\ を入力し、ジャーナル・ファイルと一致させる必要があります。これは、^JRNRESTO がパスを正規化できないためです。

      • ディレクトリ・パスを入力してリストアする各データベースを指定します。これは、ジャーナル・レコードの取得元のソース・データベースを示します。Redirect to directory プロンプトで <Enter> キーを押し、ソースとターゲットが同じであることを示し、グローバル更新をソース・データベースにリストアします。別のデータベースにリストアしている場合 (例えば、ソース・データベースをバックアップから別のシステムにリストアしたため)、ターゲット・データベースのディレクトリ・パスを入力します。

        ミラー・ジャーナル・ファイルをミラーリングされないデータベースにリストアする場合は、Directory to restore プロンプトで、以下のいずれかを実行します。

        • ソース・データベースのディレクトリ・パスを入力してから、<Enter> キーを押すかまたはターゲットのミラーリングされないデータベースのディレクトリ・パスを入力します (前述の説明を参照)。

        • ミラーリングされるソース・データベースの大文字と小文字を区別した完全なミラー・データベース名を入力します (例えば、:mirror:JLAP:MIRRORDB)。これを見つけるには、^MIRROR ユーティリティの [ミラー・ステータス] メニューにある [ミラーリングされるデータベースを一覧表示] オプションを使用します。その後、ターゲットのミラーリングされないデータベースのディレクトリ・パスを指定します。

        Note:

        ミラー・ジャーナル・ファイルをミラーリングされるデータベースにリストアする場合、この手順ではここまでは説明しません。"MirrorCatchup^JRNRESTO を使用したミラーリングされるデータベースへのジャーナルのリストア" を参照してください。

      • 指定した各データベースについて、すべてのグローバルの更新をリストアするか、またはリストアする 1 つ以上のグローバルを入力するかを確認します。

      • すべてのデータベースを入力した場合、Directory to restore プロンプトで <Enter> キーを押し、指定したデータベースおよびグローバルのリストを確認します。

      以下はその例です。

      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\test23\mgr\user\
      Redirect to Directory: c:\intersystems\test23\mgr\user\
       => --> c:\intersystems\test23\mgr\user\
      Process all globals in c:\intersystems\test23\mgr\user\? No => yes
       
      Directory to restore [? for help]: c:\intersystems\test23\mgr\data\
       Redirect to Directory: c:\intersystems\test23\mgr\data\
       => --> c:\intersystems\test23\mgr\data\
      Process all globals in c:\intersystems\test23\mgr\data\? No => no
      
      Global ^Survey.LastName
      Global ^Survey.ID
      Global ^
      
      Directory to restore [? for help]:
      
      Processing globals from the following datasets:
       1. c:\intersystems\test23\mgr\user\   All Globals
       2. c:\intersystems\test23\mgr\data\   Selected Globals:
                ^Survey.LastName
                ^Survey.ID
      
      Specifications correct? Yes =>  Yes
      
      
      Note:

      複数のデータベースを同じディレクトリにリダイレクトする場合は、同じグローバル選択を行う必要があります。つまり、対象のデータベースすべてについて、「yes」と入力し、すべてのグローバルを処理するか、「no」と入力し、処理するグローバルの同一リストを指定します。複数のデータベースを 1 つのディレクトリにリストアする場合にグローバル選択がすべて同じでないと、データベースのリダイレクトとグローバル選択を変更するか、処理をキャンセルするよう求められます。

  5. 正しいジャーナル履歴ログ (この章の "ジャーナル履歴ログ" を参照) を指定して、リストア元 (リストアしているソース・データベースと同じ InterSystems IRIS インスタンス) のジャーナル・ファイルを指定します。

    • プロンプトで「yes」と入力するかまたは <Enter> キーを押し、現在の InterSystems IRIS インスタンスのジャーナル履歴ログを使用して、処理するジャーナル・ファイルを特定します。例えば、プロセスの最初に Process all journaled globals in all directories? プロンプトで「yes」と入力した場合、ここで「yes」と入力し、現在のインスタンスのジャーナル・ファイルから現在のインスタンスのすべてのデータベースをリストアします。

    • Process all journaled globals in all directories? プロンプトで「no」と入力し、別の InterSystems IRIS インスタンスのデータベースを指定した場合、ここで「no」と入力し、そのインスタンス (またはそのインスタンスからコピーしたファイル) のジャーナル履歴ログおよびジャーナル・ファイルのディレクトリ・パスを指定し、そのインスタンスのジャーナル・ファイルからデータベースをリストアできるようにします。

      Important:

      別の InterSystems IRIS インスタンスからジャーナル履歴ログを使用している場合、実際のログではなくファイルのコピーを使用する必要があります。

      以下はその例です。

      If you have a copy of the journal history log file from the 
      instance where the journal files were created, enter its full path below;
      otherwise, press ENTER and continue.
      Journal history log: c:\InterSystems\IRIS23_journals\journal.log
      
      Specify the location of the journal files to be processed
      Directory of the journal files:  c:\InterSystems\IRIS23_journals\journal\
      Directory of the journal files: 
      
      
  6. 処理対象とするジャーナル・ファイルの範囲を指定します。以下の点に注意してください。

    • リストアされたバックアップ以後に InterSystems IRIS が複数のジャーナル・ファイルに切り替えた場合、最も古いジャーナル・ファイルから順番に、最新のものまでをリストアする必要があります。例えば、リストアする必要がある 3 つのジャーナル・ファイル 20180214.00120180214.00220180215.001 がある場合、以下の順番でリストアする必要があります。

      20180214.001

      20180214.002

      20180215.001

    • オンライン・バックアップでバックアップすると、リストア時のトランザクション・ロールバックに必要な最も古いジャーナル・ファイルに関する情報が 3 番目または最後のパスの開始時に表示され、バックアップ・ログにも格納されます。詳細は、このドキュメントの “バックアップとリストア” の章を参照してください。

    以下のようにプロンプトに応答してください。

    • このインスタンスがジャーナル・ファイルを作成するかどうかに関する前述のプロンプトで「yes」と入力した場合、または「no」と応答してから別のインスタンスのジャーナル履歴ログおよびジャーナル・ファイルの場所を指定した場合、処理する最初のジャーナル・ファイルおよび最後のジャーナル・ファイルのパス名を入力できます。いずれのプロンプトにも「?」を入力して、指定した場所にあるファイルの番号付けされたリストを確認し、ファイルの番号を入力できます。以下はその例です。

      Specify range of files to process
      Enter ? for a list of journal files to select the first and last files from
      First file to process:  ?
       
      1) c:\intersystems\iris2\mgr\journal\20180212.001
      2) c:\intersystems\iris2\mgr\journal\20180213.001
      3) c:\intersystems\iris2\mgr\journal\20180214.001
      4) c:\intersystems\iris2\mgr\journal\20180214.002
      5) c:\intersystems\iris2\mgr\journal\20180215.001
      6) c:\intersystems\iris2\mgr\journal\20180216.001
      7) c:\intersystems\iris2\mgr\journal\20180217.001
      8) c:\intersystems\iris2\mgr\journal\20180217.002
      
      First file to process:  5 c:\intersystems\iris2\mgr\journal\20180215.001
      Final file to process:
        c:\intersystems\20181316mar14\mgr\journal\20180217.002 => 
      
      Prompt for name of the next file to process? No => no
      
      
    • このインスタンスがジャーナル・ファイルを作成するかどうかに関する前述のプロンプトで「no」を入力し、ジャーナル履歴ログを指定しなかった場合、処理する特定のジャーナル・ファイルを特定しようとするプロンプトで処理が続行されます。以下はその例です。

      Journal history log:
      Specify range of files to process (names in YYYYMMDD.NNN format)
       
      from:     <20180212.001> [?] => 20180215.001
       
      through:  <20180217.001> [?] => 20180217.002
       
      Prompt for name of the next file to process? No => no
       
      Provide or confirm the following configuration settings:
       
      Journal File Prefix: [?] =>
       
      Files to dejournal will be looked for in:
           c:\intersystems\iris\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} -
           [Directory search list is emptied]
      Directory to search: {return when done} c:\intersystems\iris2\mgr\journal
      Directory to search: {return when done}
      Here is a list of directories in the order they will be searched for files:
           c:\intersystems\iris2\mgr\journal\
      
      
  7. 以下のようにジャーナル・ファイルを処理します。

    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 => Yes
    
    
  8. 指定した範囲内で 1 つまたは複数のジャーナル・ファイルが見つからない場合は、操作の中止を選択できます。操作を中止しなかった場合、またはファイルがすべて見つかった場合は、処理が続行され、リストアを開始する前にジャーナルの整合性をチェックする機会が得られます。

    Journal files in the order they will be processed:
    1. c:\intersystems\iris2\mgr\journal\20180215.001
    2. c:\intersystems\iris2\mgr\journal\20180216.001
    3. c:\intersystems\iris2\mgr\journal\20180217.001
    4. c:\intersystems\iris2\mgr\journal\20180217.002
    
    While the actual journal restore will detect a journal integrity problem
    when running into it, you have the option to check the integrity now
    before performing the journal restore. The integrity checker works by
    scanning journal files, which may take a while depending on file sizes.
    Check journal integrity? No => No
    
    
  9. 現在のジャーナル・ファイルがリストアに含まれている場合は、ジャーナリングを別のファイルに切り替える必要があり、そのためのプロンプトが表示されます。

    The journal restore includes the current journal file.
    You cannot do that unless you stop journaling or switch
         journaling to another file.
    Do you want to switch journaling? Yes => yes
    Journaling switched to c:\intersystems\iris2\mgr\journal\20180217.003
    
  10. 次に、リストア中に更新のジャーナリングを無効にし、処理を高速化するかどうかを選択します。

    You may disable journaling of updates for faster restore for all
    databases other than mirrored databases. 
    Do you want to disable journaling the updates? Yes => yes
    Updates will NOT be journaled
    
    
    Important:

    リストア中の更新のジャーナリングを無効化していないと、このセクションの冒頭で説明したように、パフォーマンスを向上するための並列デジャーナリングが使用されなくなります。

    ジャーナリングが無効になっている状態でデータベースの更新を継続すると、下記のいずれかを確実にしない限り、最新の良好なジャーナルを使用して手動でリストアすることはできなくなります。

    • 更新される内容を正確に把握し、アプリケーションの要件を満足するためにリストアされる内容を管理できます。

    • 関連するデータベースを最後のバックアップからリストアしたうえで、ジャーナルを適用すると、ジャーナルが無効な状態で書き込まれたデータが喪失することを容認します。

    このような状況では、ジャーナルのリストア完了後に下記のコマンドを実行し、オブジェクト ID が同期していることを確認することをお勧めします。同期していないことが判明した ID のみが配列 errors にレポートされます。

    Do CheckIDCounters^%apiOBJ(.errors)
    zwrite errors
    
  11. リストア・ジョブのエラー発生時の既定の動作を確認または変更した後、リストアを開始することを確認します。

    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 cannot be mounted, error applying an update, etc.), skipping
         updates to that database. Affected database(s) may not be self-consistent
         and will need to be recovered separately
     
         ALTERNATE:  Abort if an update would have to be skipped due to a
         database-related problem (e.g., a target database cannot be mounted,
         error applying an update, etc.). Databases will be left in a
         self-consistent state as of the record that caused the restore to be
         aborted. Parallel dejournaling will be disabled with this setting  
    
         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 =>
    
    Important:

    データベース関連の問題が原因で中断しないようにする場合は、このセクションの冒頭で説明したように、パフォーマンスを向上させるための並列デジャーナリングが使用されなくなります。

  12. ジャーナル・リストアの進行状況は間隔をおいて表示され、ジョブが完了すると、このリストアによって更新されたデータベースのリストが表示されます。

    c:\MyIRIS1\mgr\journal\20180406.001
     35.73%  70.61% 100.00%
    c:\MyIRIS1\mgr\journal\20180406.002
     35.73%  70.61% 100.00%
    c:\MyIRIS1\mgr\journal\20180406.003
     100.00%
    [Journal restore completed at 20180407 02:25:31]
     
    The following databases have been updated:
    
    1. c:\MyIRIS1\mgr\source22\
    2. c:\MyIRIS1\mgr\source23\
    3. c:\MyIRIS1\mgr\irislocaldata\
    4. c:\MyIRIS1\mgr\irislib\
    5. c:\MyIRIS1\mgr\iristemp\
    
    The following databases have been skipped:
    
    1. /bench/yang/InterSystems/IRIS/162/
    2. /scratch1/yang/InterSystems/IRIS/p750.162/mgr/
    3. /scratch1/yang/InterSystems/IRIS/p750.162/mgr/irislocaldata/
    4. /scratch1/yang/InterSystems/IRIS/p750.162/mgr/irislib/
    5. /scratch1/yang/InterSystems/IRIS/p750.162/mgr/iristemp/
    6. /scratch1/yang/InterSystems/IRIS/p750.162/mgr/user/
    
  13. オープン・トランザクションがある場合、リストアの最後に、不完全トランザクションのロールバックを求める以下のようなプロンプトが表示されます。

    Rollback incomplete transactions? No =>
    

    このプロンプトは、リストアされたデータベースに不完全トランザクションがある場合にのみ表示されます。詳細は、"不完全トランザクションのロールバック" を参照してください。

不完全トランザクションのロールバック

ジャーナルのリストアでも、不完全トランザクションがある場合はそのロールバックを求めるプロンプトが表示されます。ユーザがすべてのトランザクションを完了したことを確認し、リストアにより、実行中の処理がロールバックされないようにする必要があります。

バックアップをリストアし、ジャーナル・ファイルを消去する前に、すべてのトランザクションが完了しているようにする方法として、インターシステムズは以下の方法を強く推奨します。

  • 自分自身が使用しているプロセスのトランザクションをロールバックする必要がある場合は、そのプロセスを中断するか、TROLLBACK コマンドを使用します。

  • システム全体でトランザクションをロールバックする必要がある場合、InterSystems IRIS をシャットダウンした後に再起動して、システムに接続しているユーザが存在しないようにします。

ミラー・ジャーナル・ファイルのリストア

ミラーリングされるデータベースまたはミラーリングされないデータベースのどちらにも、ミラー・ジャーナル・ファイルをリストアできます。ミラーリングされるデータベースにリストアする場合は、"^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" の手順 2、および "MirrorCatchup^JRNRESTO を使用したミラーリングされるデータベースへのジャーナルのリストア" の節を参照してください。ミラーリングされないデータベースにリストアする場合は、"^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" の手順 4 を参照してください。

^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理

ジャーナル・ファイルの操作のためにジャーナル・フィルタ・メカニズムが用意されています。ジャーナル・フィルタ・プログラムは、^ZJRNFILT と呼ばれ、ユーザが記述する下記の形式のルーチンです。これは、InterSystems IRIS のジャーナル・リストア・プログラム ^JRNRESTO から呼び出され、選択したレコードのみをリストアします。^ZJRNFILT ルーチンは、次の形式を使用して生成します。

ZJRNFILT(jidsys,dir,glo,type,restmode,addr,time)

引数 タイプ 説明
jidsys 入力

コンマで区切られた 2 つのコンポーネント : jid (ジョブ ID) と remsysid (ECP の場合のみ)。

jidsys%SYS.Journal.Record.GetRealPIDSYSinFilterOpens in a new tab メソッドに渡して (以下の “^ZJRNFILT Examples” セクションに示すように)、ジャーナルを生成した PID (プロセス ID) を特定します。

dir 入力 リストアする IRIS.DAT ファイルが格納されたディレクトリのフル・パス名。ジャーナル・レコードでの指定と同じにする必要があります。
glo 入力 ジャーナル・レコードのグローバル。
type 入力 ジャーナル・レコードのコマンド・タイプ (Set の場合は S、Kill の場合は K)。
addr 入力 ジャーナル・レコードのアドレス。
time 入力 レコードのタイムスタンプ ($horolog 形式)。これは、ジャーナル・バッファの作成時刻であり、Set 処理や Kill 処理が実行された時刻ではありません。つまり、この特定の処理が最も早く実行された時刻を示しています。
restmode 出力

0 - レコードをリストアしません。

1 - レコードをリストアします。

^ZJRNFILT の考慮事項

^ZJRNFILT を使用するときは、以下の点を考慮してください。

  • スタートアップ・ルーチン (^STU) で ^JRNRESTO を呼び出す場合は、どのような状況でもフィルタ・ルーチンを呼び出すことはありません。

  • ジャーナルのリストアでジャーナル・フィルタ (^ZJRNFILT) が呼び出されるのは、それが存在する場合のみです。ジャーナル・フィルタが存在する場合は、リストア処理でそのフィルタを使用するかどうかを指定するようにリストア手順で求められます。

  • リストアするジャーナル・ファイルのすべてのレコードに対してジャーナル・フィルタを使用することを指定すると、ここに示した入力引数を使用してジャーナル・フィルタ ^ZJRNFILT が呼び出されるので、現在のレコードをリストアするかどうかを指定します。

  • ^ZJRNFILT ルーチンでは、あらゆるロジックを使用して、レコードをリストアするかどうかを指定できます。出力引数 restmode を使用して操作の確認が返されます。

  • ^ZJRNFILT ルーチンのロジックでディレクトリ名 dir を使用する場合は、完全ディレクトリ・パス名で指定します。

  • グローバル参照全体が、プログラムのロジックで使用するために ^ZJRNFILT に渡されます。

  • ジャーナルのリストア処理が完了すると、^ZJRNFILT ルーチンの名前を変更するか、そのルーチンを削除するかの確認を求められます。フィルタの名前変更を選択すると、フィルタの名前は ^XJRNFILT に変更され、元の ^ZJRNFILT は削除されます。

  • ^ZJRNFILT ルーチンにエラーが発生すると、リストア処理が中止され、対応するメッセージが表示されます。

^ZJRNFILT の例

2 つのグローバル、^ABC および ^XYZ がジャーナリングの対象となっています。ジャーナリングが有効になっている間、以下のコードが実行され、ジャーナル・ファイルには、この 2 つのグローバルに対する Set 処理および Kill 処理が記録されます。

 For I=1:1:500 Set ^ABC(I)=""
 For I=1:1:500 Set ^XYZ(I)=""
 For I=1:1:100 Kill ^ABC(I)
  1. ^ABC のみのレコードをすべてリストアする場合、^ZJRNFILT ルーチンは以下のようになります。

    ZJRNFILT(jidsys,dir,glo,type,restmode,addr,time)    /*Filter*/
     Set restmode=1                                  /*Return 1 for restore*/
     If glo["XYZ" Set restmode=0                     /*except when it is ^XYZ*/
     Quit
     ; 
  2. ^ABC に対する kill 処理以外のレコードをすべてリストアする場合、^ZJRNFILT ルーチンは以下のようになります。

    ZJRNFILT(jidsys,dir,glo,type,restmode,addr,time)    /*Filter*/
     Set restmode=1                                  /*Return 1 for restore*/
     If glo["^ABC",type="K" Set restmode=0           /*except if a kill on ^ABC*/
     Quit
     ;
    
  3. jid が PID やミラー・メンバに対するものである場合のように、remsysid が実際の ECP システム ID ではないこともあります。そのような場合は、%SYS.Journal.Record.GetRealPIDSYSinFilterOpens in a new tab メソッドを使用して、実際の PID と同時に実際の ECP システム ID も返されるようにします。

    実際の PID (および ECP システム PID) をフィルタで得るには、次のような ^ZJRNFILT ルーチンを使用します。

    ZJRNFILT(jidsys,dir,glo,type,restmode,addr,time) ;
     SET restmode=0 ;test only
     SET pid=##class(%SYS.Journal.Record).GetRealPIDSYSinFilter(jidsys,.ecpsysid)
     DO ##class(%SYS.System).WriteToConsoleLog($SELECT(pid="":"jid="_+jidsys,1:"pid="_pid)_",ecpsysid="_ecpsysid)
     QUIT
  4. 特定の時刻以降のレコードをすべてリストアする場合、^ZJRNFILT ルーチンは以下のようになります。

    ZJRNFILT(jidsys,dir,glo,type,restmode,addr,time) ;
     New zdh 
     Set zdh=$zdatetimeh("08/14/2015 14:18:31") ;in $H format as variable 'time'
     If time>zdh Set restmode=1 Quit
     If time<zdh Set restmode=0 Quit
     If $p(time,",",2)<$p(zdh,",",2) {
      Set restmode=0
     } Else {
        Set restmode=1
     }
     Quit
    

^JRNDUMP を使用したジャーナル・レコードの表示

ジャーナル・ファイルのレコードを表示するには、^JOURNAL メニューのオプション・プロンプトで「5」を入力するか、または以下の例に示すように、^JRNDUMP を実行します。

  1. システム管理者のネームスペースから ^JRNDUMP ユーティリティを実行するには、次のように入力します。

    %SYS>DO ^JRNDUMP
    
       Journal                 Directory & prefix
     
       20181113.001            C:\MyIRIS\Mgr\Journal\
       20181113.002 [JRNSTART] C:\MyIRIS\mgr\journal\
       20181113.003            C:\MyIRIS\mgr\journal\
       20181113.004            C:\MyIRIS\mgr\journal\
       20181114.001            C:\MyIRIS\mgr\journal\
       20181115.001            C:\MyIRIS\mgr\journal\
       20181115.002            C:\MyIRIS\mgr\journal\
       20181115.003            C:\MyIRIS\mgr\journal\
    >  20181115.004            C:\MyIRIS\mgr\journal\
     
    
    
  2. このルーチンは、ジャーナル・ファイルのリストを表示します。現在選択しているファイルの左側に大なり記号 (>) が表示され、その後に以下のプロンプトが表示されます。

    Pg(D)n,Pg(U)p,(N)ext,(P)rev,(G)oto,(E)xamine,(Q)uit =>
    
    

    これらのオプションを使用して、目的のジャーナル・ファイルに移動します。

    • インスタンスがミラー・メンバの場合、M と入力してミラー・ジャーナル・ファイルのみにリストを制限します (ミラー・ジャーナル・ファイルの詳細は、この章の "ジャーナル・ファイルとジャーナル履歴ログ" および "高可用性ガイド" の “ミラーリング” の章の "ミラー同期" を参照してください)。

    • ジャーナル・ファイル・リストの表示ページを変更するには、「D」または「U」を入力します。

    • 必要なジャーナル・ファイルに > を移動するには、「N」または「P」を入力します。

    • 表示するジャーナル・ファイルのフル・パス名を直接入力するには、「G」を入力します。

    • 選択したジャーナル・ファイルの内容を表示するには、「E」を入力します。

    • 選択されたジャーナル・ファイルに関する情報、および必要に応じてジャーナルのデータベースのリストを表示するには、「I」を入力します。

    • ルーチンを終了するには、「Q」を入力するか、Enter キーを押します。

  3. I」の入力時、現在選択されているジャーナル・ファイルを受け入れた場合、または別のジャーナル・ファイルを指定した場合、以下のような情報が表示されます。

    Journal: C:\MyIRIS\mgr\journal\20181113.003
    File GUID: 97734819-CA75-4CB1-9C3E-74D294784D23
    Max Size: 1073741824
    Time Created: 2018-11-13 10:44:52
    File Count: 22
    Min Trans: 22,3497948
    Prev File: C:\MyIRIS\mgr\journal\20181113.002
    Prev File GUID: 8C5D3476-F12C-4258-BF6C-7423876653A4
    Prev File End: 0
    Next File: C:\MyIRIS\mgr\journal\20181113.004
    Next File GUID: 4F4D20B1-D38C-473E-8CF0-4D04C6AF90B0
    
    (D)atabases,(Q)uit =>
    

    [最小トランザクション] は、ファイル数および最小トランザクションの位置のオフセットです (開いているトランザクションは、すべてこの時点以降から開始しています)。

    選択されているファイルがミラー・ジャーナル・ファイルである場合、追加情報が表示されます。

    下部のプロンプトで「Q」を入力すると、ジャーナル・ファイル・リストが返されます。「D」を入力すると、以下のようなデータベース情報が表示されます。

    Journal: C:\MyIRIS\mgr\journal\20181113.003
      sfn  Directory or Mirror DB Name
    ==========================================================================
        0  C:\MyIRIS\mgr\
        1  C:\MyIRIS\mgr\irislib\
        2  C:\MyIRIS\mgr\iristemp\
        3  :mirror:MIR:MIRTEST
        5  C:\MyIRIS\mgr\irislocaldata\
        6  C:\MyIRIS\mgr\user\
     
    (P)rev,(N)ext,(Q)uit =>
    

    Q」を入力すると、ジャーナル・ファイル情報の画面に戻ります。

  4. G」または「E」を入力すると、ユーティリティにはそのジャーナル・ファイル名が表示され、オフセット・アドレス別にファイルの内容のリスト生成が開始されます。以下に例を示します。

    Journal: C:\MyIRIS\mgr\journal\20180330.002
       Address   Proc ID Op Directory        Global & Value
    ===============================================================================
        131088      2980 S  C:\MyIRIS\mgr\  SYS("shdwcli","doctest","remend") = 1+
        131156      2980 S  C:\MyIRIS\mgr\  SYS("shdwcli","doctest","end") = 1013+
        131220      2980 S  C:\MyIRIS\mgr\  SYS("shdwcli","doctest","jrnend") = 1+
    ...
    
    
  5. 現在のリスト表示ページの下部には、そのジャーナル・ファイルに関する情報と以下のプロンプトが表示されます。

    Last record:     573004;   Max size: 1073741824
    (N)ext,(P)rev,(G)oto,(F)ind,(E)xamine,(Q)uit =>
    
    

    これらのオプションを使用して、表示するジャーナル・レコードに移動します。

    • アドレスの次のページまたは前のページを表示するには、「N」または「P」を入力します。

    • 特定のアドレスに表示を移動するには、「G」を入力します。

    • ジャーナル・ファイル内の特定の文字列を検索するには、「F」を入力します。

    • ジャーナル・レコードのアドレスを入力してその内容を表示するには、「E」を入力します。

    • ジャーナル・ファイルのリストに戻るには、「Q」を入力します。

  6. E」または「G」を入力した後、プロンプトでアドレスを入力します。E オプションでは、入力したアドレスのジャーナル・レコードの内容、またはそのアドレス周辺のジャーナル・レコードの内容が表示されます。G オプションでは、そのアドレスを先頭とするジャーナル・レコードのページが表示されます。

    いずれのオプションでも、指定したオフセット・アドレスに最も近いレコードが探し出されます。ジャーナル・レコードの有効なアドレスを指定する必要はありません。また、ジャーナル・ファイルの先頭に移動するには、「0」(ゼロ) を入力します。ジャーナル・ファイルの末尾に移動するには、「-1」を入力します。

  7. N」を入力すると、次のページにあるジャーナル・レコードの内容が表示され、「P」を入力すると、前のページにあるジャーナル・レコードの内容が表示されます。レコードの表示を終了するには、プロンプトで「Q」を入力し、ジャーナル・レコードのリストに戻ります。

ジャーナル・レコードには、さまざまな種類があります。

  • ジャーナル・ヘッダの長さは 8192 バイトですヘッダは、各ジャーナル・ファイルの先頭に一度出現します。^JRNDUMP ユーティリティは、ジャーナル・ヘッダ・レコードを表示しません。

  • ジャーナル・データ・レコード。

  • ジャーナル・マーカ

以下は、^JRNDUMP で表示されるジャーナル・ファイル・データ・レコードのサンプルです。例では、Set コマンドの記録方法を示しています。Set がトランザクションの範囲外に発生したため、新しい値は記録されますが、古い値は記録されません。

Journal: C:\MyIRIS\mgr\journal\20180119.004
 
Address:                 233028
Type:                    Set
In transaction:          No
Process ID:              4836
ECP system ID:           0
Time stamp:              60284,53240
Collation sequence:      5
Prev address:            232984
Next address:            0
 
Global:    ^["^^C:\MyIRIS\mgr\"]ABC
New Value: 2
 
 
(N)ext,(P)rev,(Q)uit =>

トランザクションで古い値も記録し、以下の 2 番目の例に示すように、トランザクション・ロールバックを許可します。

Journal: C:\MyIRIS\mgr\journal\20181115.004
 
Address:                 204292
Type:                    Set
In transaction:          Yes
Process ID:              458772
ECP system ID:           0
Time stamp:              60584,52579 - 11/15/2018 14:36:19
Collation sequence:      5
Prev address:            204224
Next address:            204372 

Global:    ^["^^C:\MyIRIS\mgr\"]ABC
New Value: 5
Old Value: 2
 
 
(N)ext,(P)rev,(Q)uit =>

以下は、インクリメンタル・バックアップにより作成されたジャーナル・マーカ・レコードの例です。

Journal: C:\MyIRIS\mgr\journal\20181115.004
 
Address:                 210848
Type:                    JrnMark
Marker ID:               -1
Marker text:             NOV 15 2018;03:14PM;Incremental
Marker seq number:       1
Prev marker address:     0
Time stamp:              60584,52579 - 11/15/2018 14:36:19
Prev address:            210744
Next address:            210940
 
 
 
(N)ext,(P)rev,(Q)uit =>

以下のテーブルは、ジャーナル・データ・レコードのそれぞれのフィールドです。

^JRNDUMP で表示されるジャーナル・データ・レコード・フィールド
フィールド 説明
Address ファイルの最初から数えたバイト数によるレコード位置。レコードを選択するために値を入力する唯一のフィールドです。
Type ジャーナル・レコード・エントリに記録される処理のタイプ。利用可能なタイプの詳細は、"ジャーナル・ファイルの処理" のテーブルを参照してください。
In transaction 更新がトランザクション中に発生するかどうかを示します。
Process ID コマンドを発行するプロセスのプロセス ID 番号。
ECP system ID ECP システムの ID 番号 (ローカル・プロセスの場合は 0)。
Time stamp 人間が読める $HOROLOG 形式での、ジャーナル・バッファの作成時刻。これは、Set 処理や Kill 処理が実行された時刻ではありません。つまり、この特定の処理が最も早く実行された時刻を示しています。
Collation sequence 更新されるグローバルの照合順序。
Prev address 以前のレコードの位置 (0 は、現在のレコードが最初のレコードであることを示します)。
Next address 次のレコードの位置 (0 は、現在のレコードが最後のレコードであることを示します)。
Cluster sequence # クラスタ・マウント・データベースのグローバルの順序。クラスタ・フェイルオーバー中、別のノードからのジャーナル・エントリは、このクラスタ順どおりに更新されます。
Mirror Database Name ミラー・ジャーナル・ファイルの場合、操作が行われたデータベースのミラー名。
Global 更新されるグローバルの拡張参照。
New Value Set 処理についてグローバルに割り当てられた値。
Old Value トランザクションの Set 処理または Kill 処理について、その処理が実行される前にグローバルに存在した値。

以下のテーブルでは、^JRNDUMP ジャーナル・ファイルの表示の [Op] 列および ^JRNDUMP ジャーナル・レコード・リストの [タイプ] フィールドに表示されるジャーナル処理のリストを示し、説明します。例えば、ジャーナル・ファイルの表示の前述の例では、[Op] 列の [S]JRNSET 処理を表すのに対し、ジャーナル・レコードの表示の例では、[Type] フィールドに表示される [Set]JRNSET 処理を表します。管理ポータルのジャーナル・レコード表示の [タイプ] 列 ("ジャーナル・ファイルの表示" を参照) は、いくつかの処理の点で ^JRNDUMP リストの [タイプ] フィールドと異なります。例えば、JRNSET 処理は、ポータルでは RemoteSET で示され、^JRNDUMP 出力では NSet で示されます。これらの違いをテーブルに示します。

このテーブルでは、SELECT^JRNDUMP 関数の使用時に、処理に基づいてジャーナル・レコードをフィルタ処理するために指定できるコードも示します。

ジャーナル・ファイルの処理
処理 説明 ファイル・リスト内の [Op] ^JRNDUMP レコード・リスト内の [タイプ] 管理ポータルのレコード・リスト内の [タイプ] 数値の SELECT コード アルファベットの SELECT コード
JRNSET ノードを設定、ローカル S1 Set

SET

6 s

JRNNSET

ノードを設定、リモート

S1 NSet

RemoteSET

10 s

JRNMIRSET

内部ミラー処理2

S1

Mirror Set

MirrorSET

19

s

JRNBITSET

ノード内の指定されたビット位置を設定

b1

BitSet

BitSET

14

bs

JRNKILL

ノードを削除、ローカル

K1

KillNode

KILL

7

k

JRNNKILL

ノードを削除、リモート

K1

NKill

RemoteKILL

11

k

JRNKILLDES

下位ノードを削除

k1

KillDesc

KILLdes

8

k

JRNMIRKILL

内部ミラー処理2

k1

Mirror Kill

MirrorKILL

20

k

JRNZKILL

従属ノードを削除せずにノードを削除、ローカル

k1

ZKill

ZKILL

9

zk

JRNNZKILL

従属ノードを削除せずにノードを削除、リモート

k1

NZKill

RemoteZKILL

12

zk

JRNBEGTRANS

トランザクションを開始

BT

BeginTrans

BeginTrans

4

--

JRNTBEGINLEVEL

トランザクション・レベルを開始

BTL

BeginTrans with Level

BeginTrans with level

16

--

JRNCOMMIT

トランザクションをコミット

CT

CommitTrans

CommitTrans

5

--

JRNTCOMMITLEVEL

分離されたトランザクション・レベルをコミット

CTL

CommitTrans with Level

CommitTrans with level

18

--

JRNTCOMMITPENDLEVEL

保留中のトランザクション・レベルをコミット

PTL

CommitTrans Pending with Level

CommitTrans Pending with level

17

--

JRNMARK

ジャーナル・マーカ

M

JrnMark

Marker

13

--

JRNBIGNET

ECP ネットワーキング

NN

NetReq

netsyn

15

--

JRNTROLEVEL

トランザクションをロールバック

RB

Rollback

Rollback

21

--

1T」は、トランザクション内で処理が実行されるときに付加されます。例えば、「ST」はトランザクション内の Set 処理を表し、「kT」はトランザクション内の ZKill 処理を表します。

2 ジャーナル・リストア中は処理が無視されます。

ダンプするジャーナル・レコードの選択

SELECT^JRNDUMP 関数は、ジャーナル・ファイルの任意のレコードまたはすべてのレコードを表示します。この関数に渡した引数に基づき、ジャーナル・ファイルの選択したレコードがファイルの先頭から順にダンプされます。

^JRNDUMP ユーティリティの SELECT エントリ・ポイントを使用する構文は、以下のようになります。

SELECT^JRNDUMP(%jfile,%pid,%dir,%glo,%gloall,%operation,%remsysid)
引数 説明
%jfile ジャーナル・ファイル名。既定では現在のジャーナル・ファイルです。完全修飾パスでジャーナル・ファイルを指定する必要があります。
%pid

ジャーナル・レコードのプロセス ID。既定では任意のプロセスです。

%dir ジャーナル・レコードのディレクトリ。既定では任意のディレクトリです。
%glo ジャーナル・レコードのグローバル参照。既定では任意のグローバルです。
%gloall glo で指定した名前を含むすべてのグローバル・ノードに関連するエントリを列挙するかどうかを指定するグローバル・インジケータ。0 — glo で指定した名前に完全一致するグローバル参照。1 — 部分一致。glo で指定した名前を使用しているグローバル参照を持つすべてのレコード。既定値は 0 です。
%operation ジャーナル・レコードの処理タイプ。既定では任意の処理です。前述の "ジャーナル・ファイルの処理" のテーブルにリストされている数値コードまたはアルファベット・コードを使用します。
%remsysid ジャーナル・レコードの ECP システム ID。既定では任意のシステムです。1

1 %pid が指定されている場合、既定では %remsysid はローカル・システム (0) に設定されます。それ以外の場合は、0 に指定されている場合と同様に、既定では任意のシステムに設定されます。つまり、ローカル・システムのみからジャーナル・エントリを選択することはできません

引数として NULL 文字列を渡すことができます。この場合、ルーチンはそれぞれの既定値を使用します。

ターミナルのその他の関数と同様に、Device: プロンプトを使用して、SELECT^JRNDUMP の出力先をターミナル以外のデバイス、またはファイルに指定できます (ユーザによるデバイスの選択に関する詳細は、"入出力デバイス・ガイド" の “入出力デバイスとコマンド” の章を参照してください)。出力先をファイルに指定した場合、パラメータの入力を求められます。ファイルに書き込む場合は、RW を含める必要があります。既存のファイルの場合は、A を含めることで、既存の内容に出力が上書きされるのではなく、追加されます。新しいファイルの場合は、N を指定する必要があります。Parameters? プロンプトで「?」を入力すると、すべての利用可能な選択肢を表示できます。

Note:

上書き先のファイルが現在の出力よりも長い場合、元のファイルの余分な行が更新されたファイルから削除されない場合があります。

SELECT^JRNDUMP の例

以下の例では、特定のジャーナル・レコードを選択するためのさまざまな方法を示します。

プロセス ID が 1203 のジャーナル・ファイル内のすべてのレコードを選択して、JRNDUMP.OUT という名前の新しいファイルに出力を送信する場合は、以下のようになります。

%SYS>Do SELECT^JRNDUMP("C:\MyIRIS\mgr\journal\120020507.009","1203")

Device: SYS$LOGIN:JRNDUMP.OUT   
Parameters: "RWN"=>

グローバル参照 ^ABC を含むジャーナル・ファイルのすべてのレコードを選択する場合は、以下のようになります。

DO SELECT^JRNDUMP("C:\MyIRIS\mgr\journal\20050327.001","","","^ABC",1)

グローバル参照 ^ABC に完全に一致するレコードのみを選択する場合は、以下のようになります。

DO SELECT^JRNDUMP("C:\MyIRIS\mgr\journal\20050327.001","","","^ABC",0)

Note:

^ABC(1) または ^ABC(100) など、完全には一致しないレコードは選択されません。

グローバル ^ABC に対するローカルの Set 処理のレコードのみを選択する場合は、以下のようになります。

DO SELECT^JRNDUMP("C:\MyIRIS\mgr\journal\20050327.001","","","^ABC","","6")

グローバル ^ABC に対するローカルおよびリモートの Set 処理のレコードのみを選択する場合は、以下のようになります。

DO SELECT^JRNDUMP("C:\MyIRIS\mgr\journal\20050327.001","","","^ABC","","s")

PURGE^JOURNAL を使用したジャーナル・ファイルの削除

ファイルを削除するには、以下の例に示すように、PURGE^JOURNAL ルーチンを使用するか、または^JOURNAL メニューの Option プロンプトで「6」を入力します。

PURGE^JOURNAL を直接実行する例

set $namespace="%SYS"
%SYS>Do PURGE^JOURNAL

^JOURNAL メニューからジャーナリングを開始する例

%SYS>Do ^JOURNAL
 
 ...
 6) Purge Journal Files (PURGE^JOURNAL)
 ...
Option? 6

1) Purge any journal NOT required for transaction rollback or crash recovery
2) Purge journals based on existing criteria (2 days or 2 backups)
 
Option?

このルーチンは、指定したオプションに対応して実行されるアクションについて報告します。以下はその例です。

Option? 1

The following files have been purged (listed from latest to oldest):

3. c:\intersystems\iris\mgr\journal\20180714.001
2. c:\intersystems\iris\mgr\journal\20180713.001
1. c:\intersystems\iris\mgr\journal\20180710.003

削除するファイルがない場合、以下のメッセージが表示されます。


None purged

^JRNOPTS を使用したジャーナル設定の更新

管理ポータルの [ジャーナル設定] ページを使用する代わりに、^JRNOPTS ルーチンを使用するか、^JOURNAL のメニューの Option プロンプトで「7」を入力して基本的なジャーナル構成設定を更新できます。設定を変更するには、プロンプトで新しい値を入力して、Enter キーを押します。以下に例を示します。

SYS>Do ^JRNOPTS
 
1) Primary Journal Directory: C:\MyIRIS\Mgr\Journal\
2) Alternate Journal Directory: D:\irissys\altjournal\ 
3) Journal File Size Limit (MB) 1024
4) Journal File Prefix: 
5) Journal Purge Options: 2 days OR 2 backups, whichever comes first
6) Compress Journal files: Yes

疑問符 (?) を入力すると、ヘルプが表示されます。以下はその例です。

Journal File Prefix: ?
  Enter an alphanumeric string ('_' allowed) or . to reset prefix to null

設定を変更し、Change Property? プロンプトで Enter キーを押すと、変更内容が有効になります。

Change Property?
Save and activate changes? Yes =>
*** Journal options updated.

設定を変更しない場合、以下のメッセージが表示されます。

  
*** Nothing changed

ENCRYPT^JOURNAL を使用したジャーナルの暗号化

オプション 8) ジャーナルの暗号化の有効化と無効化 (ENCRYPT^JOURNAL) の詳細は、ジャーナル・ファイルの暗号化について詳しく説明している "暗号化の起動設定の構成" を参照してください。

Note:

ジャーナルの暗号化とジャーナルの圧縮 ("ジャーナル設定の構成" を参照) の両方が有効な場合、ジャーナル・データは常に、圧縮されてから暗号化されます。暗号化されたデータは圧縮されることはありません。

Status^JOURNAL によるジャーナルの状態の表示

オプション 9) ジャーナルの状態の表示を選択すると、ジャーナルの状態に関する次の簡単な説明が表示されます。

  • 現在のジャーナルのディレクトリとその空き領域

  • 代替ジャーナルのディレクトリ (現在のジャーナルと異なる場合) とその空き領域

  • 現在のジャーナル・ファイル、その最大サイズ、および使用している領域

  • ジャーナルの状態。以下のいずれかの状態となります。

    • 有効

    • 無効 (停止)

    • I/O エラーのために無効 (中断)

    • I/O エラーのためにフリーズ

    • ジャーナルの切り替え中 (一時停止)

    I/O エラーのために中断した状態とフリーズした状態はジャーナル状態としては同じですが、実行されるアクションは異なり、フリーズした場合はジャーナル・データが破棄されます。

  • 該当する場合、^JRNSTART^JRNSTOP、または ^JRNSWTCH を実行しているすべてのプロセスのプロセス ID

例 :

%SYS>Do ^JOURNAL
 
 ...
 9) Display Journal status (Status^JOURNAL)
 ...
Option? 9
 
Current journal directory:  C:\MyIRIS\Mgr\Journal\
Current journal directory free space (KB):  53503904
Alternate journal directory:  C:\MyIRIS\Mgr\
Alternate journal directory free space (KB): 53503904
Current journal file:  C:\MyIRIS\mgr\journal\20181129.001
Current journal file maximum size:    1073741824
Current journal file space used:         1979276
Journaling is enabled.

Manage^JRNROLL を使用したトランザクション・ロールバックの管理

InterSystems IRIS には、ジャーナルのレコードに対して部分的に完了したトランザクションをロールバックするための ^JRNROLL ユーティリティが用意されています。システムの起動時またはプライマリ・ミラー・メンバの起動時に保留中または処理中のトランザクション・ロールバックがある場合、Manage エントリ・ポイント (Manage^JRNROLL) を使用します。

トランザクション・ロールバックの管理を開始するには、以下の例に示すように、Manage^JRNROLL を実行するか、または ^JOURNAL メニューのオプション・プロンプトで「11」を入力します。

%SYS>Do ^JOURNAL
 
 ...
 11) Manage pending or in progress transaction rollback (Manage^JRNROLL)
 ...
Option? 11

オプション 11) 保留中または処理中のトランザクション・ロールバックの管理 (Manage^JRNROLL) を選択すると、以下のようなメッセージが表示されます。

Transaction rollback is pending or in progress 
Do you wish to run Manage^JRNROLL? Yes => Yes 
Rollback operations currently in progress 
     ID   Phase     MB Remaining   Current Open Transaction Count 
     1    scan      307            2 
          Rollback at system startup at 11/29/2018 15:54:35 (578MB) 
          20181129.004 has 2 open transaction(s) starting at offset 11303 
          2 file(s) remaining to process   

1) Restart pending rollback 
2) Interrupt transaction rollback 
3) Redisplay rollback information  
4) Discard pending rollback

Option?  

このオプションによって、トランザクション・ロールバックの現在のフェーズ (スキャンまたはロールバック)、処理される残りのデータの量 (MB)、検出された開いているトランザクションの数などの状態が表示されます。

さらに、リストされたトランザクション・ロールバックを管理するためのサブオプションがリストされます。例えば、処理を中断することができます。この場合、その処理は “保留中” の処理としてキューに登録されるため、保留中のロールバックを再開することが可能です。

Caution:

オプション 4) Discard pending rollback は元に戻せません。保留中のロールバックを永久に破棄しても問題がないことが確実である場合以外は、このオプションを使用しないでください。

Note:

ミラーでは、トランザクション・ロールバックが 2 回実行されます。ミラーリングされないデータベースに対して 1 回 (システムの起動時) と、ミラーリングされるデータベースに対して 1 回 (システムがプライマリ・ミラー・メンバになったとき) です。その結果、プライマリ・ミラー・メンバの開始時に、ロールバックを 2 回中断することが必要になる場合があり、そうすると 2 つの処理が保留中になります。保留中の処理を再開すると、ミラー以外のロールバックとミラー・ロールバックが別々に実行されます。

ロールバックの間、一連の処理の (およそ) 10% ごとにメッセージがメッセージ・ログ (messages.log) に書き込まれ、処理のためにどのくらいの容量が残されているかと、開いているトランザクションがいくつリストされているかが示されます。

ジャーナル・ファイルが削除される場合、保留中のトランザクション・ロールバックに必要なファイルは保持されます (例えば、そうしなければそれらのファイルが削除されていた場合)。

MirrorCatchup^JRNRESTO を使用したミラーリングされるデータベースへのジャーナルのリストア

ミラー・ジャーナル・ファイルをミラーリングされるデータベースにリストアするには、^JOURNAL メニューの Option プロンプトで「12」を入力するか、またはオプション 4 の Restore Globals From Journal (^JRNRESTO) を使用したときに Catch-up mirrored databases? プロンプトで「yes」と入力します。以下はその例です。

%SYS>Do ^JOURNAL

 ...
 12) Journal catch-up for mirrored databases (MirrorCatchup^JRNRESTO) 
 ...
Option? Option? 12

Specify the list of mirrored databases you want to catch-up.
Enter database, * for all, ? for a list or to end list? *
Enter database or to end list?
Starting catch-up for the following mirrored database(s):
     sfn #6: c:\intersystems\iris\mgr\mirrordb3\
Catch-up succeeded. 

ミラーリングされるデータベースをキャッチアップするには、ジャーナリングを実行している必要はありませんが、現在のジャーナル・ディレクトリがメモリから確実に利用できるように、少なくとも 1 回はジャーナリングを起動しておく必要があります。

^STURECOV を使用した起動エラーの回復

InterSystems IRIS のスタートアップ・プロシージャでは、ジャーナルまたはトランザクションのリストア処理の際に <FILEFULL><DATABASE> などのエラーが発生した場合、そのエラーをメッセージ・ログ (messages.log) に記録して、システムをシングル・ユーザ・モードで起動します。

エラーを修復して InterSystems IRIS をマルチユーザ・モードで起動できるように、InterSystems IRIS にはユーティリティ ^STURECOV が用意されています。このルーチンには、いくつかのオプションがあります。これらのオプションを使用し、失敗した処理を再試行してシステムを起動する操作や、エラーを無視してシステムを起動する操作が可能です。ジャーナルのリストア段階では、起動が停止する前にできる限り多くの作業を実行しようとします。データベースから 4 件以上のエラーがトリガされると、そのデータベースのリカバリは中止され、マウントされないままとなります。

Note:

^STURECOV ユーティリティは、保留中または処理中のトランザクション・ロールバックがあるミラー・メンバでは機能しません。これは、トランザクション・ロールバックが完了するまで、ミラーリングされるデータベースの読み取り/書き込みがシステムによって有効化されないためです。この場合、InterSystems IRIS では、Manage^JRNROLL ルーチンを実行できます。このルーチンによって、システムを強制的に起動して、トランザクション・ロールバック情報を格納することができ、システムの起動後にその情報を使用してトランザクションをロールバックすることが可能です。詳細は、このセクションの "Manage^JRNROLL を使用したトランザクション・ロールバックの管理" を参照してください。

トランザクションのロールバックでデータベースに最初に発生したエラーによって、今後のロールバック・プロセスではそのデータベースは処理されなくなります。このプロセスでは、そのデータベースを参照するトランザクションが完全な形では再生されません。リカバリ・プロセスの間、トランザクションはロールバックに備えて保存されます。

InterSystems IRIS の起動のデジャーナリング・フェーズで問題が発生した場合、以下のような一連のメッセージ・ログ・メッセージが生成されます。

08/10-11:19:47:024 ( 2240) System Initialized. 
08/10-11:19:47:054 ( 2256) Write daemon started. 
08/10-11:19:48:316 ( 1836) Performing Journal Recovery 
08/10-11:19:49:417 ( 1836) Error in JRNRESTB: <DATABASE>restore+49^JRNRESTB 
     C:\MyIRIS\mgr\journal\20180810.004 addr=977220 
     ^["^^C:\MyIRIS\mgr\jo1666\"]test(4,3,28) 
08/10-11:19:49:427 ( 1836) Error in JRNRESTB: <DATABASE>restore+49^JRNRESTB 
     C:\MyIRIS\mgr\journal\20180810.004 addr=977268 
     ^["^^C:\MyIRIS\mgr\test\"]test(4,3,27) 
08/10-11:19:49:437 ( 1836) Error in JRNRESTB: <DATABASE>restore+49^JRNRESTB 
     C:\MyIRIS\mgr\journal\20180810.004 addr=977316 
     ^["^^C:\MyIRIS\mgr\test\"]test(4,3,26) 
08/10-11:19:49:447 ( 1836) Error in JRNRESTB: <DATABASE>restore+42^JRNRESTB 
     C:\MyIRIS\mgr\journal\20180810.004 addr=977748 
     ^["^^C:\MyIRIS\mgr\test\"]test(4,2,70) 
08/10-11:19:50:459 ( 1836) Too many errors restoring to C:\MyIRIS\mgr\test\. 
 Dismounting and skipping subsequent records 
08/10-11:19:50:539 ( 1836) 4 errors during journal restore, 
see console.log file for details. 
Startup aborted, entering single user mode. 
 

このエラーがトランザクションのロールバックで発生している場合、出力は以下のようになります。

08/11-08:55:08:732 ( 428) System Initialized. 
08/11-08:55:08:752 ( 1512) Write daemon started. 
08/11-08:55:10:444 ( 2224) Performing Journal Recovery 
08/11-08:55:11:165 ( 2224) Performing Transaction Rollback 
08/11-08:55:11:736 ( 2224) Max Journal Size: 1073741824 
08/11-08:55:11:746 ( 2224) START: C:\MyIRIS\mgr\journal\20180811.011 
08/11-08:55:12:487 ( 2224) Journaling selected globals to 
     C:\MyIRIS\mgr\journal\20180811.011 started. 
08/11-08:55:12:487 ( 2224) Rolling back transactions ... 
08/11-08:55:12:798 ( 2224) Error in %ROLLBACK: <DATABASE>set+2^%ROLLBACK 
     C:\MyIRIS\mgr\journal\20180811.010 addr=984744 
     ^["^^C:\MyIRIS\mgr\test\"]test(4,1,80) 
08/11-08:55:12:798 ( 2224) Rollback of transaction for process id #2148 
 aborted at offset 984744 in C:\MyIRIS\mgr\journal\20180811.010. 
08/11-08:55:13:809 ( 2224) C:\MyIRIS\mgr\test\ dismounted - 
      Subsequent records will not be restored 
08/11-08:55:13:809 ( 2224) Rollback of transaction for process id #924 
 aborted at offset 983464 in C:\MyIRIS\mgr\journal\20180811.010. 
08/11-08:55:14:089 ( 2224) STOP: C:\MyIRIS\mgr\journal\20180811.011 
08/11-08:55:14:180 ( 2224) 1 errors during journal rollback, 
see console.log file for details. 
Startup aborted, entering single user mode. 
 

どちらの出力表示も、次のような指示で終了します。

Enter IRIS with 
     C:\MyIRIS\bin\irisdb -sC:\MyIRIS\mgr -B 
and D ^STURECOV for help recovering from the errors. 

InterSystems IRIS が正常に起動できない場合、シングル・ユーザ・モードで起動します。このモードでは、これらの指示に示されているコマンドを実行して InterSystems IRIS を開始します ("システム管理ガイド" の “ライセンス” の章の "管理者ターミナル・セッション" を参照)。

これで管理者のネームスペースに入ることができたので、スタートアップ・リカバリ・ルーチン ^STURECOV を実行できます。

Do ^STURECOV

以下のように、^STURECOV のジャーナル・リカバリ・メニューが表示されます。


Journal recovery options 
-------------------------------------------------------------- 
1) Display the list of errors from startup 
2) Run the journal restore again 
3) Bring down the system prior to a normal startup 
4) Dismount a database 
5) Mount a database 
6) Database Repair Utility 
7) Check Database Integrity 
8) Reset system so journal is not restored at startup 
9) Display instructions on how to shut down the system 
10) Display Journaling Menu (^JOURNAL)
-------------------------------------------------------------- 
H) Display Help
E) Exit this utility
--------------------------------------------------------------
 
Enter choice (1-10) or [Q]uit/[H]elp?

このメニューのオプション 9 は、UNIX®/Linux システムにのみ表示されます。

ジャーナル・リストアやトランザクション・ロールバックで発生する障害の原因となっているエラーを修正した後、マルチユーザ・モードでシステムを起動します。実行できる処理として、以下のものがあります。

  • オプション 1 — ジャーナル・リストアとトランザクション・ロールバックのプロシージャで、エラーのリストを ^%SYS() グローバルに保存します。このオプションは必ず利用できるとは限りません。システムの不具合内容によっては利用できないこともあります。このエラー情報を入手できる場合は、そのエラーが表示されます。

  • オプション 2 — システム起動時に実行したものと同じジャーナル・リストアおよびトランザクション・ロールバックを実行します。データの量が少ないため、エラーが発生した時点から試して再起動する必要はありません。

  • オプション 3 — システムが使用できる状態になったらこのオプションを使用して、インスタンスをシャットダウンしてから、通常どおり再起動します。

  • オプション 4 — このオプションを使用するとデータベースをディスマウントできます。一般的には、ユーザがシステムを使用できるようにはするが、障害が残っているデータベースへのアクセスは禁止する場合に、このオプションを使用します (^DISMOUNT ユーティリティ)。

  • オプション 5 — このオプションを使用するとデータベースをマウントできます (^MOUNT ユーティリティ)。

  • オプション 6 — このオプションを使用するとデータベース構造を編集できます (^REPAIR ユーティリティ)。

  • オプション 7 — このオプションを使用するとデータベース構造を検証できます (^INTEGRIT ユーティリティ)。

  • オプション 8 — 起動時にジャーナル・リストアやトランザクション・ロールバックを試行しないようにシステムを更新します。次回の起動プロセス実行のときにのみ適用されます。ジャーナル・リカバリは完了できないが、ユーザにはシステムを使用できるようにする必要がある場合に、このオプションを使用します。回復されなかったデータベースをディスマウントすることを検討してください。この処理は元に戻せません。^JRNRESTO ユーティリティを使用すると、ジャーナル・リストアを手動で実行できます。

  • オプション 9 — このユーティリティからはシステムをシャットダウンできませんが、このオプションでは、UNIX® のコマンド行からシステムをシャットダウンする方法が表示されます。

  • オプション 10 — ジャーナリング・メニューを表示し、ジャーナル・ファイルの閲覧とリストアができるようにします。ジャーナリングを開始および停止するオプションはありますが、これらは通常、起動時のジャーナリングに関する問題の解決には関係ありません。

問題を解決するうえで必要な修正アクションであれば、どのようなものでも実行する必要があります。このアクションとしては、例えば ^DATABASE ルーチンを使用してデータベースの最大サイズを拡張する処理があります。また、ファイル・システムで領域を解放する処理や、^INTEGRIT ユーティリティおよび ^REPAIR ユーティリティを使用してデータベースの破損を検出、修復する処理が必要になることもあります。これらの作業と並んで、^STURECOV ユーティリティのオプション 2 を使用し、必要に応じてジャーナル再生やトランザクション・ロールバックをやり直すことができます。オプション 1 を使用して、システムの起動時からのエラーも含め、発生したすべてのエラーを表示できます。すべての不具合を修正し、オプション 2 を実行してエラーが発生しなければ、オプション 3 を使用してシステムをマルチユーザ・モードで起動します。

不具合は解決できていないが、システムを起動することが必要な場合は、オプション 8 を使用し、起動時にジャーナル・リストアとトランザクション・ロールバックをトリガする InterSystems IRIS イメージ・ジャーナル (.wij ファイル) 内の情報をクリアします。また、このオプションでは、現時点のこの情報がメッセージ・ログに記録されます。以上の作業が完了した後、オプション 3 を使用してシステムを起動します。この方法では結果を元に戻せないので、実行には注意が必要です。

InterSystems IRIS の起動時に、^STURECOV で表示するためのエラー情報を ^%SYS() グローバルに保存できない場合、メニューが表示される前に以下のようなメッセージが表示される場合があります。


There is no record of any errors during the prior startup 
This could be because there was a problem writing the data 
Do you want to continue ? No => yes 
Enter error type (? for list) [^] => ? 

Supported error types are: 
     JRN - Journal and transaction rollback 

Enter error type (? for list) [^] => JRN 
 

ジャーナリング・エラーは、この章で扱う、このユーティリティが対応しているエラーの 1 種類です。他のエラーの種類については、ドキュメントの該当するセクションで説明します。

Caution:

起動時にエラーが発生して、システムがシングル・ユーザ・モードで動作している場合にのみ、^STURECOV ユーティリティを使用します。システムがシングル・ユーザ・モード以外の状態にあるとき (正常に動作しているときなど) にこのユーティリティを使用すると、データに重大な破損が発生することがあります。それは、このユーティリティでは必要に応じてジャーナル情報がリストアされますが、そのリストアされた情報が最新のものではないことがあるからです。^STURECOV ユーティリティでは警告が表示されますが、そのまま実行に移ることができます。

^JCONVERT および ^%JREAD を使用したジャーナル・ファイルの変換

^JCONVERT ルーチンは、ジャーナル・ファイルを読み取り、それを可変レコード形式で共通ファイルに変換するユーティリティです。^%JREAD ユーティリティは、このファイルを読み取り、ジャーナル・トランザクションを別のシステム上のデータベースに適用できます。^JCONVERT ユーティリティは、InterSystems IRIS のすべてのバージョンのほか、インターシステムズの以前のデータベース製品にも用意されています。これらのユーティリティを使用して、互換性のあるジャーナル・ファイルを持たない、異なるシステムのバージョン間でジャーナル・データを移動します。

例えば、新しいバージョンの InterSystems IRIS に変換する際に停止時間を最小限とするには、以下の手順を実行します。

  1. 旧システムのジャーナリングを有効にします。

  2. 旧システムでバックアップを実行します。これによって、旧システムのジャーナル・ファイルが新しいファイルに切り替わります。

  3. 旧システムのジャーナリングを継続します。

  4. 旧システムのバックアップを新システム上にリストアし、必要な変換処理を実行します。

  5. 旧システムを停止し、バックアップ以降に旧システム上に作成されたジャーナル・ファイルに対して ^JCONVERT を実行します。

  6. ^JCONVERT の実行で作成されたファイルを新システム上で ^%JREAD への入力として使用し、旧システムのトランザクションを新システムに適用します。

^JCONVERT ユーティリティでは、ジャーナル・リストア・ユーティリティと同じプロセスを使用して、処理対象のジャーナル・ファイルを選択し、フィルタ処理します。複数のジャーナル・ファイルを入力として指定し、1 つの出力ファイルを作成できます。ジャーナル・ファイルの選択とフィルタ処理の詳細は、"^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" を参照してください。

変換されたファイルは可変レコード形式です。既定の文字エンコードは UTF8 で、これはすべてのプラットフォームでの現行の ^%JREAD ユーティリティと互換性があります。また、バイナリ FTP を使用して、複数のプラットフォーム間で移動できます。[UTF8 文字変換を使用しますか?] プロンプトに [いいえ] と答える場合、文字エンコードは適用されません。

ジャーナル・ファイルのグローバルは、そのグローバル参照に特定のディレクトリ参照が付加された状態で格納されています。変換先のファイルにこのディレクトリ参照を追加するかどうかを選択できます。ディレクトリ参照を追加しておくと、後で ^%JREAD プロシージャを実行して、いつでもディレクトリ参照をフィルタで除外したり、変更したりできます。

ディレクトリ参照は、ターゲット・システム上で ^%JREAD がグローバルを設定する場所を指定します。ディレクトリ参照を追加していない場合、^%JREAD では現在のディレクトリにすべてのセットが作成されます。ディレクトリ参照を追加していない場合は、ユーザ指定の ^%ZREAD プログラムでディレクトリが変換されない限り、このユーティリティではソース・システムと同じディレクトリにセットが作成されます。ターゲット・システムが別のオペレーティング・システム上にある場合、またはデータベースがターゲット・システム上の別のディレクトリに存在する場合は、ディレクトリ参照を変換する ^%ZJREAD ルーチンを指定する必要があります

^%JREAD ルーチンは、共通ジャーナル・ファイル形式を読み取り、ターゲット・システム上のデータベースにジャーナル・トランザクションを適用します。レコードをインポートするとき、^%ZJREAD ルーチンが存在すれば、ジャーナル・トランザクションごとにこのユーティリティから呼び出されます。これにより、そのジャーナル・レコードを操作できます。^%ZJREAD では、以下の変数を参照できます。

      type    - Transaction type
      gref    - Global reference
      value   - Global value
      %ZJREAD - 1:Apply transaction, 0:Do not apply transaction

トランザクションを適用しない場合は、変数 %ZJREAD を 0 (ゼロ) に設定してそのレコードをスキップします。他の変数を変更することもできます。例えば、gref を修正することでディレクトリ指定を変更できます。

^%ZJREAD ルーチンの例を以下に示します。このルーチンは %SYS(“JOURNAL” への更新を含むトランザクションを検索し、それが適用されないようにします。このルーチンをコピーし、目的に応じて修正して使用できます。

%ZJREAD;
 /*The following variables are defined; you can modify them
   before the transaction gets applied
 
        type - Transaction type
        gref - Global reference
        value - Global value
        %ZJREAD - 1:Apply transaction, 0:Do not apply transaction
 */
 If gref["SYS(""JOURNAL""" Set %ZJREAD=0
 Quit

^JCONVERT の実行例

以下は、^JCONVERT ユーティリティの実行例です。

%SYS>Do ^JCONVERT
 
Journal Conversion Utility  [ IRIS Format --> Common Format ]


The converted file will be in variable record format.
The default character translation UTF8 is compatible with current ^%JREAD 
on all platforms and can be moved among platforms with binary FTP.
If you answer NO, no character translation will be applied.
 
Use UTF8 character translation? <Yes>

 
Globals in the journal file are stored with a specific directory reference
appended to the global reference. You can choose either to include
the directory reference in the converted file, or exclude it. Note that
if you include it, you can always filter it out or change it later during
the %JREAD procedure.  The directory reference determines where ^%JREAD sets
the global on the target system.  If the directory reference is not included,
all sets are made to the current directory.  If the directory reference is
included, sets will be made to the same directory as on the source system
unless translated by a ^%ZJREAD program you supply.  If the target system
is on a different operating system or the databases reside in different
directories on the target system, the ^%ZJREAD program must be used to
translate the directory reference.
 
Include the directory reference? <Yes>

 
Enter common journal file name:  common.jrn
 
Common journal file: common.jrn
Record separator: Variable
Directory reference: Yes

 
Use current journal filter (ZJRNFILT)? no
Use journal marker filter (MARKER^ZJRNFILT)? no
Process all journaled globals in all directories?   enter Yes or No, please
Process all journaled globals in all directories? yes
Specify range of files to process (names in YYYYMMDD.NNN format)
 
from:     <20181201.001> [?] => 20181202.001
 
through:  <20181204.001> [?] =>
 
Prompt for name of the next file to process? No => No
 

Provide or confirm the following configuration settings:
 
Journal File Prefix: =>
 
Files to dejournal will be looked for in:
     C:\MyIRIS\mgr\journal\
     C:\MyIRIS\mgr\
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:\MyIRIS\mgr\journal\
     C:\MyIRIS\mgr\

You may tailor the response to errors by choosing between the alternative
actions described below.  Otherwise you will be asked to select an action
at the time an error actually occurs.
 
     Either Continue despite database-related problems (e.g., a target
     database is not journaled, cannot be mounted, etc.), skipping affected
     updates
 
     or     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.)
 
     Either 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.)
 
     or     Continue despite journal-related problems (e.g., journal
     corruption, some missing journal files, etc.), skipping affected updates
 
     Either Apply sorted updates to databases before aborting
 
     or     Discard sorted, not-yet-applied updates before aborting (faster)
 
Would you like to specify error actions now? No => yes
 
 
     1.  Continue despite database-related problems (e.g., a target database
     is not journaled, cannot be mounted, etc.), skipping affected updates
 
     2.  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.)
 
Select option [1 or 2]:  1
 
     1.  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.)
 
     2.  Continue despite journal-related problems (e.g., journal corruption,
     some missing journal files, etc.), skipping affected updates
 
Select option [1 or 2]:  2
 
     1.  Apply sorted updates to databases before aborting
 
     2.  Discard sorted, not-yet-applied updates before aborting (faster)
 
Select option [1 or 2]:  2
Based on your selection, this restore will
 
** Continue despite database-related problems (e.g., a target database is not
journaled, cannot be mounted, etc.), skipping affected updates
 
** Continue despite journal-related problems (e.g., journal corruption, some
missing journal files, etc.), skipping affected updates
 
** Discard sorted, not-yet-applied updates before aborting (faster)
 
 
 
C:\MyIRIS\mgr\journal\20181202.001
  13.98%  14.93%  15.95%  17.14%  18.25%  19.27%  20.49%  21.63%  22.65%  23.84%
  24.99%  25.97%  27.10%  28.25%  29.31%  30.50%  31.72%  32.84%  33.84%  34.84%
  35.84%  36.85%  37.91%  38.99%  40.10%  41.08%  42.03%  42.97%  43.93%  44.94%
  45.95%  47.05%  48.11%  49.07%  50.04%  51.02%  52.03%  53.07%  54.14%  55.25%
  56.21%  57.17%  58.15%  59.14%  60.18%  61.24%  62.33%  63.28%  64.20%  65.15%
  66.10%  67.11%  68.13%  69.05%  69.94%  70.83%  71.61%  72.41%  73.09%  73.85%
  74.59%  75.32%  76.06%  76.75%  77.73%  78.70%  79.65%  80.59%  81.53%  82.46%
  83.40%  84.33%  85.27%  86.05%  86.59%  87.13%  87.67%  88.23%  88.78%  89.34%
  89.89%  90.61%  93.28%  94.38%  97.12%  98.21%  99.93%100.00%
***Journal file finished at 11:31:36
 
 
C:\MyIRIS\mgr\journal\20181203.001
  14.01%  14.96%  15.98%  17.18%  18.29%  19.31%  20.53%  21.67%  22.69%  23.88%
  25.03%  26.01%  27.15%  28.30%  29.36%  30.55%  31.78%  32.90%  33.90%  34.90%
  35.91%  36.92%  37.99%  39.06%  40.17%  41.16%  42.11%  43.05%  44.01%  45.03%
  46.04%  47.14%  48.20%  49.17%  50.14%  51.11%  52.13%  53.17%  54.25%  55.36%
  56.33%  57.29%  58.27%  59.26%  60.30%  61.36%  62.46%  63.40%  64.33%  65.28%
  66.23%  67.24%  68.26%  69.19%  70.08%  70.97%  71.76%  72.56%  73.25%  74.01%
  74.75%  75.47%  76.22%  76.91%  77.89%  78.87%  79.83%  80.77%  81.70%  82.64%
  83.58%  84.52%  85.46%  86.24%  86.78%  87.32%  87.87%  88.42%  88.98%  89.53%
  90.09%  90.81%  93.49%  94.59%  97.33%  98.42%100.00%
***Journal file finished at 11:31:37
 
 
C:\MyIRIS\mgr\journal\20181204.001
  13.97%  14.92%  15.93%  17.12%  18.24%  19.25%  20.47%  21.61%  22.62%  23.82%
  24.96%  25.94%  27.07%  28.22%  29.28%  30.46%  31.69%  32.80%  33.80%  34.80%
  35.80%  36.81%  37.87%  38.94%  40.05%  41.04%  41.98%  42.92%  43.88%  44.89%
  45.90%  47.00%  48.06%  49.02%  49.98%  50.96%  51.97%  53.01%  54.08%  55.19%
  56.15%  57.11%  58.08%  59.07%  60.12%  61.17%  62.26%  63.20%  64.13%  65.07%
  66.02%  67.03%  68.05%  68.97%  69.86%  70.75%  71.53%  72.33%  73.01%  73.77%
  74.51%  75.23%  75.98%  76.67%  77.64%  78.61%  79.56%  80.50%  81.43%  82.37%
  83.30%  84.24%  85.17%  85.95%  86.49%  87.03%  87.57%  88.13%  88.68%  89.23%
  89.79%  90.51%  93.18%  94.27%  97.01%  98.10%  99.81%100.00%
***Journal file finished at 11:31:38
 
[journal operation completed]
Converted 26364 journal records 

^JRNMARK を使用したジャーナル・マーカの設定

ジャーナル・ファイルにジャーナル・マーカを設定するには、以下のルーチンを使用します。

SET rc=$$ADD^JRNMARK(id,text)

引数 説明
id マーカ ID (例 : バックアップは -1)
text 256 文字以内の文字列のマーカ・テキスト (例えば、バックアップについては “timestamp”)
rc マーカのジャーナル位置 (コンマで区切られたジャーナル・オフセットとジャーナル・ファイル名)、または、処理が失敗した場合、コンマの後にエラーを説明するメッセージが付いた負のエラー・コード。ジャーナル・オフセットは正の数である必要があります。

^JRNUTIL を使用したジャーナル・ファイルの操作

インターシステムズは、^JRNUTIL ルーチンでいくつかの機能を提供します。サイト特有のルーチンを記述するこれらの機能を使用して、ジャーナル・レコードとファイルを操作できます。

以下のテーブルは、このルーチンで使用可能な関数の一覧です。

^JRNUTIL で使用可能な関数
ジャーナリング・タスク 関数構文
ジャーナル・ファイルを閉じる $$CLOSEJRN^JRNUTIL(jrnfile)
ジャーナル・ファイルの削除 $$DELFILE^JRNUTIL(jrnfile)
ジャーナル・ファイルからローカル配列にレコードの読み取り $$GETREC^JRNUTIL(addr,jrnode)
別のジャーナル・ファイル・ディレクトリへの切り替え $$JRNSWCH^JRNUTIL(newdir)
ジャーナル・ファイルを開く $$OPENJRN^JRNUTIL(jrnfile)
開かれているジャーナル・ファイルの使用 $$USEJRN^JRNUTIL(jrnfile)
Important:

DELFILE^JRNUTIL 関数は、ジャーナル・ファイルを削除する前に、開いているトランザクションがあるかどうかをチェックしません。

以下のテーブルは、このユーティリティで使用される引数です。

引数 説明
addr ジャーナル・レコードのアドレス
jrnfile ジャーナル・ファイルの名前
newdir 新しいジャーナル・ファイル・ディレクトリ
jrnode ジャーナル・レコード情報を返すために、参照から渡されるローカル変数

DISABLE^%NOJRN を使用したプロセス・レベルでのジャーナリングの管理

ジャーナリングがシステム全体で有効になっている場合、特定のプロセス内のグローバルに対して Set 処理および Kill 処理を実行するために、以下のようにアプリケーション内またはプログラマ・モードからユーティリティ ^%NOJRN を呼び出して、ジャーナリングを停止できます。

%SYS>DO DISABLE^%NOJRN

ジャーナリングは、以下のイベントのいずれかが発生するまで無効になっています。

  • プロセスが中断

  • ジャーナリングを再度アクティブにするために、プロセスが以下の呼び出しを発行

    %SYS>DO ENABLE^%NOJRN
    
Note:

DISABLE^%NOJRN を使用してジャーナリングを無効にしても、ミラーリングされたデータベースに影響はありません。

DISABLE^%NOJRN を使用するには、少なくとも %Admin_Manage リソースへの読み取りアクセスが必要です。

ジャーナル入出力エラー

InterSystems IRIS でジャーナル・ファイルの入出力エラーが発生した場合、その応答は [エラー時に凍結] ジャーナル設定によって異なります。この設定は、管理ポータルの [ジャーナル設定] ページにあります。[エラー発生時に凍結する] 設定は次のように機能します。

  • [エラー発生時に凍結する] 設定が [いいえ] (既定) の場合、ジャーナル・デーモンは成功するまで、またはいくつかの条件が満たされるまで、失敗した操作を再試行します。成功または条件が満たされた時点で、すべてのジャーナリングは無効化されます。 このアプローチにより、システムは引き続き利用可能になりますが、ジャーナリングを無効にすることでデータの整合性と回復性が損なわれます。

  • [エラー発生時に凍結する][はい] に設定されている場合、すべてのジャーナリングされたグローバル更新が凍結されます。これにより、システムは使用できなくなりますが、データの整合性は保護されます。

ローカル・トランザクションのロールバックに失敗すると、[エラー発生時に凍結する] 設定もアプリケーションの動作に影響します。

業務上の必要性を確認し、環境に最適な手法をとることをお勧めします。以下のセクションでは、各選択内容によって発生する影響について説明します。

ジャーナルの [エラー発生時に凍結する] 設定が [いいえ] の場合

ジャーナル・ファイル入出力エラー時にフリーズしないよう InterSystems IRIS を構成している場合、ジャーナル・デーモンは、成功するまで、または以下の条件のいずれかが満たされるまで、定期的に (通常 1 秒ごと) 失敗した操作を再試行します。

  • デーモンが事前設定された期間 (通常 150 秒) 操作を再試行した

  • システムがそれ以上ジャーナリングされた更新をバッファできない

上記の条件のいずれかが満たされると、ジャーナリングは無効化され、データベースの更新がジャーナリングされなくなります。結果として、ジャーナルは、システムがクラッシュしたときにデータベースを回復するためソースとしては、信頼性に欠けるものになります。ジャーナリングが無効になっている場合は、以下の状況が発生します。

  • トランザクションのロールバックは失敗し、<ROLLFAIL> エラーが生成され、トランザクションが部分的にコミットされた状態になります。

  • コミットされていないデータのクラッシュ回復機能が無効になります。

  • 完全に回復するためのデータが存在しなくなります。前回のバックアップの状態にのみ回復できます。

  • ECP のロック機能とトランザクションの回復可能性から信頼性が失われます。

  • システムがクラッシュすると、ジャーナリングが無効になる前に始まっていたトランザクションが不完全な状態になっていても、InterSystems IRIS が起動するときのリカバリ・プロセスではそのトランザクションはロールバックされません。これは、トランザクションはコミットされていてもジャーナリングされていないからです。

ジャーナリングが無効になった場合の措置

ジャーナリングが無効になった場合に実行する手順を以下にまとめます。

  1. 問題の解決 — 可能な限り早急に、ジャーナリングの無効化を引き起こした問題を解決します。

  2. ジャーナル・ファイルの切り替え — ジャーナル・デーモンは、失敗した入出力処理を定期的に再試行し、ジャーナリングが無効になる前に蓄積されたジャーナル・データを保持しようとします。必要に応じ、ジャーナル・ファイルを新しいディレクトリに切り替えてエラーを解決できます。ただし、InterSystems IRIS は、失敗した入出力の処理に成功してジャーナリングを新しいファイルに切り替えても、ジャーナリングを自動的に再び有効にすることはありません。また、ジャーナル・ファイルを手動で切り替えた場合も、ジャーナリングが自動的に再び有効になることはありません

  3. データベースのバックアップ — メイン・サーバのデータベースをバックアップします (バックアップを実行すると、ジャーナリングは自動的に再び有効になります)。

    エラーの発生後は、データの損失を防止するために、できる限り早い時点でデータベースをバックアップすることを強くお勧めします。実際に、ジャーナリングの無効化の原因となった入出力エラーが解決済みで、ユーザに適切な特権があれば、そのエラーでジャーナリングが無効になっている状態でオンライン・バックアップを実行すると、ジャーナリングが自動的に再開されます。^JRNSTART を実行してジャーナリングを有効にすることもできます。

    バックアップが正常に完了してジャーナリングが再開されると、InterSystems IRIS では、保留中のすべてのジャーナル入出力が破棄されます。これは、保留中のジャーナル入出力で扱われているデータベース更新はすべて、正常に完了したバックアップに記録されているからです。

    Important:

    ジャーナリングを開始するには、バックアップを実行する場合よりも高い特権が必要です。

ジャーナルの [エラー発生時に凍結する] 設定が [はい] の場合

ジャーナル・ファイルに入出力エラーが発生したときにフリーズするように InterSystems IRIS を構成しておくと、すべてのジャーナリングされたグローバル更新は、そのようなエラーの発生時に直ちにフリーズされます。これにより、システムの可用性は低下しますが、ジャーナル・データの喪失を防止できます。ジャーナル・デーモンがジャーナル書き込みを最低 30 秒間完了できない場合にも、グローバル更新はフリーズされます。

ジャーナル・デーモンは失敗した入出力操作を再試行し、成功するとグローバル更新のフリーズを解除します。グローバル更新がフリーズしている間、その他のジョブも停止されます。一般的な結果として、ジャーナリングの問題が解決するまで InterSystems IRIS は停止したままとなり、エンドユーザにはシステムの運用が停止したように見えます。InterSystems IRIS が停止している間に問題の対策をとることができます。例えば、ディスクの領域の解放、別のディスクへのジャーナル切り替え、ハードウェア障害の修正などの措置をとります。

このオプションの利点は、問題が解決して InterSystems IRIS が通常の動作を再開した時点で、失われるジャーナル・データは存在しないことです。欠点は、問題を解決している間、システムの可用性が低下するか、まったく使用できなくなることです。

失敗した入出力処理をジャーナル・デーモンが再試行している間、InterSystems IRIS はアラート (深刻度 3) を messages.log ファイルに定期的に記録します。

ジャーナルの [エラー発生時に凍結する] 設定の TROLLBACK を使用したトランザクションのロールバックに対する影響

選択した [エラー発生時に凍結する] 設定がジャーナリングと関係のないアプリケーションの動作に大きな意味を持つ可能性があるということを認識しておくことが重要です。アプリケーションが TROLLBACK コマンドを使用して開いているトランザクションをロールバックしようとして ("ObjectScript リファレンス" の "TROLLBACK" を参照)、これに失敗すると、ジャーナル入出力エラー発生時に直面するトレードオフ (データの整合性と可用性) と同じトレードオフが発生します。ジャーナリングと同様に、TROLLBACK[エラー発生時に凍結する] 設定を使用して、以下のように適切な動作を決定します。

  • [エラー発生時に凍結する] 設定が [いいえ] (既定) の場合、トランザクションおよび TROLLBACK を開始したプロセスがエラーを受け取り、そのトランザクションが閉じられ、そのトランザクションに対して保持されているロックが解放されます。このアプローチにより、アプリケーションは引き続き利用可能になりますが、データの整合性と回復性が損なわれます。

  • [エラー発生時に凍結する][はい] に設定されている場合、開始したプロセスは停止し、CLNDMN は開いているトランザクションのロールバックを繰り返し試行します。CLNDMN が再試行している間、トランザクションに対して保持されているロックは変更されませんが、アプリケーションは停止する場合があります。これにより、アプリケーションは使用できなくなりますが、データの整合性は保護されます。

(メッセージ・ログで報告されるように) 停止したジョブの開いているトランザクションのロールバックを CLNDMN が何度も試行して失敗している場合、Manage^CLNDMN ユーティリティを使用して、トランザクションを手動で終了できます。

Note:

[エラー発生時に凍結する] 設定はローカルの (ECP でない) トランザクションのロールバックにのみ影響します。

ジャーナリングに関する特別な考慮事項

InterSystems IRIS のジャーナリングを使用するときは、以下の特別な考慮事項を確認します。

パフォーマンス

データベースの整合性を確保するうえでジャーナリングは重要ですが、ジャーナルの対象となるグローバルの更新数によっては、ディスク領域が消費され、性能が低下します。

変更がデータベースとジャーナル・ファイルの両方に記録されるため、更新処理は二重に行われます。 この結果、ジャーナリングは性能に影響を与えます。InterSystems IRIS はフラット・ファイルでのジャーナリングを使用しているので、性能の低下が最小限になります。

UNIX® ファイル・システムの推奨事項

このリリース用のオンライン・ドキュメント "インターシステムズのサポート対象プラットフォーム" の “サポートされているファイル・システム” の表では、UNIX®/Linux プラットフォームでインターシステムズが推奨しサポートしているファイル・システムの概要を示していますが、ここには、最適なジャーナル・パフォーマンスを実現するためのマウント・オプションに関する注意事項も記載されています。

Note:

推奨されるマウント・オプションが存在しないファイル・システムでプライマリまたは代替のジャーナル・ディレクトリを構成すると、以下のようなメッセージがメッセージ・ログに入力されます。

The device for the new journal file was not mounted with a recommended option (cio).

システム時計の推奨事項

InterSystems IRIS でサポートされるオペレーティング・システムのすべてに Network Time Protocol (NTP) クライアントがあり、システム時計と参照システムの同期が保持され、サマータイムと標準時間との間でシステム時計を自動調整する機能があります。

システム時計の同期の保持および管理には、システム時計を手動で調整するのではなく、オペレーティング・システムの自動クロック管理機能を利用することをお勧めします。

テスト作業などで手動で時間を調整する必要がある場合は、実稼働環境ではなく、必ずテスト環境を使用してその作業を実行してください。また、時計を進めたり、戻したりする調整などの非時系列的イベントは一部のユーティリティで障害発生の原因になる可能性があるため、手動の調整は慎重に行う必要があります。

ファイリング操作に対するジャーナリングの無効化

オブジェクトの保存や削除などのファイリング操作に対するジャーナリングを無効にすることが効果的な場合や必要な場合があります。これには、以下の 2 つの方法があります。

  • オブジェクトを開く (通常は %OpenIdOpens in a new tab または %OpenOpens in a new tab を使用します) ときに、並行処理の値として 0 を指定します。0 より大きい並行処理の値を指定してそのオブジェクトを既に開いている場合は、並行処理の値に 0 を指定しても効果はありません。

  • 現在のプロセスに対するオブジェクト・ファイラ・トランザクション処理を中断します。これを行うには、$system.OBJ.SetTransactionMode(0) を呼び出します (これは %SYSTEM.OBJOpens in a new tab クラスの SetTransactionModeOpens in a new tab メソッドなので、専用の $system オブジェクトを介して呼び出すことができます)。SetTransactionMode メソッドは 0 または 1 の値をとり、オブジェクト・ファイラ・トランザクションは 0 で無効、1 で有効になります。この設定は現在のファイリング操作だけでなく、プロセス全体に影響します。

Important:

ジャーナリングの無効化が求められることもありますが、実際にその必然性があるかどうかを確認してください。この確認を怠ると、必要なデータが部分的に欠損したジャーナルが生成され、そのデータは永久に失われる可能性があります。

FeedbackOpens in a new tab