イントロダクション

いわゆる "ACID" と呼ばれるトランザクション処理システムの4つのキーのプロパティは、原子性(Atomicity:アトミック性),一貫性(Consistency),独立性(Isolation),永続性(Durability))です。GT.Mのトランザクション処理は、TStartおよびTCommitコマンドそしてジャーナリングを介した耐久性によって最初の3つを提供します。

GT.Mのような、すべての高性能データベースのほとんどは、システムクラッシュのような予定外のイベントの後でも、データの整合性を復元しビジネスの継続性を提供するためにジャーナリングを使用します(いくつかのデータベースでは"logging:ロギング"と呼ばれています)。

注意:ジャーナリングは良いシステム構成と設計のための代用物ではありません。たとえば、同じディスクコントローラ上にデータベースとそのジャーナルファイルがある場合、そのコントローラ上のハードウェア障害は、両方のファイルと回復性の予防を破壊することになります。ジャーナリングは、堅牢なシステムを構築するために他の技術を補完します。

ジャーナリングはMのプログラミングが必要です。しかし、この章以降で説明されるGT.Mコマンドは、ジャーナリングの価値を高めるでしょう。

ジャーナルファイル

GT.Mのジャーナリングは、データベースの更新に関係する情報を記録するためにジャーナルファイルを使用します。ジャーナルファイルは、デフォルトで mjl拡張子を持ちます。新しいジャーナルファイル名(FILENAMEオプションまたはデフォルトで指定されたジャーナルファイル名)がすでに存在する場合、GT.Mはジャーナルファイルの作成時刻を表す文字列を "_YYYYJJJHHMMSS"という形式で追加して既存のジャーナルファイルの名前を変更します :

YYYY	4桁の西暦年 半角数字			例えば: 2010 
JJJ	3桁のユリウス日 半角数字(1〜366の間)	例えば: 199 
HH	2桁の時  半角数字  24時間フォーマット	例えば: 14 
MM	2桁の分  半角数字			例えば: 40 
SS	2桁の秒  半角数字			例えば: 30

次のアニメーションは、GT.Mがジャーナルファイルを使用してデータベース更新に関する情報をgtm.dat(gtmprofileによって作成されたデフォルトのデータベースファイル)に記録する方法を示しています。

任意の時点で、データベースファイル(gtm.dat)には、前の( "前世代")ジャーナルファイルへのリンクを持つ単一のアクティブなジャーナルファイル(gtm.mjl)があります。ジャーナルファイル間の黒い矢印は、ジャーナルファイルがgtm.mjl_YYYYJJJHHMMSS形式のファイル名で前のファイルにバックリンクされて、ジャーナルファイルのチェーンを形成する方法を示しています。GT.Mは、そのデータベースのジャーナル・ファイルの名前を持つ新しいジャーナル・ファイルを作成し、新しく作成されたジャーナル・ファイルのヘッダー内の前世代のジャーナル・ファイル名(リネーム後)を指定します。GT.Mジャーナリングは、ジャーナルファイルの永続的な回復/抽出、アクティブなデータベースへのデータベース更新の再生、レプリケーションが使用されているときの以前の一貫性のある状態へデータベース状態の復帰などのメカニズムを提供します。GT.Mは、ジャーナル・ファイルの自動切り替えを試みているプロセスに対して、使用可能なディスク・スペースがないか、または認証されていないなどのランタイム時の条件が発生した場合に、ジャーナリングを自動的にオフにします。GT.Mは、ジャーナル・ファイルの自動切り替えを試みているプロセスに対して、使用可能なディスク・スペースがないか、または、認証されていないなどのランタイム時の条件が発生した場合に、ジャーナリングを自動的にオフにします。そのような場合、GT.Mは適切なメッセージをオペレータログに記録し、運用スタッフに警告します。GT.Mは、リネームロジックが既に存在するファイル名(ジャーナルファイルが同じ秒に切り替わる条件)を生成したことを検出すると、文字列 "_N [N [N [N ...]]]"は名前が変更されたファイル名に追加されます。ここで、"N[N[N...]]"は次のような一連の数字を表します:

0,1,2,3,4,5,6,7,8,9,90,91,92,93,94,95,96,97,98,99,990,991,...

GT.Mは、存在しない変更されたファイル名が見つかるまで、上記の順序ですべての数字を試します。上記の図例では、gtm.mjl_2010227082618が同じ秒で切り替えられ、gtm.mjl_2010227082618_0がすでに存在する場合、名前が変更されたジャーナルファイルは gtm.mjl_2010227082618_1になります。もし上記で説明した既存のファイル名変更スキームまたはデフォルトのジャーナル・ファイル命名スキームが、(接尾辞作成ルールのために)ファイル名が255文字を超える場合、GT.Mはエラーを生成し、ジャーナリングをオフにします。

[注意] 注意

ジャーナルファイルを切り替える直前の非常に短時間のウィンドウで、GT.Mは .mjl_new拡張子を持つテンポラリファイルを作成し、いくつかの初期化ジャーナルレコードを書き込もうとします。初期の検証を実行した後、GT.Mは .mjl_newファイルの名前を現在の.mjlファイルの名前に変更します。ごくまれに、ジャーナルファイルの作成プロセスが途中で中断された場合(おそらくパーミッションまたはディスクスペースの問題のため)、.mjl_newファイルが見ることがあります。後続のMUPIPプロセスで .mjl_newファイルがあることと .mjlファイルが無いことを検出された場合、自動的にそれを削除し新しい.mjlファイルが作成されます。

ジャーナリングをオンにする2つのスイッチがあります。 ENable / DISable と ON/OFF 。ジャーナリングの Enabling または disabling (有効またはを無効)は、データベースへのアクセスとは別に自立(stand alone)している必要があります。ジャーナリングのon と offの切り替えは、データベースが使用されている時に行うことができます。注意:GT.Mは、ジャーナルファイルの自動切り替えを試みているプロセスに対して、使用可能なディスク領域がないか、またはプロセスの認可がないなどの実行時の条件により、ジャーナリングを暗黙的にオフにするときはいつでも、付随するメッセージでエラーを生成し、運用スタッフに警告します。選択したプラットフォーム上のGT.Mは、データベースファイルとジャーナルファイルのデータを暗号化できます。暗号化は、ディスクファイルにアクセスできる権限のないプロセス、つまり暗号化されたデータ(DAR)によるデータへの不正アクセスからデータを保護します。プラグインアーキテクチャは、GT.Mに暗号化を組み込むのではなく、好みの暗号化ソフトウェアの使用を容易にします。詳細は、第12章: “データベースの暗号化を参照してください。

ジャーナルファイルからリカバリ

次の2つの手順では、ジャーナル・ファイルからデータベースを回復できます:

  1. フォワードリカバリ(適用によってロールフォワード)

  2. バックワードリカバリ(チェックポイントへのロールバック、オプションで後続のロールフォワード)

[注意] 注意

マルチサイトのデータベース・レプリケーション構成では、これらのリカバリー手順を使用して、オリジナルのインスタンスのバックアップからレプリケーション・インスタンスを更新することができます。ただし、これらの両方のリカバリー手順のステップは異なります。

フォワードリカバリ

フォワードリカバリは、ジャーナルファイル内の指定されたポイントまで順方向にすべてのデータベース更新を「リプレイ」します。バックアップデータベース上のフォワードリカバリは、バックアップがとられてから開始され、ジャーナルファイルの指定されたポイントまで続きます。空のデータベース上のフォワードリカバリは、ジャーナルファイルの先頭から開始されます。

システムクラッシュが08:50時間に発生し、データベースのバックアップが08:26時間に実行されたとします。フォワードリカバリを使用すると、データベースのバックアップコピーで08:26〜8:50時間(青色)の間にデータベース更新を再生し、クラッシュ前の状態にデータベースを復元することができます。このプロセスでは、クラッシュ時に発生した未完了または破損したトランザクションを特定することもできます。次の図では、Xはクラッシュ・タイムを示し、青色の更新はフォワード処理を示します。

mupip journal -recover -forward -before="--8:50" gtm.mjl のようなコマンドがこの操作を実行します。現在のジャーナル・ファイルから、フォワード・リカバリーは、ジャーナル・ファイルの「開始トランザクション番号」がアクティブ・データベースの「現行トランザクション番号」(バックアップがとられた時点)と一致し、フォワード処理を開始するポイントに戻ります。ジャーナルファイルはその前のバージョンにバックリンクされているため、GT.Mは、リカバリ中にのみ表示されるジャーナルファイル間のテンポラリーなフォワードリンクをアクティブにすることによって、フォワード処理を容易にします。これらのフォワードリンクは、新しいジャーナルファイルが作成されるときに維持するのに費用がかかるため、一時的です。注:フォワード・リカバリーは、設計上、「開始トランザクション」がアクティブ・データベースの「現行トランザクション」と一致するジャーナル・ファイルから始まります。この状態は、バックアップの直後に新しいジャーナルファイルが作成(切り替え)された場合にのみ発生します。データベースがMUPIP BACKUP -NONEWJNLFILES(ジャーナル・ファイルが切り替わらないバックアップ・オプション)でバックアップされている場合、フォワード・リカバリは、開始トランザクションが現行トランザクションと一致するジャーナル・ファイルを見つけることができないため、フォワード・リカバリを続行できません。ジャーナル・ファイルを切り替えたり、バックアップ後にジャーナル・ファイルを明示的に切り替えるバックアップ・オプションを常に使用してください。また、フォワードリカバリを使用してデータベースをリカバリした後は、バックアップからデータベースを再度リストアしない限り、今後のリカバリに使用できなくなります。

バックワードリカバリ

バックワード・リカバリーは、ジャーナル・データベースを以前の状態にリストアします。バックワード処理は、目的の状態になる前にチェックポイント( -SINCE または -AFTER で指定)に更新をロールバックし、目的の状態までデータベース更新を再生することから開始します。

バックワードリカバリでは、 "BEFORE_IMAGE" ジャーナリングが使用されます。BEFORE_IMAGEジャーナリングを使用すると、GT.Mはデータベースの更新だけでなく、更新によって発生した変更の直前にデータベースの一部の「スナップショット」を捕らえます。バックアップデータベース上で動作するフォワードリカバリとは異なり、バックワードリカバリは、使用可能でBEFORE_IMAGEジャーナリングが有効になっていれば、本番(現在)のデータベースでのみ機能します。

システムクラッシュが10時35分に発生したとします。mupip journal recover backward-lookback_limit = "TIME = 0 10:10" -since = " - 10:20" -before = "-10:30" のようなコマンドは、バックワード・リカバリーを実行します。次の図は、10時35分にシステムクラッシュ後にGT.Mがどのようにリカバリを実行するかを示しています。バックワード・リカバリーは、データベースの更新を「un-does」して10時20分に戻します。次に、クラッシュするまでの更新をフォワードに適用します。コマンドに -BEFORE = " - - 10:30" を追加すると、10時30分以降に元々発生した更新が転送処理で検出されると、リカバリは停止します。もしアプリケーションに一連グループのトランザクションを囲む(fence) ZTSTARTコマンドとZTCOMMITコマンドが含まれている場合、10時20分に不完全な囲み済み(fenced)トランザクションを解決するために、10時10分の検索の前にバックワード処理を続行することができます。

-LOOKBACK_LIMITは、追加のバックワード処理の最大量を制御します(この場合は10分です)。この参考例の -SINCE 時間は、グラフ表示のためにわずかに誇張されていることに注意してください。もしアプリケーションにトランザクションを囲う(fence)ためのTSTARTコマンドとTCOMMITコマンドが含まれている場合、TSTART/TCOMMITトランザクションはオープント・ランザクション・フェンス(fence)を自動的に解決するので、バックワード処理にはLOOKBACK_LIMITは必要ありません。したがって、上記の例では、トランザクションがTSTART/TCOMMITで囲われている(fenced)場合、バックワードリカバリは自動的にバックワード処理を10分増加させます。

[重要] 重要

ZTSTARTとZTCOMMITは、TSTARTとCOMMITが好ましいために推奨されなくなりました。FISは、ZTSTART/ZTCOMMITと -LOOPBACK_LIMITはもはや検証しません(ZTSTART/ZTCOMMITに適用されるため)。

ロールバック ファイル(rolled_bak* files)

GT.Mは、バックワード・リカバリーによって内容全体が除去される(ロールバックされる)ジャーナル・ファイルに接頭辞 rolled_bak_ を追加します。GT.Mはリカバリが成功した後でこれらのファイルを使用しないため、移動または削除を検討することをお勧めします。将来のデータベース・リカバリには、rolled_bak *ファイルを使用しないでください。もし rolled_bak* ファイルを処理する必要がある場合は、ジャーナルレコードを抽出し、Mプログラムを使用してそれらを処理する必要があります。後続のロールバックによってロールバックジャーナルファイルを上書きされないようにするために、ロールバック後すぐにロールバックジャーナルファイルの名前を変更し、必要なら保存することをお奨めします。

ジャーナルファイルアクセス認証

GT.Mは、アクセス制限をジャーナルファイル、バックアップ、およびスナップショットのテンポラリファイルに波及します。したがって、一般的に、ジャーナル・ファイルは、対応するデータベース・ファイルと同じアクセス許可の特性を持つ必要があります。まれに、データベースアクセスが制限されているが、所有者がデータベースグループまたは$ gtm_distディレクトリに関連付けられたグループのメンバーでない場合、ジャーナルファイルへのワールド読み書きアクセス(777)を提供する必要があります。オペレーティングシステムがアクセスを許可している限り、GT.Mは、 システムにファイルに利用可能なユーザ情報やグループ情報がない場合に、データベースファイルやジャーナルへのアクセスを許可します。 このような異常な状況は、たとえば、ユーザとグループがNIS経由で提供されている場合に発生する可能性がありますが、NISが現時点で動作していない場合、所有者とグループを特定できません: または、GT.Mプロセスがアクティブな間はおそらくユーザーIDが削除されます。

ジャーナルファイル内のトリガー

GT.Mは、ジャーナリングとレプリケーション中に「トリガ定義」と「トリガ更新」を別々に管理します。トリガー定義は、ジャーナル・ファイルとレプリケーション・ストリームの両方に出現するので、その定義は回復されたデータベースと複製されたデータベースに波及します。MUPIP JOURNAL -RECOVER/-ROLLBACK は、トリガ起動しないため、トリガされた更新はジャーナルファイルに出現します。ただし、レプリケーション・インスタンス上の更新プロセスでトリガが適用され、そのロジックが処理されるため、レプリケーション・ストリームには現れません。

GT.Mは、Mトランザクションとしてトリガーを暗黙的にラップします。したがって、トリガーを使用しているデータベースのジャーナル抽出ファイルは、トリガーが更新を実行しない場合(つまり、No-op(なにもしない)と同じ効果であっても)常にタイプ8およびタイプ9(TSTART / TCOMMIT)レコードを持ちます。

ジャーナリングがオンの場合、GT.Mはトリガロジックによって実行されるデータベース更新のジャーナルレコードを生成します。明示的なデータベース更新の場合、ジャーナル・レコードは、その更新の一部としてトリガーが呼び出されたかどうかを指定します。GT.Mトリガーは、BEFORE IMAGEのジャーナル・レコードの生成および使用とロールバック/リカバリーのバックワードフェーズに影響を与えません。ジャーナルされた領域(Region)内のグローバルに関連付けられたトリガーは、ジャーナルされていない領域(Region)で更新を実行できます。ただし、複数の領域(Region)のトリガーが非ジャーナル領域(Region)リージョン内の同じノードを同時に更新する場合、リカバリーまたはロールバックの再生順序が、オリジナルの更新の再生順序と異なる可能性があり、そして異なる結果が生じる可能性があります; したがって、このプラクティスでは、慎重な分析と実装が必要です。デバッグにトリガを使用する場合を除いて、FISはトリガを使用する領域(Region)をすべてジャーナリングすることを推奨します。もしデータベースでトリガーを使用する場合は、非ジャーナル・グローバルがジャーナル・グローバル内でトリガー更新を実行しないようにし、壊れた/失われたトランザクション・ファイル内のトリガー更新を処理するプロシージャを作成することを常に保障してください。壊れたり失われたトランザクションファイルでは、これらのエントリを + または - として識別し、MUPIP TRIGGER および $ ZTRIGGER()を使用してこれらのエントリを適切に処理できます。

BEFORE_IMAGE ジャーナリング

BEFORE_IMAGEは、各データベース更新の前に「ミニバックアップ」を作成するジャーナリングの一形式です。バックワードリカバリでは、これらのミニバックアップを使用してデータベースを元どおりに復元し、その後データベースの再生を行います。「BEFORE_IMAGE」ジャーナリングでは、Mレベル(またはNOBEFORE)のジャーナリングよりも多くのディスクI/Oとストレージスペースが必要ですが、システム障害からの復旧時間が短縮されます。

[注意] 注意

GDEの章で述べたように、MMデータベースのアクセス方法はBGバッファプールをバイパスし、メモリとディスク間のトラフィックを管理するためにオペレーティング/ファイルシステム全体に依存します。MMでは、GT.Mはディスク更新のタイミングを制御できないため、BEFORE_IMAGEジャーナリングはMMのオプションではありません。 これらの2つの機能を一緒に使用しようとすると、エラーが発生します。

NOBEFORE_IMAGE ジャーナリング

「NOBEFORE_IMAGE」は、各データベースの更新をジャーナル・ファイルに順次格納するMレベルのジャーナリングの一形式です。フォワード・リカバリー操作では、これらのデータベース更新を再生してデータベースをリストアします。「NOBEFORE_IMAGE」は通常の使用ではI/O帯域幅を消費せず、使用可能なサーバーからより多くのスループットを得るのに役立ちます。

BEFORE_IMAGE と NOBEFORE_IMAGE のどちらかを選択

BEFORE_IMAGEジャーナリングとNOBEFORE_IMAGEジャーナリングの選択は、特に論理的なマルチサイトデータベースレプリケーションの展開において重要です。もしアプリケーションが実行されているサーバのI/O帯域幅をプッシュすると、NOBEFORE_IMAGEジャーナリングは使用可能なサーバからより多くのスループットを得るのに役立ちます。BEFORE_IMAGEジャーナリングは、もしクラッシュの可能性の低いイベントでアプリケーションがより迅速に回復する必要がある場合には、おそらく選択肢となります。ジャーナリングのタイプの選択に関する包括的な説明は、“BEFORE_IMAGEとNOBEFORE_IMAGEジャーナリングの選択”.を参照してください。

壊れたトランザクションファイル

致命的なイベントの場合、GT.Mがファイルへのすべてのジャーナルレコードの書き込みを適切に完了することは、ほとんどありません。GT.Mは、未完了のレコードまたは不完全に囲われた(fenced)トランザクションを「壊れたトランザクション」として報告します。 GT.Mは、破損したトランザクションを「破損したトランザクションファイル」と呼ばれるファイルに抽出します。

失われたトランザクションファイル

壊れたトランザクションの後に発生する完全なトランザクションは、失われたトランザクションです。GT.Mはそれをデータベースには再生しませんが、失われたトランザクションとして「失われたトランザクションファイル」と呼ばれるファイルに抽出します。

破損したトランザクションと失われたトランザクションはすべて、データベースリカバリの結果として使用可能になります。

操作手順とアプリケーションツールは、破損と失われたトランザクションファイル内の情報を、これらのファイルにコンテンツを配置するリカバリまたはロールバックの後に、回復および再処理する手段を提供する必要があります。

もし囲い込み(fence)がない場合は、アプリケーションレベルの完全性の問題を修復します。どちらの場合でも、MUPIP INTEG -FAST は、データベースが相対的な安全性を備えた新しい更新をサポートできるかどうかの優れた迅速なテストを提供します。

ジャーナリングの利点

データベースでジャーナルを有効にする前に、ジャーナリングの利点を理解することが重要です。Mデータベース管理は、同じ情報(または順序付けられた順序での「近傍」情報)の複数の同時更新および取得が予測可能で論理的な方法で行われることを、保障します。時には、データベース・マネージャーは、単一の更新の結果として、複数のレコード、通常は索引を、変更する必要があります。このような「マルチポイント」更新を実行しているプロセスの中断は、M実装の設計上の前提条件に違反し、不正な形式のデータベースを生じさせます。通常の操作では、データベースロジックは、更新が完了するまでそれら認識を延期することによって中断を処理します。しかし、停電やKILL-9などの事態は、そのような中断を引き起こす可能性があります。GT.Mジャーナリングは、そのような中断の場合にデータの整合性とビジネスの継続性を維持するのに役立ちます。

その他の利点には、次のものが含まれます(ただしこれに限定されません):

  • ジャーナル・ファイルに記録された最後にコミットされた更新への作業の自動再生。トランザクション処理とジャーナリングを使用すると、GT.Mは完全なACIDプロパティを提供することに、注意してください。

  • 障害の直前に記録された情報だけの処理のようなクイックリカバリオプション。たとえば、ジャーナルファイル全体を再生する代わりの作業として、ちょうど最後の瞬間を回復することができます。

  • Mプログラムによる処理のために適切にフォーマットされた記録されたデータベース更新とえば、MUPIP JOURNAL-EXTRACTは、time、user、プロセス識別番号、グローバル変数、プロセス名、およびトランザクション・タイプで指定されたレコードを生成します。

  • システム障害時にアクティブなプロセスの識別-SHOWは、これらのプロセス、および完了していないトランザクション、およびジャーナル・ファイルに含まれるデータベース更新およびプロセスに関するその他の情報を識別します。

ジャーナルファイルのバックアップ

FISでは、データベースファイルとジャーナルファイルのバックアップスキームを別々にすることを推奨しています。MUPIP BACKUPは、データベースのバックアップコピーを作成します。ジャーナルファイルは個別にバックアップする必要があります。

MUPIP BACKUPは、-BKUPDBJNL と -NEWJNLFILES パラメータを使用することで、ジャーナル・ファイルに影響を及ぼします。「一般的なデータベース管理」の章で説明したように、BKUPDBJNLはバックアップ・データベースのジャーナリング特性を有効または無効にし、NEWJNLFILESはバックアップ対象のデータベースのジャーナリング特性を設定します。次の図は、MUPIP BACKUP -NEWJNLFILES=NOPREVLINKが、新しく作成されたジャーナル・ファイルと以前の世代のジャーナル・ファイルとの間のバック・リンクをどのように切断するかを示しています。

-NEWJNLFILES=NOPREVLINKは新しく作成されたジャーナル・ファイルのバック・リンクを切断するため、後続のリカバリまたはロールバックはこの不連続を過ぎて戻ることはできません。

[注意] 注意

MUPIP SETがジャーナル状態をDISABLEDまたはOFFからONに変更すると、GT.Mは、上の例と同様にデータベースの新しいジャーナリング開始を示す、バック・リンクのない新しいジャーナルファイルを作成します。

ジャーナリングするデータベースファイルを選択

完全性を心配しているならば、データベースをジャーナルする必要があります。逆に、システムクラッシュのような不都合なイベントが万が一発生した場合に、削除するために準備ができているデータベースをジャーナルする必要はありません。

ジャーナリングのデータベースファイルを選択する前に、FISは次の点を検討することを推奨します。

  • 保存する価値のあるデータを常にジャーナリングする: データベースファイルの一部または全部をジャーナリングすることができます。 すぐに理解できる、ジャーナリングのためのデータベースファイルの選択方法は、以下のとおりです:

    • システムクラッシュのような不都合なイベントが万が一発生した場合に、削除するために準備ができているデータベースをジャーナリングしないでください。テンポラリ・データをジャーナリングしないでください。

    • 本当に、静的ではジャーナリングを必要としませんが、ジャーナリングされた領域(Region)で保持される時は、ジャーナルの影響はまったく受けません。

    • ジャーナリングを必要としない別のデータベースファイルにテンポラリな情報を移動します。グローバルにプロセス・ローカル(テンポラリ)情報または可能であれば静的情報が含まれている場合は、それらを1つ以上の別個のデータベースファイルに移動し、他の手段(MUPIP CREATEまたはMUPIP BACKUPなど)を使用してそれら領域(Region)内の情報を管理します。

  • トランザクションの手作業の再エントリ(re-entry)と自動再実行(re-play)に関連するデルタ(差異)を評価: 障害からの復旧に関連するオーバーヘッドコストの大部分は、通常、手動復旧のための準備状態を維持し、リカバリーの比較的まれでかつ「異常な」処理中の組織への潜在的なリスクによる情報の損傷から派生します。したがって、コンピュータのスループットの低下のコストや代替の追加ハードウェアのコストを常に考慮して、同じレベルのパフォーマンスでジャーナリングをサポートし、手作業による再エントリ(re-entry)が長引く可能性が低くなります。

  • 頻繁に更新されるグローバルとまれに更新されるグローバルの両方のジャーナル: 更新頻度の高いグローバルのみをジャーナルすることができます。ただし、まれに変更されたグローバルが負荷をほとんど発生させず、ジャーナル化されていないと制御上の問題が発生する可能性があるため、アプリケーションの整合性を維持するためにこれらのグローバルをジャーナリングする必要があります。

  • 障害の箇所を切り分け: ジャーナルと関連するデータベースファイルには、異なるディスクと異なるディスクコントローラ(可能ならば)を常に使用します。

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

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

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

4つのACIDプロパティは、原子性(Atomicity:アトミック性),一貫性(Consistency),独立性(Isolation),永続性(Durability))です。GT.Mは、TSTARTコマンドとTCOMMITコマンドを使用して、ジャーナリングと原子性(Atomicity:アトミック性),一貫性(Consistency),独立性(Isolation)を備えた永続性(Durability)を提供します。TSTARTコマンドとTCOMMITコマンドは、ZTSTARTコマンドとZTCOMMITコマンドの置き換えです。次の表は、それらアプリケーション・トランザクション・フェンシング(囲い込み)の要件があるTSTART/TCOMMITコマンドとZTSTART/ZTCOMMITコマンドの各セットの利点と欠点を示しています。

TSTART/TCOMMIT

ZTSTART/ZTCOMMIT

完全にACIDに準拠したトランザクション管理機能を提供します。

リカバリの質を向上させるためのジャーナル強化を提供します。ZTSTART/ZTCOMMITでは、プログラミングロジック(通常LOCKプロトコル)は,一貫性(Consistency)と独立性(Isolation)を保証する必要があります。

すべての更新は、TCOMMITまで非公開です。これにより、原子性(Atomicity:アトミック性)が保証されます。

ジャーナル・リカバリ時にのみ、アトミック性は保証されます(操作上設定されたパラメータ内で)

カスケード・ロールバックはありません

長期実行トランザクションは、カスケード・ロールバックをトリガーできます。

TS[TART][:tvexpr] [([lvn...])|lvn|*|]|[:keyword|(keyword...)]

TSTARTは再起動時にローカル変数の状態を管理できます。

ZTS[TART][:tvexpr]

TSTARTとTCOMMITの「ネスト」トランザクションの深さは127です。

ZTSTARTとZTCOMMITの「ネスト」トランザクションの深さは25です。

[重要] 重要

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

TSTART/TCOMMITの詳細については、 GT.Mプログラマーズガイドの「コマンド」の章を参照してください。

[注意] 注意

この章の冒頭で述べたように、ZTSTARTとTZTCOMMITはTSTARTとTCOMMITのために推奨されなくなりました。FISはもはやZTSTARTとZTCOMMITの機能を検証しないので、トランザクションをフェンスするためにTSTARTとTCOMMITを常に使用する必要があります。

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

いくつかの、すべての、あるいは全くないアプリケーション・プログラムをフェンス(囲い込み)するかもしれません。フェンスでプログラムするときは、MUPIP JOURNAL-RECOVERに追加の修飾子を使用することによって、フェンスを無視するように強制的に回復することができます。以下は、フェンシング トランザクションの利点と欠点のリストです。

フェンシング(囲い込み)の利点

  • より速い復旧

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

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

注意:START/COMMITのペアは、フェンシング(囲い込み)の好ましい方法です; このアプローチの利点については、GT.Mプログラマーズガイド の「トランザクション処理」の節を参照してください。

フェンシングの短所

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

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

  • フェンシング(囲い込み)は、ジャーナルファイルにいくつかのエントリを追加します。

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

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

VIEW キーワード

GT.Mは、VIEWコマンドへの引数として、JNLFLUSHとJNLWAITキーワードを提供します。通常の操作は、ジャーナリングを制御するためVIEWコマンドは必要ありません。ただし、デバッグなどのような特別の事情の下、ジャーナルキーワードをもつVIEWコマンドは、GT.Mがジャーナルファイルへすべてのその更新を転送することを確保するために、Mプログラムを許可します。

VIEW "JNLFLUSH": 領域がメモリからディスクへ与えられた領域のためにすべてのバッファされたジャーナルレコードの完全な転送を開始します。通常、ディスクへのジャーナルバッファの転送が自動的に起こります。転送は、空き場所の要件によって、新しいジャーナルレコードを、あるいは/または、最終更新からの時間の経過を、保持するためにトリガされます。VIEW "JNLFLUSH" (指定された領域なしに)は、現在のグローバルディレクトリ内のすべての領域をフラッシュします。

すべての地域でプロセスによってすべての更新が開始されるまで、プロセスの実行を停止するためにGT.Mを引き起こすVIEW "JNLWAIT" は、ジャーナルファイル(ディスク上)へ転送されています。通常の振る舞いは、あたかも、それらの最終TCOMMITで暗黙的VIEW "JNLWAIT" を含めたように、Mトランザクション内で更新します。TRANSACTION ID="BATCH" または "BA" をもつトランザクションは、暗黙の"JNLWAIT"から除外されます。通常、Mトランザクションの外で更新のためのプロセス実行は、非同期的にディスクへのジャーナルレコードの転送を続行します。

VIEWコマンドの詳細については、GT.Mプログラマーズガイドの"コマンド"の章を参照してください。

$VIEW() キーワード

GT.Mは、$VIEW関数への引数として、JNLACTIVE, JNLFILE, REGION, JNLTRANSACTIONキーワードを提供します。通常の操作は、ジャーナリングの状態を調べるため $VIEW()は必要ありません。ただし、論理的トランザクションの設計と実装をデバッグする間のような特定の状況の下では、$VIEW() は便利なツールを提供することがあります。

$VIEW("JNLACTIVE", region)は、領域にゼロ(0)を示すジャーナリングは無効で、1(1)を示すジャーナリングはOFFでなく有効で、また、2(2)を示すジャーナリングが有効でかつ領域名がON、を返します。

$VIEW("JNLFILE", region) は、ジャーナルファイルの名前を返します。ジャーナルファイル名が確立されていない場合は、それはnull文字列を返します。そうでなければ、それは完全に移されたファイル名です。

exprがgvnに評価した$VIEW("REGION", expr) は、gvnに名付けられ関連付けられた領域の名前を返します。構成に依存しない方法でジャーナリング状態を取得するために、このパラメータは上記の2つのパラメータ(JNLACTIVE&JNLFILE)を結合して使用されることがあります。

$VIEW("JNLTRANSACTION") は、発行されているZTSTARTsの数とZTCOMMITsの数との間の差を返します。もし進行中の囲まれたトランザクションがない場合は、0(ゼロ)が返されます。これは、TSTARTとTCOMMITを使用するトランザクションのため$TLEVELへ類似の機能を提供します。

$VIEW()の詳細については、GT.Mプログラマーズガイド の"関数"の章を参照してください。

inserted by FC2 system