パフォーマンスを最適化するためのベスト・プラクティス

3.1 自動チューニング・ロック・メカニズム

3.1.1 推奨されるシナリオ

適切なSPINCOUNTは、サーバーがほとんどの時間でユーザー・レベル・メソッドを介してBBロックを保持できることを示しています。BBロックの競合が大きいシナリオで、パフォーマンスを著しく向上させることができます。通常のシナリオは、Tuxedo XAメカニズムを使用したトランザクション・アプリケーションです。したがって、CPUが十分でない場合を除き、Tuxedoアプリケーションのこの機能がOracle Exalogic上でデフォルトで有効になっていることがお薦めされます。

親トピック: 自動チューニング・ロック・メカニズム

3.1.2 ロック・スピンの回数を設定する

プロセスまたはスレッドは、ユーザー・レベル・メソッドまたはシステム・レベル・メソッドを介して掲示板をロックします。システム・レベル・メソッドはコストのかかる操作であるため、適切なロック・スピン数を設定して、ほとんどのロック試行をユーザー・レベル・メソッドを介して実行することが効果的です。

ユニプロセッサ・システム上のプロセスは、ロック・スピンができません。ユニプロセッサの場合、SPINCOUNTの適切な値は1です。マルチプロセッサでは、SPINCOUNTパラメータの値は、アプリケーションおよびシステムによって異なります。自動チューニング・ロック・メカニズムでは、適切なSPINCOUNTを自動的に算出できます。

関連項目:

Oracle Tuxedo Advanced Performance Packの構成

親トピック: 自動チューニング・ロック・メカニズム

3.2 共有メモリー・プロセス間通信

親トピック: パフォーマンスを最適化するためのベスト・プラクティス

3.2.1 推奨されるシナリオ

SHMQを使用することにより、不要なメッセージ・コピーを削減して、ネイティブTuxedoアプリケーションでより高いパフォーマンスを得ることができます。次のリストの1つ以上のケースが満たされる場合は、この機能を有効にすることを検討できます。

大きいリクエスト/返信メッセージ
単純/小さなサービス
サービス・ルーチン自体が多くの時間を消費しすぎない場合に、メッセージ・コピーを削減することによって、この機能でパフォーマンスを向上させます。
IPCリソース
この機能が有効な場合、共有メモリーが多くなるばかりでなく、余分なセマフォも必要になります。この機能を使用する前に、tmloacf -cを介して最小IPCリソースを確認することをお薦めします。

親トピック: 共有メモリー・プロセス間通信

3.2.2 SHMQMAXMEMの調整

デフォルト値は、ほとんどすべてのシナリオで十分な値です。ただし、メッセージ・サイズが32KBを超える場合は、UBBCONFIGのSHMQMAXMEMの値を調整する必要があります。詳細は次のとおりです:

SHMQMAXMEM = (Recommend_value * Message_size) / 32

Recommend_value: tmloadcf -cによって返される値
Message_size: 1つのメッセージのバッファ・サイズ(KB)

親トピック: 共有メモリー・プロセス間通信

3.2.3 メモリー使用量

SHMQで使用される特定の共有メモリーがある場合、Tuxedoではそれを様々なサイズに設定されたバッファ用にいくつかの部分に分けます。一般的に、バッファ・サイズが大きくなればなるほど、この種のバッファの総エントリ数は少なくなります。一部のサイズ設定されたバッファが大きすぎる場合、SHMQの共有メモリー全体がフルでなくても、Tuxedoでローカル・メモリーを使用するために変換されます。

このリリースでは、2つの新しいMIBフィールド、TA_SHMQSTATおよびTA_MSG_SHMQNUMがあり、共有メモリー使用量に関する詳細情報を取得するために使用されます。TA_SHMQSTATおよびTA_MSG_SHMQNUMの詳細は、「セクション5 - ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス」のTM_MIB(5)に関する項を参照してください。

親トピック: 共有メモリー・プロセス間通信

3.2.4 SHMQによるプログラミング

SHMQメッセージを使用するためのtpcall()におけるTPNOCOPYの新しいフラグです。ゼロコピー・メッセージングの一般的なTuxedoユーザー・ケース:

クライアントは、tpalloc()でリクエストSHMMSGバッファを取得する
クライアントは、サーバーのリクエストSHMQに呼応してtpcall()でリクエストを送信し、応答を待機する
サーバーはリクエストをそのリクエストSHMQから受信し、リクエストを処理する
サーバーは、応答に同じSHMMSGバッファを使用する
サーバーは、クライアントの応答SHMQにtpreturn()で応答を送信する
クライアントはその応答SHMQから応答を受信する

ゼロコピー・メッセージングは、送信者と受信者が同時に共有バッファにアクセスできないという前提条件のある、理想的な状況です。現実の世界では、安全なメモリー・アクセスを保証するために、送信者は1つのコピーを実行し、元のSHMMSGのかわりにそのコピーを送信する必要があります。ただし、優れたパフォーマンスを得るために、新しいフラグTPNOCOPYがコピー・コストを回避するためにtpcall()に提供されます。アプリケーションでこのフラグの使用を選択した場合、tpcall()の失敗後は、tpfree()以外がSHMMSGバッファにアクセスしていないことを確認する必要があります。

TPNOCOPYがtpcall()フラグに対して設定されていて、送信バッファがSHMMSGバッファである場合、メッセージの送信中に安全なコピーは行われません。tpcall()の成功後は通常どおり、送信者アプリケーションが、送信バッファに対する完全なアクセス権を持ちます。ただし、tpcall()がなんらかの状況で失敗した場合、送信者アプリケーションは送信バッファにアクセスできなくなります。この場合の推奨アクションは、バッファでtpfree()を実行することです。これがバッファにおける唯一の安全な操作です。

TPNOCOPYをtpacall()に対して設定できないか、またはtperrnoをTPEINVALに設定するとtpacall()が失敗します。

親トピック: 共有メモリー・プロセス間通信

3.2.5 例外

一般に、tuxedoネイティブ・リクエスト/応答メッセージは、機能が利用可能な場合は、共有メモリー・キュー(SHMQ)を使用して転送されます。ただし、次の場合には、かわりにIPCキューが使用されます。

Tuxedoエンコード・メッセージ
CORBAステートフル・オブジェクト
デジタル署名および暗号化に関連付けられたTuxedoメッセージ
たとえば、tpseal()またはtpsign()では、暗号化またはデジタル署名用にTuxedoメッセージをマーク付けします。
BUFTYPECONVで指定されたサーバーからのTuxedoメッセージ
フィールド型ポインタ付きTuxedo FML32型メッセージ
フィールド型埋込みFML32付きTuxedo FML32型メッセージ

関連項目:

Oracle Tuxedo Advanced Performance Packの構成

親トピック: 共有メモリー・プロセス間通信

3.3 RACの部分的1フェーズ読取り専用最適化

一般に、Tuxedoは、1つのTuxedoグループのみがグローバル・トランザクションに参加している場合にのみ、1フェーズ・コミットを実行します。複数のグループが関係している場合、Tuxedoは2フェーズ・コミットを実行します。2フェーズ・コミットは、Tuxedoがグローバル・トランザクションの各ブランチに1つの準備リクエストを送信した後に、すべての準備リクエストが成功したら、読取り専用ではないすべてのブランチに1つのコミット・リクエストを送信することを示します。RACを使用する場合、トランザクションに複数のRACインスタンスが関係していると、最後の準備リクエストを除くすべての準備リクエストは読取り専用で返されます。Tuxedoでは、この知識を使用して、他のすべてのRACブランチが準備されるまで1つのブランチの準備を待機することによって、トランザクションのパフォーマンスを向上させます。他のすべてのブランチが読取り専用を返した場合、Tuxedoは残りのブランチに1フェーズ・コミットを送信します。これにより、準備コールが省略され、TLOGエントリを記述する必要がなくなります。これにより、トランザクションのレスポンス時間が若干長くなる可能性がありますが、負荷が軽減され、スループットが向上することがあります。

関連項目:

詳細は、「RACの部分的1フェーズ読取り専用最適化」を参照してください。

TuxedoアプリケーションでRACデータベースを使用している場合、アプリケーションに複数のグループが関係していると、この機能を利用できます。また、OPENINFOのデフォルト・プロパティであるOracle Databaseに対してブランチが密結合される必要があります。

通常のシナリオは、参加グループが異なるRACインスタンスに接続されるか、異なるデータベース・サービスを使用するシナリオです。通常のUBBの構成は次のとおりです。

リスト: 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
...

Tuxedo GRP1とGRP2では、異なるネット・サービスを使用して同じOracle RACデータベースに接続し、各ネット・サービスでは、個別のRACインスタンスによって提供される異なるデータベース・サービスを使用します。Tuxedo server1およびserver2は、異なるTuxedoサービスを提供します。トランザクション・ビジネスには、svc 1およびsvc2からのサービスが必要です。したがって、server1およびserver2が関係します。

読取り専用最適化を有効にすると、TLOG書込みを無視することで、リクエストが省略されます。1フェーズ・コミットを実行して、残りのブランチを効率的にコミットします。

参加しているグループが同じOracle RACインスタンスおよびRACデータベースに接続されている場合は、共通XID機能を有効にすることをお薦めします。この機能により、グローバル・トランザクションが単一フェーズで確実にコミットされます。共通XID機能は、準備リクエストおよびTLOG書込みを無視することで、読取り専用最適化よりもパフォーマンスを向上させます。

トランザクション・ビジネスで読取り専用最適化を使用しない場合は、レスポンス時間に悪影響を及ぼさないように、この最適化を有効にしないでください。通常のシナリオでは、複数のリソース・マネージャを同時に使用することが一般的です。

関連項目:

Oracle Tuxedo Advanced Performance Packの構成

親トピック: パフォーマンスを最適化するためのベスト・プラクティス

3.4 単一グループの複数ブランチ(SGMB)

親トピック: パフォーマンスを最適化するためのベスト・プラクティス

3.4.1 推奨されるシナリオ

TuxedoアプリケーションがOracle RAC上で実行されている場合、ロード・バランス、サービス・フェイルオーバーなどの非シングルトン・データベース・サービスを利用することが望ましい場合があります。Tuxedoグループは、この機能を有効にすることにより、RAC非シングルトン・サービスを使用できます。ビジネスには複数のグループが含まれる場合があるため、良好なパフォーマンスが得られるように、共通XIDとXAトランザクション・アフィニティも有効にすることをお薦めします。

標準のUBB構成は次のとおりです。

リスト: 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.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フェーズ・コミットとなります。

親トピック: 単一グループの複数ブランチ(SGMB)

3.4.2 制限事項

複数のリソース・マネージャを使用するグループはサポートされません。
1つのグループに16を超えるインスタンスが含まれる場合、トランザクションは失敗します。
優先予約グループがマルチブランチ・グループの場合、RACの部分的1フェーズ読取り専用最適化はトランザクションで機能しません。GWTDOMAINがコーディネータでない場合は、優先予約グループがコーディネータ・グループです。それ以外の場合、優先予約グループは、コーディネータ・ドメイン内で次に登場する参加グループです。
マルチスレッド・サーバーは、MIBを介してインスタンス情報を提供しません。しかし、SGMBは、サーバーによってディスパッチされたスレッドではそのまま適切に機能します。

関連項目:

Oracle Tuxedo Advanced Performance Packの構成

親トピック: 単一グループの複数ブランチ(SGMB)

3.5 共通XID

共通XIDは、コーディネータのインスタンス情報とブランチ(共通XID)をすべての参加グループと共有します。参加グループのサーバーは、コーディネータと同じインスタンス情報を持つ場合には共通XIDを再使用します。この機能は、グローバル・トランザクションが複数のグループを含み、特にすべての参加グループが同一データベース・サービスを介して同一データベース・インスタンスを関連付ける場合には、パフォーマンスにおける著しい向上をもたらします。

親トピック: パフォーマンスを最適化するためのベスト・プラクティス

3.5.1 推奨されるシナリオ

親トピック: 共通XID

3.5.1.1 シナリオA

Tuxedoアプリケーションでは、1つのOracle Databaseインスタンスのみが使用されます。標準のUBB構成は次のとおりです。

リスト18 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フェーズ・コミットになります。

親トピック: 推奨されるシナリオ

3.5.1.2 シナリオB

TuxedoアプリケーションがOracle RAC上で実行されている場合は、すべての参加グループが同一データベース・サービスを介して同一データベース・インスタンスを関連付けます。

標準のUBBサンプルは、「リスト: UBBの構成」と同じですが(シナリオAに示されているこのリストを参照)、ネット・サービスorcl.tux1は、データベース・サービスtux1を介してOracle RAC instance1に対して構成されます。共通XIDが有効になると、ビジネスAのすべてのトランザクションは1フェーズ・コミットになります。

親トピック: 推奨されるシナリオ

3.5.1.3 シナリオC

冗長サーバーまたはグループは、異なるOracle RACインスタンス上で実行されている場合に構成されます。このシナリオの場合、XAトランザクション・アフィニティ機能も有効である必要があります。ビジネスで同一データベースを介して同一のデータベース・インスタンスをコーディネータと関連付けるサービス/グループを含むことができます。

リスト19 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"
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フェーズ・コミットとなります。

親トピック: 推奨されるシナリオ

3.5.1.4 シナリオD

参加グループの一部は、同一データベース・サービスを介した同一インスタンスをコーディネータと関連付けます。このシナリオでは、共通XIDおよび読取り専用最適化機能の両方を有効にすることをお薦めします。

標準のUBB構成は次のとおりです。

リスト20 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"
 
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書込みが回避されます。

親トピック: 推奨されるシナリオ

3.5.2 制限事項

複数のリソース・マネージャを使用するグループはサポートされません。
マルチスレッド・サーバーは、MIBを介してインスタンス情報を提供しません。しかし、共通XIDは、サーバーによってディスパッチされたスレッドではそのまま適切に機能します。
2フェーズ・コミットのシナリオでは、GWTDOMAINが準備やコミットの実行に常に関与しています

関連項目:

構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
Oracle Databaseを使用したこの機能の設定方法の詳細は、『Oracle Tuxedo Oracle Tuxedoアプリケーションの設定』のTuxedoをOracle Real Application Clusters (RAC)とともに使用する方法に関する項を参照してください。

親トピック: 共通XID

3.6 XAトランザクション・アフィニティ

親トピック: パフォーマンスを最適化するためのベスト・プラクティス

3.6.1 推奨されるシナリオ

Tuxedoサーバーが同一のOracle Databaseサービスを介して異なるOracle RACインスタンス上で実行される複数のインスタンスを持つ場合に、この機能を有効にすることをお薦めします。

XAトランザクション・アフィニティが有効になっている場合、環境変数TUXRACGROUPSで指定されたOracle RACルーティングのルールを使用する必要はなく、このルールは無効になります。

次の図は、XAトランザクション・アフィニティが有効な場合に行われる変更事項を示しています。

図3-1 XAトランザクション・アフィニティの有効化

親トピック: XAトランザクション・アフィニティ

3.6.2 制限事項

複数のリソース・マネージャを使用するグループはサポートされません。
1つのトランザクション内でのアフィニティ・コンテキスト(データベース名+インスタンス名+サービス名)の最大数は16です。
XAトランザクション・アフィニティでは、複数サーバー単一キュー、マルチスレッド・サーバー、ドメイン間サービスはサポートされません。

関連項目:

Oracle Tuxedo Advanced Performance Packの構成

親トピック: XAトランザクション・アフィニティ

3.7 データベース・インスタンス間のフェイルオーバー/フェイルバック

親トピック: パフォーマンスを最適化するためのベスト・プラクティス

3.7.1 Oracleデータベースでの構成の推奨

Oracle FAN (高速アプリケーション通知)から利点を享受するには、TuxedoがOracle RACとともに使用される場合は常にこの機能を有効にすることをお薦めします。

UBBCONFIGのほかに、次の構成の場合には、Oracleデータベースを適切に設定してください。

ONS (Oracle Notification System)
この機能は、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デーモンが有効になっている必要があります。
TAF (透過的アプリケーション・フェイルオーバー)
Oracle Tuxedo非XAサーバーでOracle RAC高速アプリケーション通知(FAN)を利用する場合、TAFをお薦めします。

TAF(透過的アプリケーション・フェイルオーバー)は、データベース・インスタンスに障害が発生した場合に、クライアントが、存続するデータベース・インスタンスに自動的に再接続可能なOracle Databaseのクライアント側の機能です。
- TAFが構成されている場合、OracleクライアントがOracle TuxedoからOracle Databaseサーバーへの新規接続の再確立を行います。
- TAFが構成されていない場合、Oracle Tuxedo非XAサーバーは再確立を行わないため、この機能は無効です。

親トピック: データベース・インスタンス間のフェイルオーバー/フェイルバック

3.7.2 非XAサーバーに関する推奨事項

特定のXA以外のアプリケーション・サーバーに関連付けられたインスタンスに対してFANイベントをモニターするには、$TUXDIR/lib/tuxociucb.so.1.0が$ORACLE_HOME/libでデプロイされ、このバイナリの名前がORA_OCI_UCBPKG環境変数で指定されている必要があります。

TAFをサポートするには、次のルールに従ってください。

OCIアプリケーションの場合は、OCI_THREADEDモードでOCI環境を作成します。
Pro*Cアプリケーションの場合、threads=yesを使用して事前コンパイルを実行して、最初に実行可能な埋込みSQL文を作成する前にEXEC SQL ENABLE THREADSを使用してください。

servoptsの-Lオプションは、サーバーが Oracle Databaseに接続されることを示すために、XA以外のサーバーに対して使用される必要があります。-Lを指定するとECIDが有効になるため、ECIDをクローズする新しいオプション-Fがservoptsに導入されています。使用法は-F noECIDです。次に例を示します。

リスト: -Lオプションの例

*SERVERS
server1
SRVGRP=GRP1 SRVID=1 ClOPT="-L libclntsh.so -F noECID"

親トピック: データベース・インスタンス間のフェイルオーバー/フェイルバック

3.7.3 制限事項

複数のリソース・マネージャを使用するグループはサポートされません。
カスタマイズされたサーバーがOCIを使用してOracle Databaseに接続する場合、OCI_NO_UCBはOCI初期化時に設定できません。

関連項目:

構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
Oracle Databaseを使用したこの機能の設定方法の詳細は、『Oracle Tuxedo Oracle Tuxedoアプリケーションの設定』のTuxedoをOracle Real Application Clusters (RAC)とともに使用する方法に関する項を参照してください。

親トピック: データベース・インスタンス間のフェイルオーバー/フェイルバック

3.8 RACインスタンス間のロード・バランシング

親トピック: パフォーマンスを最適化するためのベスト・プラクティス

3.8.1 Oracleデータベースでの構成の推奨

Oracle FAN (高速アプリケーション通知)から利点を享受するには、TuxedoがOracle RACとともに使用される場合は常にこの機能を有効にすることをお薦めします。

UBBCONFIGおよびOracle Databaseを「データベース・インスタンス間のフェイルオーバー/フェイルバック」と同様に構成し、LBA (Load Balance Advisory)を次のように設定します。

LBA (ロード・バランシング・アドバイザ)
Oracle Databaseロード・バランシング・アドバイザに基づいて、Tuxedoは同一Oracle Databaseサービスに接続されるTuxedoアプリケーション・サーバー間でサービス・リクエストを分散できます。LBAおよびFANロード・バランシング・イベントのパブリッシュを有効にするには、実行時接続ロード・バランシングのサービスレベルの目標がOracle Databaseサービス定義で指定されている必要があります。サービスの作成時または変更時に、-Bオプションを使用して(srvctlを介して)目標を指定できます。

親トピック: RACインスタンス間のロード・バランシング

3.8.2 非XAサーバーに関する推奨事項

推奨事項については、「非XAサーバーに関する推奨事項」を参照してください。

親トピック: RACインスタンス間のロード・バランシング

3.8.3 制限事項

複数のリソース・マネージャを使用するグループはサポートされません。
カスタマイズされたサーバーがOCIを使用してOracle Databaseに接続する場合、OCI_NO_UCBはOCI初期化時に設定できません。
Oracle RAC LBAに基づいたロード・バランスでは、複数サーバー単一キュー、マルチスレッド・サーバー、ドメイン間サービスはサポートされません。

関連項目:

構成の詳細は、「Oracle Tuxedo Advanced Performance Packの構成」を参照してください。
Oracle Databaseでこの機能を設定する方法の詳細は、『Oracle® Database高可用性概要およびベスト・プラクティス』のレベル1: 基本的なアプリケーション高可用性の構成に関する項を参照してください。

親トピック: RACインスタンス間のロード・バランシング