|
|
以下の項では、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を設定します。 詳細は、『Oracle Tuxedoファイル形式、データ記述、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は、トランザクション・ツリーの構築方法、つまり、指定された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に送信します。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つのオプション・パラメータのどちらか、または両方を設定できます。
詳細は、『Oracle Tuxedoファイル形式、データ記述、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メッセージを生成します。
  
|