15 パフォーマンスに関するトピック
この章では、OCIのパフォーマンス機能に関するトピックについて説明します。
OCIを使用して、Oracle TimesTen In-Memory DatabaseおよびOracle TimesTen Application-Tier Database Cacheにアクセスできます。
関連項目:
TimesTenでのOracle Call Interfaceサポートの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』を参照してください。
OCIでの文キャッシュ
文キャッシュは、セッションごとの文のキャッシュを提供および管理する機能です。
文キャッシュによって、サーバーではカーソルが使用できる状態になり、文を再解析する必要はありません。文キャッシュは、接続プーリングおよびセッション・プーリングとともに使用でき、パフォーマンスおよび拡張性が向上します。また、セッション・プーリングを使用しなくても使用できます。文キャッシュを実装するOCIコールは次のとおりです。
-
OCIStmtPrepare2() -
OCIStmtRelease()
OCIでの、セッション・プーリングを使用しない文キャッシュ
セッション・プーリングを使用せずに文のキャッシングを実行する場合、ユーザーは通常のOCIステップを実行してログオンします。
セッションを取得するコールには、セッションにおいて文のキャッシングが有効であるかどうかを指定するモードがあります。最初、文キャッシュは空です。開発者は、文テキストを使用してキャッシュ内で文を見つけようとします。文が存在する場合、APIは以前に準備した文ハンドルを戻しますが、存在しない場合は、新しく準備した文ハンドルを戻します。
アプリケーション開発者は、文がキャッシュに戻される前に、文のバインドと定義を実行し、その後簡単に文の実行とフェッチを実行できます。キャッシュで文ハンドルが見つからない場合、開発者は、他のステップに加えて、ハンドルに異なる属性を設定する必要があります。
OCIStmtPrepare2()には、キャッシュ内に文が見つからない場合に、開発者がプリペアド文を使用するのか、またはNULLの文ハンドルを使用するのかを指定するモードがあります。
擬似コードは次のようになります。
OCISessionBegin( userhp, ... OCI_STMT_CACHE) ; OCIAttrset(svchp, userhp, ...); /* Set the user handle in the service context */ OCIStmtPrepare2(svchp, &stmthp, stmttext, key, ...); OCIBindByPos(stmthp, ...); OCIDefineByPos(stmthp, ...); OCIStmtExecute(svchp, stmthp, ...); OCIStmtFetch2(svchp, ...); OCIStmtRelease(stmthp, ...); ...
関連項目:
OCIでの、セッション・プーリングを使用した文キャッシュ
セッション・プーリングでの文キャッシュの場合、概念は同じですが、文キャッシュはセッション・レイヤーではなくセッション・プール・レイヤーで使用可能になります。
属性OCI_ATTR_SPOOL_STMTCACHESIZEにより、セッション・プール内のセッションごとにデフォルトの文キャッシュ・サイズが設定されます。これは、OCI_HTYPE_SPOOLハンドルで設定されます。プールの特定のセッションの文キャッシュ・サイズは、そのセッションでOCI_ATTR_STMTCACHESIZEを使用することでいつでも上書きできます。OCI_ATTR_SPOOL_STMTCACHESIZEの値は、いつでも変更できます。この属性を使用して、プール・レベルで文のキャッシングを有効または無効にできます。作成後、それと同時に、サービス・コンテキストで属性OCI_ATTR_STMTCACHESIZEを使用して、セッション・レベルで文のキャッシングを有効または無効にできます。この変更内容は、プール内の個別のセッションがユーザーに提供された際に反映されます。タグ付きセッションでは、この動作は当てはまりません。これについては、項の後半で説明します。
ノート:
属性は、セッションの取得後に変更できます。ただし、いったん属性を変更すると、基本の物理セッションで設定されたままになります。この値は、セッションが解放されてセッション・プールに戻される間、暗黙的に元の値にリセットされることはありません。したがって、OCIStmtRelease()を使用してセッションを解放するまで、セッションの状態を維持するのは開発者の責任です。
文キャッシュの有効化または無効化は、プーリングされていないセッションと同様に、各プーリング・セッションで許可されます。
OCI_SESSGET_STMTCACHEまたはOCI_LOGON2_STMTCACHEをそれぞれモード引数に指定すると、OCISessionGet()コールまたはOCILogon2()コールで文キャッシュ以外のプールから取り出されたセッションでも、ユーザーは文キャッシュを使用可能にできます。
セッション・プールのセッションを要求する場合は、そのセッションの文キャッシュ・サイズのデフォルトはプールの文キャッシュ・サイズとなります。つまり、そのセッション内で文キャッシュを使用可能または使用不可にすることができます。たとえば、プーリング・セッション(セッションA)に使用可能な文キャッシュがあり、文キャッシュがプールでオフにされ、ユーザーがセッションを要求してセッションAが戻された場合、文キャッシュはセッションAではオフになります。別の例としては、プールのセッションAに使用可能な文キャッシュがなく、プール・レベルの文キャッシュがオンになっている場合、セッションAがユーザーに戻される前に、プールのセッションとサイズが等しいセッションAの文キャッシュがオンになります。
タグ付けされたセッションが要求され、取り出された場合は、異なる結果となります。この場合は、文キャッシュのサイズは変更されません。したがって、文キャッシュはオンまたはオフになりません。さらに、OCISessionGet()コールでユーザーがモードOCI_SESSGET_STMTCACHEを指定する場合、このセッションがタグ付けされていると、これは無視されます。前述の例では、セッションAがタグ付けされていた場合、ユーザーに対するセッションとして戻されます。
関連項目:
OCIでの文キャッシュの規則
文キャッシュを使用する場合は、これらの規則に従います。
OCIでの文キャッシュには、守るべきいくつかの規則があります。
-
OCIStmtPrepare()ではなく、OCIStmtPrepare2()関数を使用します。OCIStmtPrepare()を使用する場合は、複数のサービス・コンテキスト間で1つの文ハンドルを使用しないことをお薦めします。使用した場合、OCIStmtPrepare2()を使用して文を取得するとエラーが発生します。文ハンドルを新規のサービス・コンテキストに移行するとき、実際には古いセッションに関連するカーソルがクローズされるため、文ハンドルの共有は取得されません。OCIでは、文ハンドルが移行されると、古いセッションに関連するすべてのバッファが解放されるため、クライアント側での共有も取得されません。 -
セッションごとに1つのサービス・コンテキストを保持する必要があります。サービス・コンテキストを指定した
OCIStmtPrepare2()を使用して取得した文ハンドルは、後で同じサービス・コンテキストとの組合せでのみ使用でき、異なるサービス・コンテキストとは使用できません。 -
OCIStmtPrepare2()のコールは、セッションに文キャッシュがなくても、文ハンドルを割り当てます。そのため、OCIStmtPrepare2()のみを使用するアプリケーションでは、文ハンドルのためにOCIHandleAlloc()をコールできません。 -
OCIStmtPrepare2()のコール後、ユーザーが文ハンドルでの処理を完了した後にOCIStmtRelease()をコールする必要があります。文キャッシュを使用する場合、これによって文はキャッシュに対して解放されます。文キャッシュを使用しない場合、文は割当て解除されます。OCIHandleFree()をコールしてメモリーを解放しないでください。 -
OCI_PREP2_CACHE_SEARCHONLYモードを指定してOCIStmtPrepare2()をコールし、NULLの文が戻された(文が見つからなかった)場合、後続のOCIStmtRelease()コールは必要ないため、実行しないでください。 -
OCIStmtPrepare()を使用してプリコンパイルされた文に対して、OCIStmtRelease()をコールしないでください。 -
文キャッシュには最大サイズ(文の数)があり、サービス・コンテキストの
OCI_ATTR_STMTCACHESIZE属性で変更できます。デフォルト値は20です。また、この属性を使用して、プールされている、またはプールされていないセッションの文キャッシュを使用可能または使用不可にできます。モードをOCI_STMT_CACHEに設定しないでOCISessionBegin()をコールする場合、サービス・コンテキストのOCI_ATTR_STMTCACHESIZEを0 (ゼロ)以外の属性に設定し、文キャッシュをオンにできます。セッション・プール・レベルで文キャッシュをオンにしない場合、OCISessionGet()により、文キャッシュに対応していないセッションが戻されます。OCI_ATTR_STMTCACHESIZEを使用すれば、キャッシュをオンにできます。同様に、同じ属性を使用してキャッシュ・サイズを0 (ゼロ)に設定することにより、文キャッシュをオフにできます。 -
文の解放時に文にタグを付けることができ、これによって、次回に同じタグの文を要求できます。タグは、キャッシュを検索するために使用します。タグなしの文(タグが
NULL)は、タグ付きの文の特殊なケースです。2つの文がタグのみ異なる場合、または、一方がタグ付きでもう一方がタグなしの場合、これらの文は異なる文とみなされます。
文キャッシュでのバインドおよび定義の最適化
アプリケーションがキャッシュ内の文でバインドおよび定義操作を繰り返すのを回避するために、アプリケーションは、文キャッシュから取得した文で不透明なコンテキストを登録し、サービス・コンテキストでコールバック関数を登録できます。
バインドおよび定義バッファなどのアプリケーション・データは、不透明なコンテキストに包含することができます。このコンテキストは、最初にキャッシュから取得された文で登録されます。文が2回目以降キャッシュから取得された際には、アプリケーションはバインドおよび定義バッファを再利用でき、コンテキストはその文で登録されます。アプリケーションにはまだ、バインドおよび定義を管理する責任があります。さらに、バインドと定義両方のデータとバッファを再利用するか、データのみを変更してバッファを再利用するか、または現在のサイズが十分でない場合は、バッファを解放して再割当てできます。最後のケースでは、再バインドと再定義を行う必要があります。これらのバインドおよび定義バッファに対してアプリケーションが割り当てたメモリーをクリーンアップするには、セッションを閉じる一環として文をエージ・アウトするかまたは全キャッシュを消去する際に、コールバック関数をコールします。消去するすべての文に対してコールバック関数をコールします。コールバック関数の内部で、アプリケーションはメモリーを解放して、必要なその他のクリーンアップを実行します。例15-1に疑似コードを示します。
例15-1 キャッシュ内の文に対するバインドおよび定義操作の最適化
Get the statement using OCIStmtPrepare2(...)
Get the opaque context from the statement if it exists
If opaque context does not exist
{
Allocate fetch buffers, do the OCIBindByPos, OCIDefineByPos, and so forth
Enclose the buffer addresses inside a context and set the context and
callback function on the statement
}
Execute/Fetch using the statement, and process the data in the fetch buffers.
OCIStmtRelease() that statement
Next OCIStmtPrepare2()
OCIAttrGet() opaque application context from statement handle
Execute/Fetch using the statement and process the data in the fetch buffers.
OCIStmtRelease()
. . .
void callback_fn (context, statement, mode)
{
/* mode= OCI_CBK_STMTCACHE_STMTPURGE means this was called when statement was
aging out of the statement cache or if the session is ended */
<free the buffers in the context.>
}
ROWIDの暗黙的フェッチ
この節では、以下のトピックについて説明します。
ROWIDの暗黙的フェッチについて
ROWIDは、データベース内の行のグローバル一意識別子です。ROWIDは行が表に挿入されるときに作成され、行が削除されると破棄されます。
ROWID値には、重要な用途がいくつかあります。これは、表の各行の一意識別子です。また、1行にアクセスする場合に最も高速な手段であり、表の行の格納方法を示すことができます。
SELECT ... FOR UPDATE文におけるROWIDの暗黙的フェッチとは、ROWIDがselect文で名前付きの列のいずれかではない場合でも、クライアント側で取得されるということです。OCIDefineByPos()のpositionパラメータは0 (ゼロ)に設定されます。ROWID疑似列値を取得する場合、次のホスト変数を指定できます。
-
SQLT_CHR(VARCHAR2) -
SQLT_VCS(VARCHAR) -
SQLT_STR(NULL文字で終了する文字列) -
SQLT_LVC(LONGVARCHAR) -
SQLT_AFC(CHAR) -
SQLT_AVC(CHARZ) -
SQLT_VST(OCI文字列) -
SQLT_RDD(ROWID記述子)
SELECT ... FOR UPDATE文では、更新対象の行を識別し、結果セットの各行をロックします。これは、1行の既存の値に基づいて更新する必要がある場合に役立ちます。その場合は、別のユーザーにより行が変更されないことを確認する必要があります。
ROWIDの値を格納する文字バッファの指定時(SQLT_STR形式で取得する場合など)には、ROWIDを格納するのに十分なメモリーを割り当てます。ROWIDデータ型とUROWIDデータ型の違いを覚えておいてください。ROWIDデータ型に格納できるのは物理ROWIDのみですが、UROWID型には論理ROWID (索引構成表の行の識別子)も格納できます。ROWID型の最長内部長は10バイトですが、UROWIDデータ型の場合は3950バイトです。
動的定義は、OCI_DYNAMIC_FETCHとして設定されたmodeによるOCIDefineByPos()またはOCIDefineByPos2()のコールと等価です。動的定義を使用すると、特定の定義ハンドルの属性を追加設定できます。実行時に起動され、取得されるフェッチ済データまたはそのピースを格納するバッファへのポインタを取得する、コールバック関数を指定します。
ROWIDの暗黙的フェッチを使用する前に、文ハンドルで属性OCI_ATTR_FETCH_ROWIDを次のように設定する必要があります。
OCIAttrSet(stmthp, OCI_HTYPE_STMT, 0, 0 , OCI_ATTR_FETCH_ROWID, errhp);
動的定義は、ROWIDの暗黙的フェッチとは互換性がありません。通常のシナリオの場合、このモードのアプリケーションでは1つの列の各行にバッファを提供できます。つまり、1つの列値がフェッチされるたびにコールバックが呼び出されます。
位置0 (ゼロ)についてOCIDefineByPos()またはOCIDefineByPos2()を使用するこの機能は、データ配列を一度にユーザー・バッファにフェッチし、その各ROWIDを同時に取得することが目的です。この機能では、ROWIDがSELECTを使用した問合せの列のいずれかではなくても、SELECT....FOR UPDATE文によりROWIDのフェッチが可能です。データを1つずつユーザー・バッファにフェッチする場合は、既存のOCI_ATTR_ROWID属性を使用できます。
この機能を使用してROWIDをフェッチする場合、文ハンドルのOCI_ATTR_ROWID属性を同時に使用してROWIDを取得することはできません。特定の文ハンドルに対して一度に使用できるのは1つのみです。
ROWIDの暗黙的フェッチの例
ROWIDの暗黙的フェッチの例を示します。
例15-2のCプログラムのフラグメントを基礎として使用します。
例15-2 ROWIDの暗黙的フェッチ
#include <oci.h>
int main()
{
...
text *mySql = (text *) "SELECT emp_name FROM emp FOR UPDATE";
text rowid[100][15] = {0};
text empName[100][15] = {0};
...
/* Set up the environment, error handle, etc. */
...
/* Prepare the statement - select ... for update. */
if (OCIStmtPrepare (select_p, errhp,
mySql, strlen(mySql), OCI_NTV_SYNTAX, OCI_DEFAULT))
{
printf ("Prepare failed \n");
return (OCI_ERROR);
}
/* Set attribute for implicit fetching of ROWIDs on the statement handle. */
if (OCIAttrSet(select_p, OCI_HTYPE_STMT, 0, 0, OCI_ATTR_FETCH_ROWID, errhp))
{
printf ("Unable to set the attribute - OCI_ATTR_FETCH_ROWID \n");
return OCI_ERROR;
}
/*
* Define the positions: 0 for getting ROWIDs and other positions
* to fetch other columns.
* Also, get the define conversion done implicitly by fetching
* the ROWIDs in the string format.
*/
if (OCIDefineByPos ( select_p,
&defnp0,
errhp,
0,
rowid[0],
15,
SQLT_STR,
(void *) ind,
(void *) 0,
(void *) 0,
OCI_DEFAULT) ||
OCIDefineByPos(select_p,
&defnp1,
errhp,
1,
empName[0],
15,
SQLT_STR,
(void *) 0,
(void *) 0,
(void *) 0,
OCI_DEFAULT)
)
{
printf ("Failed to define\n");
return (OCI_ERROR);
}
/* Execute the statement. */
if (errr = OCIStmtExecute(svchp,
select_p,
errhp,
(ub4) 5,
(ub4) 0,
(OCISnapshot *) NULL,
(OCISnapshot *) NULL,
(ub4) OCI_DEFAULT))
{
if (errr != OCI_NO_DATA)
return errr;
}
printf ("Column 0 \t Column 1\n");
printf ("_________ \t ________\n");
for (i =0 ;i<5 i++)
{
printf("%s \t %s \n", rowid[i], empName[i]);
}
return OCI_SUCCESS;
}
暗黙的な結果のOCIサポート
Oracle Database 12cリリース1 (12.1)より、PL/SQLで、ストアド・プロシージャおよび無名PL/SQLブロックから暗黙的に結果(カーソル)を戻すことができるようになりました。OCIStmtGetNextResult()は、暗黙的な結果を取り出し、処理するために提供されています。
例15-3に示すように、PL/SQLはDBMS_SQLパッケージでサブプログラムRETURN_RESULTを指定し、実行された文の結果を戻します。現行のリリースでは、SELECT問合せの結果セットのみ、PL/SQLブロックによって暗黙的に戻すことができます。OCIStmtGetNextResult()は、通常のOCIの定義およびフェッチ・コールを実行して行が取り出されるOCI文ハンドルを戻します。
例15-4は、暗黙的に結果セット(カーソル)をクライアントに戻すPL/SQLストアド・プロシージャを示しています。
例15-5は、クライアントによって送信される無名PL/SQLブロックを使用した同じアプローチを示しています。この例では、アプリケーションで暗黙的な結果機能を使用して、OCIアプリケーションからのSQL文のバッチを実装する方法を示しています。OCIアプリケーションでは、PL/SQL無名ブロックを動的に形成して、複数で可変のSELECT文を実行し、DBMS_SQL.RETURN_RESULTを使用して対応するカーソルを戻すことができます。
例15-6は、OCIStmtGetNextResult()コールを使用してPL/SQLストアド・プロシージャ(例15-4を参照)または無名PL/SQLブロック(例15-5を参照)で戻される暗黙的な結果を取り出し、処理する方法を示すOCIプログラムです。
OCIStmtGetNextResult()は、アプリケーションによって反復的にコールされ、実行されたPL/SQL文からの個別の暗黙的な結果を取り出すことができます。アプリケーションでは各結果セットが順次取り出されますが、任意の結果セットから別個に行をフェッチできます。トップレベルのOCI文ハンドルでは、関連付けられているすべての結果セット文ハンドルが追跡されます。トップレベルのOCI文ハンドルを解放すると、すべての暗黙的な結果セットが自動的に閉じられ、解放されます。
属性OCI_ATTR_IMPLICIT_RESULT_COUNTは、使用可能な暗黙的な結果の数を判断するためにOCI文ハンドルに提供されています。
OCIStmtGetNextResult()のrtypeパラメータは、結果の型を戻します。このリリースでは、型OCI_RESULT_TYPE_SELECTのみがサポートされています。SELECTのResultSetと同様、戻される結果セットの記述メタデータはアクセス可能になります。
ノート:
暗黙的な結果をフェッチするために、次のOCIコードを外部プロシージャで使用することもできます。その場合、OCI_PREP2_IMPL_RESULTS_CLIENTは、モードとしてOCIStmtPrepare2() コールに渡す必要があります。
例15-3 DBMS_SQL RETURN_RESULTサブプログラム
procedure return_result(rc in out sys_refcursor,
to_client in boolean default true);
procedure return_result(rc in out integer,
to_client in boolean default true);
例15-4 結果セット(カーソル)をクライアントに暗黙的に戻すためのPL/SQLストアド・プロシージャ
CREATE PROCEDURE foo AS c1 sys_refcursor; c2 sys_refcursor; begin open c1 for select * from emp; dbms_sql.return_result(c1); --return to client -- open 1 more cursor open c2 for select * from dept; dbms_sql.return_result (c2); --return to client end;
例15-5 結果セット(カーソル)をクライアントに暗黙的に戻すための無名PL/SQLブロック
declare c1 sys_refcursor; c2 sys_refcursor; begin open c1 for select * from emp; dbms_sql.return_result (c1); --return to client -- open 1 more cursor open c2 for select * from dept; dbms_sql.return_result (c2); --return to client end;
例15-6 PL/SQLストアド・プロシージャまたは無名ブロックのいずれかによって戻された暗黙的な結果を取り出し、処理するOCIStmtGetNextResult()の使用方法
OCIStmt *stmthp;
ub4 rsetcnt;
void *result;
ub4 rtype;
char *sql = "begin foo; end;";
/* Prepare and execute the PL/SQL procedure. */
OCIStmtPrepare2(svchp, &stmthp, errhp, (oratext *)sql, strlen(sql),
NULL, 0, OCI_NTV_SYNTAX, OCI_DEFAULT);
OCIStmtExecute(svchp, stmthp, errhp, 1, 0,
(const OCISnapshot *)0,
(OCISnapshot *)0, OCI_DEFAULT);
/* Now check if any implicit results are available. */
OCIAttrGet((void *)stmthp, OCI_HTYPE_STMT, &rsetcnt, 0,
OCI_ATTR_IMPLICIT_RESULT_COUNT, errhp);
/* Loop and retrieve the implicit result-sets.
* ResultSets are returned in the same order as in the PL/SQL
* procedure/block.
*/
while (OCIStmtGetNextResult(stmthp, errhp, &result, &rtype,
OCI_DEFAULT) == OCI_SUCCESS)
{
/* Check the type of implicit ResultSet, currently
* only supported type is OCI_RESULT_TYPE_SELECT
*/
if (rtype == OCI_RESULT_TYPE_SELECT)
{
OCIStmt *rsethp = (OCIStmt *)result;
/* Perform normal OCI actions to define and fetch rows. */
}
else
printf("unknown result type %d\n", rtype);
/* The result set handle should not be freed by the user. */
}
OCIStmtRelease(stmthp, errhp, NULL, 0, OCI_DEFAULT); /* Releases the statement handle. */
関連項目:
-
属性
OCI_ATTR_IMPLICIT_RESULT_COUNTの詳細は、「文ハンドル属性」を参照してください。
クライアント結果キャッシュ
OCIアプリケーションでは、OCI結果キャッシュを活用するクライアント・メモリーを使用して、繰り返される問合せの応答時間を短縮できます。
関連項目:
OCIクライアント結果キャッシュの使用の詳細は、『Oracle Database開発ガイド』を参照してください
クライアント文キャッシュ自動チューニング
クライアント文キャッシュ自動チューニングに関するトピックについて説明します。
クライアント文キャッシュ自動チューニングについて
自動チューニングにより、中間層アプリケーションのOCIクライアント・セッション機能を最適化でき、OCIアプリケーションの再プログラムを必要とすることなく、パフォーマンスを向上できます。
キャッシュ・メモリーの増減などの自動チューニング操作は、定期的なOCIStmtPrepare2()およびOCIStmtRelease()のコール中、暗黙的に行われます。キャッシュ・サイズのチェックが必要な場合は、OCIAttrGet()をサービス・ハンドルにOCI_ATTR_STMTCACHESIZEを設定してコールすると、使用されている現在のキャッシュ・サイズが取得されます。
コーディングされたOCIクライアントの文キャッシュ・サイズ設定が最適ではなくなることもあります。たとえば、これはSQL文の別のワーキング・セットを発生させる原因となるワークロードの変更に伴い発生することがあります。サイズが小さすぎると、ネットワーク・アクティビティが過剰になり、サーバーでの解析量が増大します。サイズが大きすぎると、使用されるメモリー量が超過します。クライアント側のアプリケーションが、このキャッシュ・サイズを常に最適に維持することは困難です。
自動チューニングにより、OCIの文キャッシュ・サイズが定期的に自動で再構成されます。自動チューニングは、この潜在的なパフォーマンス問題を解決するためにOCI文キャッシュを再構成するオプションを提供するデプロイメント時間設定を指定することで行われます。
これらの設定は、OCI機能のユーザー構成の手動設定をオーバーライドするクライアントのoraaccess.xmlファイル内の接続文字列ベースのデプロイメント設定として提供されています。
クライアント文キャッシュ自動チューニングの利点
自動チューニング文キャッシュのさらに具体的な利点は、文キャッシュ・サイズを透過的に検出、監視および調整して、パフォーマンスを向上またはメモリー使用量を減少させることです。
開発者およびDBAが、OCIクライアント・アプリケーションに自動チューニングを使用するには次の利点があります。
-
文キャッシュなど、システムの各部分のパフォーマンスの問題を診断および修正するのに必要な時間や労力を減らします
-
パフォーマンスを向上するためにこのOCI機能の構成に必要な手動変更を最小化します。通常、このような手動変更では異なる構成パラメータでアプリケーションを1回以上再起動する必要があるため、クライアントの高可用性がさらに低下することになります。
-
すべてのOCIアプリケーションに対し、アプリケーションを変更せずにすぐにそのままパフォーマンスを向上するための1つの解決策となります
-
OCIアプリケーションをカスタム実装する(エラーを発生させる可能性がある)必要がなく、OCIアプリケーションを自動チューニングしてパフォーマンスおよびメモリー使用量を最適化できます。この場合、自動チューニングは、OCIクライアント側文キャッシュ・サイズの内部自動チューニングのみに制限されます。
クライアント文キャッシュ自動チューニングのパラメータ
次に示すoraccess.xml内の接続に特有のパラメータは、デフォルトの接続に特有のパラメータを使用して、構成別名ごとに、またはすべての接続文字列全体に対して設定できます。
クライアントのoraaccess.xml構成ファイルで指定する値は、プログラム設定をオーバーライドします。
関連項目:
デフォルトの接続に特有のパラメータを使用して、構成別名ごとに、またはすべての接続文字列全体に対して設定する方法の詳細は、「接続パラメータのデフォルトの指定について」を参照してください
<statement_cache>
このパラメータはオプションで、文キャッシュ・チューニング可能コンポーネントの制限を設定します。
<statement_cache> <size>100</size> </statement_cache>
この制限は、セッションごとにキャッシュ可能な文の最大数です。自動チューニングが有効かどうかに関係なく、oraaccess.xml内のこの設定は、OCI文キャッシュ・サイズのプログラム設定をオーバーライドします。
自動チューニングが有効な場合、この設定は文キャッシュ・サイズの上限値となり、動的にチューニングされます。
セッションで、OCIStmtPrepare2()およびOCIStmtRelease()における文キャッシュAPIを使用していない場合、この設定は無視されます。
デフォルト値は次のとおりです。
-
自動チューニングが有効な場合、文キャッシュは動的にチューニングされ、初期の文キャッシュ・サイズは100文に設定されます。
-
自動チューニングが無効な場合、この設定は、文キャッシュ・サイズのデプロイメント設定として機能し、プログラム設定をオーバーライドします。
<auto_tune>
このセクションでは、自動チューニングのパラメータを指定します。
OCIセッションで、OCIStmtPrepare2()またはOCIStmtRelease()における文キャッシュAPIを使用していない場合、そのセッションでは自動チューニングのパラメータは無視されます。一部のセッションまたは接続においては自動チューニングが有効で、別のセッションまたは接続においては無効であるようなプロセスでも有効です。
<enable>true</enable>
このパラメータは、自動チューニングをオンまたはオフにします。
デフォルトでは、自動チューニングはオフ(FALSE)または無効です。
<auto_tune> <enable>true</enable> </auto_tune>
自動チューニングは、内部のデフォルト設定とともに有効になります。
関連項目:
内部のデフォルト設定とともに有効化される自動チューニングの詳細は、「<statement_cache>」を参照してください。
<ram_threshold>
このパラメータは省略可能です。
<auto_tune> <enable>true</enable> <ram_threshold>0.1</ram_threshold> </auto_tune>
デフォルト値は0.01%です。搭載されているRAMに対するパーセンテージとして指定します。この設定を共有するプロセスの自動チューニング・セッション間で使用可能な合計メモリーを指定します。この設定は、プロセスごとまたは接続文字列別名ごとに指定できます。
接続文字列別名ごとに指定すると、クライアント・プロセスで使用される自動チューニングの合計メモリーが増大します。
このため、oraaccess.xmlファイルの<default_parameters>セクションで自動チューニングの制限値を指定することをお薦めします。これにより、クライアント・プロセスのすべてのセッションに対して共通のメモリー・プールを確保します。
自動チューニングで制限値を小さくすると使用されるRAMも減少しますが、システムで実行されている他のプログラムのパフォーマンスが低下する可能性が増大します。
このパラメータは、<auto_tune></auto_tune>デプロイメント設定内で指定する必要があります。
関連項目:
<memory_target>
このパラメータは省略可能です。
<auto_tune> <enable>true</enable> <memory_target>40M</memory_target> </auto_tune>
バイト単位で指定します。デフォルトでは未定義です。この設定を共有するプロセスの自動チューニング・セッション間で使用可能な合計メモリーを指定します。この設定は、プロセスごとまたは接続文字列別名ごとに指定できます。
接続文字列別名ごとに指定すると、クライアント・プロセスで使用される自動チューニングの合計メモリーが増大します。
このため、oraaccess.xmlファイルの<default_parameters>セクションで自動チューニングの制限値を指定することをお薦めします。これにより、クライアント・プロセスのすべてのセッションに対して共通のメモリー・プールを確保します。
このパラメータは、<auto_tune></auto_tune>デプロイメント設定内で指定する必要があります。
このパラメータを使用すると、システムに搭載されているRAMに関係なく、自動チューニングにおいて一定量の制限値メモリーが使用されます。
指定していない場合、自動チューニングのメモリーの制限値は、<ram_threshold>パラメータ設定に基づいて決定されます。
<ram_threshold>と<memory_target>の両方のパラメータを指定すると、2つのパラメータのうち小さい方が制限値として有効になります。
関連項目:
接続に特有の自動チューニング・パラメータの比較
すべての自動チューニング・パラメータの比較について説明します。
表15-1は、接続に特有の自動チューニング・パラメータの比較を示しています。
表15-1 接続に特有の自動チューニング・パラメータの比較
| パラメータ | 設定とセマンティクス | 自動チューニングまたはデプロイメント設定について |
|---|---|---|
|
|
オプションの設定です。 セッションごとのキャッシュ・サイズです。 |
自動チューニングが有効な場合(「OCIクライアント自動チューニングの有効化または無効化」を参照)、これは各セッションにおける文キャッシュ・サイズの上限値となり、自動チューニングによりチューニングされます。 それ以外の場合は、文キャッシュのデプロイメント設定を参照します。 |
|
|
オプションの設定です。 自動チューニングを使用するには、このパラメータを指定します。NULLの接続文字列を指定する場合、この接続文字列を使用するすべての接続、またはすべての接続に適用されます。 |
自動チューニング関連のみです |
|
|
オプションの設定です。 クライアントまたは中間層システムに搭載されているRAMに基づいて、パーセンテージ設定をメモリー値に変換します。 これは、クライアント・プロセス内の自動チューニングで使用されるメモリーの上限値です。 搭載されているRAMが8GBの場合、このパラメータを指定しないと、セッション間で800KBのメモリーが割り当てられます。 各接続で自動チューニングのパラメータを独自に設定している可能性があるため、これらの値は構成設定に基づいて全プロセスで増大することがあります。このため、 |
自動チューニング関連のみです。自動チューニングが無効な場合、このパラメータ設定は無視されます。このパラメータは、 |
|
|
オプションの設定です。 これは、クライアント・プロセス内の自動チューニングで使用されるメモリーの上限値です。 各接続で自動チューニングのパラメータを独自に設定している可能性があるため、これらの値は構成設定に基づいて全プロセスで増大することがあります。このため、 構文の説明は、「ファイル(oraaccess.xml)のプロパティ」を参照してください。 値はバイト単位です。1,048,576バイトが1MBです。 |
自動チューニング関連のみです。自動チューニングが無効な場合、このパラメータ設定は無視されます。このパラメータは、 |
クライアント文キャッシュ自動チューニングの使用例
次は、接続に特有のパラメータでもある、クライアント文キャッシュの自動チューニング・パラメータの使用方法と対話を示す使用例です。
<statement_cache> <size>100</size> </statement_cache>
プログラムの文キャッシュ・サイズはこの設定で置換されます。自動チューニングは無効になり、キャッシュはLRUごとに管理されます。この場合、アプリケーションの開発者はOCIアプリケーションの文プリフェッチのプログラム設定をオーバーライドする必要がないとみなしています。
<auto_tune> <enable>true</enable> </auto_tune>
自動チューニングは、内部のデフォルト設定とともに有効になります。
<statement_cache> <size>100</size> </statement_cache> <auto_tune> <enable>true</enable> <memory_target>40M</memory_target> </auto_tune>
100に設定したこの文キャッシュのデプロイメント設定によってプログラムの文キャッシュ・サイズは置換され、また、自動チューニングが有効なため、文キャッシュは自動チューニングされます。メモリーのターゲット設定は、自動チューニングが有効なために有効になります。
自動チューニングでは、メモリー・ターゲット周辺で使用される合計文キャッシュ・メモリーを常に制限しようと試みます。メモリー・ターゲットが指定されていない場合は、搭載されている合計RAMのパーセンテージに基づいて決定されます。
この場合、メモリーの制限値は指定したメモリー・ターゲット値です。
関連項目:
内部のデフォルト設定とともに有効化される自動チューニングの詳細は、「<statement_cache>」を参照してください。
OCIクライアント自動チューニングの有効化または無効化
OCIクライアントの自動チューニングを有効化または無効化する条件について説明します。
次の条件によって、OCIクライアントの自動チューニングが有効化または無効化されます。
-
自動チューニングは、クライアントの
oraaccess.xmlに<auto_tune>セクションを追加し、TRUE (<enable>true</enable>)に指定した場合に有効になります。 -
自動チューニングはデフォルトで、または
oraaccess.xmlの<auto_tune>セクションでFALSE (<enable>false</enable>)に設定した場合に無効になります。
クライアント文キャッシュの自動チューニング使用のガイドライン
自動チューニング・パラメータを設定する際に使用するガイドラインについて説明します。
次は、自動チューニング・パラメータを設定する際に使用するガイドラインの一部です。
-
クライアントの応答、メモリー割当てまたはクライアントのCPUのいずれかが高く、OCIアプリケーションを再構築せずにパフォーマンスを向上させたい場合、
<auto_tune>設定またはデプロイメント<statement_cache>設定を使用できます。また、自動チューニングにより、クライアントとサーバーの間で転送されるネットワーク・バイト数が減少する場合もあります。 -
AWRまたはADDMで大量の解析がレポートされ、文キャッシュ・サイズをプログラムで変更できないか、または変更したくない場合、文キャッシュの自動チューニングを指定するか、あるいはデプロイメント文キャッシュ設定の
<statement_cache>を使用できます。