Comments
Description
Transcript
XAおよびOracleで制御する分散 トランザクション
Oracleホワイト・ペーパー
2010年6月
XAおよびOracleで制御する分散
トランザクション
XAおよびOracleで制御する分散トランザクション
はじめに.............................................................................................................................. 2
分散トランザクションの概要 ............................................................................................. 3
Oracleで制御する分散トランザクション ........................................................................... 4
XAベースの分散トランザクション..................................................................................... 6
X/Openの分散トランザクション処理モデル ................................................................. 6
JTAとJTS ....................................................................................................................... 7
XAトランザクションの概要 .......................................................................................... 8
リソース・マネージャ間のXAとポイント・イン・タイムのデータ整合性 ................ 10
XAとOracleで制御する分散トランザクションの使用 ....................................................... 11
XAタイムアウトとOracleデータベース ....................................................................... 11
分散トランザクションとデータベース・ロック ......................................................... 12
分散トランザクションと読取り専用の最適化 ............................................................ 14
分散トランザクションとREDO ................................................................................... 14
Oracleデータベース内の分散トランザクションの管理 .............................................. 14
XAとOracle Real Application Clusters......................................................................... 15
Oracleアカウントの権限 ............................................................................................. 19
XAとデータベース・リンク ........................................................................................ 19
Oracle Real Application Testingと分散トランザクション ........................................... 20
PL/SQLとXA ................................................................................................................ 20
中間層からのXAとOracleデータベースの使用................................................................. 21
XAおよびOracleのWebLogic Server / Fusion Middleware 11gR1 .............................. 21
XAとOracle 10gAsアプリケーション・サーバー/ Fusion Middleware 10g ................ 24
XAの典型的なアーキテクチャおよび設計の問題 ............................................................. 25
Oracleデータベースのリカバリ .................................................................................. 25
XA競合状態の回避 ....................................................................................................... 26
結論 ................................................................................................................................... 27
XAおよびOracleで制御する分散トランザクション
はじめに
今日のコンピューティング環境では、Java EEコンポーネント・ベースのアーキテクチャの採用によ
り、分散トランザクションや"グローバル"トランザクションの使用が広まっています。 分散トラン
ザクションは長年使用されており、1991年にはXA仕様が公開されましたが、アーキテクチャ内での
分散トランザクションの使用に関する設計上の意味については、明らかに認識が欠如しています。
このOracleホワイト・ペーパーでは、XAまたはOracleで制御する分散トランザクションの使用時に
考慮が必要な可能性がある、次の領域について説明します。
•
データのリカバリ能力：1つの処理に複数のポイントがあるため、すべてのデータソースをトラ
ンザクション上一貫性のあるポイントにリカバリできる場合にのみ、トランザクション一貫性を
維持できます。Oracleで制御するトランザクションの場合、システム変更番号（SCN）を使用し
てこれを実現できますが、リカバリ・プロセスに含まれるデータベースをすべて網羅するため、
データ損失レベルが上がる可能性があります。XA分散トランザクションでは、異種データソース
をトランザクション上一貫性のある同一ポイントに同期するのは簡単ではありません。
•
インダウト・トランザクション：障害時に、"インダウト"トランザクションが原因で、障害のあ
る分散トランザクションによって変更および"準備"されたデータにロックがかけられる場合があ
ります。"準備"トランザクションをリカバリしてこれらの変更を確認（コミット）または拒否（ロー
ルバック）するまでは、他のトランザクションが影響を受けるデータにアクセスできない場合が
あります。こうして単一の障害が、このデータを使用するアプリケーション内の幅広い機能に影
響する可能性があります。
•
パフォーマンス：分散トランザクションでは、分散した2フェーズ・コミット（'コミット準備'
フェーズなど）内に別のコミュニケーションが含まれていたり、トランザクション・ログ・レコー
ドの書込みが必要であったりするため、一般的に単一フェーズ・トランザクションと比べてパ
フォーマンス・オーバーヘッドが発生しやすくなります。
分散トランザクションは、同じビジネス・トランザクションで複数のデータソースの更新が必要で
あるか、製品の不可欠な要素（Oracle Application ServerのBPEL Process Managerなど）として使
用される場合にのみ使用してください。
2
XAおよびOracleで制御する分散トランザクション
分散トランザクションの範囲は小さくする必要があります。これは、障害の影響を限定し、カスタ
ム・リカバリ・プロシージャを簡素化するためです（カスタム・リカバリ・プロシージャは、すべ
ての関連データベース/データソースにわたってトランザクション一貫性をリストアする際に必要と
なる場合があります）。
分散トランザクションが含まれるアーキテクチャに取り組む前に、別の方法を検討してください。
たとえば、1つのデータソースによって他のデータソースへの更新を実行している場合、プライマリ
（駆動）・データソースへの更新前に、セカンダリ・データソースへの更新をコミットできます。こ
れらのコミット間でトランザクションが失敗すると、データはセカンダリ・データソース上でコミッ
トされますが、プライマリ（駆動）データソース上でロールバックされます。駆動データソースで
は、再起動時に（または通常のトランザクション処理の一部として）、処理の実行前に更新がセカ
ンダリ・データソースに（一意キーなどを使用して）適用されたかどうかがチェックされます。重
複が検出されるとトランザクションが破棄され、セカンダリ・データソースでの更新の成功を反映
してプライマリ・データソースが更新されます。
分散トランザクションの概要
分散トランザクションは、調整して管理する必要がある複数の関連するトランザクション・ブラン
チのセットです。トランザクションは、複数のデータソースにわたります。たとえば分散トランザ
クションには、データベース（Oracleなど）とメッセージ・キュー（MQ Seriesなど）、または2つの
独立したデータベース（Oracle同士など）間のトランザクションの管理が含まれる場合があります。
分散トランザクションを使用する場合、1つの処理に複数のポイントがあると、これが特にリカバリ
の際に大きな問題となる場合があります。リカバリでは、処理のすべてのポイントを、トランザク
ション上一貫性のある同一ポイントにリカバリする必要があるためです。ただし、おもな課題は通
常の動作中にトランザクション一貫性を維持するメカニズムを持つことです。これは、2フェーズ・
コミット・メカニズムを使用することで実現できます。
2フェーズ・コミット・メカニズムは、2つの主要フェーズ（"準備"および"コミット"）に分けられま
す。準備フェーズでは、トランザクションのコーディネータによって、他の参加データベース/デー
タソースに対してトランザクションのコミットやロールバックが指示されます。参加データベース/
データソースは、トランザクションを"準備"として継続的に記録し、トランザクション・コーディネー
タにレスポンスを返信します。コミット・フェーズ中に、すべてのトランザクション参加者がトラ
ンザクションのコミットに同意すれば、トランザクション・コーディネータはすべての参加者にト
ランザクションのコミットを指示します。トランザクションのコミットに同意しない参加者がいる
場合、トランザクション・コーディネータはすべての参加者に対してトランザクションのロールバッ
クを指示します。すべての参加者に対してコミットまたはロールバック要求の実行完了が通知され
ると、トランザクションが完了し、トランザクション・コーディネータは分散トランザクションを
削除するか、その存在を"忘却"できます。これは、"忘却フェーズ"と呼ばれることがあります。トラ
ンザクション・コーディネータが競合する分散トランザクションに関する情報を削除する方法と時
期に関しては、実装固有です。
3
XAおよびOracleで制御する分散トランザクション
ほとんどの2フェーズ・コミットの実装には、"読取り専用"最適化が含まれます。この場合、変更が適用
されていないデータソースは、準備フェーズ中に分散トランザクションの範囲から除外されます。
また、"単一フェーズ"最適化も実装に含まれる場合があります。この場合、開いたり更新したりする
データソースが1つだけであると、単一フェーズでコミットされるトランザクションで準備フェーズ
が省略されます。
分散トランザクション内のすべての参加者は、同じアクションを実行する必要があります。つまり、
参加者すべてがトランザクションのコミット、またはロールバックのいずれかを実行する必要があ
ります。トランザクション・コーディネータは分散トランザクションのコミットやロールバックを
自動的に制御/監視し、2フェーズ・コミット・メカニズムを使用してトランザクションの整合性を維
持します。
ただし、コーディネータが使用できなくなったため準備フェーズとコミット・フェーズで障害が発
生すると、トランザクションとその関連データが"インダウト"状態のままになる場合があります。"
インダウト"としてマークされたデータソース内のデータは、トランザクション・コーディネータや
（DBAやシステム管理者などによる）外部の操作によってトランザクション結果が解決されるまで変
更できません。ほとんどの場合、トランザクション・コーディネータがデータソースと通信できれ
ば、インダウト・トランザクションは自動的にリカバリされます。インダウト・トランザクション
で重要なデータ・リソースがロックされているか、マシン、ネットワーク、ソフトウェアの障害原
因を迅速に修復できない場合にのみ、手動で解決してください。
通常、2フェーズ・コミット・メカニズムは完全に透過的で、ユーザーやアプリケーション開発者に
よるプログラミングは不要です。ただし、トランザクション・コーディネータは必要です。データ
ベース（Oracleなど）、トランザクション・モニター（Oracle Tuxedoなど）、またはアプリケーショ
ン・サーバー（Oracle WebLogic Serverなど）がこの機能を実行できます。
Oracleで制御する分散トランザクション
Oracleデータベースを使用して、1つのトランザクションに参加している複数のOracleデータベース間
の分散トランザクションを調整できます。この項では、データベース・リンクを利用するトランザ
クションのみを説明します。分散トランザクションの一部としてデータベース・リンクを使用する
Oracleベース製品の例としては、アドバンスト・レプリケーションとOracle AQの伝播を取り上げま
す。Oracleデータベース内で使用される分散トランザクション・メカニズムは他にもありますが（XA
や、手続き型ゲートウェイが使用するメカニズムなど）、この項で説明する標準的な分散トランザ
クション処理とは異なります。
前述のように、Oracleの分散トランザクション・メカニズムには、"読取り専用"と"単一フェーズ"と
いう最適化があります。データベースに対して準備が指示され、そのデータベースで更新が実行さ
れなかった場合、データベースは読取り専用ステータス・コードを返し、トランザクションには参
加しなくなります。Oracle内で分散トランザクションを実行するには、同じトランザクション内の複
数のデータベースに対して変更を実行する必要があります。1つのデータベースだけを更新した場合
は準備フェーズが省略され、分散トランザクションではなく"リモート"トランザクションと見なされ
ます。
分散/リモートいずれのトランザクションでも、開始データベースがそのトランザクションのグロー
バル・コーディネータです。更新されたデータベースのうち、
4
XAおよびOracleで制御する分散トランザクション
COMMIT_POINT_STRENGTHが一番大きいデータベースがトランザクションの "コミット・ポイン
ト・サイト"として指定されます。リモート・トランザクションの場合、更新されたデータベースの
みがコミット・ポイント・サイトになります。"コミット・ポイント・サイト"は、トランザクション
のステータスが記録される単一ポイントで、他のデータベースがトランザクションに含まれる前に
コミットします。これは"準備"状態にならない唯一のデータベースであり、このため障害の'インダ
ウト'トランザクションは含まれません。実際、コミット・ポイント・サイトでの分散トランザクショ
ンやリモート・トランザクションの結果によって、トランザクションがコミットされるかロールバッ
クされるかが決まります。他のノードが含まれる場合は、コミット・ポイント・サイトの指示に従
います。グローバル・コーディネータは、分散トランザクション内のすべてのノードで、トランザ
クションがコミット・ポイント・サイトと同じ方法で完了できるようにします。
分散トランザクションの場合、コミット・ポイント・サイトとして選択されたデータベースは最重
要データを保存するデータベースである点に注意してください。このデータベースは準備状態にな
らないため、障害が発生しても"インダウト"になることはありません。障害が発生すると、障害のあ
るノードは準備状態のままとなり、"インダウト"トランザクションが解決されるまで影響を受ける
データがロックされたままです。
Oracleの2フェーズ・コミット・メカニズムには、次の固有のフェーズがあります。このフェーズは、
分散トランザクションのコミット時にデータベースで自動的に実行されます。
•
準備フェーズ：グローバル・コーディネータはコミット・ポイント・サイト以外の参加ノードに
対し、（障害があっても）トランザクションのコミットまたはロールバックを実行するよう指示
します。準備できないノードがあると、トランザクションはロールバックされます。
•
コミット・フェーズ：コーディネータは、すべての参加者から準備完了の応答を受けると、コ
ミット・ポイント・サイトに対してコミットを指示します。コミット・ポイント・サイトがコ
ミットした後、コーディネータは他のすべてのノードに対してトランザクションのコミットを
指示します。
•
忘却フェーズ：グローバル・コーディネータはトランザクションを忘却します。
Oracle内では、コミットされたトランザクションごとにシステム変更番号（SCN）が関連付けられて
おり、各トランザクション内でのSQL文の変更を一意に識別できます。OracleはSCNを利用して、問
合せの読取り一貫性を維持します。データベースごとに個別に保持する固有のSCNがあるため、あ
るデータベースが、分散トランザクション内の他のデータベースに関しては古いものである可能性
があります。このギャップによる影響を最小限にするため、各リモートSQL文の終了時、および各ト
ランザクションの開始時と終了時に、分散トランザクション内のSCNが同期されます。このSCN
ギャップにより、（リモート・データベースへの最新の変更が反映されていないような）少し古い
スナップショットを使用する問合せを実行できます。このため問合せで、読取り一貫性に従って、
一貫性はあるが古いデータが取得される場合があります。問合せで取得したデータが古いSCNから
のものであり、このためローカルで実行する更新トランザクションによってリモート・ノードの2つ
の表が更新された場合、次回のリモート・アクセスで両方の表から選択されるデータには更新前の
データが含まれます。特定の問合せでSCN同期を必要とする場合、一般的な回避策として、各リモー
ト問合せの前に、同じサイトに対してダミーのリモート問合せ（SELECT * FROM DUAL@REMOTE
など）を実行します。
5
XAおよびOracleで制御する分散トランザクション
SCNの調整/同期のメリットの1つは、単一SCN（トランザクション）に対し、すべてのデータベース
の未完了リカバリを達成できることです。このため、（災害時などに）データベースを1つだけ部分
的にリカバリできるような場合であっても、トランザクション一貫性を維持できます。ただしリカ
バリが未完了であると、欠落したトランザクションをすべて再生するカスタム・メカニズムがない
限り、すべてのデータベース間でデータ損失が発生します。
Oracleが制御する分散トランザクション内の別の障害シナリオをシミュレートするには、My Oracle
Support Note 126069.1 Manually Resolving In-Doubt Transactions: Different Scenarios（インダウト・トラ
ンザクションの手動による解決：別のシナリオ）を参照してください。
XAベースの分散トランザクション
X/Openの分散トランザクション処理モデル
XAの標準は、異種データソース間（Oracle DatabaseとDB2など）の分散トランザクション処理（DTP）
のためのX/Open仕様です（1991年に公開）。
この仕様は、分散トランザクションに参加するトランザクション・コーディネータとデータソース
間のインタフェースについて記述しています。XA内では、トランザクション・コーディネータはト
ランザクション・マネージャ、参加するデータソースはリソース・マネージャと呼ばれます。この
仕様に従うトランザクション・マネージャとリソース・マネージャは、XA準拠と呼ばれます。
OracleデータベースやOracle WebLogic Serverなどの一部の製品は、同じXAトランザクション内で、
トランザクション・マネージャやリソース・マネージャ、またはその両方として機能できます。
XAトランザクション・マネージャとしては、たとえばTuxedo、Oracle WebLogic Server、Oracleデー
タベース、IBM WebSphere Application Serverなどがあります。XAリソース・マネージャとしては、
たとえばOracle Database、IBM DB2、MS-SQL、IBM MQ-Series、JMSなどがあります。
XAといえば、ほとんどの組織ではXA仕様のバージョン1を意味します。ただし、1994年にはXA+仕
様と呼ばれるバージョン2のスナップショット（ドラフト）が公開されました。このバージョンは批
准されておらず、技術標準として正式に公開されていないため、主要なXAベンダーでは使用されて
いません。XA+仕様は、複数の異種トランザクション・マネージャ間（TuxedoとIBM Encinaなど）
での分散トランザクションの調整を可能にし、トランザクション・マネージャと複数のRMインスタ
ンス（Oracle Real Application Clusters（Oracle RAC）など）の通信方法を決定する拡張仕様です。XA
仕様のバージョンは、My Oracle Support Note 180207.1 The XA specification for Distributed Transaction
Processing（分散トランザクション処理用のXA仕様）にも記載されています。
X/Open DTPモデルについては、次の図を参照してください。アプリケーション・プログラム（AP）
は、XA準拠の複数のリソース・マネージャ（RM）を更新します。XA準拠のトランザクション・マ
ネージャ（TM）によってすべての更新が調整されるため、すべてのRMのトランザクション一貫性
が確保されます。各RMには、TMが調整する分散トランザクションのブランチが1つ以上含まれます。
分散トランザクションのすべてのブランチは、1つの作業単位としてコミットまたはロールバックさ
れる必要があります。
6
XAおよびOracleで制御する分散トランザクション
X/Open DTPモデル内では、APは すべてのDMLでRMのネイティブ・インタフェース（SQLなど）を
使用してRMと通信します。また、APはTXプロトコルを使用してTMと通信し、トランザクション境
界を決定します。TXプロトコルには、多くの"標準"実装があります。たとえば、XATMI（Tuxedoベー
ス）、TxRPC（DCEベース）、XCPI-C（IBM Encinaベース）などです。すべてのTMが、これらの実
装をすべてサポートするわけではありません。たとえば、TuxedoはXATMIおよびTxRPC標準しかサ
ポートせず、IBM EncinaはTxRPCおよびXCPI-C標準しかサポートしません。TMはXAプロトコルを
使用してすべてのRMと通信し、2フェーズ・コミットを調整します。
JTAとJTS
X/OPEN DTPモデルの使用は主にトランザクション・マネージャ（TuxedoやEncinaなど）に限定され
ますが、 X/Open DTPの概念は広く展開されています。たとえばXA仕様は、Java EE内のJava APIの
標準セットとして実装され、Java Transaction API（JTA）仕様として知られています。JTAによって、
Javaベースのトランザクション・マネージャが分散トランザクションを実行できます。JTAは基本的
にX/Open DTPモデルですが、TXプロトコルをJava APIのセットに置き換えます。アプリケーション・
プログラムはこのセットを使用して、トランザクション境界を決定します。JTAトランザクション・
マネージャの例としては、Oracle WebLogic Serverがあります。
7
XAおよびOracleで制御する分散トランザクション
またJava EE仕様にはJava Transaction Service（JTS）も含まれます。JTSは、高レベルでJTA仕様をサ
ポートするJavaラッパーです。一方、OMGのObject Transaction Service（OTS）のJavaマッピングは低
レベルで実装します。OTSはOMGのCommon Object Request Broker Architecture（CORBA）のコンポー
ネントで、あまり採用されていません。OTS仕様はX/Openの支援を受けて構築され、異種または複
数のトランザクション・マネージャ間で分散トランザクションを調整できるようにするための手段
を提供するという、XA+内で提案された概念に基づいています。またOTSモデルでは、X/Open DTP
モデル内で定義された機能的なXA/TXインタフェースが、CORBA固有のインタフェースに置き換え
られました。OTSモデルは、X/Open DTPモデルと完全に相互運用可能です。繰り返しになりますが、
XAインタフェースはTMとRM間のすべての通信を支えています。JTSはOTSモデルを実装してはい
ませんが、OTS / COBRA準拠のトランザクション・マネージャにインタフェースの仕様を提供して
います。
XAトランザクションの概要
XA内で、TMは分散トランザクションのすべてのブランチを調整し、その制御内のすべての分散ト
ランザクションに関する状態情報を保持します。この状態情報が失われたり使用できなくなったり
すると、基盤となるRMで、手動操作によるインダウト・トランザクションの解決が必要となる場合
があります。
分散トランザクションの進捗の調整/監視はTMが担当するため、アプリケーション・プログラム
に（分散トランザクションを個別にロールバック/コミットする）RM固有の文が含まれないよう
にしてください。したがって、アプリケーション・プログラムからDDL（TRUNCATE、CREATE
TABLEなど）が発行されないようにしてください。これはDDL自体が暗黙的な自己完結型のト
ランザクションであるためです。特別に許可される文について確認するには、必ずRMのマニュ
アルを確認してください。
XAの2フェーズ・コミット・メカニズムには、次の固有のフェーズがあります。このフェーズは、
アプリケーション・プログラムによる分散トランザクションのコミット時に、TMおよびRMによっ
て自動的に実行されます。
•
準備フェーズ：TMは参加RMに対し、要求に応じて（障害があっても）トランザクションのコミッ
ト（またはロールバック）を実行するよう指示します。準備できないRMがあると、トランザク
ションはロールバックされます。
•
コミット・フェーズ：TMはすべてのRMから準備完了の応答を受けると、RMに対してトランザ
クションのコミットを指示します。
前述の2フェーズ・コミットの項で説明したとおり、XAは"読取り専用"と"単一フェーズ"の両方の最
適化をサポートします。
XA分散トランザクション内には、1つ以上のRMに対して作業を実行する複数のトランザクション・
ブランチがあります。単一RM内では、これらのブランチが関連する場合があります。参加ブランチ
のペア間の関係は、密結合か疎結合です。トランザクション・ブランチが密結合の場合、これらの
ブランチはロックを共有します。このため密結合トランザクションでは、あるトランザクション・
ブランチ内のプリコミットの更新を、同じ分散トランザクションに属する他のブランチでも確認で
きます。疎結合のトランザクション・ブランチでは、ブランチ間でロックを共有せず、他のブラン
チの更新を確認できません。
8
XAおよびOracleで制御する分散トランザクション
密結合のトランザクションでは、XAトランザクションの個別のブランチ間でリソース・デッドロッ
クが発生しないことをRMが保証する必要があります。実装方法はRMによって決定されますが、す
べての密結合ブランチにわたって同時データ・アクセスが制限される可能性があります（同時にDML
をアクティブに使用できるのが、1つのブランチに限定されるなど）。
XA標準では、分散トランザクション内の1つ以上のトランザクション・ブランチをヒューリスティッ
クに完了できます。通信障害が発生した場合、一部のRMではTMとは関係なく、ヒューリスティッ
クに準備トランザクションをコミットするかロールバックするかが決定される場合があります。た
とえば、これにより共有リソースのロックは解除されるかもしれませんが、残りの分散トランザク
ションに関しては、データが一貫性のない状態のままになる可能性があります。たとえばあるRMが
ブランチをコミットし、他のすべてのブランチに対してはロールバックの指示が出された場合、す
べてのRMが一貫性のない状態になります。または、（DBAやシステム管理者などによる）手動操作
でロック解除される場合もあります。この場合も、分散トランザクションがヒューリスティックに
完了されます。ヒューリスティックな完了をTMに報告するRMの場合、そのRMはトランザクショ
ン・ブランチのナレッジを破棄しません。このため、分散トランザクションの結果を手動で解決し
ても、ヒューリスティック・トランザクションの参照は、手動で削除するまでRM内に残る可能性が
あります。
XA標準では、動作の同期/非同期モードも可能です。非同期モードはオプションで、Oracleデータベー
スではサポートされていません。
XAで制御する分散トランザクション内の別の障害シナリオをシミュレートするには、次のMy Oracle
Support notesを参照してください。
•
50743.1 Session Switching & Global Transaction Mgt（セッション切り替えと'C'ソース・プログラム
を提供するグローバル・トランザクションの管理）
•
227352.1 Demonstration of Integrating OJMS operations within an XA Transaction（XAトランザクショ
ン内でのOJMS動作の統合デモ、Javaソース・プログラムを提供）
Oracleで制御する分散トランザクションとは異なり、XA仕様では、参加データベース間で'ポイント・
イン・タイム'マーカーについて同意することはできません（前述のOracleで制御する分散トランザク
ションで説明したSCN同期などと同じです）。つまり、1つ以上のRMの不完全リカバリが必要な場
合、すべてのRMをトランザクション上一貫性のある同一のポイント・イン・タイムに集めるメカニ
ズムはありません。不完全リカバリの場合、次の2つのオプションがあります。
•
アプリケーション固有のリカバリ・メカニズムを設計し、不完全リカバリの実行時にすべてのRM
でトランザクションの一貫性が維持されるようにする。
•
RMでアクティビティがほとんど（またはまったく）ないポイントにポイント・イン・タイム・
リカバリを実行する（たとえば、コールド・バックアップまたはリカバリから、アプリケーショ
ン停止時のポイントまで）。Oracle内で不完全リカバリを実行する時期を特定するメカニズムに
ついては、My Oracle Support Note 52776.1 Determining a Point In Time for Incomplete Recovery under
XA（XAで不完全リカバリのポイント・イン・タイムを決定する）を参照してください。
9
XAおよびOracleで制御する分散トランザクション
リソース・マネージャ間のXAとポイント・イン・タイムのデータ整合性
OLTPシステム内では、多くのトランザクションが特定のポイント・イン・タイムで発生している可
能性があり、個々のトランザクションの状態がRM間で異なるため、トランザクションのすべてのブ
ランチが必ずしも同じポイント・イン・タイムで完了するとは限らないという点に注意してくださ
い。前述のとおり、これはバックアップとリカバリ、および特定のポイント・イン・タイムですべ
てのRM間のトランザクション一貫性が保たれていることを前提とするアプリケーション設計に影
響します。
XA仕様には、TMがRMに対してコミットを要求する順序や、RMでコミットが必要な時間枠につい
ては規定されていません。コミットに同意したすべてのRMが、データをコミットする必要があると
だけ記載されています。このため特に、処理が1つ以上のRMへの書込み順序に依存する場合、競合
状態が発生する可能性があります。
これは重要な点です。あるRMでの分散トランザクションによる変更が、同じ分散トランザクション
内の他のRMで使用可能になる前に、分散トランザクションを個別に実行するアプリケーション・プ
ログラムで読み取れる可能性があるためです。注：TMがRMに対してコミットを要求するシーケン
スの順序に決まりはないため、最初にコミット要求を受けるRMは、同じ分散トランザクション内の
最後のRMがコミット要求を受ける前に、変更を表示できます。逆に言えば、RMがTMに対してコミッ
トを通知済みであっても、RMの他のユーザーが変更を使用できるようにするには、これらの変更の
処理が必要な場合があります。同じ分散トランザクション内で複数または別のRMを使用する場合、
コミットを実行したり他のユーザーにこれらの変更を表示したりするための処理レベルはさまざま
です。したがって、
分散トランザクション内でTMから最初にコミット要求を受けたRMより前に、最後にコミットを指
示されたRMで変更が表示される場合があります。いずれにしても、すべてのRMでコミットが実行
され、変更が表示されるまでは、トランザクション一貫性は保証されません。コミット・フェーズ
を実行中の場合、独立したリーダーに対して、複数のRM間で整合性のないデータが表示される場合
があります。
特定のポイント・イン・タイムでのデータ整合性の問題の影響がもっとも大きくなる傾向があるの
は、キュー・ベースのアーキテクチャです。たとえば、トランザクションで1つ以上のデータベース
とファイル・ベースのメッセージ・キューが更新されるとします。コミット・フェーズ中に独立し
たプロセスでキューが監視され、キューからメッセージが読み取られる場合、更新中のデータベー
スのリーダーが、対応する更新を利用できない可能性があります。このようなユースケースでは、
独立したキュー読取りプロセスが失敗する可能性があります（予期される変更を検出できなかった
り、分散トランザクション開始前の有効値に基づいてデータ変更を終了できなかった場合）。
10
XAおよびOracleで制御する分散トランザクション
XAとOracleで制御する分散トランザクションの使用
XAタイムアウトとOracleデータベース
XA実装内では、多くのタイムアウトが使用されます。これは主に、準備フェーズとコミット・フェー
ズ間のロックの問題を回避するためです。たとえば、準備段階の後にTMが消失した場合、障害の発
生したTMインスタンスが管理している可能性のある他のトランザクションのロックを、RMが解除
できる必要があります。これらのタイムアウトの目安として、RMが使用するタイムアウトが、TM
が使用するタイムアウトより長い必要があります。これにより、TMが常に分散トランザクションを
制御できます。
たとえば、RMのタイムアウトがTMのタイムアウトより短いと、RMが制御TMを参照せずにトラン
ザ クシ ョンを 破棄 して しまう 可能 性があ りま す。 この場 合は 通常、 Oracleデ ー タベ ース から
"ORA-24756: Transaction does not exist"というレスポンスがあります。
Oracle XA実装内には、分散トランザクション内の障害の特定に使用される多くのタイムアウトがあ
ります。これらのタイムアウトのうち次の2つは、xa_open apiを使用して最初に接続を開く際に、TM
からOracleに渡されます。
•
SesTm（セッション・タイムアウト）- トランザクションがこの時間より長く非アクティブ状態
であると、トランザクションが自動的に中断されます。たとえば、TMがクライアントとサーバー
間でリモート・プロシージャ・コール（RPC）を使用している場合、あるRPCの完了から次のRPC
の開始までの間や、コミット/ロールバックの間の時間にSesTMが適用されます。
•
SesWt（セッション待機）- 他のセッションが使用しているトランザクション・ブランチの待機
がタイムアウトするまでの上限値です。デフォルト値は60秒です。
SesTM / SesWtタイムアウトは、いずれもTM固有の構成ファイルでデータベース接続文字列を使用し
て設定されます。SesTMは必須で、SesWtはデフォルト値のままの場合もあります。接続文字列の例
は次のとおりです。
ORACLE_XA+SqlNet=SID3+ACC=P/user/pwd +SesTM=10+LogDir=/usr/local/xalog
SesTM / SesWtタイムアウトが、JDBC接続経由で管理されるXAトランザクションに適用されません。
この場合は、代わりにsetTransactionTimeoutメソッドを使用します。
同様にPL/SQL（Oracle Database 11gR1以降）の場合、DBMS_XAパッケージ内のXA_SETTIMEOUT
関数を使用してトランザクション・タイムアウトを設定します。デフォルト値は60秒です。また、
次のタイムアウトも考慮する必要があります。
•
TMのグローバル・トランザクション・タイムアウト（Java EEベースのアプリケーション・サー
バーの場合はJTAタイムアウト）
•
Oracleデータベースの初期化パラメータDISTRIBUTED_LOCK_TIMEOUT（分散トランザクショ
ンのロックまでの待機時間を制限します）
•
Oracleデータベースのユーザー・プロファイル内のCONNECT_TIMEおよびIDLE_TIMEパラメー
タ（通常、DEFAULTプロファイルでは両方ともデフォルトでUNLIMITED）
11
XAおよびOracleで制御する分散トランザクション
通常、これらのタイムアウトは次の順序で設定します。
1. TMのグローバル・トランザクション・タイムアウト（またはJTAタイムアウト）<
2. SesTmおよびSesWt（JDBCまたはPL/SQLのトランザクション・タイムアウト）<
3. DISTRIBUTED_LOCK_TIMEOUT <
4. CONNECT_TIMEとIDLE_TIMEのいずれか
Oracle内でセッションがタイムアウトすると、Oracleデータベースのプロセス・モニター（PMON）
によってトランザクション・ブランチが削除されます（準備されていなかったり、準備されていて
もトランザクションのインダウトの原因になっていたりする場合）。プロセス・モニター（PMON）
がアクティブでない場合は60秒ごとにアクティブ化されるため、セッション・タイムアウトが経過
してからセッションが消去されるまで、最大60秒の遅延があります。したがって、最後のアクショ
ン（"準備"など）が実行されてから、次にトランザクションがロールバックされたり"インダウト"
トランザクションとして表示されたりするまでの時間は、SesTmタイムアウト+最大60秒です。
ト ラ ン ザク シ ョン が タ イムア ウ ト して "イ ン ダウ ト "に な る と 、 DBA_2PC_PENDINGビ ュ ー と
DBA_PENDING_TRANSACTIONSビューに表示されます。"インダウト" 状態のトランザクションが
原因で、その後にこのデータにアクセスするトランザクションが失敗する場合があります。この場
合、"ORA-01591 lock held by in-doubt distributed transaction <tran id >"というメッセージが表示されま
す。ほとんどの場合、TMがRMと通信できれば、インダウト・トランザクションは自動的にリカバ
リされます。インダウト・トランザクションで重要なデータ・リソースがロックされているか、マ
シン、ネットワーク、ソフトウェアの障害原因を迅速に修復できない場合にのみ、手動で解決して
ください。ただしトランザクションを手動で解決すると、分散トランザクションがヒューリスティッ
クに完了する場合があり、それ自体を後で解決する必要があります。
また、DISTRIBUTED_LOCK_TIMEOUTが小さい値に設定されている場合は、トランザクションが他
のセッションの完了を待機しているためにタイムアウトする場合があります。この場合は、"Error ORA-02049 timeout: distributed transaction waiting for lock"というメッセージが表示されます。
分散トランザクションとデータベース・ロック
密結合の分散トランザクションはすべて、トランザクション上でアクティブに動作している間に
DX（分散トランザクション）エンキューを取得します。このエンキュー（メモリ・ロック）を
使用して、分散トランザクションの複数のブランチ間のデータベースへのアクセスをシリアライ
ズします（これでトランザクションの1つのブランチだけがポイント・イン・タイムでSQLをア
クティブにできます）。
単一インスタンス・データベースのデプロイメント内では、デフォルトですべての分散トランザク
ションが密結合されています。XAトランザクション・マネージャは、分散トランザクションの開始
時にこれを上書きできます。
同様に、複数インスタンスのOracle RAC環境内では、すべての分散トランザクションがデフォルト
で密結合されています。ただし、Oracle Database 11gR1 RACより前のバージョンでは、DXエンキュー
は各インスタンス内に個別に保持されていました。Oracle Database 11gR1 RAC以降、この点は変更さ
れ、密結合の分散トランザクションごとにクラスタ全体のDXエンキューが取得されるようになりま
した。このクラスタ全体のDXエンキューは、 Global Enqueue Service（GES）によってOracle RAC内
で管理され、分散トランザクションがクラスタ内の複数のデータベース・インスタンスにまたがる
場合は、このエンキューの制御がデータベース・インスタンス間で転送されます。ただし、複数の
密結合トランザクション・ブランチが同時にアクティブになることはできません。
12
XAおよびOracleで制御する分散トランザクション
DXエンキュー処理内の変更を補完するため、11gR1 RACのOracle Databaseの読取り一貫性メカニズ
ムによって、密結合トランザクションの1つのトランザクション・ブランチで実行されるプリコミッ
トの更新をすべて、データベースの別のインスタンス内の他の密結合ブランチに対して表示できま
す。11gR1より前のバージョンでは、あるデータベース・インスタンスでの変更を、同じデータベー
スの他のインスタンス上のブランチに対して表示できませんでした。
疎結合の分散トランザクションは互いに独立しており、DXエンキューを取得せず、別のトランザクショ
ン・ブランチにわたるトランザクション・アクティビティをシリアライズする必要はありません。
分散トランザクション内の複数のブランチを使用することで、すべてのトランザクション・ブラン
チで2フェーズ・コミットが必ず実行されます。つまり、同一のデータベースに対して、同一の分散
トランザクションの複数のブランチが発生した場合、XAの"単一フェーズ"最適化は使用できないと
いうことです。
通常、Oracleは読取り文の開始時にSCN（システム変更番号）に基づいて読取り一貫性を維持し、読
取り文の実行前にコミットされた変更だけが返される結果セットに含まれます。ただし分散トラン
ザクションの場合は、準備フェーズとコミット・フェーズの間に、リーダーをブロックしてブロッ
ク・レベル・ロックを取得できるという例外があります。
10gR2より前のバージョンでは、外部調整された分散トランザクション（XA）はOracle分散トランザ
クションのロック戦略に従っており、変更データをブロック・レベルでロックし、準備段階とコミッ
ト段階の間にリーダーをブロックしていました。たとえばリーダーは、変更がコミットされるまで
前後のイメージを確認できませんでした。10gR2以降にこの動作は変更され、外部調整された分散ト
ランザクションがリーダーを行レベルでロックし、準備フェーズとコミット・フェーズの間はブロッ
クしないようになりました。パッチ3566945を使用すれば、前のバージョンのデータベースにもこの
動作を適用できます。このパッチは、9.2.0.6と10.1.0.3のパッチセットに組み込まれています。
ただしOracleで制御する分散トランザクションの場合、機能変更はありません。準備フェーズとコ
ミット・フェーズの間にリーダーがブロックされ、ブロック・レベル・ロックが取得されます。Oracle
で制御する分散トランザクション内では、変更のコミットSCNが現行システムのSCNより小さいため、
読取り時に準備済みのトランザクションが他のリーダーに対して表示されるかどうかが不明です。
Oracleで制御する分散トランザクションでは、コミット・フェーズ中にトランザクションに含まれる
すべてのデータベースでSCNが揃うように調整されます。
他のトランザクションが変更した行を変更するXA / Oracle分散トランザクションは、ロック・トラン
ザクションが完了するまで待機します。TMトランザクションのタイムアウトまたはデータベース
DISTRIBUTED_LOCK_TIMEOUTが原因で待機中の分散トランザクションがタイムアウトする前に、
ロック・トランザクションが正常に完了することが理想的です。ロック・トランザクションが"イン
ダウト"になると、"ORA-01591 lock held by in-doubt distributed transaction <tran id>"というメッセージ
が表示されて待機中のトランザクションが失敗します。ロック・トランザクションがデータベース
DISTRIBUTED_LOCK_TIMEOUT（タイムアウトなしの単一フェーズ・トランザクションなど）より
長く実行されると、デッドロックのような状態となり、"ORA-02049: timeout: distributed transaction
waiting for lock"というメッセージが表示されてXA / Oracle分散トランザクションが失敗する場合が
あります。タイムアウトの順序が正しければ、XA分散トランザクション内でこのエラーが発生する
ことはありません。DISTRIBUTED_LOCK_TIMEOUTに達する前に、TMのタイムアウトを超過する
ためです。
13
XAおよびOracleで制御する分散トランザクション
準備とコミットの間に分散トランザクション・ブランチが失敗すると、トランザクション・コーディ
ネータによって解決されるまでトランザクションは"インダウト"になります。この場合、失敗したト
ランザクションで変更された行はすべて、トランザクションが正常に解決されるまでロックされま
す。このロックされたデータにアクセスしようとするトランザクションはすべて失敗し、"ORA-01591
lock held by in-doubt distributed transaction <tran id >"というメッセージが表示されます。
分散トランザクションを使用するアプリケーションは、行レベルとブロック・レベルの両方で競合
が発生しないように設計する必要があります。トランザクションが同じデータや索引にアクセスす
る必要がある場合、単一フェーズ・コミットに加えて準備/コミット・フェーズが実行されるため本
来の待機時間が長くなり、パフォーマンスやスループットが大幅に低下します。たとえば、一意で
ない索引を同一部分に大量に挿入すると、基盤となるリーフの分割時に索引ヘッダー・ブロックで
の競合原因となります。同様に、"インダウト"トランザクションによって、データの同じ行やブロッ
クにアクセスする必要がある複数のアプリケーションのカスケーディングに、壊滅的な影響が出る
可能性があります。
分散トランザクションと読取り専用の最適化
Oracle RAC 11gR1より前のバージョンでは、分散トランザクションの読取り専用最適化はOracle RAC内の
データベース・インスタンス・レベルのみで行われていました。
分散トランザクションが複数のOracle RAC
データベース・インスタンスを使用する場合、読取り専用最適化は行われませんでした。
11gR1以降、分散トランザクションが複数のOracle RACデータベース・インスタンスを使用する場合
は、分散トランザクションの読取り専用最適化が行われるようになりました。
分散トランザクションとREDO
XAおよびOracleの分散トランザクションでは、準備/コミット・フェーズ中のREDOレコードが書込
まれます。11gR1では、同じ分散トランザクションに複数のデータベース・インスタンスが含まれる
場合、準備段階で別途兄弟関係レコードが書込まれます。準備中にREDOに書き込まれるレコードは
内部REDOレコードであり、Oracle Log Minerには表示されません。REDOログを使用してデータベー
スを不完全にリカバリすると（たとえば、バックアップからポイント・イン・リカバリを実行した
り、非同期Data Guardを使用したりして、一部のREDOが失われるなど）、トランザクションが"イン
ダウト"のままになる場合があります。
Oracleデータベース内の分散トランザクションの管理
Oracleデータベースでは、データベース内の分散トランザクションに関する次の情報にアクセスでき
ます。
•
未解決の分散トランザクション（準備済みや待機中のコミット/ロールバックなど）に関する情報
は、DBA_PENDING_TRANSACTIONSシステム・ビューに表示されます。
•
リカバリ待機中の分散トランザクション（"インダウト"トランザクションなど）に関する情報は、
DBA_2PC_PENDINGシステム・ビューに表示されます。
•
現在アクティブな分散トランザクションに関する情報は、V$GLOBAL_TRANSACTIONシステ
ム・ビューに表示されます。
14
XAおよびOracleで制御する分散トランザクション
•
Oracle分散トランザクション内の保留中トランザクションの着信/発信接続要求に関する情報は、
DBA_2PC_NEIGHBORSシステム・ビューに表示されます。
TMがトランザクションをリカバリできなくなった場合は、"インダウト"トランザクションを手動で
コミット（commit force 'tran_id'）、または手動でロールバック（rollback force 'tran_id'）できます。可
能であれば、TMが分散トランザクションをリカバリできるようにして、（トランザクションに含ま
れるRMごとに結果が異なるなどの）ヒューリスティックな完了を回避します。
手 動 で 解 決 さ れ た 古 い 分 散 ト ラ ン ザ ク シ ョ ン の 消 去 は 、 EXECUTE
DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('<tran_id>')を使用して実行できます。この手順の
使用方法の詳細については、My Oracle Support Note: 159377.1 How to Purge a Distributed Transaction
from a Database（データベースから分散トランザクションを消去する方法）を参照してください。
XAとOracle Real Application Clusters
Oracle RACには、多くの制限/ベスト・プラクティスがありますが、主として次のものがあります。
•
11gR1より前のバージョンでは、トランザクション・ブランチ全体を同じデータベース・インス
タンスで実行する必要があります。フェイルオーバー時には、デプロイするOracle RACのバー
ジョンによって特別な条件が適用されます。
•
11gR1より前のバージョンでは、XAトランザクションをインスタンス間でロードバランシングし
ないでください。XA仕様では、接続ロードバランシングを使用する場合、TMがトランザクショ
ン・ブランチを一時停止/再開できます。再開した接続はトランザクション・ブランチが開始され
たOracleインスタンスとは別のインスタンスに配置される可能性があります。11gR1以降、この制
限はデフォルトで解消されました。ただし、単一の分散トランザクションが複数のデータベー
ス・インスタンスにわたる場合は、パフォーマンス上の影響があります。
•
Oracle RAC内のトランザクションID（XID）のグローバル一意性を保証するフェイルセーフ
機能はありません。Oracle RACでは、Oracle RACクラスタ内のすべてのインスタンスの間で、
特定のXIDが一意であることをチェックすることはできません。TMはXIDのグローバル一意
性を維持する必要がありますが、XA仕様によると、RMは常にTMが提供するXIDを受け入れ
る必要があります。
•
11gR1より前のバージョンでは、密結合トランザクション間で相互の変更点を確認できない事態
を避けるため、密結合分散トランザクションのすべてのトランザクション・ブランチを同じイン
スタンスに置く必要がありました。同様に、すべての疎結合トランザクションを同じデータベー
ス・インスタンスに置くことが（必須ではありませんが）推奨されていました。これは、同じ分
散トランザクション内の複数のトランザクション・ブランチから異なる結果が出ることを回避す
るためです（1つのブランチではロールバック済み、別のブランチではコミット済みになるなど）。
11gR1以降は、これらの制限は解消され、クラスタ内のすべての分散トランザクションはデフォ
ルトで密結合になっています。ただし、単一の分散トランザクションが複数のデータベース・イ
ンスタンスにわたる場合は、パフォーマンス上の影響があります。
15
XAおよびOracleで制御する分散トランザクション
TMとRM（データベース）インスタンス間でインスタンスまたはネットワーク接続が喪失した後、
Oracle RACクラスタ内の代替インスタンスに接続がフェイルオーバーする場合は、特別な条件が適
用されます。TMがクラスタ内の代替Oracle RACインスタンスからグローバル・トランザクションの
ステータスを取得しようとした場合、失敗したRMインスタンスのすべてのUNDOセグメントをリカ
バリするか、元のOracle RACのトランザクションがすべてタイムアウトするまでは、分散トランザ
クションのステータスに関する誤った情報を取得する可能性があります。TMが分散トランザクショ
ン・ブランチを開始したインスタンスに対して、別のインスタンスからの分散トランザクション・
ブランチのステータスを要求すると、多くの場合"ORA-24756: Transaction does not exist"というレスポ
ンスが返されます（トランザクションがタイムアウトしていなかったり（インダウト状態など）、
データベース・インスタンス・リカバリの一部としてリカバリされていなかったりする場合）。
Oracleデータベース・バージョン9.0以下
Oracleデータベース・バージョン9.0以下の場合、xa_open api内のOPS_FAILOVER=TでXA接続を開く
必要があります。
データベース・インスタンスが喪失した場合、TMがインダウト・トランザクションを解決する前に、
xa_recover apiを使用して準備済みトランザクション・ブランチのリストを返す必要があります。準備
済みでないトランザクションはロールバック、完了したトランザクションはコミットされます。
OPS_FAILOVER=T 設 定 に よ っ て 、 xa_recover で Oracle 内 部 プ ロ シ ー ジ ャ
SYS.DBMS_SYSTEM.DIST_TXN_SYNCのコールが指示されます。これにより、失敗したデータベー
ス・インスタンスのすべてのUNDOセグメントがリカバリされるまで、TMがブロックされます。
（ネットワーク接続喪失などによるエラー時ではなく）元のRMインタンスの喪失時にだけTMを代替
RMインスタンスにフェイルオーバーさせるには、慎重な設計が必要です。
Oracle 9iR2 RAC
9iR2では、前のリリースと同じルールが適用されます。ただし9.2.0.6からは、JDBCドライバとデー
タベース・サーバーへの拡張が強制されたため、追加でOPS_FAILOVERフラグの設定が冗長化され
ました。たとえばOracle内部プロシージャSYS.DBMS_SYSTEM.DIST_TXN_SYNCは必ずxa_recover、
xa_commit、およびxa_rollbackでコールされます。
データベース・インスタンス・フェイルオーバーを処理するためのXAおよびRAC用の9iR2カスタム・
ソリューションについては、オラクルのホワイト・ペーパー『RACでXAを使用するためのベスト・プ
ラクティス』を参照してください。データベース・サービスを使用してインスタンス・アフィニティ
を簡単に維持できましたが、データベース・インスタンスの喪失より、ネットワーク接続の喪失に対
応するのに慎重なソリューション設計が必要でした。ネットワーク喪失時には、分散トランザクショ
ンはタイムアウトまで存在します。分散トランザクションがタイムアウトすると、代替データベース・
インスタンスからリカバリ可能になる前に、"インダウト"トランザクションになります。
16
XAおよびOracleで制御する分散トランザクション
9iR2 RACでは、MAX_COMMIT_PROPAGATION_DELAY初期化パラメータ（デフォルト=700）も導
入されました。このパラメータによって、データベース・インスタンスのSGA内に保有されている
システム変更番号（SCN）がログ・ライター・プロセス（LGWR）によってリフレッシュされるまで
の最長時間（100分の1秒単位）が指定されます。これにより、問合せのスナップショットSCNの取
得時に、ローカルSCNをロック値からリフレッシュするかどうかが決まります。このパラメータを
ゼロに設定すると、コミット直後にSCNがリフレッシュされます。これは、データをコミットした
データベース・インスタンス以外のデータベース・インスタンスから、最近コミットしたデータを
読み取る際に必要となる場合があります。
Oracle 10gR1 RAC
Oracle 10gR1では、ワークロード管理機能を使用することで、カスタム・スクリプトが不要となり、
XAおよびRACソリューションの設計管理がより簡単になりました。Oracleホワイト・ペーパー『RAC
でXAを使用するためのベスト・プラクティス』を参照してください。
10gR1以降では、（以前のリリースのOPS_FAILOVER=T設定ではなく）RAC_FAILOVER=T設定を使
用して、xa_open apiでXA接続を開く必要があります。10.1.0.3パッチセットからは、JDBCドライバ
とデータベース・サーバーの拡張（Oracle内部プロシージャSYS.DBMS_SYSTEM.DIST_TXN_SYNC
が必ず xa_recover、xa_commit、xa_rollbackでコールされるなど）も追加されました。ただし前述の
とおり、トランザクション・リカバリを実行するためにサポートされている唯一のメカニズムは、
データベース・インスタンスの喪失時にTMがxa_recoverへのコールを発行するというものです。
シングルトン・データベース・サービスを使用することで、ネットワーク接続喪失による問題はな
くなりました。TMは必ず、データベース・サービスを実行しているインスタンスに誘導されるため
です。
9iR2と同様に、10gR1にもMAX_COMMIT_PROPAGATION_DELAY初期化パラメータ（デフォルト
で700）が含まれます。
Oracle 10gR2 RAC
10gR2では、分散トランザクション処理（DTP）をサポートするための新しいデータベース・サービ
ス機能が導入されました。この機能により、データベース内のXAトランザクション・リカバリが最
適化されます。通常のトランザクションの実行中に、UNDO領域に準備情報が書込まれます。トラン
ザクションが失敗すると、準備されたトランザクション情報が適切なシステム表にプッシュされ、
外部リカバリを実行できるようになります。通常の処理中は、このプッシュは非積極的に実行され
ます。ただしDTPサービスを使用した場合、いずれかの使用可能なデータベース・インスタンスで
DTPサービスを再起動できるようになる前に、失敗したインスタンスの実行中の"準備済み"トランザ
クションはすべてデータベース・システムの表にプッシュされます。
10gR2内では、インスタンス・フェイルオーバーで必ずxa_recoverを実行するという要件は、TMに実
行中のトランザクションに関する十分な情報があり、xa_commitやxa_rollbackを使用してトランザク
ション・リカバリを実行できる場合に有効でした。
DTP サ ー ビ ス 機 能 が サ ポ ー ト さ れ る よ う に な る に つ れ 、 Oracle 内 部 プ ロ シ ー ジ ャ
SYS.DBMS_SYSTEM.DIST_TXN_SYNCはNULL動作（no-op）になりました。前のバージョン同様、
10gR2でのフェイルオーバー・リカバリ方法については、Oracleホワイト・ペーパー『RACでXAを使
用するためのベスト・プラクティス』を参照してください。
17
XAおよびOracleで制御する分散トランザクション
ただし、すべてのアプリケーションがDTPサービス機能を使用するわけではなく、10.2.0.3からは
SYS.DBMS_SYSTEM.DIST_TXN_SYNCが再度有効になりました（パッチ5968965によって）。
その後、10.2.0.4ではセキュリティ改良としてSYS.DBMS_SYSTEM.DIST_TXN_SYNプロシージャが
DBMS_XA.DIST_TXN_SYNCに名称変更されました。これにより、強力なDBMS_SYSTEMプロシー
ジャに対するユーザー・アクセスが制限されました。以前は、XAクライアントでDIST_TXN_SYNを
起動するには、DBMS_SYSTEMでの実行権限が必要でした。このセキュリティ強化には、サーバー
とクライアント両方のソフトウェアの変更が必要で（クライアントのOCIライブラリとJDBCなど）、
パッケージDBMS_SYSTEMの代わりにDBMS_XAがコールされます。つまり、データベース・フェ
イルオーバーでのユーザー権限エラーを回避するため、すべてのXAクライアント・ユーザーが
（DBMS_SYSTEMではなく）DBMS_XAで権限を実行することが必要になりました。同様に、互換性
の問題を回避するには、クライアントとサーバー両方のソフトウェア・バージョンが同じPL/SQLパッ
ケージ（DBMS_XAまたはDBMS_SYSTEM）を参照する必要があります。
また10gR2では、MAX_COMMIT_PROPAGATION_DELAYパラメータは推奨されず、 下位互換性の
ためだけに残されました。このパラメータはデフォルトで0に設定されているため、SCNはコミット
（"コミット時のブロードキャスト"）の直後にリフレッシュされることになります。このため、最近
コミットされたデータは、データをコミットしたデータベース・インスタンス以外のデータベース・
インタンスですぐに使用可能になります。
Oracle 11gR1 RAC
11gR1では、クラスタ全体のグローバル・トランザクションが導入されました。このため、Oracle RAC
クラスタ内のすべてのデータベース・インスタンスで分散トランザクションを処理できるようにな
りました。このため、次のような多くの新機能が導入されました。
•
密結合トランザクション用のグローバルDX（分散トランザクション）エンキュー
•
密結合トランザクションで読取り一貫性を実現（あるデータベース・インスタンスでのプリコ
ミットの変更を、他のデータベース・インスタンスで利用できるなど）
•
DXエンキューの管理およびクロスインスタンスの2フェーズ・コミット用の新しいGTXnバック
グラウンド・プロセスおよび対応する初期化パラメータ（GLOBAL_TXN_PROCESSES）
DX（分散トランザクション）エンキューおよび新しい読取り一貫性の機能については、前のデータ
ベース・ロックの項を参照してください。
GLOBAL_TXN_PROCESSESパラメータでは、各Oracle RACインスタンスのGTXnバックグラウン
ド・プロセスの初期数値を指定します。GLOBAL_TXN_PROCESSESの数は、データベースによって
自動的に管理されます。
ただし、GTXプロセスの開始と停止については、"Global transaction acquire ins"で待機イベントの超過
が発生しうるという既知の問題があります（注：804426.1を参照）。回避方法は、アンダースコア・
パラメータ_DISABLE_AUTOTUNE_GTX=TRUEを設定して、GTXの自動チューニング機能を無効に
することです。
COMPATIBLE >= 11.0の場合、クラスタ全体のグローバル・トランザクションはデフォルトで11gR1
RACです。アンダースコア・パラメータ _CLUSTERWIDE_GLOBAL_TRANSACTIONS=FALSEを設
定することによってのみ無効化できます。このパラメータの設定がFALSEの場合、デフォルトの
10gR2分散トランザクション処理メカニズムが使用されます。
18
XAおよびOracleで制御する分散トランザクション
Oracle 11gR2 RAC
XAに関して、11gR2に追加される新機能や制約はありません。
Oracleアカウントの権限
分散トランザクションを実行するデータベース・アカウントには、次の権限が必要です。
•
DBA_PENDING_TRANSACTIONSシステム・ビューの読取り権限（GRANT）。
•
"トランザクションの強制"権限に対する権限（GRANT）（他のデータベース・ユーザーが作成し
た分散トランザクションを操作する必要があるデータベース・ユーザーの場合）。
またOracle RACを使用する場合、ユーザー・アカウントには次の権限が必要です。
•
DBMS_SYSTEMシステム・パッケージ（9.2.0.8または10.2.0.3以下では、5945463 – サーバー、
5965349 – OCI/Cライブラリ、5892995 JDBCのパッチが適用されていない場合）またはDBMS_XA
システム・パッケージ（データベース・サーバー、クライアントOCIライブラリ、JDBCドライバ
の場合は10.2.0.4以上）の実行権限（GRANT）。
•
同じパッチセットまたは適切なパッチが適用されているクライアント/サーバー・バージョンを使
用し、同じデプロイメント内でDBMS_SYSTEMパッケージとDBMS_XAパッケージを一緒に使用
しない。
XAとデータベース・リンク
XAとデータベース・リンクを使用することで、XAおよびOracleで制御する分散トランザクションが
混合されます。XAでのデータベース・リンクの使用についてはバージョン依存の制約があるため、
トランザクション範囲内のすべてのデータベース・バージョンのマニュアルで、制限をチェックす
る必要があります。通常、ほとんどのバージョンでは、データベース・リンクの使用について次の
制約があります。
•
すべてのデータベース接続は、共有サーバー構成を使用する必要があります。
•
アクセス対象の他のデータベースは、もう1つのOracle Databaseである必要があります。
これらの制限が満たされない場合、XAトランザクション内でデータベース・リンクを使用すると、
TMサーバー・プロセスに直接接続されているOracleサーバーにO/Sネットワーク接続が作成されます。
TMが特定のサービスやRPCを完了したとき、他のサービスやRPCが接続を再利用できるよう、TM自
体をデータベースから切り離す必要がある場合があります。O/Sネットワーク接続をプロセス間で移
動することはできないため、これにより、TMサービスやRPCがデータベースから切り離されること
を防ぎます。この結果、データベースから"ORA-24777 use of non-migratable database link not allowed"
というレスポンスが表示されます。
19
XAおよびOracleで制御する分散トランザクション
Oracle Real Application Testingと分散トランザクション
Real Application Testing（RAT）は11gR1で導入され、本番データベース・トランザクションの取得、
分析、および再生に使用される複数のコンポーネントで構成されます。RATを使用すると、本番デー
タベース・ワークロードの再生により、テスト対象のアップグレードやシステム変更を、本番以外
のシステムで完全に実行できます。ただし、RATは同時に1つのデータベースにしかデプロイされな
いため、単一データベースでしかトランザクションを実行できません。このため、RATが取得する
分散トランザクションは、ローカル・トランザクションとして再生されます。したがって、分散ト
ランザクションを使用するアーキテクチャではRATのメリットを完全に実現することはできません。
ワークロード混在やデータ競合の可能性が、本番ワークロードで発生するものとは本質的に異なる
ためです。
PL/SQLとXA
Oracle Database 11gR1以降、PL/SQLはXAインタフェースで使用可能な機能を利用して複数のリソー
ス・マネージャ（データベースやキューなど）を含むトランザクションをサポートできるようにな
りました。PL/SQLでは、SQL*Plusセッション/プロセス間で、DBMS_XAパッケージに含まれる
XA/Openインタフェース・ライブラリを使用したトランザクションの切り替え/共有が可能になりま
した（XA_STARTによるトランザクションの開始、XA_ENDによるトランザクションの終了など）。
20
XAおよびOracleで制御する分散トランザクション
中間層からのXAとOracleデータベースの使用
XAおよびOracleのWebLogic Server / Fusion Middleware 11gR1
Oracle Weblogic Serverは、JTA / JDBC XAResourceの標準インタフェースを使用して、Oracle JDBCド
ライバ経由で密結合のXAトランザクションを実装します。アプリケーション開発者は、これをオー
バーライドできません。
Oracle WebLogic Serverマルチプール
Oracle RACの場合、Oracle WebLogic Server 11gR1（および8.1.5以降の全バージョン）ではOracle
WebLogic Serverのマルチデータソースを使用することをお勧めします。Oracle Technology Network
（OTN）には、Oracleホワイト・ペーパー『Oracle WebLogic Server 10.3とOracle Real Application Clusters
（Oracle RAC）』とOTNの"使用方法ガイド"が公開されており、Oracle WebLogic Serverのマルチデー
タソースとデータベース・サービスの使用について記載されています。詳細情報については、Oracle
WebLogic Serverの関連リリースのマニュアルと、OTNのWebサイトも参照してください。
Oracle RACでのOracle WebLogic Serverマルチデータソースのおもなアーキテクチャ上の制約は、
Oracleデータベース接続で"サーバー側の"あらゆる形式のロードバランシングが削除されることで
す。Oracle RACの各データベース・インスタンスは、対応するデータベース・インスタンスと同じ
ノード/サーバー（local_listener）上にあるローカル・データベース・リスナーによってのみ、そのサー
ビスがアドバタイズされるよう構成されています。Oracle RACではデフォルトで、すべてのデータ
ベース・リスナーが、Oracle RACクラスタ内のすべてのデータベース・インスタンス間で使用でき
るすべてのデータベース・サービスをアドバタイズできるよう構成されていますが、これは無効に
なります（remote_listenerはNULLに設定されます）。このため、Oracle WebLogic Serverマルチプール
内の個別の接続プールを、個々のデータベース・インスタンスに誘導できます。マルチデータソー
ス機能の一部として、Oracle WebLogic Serverは個別のJTAトランザクションを特定の物理プールに固
定します。
Oracle WebLogic Server 11gR1（10.3.1）以降、JDBC接続文字列内の"INSTANCE_NAME= "パラメータ
を次のように使用して、個別の接続プールをOracle RACデータベース・インスタンスに固定できる
ようになりました。
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(H
OST=VIP1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=SERV1)(INSTANCE_NAM
E=INST1)))
これにより、Oracleデータベース・パラメータremote_listenerをNULL以外の値に設定でき、個別の接
続プールを特定のデータベース・インスタンスに制限しながら、Oracle RACクラスタ内のすべての
データベース・リスナー間でデータベース・サービスをアドバタイズできます。マルチプール・デー
タソースが同じ接続は、すべて同じデータベース・サービス名を使用する必要があります。
XAを使用する場合、複数のデータベース・インスタンス間のデータベース接続のフェイルオーバー
とロードバランシングには、マルチデータソースを使用する必要があります。Oracle WebLogic Server
はデータソース間の要求のロードバランシングをおこないますが、個別のXAトランザクションは単
一データソースに固定されます。
21
XAおよびOracleで制御する分散トランザクション
Oracle RACによるOracle WebLogic ServerのXAトランザクションのリカバリ
Oracle RAC環境内でOracle WebLogic Serverが実行するリカバリ操作は、トランザクション内のどの
ポイントでOracle RACデータベース・インスタンスが失敗したかによって異なります。
アプリケーションがコミットするトランザクションをコールする前、またはコミットを要求してい
るが準備操作が完了する前にOracle RACデータベース・インスタンスの障害が発生した場合、Oracle
WebLogic Serverはトランザクションをロールバックして失敗したトランザクションの例外をアプリ
ケーションに送信します。
準備操作完了後のコミット・フェーズ中にOracle RACデータベース・インスタンスに障害が発生し
た場合、Oracle WebLogic Serverはxa_commitを使用してトランザクションの完了を再試行します。
データベース・プロシージャDIST_TXN_SYNCによってxa_commitが使用されている場合は接続がブ
ロックされ、分散トランザクションがリカバリされるまでxa_commitのレスポンスが遅れるので注意
してください。
Oracle Weblogic ServerではOracle RACの一時停止も可能です。データベースからXA_NOTAレスポン
スが返される可能性があるXA動作（リソース・マネージャで現行トランザクションが有効なトラン
ザクションと認識されない場合など）は、一時停止処理中にXA_RMERR（リソース・マネージャ・
エラーなど）に変換され、この間にデータベースはすべての未処理XAトランザクションをリカバリ
します。この一時停止期間の長さはXARetryDurationSeconds、一時停止期間内のトランザクションの
再試行間隔はXARetryIntervalSecondsで制御されます。一時停止期間が終了すると、その後のデータ
ベースからのXA_NOTAレスポンスは、すべて正常に完了した動作として解釈されます（XA_NOTA
は有効なレスポンスであることに注意してください。たとえば、TMがコミット処理を再発行したが、
RMがそのブランチをコミット済みであり、そのことを忘却していた場合などはこのレスポンスが返
されます）。
Oracle WebLogic Serverのトランザクション・ログ・ファイル（TLOG）
Oracle WebLogic Serverでは、準備後コミット・フェーズに移る前に準備フェーズの結果がそのTLOG
（トランザクション・ログ・ファイル）に書き込まれます。TLOGはディスクに保存されます。デフォ
ルトでは、Oracle WebLogic Server内の複数リソースのローカル・コミットは複数のスレッドを使用
してパラレルで実行されます。これは、（文書化されていない）JTAMBean属性のparallelXAEnabled
で制御されます。
エントリがすべてのRMでコミットされると、Oracle WebLogic Serverは"忘却"処理の一部として、そ
のエントリをTLOGから削除し、完了したトランザクションを削除します。
Oracle WebLogic Serverで可用性の高いXA構成が必要な場合は、物理サーバー間のTLOGのリカバリ
を考慮する必要があります。このためには、次のようなさまざまなファイル・システム/論理ボリュー
ムの管理方法を使用します。
•
サーバー・ベースのクラスタリング・ソフトウェア（Oracle Clusterware、IBM HACMP、HP
ServiceGuard、Veritas Clusteringなど）またはOracle WebLogic ServerのWhole Server Migration（WSM）
機能を使用して、代替サーバーにSANディスクを再マウントする
•
ネットワーク接続ストレージ（NAS）デバイスを接続し、複数のサーバー間（NetApp、EMC Clarion
など）でマウント・ポイントを共有する。またはクラスタ化されたファイル・システム（Veritas
CFS、OCFS2、Oracleの11gR2 ASM Clustered File System（ACFS）など）を使用してサーバー間で
のディスクの再マウントを回避する
22
XAおよびOracleで制御する分散トランザクション
ただし、ディスクへの高速アクセスが必要な高スループット・システムをデプロイする場合、専用
ディスクでなく共有ファイル・システムを使用することで、パフォーマンスに影響する可能性があ
ることを考慮してください。
Oracle WebLogic ServerのWhole Server MigrationおよびAutomatic Service Migration機能については、
Oracleホワイト・ペーパー『Oracle WebLogic Serverの自動サービス移行』を参照してください。この
ホワイト・ペーパーは、Oracle Technology Network（OTN）でも公開されています。
ディザスタ・リカバリの場合、ディスク・アレイ・ベースの同期レプリケーション（EMCのSRDFや、
HP/Sun/Hitachiのエンタープライズ・ディスク・アレイ内で使用される継続的アクセスなど）によっ
てTLOGを保護する必要があります。ディスク・アレイ・ベースの同期レプリケーションをディザス
タ・リカバリで使用する場合、XAトランザクションのすべての参加者（TMとRM）を、同じディス
ク・アレイ・レプリケーションの"コンシステンシ・グループ"内で保護する必要があります。これに
より、すべてのXAデータソースとTMログが相互に関連した一貫性のある状態になるように、"コン
システンシ・グループ"内のディスクへの書込みがリモートの場所ですべて正しくシーケンス化され
ます。データソース
ディザスタ・リカバリに複数のレプリケーション・メソッドを使用する場合は、ディザスタ・リカ
バリ・サイトへのフェイルオーバーにおいて、XAトランザクションのすべての参加者（TMとRMの
両方）の状態と一貫性を維持できるよう、注意が必要です。
Oracle WebLogic ServerのLogging Last Resource（LLR）
XAトランザクションの追加オプションは、JDBCデータソースを使用したOracle WebLogic Serverの
Logging Last Resource（LLR）トランザクションの最適化です。LLRは、XA以外のリソースがXAと
同じACID保証を使用して分散トランザクションに参加できるようにする、パフォーマンス向上オプ
ションです。LLR参加者が含まれる分散トランザクションでは、Oracle WebLogic Serverトランザク
ション・マネージャは次の基本手順に従います。
•
他のすべての（XA準拠の）トランザクション参加者で準備をコールします。
• （ファイル・ベースのトランザクション・ログではなく）LLR参加者の表に、コミット・レコー
ドを挿入します。
•
LLR参加者のローカル・トランザクション（トランザクション・コミット・レコードの挿入とア
プリケーションのSQL作業が含まれます）をコミットします。
•
他のすべてのトランザクション参加者で、コミットをコールします。
トランザクションが正常に完了すると、Oracle WebLogic Serverは将来のトランザクションの一部と
して、データベース・トランザクション・ログ・エントリを非積極的に削除します。
LLRは、特定のデータソース上で、（XAがサポートされていなかったり、全体の設計が複雑になっ
たりするため）XAを使用しない場合に便利です。ただし、LLR参加者はOracle WebLogic Serverのコ
ミット・レコードを維持できる必要があるため、キュー・ベースのリソース・マネージャでは使用
できません。
23
XAおよびOracleで制御する分散トランザクション
XAとOracle 10gAsアプリケーション・サーバー/ Fusion Middleware 10g
Oracle Technology Network（OTN）に公開されているOracleホワイト・ペーパー『Oracle SOA Suite XA
and RAC Database Configuration Guide』には、XA対応SOA Suiteの構成方法が記載されています。こ
のホワイト・ペーパーでは、権限（GRANT）を持つXAデータベース・ユーザーを構成し、10.2.0.3
のDBMS_SYSTEMシステム・パッケージを実行する方法について説明していますが、これ以降のバー
ジョンのデータベースでは、DBMS_XAシステム・パッケージに関する権限が必要な場合があります。
10gAS 10.1.3.1.0では、中間層の2フェーズ・コミット（2PC）コーディネータが導入されました。こ
れにより、トランザクションの調整機能が、データベース内の調整の代わりに、10gAsエンジン内に
配置されました。10gAS 10.1.3.1.0以降、データベース内の調整は推奨されていません。10.1.3.1.0よ
り前のバージョンでは、データベースの分散トランザクション・マネージャを使用したデータベー
ス内調整しか使用できるメカニズムがありませんでした。
OC4Jトランザクション・ログ・ファイルは、データベースまたはファイル・システムで保存されま
す。可用性の高いXA構成の実現が必要な場合、データベースにより柔軟性が向上します。
10gASのLast Resource Commit（LRC）
10.1.3.1.0でのXAトランザクションの追加オプションは、JDBCデータソースを使用した10gASのLast
Resource Commit（LRC）トランザクションの最適化です。LRCは、XA以外のリソースがXAと同じ
ACID保証を使用してグローバル・トランザクションに参加できるようにする、パフォーマンス向上
オプションです。LRC参加者が含まれるグローバル・トランザクションでは、OC4Jトランザクショ
ン・マネージャは次の基本手順に従います。
•
他のすべての（XA準拠の）トランザクション参加者で準備をコールします。
•
LRC参加者のローカル・トランザクションをコミットします（エミュレートされたXAリソース
など）。
エミュレートされたXAリソースに対する1フェーズ・コミットが正しく完了したら、OC4Jトランザ
クション・マネージャは、分散トランザクションをコミットするための決定をログに残し、それぞ
れの2フェーズ・コミット・リソースに対してコミットをコールします。または、エミュレートされ
たXAリソースに対する1フェーズ・コミットが失敗したら、OC4Jトランザクション・マネージャは、
分散トランザクションをロールバックするための決定をログに残し、それぞれの2フェーズ・コミッ
ト・リソースに対してロールバックをコールします。
ほとんどの場合、LRC最適化は正常に実行されますが、最後のリソース・コミット最適化を使用す
る際にリスクがあります。XA準拠でないリソースに制御を渡す間にエラーが発生した場合、リソー
スでトランザクションがコミットまたはロールバックされたかどうかをトランザクション・コー
ディネータが知ることはできません。この結果、トランザクションがヒューリスティックに完了す
る場合があります。これは検出や修正が非常に難しいです。
24
XAおよびOracleで制御する分散トランザクション
XAの典型的なアーキテクチャおよび設計の問題
XAの使用で発生する、アーキテクチャや設計の典型的な問題は次のとおりです。
•
複数のデータソース（データベースやファイル・システム・ベースのキューなど）を、バックアッ
プからトランザクション上一貫性のあるポイントにリカバリする。バックアップ/リカバリ戦略に
おいて、ファイル・システム・ベースのキューの管理に問題が発生する可能性があります。デー
タベースは同じポイント・イン・タイムにリカバリできますが、トランザクション上一貫性がな
い可能性があります（あるデータベースでは分散トランザクションがコミット済みであり、別の
データベースでは準備済みであるなど）。
•
ディザスタ・リカバリで、非同期にレプリケートされたデータソースをリカバリする。データソー
スが、別のポイント・イン・タイムおよびトランザクション一貫性で、一貫性のない状態のまま
となります。この結果、バックアップからリカバリした場合と同じ問題が発生します。
•
XAの競合状態 - XA仕様には、TMがRMに対してコミットを要求する順序や、RMでコミットが
必要な時間枠については規定されていません。コミットに同意したすべてのRMが、データをコ
ミットする必要があるとだけ記載されています。このため特に、処理が1つ以上のRMへの書込み
順序に依存する場合、競合状態が発生する可能性があります。 たとえば、（独立プロセスがJMS
キューを監視する）Message Driven Bean（MDB）タイプのアーキテクチャでは、新しいメッセー
ジを識別して処理しようとします。この際、処理対象の対応する更新は検出されますが、データ
ベースで利用可能にはなりません。
•
分散トランザクション内のDDLを誤って使用する。たとえば、一時表を使用する、CREATE
TABLEコマンドがDDLであるなど（暗黙的なトランザクションが含まれることになります）。
•
データベース競合内での設計。Oracleで制御する分散トランザクションは、準備/コミット間の未
確定の期間中、変更したすべての行をロックするため、索引とデータでの更新競合が最小限にな
るよう、各トランザクションを設計する必要があります。このように設計しないと、類似プロファ
イルを含むデータを同時処理する場合（一意でない索引を同じ範囲に挿入する場合など）、トラ
ンザクションが互いにブロックし、ロード時のスパイクやパフォーマンスの低下につながる可能
性があります。
Oracleデータベースのリカバリ
Oracleデータベース環境内では、Oracleで制御する分散トランザクションによって、トランザクショ
ン内のすべてのデータベースに対してSCNの調整と同期が強制的に実行されます。こうして、デー
タベースを（すべてのデータベースで実行される）最新の定期的なトランザクションのSCNにリカ
バリでき、トランザクション一貫性を維持できます。このためには、同期が必要な各データベース
で表を更新する、定期的なOracle分散トランザクションを実行します。ただし、この操作により不完
全または部分的なリカバリが実行される可能性があります。失われたすべてのトランザクションを
再生するカスタム・メカニズムがない限り、最新の定期的更新以降のトランザクションはすべて失
われるためです。このメカニズムによって、Oracleデータベースをトランザクション一貫性のあるポ
イント・イン・タイムにリカバリできます。ただし、分散トランザクションの一部である可能性が
あるOracle以外のデータベース・リソースは含まれません。
25
XAおよびOracleで制御する分散トランザクション
XA競合状態の回避
前述のXA競合状態を回避するには、設計時に次の手法を1つ以上使用することが必要な場合があり
ます（特定の順序はありません）。
•
再試行メカニズムにより、すべてのRMにコミット時間を許可する。
•
同じRMインスタンス上にあるキューと重要データの両方で、密結合トランザクション・ブラン
チを使用する。この結果、単一コミットになる。（TMが密結合トランザクション・ブランチを
サポートする必要があります。また、パフォーマンスに影響が出る可能性があります。）
•
組込みの時間遅延によりすべてのRMにコミット時間を許可する。
•
Oracle WebLogic ServerのJMSの"メッセージ（配信時間）のスケジュール設定"拡張機能を使用し
て、将来的なJMSメッセージの配信をスケジュールする（組込み遅延の実現など）。
•
9iR2 RACおよび10gR1 RACの場合、最近コミットしたデータを、データをコミットしたデータ
ベース・インスタンス以外のデータベース・インスタンスから読み取る必要がある場合は、
MAX_COMMIT_PROPAGATION_DELAY=0を設定する。
•
Oracle Weblogic ServerのLogging Last Resource最適化を使用する。これにより、XA以外のリソー
スがXAと同じACID保証を使用してグローバル・トランザクションに参加し、強制的にJMSキュー
が最後にコミットされるRMになるようにします（たとえば、データベースがLLR参加者で、最
初にコミットされるなど）。
•
OC4Jトランザクション・マネージャの、10gASのLast Resource Commit（LRC）機能を使用する。
これにより、1つのXA以外のリソースがグローバル・トランザクションに参加できます。LRCを
使用して、強制的にJMSキューが最後にコミットされるRMになるようにします（たとえば、デー
タベースがLRC参加者で、最初にコミットされるなど）。ただし、OC4Jトランザクション・マネー
ジャは、10gAS 10.1.3.1.0以上でしか使用できず、XAと同じACID保証は提供しません。
26
XAおよびOracleで制御する分散トランザクション
結論
システム・アーキテクチャ内で分散トランザクションや"グローバル"トランザクションを使用する場
合は、インダウト・トランザクションやシステム・パフォーマンスの低下によるデータのリカバリ
能力の問題やカスケード障害を回避するため、慎重な検討が必要です。
分散トランザクションまたは"グローバル"トランザクションのいずれかのタイプのトランザクショ
ンを使用することで、アーキテクチャは次のようになります。
•
必要なリカバリ時間目標内に、バックアップからトランザクション一貫性のある状態にリカバリ
可能。
•
トランザクションが、すべてのデータソースに同時に適用されることはない（XA競合状態など）。
•
XAトランザクション内で暗黙的なトランザクション（DDLなど）を必要とするアクションは実
行されない。
•
データの小さなサブセットの競合や依存性は組み込まれない。
•
高可用性の場合、トランザクション・マネージャ（TLOGなど）で必要なデータは捕捉されず、
障害発生後にトランザクションがリカバリされる。
•
トランザクションの手動解決ができるだけ回避される（個別のリソース・マネージャにバージョ
ンの異なる同一データが含まれる可能性があるヒューリスティックな結果につながる場合があ
るため）。トランザクション・マネージャができるだけ未処理トランザクションを完了できるよ
うにする。
27
XAおよびOracleで制御する分散
トランザクション
2010年6月
著者：Tony Flint
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Copyright © 2010, Oracle and/or its affiliates.All rights reserved.
本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一切
間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性
もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に
関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書
はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段に
よっても再作成または送信することはできません。
OracleおよびJava®はOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
海外からのお問い合わせ窓口：
電話： +1.650.506.7000
ファクシミリ： +1.650.506.7200
www.oracle.com
AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel Xeon
はIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.
の商標または登録商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。0110