目次 前 次 PDF


Domainsの管理

Domainsの管理
以下の項では、Oracle Tuxedo Domains環境を管理する方法について説明します。
Domainsの実行時管理コマンドを使用する
Domainsコンポーネントを既存のOracle Tuxedoアプリケーションと統合するには、ドメイン・ゲートウェイ・グループとゲートウェイ・サーバーのエントリをTUXCONFIGファイルに追加します。実行中のOracle TuxedoアプリケーションにDomains構成を追加するには、tmconfig(1)またはtmadmin(1)コマンドを使用します。tmadminを使用すると、ドメイン・ゲートウェイ・グループや個々のドメイン・ゲートウェイの掲示板で使用できる情報をリストすることもできます。
Domains環境を設定し、統合すると、Domainsコンポーネントに用意されている一連の管理ツールを使用して、Domains環境を動的に管理できます。たとえば、複数のアプリケーションからアクセスできるサービスのリストを指定および変更できます。DomainsソフトウェアはOracle Tuxedoのプログラミング・インタフェース(ATMI)の機能を備え、さらにATMIのスコープが拡張されているため、クライアントは複数のドメインにわたってサービスを呼び出すことができます。この機能により、プログラマは、アプリケーション・コードを変更せずに、アプリケーションを拡張したり、分割できます。
図4-1に、Domainsの管理サブシステムにおける管理コマンドと管理サーバーの関係を示します。
図4-1 Domainsの実行時の管理
Oracle Tuxedo Domainsコンポーネントには、次の管理コマンドが用意されています。
dmadmin(1) - 一般的な管理サービス用のコマンドです。管理者は、Oracle Tuxedoアプリケーションの実行中に、ドメイン・ゲートウェイ・グループを動的に設定、モニターおよび調整したり、Domainsの構成ファイル(BDMCONFIG)を更新できます。このコマンドは、管理コマンドを変換したり、サービス・リクエストをDMADMINサービスに送信したりするフロントエンド・プロセッサとして機能します。DMADMINサービスは、DMADMサーバーにより通知される汎用管理サービスです。DMADMINサービスは、DMADMサーバーに組み込まれている、検証、検索、または更新を行う機能を呼び出して、BDMCONFIGファイルを管理します。
DMADM(5) - Domains管理サーバーです。Domainsの構成を更新するための管理プロセスを提供します。このサーバーは、 dmadminコマンドに対するバックエンドとして機能し、ドメイン・ゲートウェイ・グループの登録サービスを提供します。この登録サービスは、GWADMサーバーの初期化処理で要求されます。登録サービスは、リクエスト元のドメイン・ゲートウェイ・グループが要求する構成情報をダウンロードします。DMADMサーバーは、登録済のドメイン・ゲートウェイ・グループのリストを管理し、構成ファイルが変更されると、変更内容をリスト内のドメイン・ゲートウェイ・グループに伝播します。
GWADM(5) - ゲートウェイ管理サーバーです。DMADMサーバーに登録され、対応するドメイン・ゲートウェイ・グループに使用される構成情報を取得します。GWADMは、DMADMからの問合せ、つまり、対応するドメイン・ゲートウェイ・グループの実行時オプションでの統計情報や変更に対する問合せを受け付けます。GWADMサーバーは、"I-am-alive"メッセージを定期的にDMADMサーバーに送信します。DMADMサーバーから応答がない場合、GWADMサーバーは再度登録を行います。このメカニズムにより、GWADMサーバーは、そのグループのDomains構成に関する最新の情報を常に保持できます。
GWTDOMAIN(5) - TDomainゲートウェイ・サーバーです。複数のOracle Tuxedoドメイン間で相互運用性を実現します。WebLogic Tuxedo Connector (WTC)ゲートウェイ(Oracle WebLogic Serverコンポーネント)と連係することで、Oracle Tuxedo TDomainゲートウェイはTuxedoドメインとWebLogic Serverアプリケーションの間でも相互運用性を実現できます。
注意:
GWTDOMAIN以外のドメイン・ゲートウェイ・タイプについては、http://download.oracle.com/docs/cd/E13161_01/tuxedo/tux100/interm/mainfrm.htmlを参照してください。
BDMCONFIG - Domains構成ファイルのバイナリ形式です。TUXCONFIGファイルおよびfactory_finder.iniファイル(CORBAのみ)と一緒に、Domains構成を作成するためにOracle Tuxedoソフトウェアで必要なすべての構成パラメータを格納します。
注意:
TUXCONFIGファイルのSERVERSセクションでGWADMサーバーが定義されていれば、CLOPTパラメータを使用してドメイン・ゲートウェイ・グループを起動した場合、ゲートウェイ・パラメータも指定できます。
管理インタフェースdmadmin(1)を使用する
dmadminは、DMADMサーバーおよびGWADMサーバーに対する管理インタフェースです。これらの2つのサーバー間の通信は、FMLの型付きバッファを使用して実行されます。管理者は、dmadminコマンドを使用して、次の作業を実行できます。
BDMCONFIGファイルに格納された情報と特定のOracle Tuxedoアプリケーションで実行している異なるドメイン・ゲートウェイ・グループの情報を対話形式で管理できます。
BDMCONFIGファイルに情報を追加したり、情報を更新できます。
注意:
実行時にBDMCONFIGファイルから削除できるのは、アクティブなドメイン・ゲートウェイ・グループとは関係のない情報のみです。
関連項目
『Oracle Tuxedoコマンド・リファレンス』dmadmin(1)に関する項
Domains管理サーバーDMADM(5)を使用する
Domainsの管理サーバーであるDMADM(5)は、Oracle Tuxedoに組み込まれているサーバーであり、次の機能を実行します。
BDMCONFIGファイルを実行時に管理します
BDMCONFIGファイルを管理します
DMADMサーバーは、次の2つのサービスを通知します。
DMADMINdmadminコマンドとGWADMサーバーによって使用されます。
DMADM_svridsrvidは、サービス用のサーバーIDです。登録済のGWADMサーバーは、特定の管理機能(ドメイン・ゲートウェイ・グループの構成情報をリフレッシュしたり、GWADMが登録されたままであることを通知する機能など)に対してDMADM_svridを使用します。
DMADMサーバーは、グループ内で実行しているサーバー(DMADMGRPなど)としてTUXCONFIGファイルのSERVERSセクションで定義されている必要があります。このグループには、DMADMサーバーのインスタンスが1つのみ必要です。
関連項目
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』DMADM(5)に関する項
ゲートウェイ管理サーバーGWADM(5)を使用する
ゲートウェイ管理サーバーGWADM(5)は、Oracle Tuxedoに組み込まれているサーバーであり、ドメイン・ゲートウェイ・グループ用の管理機能を提供します。GWADMサーバーの主な機能は、以下のとおりです。
DMADMサーバーからDomainsの構成情報を取得したり、dmadminからの問合せを受け付けます。GWADMサーバーは、DMADMサーバーに登録することにより、ドメイン・ゲートウェイ・グループの構成情報を取得します。次に、GWADMサーバーは、この情報を共有メモリーに格納し、ゲートウェイでこの構成を利用できるようにします。
ドメイン・ゲートウェイ・グループの管理機能を提供します。たとえば、実行時の統計情報についてdmadminからの問合せを受け付けたり、ドメイン・ゲートウェイ・グループの実行時パラメータを変更します。
ドメイン・ゲートウェイ・グループ用のトランザクション・ログ機能を提供します。GWADMサーバーは、共有メモリーに格納されている情報を読み取り、どのトランザクション・ログを記録する必要があるかを判断します。GWADMサーバーは、起動時にログをスキャンして、トランザクションの回復が必要かどうかを調べます。回復が必要であれば、共有メモリー内のトランザクション情報を回復します。ゲートウェイ・サーバーは、共用メモリーの情報をスキャンして、対応するトランザクションをリカバリします。リカバリ手順は、ドメイン・ゲートウェイ・グループで受信される新規の入力リクエストや出力リクエストとは、非同期的に行われます。
GWADMサーバーは、GWADMサーバーが属するドメイン・ゲートウェイ・グループに関連付けられたローカル・ドメイン・アクセス・ポイントの名前(BDMCONFIGファイルのDM_LOCALセクションで指定)に基づいてサービス名を通知します。dmadminコマンドは、このサービスを使用して、アクティブなすべてのドメイン・ゲートウェイ・グループまたは特定のドメイン・ゲートウェイ・グループから、情報を取り出します。
GWADMサーバーは、TUXCONFIGファイルのSERVERSセクションで定義する必要があります。グループに関連するゲートウェイが使用するMSSQの一部として指定することはできません。また、ドメイン・ゲートウェイ・グループ内で最初に起動されるサーバーでなければなりません。つまり、SEQUENCEで番号が指定されているか、またはゲートウェイ・サーバーより先に定義されていなければなりません。
GWADMサーバーにはDMADMサーバーが必要です。具体的にはDMADMサーバーを起動してから、GWADMを起動する必要があります。
GWADMサーバーは、ドメイン・ゲートウェイ・グループに必要な共有メモリーを作成し、DMADMサーバーから受け取る情報を構成表に設定する必要があります。GWADMサーバーはshmgetIPC_PRIVATEを使用し、掲示板のレジストリ・エントリにあるshmidフィールドに返されたipckeyを格納します。ゲートウェイは、GWADMレジストリ・エントリを取得し、shmidフィールドをチェックすることにより、ipckeyを取得できます。
関連項目
『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』GWADM(5)に関する項
ドメイン・ゲートウェイ・サーバーを使用する
ドメイン・ゲートウェイ・サーバーは、リモート・ドメイン・ゲートウェイ・サーバーへの接続を提供し、1つ以上のリモート・ゲートウェイと同時に通信できます。ゲートウェイは、Oracle Tuxedoアプリケーションにインポートされたサービスを通知し、アプリケーションによってエクスポートされたローカル・サービスへのアクセスを制御します。アプリケーションのエクスポートされたサービスとインポートされたサービスは、Domains構成ファイル(DMCONFIG)で定義します。ドメイン・ゲートウェイ・グループを動的に構成、モニターおよび調整するには、dmadminを使用します。
関連項目
ドメイン・ゲートウェイのパフォーマンスをチューニングする
Oracle Tuxedo 9.xでは、GWTDOMAINゲートウェイのパフォーマンスを向上しながら、他のタイプの/Domainゲートウェイとの互換性を保持しています。このため、パフォーマンスの大部分はスレッド化されたプラットフォームに制限されます。また、プログラムの簡単な変更のみで、他のタイプの/Domainゲートウェイも、拡張された共通ゲートウェイ・アーキテクチャでこの機能を利用できます。
複数のドメインにわたるアプリケーションのパフォーマンスは、様々な要因の影響を受けます。次に例を示します。
このため、ドメイン・ゲートウェイのパフォーマンスの向上を実感するには、アプリケーションで前述の要因を最小限に抑える必要があります。そうしないと、ゲートウェイのパフォーマンスはさほど向上しない場合があります。
次に、パフォーマンスに関する推奨事項を示します。
注意:
前提条件として、サーバー側のサービス処理時間が短い必要があります。レスポンス時間は、ゲートウェイ処理時間とサービス処理時間の合計です。サービス処理時間が非常に長いと、ゲートウェイのパフォーマンスの向上が抑制されます。
Domains環境でのトランザクションの管理
アプリケーション・プログラマは、トランザクション内でのリモート・サービスの実行をリクエストできます。また、リモート・ドメインのユーザーが、トランザクション内でのローカル・サービスの実行をリクエストすることもできます。Domainsは、リモート・トランザクションをローカル・トランザクションにマッピングしたり、これらのトランザクションが正しく終了(コミットまたはロールバック)されるように調整します。
Oracle Tuxedoのシステム・アーキテクチャでは、トランザクション・マネージャ・サーバー(TMS)という別個のプロセスにより、特定のグループにアクセスするトランザクション・ブランチのコミットやリカバリが調整されます。ただし、Domains環境で、受信したトランザクションのコミット操作を処理するには、ゲートウェイからTMSサーバーに別途メッセージを送信する必要があります。Domainsのアーキテクチャを単純化し、送信メッセージの数を抑えるため、TMSコードは、ゲートウェイ・コードと統合されています。これで、ドメイン・ゲートウェイは、Oracle Tuxedoシステムで使用されるトランザクション・プロトコルを処理できます。Oracle Tuxedoのトランザクション・プロトコルを使用するには、ドメイン・ゲートウェイ・グループでTMSサービスが通知されている必要があります(この通知は、最初のゲートウェイの起動時に実行されます)。いったんTMSサービスが通知されると、ドメイン・ゲートウェイ・グループ宛てのトランザクション・コントロール・メッセージは、すべてゲートウェイのキューに登録されます。
ドメイン・ゲートウェイ・グループは、TUXCONFIGファイルで定義されており、TMSNAMETMSCOUNTOPENINFOCLOSEINFOの各パラメータは指定されません。これらのパラメータは、XA対応のリソース・マネージャを使用するゲートウェイ・グループにのみ適用されるためです。ドメイン・ゲートウェイは、このリソース・マネージャを使用しません。
ドメインをまたがるコミット・プロトコルは厳密な階層構造になっています。トランザクション・ツリーを水平に構成することはできません。上位ドメインが認識するのは、すぐ下の下位ドメインのみであり、各ドメインがトランザクション・ツリーの構造を完全に把握しているわけではないためです。ツリーを水平に構成すると、トランザクションに参加しているすべてのドメインにルート・ドメインを完全に接続することも必要になります。
ドメイン・ゲートウェイには、トランザクションを管理するための4つの機能が用意されています。これらの機能については、次の各項で説明しています。
DomainsでTMS機能を使用する
Oracle TuxedoシステムのTMSは、X/Open XA準拠のリソース・マネージャを使用するサーバー・グループと暗黙的に関連付けられた特別なサーバーです。TMSサーバーは、分散型の2フェーズ・コミット・プロトコルに伴うアプリケーション・サーバーでの遅延を解消します。つまり、TMSサーバーは、TMSサービスに対して特殊なサービス・リクエストを発行することにより、トランザクションのコミットを調整します。このサービスは、すべてのTMSサーバーで提供されます。
一方、Domains環境では、GWTDOMAINゲートウェイはXA準拠のリソース・マネージャと関連付けられていません。X/Openのトランザクション処理ワーキング・グループ(TPWG)は高度なXAインタフェースを提案しました。このインタフェースは、Oracle Tuxedoシステムでは使用されていません。というのは、ゲートウェイに必要な非同期性の高い非ブロック型のモデルにインタフェースが一致しないからです。ドメイン・ゲートウェイは、専用のTMSサーバーは使用しませんが、トランザクション・マネージャ・サーバーと同等の機能、つまり、ドメイン間で実行されるトランザクションの2フェーズ・コミットを調整します。
ドメイン・ゲートウェイは、次のようにしてドメインをまたがるトランザクションを調整します。
1.
ドメイン・ゲートウェイは、TMSサービスを通知し、そのサービスに関連するすべての操作を実行します。このサービスに送信されたメッセージは、適切なドメイン・ゲートウェイ・グループによって使用されるキューに登録され、ゲートウェイはグループに対応付けられたトランザクションを管理します。
2.
図4-2 別のドメイン・ゲートウェイ・グループの下位ドメイン・ゲートウェイまたはコーディネータとしてのドメイン・ゲートウェイ
3.
図4-3 ドメイン・ゲートウェイによって管理されるクライアントのコミット
4.
ゲートウェイは、AUTOTRAN機能を使用して、転送サービスを使用する特定のクライアントまたはサーバーのためにトランザクションのコミットを管理します。この組合せが使用された場合には、転送チェーンの最後のサーバー(ドメイン・ゲートウェイ)がコミットを発行し、トランザクションのコーディネータになります。(ドメイン・ゲートウェイは、常に転送チェーンの最後のサーバーとして機能します。)
5.
ゲートウェイは、AUTOTRAN機能で指定されたリモート・サービスに対してトランザクションを自動的に開始および終了します。この機能は、アプリケーション管理者がリモート・サービスとのネットワーク・コミュニケーションの信頼性を強化したいときに必要です。管理者がこの機能を指定するには、対応するリモート・サービス定義の中のパラメータAUTOTRANYを設定します。
詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』「DMCONFIG(5)」DM_IMPORTに関する項を参照してください。
6.
トランザクションでGTRIDマッピングを使用する
Oracle Tuxedoシステムのトランザクション・ツリーは、2レベルで構成されています。ルートには、グローバル・トランザクションを調整するドメイン・ゲートウェイ・グループがあり、トランザクションはブランチに含まれます。各グループは、他のグループからは独立して、グローバル・トランザクションの一部を実行します。したがって、各グループは暗黙的にトランザクション・ブランチを定義します。Oracle Tuxedoシステムは、TMSサーバーを使用して、各ブランチの完了を確認しながら、グローバル・トランザクションの完了を調整します。
GTRIDは、グローバルトランザクション識別子です。GTRIDマッピングでは、ドメインの境界をまたぐトランザクション・ツリーの構築方法を定義します。GTRIDを指定するには、Oracle Tuxedo構成ファイルのRESOURCESセクションのMAXGTTパラメータを使用します。
密結合関係と疎結合関係の定義
X/Open DTPモデルのトランザクション・マネージャ・サーバーは、リソース・マネージャ(RM)との関係を表すトランザクション・ツリーを構築できます。関係は密結合または疎結合で定義し、XAインタフェースで使用されるトランザクション識別子(XID)が使用されます。
密結合関係では、1つのグローバル・トランザクションに参加するすべてのプロセスで同じトランザクション識別子(XID)が使用され、同じRMへのアクセスが行われます。この関係が確立されていると、プロセス間のデータ共有性を最大化できます。つまり、XA準拠のRMでは、同じXIDのプロセスによって使用されるリソースがロックを共有すると見なされます。Oracle Tuxedoシステムでは、「グループ」の概念に基づいて密結合関係を実現します。つまり、指定されたグローバル・トランザクションの代わりに、グループがすべての作業を行い、それらの作業は同じトランザクション・ブランチに設定されます。グループが行ったすべてのプロセスには、同じXIDが指定されます。
疎結合関係TMSは、グローバル・トランザクションに参加する各作業に対して、トランザクション・ブランチを生成します。RMは、各トランザクション・ブランチを別々に処理します。トランザクション・ブランチ間では、データやロックは共有されません。トランザクション・ブランチ間でデッドロックが発生すると、グローバル・トランザクションがロールバックされます。Oracle Tuxedoアプリケーションでは、1つのグローバル・トランザクションに様々なグループが参加している場合、グループごとに別のトランザクション・ブランチが定義され、疎結合関係が確立されます。
Domainsをまたがるグローバル・トランザクション
単独のOracle Tuxedoアプリケーション内のグローバル・トランザクションと、ドメインをまたがるグローバル・トランザクションとでは、いくつかの違いがあります。1つ目の違いは、Domainsのフレームワークでは、トランザクション・ツリーの構成を2レベルに下げることができないことです。これには、次の2つの理由があります。
つまり、ドメインをまたがるコミット・プロトコルは、階層型である必要があります。ループバック・サービス・リクエストも、トランザクション・ツリーでは新しいブランチとして定義されます。
注意:
ドメインをまたがるグローバル・トランザクションのトランザクション・ツリー構造は、対応するドメイン・ゲートウェイのインスタンスが使用する分散トランザクション処理プロトコルにも依存します。たとえば、OSI TPプロトコルのダイアログ(OSI TP用語でのサービス・リクエスト)は、それぞれ別のトランザクション・ブランチに関連付けられています。Oracle Tuxedoシステムでは、OSI TPインスタンスがサービス・リクエストでダイアログを使用するため、各サービス・リクエストは別のトランザクション・ブランチにマッピングされます。XAP-TPインタフェースは、このマッピングを隠し、ユーザー定義の識別子を使用してOSI TPサブツリー全体を参照するようなメカニズムを提供します。(Oracle Tuxedoの実装では、この識別子はGTRIDになります。)GTRIDは、トランザクション・ツリーの構築方法、つまり、指定されたOSI TPトランザクションにどのダイアログを含めるかをXAP-TPに指示するために使用されます。したがって、Oracle Tuxedoからは、OSI TPサブツリー全体が1つのトランザクション・ブランチとして管理されているように見えます。
ただしこの特徴は、送信サービス・リクエスト(ルート・ドメインから下位ドメインに送信されるサービス・リクエスト)にのみ適用されます。受信サービス・リクエストには適用されません。そのため、OSI TPのインスタンスは疎結合関係を実装し、各受信サービス・リクエストが新しいOracle Tuxedoグローバル・トランザクションにマッピングされます。
TDomainのインスタンスは、密結合関係を実現することにより、GTRIDのマッピングを最適化しようとします。TDomainでは、同じグローバル・トランザクションから発行された複数のサービス・リクエストは、同じネットワーク・トランザクション・ブランチにマッピングされます。したがって、受信したサービス・リクエストは、1つのOracle Tuxedoトランザクションにマッピングされます。ただし、ドメイン間通信の階層構造とドメイン間の関係を示すトランザクション・ツリーは保持される必要があります。
TDomainによる最適化は、単一のドメインに対してのみ適用されます。トランザクションに複数のドメインが関係する場合、ネットワーク・トランザクション・ツリーには、ドメイン間の通信ごとに少なくとも1つのブランチがあります。したがって、ドメインをまたがるネットワーク・トランザクション・ツリーは、疎結合のままになります。ブランチの数は、トランザクションに関係するドメインの数と同じになります。これは、すべてのブランチが同じリソース・マネージャのインスタンスにアクセスしている場合も同じです。
ドメイン・ゲートウェイ・グループは、ドメイン間のトランザクションに対して異なるトランザクション・ブランチを生成するため、疎結合関係を実装します。
ローカル・リクエストとリモート・リクエストを生成するサービス・リクエストグラフの例
図4-4に、3つのサービス・リクエスト(1つのローカル・リクエスト(r0)と2つのリモート・リクエスト(r2およびr3))を生成するクライアントのサービス・リクエストのグラフを示します。r0は、ローカル・サービス(Svc0)に送信され、別のリモート・サービス・リクエスト(r1)を生成します。r1はリモート・サービスRsvc1に送信され、Rsvc1は、ループバック・サービス・リクエストr4をローカル・サービスSvc4に送信します。Svc0Svc4は、別々のグループ(G0G4)で実行されます。ドメイン・ゲートウェイは、他のグループ(GW)内で実行され、リモート・サービスRsvc1Rsvc2およびRsvc3は別のドメイン(ドメインB)で実行されます。
図4-4 サービス・リクエストのグラフ
Oracle eLink OSI TPとOracle Tuxedo Domainsのトランザクション・ツリー
次の2つの図は、Oracle eLink OSI TPのトランザクション・ツリーと、Oracle Tuxedoドメインのトランザクション・ツリーを示します。これらの図では、ドメインAとドメインBがOracle Tuxedoシステムのアプリケーションであることを想定しています。
Oracle eLink OSI TPは、OSI TPプロトコルを使用しているため、疎結合です。このインスタンスのトランザクション・ツリーでは、クライアントが開始したグローバル・トランザクションを調整しているドメインA内に、グループG0が示されています。グループG0は、グループGWを調整します。r1r2、およびr3の3つのリクエストは、それぞれ別のOSI TPダイアログにマッピングされ、次に1つのOSI TPのトランザクション・ブランチにマッピングされます。ただし、OSI TPは、XAP-TPの機能を使用して、一意の識別子(T1)でOSI TPトランザクション全体を参照し、r1r2、およびr3の3つのリクエストにも使用します。OSI TPトランザクション識別子を作成し、対応するOSI TPトランザクション・ツリーを構築するかどうかは、XAP-TPに依存します。一般的なDomainsソフトウェアでは、r1、r2、およびr3の3つのリクエストのT1識別子へのマッピングが、必ず実行される唯一の処理です。
ドメインBでは、新しいトランザクション・ブランチを新しいOracle Tuxedoトランザクションにマッピングする必要があるという規則がOSI TPによって使用されています。したがって、OSI TPトランザクション・ブランチのr1r2およびr3は、3つの異なるOracle Tuxedoトランザクションにマッピングされます(各マッピングを、識別子T2T3およびT4で示しています)。グラフでは、Domain Bのドメイン・ゲートウェイ・グループGWが、グループG1での3つのOracle Tuxedoトランザクションを調整します。
ループバックのサービス・リクエストr4は、トランザクション・ツリーに別のブランチを生成します。OSI TPは、このリクエストを識別子T2にマッピングしますが、XAP-TPは、トランザクション・ツリーに新しいブランチを生成します。r4の場合は、BからA'のブランチです。生成されたブランチは、ドメインAの新しいトランザクション・ブランチであるため、ゲートウェイは新しいOracle Tuxedoトランザクションに対する新しいマッピングT5を生成します。トランザクション・グラフでは、ドメインAのドメイン・ゲートウェイ・グループGWが、グループG4を調整する様子を示します。
これらのマッピング関係によって、OSI TPプロトコルの階層性が完全に実現されていることに注意してください。ただし、これらのマッピング関係は疎結合であるため、トランザクション内でデッドロックが発生する可能性が高まります。たとえば、グループG1が示すRMには、3つのOracle Tuxedoトランザクションがアクセスします。
図4-5に、Oracle eLink OSI IP環境のトランザクション・ツリーを示します。
図4-5 Oracle eLink OSI TP環境のトランザクション・ツリー
TDomainのインスタンスは、密結合関係を使用してドメインを統合する、つまり、2つのドメイン間の処理で必要なトランザクション・ブランチの数を減らすことにより、このデッドロックを解決します。図4-6に、これを表すトランザクション・ツリーを示します。
図4-6 TDomain環境のトランザクション・ツリー
ゲートウェイはOracle Tuxedoシステム・トランザクションとネットワーク・トランザクション間で引き続きマッピングを実行する必要があり、ドメイン間通信の階層性が厳密に適用されている必要があることに注意します。この図では、r1r2およびr3のリクエストが、1つのTDomainトランザクション・ブランチにマッピングされています。したがって、ドメインBでは1つのOracle Tuxedoシステム・トランザクションが生成される必要があります。T2はこのマッピングを表し、グラフではグループG1を調整するドメインBのドメイン・ゲートウェイ・グループGWを示します。リクエストr4は、Domain Bの識別子T2にマッピングされますが、TDOMAINはトランザクション・ツリーに新しいブランチを生成します。r4の場合は、BからA'のブランチです。生成されたブランチは、ドメインAの新しいトランザクション・ブランチであるため、ゲートウェイは新しいOracle Tuxedoトランザクションに対する新しいマッピングT3を生成します。グラフでは、ドメインAのドメイン・ゲートウェイ・グループGWが、グループG4も調整する様子を示します。このマッピング関係により、ドメイン間通信の階層構造は強化されます。グループG4は、グループG1より先にコミットすることはできません。
Domainsでのトランザクション管理のサマリー
Domainsでのトランザクション管理は、次のようにまとめることができます。
ログ機能によるトランザクションの追跡
ログは、2フェーズ・コミット・プロトコルの進行を追跡するために使用します。ログの情報から、ネットワーク障害やマシンのクラッシュが発生したときに、トランザクションが完了したかどうかを確認できます。
ドメインをまたがるトランザクションが確実に完了するようにするため、ドメイン・ゲートウェイでは、ローカル識別子とリモート識別子間のマッピングが記録されます。このマッピング情報に加え、Domainsのトランザクション管理機能により、異なるコミット・プロトコル・フェーズで決定された処理と、トランザクションに関係するリモート・ドメインの情報が記録されます。OSI TPの場合、XAP-TPインタフェースにより、OSI TPプロトコル・マシンのリカバリに必要な情報が記録されます。blob (バイナリ・ラージ・オブジェクト)と呼ばれるこの情報は、コミット情報と同じログ・レコードに記録され、これを使用することでリカバリが容易になります。
Domainsのログ・レコードの構造は、Oracle TuxedoシステムのTLOGに格納されているログ・レコードの構造とは異なります。TLOGレコードのサイズは決まっており、単一のページに格納されています。一方、Domainsのログ・レコードのサイズは可変であり、レコードの大きさによっては、複数のページが必要な場合もあります。Domainsのログ・メカニズムであるDMTLOGでは、様々なサイズのログ・レコードを格納できます。
TMSがドメイン・ゲートウェイ・グループより上位の場合は、コミットの調整のためにOracle TuxedoのTLOGが必要です。
ログは、GWADM管理サーバーによって記録されます。ログへの書込みは、GWTDOMAINプロセスによってリクエストされますが、実際の書込みは、GWADMプロセスによって実行されます。
各ドメイン・ゲートウェイ・グループには、DMTLOGというログ・ファイルを作成する必要があります。DMTLOGファイルは、DMCONFIGファイルのDM_LOCALセクションで定義されます。DMTLOGファイルを作成するには、DMTLOGDEVパラメータにエントリを追加します。
DMTLOGDEV=string
stringはログ・ファイルの名前です。さらに、次の2つのオプション・パラメータのどちらか、または両方を設定できます。
DMTLOGNAME=identifier
詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』DMCONFIG(5)に関する項を参照してください。
管理者は、実行時管理ユーティリティ(dmadmin)を使用してDMTLOGを作成することもできます。詳細は、『Oracle Tuxedoコマンド・リファレンス』dmadmin(1)に関する項を参照してください。
ドメイン・ゲートウェイ・グループの起動時に、DMTLOGが作成されていないと、ゲートウェイ・サーバーは、BDMCONFIGファイルの情報に基づき、ログを自動的に作成します。
BDMCONFIGファイルでログ・デバイスが指定されないかぎり、ドメイン・ゲートウェイ・グループは、リクエストをトランザクション・モードで実行できず、ドメイン・ゲートウェイ・グループはTMSサービスを提供できません。
コミット・プロトコルを調整するため、ドメイン・ゲートウェイでは、次の2つのログ・レコードが必要です。
レディ・レコード - トランザクション・ツリーでリーフまたは中間マシンとして機能するファイルです。ゲートウェイによって作成されます。このファイルには、トランザクションに関連する上位および下位のリモート・ドメインについての情報が記録されます。レディ・レコードは、レコードを記録するドメイン・ゲートウェイ・グループの下位のものがすべて準備できたことを示します。
コミット・レコード - コミット・レコードは、トランザクションがコミットされたことを記録します。ドメイン・ゲートウェイは、特定のトランザクション・ツリーのコーディネータとして、コミット・レコードを作成します。
トランザクションがすべてのマシンでコミットされると、そのトランザクションのログは削除されます。
OSI TPプロトコルを使用する場合は、次の2つのヒューリスティックなレコードが記録されます。
ログ・ヒューリスティック・レコード - ドメインで行われたヒューリスティックな決定の詳細を記録します。この情報は、適切なトランザクションの結果が上位ドメインに通知されるまで保持されます。
ログ破損レコード - トランザクション・ブランチの2種類の状態、つまり、ヒューリスティック・ハザード(下位ドメインのトランザクション・ブランチの結果が不明)またはヒューリスティック・ミックス(トランザクション・サブツリーの結果が混在)のいずれかを示します。これは、tmadmin(1)を実行して作成します。
ヒューリスティックなログ・レコードは、管理者によって明示的に削除されるまで保持されます。この特性は、クラッシュ後のリカバリ処理で正しい情報を取得し、管理者に対して診断情報を提供するために必要です。
管理者は、forgettranコマンド(tmadmin(1)で実行)を使用して、不要になったヒューリスティック・レコードを削除します。
失敗したトランザクションの回復
ドメイン・ゲートウェイ・グループが起動すると、ゲートウェイ・サーバーは、DMTLOGを自動的にウォームスタートします。ウォームスタートでは、ログがスキャンされ、未完了のトランザクションがあるかどうかがチェックされます。未完了のトランザクションが見つかると、そのトランザクションを処理するアクションが実行されます。
OSI TPでは、DMTLOG内のblobsにあるトランザクション・レコードが、ネットワーク・アクセス・モジュールに渡されます。渡されたblobは、内部状態を再構築し、失敗した接続を回復するために使用されます
ドメイン・ゲートウェイ・グループがローカルTMSの下位であり、ヒューリスティックな決定が行われた場合、TMSは、最終的に決定された処理を示すTMS_STATUSメッセージを生成します。
ゲートウェイが失敗した場合は、再起動後にゲートウェイ自体がクリーンアップされます(ホット・スタート)。ゲートウェイは、関連する未処理のトランザクションをすべてロールバックします。

Copyright ©1994, 2017,Oracle and/or its affiliates. All rights reserved