このドキュメントでは、Oracle Tuxedo Advanced Performance Packのすべての機能を紹介します。このドキュメントで、これらの新機能の構成方法および既存のアプリケーションでの利用方法について学習できます。
Oracle Tuxedo Advanced Performance Packは、Oracle Tuxedo 12cリリース2 (12.1.3)の新しい製品オプションです。このパックを使用すると、Oracle Tuxedoアプリケーションのパフォーマンスが大幅に向上し、アプリケーションの可用性が増します。特に、Oracle Database/RACと連携している場合は顕著です。このパックの機能は、Microsoft Windowsプラットフォーム上のOracle Tuxedo 32ビットを除く、Oracle Tuxedoでサポートされるすべてのプラットフォームで実行できます。
Oracle Tuxedo Advanced Performance Packには、次の機能が備わっています。
この機能を使用すると、CPUサイクルを最大限に活用できるようにSPINCOUNT
の値を動的に調整できます。
Tuxedoの掲示板(BB)は、すべてのアプリケーション構成情報および動的処理情報が実行時に格納されるメモリー・セグメントです。Tuxedoシステムの一部の操作(サービス名のルックアップやトランザクションなど)では、掲示板をロックし、掲示板へのアクセスを1つのプロセスのみに制限する場合があります。プロセスまたはスレッドにより、掲示板が別のプロセスまたはスレッドでロックされていることが検出されると、再試行するか、ロック・スピンをSPINCOUNT
回数行ってから(スピンを介したユーザー・レベル・メソッド)、この操作をやめて、待機キューでスリープ状態に入ります(システム・セマフォを介したシステム・レベル・メソッド)。スリープ状態はリソースを消費するため、一定のロック・スピンを行ってからスリープ状態になるように設定しておく方が効率的です。
SPINCOUNT
パラメータの値は、アプリケーションおよびシステムによって異なるため、管理者は異なるSPINCOUNT
値の下でアプリケーション・スループットを確認して、SPINCOUT
が適切な値になるように手動で調整する必要があります。
自動チューニング・ロック・メカニズムにより、ジョブのチューニングを自動的に行います。SPINCOUNT
値が適切な値になるように設計されているため、掲示板をロックするほとんどのリクエストが、待機キューでスリープ状態になるのではなく、ロック・スピンを行うことによって完了します。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
Oracle Tuxedo 12cリリース2 (12.1.3)では、同一のTuxedoノードにおけるプロセス間通信でIPCメッセージ・キューのかわりに共有メモリー・キューを用いることで、Tuxedoアプリケーションのパフォーマンスが大幅に改善されます。共有メモリー・キューを使用すると、送信側と受信側のプロセスが割当て前のメッセージを共有メモリー内で交換することができ、本来の宛先にメッセージが届くまでに何回もコピーする必要がなくなるため、スループットが大幅に向上し、待機時間が短縮されます。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
異なるドメインでは異なるグローバル・トランザクション識別子(GTRID)が使用されるため、トランザクションのブランチが同じデータベース上で実行される場合でも、ドメインをまたがるトランザクションは疎結合されます。Oracle Tuxedo Advanced Performance Packのこの機能を使用すると、共通GTRIDがデフォルトで導入され、ドメインをまたがるグローバル・トランザクション内のブランチで共通GTRIDが使用されます。ブランチが同一データベースで実行される場合、ブランチは密結合されます(データベースが許可している場合)。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
Oracle Tuxedoでは、グローバル・トランザクション表(GTT)と呼ばれるOracle Tuxedo掲示板にアクティブなグローバル・トランザクションとそのパーティシパントの表を保持することでグローバル・トランザクションを管理します。この表は複数の同時プロセスによってアクセスされるため、セマフォを使用して保護する必要があります。通常のOracle Tuxedoの場合、掲示板のロックを使用してこの表へのアクセスはシリアライズされます。ただし、トランザクションの負荷が高い場合、このロックの競合が激しくなり、人為的なパフォーマンス・ボトルネックとなる場合があります。
Oracle Tuxedo Advanced Performance Packでは、XAトランザクションを使用して同時実効性を向上させ、ボトルネックを解消してTuxedoアプリケーションのパフォーマンスを改善します。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
この機能では、XAのリソース・マネージャの読取り専用最適化を利用します。2フェーズ・コミットのシナリオを例にします。Tuxedoが1つのトランザクション・ブランチを保留し、他のすべてのブランチを同時に準備します。他のすべてのトランザクション・ブランチが読取り専用の場合、Tuxedoは保留したブランチについて準備リクエストの送信およびTLOG
の書込みを行わずに直接1フェーズ・コミットを行います。それ以外の場合、Tuxedoは保留したブランチについて2フェーズ・コミットを行います。
TuxedoドメインおよびWTCを介したWLS間のグローバル・トランザクションを含む、ドメイン内またはドメイン間のいずれのトランザクションもサポートされます(WLS 12.1.1の場合、WLSのパッチ、または以降のリリースについて、Oracleサポートにお問い合せください)。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
以前のリリースでは、同一の参加グループのサーバーはグローバル・トランザクション内の同一トランザクション・ブランチを使用しています。これらのサーバーが同一RACの異なるインスタンスに接続する場合は、トランザクション・ブランチは失敗し、XAエラーXAER_AFFINITY
が報告されます。これは、1つのブランチでは複数のインスタンスを通過できないことを示しています。このような理由から、Tuxedoグループで使用できるのは、シングルトンRACサービスのみです。DTPサービス(DTPオプションであるsrvctl
内の-x
が指定されている場合)または1つのインスタンスのみで提供されるサービスを、シングルトンRACサービスに指定できます。
このリリースでは、この機能により、サーバー・グループ内の複数サーバーが同一のグローバル・トランザクションに参加している場合の、シングルトンRACサービスの使用が不要になります。同一サーバー・グループおよび同一グローバル・トランザクションのサーバーが異なるRACインスタンスに接続している場合は、別のトランザクション・ブランチが使用されます。これにより、このようなアプリケーションは、使用可能なRACインスタンス間でロード・バランシングを実行できるようになります。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
注意: | 1つのグループに16を超えるインスタンスが含まれる場合、トランザクションは依然として失敗します。 |
グローバル・トランザクションでは、参加している各グループにはそれぞれのトランザクション・ブランチがあり、特別なトランザクション・ブランチ識別子(XID)で各ブランチが識別されます。グローバル・トランザクションに複数のグループが含まれる場合、Tuxedoでは各ブランチで2フェーズ・コミットを採用し、最初に参加しているグループをコーディネータとみなします。
Oracle Tuxedo Advanced Performance Packの共通XID (トランザクション・ブランチ識別子)機能を使用して、Tuxedoは同一グローバル・トランザクション内の他のすべてのグループとコーディネータ・グループのXIDを共有します。以前のリリースでは、複数グループが参加している場合は、各グループが自身のXIDを持つために2フェーズ・コミットを必要としましたが、これとは対照的です。
共通XIDは、コーディネータ・ブランチを直接使用するため、同一のサービスを介して同一のOracle RACインスタンスに接続するグループに対するXAコミット操作が不要です。
グローバル・トランザクションのすべてのグループがコーディネータ・ブランチを直接使用する場合、(2フェーズ・コミット・プロトコルではなく)1フェーズ・コミット・プロトコルが使用されるため、TLOG
の書込みは行われません。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
XAトランザクション・アフィニティは、可能な場合に、1つのグローバル・トランザクション内のすべてのOracle Databaseリクエストを同一のOracle RACインスタンスにルーティングする機能を提供します。そのリクエストがOracle Tuxedoアプリケーション・サーバーからのものか、Oracle WebLogic Serverからのものかは関係ありません。この機能により、データベース要求を新しいOracle RACインスタンスにリダイレクトするコストを削減できるため、アプリケーション・パフォーマンス全体が向上します。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
高速アプリケーション通知(FAN)は、データベース・クライアントがデータベースの状態の変化を知ることができる、Oracle Databaseによって提供される機能です。これらの通知によって、アプリケーションはRACノードの計画停止やデータベースの負荷の不均衡などのイベントに対してプロアクティブに対応できます。Tuxedoは、新しいシステム・サーバーTMFAN
によってFAN通知のサポートを提供します。このシステム・サーバーでOracle RACインスタンスをモニターし、データベース・インスタンスの起動または停止の場合にTuxedoアプリケーション・サーバーに通知して新規データベース接続を確立できます。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
FAN通知に基づいてTuxedo TMFAN
サーバーは、各RACインスタンスの負荷情報を含むロード・バランシング・アドバイザリを受信できます。指摘された負荷の変化がTMFAN
コマンド行スイッチで指定されたしきい値を超えた場合、Tuxedoリクエストはデータベースの負荷の低いTuxedoアプリケーション・サーバーに転送されます。
構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
この項では、Oracle Tuxedo Advanced Performance Packの各種機能の構成方法について説明します。
UBBCONFIG
のRESOURES
のOPTIONS
パラメータがXPP
に設定されている場合、この製品のすべての機能が有効です。Oracle ExalogicおよびOracle SPARC SuperClusterプラットフォームでは、OPTIONS
パラメータはEECS
に設定される必要があります。
一部の機能には追加構成が必要です。このような各機能の構成について以降で説明します。これらの各機能は、必要に応じて個々に無効にできます。機能を個々に無効にする方法についてもこの項で説明します。
2つのオプション属性がUBBCONFIG
*MACHINES
セクションでサポートされます。
SPINTUNING_FACTOR
SPINTUNING_FACTOR
は、チューニング対象を制御します。デフォルト値は100で、ほとんどのシナリオでは十分な値です。必要に応じて、1から10000まで変更できます。100という値は、ロック試行回数が1/100未満である結果、システム・レベル・メソッドでBBロックを取得し、十分なアイドルCPUがあるかぎり、SPINCOUNT
がチューニングを停止することを示します。システム・レベル・メソッドのロック試行回数が1を超え、十分なアイドルCPU時間がある場合には、SPINCOUNT
が増加します。
SPINTUNING_MINIDLECPU
: CPUアイドル時間を指定します。
SPINTUNING_MINIDLECPU
の制限に達すると、SPINCOUNT
を増加しません。それとは反対に、チューニング対象が満たされるかどうかにかかわらず、SPINTUNING_MINIDLECPU
の制限が解除される場合は、SPINCOUNT
は減少します。たとえば、20の値が指定される場合、自動チューニング・ロック・メカニズムは、調整中に20%以上のアイドルCPU時間を制御します。デフォルト値は20です。
注: |
詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのUBBCONFIG(5)
およびUBBCONFIG(5)の追加情報の例2 自動チューニング・ロック・メカニズムの構成に関する項を参照してください。
TM_MIB
を介しても構成を設定できます。詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTM_MIB(5)
に関する項を参照してください。
リスト1は、自動チューニング・ロック・メカニズムを有効化するUBBCONFIG
サンプル・ファイルです。
*RESOURCES
OPTIONS XPP
...
この機能は、UBBCONFIG
ファイルでオプションNO_SPINTUNING
を指定して無効にできます。
リスト2は、自動チューニング・ロック・メカニズムを無効化するUBBCONFIG
サンプル・ファイルです。
*RESOURCES
OPTIONS XPP,NO_SPINTUNING
...
*RESOURCES
セクションでは、さらに別のオプション属性が用意されています
SHMQMAXMEM numeric_value
numeric_value
の範囲は1から2000 (1と2000を含む)です。その他のプラットフォームの場合、numeric_value
の範囲は1から96000 (1と96000を含む)です。SHMQMAXMEM
が指定されていない場合、推奨最小値が使用されます。この値はほとんどすべてのシナリオで十分な値です。 推奨最小値を取得するには、tmloadcf – c
を実行します。詳細は、『Oracle Tuxedoコマンド・リファレンス』のtmloadcf(1)
に関する項を参照してください。
注意: | IBM AIX 32ビット・プロセスでは、必要なメモリーが256MBより大きい場合、大規模または非常に大規模なアドレス空間モデルを有効にする必要があります。通常、環境変数LDR_CNTRL を使用してモデルを有効にできます。詳細は、IBMナレッジ・センターで大規模および非常に大規模なアドレス空間モデルを参照してください。 |
リスト3に、共有メモリー・プロセス間通信を有効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
...
この機能は、UBBCONFIG
ファイルでオプションNO_SHMQ
を指定して無効にできます。
リスト4に、共有メモリー・プロセス間通信を無効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP,NO_SHMQ
...
Oracle Tuxedo Advanced Performance Packを使用する場合、この機能はデフォルトで有効で、無効にできません。
Oracle Tuxedo Advanced Performance Packを使用する場合、この機能はデフォルトで有効で、無効にできません。
*RESOURCES
OPTIONS XPP
リスト6に、RACの部分的1フェーズ読取り専用最適化を有効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
...
この機能は、UBBCONFIG
ファイルでオプションNO_RDONLY
を指定して無効にできます。
リスト7に、RACの部分的1フェーズ読取り専用最適化を無効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP,NO_RDONLY1PC
...
TM_MIB
を介しても構成を取得/変更できます。詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTM_MIB(5)
に関する項を参照してください。
リスト8に、SGMBを有効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
この機能は、UBBCONFIG
ファイルでオプションRMOPTIONS
のSINGLETON
を指定して無効にできます。
RMOPTIONS {[...|SINGLETON],*}
注意: | このオプションは、ドメインで使用されるすべてのRACサービスがシングルトンであることを示します。 |
リスト9に、SGMBを無効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
RMOPTIONS SINGLETON
Tuxedoアプリケーションがアクティブでない場合は、TM_MIB
のT_DOMAIN
クラスを介して、このフラグを設定することもできます。詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTM_MIB(5)
に関する項を参照してください。
リスト10に、共通XIDを有効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
この機能は、UBBCONFIG
ファイルでオプションRMOPTIONS
のNO_COMMONXID
を指定して無効にできます。
RMOPTIONS {[...|NO_COMMONXID],*}
リスト11に、共通XIDを無効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
RMOPTIONS NO_COMMONXID
Tuxedoアプリケーションがアクティブでない場合は、TM_MIB
のT_DOMAIN
クラスを介して、このフラグを設定することもできます。詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTM_MIB(5)
に関する項を参照してください。
リスト12に、XAトランザクション・アフィニティを有効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
この機能は、UBBCONFIG
ファイルでオプションRMOPTIONS
のNO_XAAFFINITY
を指定して無効にできます。
RMOPTIONS {[...|NO_XAAFFINITY],*}
リスト13に、XAトランザクション・アフィニティを無効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
RMOPTIONS NO_XAAFFINITY
Tuxedoアプリケーションがアクティブでない場合は、TM_MIB
のT_DOMAIN
クラスを介して、このフラグを設定することもできます。詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTM_MIB(5)
に関する項を参照してください。
この機能は、FANテクノロジを使用して実装されます。このテクノロジを有効にするには、「FAN統合」を参照してください。
この機能は、FANテクノロジを使用して実装されます。このテクノロジを有効にするには、「FAN統合」を参照してください。
リスト14に、FAN統合を有効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
この機能は、UBBCONFIG
ファイルでオプションRMOPTIONS
のNO_FAN
を指定して無効にできます。
RMOPTIONS {[...|NO_FAN],*}
リスト15に、FAN統合を無効にするUBBCONFIG
ファイルの例を示します。
*RESOURCES
OPTIONS XPP
RMOPTIONS NO_FAN
Tuxedoアプリケーションがアクティブでない場合は、TM_MIB
のT_DOMAIN
クラスを介して、このフラグを設定することもできます。詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTM_MIB(5)
に関する項を参照してください。
FANイベントをモニターするために、SERVERS
セクションでTuxedoシステム・サーバーTMFAN
を指定します。詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTMFAN(5)
に関する項を参照してください。
Tuxedo XAサーバーのOracle TAF(透過アプリケーション・フェイルオーバー)をサポートするために、threads=t
がUBBCONFIG
の*GROUPS
セクションのOPENINFO
に含まれている必要があります。
適切なSPINCOUNT
は、サーバーがほとんどの時間でユーザー・レベル・メソッドを介してBBロックを保持できることを示しています。BBロックの競合が大きいシナリオで、パフォーマンスを著しく向上させることができます。通常のシナリオは、Tuxedo XAメカニズムを使用したトランザクション・アプリケーションです。したがって、CPUが十分でない場合を除き、Tuxedoアプリケーションのこの機能がOracle Exalogic上でデフォルトで有効になっていることがお薦めされます。
プロセスまたはスレッドは、ユーザー・レベル・メソッドまたはシステム・レベル・メソッドを介して掲示板をロックします。システム・レベル・メソッドはコストのかかる操作であるため、適切なロック・スピン数を設定して、ほとんどのロック試行をユーザー・レベル・メソッドを介して実行することが効果的です。
ユニプロセッサ・システム上のプロセスは、ロック・スピンができません。ユニプロセッサの場合、SPINCOUNT
の適切な値は1です。マルチプロセッサでは、SPINCOUNT
パラメータの値は、アプリケーションおよびシステムによって異なります。自動チューニング・ロック・メカニズムでは、適切なSPINCOUNT
を自動的に算出できます。
SHMQを使用することにより、不要なメッセージ・コピーを削減して、ネイティブTuxedoアプリケーションでより高いパフォーマンスを得ることができます。次のリストの1つ以上のケースが満たされる場合は、この機能を有効にすることを検討できます。
デフォルト値は、ほとんどすべてのシナリオで十分な値です。ただし、メッセージ・サイズが32KBを超える場合は、UBBCONFIG
のSHMQMAXMEM
の値を調整する必要があります。詳細は次のとおりです。
SHMQで使用される特定の共有メモリーがある場合、Tuxedoではそれを様々なサイズに設定されたバッファ用にいくつかの部分に分けます。一般的に、バッファ・サイズが大きくなればなるほど、この種のバッファの総エントリ数は少なくなります。一部のサイズ設定されたバッファが大きすぎる場合、SHMQの共有メモリー全体がフルでなくても、Tuxedoでローカル・メモリーを使用するために変換されます。
このリリースでは、2つの新しいMIBフィールド、TA_SHMQSTAT
およびTA_MSG_SHMQNUM
があり、共有メモリー使用量に関する詳細情報を取得するために使用されます。TA_SHMQSTAT
およびTA_MSG_SHMQNUM
の詳細は、ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスのTM_MIB(5)
に関する項を参照してください。
SHMQメッセージを使用するためのtpcall()
におけるTPNOCOPY
の新しいフラグです。ゼロコピー・メッセージングの一般的なTuxedoユーザー・ケース:
ゼロコピー・メッセージングは、送信者と受信者が同時に共有バッファにアクセスできないという前提条件のある、理想的な状況です。現実の世界では、安全なメモリー・アクセスを保証するために、送信者は1つのコピーを実行し、元のSHMMSG
のかわりにそのコピーを送信する必要があります。ただし、優れたパフォーマンスを得るために、新しいフラグTPNOCOPY
がコピー・コストを回避するためにtpcall()
に提供されます。アプリケーションでこのフラグの使用を選択した場合、tpcall()
の失敗後は、tpfree()
以外がSHMMSG
バッファにアクセスしていないことを確認する必要があります。
TPNOCOPY
がtpcall()
フラグに対して設定されていて、送信バッファがSHMMSGバッファである場合、メッセージの送信中に安全なコピーは行われません。tpcall()
の成功後は通常どおり、送信者アプリケーションが、送信バッファに対する完全なアクセス権を持ちます。ただし、tpcall()
がなんらかの状況で失敗した場合、送信者アプリケーションは送信バッファにアクセスできなくなります。この場合の推奨アクションは、バッファでtpfree()
を実行することです。これがバッファにおける唯一の安全な操作です。
TPNOCOPY
がtpacall()
に対して設定できないか、またはtperrno
がTPEINVAL
に設定されてtpacall()
が失敗します。
一般に、tuxedoネイティブ・リクエスト/応答メッセージは、機能が利用可能な場合は、共有メモリー・キュー(SHMQ)を使用して転送されます。ただし、次の場合には、かわりにIPCキューが使用されます。
一般に、Tuxedoはグローバル・トランザクションの唯一の参加グループの場合は1フェーズ・コミットを実行し、複数のグループの場合は2フェーズ・コミットを実行します。2フェーズ・コミットは、Tuxedoがグローバル・トランザクションの各ブランチに1つの準備リクエストを送信した後に、すべての準備リクエストが成功したら、各ブランチに1つのコミット・リクエストを送信することを示します。
読取り専用の最適化が使用可能な場合、Tuxedoは2フェーズ・コミットのかわりに、予約されたブランチ上で1フェーズ・コミットを呼び出して、1つの準備リクエストと密結合されたグローバル・トランザクション用のTLOG書込みを削減します。
tuxedoアプリケーションが、Oracle Databaseなどの、読取り専用最適化をサポートするデータベース上で実行されており、アプリケーションに複数のグループが関係する場合、この機能を利用できます。また、OPENINFO
のデフォルト・プロパティであるOracle Databaseに対してブランチが密結合される必要があります。
通常のシナリオは、参加グループが異なるRACインスタンスに接続されるか、異なるデータベース・サービスを使用するシナリオです。通常のUBBの構成は次のとおりです。
*RESROUCE
MODEL SHM
OPTIONS XPP
...
* MACHINES
"mach1" LMID=L1
...
*GROUPS
GRP1 LMID=L1 GRPNO=10 TMSNAME="TMSORA1"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux1+ACC= P/scott/tiger +SesTM=120"
GRP2 LMID=L1 GRPNO=20 TMSNAME="TMSORA2"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux2+ACC= P/scott/tiger +SesTM=120"
*SERVERS
server1 SRVGRP=GRP1 SRVID=10 MIN=2
server2 SRVGRP=GRP2 SRVID=10 MIN=2
...
GRP1
はネット・サービスorcl.tux1
を使用してリソース・マネージャに接続します。orcl.tux1
は、RAC instance1でサポートされているデータベース・サービスtux1に構成されます。GRP2
はネット・サービスorcl.tux2
を使用してリソース・マネージャに接続します。orcl.tux2
は、RAC instance2でサポートされているデータベース・サービスtux2
に構成されます。server1
は、Tuxedoサービスsvc1
を提供します。server2
は、Tuxedoサービスsvc2
を提供します。トランザクション・ビジネスAはsvc1
およびsvc2
に依存するため、このビジネスにはserver1
とserver2
が含まれます。
読取り専用最適化が有効になっていることにより、1つの準備リクエストが省略され、TLOG書込みが無視されます。1フェーズ・コミットが実行されます。
参加グループが同一のデータベース・サービスを介して同一のOracleインスタンスに接続される場合、グローバル・トランザクションを1フェーズ・コミットに導く共通XID機能を有効にすることをお薦めします。共通XID機能は、すべての準備リクエストおよびTLOG書込みを無視できるため、読取り専用最適化よりもパフォーマンスが向上します。
トランザクション・ビジネスで読取り専用最適化を呼び出さないことが明確な場合は、パフォーマンス上に負の影響が生じないように、読取り専用最適化を有効にしないでください。通常のシナリオは、複数のリソース・マネージャがビジネスで使用されるというシナリオです。
TuxedoアプリケーションがOracle RAC上で実行されている場合、ロード・バランス、サービス・フェイルオーバーなどの非シングルトン・データベース・サービスを利用することが望ましい場合があります。Tuxedoグループは、この機能を有効にすることにより、RAC非シングルトン・サービスを使用できます。ビジネスには複数のグループが含まれる場合があるため、良好なパフォーマンスが得られるように、共通XIDとXAトランザクション・アフィニティも有効にすることをお薦めします。
*RESROUCES
MODEL SHM
OPTIONS XPP
...
*MACHINES
"mach1" LMID=L1
...
*GROUPS
GRP1 LMID=L1 GRPNO=10 TMSNAME="TMSORA1"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux3+ACC= P/scott/tiger +SesTM=120"
GRP2 LMID=L1 GRPNO=20 TMSNAME="TMSORA2"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux3+ACC= P/scott/tiger +SesTM=120"
*SERVERS
server1 SRVGRP=GRP1 SRVID=10 MIN=4
server2 SRVGRP=GRP2 SRVID=10 MIN=4
...
GRP1
とGRP2
は同一のネット・サービスorcl.tux3
を使用して、リソース・マネージャに接続します。orcl.tux3
はデータベース・サービスtux3
に対して構成されており、RAC instance1とinstance2の両方でサポートされます。Server1
は、Tuxedoサービスsvc1
を提供し、server2
はTuxedoサービスsvc2
を提供します。トランザクション・ビジネスAはsvc1
を、次にsvc2
をコールします。これにより、server1
とserver2
が含められます。orcl.tux3
は非シングルトン・データベース・サービスであるため、server1
のコピーがinstance1またはinstance2のいずれかと関連付けられ、server2
のコピーでも同様の処理が行われます。
SGMBでは、ビジネスが良好に機能し、ビジネスAのトランザクションがinstance1およびinstanc2で均等に分散されていることを確認できます。
共通XIDおよびXAトランザクション・アフィニティが両方とも有効になっている場合、ビジネスAのすべてのトランザクションは、1フェーズ・コミットとなります。
共通XIDは、コーディネータのインスタンス情報とブランチ(共通XID)をすべての参加グループと共有します。参加グループのサーバーは、コーディネータと同じインスタンス情報を持つ場合には共通XIDを再使用します。この機能は、グローバル・トランザクションが複数のグループを含み、特にすべての参加グループが同一データベース・サービスを介して同一データベース・インスタンスを関連付ける場合には、パフォーマンスにおける著しい向上をもたらします。
Tuxedoアプリケーションでは、1つのOracle Databaseインスタンスのみが使用されます。標準のUBB構成は次のとおりです。
*RESROUCES
MODEL SHM
OPTIONS XPP
...
*MACHINES
"mach1" LMID=L1
...
*GROUPS
GRP1 LMID=L1 GRPNO=10 TMSNAME="TMSORA1"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux1+ACC= P/scott/tiger +SesTM=120"
GRP2 LMID=L1 GRPNO=20 TMSNAME="TMSORA2"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux1+ACC= P/scott/tiger +SesTM=120"
*SERVERS
server1 SRVGRP=GRP1 SRVID=10 MIN=2
server2 SRVGRP=GRP2 SRVID=10 MIN=2
...
前述の構成では、GRP1
およびGRP2
が同一のネット・サービス(orcl.tux1
、Oracle Databaseに対して構成)を使用してリソース・マネージャに接続します。Server1
は、Tuxedoサービスsvc1
を提供し、server2
はTuxedoサービスsvc2
を提供します。トランザクション・ビジネスAはsvc1
を、次にsvc2
をコールします。これにより、server1
とserver2
が含められます。共通XIDが有効になると、ビジネスAのすべてのトランザクションは1フェーズ・コミットになります。
TuxedoアプリケーションがOracle RAC上で実行されている場合は、すべての参加グループが同一データベース・サービスを介して同一データベース・インスタンスを関連付けます。
標準のUBBサンプルはリスト18と同じですが、ネット・サービスorcl.tux1
は、データベース・サービスtux1
を介してOracle RAC instance1に対して構成されます。共通XIDが有効になると、ビジネスAのすべてのトランザクションは1フェーズ・コミットになります。
冗長サーバーまたはグループは、異なるOracle RACインスタンス上で実行されている場合に構成されます。このシナリオの場合、XAトランザクション・アフィニティ機能も有効である必要があります。ビジネスで同一データベースを介して同一のデータベース・インスタンスをコーディネータと関連付けるサービス/グループを含むことができます。
*RESROUCES
MODEL SHM
OPTIONS XPP
...
*MACHINES
"mach1" LMID=L1
...
*GROUPS
GRP1 LMID=L1 GRPNO=10 TMSNAME="TMSORA1"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux1+ACC= P/scott/tiger +SesTM=120"
GRP2 LMID=L1 GRPNO=20 TMSNAME="TMSORA2"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux1+ACC= P/scott/tiger +SesTM=120"
GRP3 LMID=L1 GRPNO=30 TMSNAME="TMSORA3"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux2+ACC= P/scott/tiger +SesTM=120"
*SERVERS
server1 SRVGRP=GRP1 SRVID=10 MIN=2
server2 SRVGRP=GRP2 SRVID=10 MIN=2
server3 SRVGRP=GRP3 SRVID=10 MIN=2
...
GRP1
とGRP2
は同一のネット・サービスorcl.tux1
を使用して、リソース・マネージャに接続します。orcl.tux1
はデータベース・サービスtux1
に対して構成されており、RAC instance1でサポートされます。GRP3
はネット・サービスorcl.tux2
を使用して、リソース・マネージャに接続します。orcl.tux2
はデータベース・サービスtux2
に対して構成されており、RAC instance2でサポートされます。server1
は、Tuxedoサービスsvc1
を提供し、server2
およびserver3
はTuxedoサービスsvc2
を提供します。トランザクション・ビジネスAはsvc1
をコールし、その後 svc2
をコールします。
一般に、ビジネスAはTuxedoのロード・バランスのため、server1
およびserver2
またはserver1
およびserver3
を含む場合があります。共通XIDが有効な場合は、server1
およびserver2
を含むトランザクションは1フェーズ・コミットになります。XAトランザクション・アフィニティが有効になっている場合、ビジネスAは常にserver1
およびserver2
を含むため、ビジネスAのすべてのトランザクションは、1フェーズ・コミットとなります。
参加グループの一部は、同一データベース・サービスを介した同一インスタンスをコーディネータと関連付けます。このシナリオでは、共通XIDおよび読取り専用最適化機能の両方を有効にすることをお薦めします。
*RESROUCES
MODEL SHM
OPTIONS XPP
...
*MACHINES
"mach1" LMID=L1
...
*GROUPS
GRP1 LMID=L1 GRPNO=10 TMSNAME="TMSORA1"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux1+ACC= P/scott/tiger +SesTM=120"
GRP2 LMID=L1 GRPNO=20 TMSNAME="TMSORA2"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux1+ACC= P/scott/tiger +SesTM=120"
GRP3 LMID=L1 GRPNO=30 TMSNAME="TMSORA3"
OPENINFO="Oracle_XA:ORACLE_XA+SqlNet=orcl.tux2+ACC= P/scott/tiger +SesTM=120"
*SERVERS
server1 SRVGRP=GRP1 SRVID=10 MIN=2
server2 SRVGRP=GRP2 SRVID=10 MIN=2
server3 SRVGRP=GRP3 SRVID=10 MIN=2
...
GRP1
とGRP2
は同一のネット・サービスorcl.tux1
を使用して、リソース・マネージャに接続します。orcl.tux1
はデータベース・サービスtux1
に対して構成されており、RAC instance1でサポートされます。GRP3
はネット・サービスorcl.tux2
を使用して、リソース・マネージャに接続します。orcl.tux2
はデータベース・サービスtux2
に対して構成されており、RAC instance2でサポートされます。server1
は、Tuxedoサービスsvc1
を、server2
はTuxedoサービスsvc2
を、server3
はTuxedoサービスsvc3
を提供します。トランザクション・ビジネスBはsvc1
をコールし、次にsvc2
、最後にsvc3
をコールします。
ビジネスBはserver1/GRP1
、server2/GRP2
およびserver3/GRP3
を含みます。共通XIDが有効な場合は、GRP2
に対する準備リクエストが省略されます。読取り専用最適化も有効である場合は、GRP1
に対する準備リクエストも省略され、GRP1
で1フェーズ・コミットが実行され、TLOG書込みが回避されます。
Tuxedoサーバーが同一のOracle Databaseサービスを介して異なるOracle RACインスタンス上で実行される複数のインスタンスを持つ場合に、この機能を有効にすることをお薦めします。
XAトランザクション・アフィニティが有効であるかぎり、環境変数TUXRACGROUPS
で指定されるOracle RACルーティングのルールを使用する必要はなく、このルールは無効になります。
次の図は、XAトランザクション・アフィニティが有効な場合に行われる変更事項を示しています。
Oracle FAN (高速アプリケーション通知)から利点を享受するには、TuxedoがOracle RACとともに使用される場合は常にこの機能を有効にすることをお薦めします。
UBBCONFIG
のほかに、次の構成の場合には、Oracleデータベースを適切に設定してください。
この機能は、FANイベントにアクセスするためにONS (Oracle Notification System)に依存します。TuxedoがネイティブONSクライアントである場合、ONSデーモンは、Oracle Databaseのサーバー側とクライアント側で有効である必要があります。Tuxedoをリモート・モードで機能させることをお薦めします。
ONSデーモン構成ファイルは、$ORACLE_HOME/opmn/conf/ons.config
にあります。このファイルは、ONSデーモンにその動作方法を示します。ons.config
内の構成情報は、単純な名前と値のペアで定義されます。
ONSの構成後、onsctl
コマンドで開始できます。ONSデーモンが常に実行されていることを確認してください。
注意: | Oracle Databaseクライアント側で、Oracleバージョンが12.1.0.1.0より下のバージョンの場合、ONSデーモンが有効になっている必要があります。 |
Oracle Tuxedo非XAサーバーでOracle RAC高速アプリケーション通知(FAN)を利用する場合、TAFをお薦めします。
TAF(透過的アプリケーション・フェイルオーバー)は、データベース・インスタンスに障害が発生した場合に、クライアントが、存続するデータベース・インスタンスに自動的に再接続可能なOracle Databaseのクライアント側の機能です。
特定のXA以外のアプリケーション・サーバーに関連付けられたインスタンスに対してFANイベントをモニターするには、$TUXDIR/lib/tuxociucb.so.1.0
が$ORACLE_HOME/lib
でデプロイされ、このバイナリの名前がORA_OCI_UCBPKG
環境変数で指定されている必要があります。
servopts
の-L
オプションは、サーバーが Oracle Databaseに接続されることを示すために、XA以外のサーバーに対して使用される必要があります。-L
を指定するとECIDが有効になるため、ECIDをクローズする新しいオプション-F
がservopts
に導入されています。使用法は-F noECID
です。次に例を示します。
*SERVERS
server1
SRVGRP=GRP1 SRVID=1 ClOPT="-L libclntsh.so -F noECID"
Oracle FAN (高速アプリケーション通知)から利点を享受するには、TuxedoがOracle RACとともに使用される場合は常にこの機能を有効にすることをお薦めします。
UBBCONFIG
およびOracle Databaseを「データベース・インスタンス間のフェイルオーバー/フェイルバック」と同様に構成し、LBA (Load Balance Advisory)を次のように設定します。
推奨事項については、「非XAサーバーに関する推奨事項」を参照してください。
Oracle Tuxedo Advanced Performance Packの機能を使用するには、次のソフトウェア要件を満たす必要があります。