コミット確認の実装(SNAのみ)

5.1 コミット確認の概要

ノート:

commit-confirmを実装する場合は、すでにコンポーネントを構成している必要があります。使用しているプラットフォームに応じて、「Oracle Database Gateway for APPCインストレーションおよび構成ガイドfor IBM AIX on POWER Systems (64-Bit), Linux x86-64, Oracle Solaris on SPARC (64-Bit), and HP-UX Itanium」の第12章または「Oracle Database Gateway for APPCインストレーションおよび構成ガイドfor Microsoft Windows」の第9章の構成手順を参照してください。

コミット確認は、2フェーズ・コミットの特別な実装であり、2フェーズ・コミット全体をサポートしていないデータベースまたはゲートウェイが、2フェーズ・コミット全体をサポートする他のデータベースまたはゲートウェイとの分散更新トランザクションに参加できるようにします。この実装では、ほかのすべてのサイトが準備されたあとに、コミット確認サイトが常に最初にコミットされます。これにより、コミット確認サイトが正常にコミットされないと、他のすべてのサイトをロールバックできるため、すべてのサイトの同期を維持できます。

Oracle分散トランザクション内では、そのトランザクションに関連付けられたすべての作業に、 Oracle Global Transaction IDと呼ばれる共通識別子が割り当てられます。この識別子は、特定の分散トランザクションを排他的に識別するために使用できるように、一意であることが保証されます。コミット確認サポートの主な要件は、コミット確認サイト(この場合はOracle Database Gateway for APPC)がOracle Global Transaction IDをその一部としてログに記録できることです。作業単位。障害が発生した場合、ゲートウェイのリカバリ処理は、そのトランザクションのログ・エントリの有無によって、特定のOracle Global Transaction IDのステータスを判別できます。新しいOracleグローバル・トランザクションIDは、すべてのコミットまたはロールバック操作後に生成されます。

Oracle Database Gateway for APPCは、LU6.2 SYNCLEVEL 1を使用してcommit-confirmを実装します。これは単一サイト更新の実装と似ていますが、ゲートウェイによってアクセスされるOracleサイトと OLTPの両方のリソースを更新して同期できるという利点が追加されています。主な違いは、コミット確認の実装では、リカバリ・サポートに必要なトランザクション・ロギングを実行するためにOLTPトランザクションに追加のプログラミングが必要であることです。

5.2 サポートされているOLTP

commit-confirmはLU6.2 SYNCLEVEL 1を使用するため、CICS Transaction Server for z/OSやIMS/TMなど、APPCをサポートするOLTPでサポートできます。 Oracle Database Gateway for APPCには、CICS Transaction Server for z/OSとIMS/TMの両方のコミット確認アプリケーションのサンプルが用意されています。

CICS Transaction Server for z/OSでは、標準のコマンド・レベルのEXEC CICSインタフェースをすべてのAPPC通信に使用できます。また、CPI-Cインタフェースを使用することもできます。ゲートウェイには、EXEC CICSインタフェースを使用してCOBOLで記述されたサンプルのDB2更新トランザクションが用意されています。 CICS Transaction Server for z/OSでサポートされている言語は、コミット確認トランザクションの書込みに使用できます。

IMS/TMでは、CPI-Cインタフェースを使用し、IMSトランザクションを「明示的なAPPCトランザクション」にする必要があります(IBM IMSCICS Transaction Server for z/OSのマニュアルを参照)。これは、LU6.2 SYNCLEVEL 1制御フローがIMSトランザクションからアクセスできる唯一の方法であるため必要です。 IOPCBからの「GU」とIOPCBへの「ISRT」がデータの受信および送信に使用される「暗黙的APPC」を使用する場合、IMSトランザクションがLU6.2 SYNCLEVEL 1制御フローにアクセスする方法がなく、このメソッドをコミット確認に使用することはできません。 CPI-C APPCインタフェースを使用してCOBOLで記述されたサンプルのDLIデータベース更新トランザクションが、ゲートウェイとともに提供されます。 IMSおよびCPI-Cでサポートされているどの言語でも、コミット確認トランザクションの書き込みに使用できます。

5.3 コミット確認のサポートに必要なコンポーネント

コミット確認をサポートするには、次のコンポーネントが必要です:

Oracle Database Gateway for APPCサーバー

ゲートウェイ・サーバーは、ゲートウェイ初期化ファイルでPGA_CAPABILITY=COMMIT_CONFIRMが指定されている場合、コミット確認をサポートします。コミット確認を有効にしてゲートウェイ・サーバーを実行している場合、DBA_2PC_PENDING表に格納されているOracleの2フェーズ・コミット・ログと同様に、コミット確認トランザクション・ログを保持するローカルOracleデータベースに接続します。ゲートウェイのトランザクション・ログは、PGA_CC_PENDING表に格納されます。処理中のトランザクションごとに、この表に行が保存され、トランザクションが完了するまでそのまま残ります。通常、PGA_CC_PENDINGの行の存続期間はかなり短く、コミットがゲートウェイによって受信された時間からOracleデータベースですべてのコミット処理が完了し、ゲートウェイにトランザクションを忘れるように指示する時間まで続きます。

commit-confirmゲートウェイSIDは、commit-confirmを実装する更新トランザクションを呼び出すためにのみ使用するために予約する必要があります。 PGA_CAPABILITYがCOMMIT_CONFIRMに設定されている場合、ロギングの設定には追加のオーバーヘッドが伴います。読取り専用トランザクションは、PGA_CAPABILITYがREAD_ONLYに設定された個別のゲートウェイSIDを介して起動し、追加のオーバーヘッドが発生しないようにする必要があります。
ロギング・サーバー

Oracleデータベースは、PGA_CC_PENDING表を格納するためにゲートウェイ・サーバーが使用できる必要があります。パフォーマンスと信頼性を最大限に高めるために、Oracleでは、このOracleデータベースをゲートウェイ・サーバーと同じシステム上に配置することをお薦めします。
OLTPコミット-トランザクション・ログの確認

コミット確認トランザクション・ログ・データベースは、アクセスするOLTPシステムに対して定義する必要があります。このデータベースはリカバリ可能である必要があり、OLTPアプリケーションのデータベースと同じ作業単位の一部としてOLTPからアクセス可能である必要があります。これにより、トランザクション・ログ・データベースに対する更新が、1つの作業単位でアプリケーションのデータベースに対する更新と同期されます。

コミット確認トランザクション・ログ・データベースには、 Oracle Global Transaction IDおよび日時スタンプのみを含める必要があります。 Oracleグローバル・トランザクションIDの長さは169バイトで、キー・フィールドである必要があります。日付/タイムスタンプは、特定の障害シナリオの後にログに残すことができる古いエントリをパージするために使用されます。

簡略化するために、特定のOLTPの下にあるすべてのコミット確認アプリケーションは、同じコミット確認トランザクション・ログを共有する必要があります。
OLTPトランザクション・ロギング・コード

ゲートウェイのコミット確認の実装に必要なトランザクション・ロギングを実行するには、コミット確認ゲートウェイによって起動される各OLTPトランザクションにコードを追加する必要があります。このコードは、ゲートウェイからOracleグローバル・トランザクションIDを受け取り、その情報をOLTPコミット確認トランザクション・ログ・データベースに書き込む必要があります。最大限の柔軟性と使いやすさを実現するために、このコードは、OLTPシステム上のコミット確認トランザクションからコール可能なサブルーチンとして記述できます。

このコードは、最初のAPPC受信の前に各コミット確認トランザクションの最初に実行し、トランザクション内の各COMMITまたはROLLBACKの直後に実行する必要があります。これにより、各作業単位の開始時にロギングが行われます。
OLTP忘却/リカバリ・トランザクション

正常にコミットされたトランザクションを忘れたり、リカバリ処理中にトランザクションの状態を問い合せたりするために、ゲートウェイによって起動できるOLTPシステムに個別のAPPCトランザクションを作成する必要があります。このトランザクションは、忘れた処理中にOLTPコミット確認トランザクション・ログ・データベースから特定のOracleグローバル・トランザクションIDのエントリを削除し、リカバリ処理中にOLTPコミット確認トランザクション・ログ・データベースから特定のOracleグローバル・トランザクションIDのエントリを問い合せます。

ノート:

プラットフォームに応じて、「Oracle Database Gateway for APPCインストレーションおよび構成ガイドfor IBM AIX on POWER Systems (64-Bit), Linux x86-64, Oracle Solaris on SPARC (64-Bit), and HP-UX Itanium」の第11章または「Oracle Database Gateway for APPCインストレーションおよび構成ガイドfor Microsoft Windows」の第8章の説明に従って、ゲートウェイ初期化パラメータおよびOLTPパラメータが適切に構成されていることを確認してください。

5.4 アプリケーション設計の要件

Oracle Database Gateway for APPCで使用するコミット確認アプリケーションを設計する場合、障害が発生した場合にゲートウェイがトランザクションの状態を判別できるようにするために満たす必要がある要件がいくつかあります。これらの要件が満たされていない場合、コミット確認ゲートウェイでアプリケーションを使用しようとすると、予期しない結果になります。

コミット確認ゲートウェイによって起動されるOLTPトランザクションによって最初に実行する必要があるのは、ゲートウェイからO racleグローバル・トランザクションIDを受信し、それをOLTPコミット確認トランザクション・ログ・データベースにログインすることです。これは、OLTPトランザクションとOracleアプリケーションの間の通常のデータ・フローを開始する前に行う必要があります。ゲートウェイは常に、最初のデータ・アイテムとしてOracle Global Transaction IDを送信します。

OLTPトランザクションがワン・ショット・トランザクションの場合、これが唯一必要な変更です。トランザクションが、複数の作業単位(複数のコミットまたはロールバックを発行)を実行する永続トランザクションである場合、COMMITまたはROLLBACKのたびに新しいOracleグローバル・トランザクションIDを受信してログに記録する必要があります。

Oracleグローバル・トランザクションIDは、ゲートウェイによって、最大長が202バイトの可変長レコードで送信されます。最初の32バイトには、データが他のアプリケーションからではなくゲートウェイから送信されたことを確認するために使用される特別なバイナリ文字列が含まれています。次の1バイトは予約フィールドです。 Oracleグローバル・トランザクションIDは次に、最大長は169バイトです。予約済フィールドとOracle Global Transaction ID、日付/タイムスタンプ、およびログに記録するその他の情報を記録する必要があります。忘却/リカバリ・トランザクションがOracleグローバル・トランザクションIDを使用してログ・エントリに直接アクセスできるように、Oracleグローバル・トランザクションIDはログ・データベースのキー・フィールドである必要があります。

ノート:

OLTPがIMS/TMの場合は、コミット確認ゲートウェイで使用するトランザクションごとに、コミット確認トランザクション・ログ・データベースのPCBをPSBに追加する必要があります。このPCBは、PSBの最初のPCBである必要があります。

5.5 コミット確認アーキテクチャ

Oracle Database Gateway for APPCでのcommit-confirm実装のアーキテクチャは、次の3つの主要コンポーネントで構成されます:

Oracleデータベース
Oracle Database Gateway for APPCサーバー(ゲートウェイ・サーバー)
ロギング・サーバー(表PGA_CC_PENDINGおよびPGA_CC_LOGを保持するOracleデータベース)

この項では、各コンポーネントがコミット確認の操作で果たすロールと、これらのコンポーネントの相互作用について説明します。

5.5.1 コンポーネント

Oracleデータベースは、コミット確認アーキテクチャの制御コンポーネントです。これは、トランザクションをコミットするタイミングとトランザクションをロールバックするタイミングをゲートウェイ・サーバーに指示します。これは、分散トランザクションに参加している他のすべてのサーバーについても同様です。障害の発生時には、統合サーバーとして機能するOracleデータベースであり、ゲートウェイ・サーバーを含む各参加サーバーのリカバリ・プロセスを駆動します。

ゲートウェイ・サーバーは、指示をOracleデータベースからLU6.2操作に変換し、トランザクションをロギング・サーバーに記録するタスクを実行します。ゲートウェイ・サーバーは、ログ情報をロギング・サーバー上のPGA_CC_PENDINGという表に格納します。トランザクション処理中に障害が発生した場合、ゲートウェイ・サーバーは、どのエラーをOracleデータベースに返すかを決定します。

ロギング・サーバーは、コミット確認ログ情報を格納およびアクセスするために、ゲートウェイのサーバーで使用可能なOracleデータベースです。ロギング・サーバーは、統合サーバーとして機能するOracleデータベースと同じである必要はありません。ロギング・サーバーはゲートウェイのコミット確認操作の不可欠なコンポーネントであるため、そのサーバーが存在するのに最適な場所はゲートウェイ・サーバーと同じシステムです。これにより、ゲートウェイ・サーバーとロギング・サーバー間の通信でプロセス間通信を使用できるようになり、コンポーネント間の高速で低オーバーヘッドのローカル接続が提供されます。

5.5.2 相互作用

コンポーネント間で発生する特定の相互作用セットがあります。これらを次に示します。

Oracle Database <-->ゲートウェイ・サーバー

Oracleデータベースは、ゲートウェイ・サーバーによるすべてのアクションを駆動します。 Oracleアプリケーションのリクエスト時に、統合サーバーはゲートウェイ・サーバーに、新しいOracleトランザクションの開始、コミット順序の開始、ロールバック順序の開始または忘却順序の開始を指示できます。また、Oracleアプリケーションにかわってゲートウェイ・リモート・プロシージャ・コール(RPC)関数( PGAINIT, PGAXFER, PGATERM)をコールすることもできます。
Gateway Server <-->ロギング・サーバー

ゲートウェイ・サーバーは、ロギング・サーバーをコールして、そのPGA_CC_PENDING表に行を挿入および削除します。これは実際には、ロギング・サーバーで PL/SQLストアド・プロシージャPGA_CC_LOGをコールして、そのロギングを実行するためにゲートウェイ・サーバーで必要なオープン・カーソルの数を減らします。ゲートウェイ・サーバーでロギングに必要なカーソルは1つのみです。

5.6 コミット確認フロー

Oracleアプリケーションと OLTPトランザクション間のコミットを成功させるための制御フローについては、次の項で説明し、「図5-1」を参照してください。この図は、OracleリソースとOLTPリソースの両方が更新されていることを前提としています。「コミット-ロジックの確認Flow_ステップ・バイ・ステップ」の次のステップでは、コミット確認ロジック・フローの概要を示します。

5.6.1 コミット-ロジック・フローの確認、ステップ・バイ・ステップ

アプリケーションは、OracleデータベースにCOMMITを発行します。
Oracleデータベースは、ゲートウェイ以外の分散トランザクションの各参加者にPREPAREを送信します。
各参加者は、データベースの更新を準備し、PREPARE OKをOracleデータベースに応答します。
Oracleデータベースは、COMMITをゲートウェイに送信します。ゲートウェイは、OracleデータベースからCOMMITを受信し、新しい保留中のトランザクション行をPGA_CC_PENDING表に挿入します。
ゲートウェイは、APPC CONFIRMをOLTPアプリケーションに送信します。 OLTPアプリケーションは、最後のAPPC RECEIVEからのステータスの形式でCONFIRMリクエストを受信します。
OLTPアプリケーションは、適切なOLTP関数を使用してCOMMITを発行します。 OLTPは、コミット確認トランザクション・ログ更新を含む、最後のCOMMIT以降にアプリケーションによって行われたすべてのデータベース更新をコミットします。
データベースの更新がコミットされると、OLTPは、COMMITのステータスを示すリターン・コードで制御をアプリケーションに返します。
OLTPアプリケーションは、APPC CONFIRMEDをゲートウェイに送信します。
ゲートウェイはCONFIRMEDを受け取り、COMMIT OKをOracleデータベースに戻します。
Oracleデータベースは、ゲートウェイ以外の分散トランザクションの各参加者にCOMMITを送信します。
各参加者は、データベースの更新をコミットし、COMMIT OKをOracleデータベースに応答します。
Oracleデータベースは、FORGETをゲートウェイに送信します。
ゲートウェイは、FORGETを受信し、OLTPでFORGET/RECOVERYトランザクションとの新しいAPPC対話を開始し、FORGETリクエストとAPPC CONFIRMを送信します。 FORGET/RECOVERYトランザクションは、FORGETリクエストを受信し、現在のOracleトランザクションのコミット確認トランザクション・ログからエントリを削除して、削除をコミットします。
FORGET/RECOVERYトランザクションは、APPC CONFIRMEDをゲートウェイに送信して、FORGETが処理されたことを示してから終了します。ゲートウェイは、CONFIRMEDを受信し、PGA_CC_PENDING表から保留中のトランザクション行を削除します。
ゲートウェイは、FORGET OKをOracleデータベースに戻します。
Oracleデータベースは、Oracleアプリケーションに制御を戻します。

「図5-1」は、前の項で説明したコミット-確認ロジック・フローを示しています。

図5-1 Synclevel 1を使用したコミット確認フロー

図5-1 Synclevel 1を使用したコミット確認フロー」の説明

5.6.2 Gateway Serverコミット-トランザクション・ログの確認

コミット確認トランザクション・ログは、単一の表 PGA_CC_PENDINGで構成されます。この表には、コミット確認ゲートウェイを含む処理中の各Oracleトランザクションの行が含まれます。表は、ゲートウェイ・サーバーによって保持され、OracleデータベースのDBA_2PC_PENDING表と機能的に似ています。ゲートウェイによってCOMMITが受信され、ゲートウェイによってFORGETが受信されると行が削除されるまで、この表に行が挿入されないことに注意してください。 PREPAREフェーズでは、ゲートウェイによる関与はありません。

PGA_CC_PENDING表には、次の列が含まれます:

GLOBAL_TRAN_ID

これは、トランザクションの Oracle Global Transaction IDです。これは、DBA_2PC_PENDING表の対応する列と同じです。
SIDE_NAME

これは、ゲートウェイがターゲットLUとのAPPC会話を割り当てるために使用したサイド情報プロファイル名です。これは、PGAINITゲートウェイ関数に渡されるSIDENAMEパラメータに対応します。
LU_NAME

これは、ターゲットLUの完全修飾パートナLU名です。この値は、サイド情報プロファイルのLU名、またはPGAINITゲートウェイ関数に渡されるLUNAMEパラメータのいずれかです。この名前は、トランザクションが実行されたOLTPシステムを完全に識別します。
MODE_NAME

これは、ゲートウェイがターゲットLUとのAPPC対話を割り当てるために使用したモード名です。値は、サイド情報プロファイルのモード名、またはPGAINITゲートウェイ関数に渡されるMODENAMEパラメータのいずれかです。
TP_NAME

これは、ターゲットLUで実行されるトランザクション・プログラム名です。値は、サイド情報プロファイルのTP名、またはPGAINITゲートウェイ関数に渡されるTPNAMEパラメータのいずれかです。この名前は、実行されたOLTPトランザクション・プログラムを完全に識別します。