管理の手引き


データベースをリソース・マネージャーとして設定する

各データベースは、 トランザクション・マネージャー (TM) に対して別個のリソース・マネージャー (RM) として定義されているので、 xa_open ストリングによって識別する必要があります。 DB2 の xa_open ストリングの形式については、xa_open および xa_close ストリングの使用法を参照してください。

xa_open および xa_close ストリングの使用法

データベース・マネージャーの xa_open ストリングには、2 つの形式があります。 1 つは DB2 バージョン 7 で新しく使用される形式です。 2 番目の形式は DB2 の以前のバージョンで使われるもので、 バック・レベル互換性のために保持されています。 新しく実装する際には新しい形式を使用すべきであり、以前に実装したものは、 可能であれば新しい形式に移行してください。 DB2 の将来のバージョンでは、 古い形式の xa_open ストリングをサポートしない可能性があります。 以前の xa_open ストリング形式については、以前のバージョンの DB2 の xa_open ストリング形式を参照してください。

データベースをリソース・マネージャーとして設定する場合、 xa_close ストリングは必要ありません。 このストリングを指定しても、 データベース・マネージャーによって無視されます。

DB2 バージョン 7 での新しい xa_open ストリング形式

以下の xa_open ストリング形式は DB2 バージョン 7 で新しく使用されるものです。

   parm_id1 = <parm value>,parm_id2 = <parm value>, ...

パラメーターは任意の順序で指定できます。 parm_id の有効値は、以下の表のとおりです。

表 22. parm_id の有効値
パラメーター名 必須かどうか 大文字小文字の区別 デフォルト値
DB データベース別名 はい なし なし
データベースへのアクセスにアプリケーションが使用するデータベース別名。
UID ユーザー ID いいえ あり なし
データベースへの接続を許可されているユーザー ID。 パスワードが指定される場合に必要。
PWD パスワード いいえ あり なし
ユーザー ID に関連したパスワード。 ユーザー ID が指定される場合に必要。
TPM トランザクション処理モニター名 いいえ なし なし
使用されている TP モニターの名前。 サポートされている値については、TPM 値および TP_MON_NAME 値を参照してください。 このパラメーターを指定すると、 複数の TP モニターで単一の DB2 インスタンスを使用できます。 ここで指定した値は、 データベース・マネージャー構成パラメーター tp_mon_name に 指定された値をオーバーライドします。
AXLIB TP モニターの ax_reg 関数 および ax_unreg 関数を含むライブラリー。 いいえ あり なし
この値は、必要な ax_reg 関数 および ax_unreg 関数のアドレスを得るために DB2 によって使用されます。 この値を使って、TPM パラメーターに基づく仮定値をオーバーライドできます。 または、TPM のリストに現れない TPM モニターがこの値を使用することもできます。
CHAIN_END xa_end チェーニング・フラグ。 有効な値は、TF、または値なしです。 いいえ なし F
XA_END チェーニングとは、 ネットワーク・フローを減らすために DB2 が使用することのできる最適化です。 xa_end 呼び出しに続いてただちに 同じスレッド (またはプロセス) で 必ず xa_prepare が呼び出されるような TP モニター環境では、CHAIN_END がオンであれば、 xa_end フラグは xa_prepare コマンドと連結され、 こうしてネットワーク・フローが 1 つ減ります。 値 T は CHAIN_END がオンであることを示し、 値 F は CHAIN_END がオフであることを示します。 値を指定しない場合、CHAIN_END はオンになります。 また、このパラメーターを使用して、 特定の TPM 値から派生した設定をオーバーライドできます。
SUSPEND_CURSOR トランザクションの制御スレッドが中断されている場合にカーソルを保持するかどうかを指定します。 有効な値は、TF、または値なしです。 いいえ なし F
トランザクション分岐を中断する TP モニターは、 中断されたスレッドまたはプロセスを他のトランザクション用に再使用できます。 このような状況では、 新しいトランザクションがカーソルを継承しないようにするために、 カーソルを閉じる必要があります。 中断されたトランザクションが再開されると、 アプリケーションは再びカーソルを取得する必要があります。 SUSPEND_CURSOR がオンであれば、開いたカーソルはいずれも閉じられませんが、 スレッドまたはプロセスを他のトランザクション用に再使用することはできません。 中断されたトランザクションの再開だけが可能です。 値 T 値は SUSPEND_CURSOR がオンであることを示し、 値 F 値は SUSPEND_CURSOR がオフであることを示します。 値を指定しない場合、SUSPEND_CURSOR はオンになります。 また、このパラメーターを使用して、 特定の TPM 値から派生した設定をオーバーライドできます。
HOLD_CURSOR トランザクションのコミット後に次のコミットまでカーソルを保持するかどうかを指定します。 有効な値は、TF、または値なしです。 いいえ なし F
通常、TP モニターは、 スレッドまたはプロセスを複数のアプリケーション用に再使用します。 新しくロードされたアプリケーションが、 以前のアプリケーションによって開かれたカーソルを継承しないようにするために、 カーソルはコミット後に閉じられます。 HOLD_CURSOR がオンであれば、 トランザクションのコミット後も次のコミットまでカーソルを保持します。 値 T 値は HOLD_CURSOR がオンであることを示し、 値 F 値は HOLD_CURSOR がオフであることを示します。 値を指定しない場合、HOLD_CURSOR はオンになります。 また、このパラメーターを使用して、 特定の TPM 値から派生した設定をオーバーライドできます。

TPM 値および TP_MON_NAME 値

xa_open ストリングの TPM パラメーターと データベース・マネージャー構成パラメーター tp_mon_name は、 使用中の TP モニターを DB2 に示すために使われます。 tp_mon_name 値は DB2 インスタンス全体に適用されます。 TPM パラメーターは、特定の XA リソース・マネージャーにのみ適用されます。 TPM 値は tp_mon_name パラメーターをオーバーライドします。 TPM および tp_mon_name パラメーターの有効値は以下のとおりです。

表 23. TPM および tp_mon_name の有効値
TPM 値 TP モニター製品 内部設定
CICS IBM TxSeries CICS
AXLIB=libEncServer (Windows の場合)
     =/usr/lpp/encina/lib/libEncServer
        (UNIX ベースのシステムの場合)
HOLD_CURSOR=T
CHAIN_END=T
SUSPEND_CURSOR=F


ENCINA IBM TxSeries Encina Monitor
AXLIB=libEncServer (Windows の場合)
     =/usr/lpp/encina/lib/libEncServer
        (UNIX ベースのシステムの場合)
HOLD_CURSOR=F
CHAIN_END=T
SUSPEND_CURSOR=F


MQ IBM MQSeries
AXLIB=mqmax (Windows の場合)
     =/usr/mqm/lib/libmqmax.a
        (AIX の場合)
     =/opt/mqm/lib/libmqmax.a
        (Solaris の場合)
HOLD_CURSOR=F
CHAIN_END=F
SUSPEND_CURSOR=F


CB IBM Component Broker
AXLIB=somtrx1i (Windows の場合)
     =libsomtrx1
        (UNIX ベースのシステムの場合)
HOLD_CURSOR=F
CHAIN_END=T
SUSPEND_CURSOR=F


SF IBM San Francisco
AXLIB=ibmsfDB2
HOLD_CURSOR=F
CHAIN_END=T
SUSPEND_CURSOR=F


TUXEDO BEA Tuxedo
AXLIB=libtux
HOLD_CURSOR=F
CHAIN_END=F
SUSPEND_CURSOR=F


MTS Microsoft Transaction Server
MTS 用に DB2 を構成する必要はありません。 MTS は DB2 の ODBC ドライバーによって自動的に検出されます。
JTA Java Transaction API
IBM WebSphere などの Enterprise Java Server (EJS) 用に DB2 を 構成する必要はありません。 DB2 の JDBC ドライバーは、この環境を自動的に検出します。

  1. Windows NT で IBM TxSeries CICS を使用しているとします。 TxSeries の資料によると、 tp_mon_name を値 libEncServer:C に構成する必要があります。 これは許容できる形式ですが、 DB2 UDB または DB2 コネクトのバージョン 7 では、以下のようなオプションもあります。
  2. Windows NT で IBM MQSeries を使用しているとします。 MQSeries の資料によると、 tp_mon_name を値 mqmax に構成する必要があります。 これは許容できる形式ですが、 DB2 UDB または DB2 コネクトのバージョン 7 では、以下のようなオプションもあります。
  3. Windows NT で IBM TxSeries CICS および IBM MQSeries の両方を使用しているとします。 さらに、1 つの DB2 インスタンスが使用されています。 このシナリオでは、次のように構成します。

    1. 「領域 (Region)」->「リソース (Resources)」->「製品 (Product)」->「XAD」 ->「リソース・マネージャー初期化ストリング (Resource manager initialization string)」で、 CICS に対して定義された各データベースごとに以下のように指定します。

         pwd=password,uid=userid,tpm=cics,db=dbalias
      
    2. 待ち行列管理プログラムのプロパティーでリソースとして定義されている 各データベースごとに、XaOpenString を以下のように指定します。

         db=dbalias,uid=userid,pwd=password,tpm=mq
      
  4. Windows NT で独自の XA 準拠トランザクション・マネージャー (XA TM) を開発していて、 DB2 に対して、ライブラリー myaxlib に必要な 関数 ax_reg および ax_unreg が 入っていることを示したいとします。 ライブラリー myaxlib は、PATH ステートメントで指定されたディレクトリーにあります。 次のようなオプションがあります。
  5. Windows NT で独自の XA 準拠トランザクション・マネージャー (XA TM) を開発していて、 DB2 に対して、ライブラリー myaxlib に必要な 関数 ax_reg および ax_unreg が 入っていることを示したいとします。 ライブラリー myaxlib は、PATH ステートメントで指定されたディレクトリーにあります。 また、XA END チェーニングも使用可能にしたいとします。 次のようなオプションがあります。

以前のバージョンの DB2 の xa_open ストリング形式

以前のバージョンの DB2 は、ここで説明する xa_open ストリング形式を使用します。 この形式は、互換性のためにサポートされています。 可能な限り、 アプリケーションを新しい形式 (DB2 バージョン 7 での新しい xa_open ストリング形式を参照) に移行してください。

各データベースは、トランザクション・マネージャー (TM) に対して 別個のリソース・マネージャー (RM) として定義されているので、 次の構文の xa_open ストリングによってデータベースを識別する必要があります。

   "database_alias<,userid,password>"

database_alias は必須であり、データベースの別名を指定するものです。 データベース作成後に明示的に別名をカタログ化したのでない限り、 この別名はデータベース名と同じになります。 ユーザー名とパスワードは任意指定であり、認証方式によっては、 データベースに認証情報を提供するのに使用します。

データベースをリソース・マネージャーとして設定する場合、 xa_close ストリングは必要ありません。 このストリングを指定しても、 データベース・マネージャーによって無視されます。

ホストまたは AS/400 データベース・サーバーの更新

XA トランザクション・マネージャーのアーキテクチャーによっては、 ホストおよび AS/400 データベース・サーバーを更新することができます。 異なるプロセスからの連続コミットをサポートするには、 DB2 コネクト・コンセントレーターが使用可能でなければなりません。 DB2 コネクト EE コンセントレーターを使用可能にするには、 データベース・マネージャー構成パラメーター max_logicagents を、 maxagents より大きな値に設定します。 異なるプロセスからの連続 XA コミットを DB2 コネクト EE コンセントレーターが サポートするためには、 DB2 バージョン 7.1 クライアントが必要であることに注意してください。 この環境で使用できる SQL ステートメントについては、 アプリケーション開発の手引き を参照してください。 コンセントレーターについては、DB2 コネクト 使用者の手引き を参照してください。

ホストまたは AS/400 データベース・サーバーを更新する場合は、 DB2 同期点マネージャー (SPM) が構成されている DB2 コネクトが必要です。 詳しくは、概説およびインストール を参照してください。

データベース接続の考慮事項

このセクションでは、次のトピックについて説明します。

RELEASE ステートメント

RELEASE ステートメントを用いてデータベースへの接続を解放する場合は、 SET CONNECTION ではなく CONNECT ステートメントを用いてそのデータベースに再接続してください。

区分データベースにアクセスするトランザクション

区分データベース環境では、 ユーザー・データが複数のデータベース区画にまたがって分散されることがあります。 このデータベースにアクセスするアプリケーションは、 データベース区画 (調整プログラム・ノード) のいずれかに接続し、要求を送信します。 異なったアプリケーションが異なったデータベース区画に接続することや、 同じアプリケーションが異なった接続について異なったデータベース区画を選択することができます。

区分データベース環境のデータベースに対するトランザクションについては、 同一の データベース区画から、 すべてのアクセスが行われなければなりません。 つまり、 トランザクションの開始からそのトランザクションがコミットされる時まで (この時点も含む)、 同じデータベース区画を使用しなければならないということです。

区分データベースに対するトランザクションは、 切断前にコミットされる必要があります。

発見的手法の決定

XA 準拠のトランザクション・マネージャー (トランザクション処理モニター) は、 2 フェーズ・コミット・プロセスについてで説明されているように、 DB2 トランザクション・マネージャーが使用するのと同様な 2 フェーズ・コミットを使用します。 これら 2 つの環境の主な違いは、 DB2 トランザクション・マネージャーおよびトランザクション・マネージャー・データベースの機能の代わりに、 TP モニターがトランザクションのロギングや制御の機能を提供することです。

DB2 トランザクション・マネージャーについて論じられたエラー (2 フェーズ・コミット時の問題を回復する参照) と同様のエラーが、 XA 準拠のトランザクション・マネージャー使用中にも起きることがあります。 DB2 トランザクション・マネージャーと同様、 XA 準拠のトランザクション・マネージャーは未確定トランザクションの再同期を試行します。

何らかの理由で、 トランザクション・マネージャーが自動的に未確定トランザクションを解決するまで待てない場合は、 未確定トランザクションを手動で解決するための措置がいくつかあります。 この手動の処理は、「発見的手法の決定」と呼ばれることもあります。

(WITH PROMPTING オプションとともに) LIST INDOUBT TRANSACTIONS コマンドを使用して、 または関連する API のセットを使用して、未確定トランザクションの照会、 コミット、およびロールバックを行うことができます。 さらに、ログ・レコードを削除してログ・スペースを解放することにより、発見的 手法でコミットまたはロールバックされたトランザクションを「忘れる」こともできます。 UNIX ベースのシステム、Windows オペレーティング・システム、 または OS/2 の DB2 UDBから未確定トランザクション情報を得るには、 データベースに接続し、 LIST INDOUBT TRANSACTIONS WITH PROMPTING コマンドまたは これに対応する API を発行します。 このコマンドまたは関連する管理 API については、 コマンド解説書 または 管理 API 解説書 を参照してください。

ホストまたは AS/400 データベース・サーバーに関連した未確定トランザクション情報は、 以下の 2 つの方法のいずれかで取得できます。

これらのコマンド (または関連する API) は、あくまでも最後の手段として、 細心の注意 を払って使用してください。 最善の方法は、トランザクション・マネージャーが再同期操作を始めるまで待つことです。 ある参加データベースでは手動でコミットまたはロールバックを行い、 別の参加データベースでは正反対の処置を取るならば、 データ保全の問題が生じかねません。 データ保全の問題から回復するには、 アプリケーション論理を理解し、変更またはロールバックされたデータを識別して、 次いで所定時間内にデータベースを回復するか、 または手動で変更の取り消し (またはやり直し) をする必要があります。

トランザクション・マネージャーが再同期を開始するまで待てず、 かつ未確定トランザクションに結び付けられているリソースを解放しなければならない場合は、 発見的手法の操作が必要です。 このような状況は、 トランザクション・マネージャーが長時間使用できないために再同期を実行することができず、 緊急に必要なリソースが未確定トランザクションによって拘束されている場合に発生する可能性があります。 トランザクション・マネージャーまたはリソース・マネージャーが使用不能になる前に未確定トランザクションに関連していたリソースは、 依然としてそのトランザクションに結び付けられています。 データベース・マネージャーの場合、これらのリソースには、表や索引のロック、ログのスペース、 およびそのトランザクションにより占有されている記憶域などが含まれます。 各未確定トランザクションごとに、 データベースで処理できる並行トランザクションの最大数も (1 つずつ) 減っていきます。

発見的手法の操作を行う単純明快な方法というものはありませんが、 一般的な指針を以下に示します。

  1. すべてのトランザクションを完了しなければならないデータベースに接続する。
  2. LIST INDOUBT TRANSACTIONS コマンドを使って、未確定トランザクションを表示する。 このとき、xid は大域トランザクション ID を表し、 このトランザクションに参加しているトランザクション・マネージャーや他のリソース・マネージャーが使用する xid と同じです。
  3. 各未確定トランザクションについて、 アプリケーションと操作環境に関する知識を活用して、 他の参加リソース・マネージャーを判別する。
  4. トランザクション・マネージャーが利用可能かどうかを判別する。

発見的手法でコミットまたはロールバックされたトランザクションが原因で ログ満杯状態が発生した場合 (LIST INDOUBT TRANSACTIONS コマンドからの出力に示される) を除き、 発見的手法の forget 関数は実行しないでください。 発見的手法の forget 関数を実行すると、 未確定トランザクションが占有していたログ・スペースが解放されます。 つまり、トランザクション・マネージャーが この未確定トランザクションに関して再同期操作を実行すると、 このリソース・マネージャーにはトランザクションのログ・レコードがないために、 他のリソース・マネージャーのコミットやロールバックを行うという 間違った決定を下す危険性があります。 一般に、ログ・レコードが「欠落」しているということは、 リソース・マネージャーがトランザクションをロールバックしたことを暗示します。

機密保護についての考慮事項

TP モニターは一連のサーバー・プロセスを事前に割り振り、 それらのサーバー・プロセスの ID 下で異なるユーザーからトランザクションを実行します。 データベース側からすれば、各サーバー・プロセスは、 そのサーバー・プロセスに関連した同じ ID で実行中の多くの作業単位を持つ 1 つの巨大なアプリケーションのように見えます。

たとえば、CICS を使用している AIX 環境では、TXSeries CICS 領域が始動すると、 その領域は定義されている AIX ユーザー名に関連付けられます。 すべての CICS アプリケーション・サーバー・プロセスも、 この TXSeries CICS の「マスター」ID (通常 "cics" と定義されている) で実行されます。 CICS ユーザーは DCE ログイン ID で CICS トランザクションを呼び出すことができ、 CICS にいる間は、CESN サインオン・トランザクションを使用して ID を変更することもできます。 どちらの場合も、RM にはエンド・ユーザーの ID を使用できません。 結果として、CICS アプリケーション・プロセスは多くのユーザーの代行としてトランザクションを実行することになりますが、 RM からは、それらが同じ "cics" ID の多くの作業単位を伴う単一プログラムのように見えます。 オプションとして xa_open ストリングにユーザー ID とパスワードを指定すると、 データベース接続時には、"cics" ID ではなくそのユーザー ID が使用されます。

静的 SQL ステートメントの場合は、エンド・ユーザーの特権ではなく、 バインド側の特権を使用してデータベースにアクセスするので、あまり影響はありません。 ただし、これは、データベース・パッケージの EXECUTE 特権を エンド・ユーザー ID ではなくサーバー ID に与える必要がある というわけではありません。

実行時にアクセス確認を行う動的ステートメントの場合は、 データベース・オブジェクトへのアクセス特権は、 それらのオブジェクトの実際のユーザーではなく、 サーバーの ID に付与する必要があります。 データベースによって特定のユーザーのアクセスを制御するのではなく、 TP モニター・システムを利用して、 どのユーザーがどのプログラムを実行できるかを判別する必要があります。 サーバー ID には、SQL ユーザーが必要とするすべての特権を付与することが必要です。

だれがデータベース表または視点にアクセスしたかを調べるためには、 以下のステップを実行することができます。

  1. SYSCAT.PACKAGEDEP カタログ視点から、 その表または視点に依存するすべてのパッケージのリストを入手する。
  2. インストール時に使用した命名規則により、 それらのパッケージに対応するサーバー・プログラム (CICS プログラムなど) の名前が何かを調べる。
  3. それらのプログラムを呼び出せるクライアント・プログラム (CICS トランザクション ID など) を調べ、 TP モニターのログを使用して、 いつだれがこれらのトランザクションまたはプログラムを実行したかを調べる。

構成についての考慮事項

TP モニター環境を設定する場合は、次の構成パラメーターを考慮してください。

サポートされている XA 関数

DB2 ユニバーサル・データベースは、 X/Open CAE Specification Distributed Transaction Processing: The XA Specification で定義されている XA91 仕様をサポートしますが、以下は例外です。

xa_open ストリングおよび xa_close ストリングの使用法については、 xa_open および xa_close ストリングの使用法を参照してください。

XA スイッチの使用法と位置

XA インターフェースとして必要とされるものとして、データベース・マネージャーには、 XA スイッチ構造体を TM に戻すために使う xa_switch_t 型の外部 C 変数 db2xa_switch が用意されています。 さまざまな XA 関数のアドレス以外に、以下のフィールドが返されます。

フィールド

name
データベース・マネージャーの製品名。 たとえば、DB2 (AIX 版)。

flags
TMREGISTER | TMNOMIGRATE

DB2 ユニバーサル・データベースが動的登録を使用し、 TM は関連の移行を使用してはならないことを明示的に示します。 非同期操作がサポートされないことを暗黙的に示します。

version
常に 0。

DB2 ユニバーサル・データベース XA スイッチの使用

XA アーキテクチャーでは、 XA トランザクション・マネージャー (TM) が リソース・マネージャー (RM) の xa_ ルーチンに アクセスできるようにするスイッチ を、 RM が提供しなければなりません。 RM のスイッチは、xa_switch_t と呼ばれる構造体を使用します。 スイッチには、RM の名前、RM の XA 入り口点への 非空ポインター、フラグ、 およびバージョン番号が含まれます。

UNIX ベースのシステムおよび OS/2

DB2 UDB のスイッチは、以下の 2 つの方法のいずれかによって得られます。

いずれの場合も、libdb2 (UNIX ベースの システム) または db2api.lib (OS/2) を使用して、 アプリケーションをリンクする必要があります。

Windows NT

xa_switch 構造体 db2xa_switch を示すポインターは DLL データとしてエクスポートされます。 したがって、この構造体を使用する Windows NT アプリケーションは、 次の 3 つのいずれかの方法でこれを参照する必要があります。

いずれの方式でも、 db2api.lib を使用してアプリケーションをリンクする必要があります。

C コードの例

以下のコードは、 任意の DB2 UDB プラットフォーム上の C プログラムで db2xa_switch にアクセスするいくつかの方法を示しています。 必ずアプリケーションを適切なライブラリーとリンクしてください。

   #include <stdio.h>
   #include <xa.h>
   struct xa_switch_t * SQL_API_FN  db2xacic( );
   #ifdef DECLSPEC_DEFN
   extern __declspec(dllimport) struct xa_switch_t db2xa_switch;
   #else
   #define db2xa_switch (*db2xa_switch)
   extern struct xa_switch_t db2xa_switch;
   #endif

main( )
   {
      struct xa_switch_t *foo;
      printf ( "%s \n", db2xa_switch.name );
      foo = db2xacic();
      printf ( "%s \n", foo->name );
      return ;
   }

XA インターフェースの問題判別

TM からの XA 要求時にエラーが検出された場合、 アプリケーション・プログラムは TM からそのエラー・コードを入手することはできません。 ご使用のプログラムが異常終了したり、 TP モニターまたは TM からの暗号戻りコードを受け取ったりした場合、 基本障害保守ログを調べてください。 診断レベルが 3 以上であればここに XA エラー情報が報告されています。 基本障害保守ログの詳細について、問題判別の手引き を参照してください。

その他に、コンソール・メッセージ、TM エラー・ファイル、 またはご使用の外部トランザクション処理ソフトウェア製品固有の情報も調べてください。

データベース・マネージャーは、XA 固有のエラーを基本障害保守ログに書き込み、 その際 SQLCODE -998 (トランザクションまたは発見的手法のエラー) と該当する理由コードを指定します。 最も一般的なエラーには、以下のようなものがあります。

以下の例は、 (xa_open ストリングがないために) AIX で生成される xa_open エラーの エラー・ログを示しています。

   Tue Apr  4 15:59:08 1995
   toop pid(83378) process (xatest) XA DTP Support      sqlxa_open Probe:101
   DIA4701E Database "" could not be opened for distributed transaction
   processing.
   String Title : XA Interface SQLCA  pid(83378)
   SQLCODE = -998  REASON CODE: 4  SUBCODE: 1
   Dump File : /u/toop/diagnostics/83378.dmp Data : SQLCA


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]