日本語PDF

B パフォーマンス・チューニング

この付録では、アプリケーションのパフォーマンス(性能)が向上する簡単な適用方法をいくつか紹介します。これらの方法を使用すると、多くの場合、処理時間を25%以上短縮できます。この付録の内容は次のとおりです。

• パフォーマンスを低下させる原因

• パフォーマンスの改善方法

• ホスト配列の使用について

• 埋込みPL/SQLの使用について

• SQL文の最適化について

• 文キャッシュについて

• 索引の使用について

• 行レベル・ロックの利用について

• 不要な解析の排除について

• 接続プーリングの使用方法について

• Traffic DirectorモードのOracle Connection Managerの使用について

B.1 パフォーマンスを低下させる原因

パフォーマンスを低下させる原因の1つは通信オーバーヘッドが高いことです。サーバーでは、SQL文を一度に1つずつ処理する必要があります。つまり、文ごとに個別のコールが発生し、単一のオーバーヘッドが増加します。ネットワーク化された環境下では、ネットワークを介してSQL文を送信する必要があるため、ネットワークの通信量が増加することになります。ネットワークの通信量が多いと、アプリケーションの処理速度は著しく低下します。

パフォーマンスを低下させるもう1つの原因は、非効率的なSQL文です。SQLは非常に柔軟性があるため、2つの異なる文で同じ結果を得ることができますが、一方の文の効率が悪い場合があります。たとえば、次の2つのSELECT文は同じ行(少なくとも従業員が1人いる部門ごとの名称および番号)を戻します。

EXEC SQL SELECT dname, deptno 
    FROM dept 
    WHERE deptno IN (SELECT deptno FROM emp); 
 
EXEC SQL SELECT dname, deptno 
    FROM dept 
    WHERE EXISTS 
    (SELECT deptno FROM emp WHERE dept.deptno = emp.deptno); 

ただし、この最初の文はDEPT表内のすべての部門番号を探してEMP表全体をスキャンするため、処理に時間がかかります。EMP表内のDEPTNO列に索引を付けていても、この副問合せにはDEPTNOを指定するWHERE句がないので、索引は使用されません。

パフォーマンス低下の3つ目の原因は、不要な解析およびバインドです。SQL文を実行する前に、サーバーでこのSQL文を解析してバインドする必要があることに注意してください。解析とは、SQL文を調べて、これが構文規則に従って正しいデータベース・オブジェクトを参照していることを確認する作業です。バインドとは、SQL文内のホスト変数をそれぞれのアドレスに対応付け、サーバーがその値に対して読込みまたは書込みができるようにする処理です。

大部分のアプリケーションにおいて、カーソルの管理を十分に行っているとはいえません。このため不要な解析またはバインドが発生し、結果的に処理のオーバーヘッドが著しく増加します。

B.2 パフォーマンスの改善方法

プリコンパイルしたプログラムのパフォーマンスがよくない場合でも、オーバーヘッドを減少させる方法はあります。

特にネットワーク化された環境下では、次の処理によって通信オーバーヘッドを大幅に削減できます。

• ホスト変数の使用

• 埋込みPL/SQLの使用

次の方法で、処理のオーバーヘッドを場合によっては大幅に削減できます。

• SQL文の最適化

• 索引の使用

• 行レベル・ロックの利用

• 不要な解析の排除

• 不要な再解析の回避

次の項目では、オーバーヘッドを削減するための方法を検討します。

B.3 ホスト配列の使用について

ホスト配列を使用すると、1つのSQL文でデータの集まり全体を操作できるため、パフォーマンスが向上します。たとえば、300人の従業員の給料をEMP表にINSERTする場合を考えてみます。配列がないと、プログラムは300の個々のINSERT(各従業員に1つ)を実行する必要があります。配列を使用すると、必要なINSERTは1回のみになります。次の文を考えてみます。

EXEC SQL INSERT INTO emp (sal) VALUES (:salary); 

salaryが単純なホスト変数の場合は、サーバーでこのINSERT文を1回実行すると、EMP表には1行のみが挿入されます。この行のSAL列にはsalaryの値が格納されます。この方法で300行を挿入するには、このINSERT文を300回実行する必要があります。

しかし、salaryがサイズ300のホスト配列の場合は、一度に300行すべてがEMP表に挿入されます。各行のSAL列にはsalary配列の要素の値が格納されます。

B.4 埋込みPL/SQLの使用について

図B-1のように、アプリケーションがデータベース集約型であれば、制御構造体を使用してPL/SQLブロック内でSQL文をグループ化し、ブロック全体をデータベース・サーバーに送ることができます。これによってアプリケーションとデータベース・サーバーとの間の通信量は大幅に減少します。

また、PL/SQLサブプログラムを使用してアプリケーションからサーバーへのコールを少なくすることもできます。たとえば、10個のSQL文を個々に実行するには、10回のコールが必要ですが、10個のSQL文を含む1つのサブプログラムを実行する場合、コールは1回で済みます。

図B-1 PL/SQLによるパフォーマンスの向上

「図B-1 PL/SQLによるパフォーマンスの向上」の説明

PL/SQLは、Oracle FormsなどのOracleアプリケーション開発ツールでも使用できます。PL/SQLでこれらのツールに手続き型処理能力を追加することで、パフォーマンスが向上します。PL/SQLを使用すると、Oracleのツール製品ではデータベース・サーバーをコールせずに、すべての計算を迅速かつ効率的に処理できます。この結果、時間が節約され、ネットワークの通信量が減少します。

B.5 SQL文の最適化について

Oracleオプティマイザにより、すべてのSQL文について実行計画(その文を実行するためにサーバーが行う一連の手順)が生成されます。これらの手順は、『Oracle Databaseアプリケーション開発者ガイド - 基礎編』に記載されたルールによって決まります。これらのルールに従うと、最適なSQL文を作成できます。

B.5.1 オプティマイザ・ヒント

場合によっては、サーバーに対してSQL文を最適化する方法を示すことができます。このようにして示す内容はヒントと呼ばれ、これによりオプティマイザによる決定に運用側から影響を与えることができます。

ヒントはディレクティブではなく、オプティマイザによるジョブの実行を助けるだけです。一部のヒントはSQL文を最適化するために使用される情報の範囲を制限し、他のヒントは全体的な戦略を提案します。

ヒントを使用して、次の事項を指定できます。

• SQL文の最適化アプローチ

• 参照されているそれぞれの表へのアクセス・パス

• 結合のための結合順序

• 表を結合する方法

つまり、ヒントは次の4つのカテゴリに分けられます。

• 最適化アプローチ

• アクセス・パス

• 結合順序

• 結合操作

たとえば、2つの最適化アプローチ・ヒントであるCOSTとNOCOSTは、コストベースのオプティマイザとルールベースのオプティマイザをそれぞれ起動します。

SELECT、UPDATE、INSERTあるいはDELETE文の動詞の直後にC言語のスタイルのコメントを記述して、オプティマイザにヒントを与えます。たとえば、オプティマイザは次の文でコストベースのアプローチを使用します。

SELECT /*+ COST */ ename, sal INTO ... 

C++コードでは、//+という形式のオプティマイザ・ヒントも認識されます。

B.5.2 トレース機能

SQLトレース機能とEXPLAIN PLAN文を使用すると、アプリケーションの処理速度を低下させるおそれのあるSQL文を特定できます。

SQLトレース機能は、実行された各SQL文についての統計情報を生成します。この統計表示で、最も処理時間のかかる文がどれか判断できます。このため、それらの文の処理効率のチューニングに専念できます。

EXPLAIN PLAN文はアプリケーション内の各SQL文に対する実行計画を示します。実行計画には、SQL文の実行に必要なデータベース処理が記述されています。実行計画を使用すると、非効率的なSQL文を特定できます。

B.6 文キャッシュについて

これは、動的SQL文に依存するすべてのプリコンパイラ・アプリケーションのパフォーマンス向上に役立つ機能です。この新機能の実装により、動的文を再利用する際の解析のオーバーヘッドが削減されます。プリコンパイラ・アプリケーションのユーザーは、新しいコマンドライン・オプション(文のキャッシュ・サイズ用)を使用することで、パフォーマンスの向上を実現できます。このオプションにより、動的文の文のキャッシュが有効になります。この新しいオプションを有効にすると、セッション作成時に文のキャッシュが作成されます。キャッシングは動的文に対してのみ適用され、静的文用のカーソル・キャッシュとこの機能は共存します。

B.7 索引の使用について

索引は、ROWIDを使用して、表の列の各値をその値が格納されている行に関連付けます。索引はCREATE INDEX文で作成します。詳細は、CREATE INDEXを参照してください。

表の15%未満の行しか戻さない問合せでは、索引を使用することによりパフォーマンスが向上します。表の15%以上の行を戻す問合せは、全体スキャンによる方法、つまり、すべての行を順番に読み込む方法の方が速く処理されます。

WHERE句内で索引の付いた列を指定する問合せは、その索引を使用します。索引を付ける列を選択するためのガイドラインは、Oracle Databaseアドバンスト・アプリケーション開発者ガイドを参照してください。

B.8 行レベル・ロックの利用について

デフォルトでは、データは表レベルではなく行レベルでロックされます。行レベルでロックすると、複数のユーザーが同一の表の別の行に同時にアクセスできます。その結果、パフォーマンスが大幅に向上します。

表レベルでのロックも指定できますが、これはトランザクション処理オプションの効果を低下させます。

オンラインのトランザクション処理を実行するアプリケーションには、行レベル・ロックが最も有効です。アプリケーションで表レベル・ロックを指定している場合は、行レベル・ロックを利用できるように変更してください。通常、明示的な表レベル・ロックは使用しないようにします。

B.9 不要な解析の排除について

不要な解析をなくすには、カーソルを正しく操作することと、次に示すカーソル管理オプションを選択して使用する必要があります。

• MAXOPENCURSORS

• HOLD_CURSOR

• RELEASE_CURSOR

これらのオプションは、暗黙カーソルおよび明示カーソル、カーソル・キャッシュおよびプライベートSQL領域に影響します。

B.9.1 明示カーソルの処理について

カーソルには、暗黙カーソルと明示カーソルの2種類があることを思い出してください。カーソルは、データ定義文およびDML文のすべてについて暗黙的に宣言されます。ただし、複数行を戻す問合せでは、カーソルを明示的に宣言する(またはホスト配列を使用する)必要があります。DECLARE CURSOR文を使用すると、明示カーソルを宣言できます。明示カーソルのオープンおよびクローズを処理する方法はパフォーマンスに影響します。

アクティブ・セットを再評価する必要がある場合は、そのカーソルを再OPENするのみで済みます。OPENでは任意の新しいホスト変数値が使用されます。カーソルを再OPENする前にCLOSEしなければ、処理時間を節約できます。

注意:

すでにオープンしているカーソルを再OPENすると、パフォーマンスの最適化が簡単になります。ただし、これはANSI拡張機能です。したがって、MODE=ANSIを指定している場合には、カーソルを再OPENする前にCLOSEする必要があります。

カーソルのOPENによって取得したリソース(メモリーおよびロック)を解放するときにのみ、そのカーソルをCLOSEします。たとえば、プログラムでは終了前にすべてのカーソルをCLOSEする必要があります。

B.9.1.1 カーソルの制御

一般に、明示的に宣言されたカーソルの制御には、次の3つの方法があります。

• DECLARE、OPENおよびCLOSEを使用します。

• PREPARE、DECLARE、OPENおよびCLOSEを使用します。

• MODE=ANSIの場合は、COMMITによってカーソルをクローズします。

最初の方法を使用する場合は、不要な解析に注意する必要があります。カーソルをCLOSEしたか、まだOPENしていないために、解析された文を使用できないときにかぎり、OPENで解析を実行します。プログラムはカーソルをDECLAREし、ホスト変数の値が変わるたびにこれを再OPENし、このSQL文が必要なくなったときにのみこれをCLOSEする必要があります。

2番目の方法(動的SQL方法3および方法4用の方法)を使用する場合は、PREPAREで解析が実行され、解析された文はCLOSEを実行するまで使用できます。プログラムで次のようにする必要があります。

• SQL文をPREPAREします。

• カーソルをDECLAREします。

• ホスト変数の値が変更されるたびに、カーソルを再OPENします。

• SQL文を再びPREPAREします。

• SQL文が変更された場合は、カーソルを再OPENします。

• SQL文が不要になった場合にのみカーソルをCLOSEします。

OPEN文およびCLOSE文をループの中に配置するのはできるだけ避けてください。SQL文の不要な再解析の原因になります。次の例では、OPEN文とCLOSE文がどちらも外側のwhileループの中にあります。MODE=ANSIの場合は、CLOSE文は例に示す位置に配置する必要があります。ANSIでは、カーソルを再OPENする前にCLOSEする必要があります。

EXEC SQL DECLARE emp_cursor CURSOR FOR 
     SELECT ename, sal from emp where sal >  :salary and  
                                      sal <= :salary + 1000; 
salary = 0; 
while (salary < 5000) 
{  
     EXEC SQL OPEN emp_cursor; 
     while (SQLCODE==0) 
     { 
         EXEC SQL FETCH emp_cursor INTO .... 
         ... 
     } 
     salary += 1000; 
     EXEC SQL CLOSE emp_cursor; 
}

一方、MODE=ORACLEのときは、カーソルを再OPENせずにCLOSE文を実行できます。CLOSE文を外側のwhileループの外に配置すると、OPEN文が繰り返されるたびに再解析されるのを回避できます。

... 
while (salary < 5000) 
{  
     EXEC SQL OPEN emp_cursor; 
     while (sqlca.sqlcode==0) 
     { 
         EXEC SQL FETCH emp_cursor INTO .... 
         ... 
     } 
     salary += 1000; 
} 
EXEC SQL CLOSE emp_cursor;

B.9.2 カーソル管理オプションの使用について

SQL文の解析は、構成を変更しないかぎり一度のみで十分です。たとえば、選択リストまたはWHERE句に列を追加して問合せの構成を変更するとします。HOLD_CURSORおよびRELEASE_CURSOR、MAXOPENCURSORSオプションによって、サーバーにおけるSQL文の解析および再解析の管理方法を制御できます。明示カーソルを宣言すると、解析を最大限に制御できます。

B.9.2.1 SQL領域とカーソル・キャッシュ

DML文を実行すると、その文に対応しているカーソルがPro*C/C++カーソル・キャッシュ内のエントリにリンクされます。カーソル・キャッシュとはカーソル管理のために使用されて連続的に更新されるメモリー領域です。カーソル・キャッシュ・エントリは、次々に1つのプライベートSQL領域にリンクされます。

プライベートSQL領域とは、実行時に動的に作成される作業領域で、ホスト変数のアドレスおよびその文の処理に必要なその他の情報が保存されます。明示カーソルを使用すると、SQL文に名前を付け、プライベートSQL領域に保存されている情報にアクセスし、この情報の処理をある程度制御できます。

図B-2は、プログラムでINSERTおよびDELETEを実行した後のカーソル・キャッシュを表しています。

図B-2 カーソル・キャッシュでリンクされたカーソル

「図B-2 カーソル・キャッシュでリンクされたカーソル」の説明

B.9.2.2 リソースの使用

ユーザー・セッションごとのオープン・カーソルの最大数は、初期化パラメータOPEN_CURSORSによって設定します。

MAXOPENCURSORSは、カーソル・キャッシュの初期サイズを指定します。新しいカーソルが必要で、しかも空きのキャッシュ・エントリがない場合、サーバーではエントリの再利用が試行されます。再利用の可能性はHOLD_CURSORとRELEASE_CURSORの値によって決まり、また明示カーソルの場合には、カーソル自体の状態によって決まります。

MAXOPENCURSORSの値が実際に必要なキャッシュ・エントリの数より小さい場合、サーバーでは再利用可能とマークされている最初のキャッシュ・エントリが使用されます。たとえば、INSERT文のキャッシュ・エントリE(1)が再利用可能とマークされていて、キャッシュ・エントリの数がすでにMAXOPENCURSORSに達しているとします。プログラムが新しい文を実行する場合、キャッシュ・エントリE(1)とそのプライベートSQL領域は新しい文に再度割り当てられることがあります。INSERT文を再実行するために、サーバーではそれを再度解析しなおして、別のキャッシュ・エントリを再度割り当てる必要があります。

再利用できるキャッシュ・エントリが見つからない場合、サーバーでは追加のキャッシュ・エントリが割り当てられます。たとえば、MAXOPENCURSORS=8で、8エントリすべてがアクティブな場合、9番目のエントリが作成されます。サーバーでは、空きメモリーがなくなるかOPEN_CURSORSで設定された上限に達するまで、必要に応じてキャッシュ・エントリの割当てが続行されます。この動的割当ては、処理オーバーヘッドを増大させます。

したがって、MAXOPENCURSORSの値を小さく設定すると、メモリーの節約にはなりますが、新しいキャッシュ・エントリの動的割当ておよび割当て解除に資源を消耗する場合があります。MAXOPENCURSORSの値を大きく設定すると、実行は確実に速くなりますが、より大きなメモリーを使用することになります。

B.9.2.3 実行回数の少ない場合

実行回数の少ないSQL文とそのプライベートSQL領域間のリンクは、一時的なものにした方がよい場合もあります。

HOLD_CURSOR=NO(デフォルト値)と指定した場合は、サーバーによりそのSQL文が実行され、カーソルがクローズされた後に、プリコンパイラによりこのカーソルとカーソル・キャッシュ間のリンクが再利用可能としてマークされます。このリンクは、それが示すカーソル・キャッシュ・エントリが別のSQL文に必要になると、すぐに再利用されます。これにより、プライベートSQL領域に割り当てられたメモリーが解放され、解析ロックが解除されます。ただし、PREPAREしたカーソルは実行状態のままにする必要があるため、HOLD_CURSOR=NOと指定した場合でもそのリンクは維持されます。

RELEASE_CURSOR=YESと指定した場合は、サーバーによりそのSQL文が実行され、カーソルがクローズされた後に、プライベートSQL領域が自動的に解放され、解析した文は失われます。メモリーの節約のためにMAXOPENCURSORSを低い値に設定しているような場合には、この指定が必要です。

DML文がデータ定義文より前にあり、どちらの文も同じ表を参照する場合には、DML文にRELEASE_CURSOR=YESを指定してください。これにより、データ操作文で取得される解析ロックと、データ定義文で要求される排他ロックとの間の競合が回避できます。

RELEASE_CURSOR=YESを指定した場合は、プライベートSQL領域とキャッシュ・エントリ間のリンクはただちに削除され、このプライベートSQL領域は解放されます。HOLD_CURSOR=YESを指定している場合でも、RELEASE_CURSOR=YESによりHOLD_CURSOR=YESが上書きされるため、サーバーではSQL文を実行する前に、プライベートSQL領域にメモリーを再度割り当てて、このSQL文を再解析する必要があります。

ただし、RELEASE_CURSOR=YESを指定した場合、サーバーではSQL文とPL/SQLブロックの解析済の表現が共有SQLキャッシュに保存されるため、それ以上の再解析処理は不要になることがあります。カーソルをクローズしても、解析された表現はキャッシュの内容が書き換えられるまで効力を持ちます。

B.9.2.4 実行回数の多い場合

プライベートSQL領域には文の実行に必要なすべての情報が格納されているため、頻繁に実行されるSQL文とそのプライベートSQL領域のリンクを維持する必要があります。この情報へのアクセスを上手に管理すると、後続の文の実行速度をさらに向上させることができます。

HOLD_CURSOR=YESを指定した場合は、サーバーによりSQL文が実行された後に、カーソルとカーソル・キャッシュのリンクが維持されます。したがって、解析された文および割り当てられたメモリーが、利用可能なまま維持されます。これは、不必要な再解析を避けるためにアクティブにしておくSQL文で役に立ちます。

RELEASE_CURSOR=NO(デフォルト値)の場合、サーバーでSQL文を実行した後にキャッシュ・エントリとプライベートSQL領域間のリンクが維持され、オープンしたカーソルの数がMAXOPENCURSORSの値を超えないかぎり、そのリンクは再利用されません。これは、解析した文および割り当てたメモリーが使用可能な状態のままのため、頻繁に実行するSQL文の場合に有効です。

注意:

Oracle8iの以前のバージョンでは、SQL文の実行後にRELEASE_CURSOR=NOおよびHOLD_CURSOR=YESとなっていると、解析後の表現を継続して使用できました。ただし、Oracleの後続のバージョンでは、RELEASE_CURSOR=NOおよびHOLD_CURSOR=YESが指定されている場合、解析後の表現を使用できるのは共有SQLキャッシュの内容が期限切れになるまでの間です。通常、これは問題にはなりませんが、そのSQL文が再解析される前に参照オブジェクトの定義が変わると、結果が予期せぬものになる場合があります。

B.9.2.5 埋込みPL/SQLの考慮事項

カーソルを管理するために、埋込みPL/SQLブロックはSQL文と同様に扱われます。埋込みPL/SQLブロックが実行されると、親カーソルがPL/SQLブロック全体に対応付けられ、埋込みPL/SQLブロック用にキャッシュ・エントリとPGAのプライベートSQL領域の間にリンクが作成されます。埋込みブロック内の各SQL文にも、PGAのプライベートSQL領域が必要なことに注意してください。これらのSQL文は、PL/SQLが管理する子カーソルを使用します。子カーソルの性質は、対応付けられた親カーソルによって決まります。つまり、子カーソルが使用するプライベートSQL領域は、親カーソルのプライベートSQL領域が解放された後解放されます。

B.9.2.6 パラメータの相互作用

図B-1に、HOLD_CURSORとRELEASE_CURSORの相互関係を示します。HOLD_CURSOR=NOを指定すると、RELEASE_CURSOR=NOはオーバーライドされ、RELEASE_CURSOR=YESを指定すると、HOLD_CURSOR=YESがオーバーライドされることに注意してください。

表B-1 HOLD_CURSORとRELEASE_CURSORの相互関係

HOLD_CURSOR	RELEASE_CURSOR	リンク
NO	NO	再利用可能とマークされます。
YES	NO	維持されます。
NO	YES	ただちに削除されます。
YES	YES	ただちに削除されます。

B.10 不要な再解析の回避について

不要な再解析を回避するには、ループ内のSQL文の実行フェーズ中に発生するエラーを排除する必要があります。ループ内の埋込みSQL文が実行されるときには、そのSQL文が一度のみ解析されます。ただし、実行結果がエラーになったSQL文は、通常は再解析されます。この場合、次のエラーを除き、発生したエラーすべてについて再解析が発生します。

• ORA-1403 (見つかりません)

• ORA-1405 (切捨て)

• ORA-1406 (NULL値)

他のすべてのエラーを排除すれば、不要な再解析を回避できます。

B.11 接続プーリングの使用方法について

この項では、接続プーリングを使用したパフォーマンス・チューニングを説明します。アプリケーションがマルチスレッドで、同一データベースに対して同時操作を実行している場合、接続プーリング機能を使用するとパフォーマンスを上げられます。接続プーリングに使用されるパラメータに適切な値を選択してアプリケーションのパフォーマンスをチューニングすると、既存のアプリケーション・パフォーマンスに比べて、パフォーマンスを最高3倍まで上げられます。

B.12 Traffic DirectorモードのOracle Connection Managerの使用について

Traffic DirectorモードのOracle Connection Managerは、サポートされているデータベース・クライアントとデータベース・インスタンスの間に配置されるプロキシです。

Oracle Database 11gリリース2 (11.2)以上からサポートされるクライアントは、Traffic DirectorモードのOracle Connection Managerに接続できます。Traffic DirectorモードのOracle Connection Managerは、計画済および計画外のデータベース・サーバー停止に対する改善された高可用性(HA)、接続多重化のサポートおよびロード・バランシングを提供します。Traffic DirectorモードのOracle Connection Managerのサポートは、次の項で詳しく説明しています

• 操作のモード

• 主な機能

操作のモード

Traffic DirectorモードのOracle Connection Managerは、次のモードの操作をサポートします。

• プール接続モードでは、Traffic DirectorモードのOracle Connection Managerは、次のデータベース・クライアント・リリースを使用するすべてのアプリケーションをサポートします。

  • OCI、OCCIおよびOpen Source Driver (Oracle Database 11gリリース2 (11.2.0.4)以上)

  • JDBC (Oracle Database 12cリリース1 (12.1)以上)

  • ODP.NET (Oracle Database 12cリリース2 (12.2)以上)

  さらに、アプリケーションでDRCPを使用する必要があります。つまり、アプリケーションでは、接続文字列で(またはtnsnames.ora別名で)DRCPを有効にする必要があります。

• 非プール接続(または専用)モードでは、Traffic DirectorモードのOracle Connection Managerは、データベース・クライアント・リリースOracle Database 11gリリース2 (11.2.0.4)以上を使用するすべてのアプリケーションをサポートします。このモードでは、接続多重化など一部の機能は使用できません。

主な機能

Traffic DirectorモードのOracle Connection Managerは次に対するサポートを提供しています。

• 次を含む透過的パフォーマンス拡張機能および接続多重化。

  • 文のキャッシング、行のプリフェッチ、および結果セットのキャッシングは、すべてのモードの操作に対して自動で有効化されます。

  • プロキシ常駐接続プール(PRCP)を使用するデータベース・セッション多重化(プール・モードのみ)。ここでPRCPは、データベース常駐接続プーリング(DRCP)のプロキシ・モードです。アプリケーションは、Traffic DirectorモードのOracle Connection Managerとデータベースの間で、透過的な接続時ロード・バランシングおよび実行時ロード・バランシングを取得します。

  • 複数のTraffic DirectorモードのOracle Connection Managerインスタンスがある場合、アプリケーションは、クライアント側の接続時ロード・バランシングまたはロード・バランサ(BIG-IP、NGINXなど)を通じてスケーラビリティが増加します

• アプリケーション停止時間がゼロ

  • 計画済データベース・メンテナンスまたはプラガブル・データベース(PDB)再配置

    • プール・モード

      Traffic DirectorモードのOracle Connection Managerは、計画済停止に対するOracle Notification Service (ONS)イベントに応答し、作業をリダイレクトします。要求が完了すると、Traffic DirectorモードのOracle Connection Managerのプールから接続が排出されます。サービスの再配置は、Oracle Database 11gリリース2 (11.2.0.4)以上に対してサポートされています。

      PDB再配置については、Traffic DirectorモードのOracle Connection Managerは、ONSが構成されていない場合でも、PDBが再配置されるときにインバンド通知に応答します(Oracle Databaseリリース18c、バージョン18.1以上のサーバーに対してのみ) 

    • 非プールまたは専用モード

      クライアントからの要求境界情報がない場合、Traffic DirectorモードのOracle Connection Managerは、多くのアプリケーションに対して計画済停止をサポートします(要求/トランザクション境界を越えて保持する必要があるものが単純なセッション状態およびカーソル状態である場合のみ)。次の機能がサポートされます。

      • トランザクション境界でサービス/PDBを停止するか、Oracle Databaseリリース18cの連続アプリケーション可用性を利用して、要求境界でサービスを停止します

      • Traffic DirectorモードのOracle Connection Managerは、透過的アプリケーション・フェイルオーバー(TAF)のフェイルオーバー・リストアを利用し、再接続して単純な状態をリストアします。

  • ほとんどが読取りのワークロードに対する計画外データベース停止

• 単一点障害を回避するTraffic DirectorモードのOracle Connection Managerの高可用性。これは次によってサポートされます。

  • 接続文字列でロード・バランサまたはクライアント側のロード・バランシング/フェイルオーバーを使用する、複数インスタンスのTraffic DirectorモードのOracle Connection Manager

  • Traffic DirectorモードのOracle Connection Managerインスタンスのローリング・アップグレード

  • クライアントからTraffic DirectorモードのOracle Connection Managerへの既存の接続の、計画済停止に対する正常なクローズ

  • Oracle Databaseリリース18c以上のクライアントに対するインバンド通知

  • 古いクライアントに対しては、通知は現在の要求の応答とともに送信されます

• セキュリティおよび分離のために、Traffic DirectorモードのOracle Connection Managerは次の機能を提供します。

  • Transmission Control Protocol/Transmission Control Protocol Secure (TCP/TCPS)およびプロトコル変換をサポートするデータベース・プロキシ

  • IPアドレス、サービス名、およびSecure Socket Layer/Transport Layer Security (SSL/TLS)ウォレットに基づくファイアウォール

  • マルチテナント環境でのテナント分離

  • サービス妨害およびファジング攻撃からの保護

  • オンプレミスのOracle DatabaseとOracle Cloudの間のデータベース・トラフィックの安全なトンネリング

関連項目:

• Traffic DirectorモードのOracle Connection Managerを設定するためのcman.ora構成ファイルの構成の詳細は、Oracle Database Net Services管理者ガイドを参照してください

• Traffic DirectorモードのOracle Connection Managerプロキシ認証の構成の詳細は、Oracle Database Net Services管理者ガイドを参照してください

• 計画外停止イベントに対するTraffic DirectorモードのOracle Connection Managerの構成の詳細は、Oracle Database Net Services管理者ガイドを参照してください

• 計画済停止イベントに対するTraffic DirectorモードのOracle Connection Managerの構成の詳細は、Oracle Database Net Services管理者ガイドを参照してください

• Traffic DirectorモードのOracle Connection Managerで使用するためのプロキシ常駐接続プールの構成の詳細は、Oracle Database Net Services管理者ガイドを参照してください

• Traffic DirectorモードのOracle Connection Managerのすべてのドライバでサポートされていない機能の詳細は、Oracle Database Net Services管理者ガイドを参照してください

• Oracle CMAN構成ファイルの概要は、Oracle Database Net Servicesリファレンスを参照してください