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 のジャーナリングとトランザクション処理によって論理的な整合性が維持されます。バックアップ方法とジャーナリングの組み合わせにより、物理的な整合性が失われても迅速なリカバリが可能です。

この章では、構造的な整合性がどのように維持されているか、およびその検証方法について説明します。残りの各章では、以下の項目について説明します。

基本的なデータ整合性の保護

一般に、整合性は 2 つの異なるレベルで表示できます。

  • 構造的なデータベースの整合性または物理的な整合性は、ディスク上のデータベース・ブロックのコンテンツを指します。構造的な整合性を持つには、データベース・ブロックが自己整合しており、グローバルが検索可能でなければなりません。システム・クラッシュ時の構造的な整合性は、“ライト・イメージ・ジャーナリングとリカバリ” の章に説明があるインターシステムズのライト・イメージ・ジャーナル (WIJ) テクノロジ、および InterSystems IRIS の内部アルゴリズムによって保持されます。

  • 論理的な整合性は、データベース内のグローバルによって表現されるデータを指し、アプリケーションによって作成されるデータの自己一貫性、そのトランザクション整合性、および現実との最新性が含まれます。システム・クラッシュ時の論理的な整合性は、InterSystems IRIS ジャーナリング (“ジャーナリング” の章を参照) およびトランザクション処理によって保持されます。(論理的な整合性の他の点は、インタロック、トランザクション、およびアプリケーションが使用するプログラミング・パラダイムに固有の他のメカニズムを適切に使用することにより、アプリケーション・コードで管理されます。)

自動的な WIJ およびジャーナルのリカバリは、InterSystems IRIS データベースをシステム障害から保護する、インターシステムズの "防弾型" データベース・アーキテクチャの基本的な構成要素です。

整合性の検証とリカバリのメカニズム

システム・クラッシュだけで整合性の低下を招く可能性はないとしても、ストレージ・デバイスに破壊的な障害が生じたり、物理的な損傷を受けたり、改ざんされたりする可能性は常に存在します。その場合、データベース、WIJ、およびジャーナルの整合性が危険にさらされる可能性があります。そうした災害の影響を軽減するために、InterSystems IRIS は以下の機能を提供します。

  • データベースの構造的な整合性を確認するためのツール。詳細は、この章の "構造的な整合性の検証" を参照してください。

  • バックアップ・メカニズム。詳細は、“バックアップとリストア” の章を参照してください。

  • ミラーリング ("高可用性ガイド" の “ミラーリング” の章を参照) を使用した、自動フェイルオーバーおよび災害復旧のためのジャーナリング・ベースの論理データ・レプリケーション。

  • DataCheck。これは、ミラーリングなどのテクノロジがデータの複製コピーを保持する際、複数のシステム間でデータの整合性を確認するツールです (“複数のシステムでのデータ整合性” の章を参照)。

構造的な整合性の検証

整合性チェックにより、データベースのセット、またはデータベース内のグローバルのサブセットの構造的な整合性を検証します ("基本的なデータ整合性の保護" を参照)。

整合性チェックの実行の利点は以下のとおりです。

  • 整合性チェックとバックアップ方法を統合して、バックアップ時にデータベースのコピーが損なわれず、バックアップ自体にエラーが入り込んでいないことを確認できます。詳細説明は、“バックアップとリストア” の章の "外部バックアップ" にあります。

  • 整合性チェックでは、破損が生じる前にそれを検出できるため、ユーザが影響を受ける前に計画を立てる時間があります。

  • 定期的な整合性チェックにより、検出された構造的な整合性の問題の原因を早めに正確に突き止められるため、根本原因を特定できる可能性が高くなります。

整合性チェックにより、選択したデータベース内のすべてのグローバルの整合性、または指定された単一のデータベースに格納されている選択したグローバルの整合性を検証できます。整合性チェックは、管理ポータルから実行することも、ターミナル・ウィンドウで ^Integrity ユーティリティを使用して実行することもできます。このセクションでは、以下のトピックについて説明します。

整合性チェックの誤検出

揮発性データベースに対して整合性チェックを実行すると、進行中のデータベース更新が原因で、データベース整合性エラーのレポートが誤って生成されることがあります。

"管理ポータルを使用したデータベース整合性のチェック" で説明されているように、整合性チェックが管理ポータルまたはタスク・マネージャから実行される場合、バックグラウンドで実行され、エラーが検出されたすべてのグローバルを自動的に再テストします。この自動の2回目のパスを含む整合性チェックからの出力では、以下の方法でエラーを報告します。

  • グローバルのエラーが1回目のパスでは検出されたが、2回目のパスでは検出されない場合、最初のエラーは誤検出と想定され、エラーは報告されません。

  • 2回目のパスで検出されたグローバルのエラーが、1回目のパスで検出されたエラーと異なる場合、2回目のパスのエラーのみ報告され、These errors in global <global_name> differ from the errors prior to the retry というテキストが表示されます。

  • 両方のパスでグローバルに同じエラーが検出される場合、エラーは、When retried the errors in global <global_name> remained unchanged というメッセージで報告されます。

"^Integrity ユーティリティを使用したデータベース整合性のチェック" に説明がある ^Integrity ユーティリティまたはエントリ・ポイントのいずれかを使用して手動で実行される整合性チェックでは、1回目のパスでエラーが報告されたグローバルの再テストは行われません。エラーが返される場合、その特定のデータベースのチェックを繰り返します。

一般に、アクティブ・システムに対して実行される整合性チェックの場合、2回目のパスで繰り返されないエラーは誤検出であり、2回目のパスで持続するエラーは実際の整合性の問題を表します。後者のエラーは調査する必要があります。また、前者のエラーも、アクティビティのレベル、エラーの数、以前に誤検出が発生したエクステントに応じて、調査するメリットがあります。調査の種類は、専門知識のレベルや過去の誤検出の経験によって決まります。実行できる手順は以下のとおりです。

  • 可能であれば、システム・アクティビティの少ない期間に、整合性チェックを再度実行します。

  • 最新のバックアップのリストアされたコピーに対して整合性チェックを実行します。

  • 根本原因の手掛かりを得るために、問題となっているデータの範囲を確認します。

  • インターシステムズのサポート窓口Opens in a new tabに問い合わせます。

誤検出の問題は、"データ整合性ガイド" の “バックアップ” の章にある "外部バックアップ" で説明されているような標準のバックアップ手順に、整合性チェックを統合することで回避できます。これにより、データベースは、そのデータベースが存在する論理ディスク・ボリュームのスナップショットが取られた直後に、"整合性チェックの分離" で説明されているように、プロダクションから切り離してチェックされるようになります。

整合性チェックの出力

整合性チェックは、検出したエラーを報告するだけでなく、各グローバルに含まれるブロックの数と、使用中のそれらのブロックの割合についての情報をブロック・レベルで分割して報告します。その例として、20,000 件のユーザのデータが入力された DATA データベースに対する整合性チェックの出力の一部を次に示します。

File Name: c:\intersystems\20182555dec15a\mgr\integ.txt

IRIS Database Integrity Check - Report Created 01/25/2018 10:41:16
System: BBINSTOCK6440 Configuration: 20182555DEC15A

No Errors were found.


Full Listing of Databases Checked


Directory: C:\InterSystems\20182555DEC15A\Mgr\DATA\
0 globals with errors found

Global: Aviation.AircraftD                                  0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (6% full)
 Data Level:           # of blocks=64      512kb (87% full)
 Total:                # of blocks=65      520kb (85% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:15

Global: Aviation.AircraftI                                  0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (0% full)
 Data Level:           # of blocks=4      32kb (83% full)
 Total:                # of blocks=5      40kb (67% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:15

Global: Aviation.Countries                                  0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (0% full)
 Data Level:           # of blocks=1      8kb (52% full)
 Total:                # of blocks=2      16kb (26% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:15

Global: Aviation.CrewI                                      0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (1% full)
 Data Level:           # of blocks=5      40kb (90% full)
 Total:                # of blocks=6      48kb (75% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:15

Global: Aviation.EventD                                     0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (41% full)
 Data Level:           # of blocks=377      3,016kb (78% full)
 Big Strings:          # of blocks=776      6,208kb (72% full) # = 479
 Total:                # of blocks=1,154      9,232kb (74% full)
 Elapsed Time = 0.1 seconds, Completed 01/25/2018 10:41:15

Global: Aviation.EventI                                     0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (0% full)
 Data Level:           # of blocks=3      24kb (77% full)
 Total:                # of blocks=4      32kb (58% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:15

...

Global: ROUTINE                                             0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (1% full)
 Data Level:           # of blocks=6      48kb (78% full)
 Total:                # of blocks=7      56kb (67% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:16

Global: SYS                                                 0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (0% full)
 Data Level:           # of blocks=1      8kb (0% full)
 Total:                # of blocks=2      16kb (0% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:16

Global: Data.CompanyD                                     0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (0% full)
 Data Level:           # of blocks=1      8kb (35% full)
 Total:                # of blocks=2      16kb (17% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:16

Global: Data.CompanyI                                     0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (0% full)
 Data Level:           # of blocks=1      8kb (9% full)
 Total:                # of blocks=2      16kb (4% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:16

Global: Data.PersonD                                      0 errors found
 Top/Bottom Pnt Level: # of blocks=1      8kb (0% full)
 Data Level:           # of blocks=5      40kb (81% full)
 Total:                # of blocks=6      48kb (67% full)
 Elapsed Time = 0.0 seconds, Completed 01/25/2018 10:41:16

...
   

管理ポータルからの実行時には、整合性チェックで生成されたエラーと警告があれば、レポートの先頭にそのリストが示されます。^Integrity ユーティリティを使用して実行する場合、エラーの概要は出力の末尾に示されます。

管理ポータルを使用した整合性のチェック

選択した複数のデータベースの整合性や、1 つのデータベースに格納された複数の選択したグローバルの整合性をチェックするには、管理ポータルの [データベース] ページ ([ホーム][システム処理][データベース]) に移動し、次の手順を実行します。

  1. [整合性チェック] をクリックして、データベースのリストを表示します。

  2. 確認対象のデータベースのチェック・ボックスにチェックを付けます。

    単一のデータベースに格納されたグローバルをチェックする場合は、チェック対象のグローバルが格納されたデータベースのみを選択して [グローバルを選択] をクリックし、選択したデータベースに格納されたグローバルのリストを表示します。チェックするグローバルを選択して、[保存] をクリックします。リストからグローバルを選択していないと、選択したデータベースのグローバルがすべてチェックされます。

  3. エラー発生時にデータベース整合性チェックを停止する場合、[エラー発生後に停止する] チェック・ボックスにチェックを付けます。

  4. [OK] をクリックし、整合性チェックを開始します。整合性チェックのプロセスがバックグラウンドで実行されます。

[整合性ログ] をクリックすると、ポータルを使用して最後に実行した整合性チェックの出力が表示されます。このファイルのパスと内容が自動的に表示されます。

整合性チェックは、また、タスク・マネージャの、既定のシステム・バックグラウンド・タスクの 1 つです。必要に応じて、複数の整合性チェックをスケジュールすること (異なる時間に異なるデータベースをスケジュールするなど) もできます。システム・タスクのスケジューリングの詳細は、"システム管理ガイド" の “InterSystems IRIS の管理” の章にある "タスク・マネージャの使用" を参照してください。

Note:

データベースはマウントされているが、管理ポータルのデータベース構成に一度も追加されたことがない場合、または管理ポータルのデータベース構成から削除された場合 ("システム管理ガイド" の "データベースの構成" を参照)、そのデータベースは整合性チェック機能で表示されるデータベース・リストには含められません。

^Integrity ユーティリティを使用したインタラクティブな整合性チェック

手動の整合性チェックは、^Integrity ユーティリティを使用して実行できます。このユーティリティを実行するには、ターミナル・ウィンドウを開き、%SYS ネームスペースに切り替えて、do ^Integrity と入力します。これは管理ポータルの [データベース] ページから整合性チェックを実行することと同様です。ただし、"整合性チェックの誤検出" で説明したとおり、^Integrity ユーティリティは、完了して結果を報告する前に、1 回目のパスでエラーが検出されたグローバルを再チェックすることはできないため、エラーが報告されたグローバルを再チェックして誤検出を排除することが重要になります (管理ポータルの整合性チェックでは、^Integrity ユーティリティのような単一のジョブを実行するのではなく、整合性チェックも複数のジョブに分散されます)。

以下の ^Integrity エントリ・ポイントをインタラクティブに使用することもできます。

  • Do CheckPointer^Integrity は、チェックを開始するディレクトリとポインタ・ブロックを尋ねます。

  • Do Exclude^Integrity でチェックから除外するためのデータベースのリストを要求します。? を入力してマウントされたデータベースのリストを表示します。

整合性チェック API

以下の ^Integrity エントリ・ポイントは、プログラムによる使用が可能です。

  • Do CheckList^Integrity(outputglobal,dirlist,stopafteranyerror,listofglolist,maxproc,partialcheck) はバックグラウンドで整合性チェックを実行し、情報や警告を含む結果を格納します。パラメータの使用法は以下のとおりです。

    • outputglobal

      結果を格納するグローバルを指定します。このパラメータの呼び出しを省略した場合、結果は ^IRIS.TempIntegrityOutput(+$JOB) に格納されます。このパラメータを使用する際には、$datat(@outputglo)=0 であること、およびこれが複数の並行呼び出しで共有されていないことを確認する必要があります。

    • dirlist

      チェックするすべてのディレクトリの $LIST を指定します。省略した場合は、すべてのディレクトリをチェックします。

    • stopafteranyerror

      エラー発生時の整合性チェックの動作を指定します。1 を指定した場合、エラーが検出されるとディレクトリのチェックは停止され、0 (既定値) を指定した場合、エラー発生時にチェックは続行されます。

    • listofglolist

      グローバル名を指定した $LIST を複数含む $LIST を、dirlist で指定されたディレクトリごとに 1 つ指定します。これらのパラメータを使用すると、例えば、$LB($LB("oddDEF")) を指定してすべてのディレクトリですべての oddDEF グローバルをチェックできます。listofglolist の要素が dirlist よりも少ない場合、前者の最後の要素が後者の残りのディレクトリに使用されます。

    • maxproc

      使用する並列処理の最大数を指定します。既定値は 8 です。1 未満の値を指定した場合、ホスト・システムのコアの数が使用されます。1 を指定した場合、整合性チェックはフォアグラウンドで実行されます。

    • partialcheck

      既定値 0 を指定すると、グローバル全体がチェックされ、大規模なグローバルの場合は範囲別に分割できます。-1 を指定した場合もグローバル全体がチェックされますが、大規模なグローバルを範囲別に分割することはできません。この値は、予期しない問題が発生した場合のフォールバックとしてのみ提供されており、今後削除される可能性があります。1 を指定すると、大規模なグローバルの場合はポインタ構造のみがチェックされます。この値ではそれほど詳細なチェックは行われず、データ・ブロックや大規模な文字列ブロックのエラーは検出されません。

    Do CheckList^Integrity は %Status sc を返し、これは次のように評価されます。

    • $system.Status.IsOK(sc) が返される場合、整合性チェックが実行され、エラーは検出されていません。

    • 単一のエラー・コード $$$IntegrityCheckErrors の戻りステータス、すなわち $system.Status.GetErrorCodes(sc)=$$$ERRORCODE($$$IntegrityCheckErrors) の場合、整合性チェックは成功していますが、エラーが検出されています。

    • 前述のどちらも返されない場合、問題が発生し、整合性チェックで完全な結果を返せない可能性があります。この場合、sc に複数のエラー・コードが含まれ、そのいずれかが $$$IntegrityCheckErrors である可能性があります。

  • Do Display^Integrity(integritout,flags,dirsum) は、整合性チェックの結果を表示します。パラメータの使用法は以下のとおりです。

    • integritout

      整合性チェックの結果を格納したグローバルの名前を (CheckList^Integrity により) 指定します。指定がない場合は、既定の ^IRIS.TempIntegrityOutput(+$JOB) になります。

    • flags

      以下の値に基づいて、表示されるメッセージを決定します。

      • 0 は、すべてのメッセージを表示します。

      • 1 は、エラーと警告のみを表示します。

      • 2 は、エラーのみを表示します。

      指定されていない場合は、すべてのメッセージが表示されます。

    • dirsum

      指定されていて 0 ではない場合、表示にはスキャンされたそれぞれのディレクトリのブロックの概要が含まれます。

以下に、5 つのプロセスを使用して 3 つのデータベースをチェックする例を示します。 ここで dblist パラメータを省略すると、すべてのデータベースがチェックされます。(上記 CheckList^Integrity の戻り値の説明で記載した sc の評価で、結果を表示する必要はありません。)

set dblist=$listbuild(“/data/db1/”,”/data/db2/”,”/data/db3/”)
set sc=$$CheckList^Integrity(,dblist,,,5)
do Display^Integrity()
kill ^IRIS.TempIntegrityOutput(+$job)

以下のエントリ・ポイントは、従来の使用法でのみサポートされます。

  • Do Silent^Integrity(logfilename,dirlist) は、選択したデータベース、またはすべてのデータベースで整合性チェックを実行するバックグラウンド・プロセスを開始し、結果を logfilename パラメータで指定されたファイルに出力します。オプションの dirlist パラメータは、チェック対象データベースの $LIST を指定します。指定しない場合は、すべてのデータベースがチェックされます。これは、管理ポータルの [データベース] ページから整合性チェックを実行するのと同じです。

  • Do SilentGlobalCheck^Integrity(logfilename,dir,gbllist) は、選択したデータベース内の選択したグローバルの整合性チェックを実行するバックグラウンド・プロセスを開始し、結果を logfilename パラメータで指定されたファイルに出力します。必須の dir パラメータは、チェックするグローバルを含むデータベースを特定します。必須の gbllist パラメータは、チェックする 1 つ以上のグローバルの $LIST を指定します。これは、管理ポータルの [データベース] ページから整合性チェックを実行するときに、[グローバル選択] を選択するのと同じです。

  • Do Query^Integrity(logfilename,outdevice) は整合性チェックを実行しませんが、logfilename パラメータで指定されたファイルのコンテンツ (前回の実行で保存された結果) を、オプションのパラメータ outdevice で指定されたデバイスに出力します。outdevice の例として、現在のデバイス (既定)、プリンタ、その他のディスプレイ・デバイス、その他のオペレーティング・システム・ファイル名 (logfilename のコピー先) があります。

整合性チェックのパフォーマンスの調整

整合性チェックでは、チェック対象のグローバルのすべてのブロックを (まだバッファに入っていない場合)、各グローバルの構造で指示された順序で読み取る必要があるため、この処理にはかなりの時間がかかり、ストレージ・サブシステムの帯域幅の多くを使用する可能性があります。整合性チェックの速度とパフォーマンスに与える影響の最適なバランスは、整合性チェックを実行する理由とタイミングによって決まります。例えば、ストレージの破損を伴う災害に対応して整合性チェックを実行する場合は、できるだけ早く結果を入手したいと考えますが、プロダクションと並行して実行する場合は、ストレージ・サブシステムへの影響を最小限に抑えたいと考えるでしょう。

整合性チェックでは、ストレージ・サブシステムで可能な限りの速度で読み取りを行うことができます。使用中の整合性チェック・プロセスの数に、各プロセスに許容される同時有効非同期読み取りの最大数 (既定値は 8) を掛けた値が、全体的な同時読み取り数の上限ですが、平均値はその半分です。この予測値をストレージ・サブシステムの容量と比較して、最適なプロセス数を決定します。例えば、ストレージが 20 のドライブにストライピングされ、プロセス当たりの同時読み取り数が既定の 8 の場合、ストレージ・サブシステムの全容量を捕捉するには、5 つ以上のプロセスが必要です (5*8/2=20)。(プロセスへの割り当てはグローバルごとに行われるため、特定のグローバルは常に 1 つのプロセスのみによってチェックされます。)

整合性チェックのパフォーマンスを調整するための推奨アプローチは次のとおりです。

  1. 最初の手順では、整合性チェックを起動するための最適な方法を次のように選択します。

    • 整合性チェックを起動する CheckList^Integrity エントリ・ポイントでは、プロセス数を指定できるため、パフォーマンスを最大限制御できます。このため、整合性チェックのパフォーマンスを調整するための最も簡単なアプローチとなっています。整合性チェックで使用する並列プロセスの数を指定する、CheckList^Integritymaxproc 引数については、"整合性チェック API" を参照してください。

    • 管理ポータルの [整合性チェック] オプションとタスク・マネージャの [整合性チェック] システム・バックグラウンド・タスクは複数のプロセスを使用しますが、CheckList^Integrity と同じ制御ではありません。管理ポータルのオプション、タスク・マネージャのタスク、および SYS.Database.IntegrityCheck()Opens in a new tab API 呼び出しはすべて、CPU コア数と同じプロセス数 (一般に比較的大きな数になります) を選択します。また、これらのインタフェースは、同時更新による誤検出を特定する際にエラーが報告されたグローバルの完全な再チェックも実行します。この再チェックは、整合性チェック・アルゴリズムに組み込まれた誤検出の軽減策に加えて行われるもので、時間がかかるため不要な場合があります。

    • ターミナルの ^Integrity ルーチンや Silent^Integrity エントリ・ポイントなどその他の起動方法は、整合性チェックを単一プロセスで実行するため、すぐに結果が必要なときには役に立ちません。これらの起動方法にも、結果をファイルやターミナルに即座に出力して、整合性チェックの進行中にユーザに表示できるという利点があります。

  2. 整合性チェック・プロセスではグローバルのポインタ・ブロックを一度に 1 つずつ、指し示すデータ・ブロックの内容に対して検証します。ストレージ・サブシステムが複数の同時有効読み取り要求を処理できるように、データ・ブロックは非同期入出力で読み取られ、各読み取りが完了すると検証が実行されます。既定では、同時読み取り要求の最大数は 8 です。以下の点に注意してください。

    • 使用中のプロセスの数にプロセス当たりの最大同時読み取り数を掛けた値が、全体的な同時読み取り数の上限であるため、整合性チェックの並列プロセス数を変更することが、通常最初に行う調整になります。ただし、最大同時読み取りパラメータを変更すると、追加制御が提供される場合があります。また、整合性チェックが単一プロセスに制限されている場合は (例えば、1 つの非常に大きいグローバルがある場合や、その他の外部制約がある場合)、このパラメータを調整することが、パフォーマンスを調整する主な手段となります。

    • このパラメータを引き上げるメリットは、ストレージ・サブシステムの同時読み取りを処理する能力によって制限されます。データベースが単一のローカル・ドライブに格納されている場合、値が大きいとメリットはなくなります。他方、多数のドライブにストライピングされたストレージ・アレイは多数の読み取りを同時に処理することができます。このメリットは、さまざまな要素の中で、特に計算時間によっても制限されます。

    同時読み取りの最大数を調整するには、%SYS ネームスペースでターミナルを開いて、write $$GetAsyncReadBuffers^Integrity() を入力して現在の値を表示し、必要に応じて do SetAsyncReadBuffers^Integrity(value) を入力して変更します。最大値は 128 です。変更は、次にグローバルをチェックするときに反映されます。(この設定は、インスタンスが再起動されている間、保持されるわけではありません。)

    ディスク上でブロックが連続している場合に (または、それに近い場合)、各読み取りの最大サイズを制御する、似たようなパラメータがあります。このパラメータが必要になることはそれほどありませんが、待ち時間の長いストレージや、ブロック・サイズが大きいデータベースは、調整することで効果が得られる可能性があります。このパラメータのコマンドは write $$GetAsyncReadBufferSize^Integrity()do SetAsyncReadBufferSize^Integrity(value) です。値は 64 KB の単位で設定されるため、値 1 は最大値として 64 KB を設定し、4 は 256 KB を設定し、最大 512 (32,768 KB) まで設定できます。既定値は 0 で、インスタンスが値を選択できます。現在、64 KB を表す 1 が選択されています。

整合性チェックの分離

多くのサイトでは、プロダクション・システムで直接、定期的に整合性チェックを実行しています。これは簡単であるというメリットがありますが、整合性チェックがストレージの帯域幅に与える影響が懸念されるほかに、データベース同時更新アクティビティで誤検出エラーが発生することもあります (組み込みの移行手段にもかかわらず)。プロダクション・システムでの整合性チェックでこのエラーが報告された場合、この評価や再チェックは管理者が行う必要があります。

誤検出を避けるために、整合性チェックをプロダクションから切り離すことができます。それには、ストレージ・スナップショットやバックアップ・イメージを別のホストにマウントして、切り離された InterSystems IRIS インスタンスで整合性チェックを実行させます。ストレージもプロダクションから切り離されていれば、整合性チェックのパフォーマンスを最大限に高め、プロダクションのストレージに与える影響を心配することなく、結果を可能な限り早く入手することができます。このアプローチは、整合性チェックを使用してバックアップを検証する場合に適しています。検証されたバックアップは、バックアップを作成した時点でのプロダクション・データベースを効果的に検証します。また、クラウドおよび仮想化プラットフォームでも、スナップショットから使用に適した切り離された環境を容易に構築できます。

FeedbackOpens in a new tab