ジャーナリングの設定
前 第6章. GT.M ジャーナリング 次

ジャーナリングの設定

GT.Mのジャーナリング機能はコンポーネント数に影響します：

ジャーナリングを使用するには、ツールをよく理解する必要があります。ひとつの重要な選択は、どのようにジャーナルフェンスを使用するかどうかを決めることです。別の方法は、適切なデータベースバックアップのスキームとの連携では、ジャーナルファイルを管理することです。レプリケーションを使用するかどうかは、これらの選択に影響します。

次のセクションで、詳細にこれらのジャーナリングのトピックを取り上げます。

トランザクションフェンシング(囲い込)

論理的トランザクションのフェンシング(境界)の実行プログラミングは、システムの中断中のデータベースの整合性を保護します。論理トランザクションは、トランザクションのすべての部分が捕らえられていない限り、完全ではない論理単位です。たとえば、論理トランザクション「口座間の送金」は、1つの口座へデビット(借り方)更新と別の口座へのクレジット更新で構成されます。

論理トランザクションの周りに囲い込み(フェンス)を確立することは、トランザクションが1つの単位としてコミットされることを保証し、それにより論理的不一致を防ぎます。これらの論理的不一致は、アプリケーションレベルのデータベース整合性の問題とも呼ばれ、ランタイムエラー、不適切な分岐、誤ったレポートとして現れます。

GT.Mでは、アプリケーションのトランザクション境界を定義する2つの方法があります。1つの方法は、トランザクションコマンドであるTSTARTとTCOMMITを使用しています。他の方法は、GT.MのジャーナルフェンシングのコマンドであるZTSTARTとZTCOMMITを使用します。

TSTARTまたはZTSTARTは、トランザクション フェンス コントロールをアクティブにします。領域にアクセスするすべてと交差するSETs と KILLsに引き続いて、トランザクションに囲まれているものとしてマークされます。TCOMMITまたはZTCOMMITコマンドは、それぞれ、囲まれたトランザクションを閉じ、トランザクションに関係のある全領域の全ジャーナルファイルの中でTCOMMITまたはZTCOMMITによってジャーナルレコードを書き込みます。

もしTSTARTが処理されていたならば、そして、他のTSTARTがTCOMMITより前に検出されていたならば、2番目のTSTARTはジャーナルファイルへ放出される別のフェンスを引き起こしません、その代わりに、$TLEVELとしてアクセス可能なカウンタである "トランザクションの深さ(transaction depth)" を増やします。TCOMMIT命令に引き続いて、このトランザクションの深さ(transaction depth)カウンタの減少が発生します。"トランザクションの深さ(transaction depth)"がゼロ（0）を返す時には、TCOMMITフェンスはジャーナルファイルへ放出されます。（この出来事はネストトランザクションまたはサブトランザクションとして呼ばれます）

  • TPトランザクションのネストの最大深度は127レベルです。

    同様に、もしZTSTARTが処理されていたならば、そして、他のZTSTARTがZTCOMMITより前に検出されていたならば、2番目のZTSTARTはジャーナルファイルへ放出される別のフェンスを引き起こしません。代わりに、2番目のZTSTARTは、"トランザクションの深さ"のカウンタを１つ増やします。ZTCOMMIT命令に引き続いて、このトランザクションの深さ(transaction depth)カウンタの減少が発生します。"トランザクションの深さ(transaction depth)"がゼロ（0）を返す時には、ZTCOMMITフェンスはジャーナルファイルへ放出されます。（この出来事はネストトランザクションまたはサブトランザクションとして呼ばれます）

  • ZTSTARTトランザクションのネストの最大深度は255レベルです。

    数値式(numexpr)がゼロ（0）以上である場所のコマンドZTCOMMIT 数値式(numexpr)は、機能的にコードと同等です：

    X "NEW X F X=1:1:numexpr ZTCOMMIT"

    そして、コマンドZTCOMMIT 0 は、コマンドと等価です：

    ZTCOMMIT $VIEW("JNLTRANSACTION")

    これの本質的な意味は、ZTCOMMIT 0 は、、トランザクションを、および任意および開いているすべてのサブトランザクションを、閉じます。

  • 数値式(numexpr)の負値は、誤りです。

    TSTART/ TCOMMITの場合、トランザクションに関係のあるすべてのフェンスで囲まれてた更新により、ジャーナルレコードは、TCOMMITの時間中にのみ、すべての領域のジャーナルファイルへ書きこまれます。即ち、TCOMMITのそのときだけジャーナルレコードは書かれます。一方、ZTSTART/ ZTCOMMITのケースでは、SETまたはKILLそれぞれがフェンスで囲まれたトランザクション内で発生される時には、ジャーナルレコードとして書きます。

    （一定の規則に従っている時）TSTARTとTCOMMITがACID特性でトランザクションを生成している間、ZTSTARTとZTCOMMITはすべて時にMセマンティクス(意味構文)を変更しません。これらコマンドは、ジャーナルでフェンシング情報だけを生成します。MとZトランザクションコマンドは、単一トランザクションで混在させることはできません。MUPIP ジャーナルは、トランザクションを構成する更新のセット全体を復元するために（ただし、更新の一部のみ復元することを明確に指示されていない限りにおいては、）、TSTARTとTCOMMITまたはZTSTARTとZTCOMMITによって与えられる情報を使用します。

    TSTARTとTCOMMITまたはZTSTARTとZTCOMMITを使用して、ジャーナリングの利便性を大幅に向上します。ジャーナルファイルから復元する時、デフォルトでは、MUPIP JOURNAL -RECOVER処理は、トランザクションフェンス、または、それらのいずれもの中で、すべての更新を回復し、そして、回復中に後者のケースを報告します。

  • MUPIPドキュメントでは、トランザクションの期間とは、"データベースの更新" を意味します。

フェンシング(囲い込)を使用するかどうかを決定する

あなたのアプリケーションプログラムで、いくつか、すべて、なし、のフェンス(囲い込)をできます。フェンス(囲い込)を持ってプログラムする時、、MUPIP JOURNAL -RECOVER のために追加の修飾子を使用して、フェンス(囲い込)を無視するように平然とリカバリを強制できます。以下は、フェンシング トランザクションの利点と欠点のリストです。

フェンシングの利点：

  • より速い復旧

  • 最小のリスクでリカバリ

  • フェンス(囲い込み)を含むジャーナルから回復されたデータベースは、復旧後のチェックや論理的な一貫性のための修復を必要としません

フェンシング短所：

  • Mコードにプログラムをする必要があります。

    もしアプリケーションが論理トランザクションの破損の問題を最小限に抑えるためにすでに構造化されている場合、フェンシング(囲い込み)コマンドを挿入することは大部分は機械的な作業です。あまり構造化されていないアプリケーションでは、トランザクションに関連するMロックのすぐ"内側"にフェンス(囲い込み)を挿入することは、適切なフェンス(囲い込み)の優れた最初の近似を提供することができる。

  • フェンシングは、追加のCPUリソースを必要とし、ジャーナルファイルへのエントリを追加します。

  • フェンシング(囲い込み)は、これらの問題に対処するために既に確立されている回復方法を複製するかもしれません

    各論理トランザクションのすべての情報が単一のグローバルノードに格納されるように構造化されたアプリケーション（他のノードが冗長情報のみを保持している間）は、プログラムを再構築して論理的不一致を完全に修正することを可能にします。制約の少ない設計では、論理的不整合を手動または半自動化技術を使用して修正できます。

フェンシングとロックのトランザクション

LOCKsとZTSTARTとZTCOMMITトランザクションのフェンスは、重要な関係があります。MUPIP JOURNAL -RECOVERは、フェンスで囲まれたトランザクションが分離されることを想定し、そして、カスケードのロールバックを実行はけっしてありません。カスケーディング・ロールバックという用語は、1つのトランザクションを削除すると、すべてのトランザクションが削除されるまで、以前のトランザクションが順次削除される状況を示しています。もしアプリケーションがこの仮定に違反するならば、JOURNAL -RECOVER は、アプリケーションレベルの整合性の問題をもってデータベース作成するでしょう。M LOCKは、他の更新との相互作用から一連の更新を確実に分離します。TSTARTおよびTCOMMITトランザクション・フェンス(囲い込み)は、関連するLOCKの有無にかかわらずフェンス(囲い込み)が使用されるかどうかにかかわらず、必要な分離を暗黙的に示します。

トランザクションに分離されていない例：

Process A                    Process B
---------                    ---------
ZTS
S ^(acct)=^AMT(d,acct)+amt
                             ZTS
                             S ^(acct)=^AMT(d,acct)+amt
                             S (j,^(0))=^JNL(acct,0)+1
                             S ^JNL(acct,j)=stf
                             ZTC
S (j,^(0))=^JNL(acct,0)+1
-- failure --

トランザクションのこれらの2つのセットは、それぞれ他から隔離されていません。システムが失敗する後は、プロセス Aのトランザクションは-RECOVER -BACKWARDによって、削除される必要があり、または、-RECOVER -FORWARDでは、けっして再生されません。ただし、プロセスBのトランザクションが回復される時に、もしacctが両方のプロセスに同じ値を持つ場合は、^AMT(d,acct) はプロセス Aのamtだけでなく、プロセス Bの amt を含みます。

プログラムへ１つのLOCKの追加は、（例えば、L ^JNL(acct)は、ZTSTARTとLOCKの直前で、引数なしで、ZTCOMMIT後で）、トランザクションを分離し、そして、オーバーラップから2つのプロセスを防ぎます。Mはアトミック(原子性)なデータベース操作としてSETコマンドを扱わないので、TSTART/TCOMMITコマンドの欠如で、このようなLOCKsは、^AMT(d,acct)と^JNL(0)への更新を保護するためにジャーナリングの考慮事項の独立して存在する必要があります。

前 上 次
ジャーナリングを使用するかどうかを決定する ホーム ジャーナルファイルの操作
inserted by FC2 system