![]() ![]() ![]() ![]() ![]() ![]() ![]() |
以下の項では、Oracle Tuxedo Domains環境を管理する方法について説明します。
Domainsコンポーネントを既存のOracle Tuxedoアプリケーションと統合するには、ドメイン・ゲートウェイ・グループとゲートウェイ・サーバーのエントリをTUXCONFIG
ファイルに追加します。実行中のOracle TuxedoアプリケーションにDomains構成を追加するには、tmconfig(1)
またはtmadmin(1)
コマンドを使用します。tmadmin
を使用すると、ドメイン・ゲートウェイ・グループや個々のドメイン・ゲートウェイの掲示板で使用できる情報をリストすることもできます。
Domains環境を設定し、統合すると、Domainsコンポーネントに用意されている一連の管理ツールを使用して、Domains環境を動的に管理できます。たとえば、アプリケーションのどこからでもアクセスできるサービスをリスト化したり、そのリストを変更することができます。Domainsソフトウェアには、Oracle Tuxedoのプログラミング・インタフェース(ATMI)の機能に加え、拡張された機能が備わっているため、クライアントはドメイン内のあらゆるサービスを呼び出すことができます。この機能により、プログラマは、アプリケーション・コードを変更せずに、アプリケーションを拡張したり、分割できます。
図4-1は、Domainsの管理サブシステムにおける管理コマンドと管理サーバーの関係を示します。
Oracle Tuxedo Domainsコンポーネントには、次の管理コマンドが用意されています。
BDMCONFIG
)を更新できます。このコマンドは、管理コマンドを変換したり、サービス・リクエストをDMADMIN
サービスに送信したりするフロントエンド・プロセッサとして機能します。DMADMINサービスは、DMADM
サーバーにより公開される汎用管理サービスです。DMADMIN
サービスは、DMADM
サーバーに組み込まれている、検証、検索、または更新を行う機能を呼び出して、BDMCONFIG
ファイルを管理します。dmadmin
コマンドに対するバックエンドとして機能し、ドメイン・ゲートウェイ・グループの登録サービスを提供します。この登録サービスは、GWADM
サーバーの初期化処理で要求されます。登録サービスは、リクエスト元のドメイン・ゲートウェイ・グループが要求する構成情報をダウンロードします。DMADM
サーバーは、登録済みのドメイン・ゲートウェイ・グループのリストを管理し、構成ファイルが変更されると、変更内容をリスト内のドメイン・ゲートウェイ・グループに伝播します。DMADM
サーバーに登録され、対応するドメイン・ゲートウェイ・グループに使用される構成情報を取得します。GWADM
は、DMADM
からの問合せ、つまり、対応するドメイン・ゲートウェイ・グループの実行時オプションでの統計情報や変更に対する問合せを受け付けます。GWADM
サーバーは、"I-am-alive"メッセージを定期的にDMADM
サーバーに送信します。DMADM
サーバーから応答がない場合、GWADM
サーバーは再度登録を行います。このメカニズムにより、GWADM
サーバーは、そのグループのDomains構成に関する最新の情報を常に保持できます。注意: | 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
は、DMADM
サーバー用のGWADM
サーバーへの管理インタフェースです。これらの2つのサーバー間の通信は、FMLの型付きバッファを使用して実行されます。管理者は、dmadmin
コマンドを使用して、次の作業を実行できます。
注意: | 実行時にBDMCONFIG ファイルから削除できるのは、アクティブなドメイン・ゲートウェイ・グループとは関係のない情報だけです。 |
Domainsの管理サーバーであるDMADM(5)は、Oracle Tuxedoに組み込まれているサーバーであり、以下の機能を実行します。
DMADM
サーバーは、グループ内で実行しているサーバー(DMADMGRP
など)としてTUXCONFIG
ファイルのSERVERS
セクションで定義されている必要があります。このグループには、DMADM
サーバーのインスタンスが1つのみ必要です。
ゲートウェイ管理サーバー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
サーバーはshmget
でIPC_PRIVATE
を使用し、掲示板のレジストリ・エントリにあるshmid
フィールドに返されたipckey
を格納します。ゲートウェイは、GWADM
レジストリ・エントリを取得し、shmid
フィールドをチェックすることにより、ipckey
を取得できます。
ドメイン・ゲートウェイ・サーバーは、リモート・ドメイン・ゲートウェイ・サーバーへの接続を実現し、1つ以上のリモート・ゲートウェイと同時に通信できます。ゲートウェイは、Oracle Tuxedoアプリケーションにインポートされたサービスを通知し、アプリケーションによってエクスポートされたローカル・サービスへのアクセスを制御します。アプリケーションのエクスポートされたサービスとインポートされたサービスは、Domains構成ファイル(DMCONFIG
)で定義します。ドメイン・ゲートウェイ・グループを動的に構成、モニターおよび調整するには、dmadmin
を使用します。
Oracle Tuxedo 9.xでは、GWTDOMAINゲートウェイのパフォーマンスの向上を実現しつつ、ほかのタイプの/Domainゲートウェイとの互換性を保持しています。このため、パフォーマンスの大部分はスレッド対応プラットフォームに制限されます。また、プログラムを一部変更するだけで、ほかのタイプの/Domainゲートウェイも、拡張された共通ゲートウェイ・アーキテクチャでこの機能を利用できます。
複数のドメインにわたるアプリケーションのパフォーマンスは、様々な要因の影響を受けます。例:
このため、ドメイン・ゲートウェイのパフォーマンスの向上を実感するには、アプリケーションで上記の要因を最小限に抑える必要があります。そのようにしない場合、ゲートウェイのパフォーマンスはさほど向上しない場合があります。
注意: | 前提条件として、サーバー側のサービス処理時間が短くなくてはなりません。レスポンス時間は、ゲートウェイ処理時間とサービス処理時間の合計です。サービス処理時間が非常に長いと、ゲートウェイのパフォーマンスの向上が抑制されます。 |
アプリケーション・プログラマは、トランザクションでリモート・サービスの実行をリクエストすることができます。また、リモート・ドメインのユーザーが、トランザクションでローカル・サービスの実行をリクエストすることもできます。Domainsは、リモート・トランザクションをローカル・トランザクションにマッピングしたり、これらのトランザクションが正しく終了(コミットまたはロールバック)されるように調整する役割を果たします。
Oracle Tuxedoのシステム・アーキテクチャでは、トランザクション・マネージャ・サーバー(TMS
: Transaction Manager Server)という別個のプロセスにより、特定のグループにアクセスするトランザクション・ブランチのコミットやリカバリが調整されます。ただし、Domains環境で、受信したトランザクションのコミット操作を処理するには、ゲートウェイからTMS
サーバーに別途メッセージを送信する必要があります。Domainsのアーキテクチャを単純化し、送信メッセージの数を抑えるため、TMS
コードは、ゲートウェイ・コードと統合されています。これで、ドメイン・ゲートウェイは、Oracle Tuxedoシステムで使用されるトランザクション・プロトコルを処理できます。Oracle Tuxedoのトランザクション・プロトコルを使用するには、ドメイン・ゲートウェイ・グループでTMS
サービスが通知されている必要があります(この通知は、最初のゲートウェイの起動時に実行されます)。いったんTMS
サービスが通知されると、ドメイン・ゲートウェイ・グループ宛てのトランザクション・コントロール・メッセージは、すべてゲートウェイのキューに登録されます。
ドメイン・ゲートウェイ・グループは、TUXCONFIG
ファイルで定義されており、TMSNAME
、TMSCOUNT
、OPENINFO
、CLOSEINFO
の4つのパラメータは指定されません。これらのパラメータは、XA対応のリソース・マネージャを使用するゲートウェイ・グループにのみ適用されるためです。ドメイン・ゲートウェイは、このリソース・マネージャを使用しません。
ドメインのコミット・プロトコルは厳密な階層構造になっています。トランザクション・ツリーを水平に構成することはできません。上位ドメインが認識するのは、すぐ下の下位ドメインだけであり、各ドメインがトランザクション・ツリー全体を把握しているわけではないためです。ツリーを水平に構成すると、トランザクションに参加しているすべてのドメインにルート・ドメインを完全に接続することも必要になります。
ドメイン・ゲートウェイには、トランザクションを管理するための4つの機能が用意されています。これらの機能については、以下の項を参照してください。
Oracle TuxedoシステムのTMS
は、X/Open XA準拠のリソース・マネージャを使用するサーバー・グループと暗黙的に関連付けられた特別なサーバーです。TMS
サーバーは、分散型の2フェーズ・コミット・プロトコルに伴うアプリケーション・サーバーでの遅延を解消します。つまり、TMS
サーバーは、TMS
サービスに対して特殊なサービス・リクエストを発行することにより、トランザクションのコミットを調整します。このサービスは、すべてのTMS
サーバーで提供されます。
一方、Domains環境では、GWTDOMAIN
ゲートウェイはXA準拠のリソース・マネージャと関連付けられていません。X/Openのトランザクション処理ワーキング・グループ(TPWG
)は高度なXAインタフェースを提案しました。このインタフェースは、Oracle Tuxedoシステムでは使用されていません。というのは、ゲートウェイに必要な非同期性の高い非ブロック型のモデルにインタフェースが一致しないからです。ドメイン・ゲートウェイは、専用のTMS
サーバーは使用しませんが、トランザクション・マネージャ・サーバーと同等の機能、つまり、ドメイン間で実行されるトランザクションの2フェーズ・コミットを調整します。
ドメイン・ゲートウェイは、次のようにしてドメインをまたがるトランザクションを調整します。
TMS
サービスを公開し、そのサービスに関連するすべての操作を行います。このサービスに送信されたメッセージは、適切なドメイン・ゲートウェイ・グループによって使用されるキューに登録され、ゲートウェイはグループに対応付けられたトランザクションを管理します。AUTOTRAN
機能を使用して、転送サービスを使用する特定のクライアントまたはサーバーのためにトランザクションのコミットを管理します。この組合せが使用された場合には、転送チェーンの最後のサーバー(ドメイン・ゲートウェイ)がコミットを発行し、トランザクションのコーディネータになります。(ドメイン・ゲートウェイは、常に転送チェーンの最後のサーバーとして機能します。)AUTOTRAN
機能で指定されたリモート・サービスに対してトランザクションを自動的に開始および終了します。この機能は、アプリケーション管理者がリモート・サービスとのネットワーク・コミュニケーションの信頼性を強化したいときに必要です。管理者がこの機能を指定するには、対応するリモート・サービス定義の中のパラメータAUTOTRAN
にY
を設定します。 詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「DMCONFIG(5)」のDM_IMPORT
セクションを参照してください。
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つのグローバル・トランザクションにさまざまなグループが参加している場合、グループごとに別のトランザクション・ブランチが定義され、疎結合関係が確立されます。
単独のOracle Tuxedoアプリケーション内のグローバル・トランザクションと、ドメインをまたがるグローバル・トランザクションとでは、いくつかの違いがあります。最大の相違点は、Domainsのフレームワークでは、トランザクション・ツリーの構成を2レベルに下げることができないことです。これには、次の2つの理由があります。
つまり、ドメインをまたがるコミット・プロトコルは、階層型でなければなりません。ループバックされたサービス・リクエストも、トランザクション・ツリーでは新しいブランチとして定義されます。
注意: | ループバック・リクエストとは、別のドメインに送信された後で、送信元のドメインに返される要求です。たとえば、ドメインAがドメインBのサービスを要求したとします。ドメインBのサービスは、ドメインAの別のサービスを要求します。トランザクション・ツリーには、ネットワーク・レベルで2つのブランチがあります。つまり、ドメインAからドメインBへの要求を示すブランチb1と、ドメインBからドメインAへの要求を示すブランチb2です。ドメインAは、ドメインBからコミットの指示を受けるまで、ブランチb2の作業をコミットすることはできません。 |
ドメインをまたがるグローバル・トランザクションのトランザクション・ツリー構造は、対応するドメイン・ゲートウェイのインスタンスが使用する分散トランザクション処理プロトコルにも依存します。たとえば、OSI TPプロトコルのダイアログ (OSI TPでのサービス・リクエスト)は、それぞれ別のトランザクション・ブランチに関連付けられています。Oracle Tuxedoシステムでは、OSI TPインスタンスがサービス・リクエストでダイアログを使用するため、各サービス・リクエストは別のトランザクション・ブランチにマッピングされます。XAP-TPインタフェースは、このマッピングを隠し、ユーザー定義の識別子を使用してOSI TPサブツリー全体を参照するようなメカニズムを提供します。(Oracle Tuxedoの実装では、この識別子はGTRID
になります。)GTRID
はトランザクション・ツリーの構築方法をXAP-TPに指示します。つまり、指定されたOSI 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
に送信します。Svc0
とSvc4
は、別々のグループ(G0
とG4
)で実行されます。ドメイン・ゲートウェイは、他のグループ(GW
)内で実行され、リモート・サービスRsvc1
、Rsvc2
およびRsvc3
は別のドメイン(ドメインB)で実行されます。
次の2つの図は、Oracle eLink OSI TPのトランザクション・ツリーと、Oracle Tuxedoドメインのトランザクション・ツリーを示します。これらの図では、ドメインAとドメインBがOracle Tuxedoシステムのアプリケーションであることを想定しています。
Oracle eLink OSI TPは、OSI TPプロトコルを使用しているため、疎結合です。このインスタンスのトランザクション・ツリーでは、ドメインA (クライアントが開始したグローバル・トランザクションを調整)内にグループG0が示されています。グループG0
は、グループGW
を調整します。r1
、r2
、およびr3
の3つのリクエストは、それぞれ別のOSI TPダイアログにマッピングされ、次に1つのOSI TPのトランザクション・ブランチにマッピングされます。ただし、OSI TPは、XAP-TPの機能を使用して、一意の識別子(T1
)でOSI TPトランザクション全体を参照し、r1
、r2
、およびr3
の3つのリクエストにも使用します。OSI TPトランザクション識別子を作成し、対応するOSI TPトランザクション・ツリーを構築するかどうかは、XAP-TPに依存します。一般的なDomainsソフトウェアでは、r1、r2、およびr3の3つのリクエストのT1
識別子へのマッピングが、必ず実行される唯一の処理です。
Domain Bでは、新しいOracle Tuxedoトランザクションには新しいトランザクション・ブランチをマッピングする、というOSI TPの規則が使用されます。したがって、OSI TPトランザクション・ブランチであるr1
、r2
、およびr3
は、3つの異なるOracle Tuxedoトランザクション(T2
、T3
、および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トランザクションがアクセスします。
Oracle eLink OSI IP環境のトランザクション・ツリーを図4-5に示します。
TDomainのインスタンスは、密結合関係を使用してドメインを統合する、つまり、2つのドメイン間の処理で必要なトランザクション・ブランチの数を減らすことにより、このデッドロックを解決します。図4-6は、この関係を表すトランザクション・ツリーを示しています。
ゲートウェイはOracle Tuxedoシステム・トランザクションとネットワーク・トランザクション間で継続してマッピングを実行する必要があり、ドメイン間通信の階層構造は厳密に強化される必要があることに注意します。この図では、r1
、r2
、およびr3
の3つのリクエストが、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でのトランザクション管理は、次のようにまとめることができます。
ログ機能は、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つのオプション・パラメータのどちらか、または両方を設定できます。
詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のDMCONFIG(5)を参照してください。
管理者は、実行時管理ユーティリティ(dmadmin
)を使用してDMTLOG
を作成することもできます。詳細は、『Oracle Tuxedoコマンド・リファレンス』のdmadmin(1)を参照してください。
ドメイン・ゲートウェイ・グループの起動時に、DMTLOG
が作成されていないと、ゲートウェイ・サーバーは、BDMCONFIG
ファイルの情報に基づき、ログを自動的に作成します。
BDMCONFIG
ファイルでログ・デバイスが指定されないかぎり、ドメイン・ゲートウェイ・グループは、リクエストをトランザクション・モードで実行できず、ドメイン・ゲートウェイ・グループはTMS
サービスを提供できません。
コミット・プロトコルを調整するため、ドメイン・ゲートウェイでは、次の2つのログ・レコードが必要です。
トランザクションがすべてのマシンでコミットされると、そのトランザクションのログは削除されます。
OSI TPプロトコルを使用する場合は、次の2つのヒューリスティックなレコードが記録されます。
ヒューリスティックなログ・レコードは、管理者によって明示的に削除されないかぎり、削除されません。この特性は、クラッシュ時のリカバリ処理で正しい情報を取得し、管理者に対して診断情報を提供するために必要です。
管理者は、forgettran
コマンド(tmadmin(1)で実行)を使用して、不要になったヒューリスティック・レコードを削除することができます。
ドメイン・ゲートウェイ・グループが起動すると、ゲートウェイ・サーバーは、DMTLOG
を自動的にウォームスタートします。ウォームスタートでは、ログがスキャンされ、未完了のトランザクションがあるかどうかがチェックされます。未完了のトランザクションが見つかると、そのトランザクションを処理するアクションが実行されます。
OSI TPでは、DMTLOG
内のblobにあるトランザクション・レコードが、ネットワーク・アクセス・モジュールに渡されます。渡されたblobは、内部状態を再構築し、失敗した接続を回復するために使用されます。
ドメイン・ゲートウェイ・グループがローカルTMS
の下位であり、ヒューリスティックな決定が行われた場合、TMS
は、最終的に決定された処理を示すTMS_STATUS
メッセージを生成します。
![]() ![]() ![]() |