機械翻訳について

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_CAPABILITYCOMMIT_CONFIRMに設定されているときのログの設定には、若干のオーバーヘッドがあります。 読取り専用トランザクションは、PGA_CAPABILITYREAD_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トランザクション・ログを共有する必要があります。

  • OLTPトランザクション・ログ・コード

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

    このコードは、最初のAPPC受信の前に各Commit-Confirmトランザクションの開始時に実行され、トランザクションの各COMMITまたはROLLBACKの直後に実行されなければなりません。 これにより、各作業単位の開始時にロギングが確実に行われます。

  • OLTP忘れ/リカバリ・トランザクション

    正常にコミットされたトランザクションを忘れて、リカバリ処理中にトランザクション状態を問合せするために、ゲートウェイが開始できる別の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をログ・データベースのキー・フィールドにする必要があるため、忘れ/リカバリ・トランザクションで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_PENDINGPGA_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)関数( PGAINITPGAXFERPGATERM)を呼び出すこともできます。

  • ゲートウェイ・サーバー<-->ログ・サーバー

    ゲートウェイ・サーバーは、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論理フロー、ステップ・バイ・ステップ

  1. アプリケーションは、OracleデータベースにCOMMITを発行します。
  2. Oracleデータベースは、ゲートウェイ以外の分散トランザクションの各参加者にPREPAREを送信します。
  3. 各参加者はデータベースの更新を準備し、PREPARE OKをOracleデータベースに応答します。
  4. Oracleデータベースは、COMMITをゲートウェイに送信します。 ゲートウェイは、OracleデータベースからCOMMITを受け取り、新しい保留トランザクション・ローをPGA_CC_PENDING表に挿入します。
  5. ゲートウェイは、APPC CONFIRMをOLTPアプリケーションに送信します。 OLTPアプリケーションは、最後のAPPC RECEIVEからステータスの形式でCONFIRMリクエストを受け取ります。
  6. OLTPアプリケーションは、適切なOLTP機能を使用してCOMMITを発行します。 OLTPは、最後のCOMMIT (Commit-Confirmトランザクション・ログ更新を含む)以来、アプリケーションによって行われたすべてのデータベース更新をコミットします。
  7. データベースの更新がコミットされると、OLTPはCOMMITのステータスを示すリターン・コードでアプリケーションに制御を返します。
  8. OLTPアプリケーションはAPPC CONFIRMEDをゲートウェイに送信します。
  9. ゲートウェイはCONFIRMEDを受け取り、COMMIT OKをOracleデータベースに戻します。
  10. Oracleデータベースは、ゲートウェイ以外の分散トランザクションの各参加者にCOMMITを送信します。
  11. 各参加者はデータベースの更新をコミットし、COMMIT OKをOracleデータベースに応答します。
  12. Oracleデータベースは、FORGETをゲートウェイに送信します。
  13. ゲートウェイはFORGETを受信し、OLTPでFORGET/RECOVERYトランザクションを使用して新しいAPPC会話を開始し、FORGETリクエストとAPPC CONFIRMを送信します。 FORGET/RECOVERYトランザクションは、FORGETリクエストを受け取り、現行のOracleトランザクションのCommit-Confirmトランザクション・ログからそのエントリを削除し、削除をコミットします。
  14. FORGET/RECOVERYトランザクションはAPPC CONFIRMEDをゲートウェイに送信して、FORGETが処理されたことを示し、終了します。 ゲートウェイはCONFIRMEDを受信し、保留中のトランザクション行をPGA_CC_PENDING表から削除します。
  15. ゲートウェイは、FORGET OKをOracleデータベースに戻します。
  16. Oracleデータベースは、制御をOracleアプリケーションに戻します。

「図5-1」は、前のセクションで説明したCommit-Confirmロジック・フローを示しています。

図5-1 Synclevel 1によるCommit-Confirmフロー

図5-1の説明が続きます
「図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表には、次のカラムがあります:

  • GLOBAL_TRAN_ID

    これは、トランザクションのOracleグローバル・トランザクション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トランザクション・プログラムを完全に識別します。