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

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

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

• パフォーマンスの向上

• ホスト表の使用方法

• PL/SQLおよびJavaの使用

• SQL文の最適化

• 索引の使用

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

• 不要な解析の排除

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

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

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

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

     EXEC SQL SELECT DNAME, DEPTNO 
         FROM DEPT 
         WHERE DEPTNO IN (SELECT DEPTNO FROM EMP)
     END-EXEC. 

次の文と比較してください。

     EXEC SQL SELECT DNAME, DEPTNO 
         FROM DEPT 
         WHERE EXISTS 
         (SELECT DEPTNO FROM EMP WHERE DEPT.DEPTNO = EMP.DEPTNO)
     END-EXEC. 

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

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

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

C.2 パフォーマンスの向上

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

ネットワーク化された環境下では、次の方法で、Oracleの通信オーバーヘッドを大幅に削減できます。

• ホスト表の使用

• 埋込みPL/SQLの使用

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

• SQL文の最適化

• SQL文のキャッシング

• 索引の使用

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

• 不要な解析の排除

• 不要な再解析の回避

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

C.3 ホスト表の使用

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

     EXEC SQL INSERT INTO EMP (SAL) VALUES (:SALARY) END-EXEC.

SALARYが通常のホスト変数の場合は、OracleはINSERT文を1回実行し、EMP表に1行を挿入します。この行のSAL列にはSALARYの値が格納されます。この方法で300行を挿入するには、このINSERT文を300回実行する必要があります。

これに対して、SALARYがサイズ300のホスト表の場合は、Oracleは300行全部を一度にEMP表に挿入します。各行のSAL列にはSALARY表の要素の値が格納されます。

詳細は、ホスト表を参照してください

C.4 PL/SQLおよびJavaの使用

図C-1に示すように、データベース処理が中心のアプリケーションの場合は、制御構造を使用して複数のSQL文を1つのPL/SQLブロックにまとめ、そのブロック全体をOracleに送信できます。これにより、使用しているアプリケーションとデータベースとの通信量を大幅に削減できます。

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

無名ブロックとは異なり、PL/SQLおよびJavaサブプログラムは別々にコンパイルし、データベースに格納できます。コールされたPL/SQLサブプログラムは、ただちにPL/SQLエンジンに渡されます。さらに、複数のユーザーが1つのサブプログラムを実行する場合でも、メモリーにロードするコピーは1つで済みます。

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

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

C.5 SQL文の最適化

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

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

オプティマイザにより、すべてのSQL文について実行計画(その文を実行するためにOracleが行う一連のステップ)が生成されます。場合によっては、SQL文を最適化する方法を提示することもできます。このようにして示す内容はヒントと呼ばれ、これによりオプティマイザによる決定に運用側から影響を与えることができます。

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

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

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

• 結合のための結合順序

• 表を結合する方法

C.5.1.1 ヒントの渡し方

ヒントをオプティマイザに渡すには、SELECT文、UPDATE文またはDELETE文の動詞の直後にC言語形式のコメントの中に入れます。ルール重視の最適化またはコスト重視の最適化のどちらかを選択できます。コスト重視の最適化では、ヒントはスループットの最大化または応答時間に寄与します。次の例では、ALL_ROWSヒントによって問合せのスループットが最大になります。

     EXEC SQL SELECT /*+ ALL_ROWS (cost-based) */ EMPNO, ENAME, SAL
         INTO :EMP-NUMBER, :EMP-NAME, :SALARY  
         FROM EMP 
         WHERE DEPTNO = :DEPT-NUMBER
     END-EXEC. 

プラス記号(+)はコメント先頭の直後に置く必要があり、コメントが1つ以上のヒントを含むことを示します。コメントにはヒントだけでなく注釈も含まれることがあることに注意してください。

オプティマイザ・ヒントの詳細は、「パフォーマンスとスケーラビリティ」を参照してください。

トレース機能

SQLトレース機能およびEXPLAIN PLAN文を使用すると、アプリケーションの処理速度を低下させるおそれのあるSQL文を特定できます。トレース機能で、Oracleで実行するすべてのSQL文に対する統計表示を生成します。この統計表示で、最も処理時間のかかる文がどれか判断できます。このため、それらの文の処理効率のチューニングに専念できます。

EXPLAIN PLAN文はアプリケーション内の各SQL文に対する実行計画を示します。実行計画を使用すると、非効率的なSQL文を特定できます。

関連項目: トレース・ツールの使用方法および出力の分析方法は、パフォーマンス用ツールを参照してください。

C.6 SQL文のキャッシング

文キャッシングを使用すると、プリコンパイラ・アプリケーションのパフォーマンスが向上します。動的SQL文を使用するすべてのプログラムは、文の再解析にカーソルを使用する必要があるため、文キャッシングによってパフォーマンスが向上します。この新機能によって、全体的に実行時間が減少します。

stmt_cacheオプションを設定すると、アプリケーションでそれぞれの動的SQL文の予測数を保持できます。stmt_cacheサイズは、新しいプリコンパイラ・コマンドライン・オプションを使用して設定できます。stmt_cacheの最適な値は、入力プログラムの動作に依存するため設定できません。

パフォーマンスは、(文キャッシングを使用した場合と使用しない場合の)実行時間の変化によって測定できます。

C.7 索引の使用

索引は、ROWIDを使用して、表の列のそれぞれの値をその値が入っている行に対応付けます。索引はCREATE INDEX文で作成します。詳細は、CREATE INDEXを参照してください。

表の15%未満の行しか戻さない問合せでは、索引を使用することによりパフォーマンスが向上します。表の15%以上の行を戻す問合せは、フル・スキャンによる方法、つまり、すべての行を順番に読み込む方法の方が速く処理されます。WHERE句内で索引の付いた列を指定する問合せは、その索引を使用します。どの列に索引を付けるかを選択するためのガイドラインは、「データベース・アプリケーションの索引の使用方法」を参照してください。

C.8 行レベル・ロックの利用

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

表レベルでのロックも指定できますが、これはトランザクション処理オプションの効果を低下させます。表ロックの詳細は、「LOCK TABLE文の使用方法」を参照してください。

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

C.9 不要な解析の排除

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

• MAXOPENCURSORS

• HOLD_CURSOR

• RELEASE_CURSOR

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

注意: カーソル・キャッシュの統計情報は、ORACAを使用して取得できます。「Oracle通信領域の使用」を参照してください。

C.9.1 明示カーソルの操作

カーソルには暗黙カーソルおよび明示カーソルの2種類があることに注意してください(「エラーおよび警告」を参照してください)。Oracleはデータ定義文およびDML文のすべてを暗黙的にカーソルを宣言します。ただし、複数の行を戻す問合せでは、明示的にカーソルを宣言し、1つのホスト表の中に選択するのではなく一括でフェッチする必要があります。DECLARE CURSOR文を使用すると、明示カーソルを宣言できます。明示カーソルのオープンとクローズの方法によって、パフォーマンスに影響があります。

アクティブ・セットの再評価が必要なときは、そのカーソルを再度オープンするだけでかまいません。OPEN文では、任意の新しいホスト変数の値が使用されます。最初にカーソルをクローズせずにオープンのままにしておくと、処理時間を節約できます。

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

注意: パフォーマンスをチューニングしやすいように、プリコンパイラではすでにオープンされているカーソルを再オープンできます。ただし、これはANSI/ISOの埋込みSQL規格に対するOracle拡張機能です。したがって、MODE=ANSIのときは、カーソルを再オープンする前にクローズする必要があります。

C.9.1.1 カーソルの制御

一般的に、明示的に宣言されたカーソルの制御には次のような3つの要素が影響します。

• DECLARE、OPEN、FETCHおよびCLOSE文の使用。

• PREPARE、DECLARE、OPEN、FETCHおよびCLOSE文の使用

• MODE=ANSIの場合の、COMMITによるカーソルのクローズ

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

動的SQLの方法3および4で使用されている2番目の方法を使用する場合は、PREPAREで解析が実行され、解析された文はCLOSEを実行するまで使用できます。プログラムはSQL文を用意してカーソルを宣言し、ホスト変数の値が変わるたびにこれを再オープンし、SQL文に変更があったときはSQL文を再度準備してカーソルを再オープンし、このSQL文が必要なくなったときにのみこれをクローズする必要があります。

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

     EXEC SQL DECLARE emp_cursor CURSOR FOR 
         SELECT ENAME, SAL FROM EMP
         WHERE SAL >  :SALARY
         AND SAL <= :SALARY + 1000
     END-EXEC. 
     MOVE 0 TO SALARY. 
 TOP. 
     EXEC SQL OPEN emp_cursor END-EXEC.
 LOOP.
     EXEC SQL FETCH emp_cursor INTO ....
     ... 
         IF SQLCODE = 0
              GO TO LOOP
          ELSE
              ADD 1000 TO SALARY
          END-IF.
     EXEC SQL CLOSE emp_cursor END-EXEC.
     IF SALARY < 5000
         GO TO TOP. 

MODE=ORACLEでCLOSE文を外側のループの外に指定すると、OPEN文が繰り返されるたびに再解析されるのを回避できます。

 TOP. 
     EXEC SQL OPEN emp_cursor END-EXEC.
 LOOP.
     EXEC SQL FETCH emp_cursor INTO ....
     ... 
         IF SQLCODE = 0
              GO TO LOOP
          ELSE
              ADD 1000 TO SALARY
          END-IF. 
     IF SALARY < 5000
         GO TO TOP. 
     EXEC SQL CLOSE emp_cursor END-EXEC.

C.9.2 カーソル管理オプションの使用方法

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

C.9.2.1 プライベートSQL領域およびカーソル・キャッシュ

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

プライベートSQL領域とは、Oracleが実行時に動的に作成する作業領域であり、この領域には解析されたSQL文、ホスト変数のアドレスおよびその文の処理に必要なその他の情報が保存されます。動的方法3を使用すると、SQL文のネーミング、プライベートSQL領域に保存されている情報へのアクセス、およびある程度の処理の制御を行うことができます。

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

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

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

C.9.2.2 リソースの使用

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

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

プログラム実行中にキャッシュする必要がある文の数よりMAXOPENCURSORSの値が少ない場合は、MAXOPENCURSORSキャッシュ・エントリがなくなると、Oracleは再利用できるカーソル・キャッシュ・エントリを探します。たとえば、INSERT文のキャッシュ・エントリE(1)が再利用可能とマークされていて、キャッシュ・エントリの数がすでにMAXOPENCURSORSに達しているとします。プログラムが新しい文を実行する場合、キャッシュ・エントリE(1)とそのプライベートSQL領域は新しい文に再度割り当てられることがあります。INSERT文を再実行するには、Oracleはそれをもう一度解析し、別のキャッシュ・エントリを再度割り当てる必要があります。

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

したがって、HOLD_CURSOR=NO (デフォルト)を指定してMAXOPENCURSORSの値を小さく設定すると、メモリーの節約にはなりますが、新しいキャッシュ・エントリの動的割当ておよび割当て解除のコストが高くなる場合があります。MAXOPENCURSORSの値を大きく設定すると、実行は確実に速くなりますが、より大きなメモリーを使用することになります。

C.9.2.3 実行回数が少ない場合

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

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

RELEASE_CURSOR=YESと指定した場合は、OracleがそのSQL文を実行してカーソルがクローズされた後、プライベートSQL領域が自動的に解放され、解析した文はなくなります。これは、メモリーを節約する場合などに必要になる可能性があります。

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

C.9.2.4 実行回数が多い場合

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

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

C.9.2.5 共有SQL領域への影響

Oracleでは、解析されたSQL文およびPL/SQLの表現を共有SQLキャッシュにキャッシュします。これらの表現は、他の文をキャッシュするために領域が必要になってエージ・アウトするまで保持されます。詳細は『Oracle Database概要』を参照してください。この面でのOracleサーバーの動作は、プリコンパイラのカーソル管理設定の影響を受けないため、次のような効果をもたらします。

• RELEASE_CURSOR=YESを設定して文を再実行すると、要求がサーバーに送られて解析されますが、文はまだキャッシュに格納されているので全解析を行う必要はありません。

• HOLD_CURSOR=YESを使用すると、文で参照されるオブジェクトのロックは保持されません。したがって、文のオブジェクトの1つが再定義されると、キャッシュされた文が無効になり、サーバーは自動的に文を再解析します。これは予想しない結果をもたらすことがあります。

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

C.9.2.6 埋込みPL/SQLに関する考慮事項

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

注意:

デフォルトのHOLD_CURSOR=YESおよびRELEASE_CURSOR=NOを使用した場合、Oracleの旧バージョンでSQL文を実行すると、解析された表現は実行後も使用可能です。これと同じ条件でOracleでSQL文を実行すると、解析された表現は、共有SQLキャッシュがエージ・アウトされるまで使用可能です。通常、これが問題となることはありませんが、SQL文が再解析される前に参照されたオブジェクトの定義が変更されると、予期しない結果をもたらす場合があります。

C.9.2.7 パラメータの相互作用

「HOLD_CURSORおよびRELEASE _CURSORの相互関係」に、HOLD_CURSORとRELEASE_CURSORの相互関係を示します。HOLD_CURSOR=NOを指定すると、RELEASE_CURSOR=NOはオーバーライドされ、RELEASE_CURSOR=YESを指定すると、HOLD_CURSOR=YESがオーバーライドされることに注意してください。

表C-1 HOLD_CURSORおよびRELEASE _CURSORの相互関係

HOLD_CURSOR	RELEASE_CURSOR	リンク
NO	NO	再利用可能としてマーク
YES	NO	維持
NO	YES	ただちに削除
YES	YES	ただちに削除

C.10 不要な再解析の回避

埋込みSQL文をループで実行した場合、解析は1回のみ行われます。ただし、SQL文の実行フェーズでエラーが発生した結果、文を再解析した場合は次の例外が発生することがあります。

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

• ORA-1405 (切捨て)

• ORA-1406 (NULL値)

これらのエラーを修正すると、不要な再解析を避けることができます。

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

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

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cでサポートされている唯一のアーキテクチャです。ドキュメントが改訂途中の間は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じてCDBまたはPDBを指しています。アップグレードなどでは、「非CDB」が以前のリリースの非CDBを指している場合もあります。

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およびオープン・ソース・ドライバ(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)ウォレットに基づくファイアウォール

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

  • DoS攻撃およびFuzzing攻撃からの保護

  • Oracle DatabaseオンプレミスとOracle Cloud間のデータベース・トラフィックのセキュア・トンネル接続

関連項目:

• Oracle Database Net Services管理者ガイド(cman.ora構成ファイルを構成して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管理者ガイド(Traffic DirectorモードのOracle Connection Managerのすべてのドライバでサポートされていない機能の詳細)

• Oracle Database Net Servicesリファレンス(Oracle CMAN構成ファイルの概要)