5 Commit-Confirmの実装(SNAのみ)
Commit-confirmを使用すると、Oracle Database Gateway for APPCを介してアクセスされるOracle以外のリソースの更新と同じOracleトランザクションで、ローカルOracleリソースの更新を実行できます。
commit-confirmの要素と機能を理解するために、以下のトピックを読んでください。
インストール・ガイドには、SNA環境でのCommit-Confirmのためのゲートウェイ・コンポーネントの構成手順が記載されています。 特定の情報については、インストールおよび構成ガイドの第5章、"ネットワークの構成"および第6章、"SNA通信プロトコルを使用したゲートウェイ構成"を参照してください。
トピック:
Commit-Confirmの概要
注意:
Commit-Confirmを実装する予定の場合は、すでにコンポーネントを構成しておく必要があります。 プラットフォームによっては、の第12章 または「Oracle Database Gateway for APPCのインストールと構成ガイドfor Microsoft Windows」の第9章を参照してください。
Commit-confirmは、完全2フェーズ・コミットをサポートしていないデータベースまたはゲートウェイが、完全な2フェーズ・コミットをサポートする他のデータベースまたはゲートウェイとの分散更新トランザクションに参加できるようにする、2フェーズ・コミットの特別な実装です。 この実装では、他のすべてのサイトが準備された後、Commit-Confirmサイトが常にコミットされます。 これにより、Commit-Confirmサイトが正常にコミットできなかった場合、他のすべてのサイトをロールバックできるため、すべてのサイトを同期させることができます。
Oracle分散トランザクション内では、そのトランザクションに関連するすべての作業に、Oracleグローバル・トランザクションIDと呼ばれる共通の識別子が割り当てられます。 この識別子は一意であることが保証されているため、特定の分散トランザクションを排他的に識別するために使用できます。 Commit-Confirmサポートの重要な要件は、Commit-Confirmサイト(この場合は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の両方のリソースを更新して同期させることができるという利点があります。 主な違いは、Commit-Confirm実装では、リカバリ・サポートに必要なトランザクション・ロギングを実行するために、OLTPトランザクションでいくつかの追加プログラミングが必要であることです。
サポートされているOLTP
Commit-ConfirmはLU6.2 SYNCLEVEL 1
を使用するため、z/OSおよびIMS/TM用のCICS Transaction Serverを含む、APPCをサポートするすべてのOLTPによってサポートされます。 Oracle Database Gateway for APPCは、z/OS用のCICS Transaction ServerとIMS/TM用の両方のCommit-Confirmアプリケーションのサンプルを提供します。
z/OS用CICS Transaction Serverでは、標準のコマンド・レベルEXEC CICSインタフェースをすべてのAPPC通信に使用できます。 さらに、望ましい場合には、CPI-Cインタフェースを使用することができます。 EXEC CICSインタフェースを使用してCOBOLで作成されたサンプルDB2更新トランザクションは、ゲートウェイとともに提供されます。 z/OS用にCICS Transaction Serverでサポートされている言語は、Commit-Confirmトランザクションの作成に使用できます。
IMS/TMでは、IBM IMSCICS Transaction Server for z/OSのマニュアルで言及されているように、IMSトランザクションを明示的なAPPCトランザクションにするために、CPI-Cインタフェースを使用する必要があります。 これは、LU6.2のSYNCLEVEL 1
制御フローがIMSトランザクションにアクセスできる唯一の方法であるため、必要です。 IOPCBのGUとIOPCBのISRTがデータの送受信に使用される暗黙のAPPCを使用すると、IMSトランザクションがLU6.2のSYNCLEVEL 1
制御フローにアクセスする方法がないため、Commit-Confirmにこのメソッドを使用してください。 CPI-C APPCインタフェースを使用してCOBOLで書かれたサンプルDLIデータベース更新トランザクションは、ゲートウェイに付属しています。 IMSおよびCPI-Cでサポートされている言語は、Commit-Confirmトランザクションの作成に使用できます。
Commit-Confirmをサポートするために必要なコンポーネント
Commit-Confirmをサポートするには、次のコンポーネントが必要です:
-
Oracle Database Gateway for APPCサーバー
ゲートウェイ初期化ファイルで
PGA_CAPABILITY=COMMIT_CONFIRM
が指定されている場合、ゲートウェイ・サーバーはCommit-Confirmをサポートします。 ゲートウェイ・サーバーがCommit-Confirmを有効にして実行されている場合、DBA_2PC_PENDING
表に格納されているOracle 2フェーズ・コミット・ログと同様に、Commit-Confirmトランザクション・ログを管理するローカルOracleデータベースに接続します。 ゲートウェイ・トランザクション・ログは、PGA_CC_PENDING
表に格納されます。 この表には、各実行中のトランザクションごとに1つの行が格納され、トランザクションが完了するまでそこに残ります。PGA_CC_PENDING
の行の寿命は、通常はかなり短く、コミットがゲートウェイによって受信されてからOracleデータベースがすべてのコミット処理を完了し、ゲートウェイにトランザクションを忘れるよう指示するまで持続します。Commit-ConfirmゲートウェイSIDは、Commit-Confirmを実装する更新トランザクションを呼び出すためだけに予約されている必要があります。
PGA_CAPABILITY
がCOMMIT_CONFIRM
に設定されているときのログの設定には、若干のオーバーヘッドがあります。 読取り専用トランザクションは、PGA_CAPABILITY
をREAD_ONLY
に設定した別のゲートウェイSIDを介して呼び出されるため、余分なオーバーヘッドが発生しません。 -
Oracleデータベースは、
PGA_CC_PENDING
表を格納するためにゲートウェイ・サーバーで使用できる必要があります。 パフォーマンスと信頼性を最大限に高めるには、このOracleデータベースをゲートウェイ・サーバーと同じシステムに配置することをお薦めします。 -
OLTP Commit-Confirmトランザクション・ログ
Commit-Confirmトランザクション・ログ・データベースは、アクセス中のOLTPシステムに定義する必要があります。 このデータベースは回復可能でなければならず、OLTPアプリケーション・データベースと同じ作業単位の一部としてOLTPからアクセス可能でなければならないため、トランザクション・ログ・データベースの更新は、アプリケーション・データベースの更新と作業。
Commit-Confirmトランザクション・ログ・データベースには、Oracleグローバル・トランザクションIDと日付/時間スタンプのみが含まれている必要があります。 Oracleグローバル・トランザクションIDは169バイトで、キー・フィールドでなければなりません。 日付/時間スタンプは、特定の障害シナリオの後にログに残る可能性がある古いエントリを削除するために使用されます。
簡単にするために、特定のOLTP下のすべてのCommit-Confirmアプリケーションは、同じCommit-Confirmトランザクション・ログを共有する必要があります。
-
ゲートウェイCommit-Confirm実装で必要なトランザクション・ログを実行するには、Commit-Confirmゲートウェイによって呼び出される各OLTPトランザクションにコードを追加する必要があります。 このコードは、ゲートウェイからOracle Global Transaction IDを受け取り、その情報をOLTP Commit-Confirmトランザクション・ログ・データベースに書き込む必要があります。 最大限の柔軟性と使いやすさを実現するために、このコードは、OLTPシステム上のCommit-Confirmトランザクションから呼び出すサブルーチンとして記述することができます。
このコードは、最初のAPPC受信の前に各Commit-Confirmトランザクションの開始時に実行され、トランザクションの各
COMMIT
またはROLLBACK
の直後に実行されなければなりません。 これにより、各作業単位の開始時にロギングが確実に行われます。 -
正常にコミットされたトランザクションを忘れて、リカバリ処理中にトランザクション状態を問合せするために、ゲートウェイが開始できる別のAPPCトランザクションをOLTPシステム上に作成する必要があります。 このトランザクションは、忘却処理中に特定のOracleグローバル・トランザクションIDのエントリをOLTP Commit-Confirmトランザクション・ログ・データベースから削除し、リカバリ処理中にOLTP Commit-Confirmトランザクション・ログ・データベースから特定の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パラメータが正しく構成されていることを確認してください。
アプリケーション設計要件
Oracle Database Gateway for APPCで使用するCommit-Confirmアプリケーションを設計する場合、障害発生時にゲートウェイがトランザクションの状態を判断できるようにするために満たすべき要件がいくつかあります。 これらの要件が満たされない場合、Commit-Confirmゲートウェイでアプリケーションを使用しようとすると、予期しない結果が発生します。
Commit-Confirmゲートウェイによって呼び出されるOLTPトランザクションによって最初に行われなければならないことは、ゲートウェイからOracleグローバル・トランザクションIDを受け取り、それをOLTP Commit-Confirmトランザクション・ログ・データベースに記録することです。 これは、OLTPトランザクションとOracleアプリケーション間の通常のデータ・フローが開始する前に実行する必要があります。 ゲートウェイは、常にOracleグローバル・トランザクションIDを最初のデータ・アイテムとして送信します。
OLTPトランザクションがワン・ショット・トランザクションである場合、これが唯一必要な変更です。 トランザクションが複数の作業単位(複数のコミットまたはロールバックを発行)を実行する永続トランザクションである場合、COMMIT
またはROLLBACK
のたびに新しいOracleグローバル・トランザクションIDを受信してログに記録する必要があります。
Oracle Global Transaction IDは、ゲートウェイから最大長202バイトの可変長レコードで送信されます。 最初の32バイトには、ゲートウェイからのデータであり、他のアプリケーションからのデータではないことを確認するために使用される特殊なバイナリ文字列が含まれています。 次の1バイトは予約フィールドです。 Oracleグローバル・トランザクションIDは次に169バイトの長さです。 予約されたフィールドとOracleグローバル・トランザクションID、および日付/時間スタンプおよびログに記録するその他の情報を記録する必要があります。 Oracleグローバル・トランザクションIDをログ・データベースのキー・フィールドにする必要があるため、forget/recoveryトランザクションでOracleグローバル・トランザクションIDを使用してログ・エントリに直接アクセスできるように注意してください。
注意:
OLTPがIMS/TMの場合は、Commit-Confirmゲートウェイで使用するトランザクションごとに、Commit-Confirmトランザクション・ログ・データベース用のPCBをPSBに追加する必要があります。 このPCBは、PSBの最初のPCBでなければなりません。
Commit-Confirmアーキテクチャ
Oracle Database Gateway for APPCのCommit-Confirm実装のアーキテクチャは、3つの主要コンポーネントで構成されています:
-
Oracleデータベース
-
Oracle Database Gateway for APPCサーバー(ゲートウェイ・サーバー)
-
ロギング・サーバー(表
PGA_CC_PENDING
とPGA_CC_LOG
を保持するOracleデータベース)
このセクションでは、Commit-Confirmの操作における各コンポーネントのロールと、これらのコンポーネントがどのように相互作用するかについて説明します。
コンポーネント
Oracleデータベースは、Commit-Confirmアーキテクチャの制御コンポーネントです。 これは、ゲートウェイ・サーバーにトランザクションをコミットするタイミングと、トランザクションをいつロールバックするかを指示します。 これは、分散トランザクションに参加している他のすべてのサーバーでも同じです。 障害が発生した場合、ゲートウェイ・サーバーを含む各参加サーバーのリカバリ・プロセスを駆動するのは、統合サーバーとして機能するOracleデータベースです。
ゲートウェイ・サーバーは、Oracleデータベースからの指示をLU6.2操作に変換するタスクを実行し、トランザクションをログ・サーバーに記録します。 ゲートウェイ・サーバーは、ロギング・サーバー上のPGA_CC_PENDING
という表にログ情報を格納します。 トランザクション処理中に障害が発生すると、ゲートウェイ・サーバーは、Oracleデータベースに戻されるエラーを判別します。
ロギング・サーバーは、ゲートウェイ・サーバーがCommit-Confirmログ情報を保管してアクセスするために使用できるOracleデータベースです。 ロギング・サーバーは、統合サーバーとして機能する同じOracleデータベースである必要はありません。 ロギング・サーバーはゲートウェイCommit-Confirm操作の不可欠なコンポーネントであるため、ゲートウェイ・サーバーと同じシステム上に配置するのが最適です。 これにより、ゲートウェイ・サーバーとロギング・サーバー間の通信でプロセス間通信を使用できるため、コンポーネント間で高速で低オーバーヘッドのローカル接続が提供されます。
相互作用
コンポーネント間には特定の一連の対話が存在します。 これらを次に示します。
-
Oracle Database <-->ゲートウェイ・サーバー
Oracleデータベースは、ゲートウェイ・サーバーによるすべてのアクションを駆動します。 Oracleアプリケーションのリクエストでは、統合サーバーは、新しいOracleトランザクションの開始、コミット・シーケンスの開始、ロールバック・シーケンスの開始、または忘れたシーケンスの開始をゲートウェイ・サーバーに指示できます。 また、Oracleアプリケーションの代わりに、ゲートウェイのリモート・プロシージャ・コール(RPC)関数(
PGAINIT
、PGAXFER
、PGATERM
)を呼び出すこともできます。 -
ゲートウェイ・サーバーは、
PGA_CC_PENDING
表から行を挿入および削除するために、PGA_CC_PENDING
ロギング・サーバーを呼び出します。 これは、実際には、ロギング・サーバーでPL/SQLストアド・プロシージャPGA_CC_LOG
を呼び出して、ロギングを実行するためにゲートウェイ・サーバーが必要とするオープン・カーソルの数を減らすことによって行われます。 ロギングのためにゲートウェイ・サーバーは1つのカーソルしか必要としません。
Commit-Confirmフロー
OracleアプリケーションとOLTPトランザクション間の正常なコミットの制御フローは、次のセクションで説明されており、in「図5-1」を示しています。 図は、OracleリソースとOLTPリソースの両方が更新されていることを前提としています。 「Commit-Confirm論理フロー_ ステップ・バイ・ステップ」の次のステップでは、Commit-Confirmロジック・フローの概要を説明します。
Commit-Confirm論理フロー、ステップ・バイ・ステップ
- アプリケーションは、Oracleデータベースに
COMMIT
を発行します。 - Oracleデータベースは、ゲートウェイ以外の分散トランザクションの各参加者に
PREPARE
を送信します。 - 各参加者はデータベースの更新を準備し、
PREPARE OK
をOracleデータベースに応答します。 - Oracleデータベースは、
COMMIT
をゲートウェイに送信します。 ゲートウェイは、OracleデータベースからCOMMIT
を受け取り、新しい保留トランザクション・ローをPGA_CC_PENDING
表に挿入します。 - ゲートウェイは、APPC
CONFIRM
をOLTPアプリケーションに送信します。 OLTPアプリケーションは、最後のAPPCRECEIVE
からステータスの形式でCONFIRM
リクエストを受け取ります。 - OLTPアプリケーションは、適切なOLTP機能を使用して
COMMIT
を発行します。 OLTPは、最後のCOMMIT
(Commit-Confirmトランザクション・ログ更新を含む)以来、アプリケーションによって行われたすべてのデータベース更新をコミットします。 - データベースの更新がコミットされると、OLTPは
COMMIT
のステータスを示すリターン・コードでアプリケーションに制御を返します。 - OLTPアプリケーションはAPPC
CONFIRMED
をゲートウェイに送信します。 - ゲートウェイは
CONFIRMED
を受け取り、COMMIT OK
をOracleデータベースに戻します。 - Oracleデータベースは、ゲートウェイ以外の分散トランザクションの各参加者に
COMMIT
を送信します。 - 各参加者はデータベースの更新をコミットし、
COMMIT OK
をOracleデータベースに応答します。 - Oracleデータベースは、
FORGET
をゲートウェイに送信します。 - ゲートウェイは
FORGET
を受信し、OLTPでFORGET/RECOVERY
トランザクションを使用して新しいAPPC会話を開始し、FORGET
リクエストとAPPCCONFIRM
を送信します。FORGET/RECOVERY
トランザクションは、FORGET
リクエストを受け取り、現行のOracleトランザクションのCommit-Confirmトランザクション・ログからそのエントリを削除し、削除をコミットします。 FORGET/RECOVERY
トランザクションはAPPCCONFIRMED
をゲートウェイに送信して、FORGET
が処理されたことを示し、終了します。 ゲートウェイはCONFIRMED
を受信し、保留中のトランザクション行をPGA_CC_PENDING
表から削除します。- ゲートウェイは、
FORGET OK
をOracleデータベースに戻します。 - Oracleデータベースは、制御をOracleアプリケーションに戻します。
「図5-1」は、前のセクションで説明したCommit-Confirmロジック・フローを示しています。
図5-1 Synclevel 1によるCommit-Confirmフロー
「図5-1 Synclevel 1によるCommit-Confirmフローの説明」
ゲートウェイ・サーバーのCommit-Confirmトランザクション・ログ
Commit-Confirmトランザクション・ログは、単一の表 PGA_CC_PENDING
で構成されています。 この表には、Commit-Confirmゲートウェイを含む各実行中Oracleトランザクションの行が含まれています。 表はゲートウェイ・サーバーによって管理され、OracleデータベースのDBA_2PC_PENDING
表と機能的に似ています。 COMMIT
がゲートウェイによって受信され、FORGET
がゲートウェイによって受信されると、行が削除されるまで、この表に行が挿入されないことに注意してください。 PREPARE
フェーズでは、ゲートウェイによる関与はありません。
PGA_CC_PENDING
表には、次のカラムがあります:
-
これは、トランザクションのOracleグローバル・トランザクションIDです。 これは、
DBA_2PC_PENDING
表の対応する列と同じです。 -
これは、ターゲットLUとのAPPC会話を割り当てるためにゲートウェイによって使用されたサイド情報プロファイル名です。 これは、
PGAINIT
ゲートウェイ機能に渡されるSIDENAME
パラメータに対応します。 -
これは、ターゲットLUの完全修飾パートナLU名です。 この値は、サイド情報プロファイルのLU名または
PGAINIT
ゲートウェイ関数に渡されるLUNAME
パラメータのいずれかです。 この名前は、トランザクションが実行されたOLTPシステムを完全に識別します。 -
これは、ターゲットLUとのAPPC会話を割り当てるためにゲートウェイによって使用されたモード名です。 値は、サイド情報プロファイルのモード名か、
PGAINIT
ゲートウェイ機能に渡されるMODENAME
パラメータのいずれかです。 -
これは、ターゲットLUで実行されるトランザクション・プログラム名です。 値は、サイド情報プロファイルからのTP名か、
PGAINIT
ゲートウェイ関数に渡されるTPNAME
パラメータのいずれかです。 この名前は、実行されたOLTPトランザクション・プログラムを完全に識別します。