| Oracle® TimesTen Application-Tier Database Cacheユーザーズ・ガイド 11g リリース2 (11.2.2) B66442-07 |
|
 前 |
 次 |
次の各項では、キャッシュ・パフォーマンスに関する情報について説明します。
|
注意: 自動リフレッシュ処理の監視および自動リフレッシュ・パフォーマンスの向上の詳細は、Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドを参照してください。自動リフレッシュ・キャッシュ・グループの監視に関する説明および自動リフレッシュのパフォーマンスが悪い場合に関する説明を参照してください。 Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドには、AWTキャッシュ・グループのパフォーマンスに関する情報も記載されています。AWTのパフォーマンスの監視に関する説明およびAWTのパフォーマンスが悪い場合に考えられる原因に関する説明を参照してください。 |
ルート表の主キー検索に基づいた動的ロードの方が、子表に対する主キー検索または子表に対する外部キー検索よりも、パフォーマンスが速くなります。詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。
次の方法を使用して、AWTキャッシュ・グループのスループットを向上させます。
AWTキャッシュ・グループのスループットを向上させるために、パラレル動作でトランザクションの変更をOracle Databaseに伝播および適用する複数のスレッドを構成できます。パラレル伝播では、トランザクションの依存性に従って、AWTキャッシュ表の変更をコミット順にOracle Database表に適用します。詳細は、「Oracle Database表へのパラレル伝播の構成」を参照してください。
デフォルトでは、AWTキャッシュ・グループは、TimesTenでの変更をOracle Databaseに適用する際にPL/SQL実行メソッドを使用します。AWTでは、すべての保留中の処理を単一のPL/SQLコレクションにまとめ、Oracle Databaseサーバーに送信して実行します。この実行メソッドは、TimesTenとOracle Databaseサーバー間で混合トランザクションおよびネットワーク待機時間が存在する場合に適しています。
TimesTenでの変更をOracle Databaseに適用するためにSQL配列実行を指定するには、CacheAWTMethod初期接続属性を使用します。このメソッドは、同じタイプの処理を繰り返す場合に適しています。たとえば、表の複数の行に影響する更新をユーザーが行う場合にSQL配列実行は非常に効果的です。更新はグループにまとめられ、一度のバッチ処理でOracle Databaseサーバーに送信されます。
次のいずれかの場合に、PL/SQL実行メソッドは、ユーザーに意識させることなく一時的にSQL配列実行モードになります。
長さが32761バイトを超える文。
BINARY FLOAT、BINARY DOUBLEおよび4000バイトを超える長さのVARCHAR/VARBINARYの各データ型の列を参照する文。
|
注意: ttDBConfig組込みプロシージャでCacheAwtMethodパラメータを指定して、この値を設定することもできます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。 |
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCacheAWTMethodに関する説明を参照してください。
次の各項では、大規模なトランザクションがある場合、または増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際に大規模な表に参加する場合にパフォーマンスを向上させる方法について説明します。
ある期間において、月末、四半期末、年末のトランザクションなどのように大規模なトランザクションを実行する必要が生じる場合があります。また、短期間のうちに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表およびdepartments表に対して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のマイナー・リリース番号のxxに置き換えると、次のようになります。
SELECT * FROM pat.tt_06_arinterval_params WHERE param='AutorefreshSelectEveryN' AND host='myhost' AND database like '%myTtDb%' ORDER BY arinterval;
間隔はミリ秒単位で保存されます。
特定の自動リフレッシュ間隔に対して選択制限が実行されることを確認するために、ttCacheAutorefIntervalStatsGet組込みプロシージャを使用してこの自動リフレッシュ間隔に対する増分自動リフレッシュ・トランザクションの統計を取得できます。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクションの再要求処理に関する説明にあるように、トランザクションのコミットの再利用フェーズ時にTimesTenリソースのクリーンアップが実行されます。パフォーマンス向上のため、数件のトランザクション・ログ・レコードをメモリーにキャッシュしてコミット・バッファのディスク上のトランザクション・ログへのアクセスを減らします。ただし、トランザクションが再利用バッファより大きい場合、TimesTenはディスク上のトランザクション・ログにアクセスする必要があります。
キャッシュ・グループに自動リフレッシュを使用する場合、キャッシュ・エージェントは独自の再利用バッファを使用して、自動リフレッシュ処理内でコミットされたトランザクションを管理します。キャッシュ・エージェントの再利用バッファが小さすぎる場合、自動リフレッシュ時のコミット処理は、ディスク上のトランザクション・ログにアクセスする必要があるため、予想よりも長くなる可能性があります。パフォーマンス問題を回避するには、キャッシュ・エージェントに大きな再利用バッファを構成し、再利用時にこのキャッシュ・エージェントがメモリー内で大規模なトランザクションを処理できるようにします。
アクティブ・スタンバイ・ペア・レプリケーション・スキームを使用して自動リフレッシュ処理をレプリケートする場合、レプリケーション・エージェントがレプリケーションの一部として同じ自動リフレッシュ処理を適用します。このため、アクティブおよびスタンバイ・ノードのレプリケーション・エージェントにはそれぞれの再利用バッファがあります。これらはキャッシュ・エージェントの再利用バッファと同じまたは大きいサイズで構成する必要があります。
ttDbConfig組込みプロシージャにより、キャッシュ・エージェントおよびレプリケーション・エージェント両方の再利用バッファの最大サイズを設定する次のパラメータが提供されます。(再利用バッファのメモリーは一時メモリーから割り当てられます。)
CacheAgentCommitBufSizeはキャッシュ・エージェントの再利用バッファの最大サイズを設定します。
RepAgentCommitBufSizeは、レプリケーション・エージェントの再利用バッファの最大サイズを設定します。アクティブおよびスタンバイ・ノードの両方で再利用バッファの最大サイズを構成する必要があります。再利用バッファのサイズは両方のノードに同じ値を設定することをお薦めしますが、必要ではありません。
|
注意: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDbConfigに関する説明を参照してください。 |
キャッシュ・エージェントの再利用バッファのサイズを増分する必要があるかを判断するには、ttCacheAutorefIntervalStatsGet組込みプロシージャにより提供されるCommitBufMaxReachedおよびCommitBufNumOverflows統計を評価します。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。
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データベースで単一のキャッシュ管理ユーザーを指定すると、速度が低下しているデータベースに更新が伝播されるのを待機するため、高速の接続状態でのアプリケーションの速度が低下します。
