| Oracle® TimesTen Application-Tier Database Cacheユーザーズ・ガイド リリース18.1 E98634-04 |
|
 前 |
 次 |
次の各項では、キャッシュ・パフォーマンスに関して説明します。
|
ノート: 自動リフレッシュ処理の監視および自動リフレッシュ・パフォーマンスの向上の詳細は、Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドを参照してください。自動リフレッシュ・キャッシュ・グループの監視に関する説明および自動リフレッシュのパフォーマンスが悪い場合に関する説明を参照してください。 AWTキャッシュ・グループのパフォーマンスの詳細は、Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドのAWTのパフォーマンスの監視およびAWTのパフォーマンスが悪い場合に考えられる原因を参照してください。 |
ルート表の主キー検索に基づいた動的ロードの方が、子表に対する主キー検索または子表に対する外部キー検索よりも、パフォーマンスが速くなります。詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。
動的ロード処理と自動リフレッシュ処理を組み合せた場合、競合が発生する可能性があります。この状況でパフォーマンスを改善する方法の詳細は、「自動リフレッシュ処理のパフォーマンスの向上」を参照してください。
また、動的ロード処理用に新しい接続を開く際に、パフォーマンス・コストが発生する可能性があります。接続プールを作成して新しい接続を開くコストを削減する方法の詳細は、「動的ロード・リクエストのためのOracleデータベースへのキャッシュ接続プールの管理」を参照してください。
適格なSELECT文が動的な読取り専用キャッシュ表で発行され、そのデータがTimesTenキャッシュ表に存在しない(が、基本となるOracleデータベース表には存在する)場合、キャッシュ・ミスが発生します。その後、TimesTenは動的なロードを実行してOracleデータベースから(Oracleデータベースへの既存の接続または新しい接続を介して)データを取得し、行をキャッシュ・グループに挿入します。動的ロード用に新しい接続を開く際に、パフォーマンス・コストが発生する可能性があります。
デフォルトでは、TimesTenへのアプリケーション接続が閉じるまで、Oracleデータベースへの接続は開いたままです。アプリケーションで動的ロードが開始されると、各クライアント接続はOracleデータベースへの接続に関連付けられます(TimesTen Cacheを使用する場合)。複数の接続を使用する場合、Oracleデータベースへの新しい接続に対するTimesTenのリクエスト数が、Oracleデータベースに対して許可されている最大接続数を超える可能性があります。
Oracleデータベースに対する動的ロード要求をアプリケーションが複数持つ場合がありますが、その場合、バックエンドのOracleデータベースに対して開かれる接続が多くなりすぎる可能性があります。ただし、サーバーごとに複数の接続を持つクライアント/サーバー・アプリケーションの場合は、Oracleデータベースへのすべての接続にキャッシュ接続プールを使用するようにTimesTenを構成できます。プールされた接続はすべてのクライアント/サーバー接続間で共有されるため、キャッシュ接続プールを利用できるのは、クライアント/サーバー接続を使用するアプリケーションのみです。
動的ロード要求では、(新規接続を作成するのではなく)キャッシュ接続プールからOracleデータベースへの既存の接続を使用して、オープン接続の合計数を減らします。動的ロード要求が完了したら、接続はキャッシュ接続プールに戻されます。
キャッシュ接続プールから既存の接続を使用すると、次のようにアプリケーションのパフォーマンスが向上します。
新しくリクエストした接続ごとに専用のOracleサーバー・プロセス(またはスレッド)を開始するコストを削減します。
各プロセス(スレッド)を単一の接続専用にするのではなく、接続間で共有することにより、Oracleサーバー・プロセス(スレッド)の合計数を減らします。
接続間のセッション・レベルのサーバー・リソース(メモリーなど)の共有を有効にします。
接続がキャッシュ接続プールに戻されると、アプリケーションは接続が論理的に切断されている状態と認識します。したがって、アプリケーションにパススルー文(Oracleデータベースで実行されるDDLまたはDML文)が含まれる場合、動的ロードをリクエストするかエラーがスローされる前に、パススルー文をコミットまたはロールバックする必要があります。自動コミットをONに設定するか、動的ロードの前にトランザクション内でコミットまたはロールバックを明示的に実行できます。
|
ノート: アプリケーションで実行される動的ロード・リクエストの数が通常より多く、パフォーマンスが重要な場合は、次のいずれかを考慮できます。
|
キャッシュ接続プールを使用するかどうかを判断するには、アプリケーションがOracleデータベースから大量のデータの動的ロード・リクエストをリクエストした(そのためOracleデータベースへのオープン接続が多すぎる)かどうかを評価します。
次の各項では、動的な読取り専用キャッシュ・グループ用のキャッシュ接続プールの使用方法を説明します。
TimesTenの起動時にTimesTenサーバー上にキャッシュ接続プールを作成するように指定できます。すべてのTimesTenサーバーが、Oracleデータベースに格納されているパラメータを共有します。
クライアント/サーバー接続から動的ロード・リクエストを行うと、キャッシュ接続プールからの接続が取得され、動的ロードが実行され、動的ロード・リクエストの完了時に接続がキャッシュ接続プールに戻されます。TimesTenサーバーが停止すると、キャッシュ接続プールが破棄されます。
|
ノート: キャッシュ接続プールは、クライアント/サーバー・アプリケーションからのみ開始でき、動的な読取り専用キャッシュ・グループ用に開始された動的ロードにのみ使用されます。 |
クライアント/サーバー接続リクエストでキャッシュ接続プールを使用できるようにするには、アプリケーションで接続時に次の接続属性を指定する必要があります。
MaxConnsPerServer接続属性: キャッシュ接続プールを使用するには、値を1より大きい値に設定する必要があります。
この接続属性が1より大きい場合、TimesTenサーバーは、処理を作成して(マルチスレッド・モードで)複数のTimesTen子サーバー・プロセスに割り当てることができます。この接続属性は、子サーバー・プロセスごとに接続プールで作成できるクライアント接続の最大数を設定します。
ServersPerDSN接続属性: 値は、TimesTenサーバー用に生成する子サーバー・プロセスの数を指定します。デフォルトは1です。
それぞれの新規着信接続により、ServersPerDSN接続属性で指定された値まで、新しい子サーバー・プロセスが生成されます。子サーバー・プロセスの最大数に到達すると、既存の子サーバー・プロセスは、ラウンドロビン方式で複数の接続を(MaxConnsPerServerに指定された数まで)処理します。つまり、ServersPerDSNを2に、MaxConnsPerServerを3に指定すると、最初の2つの接続によって2つの子サーバー・プロセスが生成されます。3番目から6番目までの接続がこれらの子サーバー・プロセスによって処理され、各子サーバー・プロセスが他の接続をそれぞれ処理します。
すべての子サーバー・プロセスの接続が最大許容数に達すると、次の受信接続で新しい子サーバー・プロセスのセットを開始します。
ServersPerDSNおよびMaxConnsPerServer接続属性は、複数の子サーバー・プロセスに接続を分散する方法を指定するために使用します。
UseCacheConnPool接続属性: キャッシュ接続プールを使用可能にする場合は、値を2に設定します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のUseCacheConnPoolに関する項を参照してください。
動的ロードが異なるタイプの接続から開始される場合に予想される動作を次に示します。
直接接続: キャッシュ接続プールは使用されません。動的ロードは、既存の動作を使用して実行します。
シングル・スレッドのクライアント/サーバー接続(MaxConnsPerServer=1の場合): キャッシュ接続プールは使用されません。動的ロードは、既存の動作を使用して実行します。
マルチスレッド・クライアント/サーバー接続(MaxConnsPerServer>1の場合): 作成時に、動的ロードにキャッシュ接続プールを使用します。それ以外の場合は、エラーが返されます。
接続の接続属性は、DSN定義または接続文字列で設定できます。
例7-1 DSN定義でのキャッシュ接続プールの接続属性の指定
sys.odbc.iniファイルのcache1 DSN定義では、UseCacheConnPool=2、ServersPerDSN=2およびMaxConnsPerServer=3を指定します。
[cache1] DataStore=/users/OracleCache/database1 PermSize=64 OracleNetServiceName=oracledb DatabaseCharacterSet=AL32UTF8 UseCacheConnPool=2 ServersPerDSN=2 MaxConnsPerServer=3
例7-2 接続文字列でのキャッシュ接続プールの接続属性の指定
または、アプリケーションから接続するときに、両方の接続属性をコマンドラインで指定することもできます。
ttIsql "DSN=cache1; OracleNetServiceName=oracledb; UseCacheConnPool=2; ServersPerDSN=2; MaxConnsPerServer=3"
|
ノート: 詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのMaxConnsPerServer、ServersPerDSNおよびUseCacheConnPoolを参照してください。 |
キャッシュ接続プールのサイズを適切に設定すると、ttCacheConnPoolSet組込みプロシージャを使用した接続との競合を回避できます。ttCacheConnPoolSet組込みプロシージャは、これらのパラメータの値をOracleデータベースに保存します。これらの値は、TimesTenサーバーを再起動するときにデフォルト値として使用されます。
|
ノート: サイズ変更を動的に行う場合は、ttCacheConnPoolApply組込みプロシージャを実行することによって各TimesTenサーバーに変更を適用できます。ttCacheConnPoolApply組込みプロシージャの詳細は、「現在実行中のデータベースに対するキャッシュ接続プールのサイズの適用」を参照してください。 |
各TimesTenサーバーに適用されると、TimesTenデータベースのすべてのクライアント/サーバー・アプリケーションにわたるキャッシュ接続プールに指定された値が使用されます。
ttCacheConnPoolSet組込みプロシージャは、直接接続、シングル・スレッドのクライアント/サーバー接続またはマルチスレッドのクライアント/サーバー接続から実行できます。
|
ノート: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConnPoolSetに関する項を参照してください。 |
たとえば、次の例では、起動時にプールされる接続の最小数が10、最大数が32、増分が1になります。クライアントによる最大アイドル時間は10秒に設定されます。また、すべての動的ロード処理は、キャッシュ接続プールからの接続が使用可能になるまで待機します。
Command> call ttCacheConnPoolSet(10, 32, 1, 10, 0);
キャッシュ接続プールの最小サイズと最大サイズを、必要なときに接続が使用可能なレベルに設定します。プール内に使用可能な接続がない場合、TimesTenは、ttCacheConnPoolSet組込みプロシージャのConnNoWaitパラメータの設定に応じて、次を実行します。
ConnNoWait=0: プールからの接続が使用可能になるか、タイムアウトが発生するまで、TimesTenは停止します。Oracleデータベースが停止している場合、アプリケーションはOracleデータベースが再起動されるか、タイムアウトが発生するまで待機します。
Oracleデータベースへの接続がタイムアウトになると、接続の切断を示すエラーを受け取ります。TimesTenでロールバックが必要になる場合があります。
ConnNoWait=1: キャッシュ接続プールに使用可能な接続がない場合、動的ロード処理はエラーで失敗します。
ttCacheConnPoolGet組込みプロシージャを使用して、キャッシュ接続プールのパラメータが何であるかを問い合せることができます。
この組込みプロシージャの使用方法の完全な例は、「キャッシュ接続プールの管理の例」を参照してください。
クライアント/サーバー環境では、TimesTenは複数のTimesTen子サーバー・プロセスを使用してクライアントからの着信リクエストを処理できます。特定のキャッシュ接続プール組込みプロシージャの特定の子サーバー・プロセスを識別するには、ChildServer接続属性を指定します。各子サーバー・プロセスは、ChildServer=n接続属性で割り当てられた数字により識別されます。ここで、nは、1から実行中の子サーバー・プロセスの数までの範囲です。子サーバー・プロセスに接続したら、特定の子サーバー・プロセス用のttCacheConnPoolGet('current')またはttCacheConnPoolApply組込みプロシージャを実行できます。
この接続属性を必要とする組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConnPoolApplyおよびttCacheConnPoolGetに関する項を参照してください。この説明属性の使用方法の例は、「キャッシュ接続プールの管理の例」を参照してください。
キャッシュ接続プールのパラメータはOracleデータベースに保存されるため、これらのパラメータは、TimesTenサーバーが再起動するたびに、TimesTenデータベースのキャッシュ接続プールを初期化するために使用されます。
ただし、データベースがすでに実行されているときにキャッシュ接続パラメータを設定する場合、ttCacheConnPoolApply組込みプロシージャを使用して各子サーバー・プロセスのキャッシュ接続プール・パラメータを動的にサイズ変更できます。この後、キャッシュ接続プール・パラメータが子サーバー・プロセスに関連付けられます。
たとえば、次の場合、1として識別された子サーバー・プロセスに接続し、保存されたキャッシュ接続プール構成をこの子サーバー・プロセスに適用します。子サーバー・プロセス2に対しても同じプロセスを実行します(ServersPerDSNが2の場合)。
Command> connect "DSN=cache1;ChildServer=1;"; Command> call ttCacheConnPoolApply; Command> disconnect; Command> connect "DSN=cache1;ChildServer=2;"; Command> call ttCacheConnPoolApply; Command> disconnect;
ttCacheConnPoolApply組込みプロシージャは、マルチスレッドのクライアント/サーバー接続からのみ実行できます。
キャッシュ接続プールに障害が発生した場合は、任意の子サーバー・プロセスからttCacheConnPoolApply組込みプロシージャを実行してプールを再作成できます。
この組込みプロシージャの使用方法の完全な例は、「キャッシュ接続プールの管理の例」を参照してください。
例7-1に示すようにキャッシュ接続プールを有効にするcache1 DSNを使用して、「キャッシュ管理ユーザーの名前およびパスワードの設定」の説明に従ってキャッシュ管理者とパスワードを設定したことを前提として、次の例では、キャッシュ接続プールの新しい値を設定し、2つの別々の子サーバー・プロセスにこれらを適用します。
/* Since ServerPerDSN is set to two and MaxConnsPerServer is set to 3, the first
and second connections spawn off both child server processes. And then you can
create four more connections to reach the MaxConnsPerServer maximum, which are
routed by the TimesTen server to the appropriate child server process (using a
round robin method).*/
Command> connect "DSN=cache1;" as conn1;
Command> connect "DSN=cache1;" as conn2;
Command> connect "DSN=cache1;" as conn3;
Command> connect "DSN=cache1;" as conn4;
Command> connect "DSN=cache1;" as conn5;
Command> connect "DSN=cache1;" as conn6;
Command> use conn1;
/* Query the values for the cache connection pool that are saved on the Oracle database*/
Command> call ttCacheConnPoolGet('saved');
< 1, 10, 1, 10, 0, -1, -1, -1>
/* Change the configuration of the cache connection pool */
Command> call ttCacheConnPoolSet(1, 20, 1, 10, 0);
/* Query existing values for cache connection pool saved on the Oracle data base.
Since these are the saved values, this returns -1 for OpenCount, BusyCount
and LastOraErr. */
Command> call ttCacheConnPoolGet('saved');
< 1, 20, 1, 10, 0, -1, -1, -1 >
/* Query existing values for the current cache connection pool on this TimesTen database */
Command> call ttCacheConnPoolGet('current');
< 1, 10, 1, 10, 0, 1, 0, 0 >
/* Connect to the child server process 1 using the ChildServer=1 connection
attribute. Apply the saved values as the current values to the cache connection
pool for child server process identified as ChildServer 1. */
Command> connect "DSN=cache1;ChildServer=1;";
Command> call ttCacheConnPoolApply;
Command> disconnect;
/* Connect to the child server process 1 using the ChildServer=1 connection
attribute. Apply the saved values as the current values to the cache connection
pool for child server process identified as ChildServer 2. */
Command> connect "DSN=cache1;ChildServer=2;";
Command> call ttCacheConnPoolApply;
Command> disconnect;
/* Query values for the cache connection pool in ChildServer 1 */
Command> use conn1;
Command> call ttCacheConnPoolGet('current');
< 1, 20, 1, 10, 0, 1, 0, 0 >
/* Query values for the cache connection pool in ChildServer 2 */
Command> use conn2;
Command> call ttCacheConnPoolGet('current');
< 1, 20, 1, 10, 0, 1, 0, 0 >
Oracleデータベースへの接続数を確実に制限しながら、パフォーマンスをチューニングできます。合計接続数のチューニングは、次によって異なります。
N: Oracleデータベースへの接続数。
P: 各キャッシュ接続プールの接続数に対する制限。各TimesTen子サーバー・プロセスには、キャッシュ接続プールがあり、これは、ttCacheConnPoolSet組込みプロシージャのMaxSizeキャッシュ接続プール・パラメータを使用して設定できます。
S: 新しい接続に対して生成可能な子サーバー・プロセスの数。現在、子サーバー・プロセスの数を制限する直接的な方法はありません。間接的に、次の式に示すように、MaxSizeパラメータ、MaxConnsPerServer接続属性およびConnections接続属性を設定することによって、子サーバー・プロセスの数を制限できます。
M: 子サーバー・プロセスごとの接続の最大数で、MaxConnsPerServer接続属性を使用して設定できます。
D: DSNへの接続の最大数で、Connections接続属性を使用して設定されます。
Oracleデータベースへの接続の数(N)は、TimesTenの子サーバー・プロセスの数(S)に各キャッシュ接続プールの接続数(M)を掛けた値と等しくなります。
N=S*P
一方、DSNへの接続の最大数(D)は、各子サーバー・プロセスの接続の最大数(M)にTimesTen子サーバー・プロセスの数(S)を掛けた値と等しくなります。
D=M*S
前述の計算は、次のように表すこともできます。
S=D/M
TimesTen子サーバー・プロセスの数には強い制限がないため、これら2つの等式を結合してSを消去して次の等式を得ます。
N=(D*P)/M
このため、Oracleデータベースへの接続数は、(Connections接続属性によって設定される) DSNへの最大接続数に(MaxSizeキャッシュ接続プール・パラメータによって設定される)各キャッシュ接続プールへの接続数を掛けた値を(MaxConnsPerServer接続属性によって設定される)各子サーバー・プロセスの最大接続数で割った値に設定されます。
次の方法を使用して、AWTキャッシュ・グループのスループットを向上させます。
AWTキャッシュ・グループのスループットを向上させるために、パラレル動作でトランザクションの変更をOracle Databaseに伝播および適用する複数のスレッドを構成できます。パラレル伝播では、トランザクションの依存性に従って、AWTキャッシュ表の変更をコミット順にOracle Database表に適用します。詳細は、「Oracle Database表へのパラレル伝播の構成」を参照してください。
CacheAWTMethod接続属性の設定により、Oracleデータベースに変更を適用するときに、非同期のライトスルー伝播に対してPL/SQL実行メソッドとSQL配列実行メソッドのどちらを使用するかが決まります。
PL/SQL実行メソッド: AWTでは、すべての保留中の処理を単一のPL/SQLコレクションにまとめ、Oracle Databaseサーバーに送信して実行します。この実行メソッドは、TimesTenとOracle Databaseサーバー間で混合トランザクションおよびネットワーク待機時間が存在する場合に適しています。これは、ワークロードが同じ表または異なる表に対してINSERT、UPDATEおよびDELETE文を混在させて構成されている場合、ほとんどのユースケースで効率的です。デフォルトでは、TimesTenはPL/SQL実行メソッド(CacheAWTMethod=1)を使用します。
SQL配列実行メソッド: 変更が同じ表に対する同じ処理(INSERT、UPDATEまたはDELETE)のほぼ繰り返しのシーケンスで構成されている場合は、CacheAWTMethodを0に変更することを検討してください。たとえば、表の複数の行に影響する更新をユーザーが行う場合、SQL配列実行は非常に効果的です。更新はグループにまとめられ、一度のバッチ処理でOracle Databaseに送信されます。
次のいずれかの場合に、PL/SQL実行メソッドは、ユーザーに意識させることなく一時的にSQL配列実行モードになります。
長さが32761バイトを超える文。
BINARY FLOAT、BINARY DOUBLEおよび4000バイトを超える長さのVARCHAR/VARBINARYの各データ型の列を参照する文。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCacheAWTMethodに関する説明を参照してください。
次の各項では、自動リフレッシュ処理のパフォーマンスを向上させる方法について説明します。
自動リフレッシュ間隔を0ミリ秒に設定すると、自動リフレッシュを連続するよう指定できます。連続自動リフレッシュを指定している場合、次の自動リフレッシュ・サイクルは、最後の自動リフレッシュ・サイクルの終了後、可能なかぎり早くスケジュールされます。
キャッシュ・エージェントはOracleデータベースに対して不要なラウンドトリップを実行する可能性があるため、Oracleデータベース上のワークロード率が低い場合は、連続自動リフレッシュによってリソースの使用率が向上することがあります。
自動リフレッシュ間隔の設定方法の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE CACHE GROUPおよびALTER CACHE GROUPに関する項を参照してください。
ほとんどのキャッシュ・グループ処理では、自動リフレッシュ処理および動的ロード処理で、Oracleデータベースへのアクセスを正確に調整します。TimesTenのデフォルトの調整動作により、自動リフレッシュ処理と動的ロード処理の間で競合が発生する可能性があります(極端な場合)。
増分自動リフレッシュが設定された動的な読取り専用キャッシュ・グループがある場合:
自動リフレッシュ処理によって複数の動的ロード処理がブロックされる可能性があります。
自動リフレッシュ処理が動的ロード処理の完了を待機している間に頻繁に遅延します。
DynamicLoadReduceContentionデータベース・システム・パラメータを有効にすると、自動リフレッシュ処理と動的ロード処理が調整される方法が変更され、自動リフレッシュ処理と動的ロード処理の間の競合が減少します。
(同期処理が追加されているため)自動リフレッシュ処理によって動的ロード処理がブロックされることがありません。
自動リフレッシュ処理が動的ロード処理によって完全に遅延することはありません。かわりに、自動リフレッシュ処理は、新しい自動リフレッシュ処理が開始されたことが同時実行中の動的ロード処理に通知されるまでしばらく待機します。これにより、動的ロード処理は、同時実行中の動的ロード処理と並行して同期できるようになります。
|
ノート: 動的な読取り専用キャッシュ・グループがある場合、またはキャッシュまたはレプリケーション・エージェントが実行されている場合、DynamicLoadReduceContentionデータベース・システム・パラメータの値を変更することはできません。この値を変更する前に、既存の動的な読取り専用キャッシュ・グループをすべてアンロードまたは削除(して後で再作成)する必要があります。 |
次の例では、DynamicLoadReduceContentionを1に設定しています。
call ttDbConfig('DynamicLoadReduceContention','1');
DynamicLoadReduceContentionパラメータの現在の値を問い合せることができます。
call ttDbConfig('DynamicLoadReduceContention');
|
ノート: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。 |
DynamicLoadReduceContentionデータベース・システム・パラメータは、TimesTenリリース11.2.2.8.39以降でサポートされています。また、DynamicLoadReduceContentionデータベース・システム・パラメータを有効にする際の要件は次のとおりです。
2つのOracle Database権限をキャッシュ管理ユーザーに付与する必要があります。
EXECUTE ON SYS.DBMS_FLASHBACK
SELECT ANY TRANSACTION
これらは、grantCacheAdminPrivileges.sqlスクリプトおよびinitCacheAdminSchema.sqlスクリプトを実行するときに、キャッシュ管理ユーザーに付与されます。
この機能では、Oracle Databaseフラッシュバック・トランザクション問合せを使用する必要があります。ただし、Oracle Database 12.2.0.1をマルチテナント・オプションとともに使用している場合は、フラッシュバック・トランザクション問合せはローカルUNDOのみサポートします。共有UNDOを使用したOracle Database 12.2.0.1 Multitenantオプションはサポートしていません。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを使用している場合:
アクティブ・マスターとスタンバイ・マスターは両方ともTimesTenリリース11.2.2.8.39以降とともにインストールする必要があります。異なるTimesTenバージョンがインストールされているアクティブ・マスターとスタンバイ・マスター間でレプリケートするときに、TimesTenバージョンの1つがこの機能をサポートしていない場合、このパラメータを有効にすることはできません。
DynamicLoadReduceContentionデータベース・システム・パラメータは、アクティブ・マスターとスタンバイ・マスターの両方で同じ値に設定する必要があります。
そうでない場合、エラーがデーモン・ログに書き込まれます。設定およびTimesTenのバージョンがアクティブ・マスターとスタンバイ・マスターの両方で一致するまで、レプリケーションは進行しません。
自動リフレッシュ処理は、キャッシュされたOracle Database表にコミットされた更新をTimesTenキャッシュ表に自動的にロードします。動的ロード処理は、(SELECT文から発生した) Oracleデータベースからのデータをリクエストし、その行をキャッシュ・グループに挿入します。自動リフレッシュ処理と動的ロード処理は両方とも、TimesTen Cacheメタデータへのアクセスが必要であるため、ロック競合が発生する可能性があります。
自動リフレッシュ処理の終了時に、TimesTenによってメタデータが更新され、自動リフレッシュの進行状況が追跡されます。DurableCommits接続属性を1に設定して永続性の保証をリクエストした場合、メタデータに対する自動リフレッシュの更新は常に永続的にコミットされます。DurableCommits接続属性を0 (デフォルト)に設定して永続性の遅延をリクエストした場合、Oracleデータベースに格納された自動リフレッシュ・トラッキング表をガベージ・コレクタがクリーンアップする前に、メタデータに対する自動リフレッシュの更新が永続的にコミットされていることをTimesTenが保証する必要があります。
永続コミットがメタデータに対して開始されると、ファイル・システムにフラッシュされていないログ・バッファ内の以前にコミットされた非永続トランザクションも永続コミットの一部となります。ファイル・システムがビジー状態または低速状態であるホストでは、動的ロードのリクエストを望ましくないほど長時間にわたってロックアウトしてしまうほど永続コミットが遅くなる可能性があります。
自動リフレッシュ・リクエストと動的ロード・リクエストの間のロック競合のためにアプリケーションがタイムアウトした場合、ttCacheConfig組込みプロシージャを使用して、CacheCommitDurableキャッシュ構成パラメータを0に設定できます。これにより、次の方法によって同じアプリケーションでの自動リフレッシュ・リクエストと動的ロード・リクエスト間のロック競合の発生を削減できます。
メタデータに対して行われる自動リフレッシュ変更の非永続コミットを実行します。
Oracleデータベースに保存されている自動リフレッシュ・トラッキング表をガベージ・コレクタがクリーンアップする前に、キャッシュ・エージェント内の別のスレッドを使用して自動リフレッシュの変更を永続的にコミットします。
新しいスレッドを起動してトランザクション・ログの永続コミットを実行することにより、そのロックは、メタデータに対する自動リフレッシュの変更の非永続コミット後に削除されます。その後は、メタデータのロックが解除され、最近リフレッシュされた表に対する動的なロード要求は待機せずに処理を続行できるようになります。
次の例では、CacheCommitDurableを0に設定しています。
call ttCacheConfig('CacheCommitDurable',,,'0');
CacheCommitDurableパラメータの現在の値を問い合せることができます。
call ttCacheConfig('CacheCommitDurable');
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する項を参照してください。
|
ノート: CacheCommitDurableを0に設定すると、トランザクション・ログ・バッファの永続コミットを実行する新しいスレッドが生成されるため、自動リフレッシュ変更ログ・レコードのガベージ・コレクションが開始されるのは、CacheCommitDurableが1である場合よりも後になります。 |
Oracle TimesTen In-Memory Databaseオペレーション・ガイドのトランザクションの再要求操作の説明にあるように、トランザクションのコミットの再要求フェーズ時にTimesTen Classicリソースのクリーン・アップが実行されます。パフォーマンス向上のため、数件のトランザクション・ログ・レコードをメモリーにキャッシュしてコミット・バッファのトランザクション・ログへのアクセスを減らします。ただし、トランザクションが再利用バッファより大きい場合、TimesTenはトランザクション・ログにアクセスする必要があります。
キャッシュ・グループに自動リフレッシュを使用する場合、キャッシュ・エージェントは独自の再利用バッファを使用して、自動リフレッシュ処理内でコミットされたトランザクションを管理します。キャッシュ・エージェントの再利用バッファが小さすぎる場合、自動リフレッシュ時のコミット操作は、トランザクション・ログ・ファイルにアクセスする必要があるため、予想よりも長くなる可能性があります。パフォーマンス問題を回避するには、キャッシュ・エージェントに大きな再利用バッファを構成し、再利用時にこのキャッシュ・エージェントがメモリー内で大規模なトランザクションを処理できるようにします。
アクティブ・スタンバイ・ペア・レプリケーション・スキームを使用して自動リフレッシュ処理をレプリケートする場合、レプリケーション・エージェントがレプリケーションの一部として同じ自動リフレッシュ処理を適用します。このため、アクティブおよびスタンバイ・ノードのレプリケーション・エージェントにはそれぞれの再利用バッファがあります。これらはキャッシュ・エージェントの再利用バッファと同じまたは大きいサイズで構成する必要があります。
ttDbConfig組込みプロシージャにより、キャッシュ・エージェントおよびレプリケーション・エージェント両方の再利用バッファの最大サイズを設定する次のパラメータが提供されます。(再利用バッファのメモリーは一時メモリーから割り当てられます。)
CacheAgentCommitBufSizeはキャッシュ・エージェントの再利用バッファの最大サイズを設定します。
RepAgentCommitBufSizeは、レプリケーション・エージェントの再利用バッファの最大サイズを設定します。アクティブおよびスタンバイ・ノードの両方で再利用バッファの最大サイズを構成する必要があります。再利用バッファのサイズは両方のノードに同じ値を設定することをお薦めしますが、必要ではありません。
|
ノート: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。 |
キャッシュ・エージェントの再利用バッファのサイズを増分する必要があるかを判断するには、ttCacheAutorefIntervalStatsGet組込みプロシージャにより提供されるCommitBufMaxReachedおよびCommitBufNumOverflows統計を評価します。詳細は、自動リフレッシュ・トランザクションに関する統計情報の取得を参照してください。
ある期間において、月末、四半期末、年末のトランザクションなどのように大規模なトランザクションを実行する必要が生じる場合があります。また、短期間のうちにOracle Database内にある大量のデータを変更したり追加したりする状況が生じる場合もあります。増分自動リフレッシュを使用した読取り専用キャッシュ・グループの場合、自動リフレッシュ処理がこれらのいずれかのケースに適用されたときに、TimesTenが永続領域を使い切ってしまう可能性があります。このため、このような状況においては、自動リフレッシュ・トランザクション制限を構成して、大量のデータを複数の小規模なトランザクションに分割して適用し、コミットするようにできます。
|
ノート: 自動リフレッシュ・トランザクション制限は、静的な読取り専用キャッシュ・グループに対してのみ設定できます。 |
ttCacheAutorefreshXactLimit組込みプロシージャを使用すると、特定の数の処理の実行後に自動リフレッシュをコミットするように指定できます。このオプションは、同じ自動リフレッシュ間隔で構成されるすべての増分自動リフレッシュ読取り専用キャッシュ・グループに適用されます。
単一のトランザクションが複数の小規模なトランザクションに分割されるため、自動リフレッシュの進行中はトランザクションの一貫性が確保できません。自動リフレッシュ・サイクルが完了すると、データに関するトランザクションの一貫性が確保されます。インスタンスの一貫性を確保するために、単一の表を持つキャッシュ・グループのみで自動リフレッシュ・トランザクション制限を設定することをお薦めします。これは、親表と子表の間のインスタンスの一貫性が保証されないためです。自動リフレッシュ・トランザクション制限の設定をオンにすると、TimesTenはインスタンスの一貫性を確保する外部キー関係を指定しません。増分自動リフレッシュ読取り専用キャッシュ・グループに対する自動リフレッシュ・トランザクション制限の設定をオフにすると、インスタンスの一貫性とトランザクションの一貫性の両方が再度確保されます。
|
ノート: アクティブ・スタンバイ・ペアを使用している場合は、アクティブ・マスターとスタンバイ・マスターの両方で同じ値でttCacheAutorefreshXactLimit組込みプロシージャをコールする必要があります。 |
|
ノート: 構文、返される結果などの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のttCacheAutorefreshXactLimitに関する説明を参照してください。 |
月末の処理の場合、自動リフレッシュ・キャッシュ・グループにキャッシュされているOracle表の単一のトランザクションに大量の更新が存在することがあります。大規模なトランザクションにより永続メモリーが一杯にならないようにするために、ttCacheAutorefreshXactLimit組込みプロシージャにより、256個(またはユーザー指定の他の値)の処理が終了するごとに自動リフレッシュをコミットするようにできます。
ttCacheAutorefreshXactLimit組込みプロシージャでvalueをONまたは特定の処理数に設定して大規模なトランザクションを実行する前に、増分自動リフレッシュ読取り専用キャッシュ・グループに対する自動リフレッシュ・トランザクション制限の設定をオンにします。次に、自動リフレッシュによるTimesTen内のキャッシュ表の更新が終了したら、ttCacheAutorefreshXactLimit組込みプロシージャにより、増分自動リフレッシュ読取り専用キャッシュ・グループに対する自動リフレッシュ・トランザクション制限の設定をオフにします。
次の例では、間隔の値が10秒として定義されているすべての増分自動リフレッシュ読取り専用キャッシュ・グループに対して、256個の処理が終了するごとにトランザクション制限をコミットするように設定しています。
call ttCacheAutorefreshXactLimit('10000', 'ON');
月末の処理が完了し、増分自動リフレッシュ読取り専用キャッシュ・グループがリフレッシュされた後、間隔の値が10秒として定義されている増分自動リフレッシュ読取り専用キャッシュ・グループに対するトランザクション制限の設定を無効にします。
call ttCacheAutorefreshXactLimit('10000', 'OFF');
1024個の処理が終了するごとに増分自動リフレッシュ読取り専用キャッシュ・グループに対するトランザクション制限をコミットするように設定するには、次のように値として1024を指定します。
call ttCacheAutorefreshXactLimit('10000', '1024');
次の例では、employee表およびdepartment表を使用しますが、ここでdepartment表のdepartment idは外部キーで、employee表のdepartment idを示しています。
次の例では、2つの増分自動リフレッシュ読取り専用キャッシュ・グループを作成しますが、それぞれのキャッシュ・グループは独自のキャッシュ・グループ内にあります。大規模なトランザクションの前にttCacheAutorefreshXactLimitにより自動リフレッシュ・トランザクション制限の設定を有効にし、トランザクションの完了後に設定を無効にします。
大規模なトランザクションを開始する前に、ttCacheAutorefreshXactLimitを起動して、間隔の値およびその間隔で自動的にコミットする処理数を設定します。次の例では、間隔が2秒に設定されているすべての増分自動リフレッシュ読取り専用キャッシュ・グループに対して、処理数を3 (例を簡単にするために意図的に小さな値にしています)に設定しています。
CALL ttCacheAutorefreshXactLimit('2000', '3');
< 2000, 3 >
1 row found.
間隔を2秒に設定して、増分自動リフレッシュ読取り専用キャッシュ・グループを作成します。この例では、2つの静的(動的ではない)読取り専用キャッシュ・グループを作成しますが、それぞれのキャッシュ・グループに表が1つ含まれています。
CREATE READONLY CACHE GROUP cgDepts AUTOREFRESH MODE INCREMENTAL
INTERVAL 2 SECONDS
FROM departments
( department_id NUMBER(4) PRIMARY KEY
, department_name VARCHAR2(30) NOT NULL
, manager_id NUMBER(6)
, location_id NUMBER(4)
);
CREATE READONLY CACHE GROUP cgEmpls AUTOREFRESH MODE INCREMENTAL
INTERVAL 2 SECONDS
FROM employees
( employee_id NUMBER(6) PRIMARY KEY
, first_name VARCHAR2(20)
, last_name VARCHAR2(25) NOT NULL
, email VARCHAR2(25) NOT NULL UNIQUE
, phone_number VARCHAR2(20)
, hire_date DATE NOT NULL
, job_id VARCHAR2(10) NOT NULL
, salary NUMBER(8,2)
, commission_pct NUMBER(2,2)
, manager_id NUMBER(6)
, department_id NUMBER(4)
);
両方の自動リフレッシュ・キャッシュ・グループに対して、手動でLOAD CACHE GROUPを実行します。
LOAD CACHE GROUP cgDepts COMMIT EVERY 256 ROWS; 27 cache instances affected. LOAD CACHE GROUP cgEmpls COMMIT EVERY 256 ROWS; 107 cache instances affected.
employees表で示されているように、自動リフレッシュ中は表内に非一貫性が発生する場合があります。
TimesTenで、すべての従業員の給与の最大値と最小値を選択します。
SELECT MIN(salary), MAX(salary) FROM employees; < 2100, 24000 > 1 row found.
Oracle Databaseで、全員の給与に100,000を追加します。
UPDATE employees SET salary = salary + 100000; 107 rows updated.
TimesTenで、再度SELECTを実行すると(自動リフレッシュ・トランザクションは3レコードごとにコミットされています)、給与の最大値は更新されていますが、最小値は元の値のままです。
SELECT MIN(salary), MAX(salary) FROM employees; < 2100, 124000 > 1 row found.
ただし、自動リフレッシュが完了すると、トランザクションの一貫性が確保されます。この例では、自動リフレッシュ・プロセスが完了すると、すべての従業員の給与が100,000だけ増加しています。
SELECT MIN(salary), MAX(salary) FROM employees; < 102100, 124000 > 1 row found.
大規模なトランザクションが完了したため、間隔が2秒に設定されている自動リフレッシュ・キャッシュ・グループに対するトランザクション制限の設定を無効にします。
call ttCacheAutorefreshXactLimit('2000', 'OFF');
自動リフレッシュ・プロセスの進行中にSQL文を実行すると、キャッシュ・グループ間でトランザクションの非一貫性が発生する可能性があります。次の例では、cgDepts自動リフレッシュ・グループ内のemployees表およびdepartment表に対してSELECT文を実行しています。この例では、TimesTenで外部キーが指定されておらず、自動リフレッシュ・プロセスが複数のトランザクションに適用されているため、departmentの更新の前にemployee表の更新が挿入される場合があります。
さらに、キャッシュ・グループ内の両方の表に対するすべての更新は、自動リフレッシュ・サイクルが完了するまでは適用されません。次の例では、自動リフレッシュ・プロセスが完了する前にSELECT文が実行されています。このように、結果には必要なデータがすべて表示されているわけではなく、部門名や複数の従業員(法務部1000の弁護士の一部)が欠落しています。
SELECT e.department_id, d.DEPARTMENT_NAME, e.FIRST_NAME, e.LAST_NAME
FROM employees e, departments d
WHERE e.DEPARTMENT_ID = d.DEPARTMENT_ID (+)
AND e.department_id >= 1000 ORDER BY 1,2,3,4;
< 1000, <NULL>, Alan, Dershowitz >
< 1000, <NULL>, F. Lee, Bailey >
< 1000, <NULL>, Johnnie, Cochran >
3 rows found.
ただし、自動リフレッシュ・プロセスが完了すると、トランザクションの一貫性が確保されます。次の例では、自動リフレッシュの完了後に同じSELECT文が実行されています。この場合、部門情報や新しいすべての弁護士などの必要なデータがすべて更新されています。
SELECT e.department_id, d.DEPARTMENT_NAME, e.FIRST_NAME, e.LAST_NAME
FROM employees e, departments d
WHERE e.DEPARTMENT_ID = d.DEPARTMENT_ID (+)
AND e.department_id >= 1000 ORDER BY 1,2,3,4;
< 1000, Legal, Alan, Dershowitz >
< 1000, Legal, Barry, Scheck >
< 1000, Legal, F. Lee, Bailey >
< 1000, Legal, Johnnie, Cochran >
< 1000, Legal, Robert, Kardashian >
< 1000, Legal, Robert, Shapiro >
6 rows found.
複数の表を持つ自動リフレッシュ・キャッシュ・グループの場合も、自動リフレッシュ・プロセスの進行中にSQL文を実行すると、トランザクションの非一貫性が発生することがあります。
ttCacheAutorefreshXactLimit組込みプロシージャにより、2秒間隔の増分自動リフレッシュ・キャッシュ・グループに対してトランザクション制限の設定を開始し、employeesおよびdepartmentsの2つの表を持つ単一の自動リフレッシュ・キャッシュ・グループを作成します。
CALL ttCacheAutorefreshXactLimit('2000', '3');
< 2000, 3 >
1 row found.
CREATE READONLY CACHE GROUP cgDeptEmpls AUTOREFRESH MODE INCREMENTAL
INTERVAL 2 SECONDS
FROM departments
( department_id NUMBER(4) PRIMARY KEY
, department_name VARCHAR2(30) NOT NULL
, manager_id NUMBER(6)
, location_id NUMBER(4)
)
, employees
( employee_id NUMBER(6) PRIMARY KEY
, first_name VARCHAR2(20)
, last_name VARCHAR2(25) NOT NULL
, email VARCHAR2(25) NOT NULL UNIQUE
, phone_number VARCHAR2(20)
, hire_date DATE NOT NULL
, job_id VARCHAR2(10) NOT NULL
, salary NUMBER(8,2)
, commission_pct NUMBER(2,2)
, manager_id NUMBER(6)
, department_id NUMBER(4)
, foreign key(department_id) references departments(department_id)
);
キャッシュ・グループを手動でロードします。
LOAD CACHE GROUP cgDeptEmpls COMMIT EVERY 256 ROWS; 27 cache instances affected.
TimesTenでSELECT文を実行し、法務部のデータをすべてアップロードします。
SELECT e.department_id, d.department_name, count(*)
FROM employees e, departments d
WHERE e.department_id = d.department_id (+)
GROUP BY e.department_id, d.department_name
ORDER BY 1 desc;
< 110, Accounting, 2 >
< 100, Finance, 6 >
< 90, Executive, 3 >
< 80, Sales, 34 >
< 70, Public Relations, 1 >
< 60, IT, 5 >
< 50, Shipping, 45 >
< 40, Human Resources, 1 >
< 30, Purchasing, 6 >
< 20, Marketing, 2 >
< 10, Administration, 1 >
11 rows found.
Oracleでemployeeおよびdepartmentの両方の表に、6人の新しい弁護士が所属する新しい法務部(番号1000)を挿入します。
自動リフレッシュ・プロセス時にTimesTenでSELECT文を実行すると、部門1000の2人の弁護士に関するデータのみがTimesTenにアップロードされます。
SELECT e.department_id, d.department_name, count(*)
FROM employees e, departments d
WHERE e.department_id = d.department_id (+)
GROUP BY e.department_id, d.department_name
ORDER BY 1 desc;
< 1000, Legal, 2 >
< 110, Accounting, 2 >
< 100, Finance, 6 >
< 90, Executive, 3 >
< 80, Sales, 34 >
< 70, Public Relations, 1 >
< 60, IT, 5 >
< 50, Shipping, 45 >
< 40, Human Resources, 1 >
< 30, Purchasing, 6 >
< 20, Marketing, 2 >
< 10, Administration, 1 >
12 rows found.
ただし、自動リフレッシュ・プロセスが完了すると、法務部に所属する6人の従業員(弁護士)すべてのデータがTimesTenにアップロードされます。これにより、現時点においてトランザクションの一貫性が確保されます。
SELECT e.department_id, d.department_name, COUNT(*)
FROM employees e, departments d
WHERE e.department_id = d.department_id (+)
GROUP BY e.department_id, d.department_name
ORDER BY 1 desc;
< 1000, Legal, 6 >
< 110, Accounting, 2 >
< 100, Finance, 6 >
< 90, Executive, 3 >
< 80, Sales, 34 >
< 70, Public Relations, 1 >
< 60, IT, 5 >
< 50, Shipping, 45 >
< 40, Human Resources, 1 >
< 30, Purchasing, 6 >
< 20, Marketing, 2 >
< 10, Administration, 1 >
12 rows found.
大規模なトランザクションが完了したため、間隔が2秒に設定されている自動リフレッシュ・キャッシュ・グループに対するトランザクション制限の設定を無効にします。
call ttCacheAutorefreshXactLimit('2000', 'OFF');
特定の自動リフレッシュ間隔に対して自動リフレッシュ・トランザクション制限がどのように実行されるかを確認するために、ttCacheAutorefIntervalStatsGet組込みプロシージャを使用して、この自動リフレッシュ間隔に対する最後の10回の増分自動リフレッシュ・トランザクションの統計を取得できます。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。
読取り専用キャッシュ・グループの増分自動リフレッシュを容易にするために、TimesTenはOracle Databaseの実表とその対応する変更ログ表の両方に表の結合問合せを実行して、増分の変化を取得します。ただし、両方の表が非常に大きい場合は、結合問合せが遅くなる可能性があります。また、結合問合せの実行中にOracle Databaseの実表が常に更新されている場合、長期実行自動リフレッシュ問合せからORA-01555「snapshot too old」エラーを受信する可能性があります。
この状況を回避するために、静的な読取り専用キャッシュ・グループに対する選択制限を使用して増分自動リフレッシュを構成できます。選択制限はOracle Databaseの実表を自動リフレッシュ変更ログ表の制限された行数と結合します。ttCacheAutorefreshSelectLimit組込みプロシージャを使用して選択制限を構成できます。
|
ノート: 選択制限は、静的な読取り専用キャッシュ・グループに対してのみ設定できます。 |
自動リフレッシュは自動リフレッシュ変更ログ表のすべての行が適用されるまで、キャッシュ表に対する変更を適用し続けます。適用する行がなくなった場合、自動リフレッシュ・スレッドは残りの時間間隔内で休止状態になります。
|
ノート: 構文、パラメータ、結果セット、および制限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAutorefreshSelectLimitに関する説明を参照してください。 |
たとえば、大規模なトランザクションの前にttCacheAutorefreshSelectLimit組込みプロシージャをコールして、間隔の値が10秒の増分自動リフレッシュ・キャッシュ・グループの選択制限を1000行に設定します。次の例では、valueがONに設定されています。
Command> call ttCacheAutorefreshSelectLimit('10000', 'ON');
< 10000, ON >
1 row found.
次の例では間隔値が7秒の増分自動リフレッシュ・キャッシュ・グループに対して選択制限を2000行に設定しています。
Command> call ttCacheAutorefreshSelectLimit('7000', '2000');
< 7000, 2000 >
1 row found.
valueをOFFに設定することで、間隔の値が10秒の増分自動リフレッシュ・キャッシュ・グループの選択制限を無効にできます。
Command> call ttCacheAutorefreshSelectLimit('10000', 'OFF');
< 10000, OFF >
1 row found.
特定の自動リフレッシュ間隔に対する選択制限がどのように実行されるかを確認するために、この自動リフレッシュ間隔に対する増分自動リフレッシュ・トランザクションの統計を取得できます。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。
キャッシュ・グループの間隔を決定するには、ttIsqlを使用してcachegroupsコマンドを実行します。
> cachegroups cgowner.cgname;
これにより、間隔を含むcgowner.cgnameキャッシュ・グループのすべての属性が返されます。
どの間隔に選択制限があるか確認するために、Oracle Databaseで次の問合せを実行できます(このOracle Databaseでは<cacheAdminUser>はキャッシュ管理者、<hostName>はTimesTenデータベースがあるマシンのホスト名、<databaseFileName>はDataStore属性から引き継いだデータベース・パスとなっており、バージョン番号(06など)がxxに置き換えてあります)。
SELECT * FROM <cacheAdminUser>.tt_xx_arinterval_params
WHERE param='AutorefreshSelectEveryN'
AND host='<hostName>'
AND database like '%<databaseFileName>%'
ORDER BY arinterval;
たとえば、キャッシュ管理者のユーザー名はpat、ホスト名はmyhost、データベース・ファイル名はmyTtDb、06をTimesTen Classicのマイナー・リリース番号のxxに置き換えると、次のようになります。
SELECT * FROM pat.tt_06_arinterval_params WHERE param='AutorefreshSelectEveryN' AND host='myhost' AND database like '%myTtDb%' ORDER BY arinterval;
間隔はミリ秒単位で保存されます。
特定の自動リフレッシュ間隔に対して選択制限が実行されることを確認するために、ttCacheAutorefIntervalStatsGet組込みプロシージャを使用してこの自動リフレッシュ間隔に対する増分自動リフレッシュ・トランザクションの統計を取得できます。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。
ttCacheAutorefIntervalStatsGet組込みプロシージャをコールして、増分自動リフレッシュ読取り専用キャッシュ・グループに定義された特定の自動リフレッシュ間隔による最後の10回の自動リフレッシュ・サイクルに関する統計情報を取得します。
|
ノート: この組込みプロシージャの構文および返される結果セットの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAutorefIntervalStatsGetに関する説明を参照してください。この組込みプロシージャはトランザクション制限または選択制限を増分、自動リフレッシュ読取り専用キャッシュ・グループに設定する場合に役立ちます。詳細は、増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の大規模なトランザクションの実行および増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の選択制限の構成を参照してください。 |
次の例では、ttCacheAutorefIntervalStatsGet組込みプロシージャをコールして、静的に定義され、間隔が2秒の増分自動リフレッシュ読取り専用キャッシュ・グループの統計を取得する方法を示します。
Command> call ttCacheAutorefIntervalStatsGet(2000, 1); < 2000, 1, 21, 2013-04-30 06:05:38.000000, 100, 3761, 3761, 822, 1048576, 1280, 0, 58825, 63825, 13590, 0, 0, 0, 0, 0 > < 2000, 1, 20, 2013-04-30 06:05:37.000000, 100, 85, 85, 18, 1048576, 1280, 0, 55064, 60064, 12768, 0, 0, 0, 0, 0 > < 2000, 1, 19, 2013-04-30 06:05:32.000000, 100, 3043, 3043, 666, 1048576, 1280, 0, 54979, 59979, 12750, 0, 0, 0, 0, 0 > < 2000, 1, 18, 2013-04-30 06:05:30.000000, 100, 344, 344, 74, 1048576, 1280, 0, 51936, 56936, 12084, 0, 0, 0, 0, 0 > < 2000, 1, 17, 2013-04-30 06:05:28.000000, 100, 1826, 1826, 382, 1048576, 1280, 0, 51592, 56592, 12010, 0, 0, 0, 0, 0 > < 2000, 1, 16, 2013-04-30 06:05:26.000000, 100, 55, 55, 12, 1048576, 1280, 0, 49766, 54766, 11628, 0, 0, 0, 0, 0 > < 2000, 1, 15, 2013-04-30 06:05:22.000000, 100, 2901, 2901, 634, 1048576, 1280, 0, 49711, 54711, 11616, 0, 0, 0, 0, 0 > < 2000, 1, 14, 2013-04-30 06:05:21.000000, 100, 55, 55, 12, 1048576, 1280, 0, 46810, 51810, 10982, 0, 0, 0, 0, 0 > < 2000, 1, 13, 2013-04-30 06:05:10.000000, 100, 5844, 5844, 1263, 1048576, 1280, 0, 46755, 51755, 10970, 0, 0, 0, 0, 0 > < 2000, 1, 12, 2013-04-30 06:05:08.000000, 100, 607, 607, 132, 1048576, 1280, 0, 40911, 45911, 9707, 0, 0, 0, 0, 0 > 10 rows found.
TimesTenは、キャッシュ管理ユーザーごとにキャッシュ・グループの各キャッシュ表について、Oracle Database内に変更ログ表とトリガーを作成します(キャッシュを管理するために作成する項目の一部として)。トリガーは、キャッシュされたOracle Database表で挿入、更新または削除処理がコミットされるたびに起動され、アクションが変更ログ表に記録されます。
2つの異なるTimesTenデータベース上で1つのキャッシュ・グループに同じOracle Database表をキャッシュする場合は、それぞれのTimesTenデータベースでのキャッシュ表の所有者と同じキャッシュ管理ユーザー名を、両方のTimesTenデータベースで使用することをお薦めします。同じキャッシュ管理ユーザーを使用すると、1つのトリガーと変更ログ表のみが作成され、実表への変更内容が管理されます。これは効率的な方法であり、アプリケーションの速度も低下しません。
それぞれのTimesTenデータベースで個別にキャッシュ管理ユーザーを作成して、同じOracle表をキャッシュするキャッシュ・グループを所有する場合は、Oracle Databaseの同じ表にキャッシュ管理ユーザーごとに別々のトリガーと変更ログ表が存在します。たとえば、2つの別のTimesTenデータベースが存在して、それぞれに独自のキャッシュ管理ユーザーが指定されている場合、実表では各DML処理に対して2つのトリガーが起動され、それぞれは別の変更ログ表に保存されます。2つのトリガーが起動されて変更ログ表を個別に管理すると、アプリケーションの速度が低下することがあります。
キャッシュ管理ユーザーを個別に作成する唯一の理由は、同じ表をキャッシュする複数のTimesTenデータベースのいずれかで自動リフレッシュのレートが低下しているか、またはOracle Databaseへの接続速度が低下しているためです。この場合、両方のTimesTenデータベースで単一のキャッシュ管理ユーザーを指定すると、速度が低下しているデータベースに更新が伝播されるのを待機するため、高速の接続状態でのアプリケーションの速度が低下します。
