| Oracle® TimesTen Application-Tier Database Cacheユーザーズ・ガイド リリース18.1 E98634-04 |
|
 前 |
 次 |
次の各項では様々なタイプのキャッシュ・グループとそれを定義する方法について説明します。
TimesTenデータベースにキャッシュするOracle Databaseデータは、キャッシュ・グループによって定義されます。キャッシュ・グループを作成すると、キャッシュされたOracle Database表に対応するキャッシュ表がTimesTenデータベースに作成されます。
キャッシュ・グループ定義には、キャッシュされるOracle Database表ごとに個別の表定義を指定する必要があります。TimesTenキャッシュ表の所有者、表名およびキャッシュされる列の名前は、対応するキャッシュ対象のOracle Database表の所有者、表名および列名と一致している必要があります。キャッシュ表に、キャッシュされたOracle Database表のすべての行と列または行と列のサブセットを格納できます。各TimesTenキャッシュ表には主キーが必要です。
Oracle Database表は、同じTimesTenデータベースにある複数のキャッシュ・グループにキャッシュすることはできません。ただし、異なるTimesTenデータベースにある別々のキャッシュ・グループにキャッシュすることは可能です。別々のAWTキャッシュ・グループに表がキャッシュされており、同じキャッシュ・インスタンスが複数のTimesTenデータベースで同時に更新された場合、キャッシュされたOracle Database表にこの更新が伝播される順序は保証されません。また、TimesTenデータベース間で、更新されたキャッシュ表の内容に一貫性がなくなります。
キャッシュ・グループ表を定義する前に、キャッシュされるOracle Database表を作成します。各表は次のいずれかである必要があります。
NULLを指定できない列に主キーがあるOracle Database表。TimesTenキャッシュ表の主キーは、全Oracle Database表の主キーで定義する必要があります。たとえば、キャッシュされたOracle Database表の列c1、c2およびc3に複合主キーがある場合、TimesTenキャッシュ表の列c1、c2およびc3にも複合主キーが必要です。
次の例では、複合主キーがあるOracle Database表からキャッシュ・グループを作成する方法を示します。Oracle Databaseに、複合キーを持つjob_history表を作成します。
SQL> CREATE TABLE job_history
(employee_id NUMBER(6) NOT NULL,
start_date DATE NOT NULL,
end_date DATE NOT NULL,
job_id VARCHAR2(10) NOT NULL,
department_id NUMBER(4),
PRIMARY KEY(employee_id, start_date));
Table created.
TimesTenデータベースに、複合主キーの列をすべて持つキャッシュ・グループを作成します。
Command> CREATE WRITETHROUGH CACHE GROUP job_hist_cg
FROM oratt.job_history
(employee_id NUMBER(6) NOT NULL,
start_date DATE NOT NULL,
end_date DATE NOT NULL,
job_id VARCHAR2(10) NOT NULL,
department_id NUMBER(4),
PRIMARY KEY(employee_id, start_date));
NULLを指定できない列を持つOracle Database表。この表内の1つ以上のNULLを指定できない列に一意索引が指定されています。TimesTenキャッシュ表の主キーは、一意索引のすべての列に定義されている必要があります。たとえば、Oracle Database表の一意索引が複数の列c1、c2およびc3で構成されている場合、TimesTenキャッシュ表の列c1、c2およびc3には複合主キーが必要です。
次の例では、NULLを指定できない列を持つ表に定義するOracle Database一意索引を作成します。
SQL> CREATE TABLE regions(
region_id NUMBER NOT NULL,
region_name VARCHAR2(25));
Table created.
SQL> CREATE UNIQUE INDEX region_idx
ON regions(region_id);
Index created.
SQL> CREATE TABLE sales(
prod_id INT NOT NULL,
cust_id INT NOT NULL,
quantity_sold INT NOT NULL,
time_id DATE NOT NULL);
Table created.
SQL> CREATE UNIQUE INDEX sales_index ON sales(prod_id, cust_id);
Index created.
Oracle Database表と一意索引を作成した後に、次に示すように一意索引列を主キー定義として使用することにより、これらの表についてTimesTenデータベースにキャッシュ・グループを作成できます。
Command> CREATE WRITETHROUGH CACHE GROUP region_cg FROM oratt.regions (region_id NUMBER NOT NULL PRIMARY KEY, region_name VARCHAR2(25)); Command> CREATE WRITETHROUGH CACHE GROUP sales_cg FROM oratt.sales (prod_id INT NOT NULL, cust_id INT NOT NULL, quantity_sold INT NOT NULL, time_id DATE NOT NULL, PRIMARY KEY(prod_id, cust_id));
TimesTenデータベースには、複数のキャッシュ・グループを含めることができます。キャッシュ・グループには、1つ以上のキャッシュ表を含めることができます。
TimesTenのキャッシュ表に索引を作成すると、TimesTenの通常の表の場合と同様に、表に対して発行された特定の問合せを高速化できます。TimesTenキャッシュ表に対して非一意索引を作成できます。キャッシュ表には、キャッシュされたOracle Database表の一意索引と一致しない一意索引を作成しないでください。このような一意索引を作成すると、キャッシュされたOracle Database表では発生しない一意制約による障害がキャッシュ表で発生する可能性があり、その結果、自動リフレッシュ処理が実行されたときに、2つのデータベース内でこれらの表が互いに同期化されなくなります。
最も単純なキャッシュ・グループは、単一のOracle Database表をキャッシュするキャッシュ・グループです。単一表のキャッシュ・グループには、ルート表はありますが子表はありません。
図4-1に、customer表をキャッシュする単一表キャッシュ・グループtarget_customersを示します。
複数表のキャッシュ・グループは、1つのルート表および1つ以上の子表を定義するキャッシュ・グループです。キャッシュ・グループに含めることのできるルート表は、1つのみです。各子表は、外部キー制約を使用して、キャッシュ・グループ内のルート表または別の子表について、主キーまたは一意索引を参照する必要があります。複数表のキャッシュ・グループ内の表は、TimesTenデータベース内で外部キー制約によって相互に関連付けられている必要がありますが、Oracle Database内で相互に関連付けられている必要はありません。ルート表は、外部キー制約を使用してキャッシュ・グループ内の表を参照することはありません。
図4-2に、customer、ordersおよびorder_itemの各表をキャッシュする複数表のキャッシュ・グループcustomer_ordersを示します。customer_ordersキャッシュ・グループ内の各親表が持つ主キーは、外部キー制約を介して子表によって参照されます。customer表は外部キー制約を使用してキャッシュ・グループ内の表を参照していないため、この表がキャッシュ・グループのルート表です。ルート表の主キーは、キャッシュ・グループの主キーとみなされます。orders表は、customerルート表の子表です。order_item表は、orders子表の子表です。
複数表のキャッシュ・グループ内の表階層で、子表を他の子表の親に指定できます。子表は2つ以上の親表を参照できません。ただし、親表は2つ以上の子表から参照されることがあります。
図4-3に、不適切なキャッシュ表階層を示します。customer表およびproduct表は、どちらも外部キー制約を介してキャッシュ・グループ内の表を参照していません。これにより、キャッシュ・グループは2つのルート表を持つことになるため無効です。
この問題を解決してすべての表をキャッシュするには、図4-4に示すように、customer、ordersおよびorder_itemの各表を含むキャッシュ・グループと、productおよびinventoryの各表を含む2つ目のキャッシュ・グループを作成します。
キャッシュ・グループを作成するには、CREATE CACHE GROUP SQL文を使用するか、グラフィカル・ツールであるOracle SQL Developerを使用します。SQL Developerの詳細は、『Oracle SQL Developer TimesTen In-Memory Databaseサポート・ユーザーズ・ガイド』を参照してください。
キャッシュ・グループは、システム管理またはユーザー管理のいずれかとして識別されます。システム管理キャッシュ・グループでは特定の動作が実行されますが、ユーザー管理キャッシュ・グループの動作はカスタマイズできます。システム管理キャッシュ・グループには、次のタイプがあります。
ユーザー管理キャッシュ・グループの詳細は、ユーザー管理キャッシュ・グループを参照してください。
キャッシュ・グループの作成には、次の内容も適用されます。
キャッシュ・グループは、キャッシュ・マネージャ・ユーザーが作成して所有する必要があります。
Oracle Databaseデータを一時データベースにキャッシュすることはできません。
読取り専用キャッシュ・グループでは、図4-5に示すように、TimesTenキャッシュ表を直接更新できない場合、キャッシュ動作が実行されて、キャッシュされたOracle Database表でコミットされた更新をキャッシュ表に自動的にリフレッシュします。
なんらかの理由でTimesTenデータベースを利用できない場合でも、読取り専用キャッシュ・グループにキャッシュされているOracle Database表は更新できます。TimesTenデータベースが処理を再開すると、TimesTenデータベースが利用できなかった間にキャッシュされたOracle Database表でコミットされた更新が、TimesTenキャッシュ表に自動的にリフレッシュされます。
|
ノート: TimesTenで読取り専用キャッシュ・グループの操作を管理する場合、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続します。ttCacheUidPwdSetの詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。 |
例4-1、例4-12、例4-15、例4-23および例4-24に定義された読取り専用キャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。
CREATE TABLE customer (cust_num NUMBER(6) NOT NULL PRIMARY KEY, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100)); CREATE TABLE orders (ord_num NUMBER(10) NOT NULL PRIMARY KEY, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL);
キャッシュ・マネージャ・ユーザーがoratt.customer表およびoratt.orders表をキャッシュする読取り専用キャッシュ・グループを作成できるようにし、キャッシュされたOracle Database表からTimesTenキャッシュ表への自動リフレッシュ処理が実行されるようにするには、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のコンパニオンOracle Databaseユーザーに、これらの表に対するSELECT権限を付与する必要があります。
読取り専用キャッシュ・グループを作成するには、CREATE READONLY CACHE GROUP文を使用します。
次の文では、oratt.customer表(ルート表)およびoratt.orders表(子表)をキャッシュする読取り専用キャッシュ・グループcustomer_ordersが作成されます。
CREATE READONLY CACHE GROUP customer_orders FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)), oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num), FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));
読取り専用キャッシュ・グループ内のキャッシュ表は直接更新できません。ただし、パススルー・レベルを2に設定すると、TimesTenキャッシュ表に対して発行されたコミット済の更新処理をパススルーし、キャッシュされたOracle Database表上で処理してから、更新を自動的にキャッシュ表にリフレッシュできます。「パススルー・レベルの設定」を参照してください。
読取り専用キャッシュ・グループ内のキャッシュ表に対する、パススルーされた文の影響は、更新処理が発行されたトランザクションでは発生しません。かわりに、この影響は、パススルーされた更新処理がOracle Databaseにコミットされ、キャッシュ・グループの次の自動リフレッシュが実行された後に発生します。パススルーされた更新処理をキャッシュされたOracle Database表で実行するには、読取り専用キャッシュ・グループにキャッシュされるOracle Database表において、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、INSERT、UPDATEおよびDELETE権限が付与されている必要があります。
「データのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」の説明に従って、自動リフレッシュ・キャッシュ・グループの定義済動作を実行するためにOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。
次に、ttIsqlユーティリティのcachesqlgetコマンドを実行して、読取り専用キャッシュ・グループにキャッシュされるOracle Database表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトを生成する必要があります。これらのオブジェクトの作成方法の詳細は、「自動リフレッシュ・キャッシュ・グループ用のOracle Databaseオブジェクトの手動による作成」を参照してください。
読取り専用キャッシュ・グループを使用する場合は、次の制限が適用されます。
TimesTenのキャッシュ表は直接更新できません。
キャッシュ表定義では、ON DELETE CASCADEおよびUNIQUE HASH ONキャッシュ表属性のみを使用できます。
ON DELETE CASCADEキャッシュ表属性の詳細は、「ON DELETE CASCADEキャッシュ表属性」を参照してください。
UNIQUE HASH ONキャッシュ表属性の詳細は、「UNIQUE HASH ONキャッシュ表属性」を参照してください。
キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。
キャッシュされたOracle Database表に対して発行されたTRUNCATE TABLE文は、TimesTenキャッシュ表に自動的にリフレッシュされません。
キャッシュ・グループが動的である場合を除いて、キャッシュ・グループにLOAD CACHE GROUP文を発行できるのはキャッシュ表が空の場合のみです。
LOAD CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。
動的キャッシュ・グループの詳細は、「動的キャッシュ・グループ」を参照してください。
キャッシュ・グループが動的である場合を除いて、キャッシュ・グループに対してLOAD CACHE GROUP文を発行する前の自動リフレッシュ状態はPAUSEDである必要があります。キャッシュ・グループが動的である場合は、自動リフレッシュ状態はPAUSEDまたはONであることが必要です。キャッシュ・グループが動的である場合を除いて、LOAD CACHE GROUP文にWHERE句を含めることはできず、キャッシュ・グループが動的である場合は、WHERE句の後にCOMMIT EVERY n ROWS句を続ける必要があります。
自動リフレッシュ状態の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。
キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。
REFRESH CACHE GROUP文をキャッシュ・グループに対して発行するには、自動リフレッシュ状態がPAUSEDになっている必要があります。REFRESH CACHE GROUP文にWHERE句を含めることはできません。
REFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。
キャッシュ・グループの作成、ロードまたはアンロード時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name
最低使用頻度(LRU)エージングがデフォルトで定義されている、キャッシュ・グループが動的である場合を除いて、キャッシュ・グループにLRUエージングを指定できません。
LRUエージングの詳細は、「LRUエージング」を参照してください。
読取り専用キャッシュ・グループでは、Oracle Databaseビューまたはマテリアライズド・ビューをキャッシュできません。
ASYNCHRONOUS WRITETHROUGH (AWT)キャッシュ・グループでは、図4-6に示すように、TimesTenキャッシュ表でコミット済の更新が、キャッシュされたOracle Database表に非同期で自動的に伝播されるというキャッシュ動作が実行されます。
|
ノート: AWTキャッシュ・グループにキャッシュされているOracle Database表では、DML文を実行することは避けてください。実行すると、エラー状態になる場合があります。詳細は、「AWTキャッシュ・グループの使用の制限」を参照してください。 |
AWTキャッシュ・グループはTimesTenデータベースからOracle Databaseにデータを伝播するため、Oracle Databaseのキャッシュ表でユーザーが変更したデータは、Oracle DatabaseからTimesTenデータベースに自動的にはアップロードされません。この場合は、TimesTenにおいてAWTキャッシュ・グループを明示的にアンロードしてからリロードする必要があります。
TimesTenデータベースでのトランザクションのコミットは、Oracle Databaseでのコミットとは非同期に実行されます。これにより、アプリケーションはOracle Databaseトランザクションの完了を待機することなく、継続してTimesTenデータベースに対してトランザクションを発行できます。ただし、アプリケーションでは、Oracle Database上でトランザクションが完了するタイミングを確認できません。
AWTキャッシュ・グループに対するUNLOAD CACHE GROUP文の実行は、行に対する更新がOracle Databaseに伝播されるまで待機します。
AWTキャッシュ・グループ内のキャッシュ表は、Oracle Databaseが利用できない場合も更新できます。Oracle Databaseが処理を再開すると、Oracle Databaseが利用できなかった間にキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に伝播されます。
Oracle Databaseに伝播しないDML文からの更新が存在する場合は、ttCachePropagateFlagSet組込みプロシージャでフラグを0 (ゼロ)に設定することによって、Oracle Databaseに対する現在のトランザクション内でコミットされた更新の伝播を無効(DML文の実行によって)にできます。このフラグを0 (ゼロ)に設定した後、DML文の実行の影響はバックエンドのOracle Databaseに伝播されることはありません。そのため、これらの更新はTimesTenデータベース上にのみ存在します。後で、ttCachePropagateFlagSet組込みプロシージャでこのフラグを1に再設定することによって、伝播を再有効化できます。このフラグの設定を1に戻した後は、Oracle Databaseに対してすべてのコミットされた更新の伝播が再開されます。伝播フラグは、トランザクションのコミット後またはロールバック後に自動的に1に再設定されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCachePropagateFlagSetに関する説明を参照してください。
|
ノート: TimesTenでAWTキャッシュ・グループの操作を管理する場合、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続します。ttCacheUidPwdSetの詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。 |
例4-2、例4-16および例4-18に定義されたAWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。
CREATE TABLE customer (cust_num NUMBER(6) NOT NULL PRIMARY KEY, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100));
キャッシュ・マネージャ・ユーザーが、oratt.customer表をキャッシュするAWTキャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。Oracle Databaseに対して非同期ライトスルー処理を行うには、oratt.customer表においてキャッシュ管理ユーザーに、INSERT、UPDATEおよびDELETEのOracle Database権限が付与されている必要があります。
AWTキャッシュ・グループを作成するには、CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用します。
次の文では、oratt.customer表をキャッシュする、AWTキャッシュ・グループnew_customersが作成されます。
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num));
次の各項では、AWTキャッシュ・グループの構成、動作および管理について説明します。
非同期ライトスルー処理を実行するには、AWTキャッシュ・グループを含むTimesTenデータベース上でレプリケーション・エージェントが実行されている必要があります。CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を実行すると、TimesTenキャッシュ表上でコミットされた更新を、キャッシュされたOracle Database表に非同期に伝播できるレプリケーション・スキームが作成されます。
AWTキャッシュ・グループを作成した後、TimesTenデータベース上でレプリケーション・エージェントを起動します。
キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、レプリケーション・エージェントをプログラムから手動で起動できます。
% ttIsql "DSN=cache1;UID=cacheuser;PWD=timesten;OraclePWD=oracle" Command> call ttRepStart;
また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -repStartユーティリティ・コマンドを実行することによって、コマンドラインから起動することもできます。
% ttAdmin -repStart cache1
TimesTenデータベースに1つ以上のAWTキャッシュ・グループまたはレプリケーション・スキームがない場合、レプリケーション・エージェントは起動しません。
レプリケーション・エージェントが実行されている場合は、AWTキャッシュ・グループに対して別のCREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文またはDROP CACHE GROUP文を発行する前にエージェントを停止する必要があります。
キャッシュ・マネージャ・ユーザーとしてttRepStop組込みプロシージャをコールすることによって、レプリケーション・エージェントをプログラムから手動で停止できます。
Command> call ttRepStop;
また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -repStopユーティリティ・コマンドを実行することによって、コマンドラインから停止することもできます。
% ttAdmin -repStop cache1
レプリケーション・エージェント起動ポリシーを設定して、TimesTenデータベースでレプリケーション・エージェント・プロセスを起動する方法およびタイミングを決定できます。
デフォルトの起動ポリシーはmanualであり、これはttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行することによって、手動でレプリケーション・エージェントを起動する必要があることを意味します。実行しているレプリケーション・エージェント・プロセスを手動で停止するには、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行します。
TimesTenメイン・デーモン・プロセスの起動時にレプリケーション・エージェントを自動的に起動できるように、起動ポリシーをalwaysに設定することもできます。always起動ポリシーを使用しているときは、メイン・デーモンを実行している間、レプリケーション・エージェントを停止できませんが、起動ポリシーをmanualまたはnorestartに変更した後、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行して手動停止を発行すると、レプリケーション・エージェントを停止できます。
manualおよびalways起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後、レプリケーション・エージェントは自動的に再起動されます。
起動ポリシーをnorestartに設定することもできます。この場合、レプリケーション・エージェントを手動で起動するには、ttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行する必要があります。また、手動で停止するには、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行する必要があります。
norestart起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後でも、レプリケーション・エージェントは自動的に再起動されません。ttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行して、レプリケーション・エージェントを手動で再起動する必要があります。
インスタンス管理者として、キャッシュ・マネージャ・ユーザーにADMIN権限を付与します。
% ttIsql cache1 Command> GRANT ADMIN TO cacheuser; Command> exit
レプリケーション・エージェント起動ポリシーは、キャッシュ・マネージャ・ユーザーとしてttRepPolicySet組込みプロシージャをコールすることによって、プログラムで設定できます。
% ttIsql "DSN=cache1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttRepPolicySet('manual');
Command> exit
また、ADMIN権限を持つTimesTen外部ユーザーとしてttAdmin -repPolicyユーティリティ・コマンドを実行することによって、コマンドラインから設定することもできます。
% ttAdmin -repPolicy always cache1
AWTキャッシュ・グループでは、レプリケーション・エージェントを使用してOracle Databaseにトランザクションを非同期に伝播するため、これらのトランザクションがOracle Databaseで完全に処理されたことをレプリケーション・エージェントが確認するまで、トランザクションはトランザクション・ログ・バッファおよびトランザクション・ログ・ファイルに保持されます。ttLogholds組込みプロシージャを使用して、これらのトランザクションの伝播を監視できます。ttLogHolds組込みプロシージャをコールすると、AWTキャッシュ・グループの伝播用に保持されているトランザクション・ログを区別するために、説明フィールドには_ORACLEと記されます。
Command> call ttLogHolds(); < 0, 18958336, Checkpoint , cache1.ds0 > < 0, 19048448, Checkpoint , cache1.ds1 > < 0, 19050904, Replication , ADC6160529:_ORACLE > 3 rows found.
ttLogHolds組込みプロシージャの詳細およびブックマークおよびログ順序番号を使用したレプリケーションの監視方法については、Oracle TimesTen In-Memory Databaseレプリケーション・ガイドのレプリケートされたログ・レコードの表示を参照してください。
AWTキャッシュ・グループのスループットを向上させるために、パラレル動作でトランザクションの変更をOracle Databaseに伝播および適用する複数のスレッドを構成できます。パラレル伝播では、トランザクションの依存性に従って、AWTキャッシュ表の変更をコミット順にOracle Database表に適用します。
パラレル伝播は、AWTキャッシュ・グループにおいて次の構成でサポートされます。
アクティブ・スタンバイ・ペア・レプリケーション・スキームに関連するAWTキャッシュ・グループ
単一のTimesTenデータベース内のAWTキャッシュ・グループ(レプリケーション・スキーム構成なし)
いずれかのエージング・ポリシーで構成されたAWTキャッシュ・グループ
次のデータ・ストア属性を使用すると、パラレル伝播を有効化し、パラレル動作で変更をAWTキャッシュ表から対応するOracle Database表に伝播するスレッドの数を制御できます。
ReplicationParallelismは、レプリケーション・スキームでパラレル・レプリケーションを行う場合のソース・データベースでの送信側スレッド数およびターゲット・データベースでの受信側スレッド数を定義します。パラレル・レプリケーションのためだけに使用される場合、この値は2から32の間で指定できます。デフォルトは1です。また、ReplicationParellelismの値は、LogBufParallelismの値の半分を超えてはなりません。
CacheAWTParallelism(設定時)では、AWTキャッシュ表からOracle Database表への変更のパラレル伝播で使用されるスレッド数を決定します。この属性は2から31の間で設定します。デフォルトは1です。
AWTキャッシュ・グループのパラレル伝播は、次のシナリオのうちいずれかを使用して構成されます。
ReplicationApplyOrderingを0に、ReplicationParallelismを1より大きな値に設定します。
CacheAWTParallelismを設定しない場合、Oracle Databaseに変更を適用するスレッドの数は、ReplicationParallelismの設定の2倍になります。たとえば、ReplicationParallelism=3の場合、Oracle Database表に変更を適用するスレッドの数は6です。この場合、ReplicationParallelismは2から16の間でのみ設定可能で、それ以外の値を使用すると、2倍になった値がパラレル伝播の最大スレッド数である31を超えてしまいます。この値を16に設定すると、最大スレッド数のデフォルト値は31になります。
ReplicationApplyOrderingを0に、ReplicationParallelismを1以上の値に、CacheAWTParallelismを1より大きな値に設定します。CacheAWTParallelismには、ReplicationParallelismで設定された値以上の値で、かつ31以下の値を指定する必要があります。
CacheAWTParallelismを指定しない場合、Oracle Databaseへのパラレル伝播に使用するスレッド数はReplicationParallelismを使用して決定されます。ただし、この値はパラレル伝播のスレッドに使用すると2倍になるため、ReplicationParallelismに設定できるのは2から16の間の数のみです。この値を16に設定すると、最大スレッド数のデフォルト値は31になります。
ReplicationParallelism属性とCacheAWTParallelism属性の両方が設定されている場合は、CacheAWTParallelismに設定される値がパラレル伝播で使用するスレッド数を構成します。CacheAWTParallelismの設定によって、パラレル伝播に適用されるスレッドの数が決まり、またReplicationParallelismの設定によって、パラレル・レプリケーションのスレッド数が決まります。これからわかるように、ReplicationParallelismを4に、CacheAWTParallelismを6に設定すると、Oracle Database表に変更を適用するスレッドの数は6になります。これにより、Oracle Database表へのパラレル・レプリケーションとパラレル伝播に使用するスレッド数を異ならせることができます。
|
ノート: パラレル・レプリケーションの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のパラレル・レプリケーションの構成に関する説明を参照してください。これらのデータ・ストア属性の詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのReplicationApplyOrdering、ReplicationParallelismおよびCacheAWTParallelismを参照してください。 |
これらのデータ・ストア属性は、相互に関連性があります。表4-1に、使用可能な各種属性値の組合せ結果を示します。
表4-1 パラレル伝播のデータ・ストア属性関係の結果
| ReplicationApply Ordering |
ReplicationParallelism | CacheAWTParallelism | パラレル伝播のスレッド数 |
|---|---|---|---|
|
0に設定(パラレル伝播を有効化) |
複数のトラックを使用するために1より大きい16以下の値を設定します。 |
指定しません。 |
|
|
0に設定(パラレル伝播を有効化) |
複数のトラックを使用するために16より大きい32以下の値を設定します。 |
指定しません。 |
エラーがスローされます。 |
|
0に設定(パラレル伝播を有効化) |
複数のトラックを使用するために1より大きい32以下の値を設定します。 |
|
|
|
0に設定(パラレル伝播を有効化) |
複数のトラックを使用するために1より大きい32以下の値を設定します。 |
|
データベース作成時にエラーがスローされます。 |
|
0に設定(パラレル伝播を有効化) |
1を設定するかまたは指定しません。シングル・トラック。 |
1より大きな値を設定します。 |
|
|
1に設定(パラレル伝播を無効化)。 |
N/A |
1より大きな値を設定します。 |
パラレル化が無効になっているのに、パラレル伝播が有効化されることを見込んで |
キャッシュされるOracle Database表の外部キーには、その外部キーに対する索引を作成する必要があります。次のOracle Database表について考えてみます。
CREATE TABLE parent (c1 NUMBER PRIMARY KEY NOT NULL);
CREATE TABLE child (c1 NUMBER PRIMARY KEY NOT NULL,
c2 NUMBER REFERENCES parent(c1));
CREATE TABLE grchild (c1 NUMBER PRIMARY KEY NOT NULL,
c2 NUMBER REFERENCES parent(c1),
c3 NUMBER REFERENCES parent(c1));
次の索引を作成する必要があります。
CREATE INDEX idx_1 ON child(c2); CREATE INDEX idx_2 ON grchild(c2); CREATE INDEX idx_3 ON grchild(c3);
AWTキャッシュ・グループでパラレル伝播を使用する場合は、データの整合性を手動で維持する必要があります。キャッシュされるOracle Database表の列に対する任意の一意索引、一意制約または外部キー制約は、TimesTen内のAWTキャッシュ表でも作成する必要があります。AWTキャッシュ表でこれらの制約を作成できずにパラレル伝播用に構成すると、TimesTenは制約が欠落している表に対してDML処理によりすべてのトランザクションをシリアライズします。たとえば、Oracle Databaseの表に対して作成された一意索引がTimesTenの対応するキャッシュ表に対して作成できない場合、この表に関するすべてのトランザクションがシリアライズされます。
TimesTenは、次のSQL文のいずれかが発行された場合に、TimesTenでキャッシュされていないOracle Databaseにおいて制約の欠落を自動的にチェックします。
AWTキャッシュ・グループをCREATE ASYNCHRONOUS CACHE GROUP文で作成する場合
AWTキャッシュ表に対してCREATE UNIQUE INDEX文で一意索引を作成する場合
AWTキャッシュ表に対してDROP INDEX文で一意索引を削除する場合
|
ノート: ttCacheCheck組込みプロシージャにより、制約の欠落のチェックを手動で開始できます。たとえば、TimesTenは、キャッシュされたOracle Database表でスキーマが変更された後は、制約の欠落を自動的にはチェックしません。Oracle Databaseでスキーマが変更された後には、TimesTenデータベースでttCacheCheckを実行することにより、制約の欠落のチェックを手動で実行する必要があります。
制約の欠落を手動でチェックする必要があるその他の条件については、「制約の欠落チェックの手動開始」を参照してください。 |
チェックによりキャッシュ表で制約が欠落していることが判明した場合、TimesTenは欠落している各制約に関する警告を発行します。
次のシナリオでは、DML処理を含むトランザクションがOracle Databaseに伝播された際にシリアライズされるように、キャッシュ表がマークされます。
一意索引または一意制約が欠落しているAWTキャッシュ表にDML処理を適用するトランザクション。
単一のAWTキャッシュ・グループ内の表に対して外部キー制約が欠落している。
外部キー関係の参照元表と参照先表の両方が同じAWTキャッシュ・グループ内にあり、外部キー関係が定義されていない場合は、両方の表に対してトランザクションのシリアライズを行うようにマークされます。
参照元表はAWTキャッシュ・グループ内にあるが、参照先表はAWTキャッシュ・グループ内にない場合、キャッシュ・グループ内の表に対してはトランザクションのシリアライズを行うようマークはされません。ユーザーに対して、制約が欠落していることを通知する警告が発行されるだけです。
参照先表はAWTキャッシュ・グループ内にあるが、参照元表はAWTキャッシュ・グループ内にない場合、キャッシュ・グループ内の表に対してはトランザクションのシリアライズを行うようマークはされません。ユーザーに対して、制約が欠落していることを通知する警告が発行されるだけです。
キャッシュ・グループ間で外部キー制約が欠落している。外部キー制約が欠落している個別のAWTキャッシュ・グループで表を定義した場合、両方の表に対してトランザクションのシリアライズを行うようにマークされます。
外部キー制約が欠落していることにより、2つのAWTキャッシュ・グループ間の外部キー制約のチェーンが破損した場合は、両方のAWTキャッシュ・グループ内のすべての表に対するトランザクションがシリアライズされます。
|
ノート: Oracle Databaseトリガーにより、TimesTenが認識できない処理上の依存性が発生する場合があります。この場合、AWTキャッシュ・グループでのパラレル伝播を使用不可にするか、またはトリガーが作成されたAWTキャッシュ・グループで表をキャッシュしないようにする必要があります。 |
例4-6 AWTキャッシュ・グループの作成時に制約が欠落している例
次の例では、Oracle Databaseのorattスキーマに2つの表を作成します。active_customer表とordertab表の間には外部キー関係が存在します。この例ではパラレル伝播でこれらの表を使用するため、ordertab表の外部キーに対して索引が作成されます。
SQL> CREATE TABLE active_customer
(custid NUMBER(6) NOT NULL PRIMARY KEY,
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12),
region VARCHAR2(12) DEFAULT 'Unknown');
Table created.
SQL> CREATE TABLE ordertab
(orderid NUMBER(10) NOT NULL PRIMARY KEY,
custid NUMBER(6) NOT NULL);
Table created.
SQL> ALTER TABLE ordertab
ADD CONSTRAINT cust_fk
FOREIGN KEY (custid) REFERENCES active_customer(custid);
Table altered.
SQL> CREATE INDEX order_idx on ordertab (custid);
TimesTenは、CREATE CACHE GROUPが発行されるたびに、制約の欠落を自動的にチェックします。次の例では、active_customer表を含む単一のキャッシュ・グループを作成します。active_customerは参照先表であり、参照元表ordertabはAWTキャッシュ・グループ内にないため、警告が発行されるだけです。active_customer表に対しては、トランザクションのシリアライズを行うようマークはされません。
CREATE WRITETHROUGH CACHE GROUP update_cust FROM oratt.active_customer (custid NUMBER(6) NOT NULL PRIMARY KEY, name VARCHAR2(50), addr VARCHAR2(100), zip VARCHAR2(12)); Warning 5297: The following Oracle foreign key constraints on AWT cache table ORATT.ACTIVE_CUSTOMER contain cached columns that do not have corresponding foreign key constraints on TimesTen: ORATT.CUST_FK [Outside of CG].
次の例ではTimesTenで2つのAWTキャッシュ・グループを作成しますが、1つにはactive_customer表が含まれており、もう1つにはordertab表が含まれています。キャッシュ・グループ間では外部キー制約が欠落しています。この場合、両方の表に対して警告が発行されますが、ordertab表が参照元表で外部キーを含んでいる必要があるため、この表に対してのみトランザクションのシリアライズを行うようにマークされます。
CREATE WRITETHROUGH CACHE GROUP update_cust FROM oratt.active_customer (custid NUMBER(6) NOT NULL PRIMARY KEY, name VARCHAR2(50), addr VARCHAR2(100), zip VARCHAR2(12); Warning 5297: The following Oracle foreign key constraints on AWT cache table oratt.update_customer contain cached columns that do not have corresponding foreign key constraints on TimesTen: ordertab.cust_fk [Outside of CG]. CREATE WRITETHROUGH CACHE GROUP update_orders FROM oratt.ordertab (orderid NUMBER(10) NOT NULL PRIMARY KEY, custid NUMBER(6) NOT NULL); Warning 5295: Propagation will be serialized on AWT cache table ORATT.ORDERTAB because the following Oracle foreign key constraints on this table contain cached columns that do not have corresponding foreign key constraints on TimesTen: ORDERTAB.CUST_FK [Across AWT cache groups].
ttCacheCheck組込みプロシージャは、TimesTenが自動的に実行するのと同じ制約の欠落チェックを、Oracle Databaseのキャッシュ表に対して実行します。ttCacheCheckは、伝播のシリアライズを行うようにマークされた表と制約の欠落に関して該当するメッセージを提供します。ttCacheCheck組込みプロシージャを使用すると、TimesTen内の指定されたキャッシュ・グループまたはすべてのキャッシュ・グループに対して制約の欠落のチェックを行い、すべてのキャッシュ・グループにおいて制約が欠落していない状態にできます。
|
ノート: ttCacheCheckはシステム表を更新して、1つの表に対して実行されたDMLをシリアライズする必要があるかないかを示すため、ttCacheCheck組込みプロシージャの完了後にコミットまたはロールバックを行う必要があります。
|
次のシナリオのいずれかの後に、ttCacheCheck組込みプロシージャを手動でコールし、既知の依存性を更新する必要があります。
DROP CACHE GROUP文によりTimesTenで一連のAWTキャッシュ・グループを削除した後。
AWTキャッシュ・グループにキャッシュされているOracle Databaseにおいて一意索引、一意制約または外部キーを追加または削除した後。制約の追加後にttCacheCheck組込みプロシージャをコールしない場合、AWTキャッシュ・グループでランタイム・エラーが発生する可能性があります。制約を削除すると、TimesTenは必要がない場合でもトランザクションをシリアライズすることがあります。ttCacheCheck組込みプロシージャをコールすると、シリアライズが必要かどうかが確認されます。
この組込みプロシージャを使用すると、いくつかのトランザクションがシリアライズされている理由を判別できます。
|
ノート: ttCacheCheck組込みプロシージャは、レプリケーション・エージェントの実行中にはコールできません。
複数のキャッシュ・グループで |
例4-7 ttCacheCheckの手動実行による欠落している依存性の更新
次に、ユーザーがttCacheCheck組込みプロシージャを手動で実行し、cacheuserが所有しているAWTキャッシュ・グループupdate_ordersで制約が欠落しているかどうかを判別する例を示します。エラー・メッセージを含む結果セットが返されています。update_ordersキャッシュ・グループのordertab表に対して、トランザクションをシリアルに伝播するようにマークされています。
Command> call ttCacheCheck(NULL, 'cacheuser', 'update_orders'); < CACHEUSER, UPDATE_ORDERS, CACHEUSER, ORDERTAB, Foreign Key, CACHEUSER, CUST_FK, 1, Transactions updating this table will be serialized to Oracle because: The missing foreign key connects two AWT cache groups., table CACHEUSER.ORDERTAB constraint CACHEUSER.CUST_FK foreign key(CUSTID) references CACHEUSER.ACTIVE_CUSTOMER(CUSTID) > 1 row found.
TimesTenデータベースまたはOracle Databaseでキャッシュ・グループ・スキーマが変更されるたびに、すべてのAWTキャッシュ・グループに対してttCacheCheckをコールすることにより、すべての制約を確認できます。次に、ユーザーがttCacheCheck組込みプロシージャを手動で実行し、すべての入力パラメータに対してNULL値を指定することにより、全TimesTenデータベース内のAWTキャッシュ・グループで制約が欠落しているかどうかを判別する例を示します。エラー・メッセージを含む結果セットが返されています。
Command> call ttCacheCheck(NULL, NULL, NULL); < CACHEUSER, UPDATE_ORDERS, CACHEUSER, ORDERTAB, Foreign Key, CACHEUSER, CUST_FK, 1, Transactions updating this table will be serialized to Oracle because: The missing foreign key connects two AWT cache groups., table CACHEUSER.ORDERTAB constraint CACHEUSER.CUST_FK foreign key(CUSTID) references CACHEUSER.ACTIVE_CUSTOMER(CUSTID) > 1 row found.
AWTキャッシュ・グループを使用する際に、TimesTenはバックエンドOracle Databaseに対してパラレルに適用される1つ以上のトランザクションをバッチ処理します。CacheParAwtBatchSizeパラメータにより、1度のバッチ処理に含まれる行数に対してしきい値を設定します。行数が最大値に到達すると、TimesTenはトランザクションに残りの行を含めますが(TimesTenはトランザクションを分割はしません)、バッチ処理にこれ以上のトランザクションは追加しません。
たとえば、ユーザーがCacheParAwtBatchSizeを200に設定したとします。次のAWT伝播では、それぞれ120行を持つ3つのトランザクションが存在し、それらを伝播してOracle Databaseに適用する必要があります。TimesTenは、1回目のバッチ処理に最初の2つのトランザクション(合計240行)を組み込みます。3つ目のトランザクションは2回目のバッチ処理に組み込まれます。
CacheParAwtBatchSizeパラメータのデフォルト値は125行です。最小値は1です。ttDBConfig組込みプロシージャのCacheParAwtBatchSizeパラメータの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttDBConfigを参照してください。
CacheParAwtBatchSizeの現在の値を取得するには、次のようにします。
call ttDBConfig('CacheParAwtBatchSize');
< CACHEPARAWTBATCHSIZE, 125 >
1 row found.
CacheParAwtBatchSizeパラメータを200に設定するには、次のようにします。
call ttDBConfig('CacheParAwtBatchSize','200');
< CACHEPARAWTBATCHSIZE, 200 >
1 row found
Oracleサポートがワークロードとそのワークロード内のすべての依存性を分析し、CacheParAwtBatchSizeを別の値にした方がパフォーマンスが向上する可能性があるかどうかを判別しますので、指示があった場合にのみCacheParAwtBatchSizeパラメータを設定してください。複数のトランザクションが同じデータを同時に変更している場合は、依存性が存在します。ワークロード内にあまりにも多数の依存性が存在する場合には、Oracleサポートからこの値を小さくするように提案させていただく場合があります。
AWTキャッシュ・グループでは、次のことが保証されます。
TimesTenデータベースとOracle Databaseの間の通信障害が原因でトランザクションが失われないこと。
レプリケーション・エージェントが実行されていない場合またはOracle Databaseへの接続を失った場合は、エージェントの再起動後またはOracle Databaseに再接続後に、TimesTenキャッシュ表に対してコミットされた更新を、キャッシュされたOracle Database表に自動伝播する処理が再開されること。
トランザクションが、TimesTenデータベースでコミットされた順序と同じ順序で、Oracle Databaseでもコミットされること。
AWTキャッシュ・グループでは、次のことが保証されません。
TimesTenデータベースでコミットが成功したすべてのトランザクションが、Oracle Databaseに正しく伝播され、コミットされること。Oracle Databaseで実行エラーが発生すると、Oracle Databaseのトランザクションがロールバックされます。たとえば、一意制約違反のためにOracle Databaseでの更新が失敗する可能性があります。実行エラーが発生したトランザクションは再試行されません。
実行エラーは永続エラーであるとみなされ、TimesTenデータベースのチェックポイント・ファイルと同じディレクトリに存在するTimesTenDatabaseFileName.awterrsファイルにレポートされます。詳細は、「AWTキャッシュ・グループでのOracle Database永続エラーのレポート」を参照してください。
Oracle Database更新の絶対順序が保存されること(TimesTenは更新競合を解決しないため)。次に例を示します。
2つの異なるTimesTenデータベース(DB1およびDB2)で、異なるAWTキャッシュ・グループが同じOracle Database表をキャッシュしています。DB1内のキャッシュ表で、更新がコミットされます。次に、DB2内のキャッシュ表で、更新がコミットされます。2つのキャッシュ表は異なるTimesTenデータベースに存在し、同じOracle Database表をキャッシュしています。ライトスルー操作は非同期であるため、DB2の更新がOracle Databaseに伝播されてから、DB1の更新が伝播される場合があり、この結果、DB1の更新によって、DB2の更新が上書きされます。
AWTキャッシュ・グループ内のキャッシュ表で更新がコミットされます。この同じ更新が、パススルー処理を使用して、キャッシュされたOracle Database表でコミットされます。キャッシュ表の更新は、Oracle Databaseに自動的に非同期で伝播されますが、伝播された更新とパススルーされた更新をOracle Databaseで処理するタイミングによっては、キャッシュされたOracle Database表で直接処理される、パススルーされた更新を上書きする場合があります。この状態と他に発生する可能性がある状態に備えて、TimesTenでは、AWTキャッシュ・グループにキャッシュされているOracle Database表に対して、直接DML文を実行しないことをお薦めします。詳細は、「AWTキャッシュ・グループの使用の制限」を参照してください。
AWTキャッシュ・グループを使用する場合は、次の制限が適用されます。
キャッシュ表定義では、ON DELETE CASCADEおよびUNIQUE HASH ONキャッシュ表属性のみを使用できます。
ON DELETE CASCADEキャッシュ表属性の詳細は、「ON DELETE CASCADEキャッシュ表属性」を参照してください。
UNIQUE HASH ONキャッシュ表属性の詳細は、「UNIQUE HASH ONキャッシュ表属性」を参照してください。
キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。
キャッシュ表定義にWHERE句を含めることはできません。
キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。
キャッシュ表に対してTRUNCATE TABLE文を発行できません。
AWTキャッシュ・グループでは、Oracle Databaseビューまたはマテリアライズド・ビューをキャッシュできません。
AWTキャッシュ・グループを作成または削除する前にレプリケーション・エージェントを停止する必要があります。
レプリケーション・エージェントの停止方法および起動方法の詳細は、「レプリケーション・エージェントの管理」を参照してください。
レプリケーション・エージェントが実行されていない場合、TimesTenキャッシュ表でコミットされた更新は、キャッシュされたOracle Database表に伝播されません。
AWTキャッシュ・グループを作成するには、TimesTenデータベースの絶対パス名の長さを248文字以内にする必要があります。
AWTキャッシュ・グループにキャッシュされているOracle Database表では、DML文を実行することは避けてください。これにより、エラー状態になる場合があります。キャッシュされたOracle Database表で挿入、更新または削除処理のいずれかを行うと、処理対象の行に対してTimesTenで実行される処理に不適切な影響を与える場合があります。TimesTenでは、Oracle Databaseで発生する更新競合は検出または解決されません。キャッシュされたOracle Database表で直接コミットされた更新は、キャッシュ表の更新がOracle Databaseに伝播されたときに、TimesTenキャッシュ表でコミットされた更新によって上書きされる場合があります。さらに、キャッシュされたOracle Database表で行を削除すると、TimesTenがすでに存在しない行に対して更新を試みたときに、更新が適用されなくなる場合があります。
Oracle DatabaseですべてのデータがDML文から制限を受けることがないようにするために、Oracle Databaseでデータを分割して、AWTキャッシュ・グループに含まれているデータとAWTキャッシュ・グループから除外されるデータとを分けることができます。
TimesTenでは、単一のSQL文によって一意索引の制約違反が発生するかどうかを判別するときに、遅延チェックを実行します。
たとえば、キャッシュされたOracle Database表のNUMBER列に一意索引があり、TimesTenキャッシュ表の同じNUMBER列にも一意索引があるとします。キャッシュされたOracle Database表には5つの行があり、キャッシュ表にも同じ5つの行があります。NUMBER列の値の範囲は1から5です。
キャッシュ表に対してUPDATE文を発行し、すべての行のNUMBER列の値を1増分します。この処理は、キャッシュ表では成功しますが、キャッシュされたOracle Database表に伝播されると失敗します。
これは、TimesTenでは、一意索引の制約のチェックが、すべての行が更新された後、文の実行の最後に行われるために発生します。ただし、Oracle Databaseでは、1行更新されるたびに制約のチェックが実行されます。
したがって、NUMBER列の値が1であるキャッシュ表の行が2に変更され、この更新がOracle Databaseに伝播されると、キャッシュされたOracle Database表のNUMBER列の値が2となった行で一意制約違反が発生します。
トランザクションが正常に伝播されず、Oracle Databaseにコミットされない場合は、こうした永続エラーによりOracle Databaseのトランザクションがロール・バックされます。たとえば、一意制約違反のためにOracle Databaseでの更新が失敗する可能性があります。永続エラーが発生したトランザクションは再試行されません。
永続エラーは常に、TimesTenデータベースのチェックポイント・ファイルと同じディレクトリに存在するTimesTenDatabaseFileName.awterrsテキスト・ファイルにレポートされます。このファイルの内容の詳細は、『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』のTimesTen for AWTによって報告されるOracle Databaseエラーに関する説明を参照してください。
ttCacheConfig組込みプロシージャにより、ASCIIおよびXMLの両方の書式でこれらのエラーをレポートするようにTimesTenを構成できます。
|
ノート: エラー・ファイルの書式の設定にはttCacheConfigのtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。 |
TimesTenDatabaseFileName.awterrsテキスト・ファイルのみに永続エラーをレポートするようにTimesTenを構成するには、ASCIIパラメータを指定してttCacheConfig組込みプロシージャをコールします。これがデフォルトです。
Command> call ttCacheConfig('AwtErrorXmlOutput',,,'ASCII');
TimesTenDatabaseFileName.awterrsテキスト・ファイルとTimesTenDatabaseFileName.awterrs.xmlという名前のXMLファイルの両方に永続エラーをレポートするようにTimesTenを構成するには、XMLパラメータを指定してttCacheConfig組込みプロシージャをコールします。
Command> call ttCacheConfig('AwtErrorXmlOutput',,,'XML');
|
ノート: 永続エラーをXMLファイルにレポートするためにttCacheConfigをコールする前に、まずレプリケーション・エージェントを停止する必要があります。次に、組込みプロシージャの完了後に、レプリケーション・エージェントを再起動します。
この組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する説明を参照してください。 |
エラーをXML書式でレポートするように構成すると、Oracle Database永続エラーが発生したときに、次の2つのファイルが生成されます。
TimesTenDatabaseFileName.awterrs.xml。このファイルには、Oracle Database永続エラー・メッセージがXML書式で記載されています。
TimesTenDatabaseFileName.awterrs.dtd。このファイルにはXML Document Type Definition (DTD)が記載されており、これはTimesTenDatabaseFileName.awterrs.xmlファイルの解析に使用します。
XML DTDは、エラーのログを含む有効なXMLファイルの要素および構造を記述した一連のマークアップ宣言であり、XML 1.0仕様に基づいています。XMLファイルはUTF-8を使用してエンコードされます。次に、XML書式で記述された要素を示します。
<!ELEMENT ttawterrorreport (awterrentry*) > <!ELEMENT awterrentry(header, (failedop)?, failedtxn) > <!ELEMENT header (time, datastore, oracleid, transmittingagent, errorstr, (ctn)?, (batchid)?, (depbatchid)?) > <!ELEMENT failedop (sql) > <!ELEMENT failedtxn ((sql)+) > <!ELEMENT time (hour, min, sec, year, month, day) > <!ELEMENT hour (#PCDATA) > <!ELEMENT min (#PCDATA) > <!ELEMENT sec (#PCDATA) > <!ELEMENT year (#PCDATA) > <!ELEMENT month (#PCDATA) > <!ELEMENT day (#PCDATA) > <!ELEMENT datastore (#PCDATA) > <!ELEMENT oracleid (#PCDATA) > <!ELEMENT transmittingagent (transmitingname, pid, threadid) > <!ELEMENT pid (#PCDATA) > <!ELEMENT threadid (#PCDATA) > <!ELEMENT transmittingname (#PCDATA) > <!ELEMENT errorstr (#PCDATA) > <!ELEMENT ctn (timestamp, seqnum) > <!ELEMENT timestamp(#PCDATA) > <!ELEMENT seqnum(#PCDATA) > <!ELEMENT batchid(#PCDATA) > <!ELEMENT depbatchid(#PCDATA) > <!ELEMENT sql(#PCDATA) >
同期ライトスルー(SWT)キャッシュ・グループでは、図4-7に示すように、TimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に同期して伝播されるというキャッシュ動作が実行されます。
|
ノート: SWTキャッシュ・グループにキャッシュされているOracle Database表では、DML文を実行することは避けてください。実行すると、エラー状態になる場合があります。詳細は、「SWTキャッシュ・グループの使用の制限」を参照してください。 |
TimesTenデータベースでのトランザクションのコミットは、Oracle Databaseでのコミットと同期して実行されます。アプリケーションによってTimesTenデータベースでトランザクションがコミットされると、このトランザクションは、TimesTenで処理される前にOracle Databaseで処理されます。Oracle DatabaseとTimesTenデータベースの両方でトランザクションが完了するまで、アプリケーションはブロックされます。
トランザクションがOracle Databaseでのコミットに失敗した場合、アプリケーションはTimesTenでトランザクションをロールバックする必要があります。Oracle Databaseトランザクションのコミットが成功し、TimesTenトランザクションのコミットが失敗した場合、SWTキャッシュ・グループ内のキャッシュ表は、キャッシュされたOracle Database表と同期化されなくなります。
|
ノート: 伝播された更新をコミットする際に、TimesTenデータベースとOracle Databaseの両方でコミットが発生する仕組みにおける動作およびエラー状態は、PROPAGATEキャッシュ表属性で説明されているPROPAGATEキャッシュ属性を持つユーザー管理キャッシュ・グループに対するのと同じコミット・プロセスです。 |
キャッシュされたOracle Database表とキャッシュ表を手動で再同期化するには、ttCachePropagateFlagSet組込みプロシージャをコールして更新の伝播を無効にしてから、TimesTenでトランザクションのコミットが失敗した原因となった問題を修正した後、TimesTenデータベースでトランザクションを再発行します。次に、ttCachePropagateFlagSet組込みプロシージャをコールして、更新の伝播を再度有効化します。また、付随するキャッシュ・グループをリロードすることによって、キャッシュされたOracle Database表とキャッシュ表を再同期化することもできます。
例4-8に定義されたSWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。
CREATE TABLE product (prod_num VARCHAR2(6) NOT NULL PRIMARY KEY, name VARCHAR2(30), price NUMBER(8,2), ship_weight NUMBER(4,1));
キャッシュ・マネージャ・ユーザーが、oratt.product表をキャッシュするSWTキャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。TimesTenキャッシュ表からキャッシュされたOracle Database表に同期ライトスルー処理が実行されるようにするには、このOracle Databaseユーザーにoratt.product表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。
SWTキャッシュ・グループを作成するには、CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用します。
次の文では、oratt.product表をキャッシュするSYNCHRONOUS WRITETHROUGHキャッシュ・グループtop_productsが作成されます。
CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP top_products FROM oratt.product (prod_num VARCHAR2(6) NOT NULL, name VARCHAR2(30), price NUMBER(8,2), ship_weight NUMBER(4,1), PRIMARY KEY(prod_num));
TimesTenでSWTキャッシュ・グループの操作を管理する場合、TimesTenは、ユーザーの現在の資格証明をユーザー名に、OraclePwd接続属性をOracleパスワードに使用してOracle Databaseに接続します。SWTキャッシュ・グループの操作を管理する場合、TimesTenでは、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続しません。詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。
SWTキャッシュ・グループを使用する場合は、次の制限が適用されます。
キャッシュ表定義では、ON DELETE CASCADEおよびUNIQUE HASH ONキャッシュ表属性のみを使用できます。
ON DELETE CASCADEキャッシュ表属性の詳細は、「ON DELETE CASCADEキャッシュ表属性」を参照してください。
UNIQUE HASH ONキャッシュ表属性の詳細は、「UNIQUE HASH ONキャッシュ表属性」を参照してください。
キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください
キャッシュ表定義にWHERE句を含めることはできません。
キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。
キャッシュ表に対してTRUNCATE TABLE文を発行できません。
SWTキャッシュ・グループでは、Oracle Databaseビューまたはマテリアライズド・ビューをキャッシュできません。
SWTキャッシュ・グループにキャッシュされているOracle Database表では、直接DML文を実行することは避けてください。これにより、エラー状態になる場合があります。キャッシュされたOracle Database表で挿入、更新または削除処理のいずれかを行うと、処理対象の行に対してTimesTenで実行される処理に不適切な影響を与える場合があります。TimesTenでは、Oracle Databaseで発生する更新競合は検出または解決されません。キャッシュされたOracle Database表で直接コミットされた更新は、キャッシュ表の更新がOracle Databaseに伝播されたときに、TimesTenキャッシュ表でコミットされた更新によって上書きされる場合があります。さらに、キャッシュされたOracle Database表で行を削除すると、TimesTenがすでに存在しない行に対して更新を試みたときに、更新が適用されなくなる場合があります。
Oracle DatabaseですべてのデータがDML文から制限を受けることがないようにするために、Oracle Databaseでデータを分割して、SWTキャッシュ・グループに含まれているデータとSWTキャッシュ・グループから除外されるデータとを分けることができます。
システム管理キャッシュ・グループ(読取り専用、AWT、SWT)がアプリケーションの要件を満たさない場合は、次のキャッシュ表属性の1つ以上を持つ、カスタマイズされたキャッシュ動作を定義するユーザー管理キャッシュ・グループを作成できます。
|
ノート: TimesTenでユーザー管理キャッシュ・グループの操作を管理する場合、TimesTenは、ユーザーの現在の資格証明をユーザー名に、OraclePwd接続属性をOracleパスワードに使用してOracle Databaseに接続します。ユーザー管理キャッシュ・グループの操作では、TimesTenは、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続しません。詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。 |
ユーザー管理キャッシュ・グループ内の各キャッシュ表に対してREADONLYキャッシュ表属性を指定すると、TimesTenでデータがOracle Databaseから表レベルでリフレッシュされる読取り専用の動作を定義できます。
ユーザー管理キャッシュ・グループ内の各キャッシュ表に対してPROPAGATEキャッシュ表属性を指定すると、表レベルで同期ライトスルーの動作を定義できます。PROPAGATEキャッシュ表属性は、キャッシュ表に対してコミットされた更新が、キャッシュされたOracle Database表に自動的に同期して伝播されるように指定します。
ユーザー管理キャッシュ・グループは、AUTOREFRESHキャッシュ・グループ属性およびPROPAGATEキャッシュ表属性を使用することによって、コミットされた更新をOracle DatabaseとTimesTenデータベースの間で自動的にリフレッシュおよび伝播するように定義できます。両方の属性を使用すると、双方向送信が可能になるため、TimesTenキャッシュ表またはキャッシュされたOracle Database表に対してコミットされた更新が、相互に伝播またはリフレッシュされます。
自動リフレッシュのモード、間隔および状態の定義の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。
LOAD CACHE GROUP文、REFRESH CACHE GROUP文およびFLUSH CACHE GROUP文を使用して、Oracle DatabaseとTimesTenデータベースの間でのコミットされた更新の送信を手動で制御できます。
LOAD CACHE GROUP文およびREFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。
PROPAGATEキャッシュ・グループ属性もAUTOREFRESHキャッシュ・グループ属性も使用しないユーザー管理キャッシュ・グループに、Oracle Databaseマテリアライズド・ビューをキャッシュできます。キャッシュ・グループは、手動でロードおよびフラッシュする必要があります。Oracle Databaseビューはキャッシュできません。
次の各項では、ユーザー管理キャッシュ・グループについて詳しく説明します。
READONLYキャッシュ表属性は、ユーザー管理キャッシュ・グループ内のキャッシュ表に対してのみ指定できます。READONLYは、キャッシュ表が直接更新されないように指定します。デフォルトでは、ユーザー管理キャッシュ・グループ内のキャッシュ表は更新可能です。
すべてのキャッシュ表が読取り専用である読取り専用キャッシュ・グループとは異なり、ユーザー管理キャッシュ・グループでは、READONLYキャッシュ表属性を使用して、個々のキャッシュ表を読取り専用に指定できます。
例4-10では、oratt.cust_interestsキャッシュ表のREADONLYキャッシュ表属性を示します。
READONLYキャッシュ表属性を使用する場合は、次の制限が適用されます。
キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、すべてのキャッシュ表でREADONLYキャッシュ表属性を指定するか、またはいずれのキャッシュ表にもREADONLYキャッシュ表属性を指定しないようにする必要があります。
AUTOREFRESHキャッシュ・グループ属性の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。
READONLYとPROPAGATEキャッシュ表属性の両方を同じキャッシュ表で使用することはできません。
PROPAGATEキャッシュ表属性の詳細は、「PROPAGATEキャッシュ表属性」を参照してください。
1つ以上のキャッシュ表でREADONLYキャッシュ表属性もPROPAGATEキャッシュ表属性も使用していない場合を除いて、キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。
キャッシュ表にREADONLYキャッシュ表属性が指定されると、キャッシュ・グループを削除して再度作成する場合を除いて、この属性を変更できません。
PROPAGATEキャッシュ表属性は、ユーザー管理キャッシュ・グループ内のキャッシュ表に対してのみ指定できます。PROPAGATEは、TimesTenトランザクションの一部としてTimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に同期して伝播されるように指定します。PROPAGATEキャッシュ表属性を指定しない場合、ユーザー管理キャッシュ・グループ内のキャッシュ表のデフォルトの設定は、NOT PROPAGATEキャッシュ表属性になります(キャッシュ表でコミットされた更新は、キャッシュされたOracle表に伝播されません)。
キャッシュ表でアプリケーションによって実行されるSQL文はすべて、キャッシュ表に即座に適用されます。これはの処理はすべて、トランザクションがコミットされるまで、またはメモリーの上限に達するまでバッファされます。この時点で、すべての処理がOracle Database内の表に伝播されます。
|
ノート: TimesTenデータベースまたはそのデーモンが予期せずに失敗した場合、TimesTenデータベースまたはOracle Databaseでのトランザクションの結果は保証されません。 |
トランザクションでの処理はTimesTenデータベースとOracle Databaseの両方の表に適用されるため、コミットのプロセスは次のようになります。
処理がOracle Databaseに伝播されると、Oracle Databaseではまずコミットが試行されます。
Oracle Databaseの表で処理が適用されたときにエラーが発生した場合は、Oracle Databaseの表ですべての処理がロールバックされます。Oracle Databaseでコミットが失敗すると、TimesTenデータベースではコミットが試行されず、アプリケーションはTimesTenトランザクションをロールバックする必要があります。ユーザーが別の文を実行しようとすると、ロールバックが必要であることを示すエラーが表示されます。このため、Oracle DatabaseはTimesTenでコミットされた更新を見落とすことがなくなります。
Oracle Databaseでコミットが成功すると、TimesTenデータベースでコミットが試行されます。
Oracle Databaseでトランザクションが正常にコミットされると、TimesTenでユーザーのトランザクションがコミットされ(トランザクション・ログのコミット・ログ・レコードにより示されます)、アプリケーションに通知されます。TimesTenがローカル・コミットに成功したことを通知する前にアプリケーションが突然終了した場合でも、TimesTenは、トランザクション・ログに保存されている内容を基にして、TimesTenでトランザクションのコミットをファイナライズできます。
Oracle Databaseでトランザクションが正常にコミットされた一方、TimesTenではコミットのステータスを返す前に障害が発生した場合、成功したコミットのレコードはトランザクション・ログには書き込まれず、トランザクションはロールバックされます。
TimesTenでコミットが失敗すると、失敗の原因を示すエラー・メッセージがTimesTenから返されます。この場合は、手動でキャッシュ表をOracle Database表と再同期化する必要があります。
ttCachePropagateFlagSet組込みプロシージャを使用して、TimesTenキャッシュ表でコミットされた更新をOracle Databaseに伝播することを無効化できます。この組込みプロシージャを使用すると、現在のトランザクションでTimesTenのキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に伝播されないようにするために、自動伝播を有効または無効にできます。後で、ttCachePropagateFlagSet組込みプロシージャでこのフラグを1に再設定することによって、DML文の伝播を再有効化できます。このフラグの設定を1に戻した後は、Oracle Databaseに対してコミットされた更新の伝播が再開されます。伝播フラグは、トランザクションのコミット後またはロールバック後に自動的に1に再設定されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCachePropagateFlagSetに関する説明を参照してください。
例4-9では、oratt.active_customerキャッシュ表のPROPAGATEキャッシュ表属性の使用方法を示します。
PROPAGATEキャッシュ表属性を使用する場合は、次の制限が適用されます。
キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、すべてのキャッシュ表でPROPAGATEキャッシュ表属性を指定するか、またはいずれのキャッシュ表にもPROPAGATEキャッシュ表属性を指定しないようにする必要があります。
AUTOREFRESHキャッシュ・グループ属性の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。
キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、いずれのキャッシュ表に対してもNOT PROPAGATEキャッシュ表属性を明示的に指定できません。
PROPAGATEとREADONLYキャッシュ表属性の両方を同じキャッシュ表で使用することはできません。
READONLYキャッシュ表属性の詳細は、「READONLYキャッシュ表属性」を参照してください。
1つ以上のキャッシュ表でPROPAGATEキャッシュ表属性もREADONLYキャッシュ表属性も使用していない場合を除いて、キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。
キャッシュ表にPROPAGATEキャッシュ表属性が指定されると、キャッシュ・グループを削除して再度作成する場合を除いて、この属性を変更できません。
Oracle Databaseマテリアライズド・ビューをキャッシュする場合は、PROPAGATEキャッシュ表属性を使用できません。
TimesTenでは、キャッシュされたOracle Database表で直接更新されたデータが、伝播処理によって上書きされないようにするための競合チェックを実行しません。したがって、TimesTenキャッシュ表またはキャッシュされたOracle Database表で更新を直接実行し、両方の表では更新を実行しないようにしてください。
例4-9および例4-10に定義されたユーザー管理キャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。
CREATE TABLE active_customer (custid NUMBER(6) NOT NULL PRIMARY KEY, name VARCHAR2(50), addr VARCHAR2(100), zip VARCHAR2(12), region VARCHAR2(12) DEFAULT 'Unknown'); CREATE TABLE ordertab (orderid NUMBER(10) NOT NULL PRIMARY KEY, custid NUMBER(6) NOT NULL); CREATE TABLE cust_interests (custid NUMBER(6) NOT NULL, interest VARCHAR2(10) NOT NULL, PRIMARY KEY (custid, interest)); CREATE TABLE orderdetails (orderid NUMBER(10) NOT NULL, itemid NUMBER(8) NOT NULL, quantity NUMBER(4) NOT NULL, PRIMARY KEY (orderid, itemid));
ユーザー管理キャッシュ・グループを作成するには、CREATE USERMANAGED CACHE GROUP文を使用します。
次の文では、図4-8に示すように、oratt.active_customer表をキャッシュするユーザー管理キャッシュ・グループupdate_anywhere_customersが作成されます。
CREATE USERMANAGED CACHE GROUP update_anywhere_customers AUTOREFRESH MODE INCREMENTAL INTERVAL 30 SECONDS FROM oratt.active_customer (custid NUMBER(6) NOT NULL, name VARCHAR2(50), addr VARCHAR2(100), zip VARCHAR2(12), PRIMARY KEY(custid), PROPAGATE);
この例では、oratt.active_customer表のregion以外の列はすべてTimesTenにキャッシュされます。これはPROPAGATEキャッシュ表属性で定義されるため、TimesTenのキャッシュ表oratt.active_customerでコミットされた更新は、キャッシュされたOracle Database表oratt.active_customerに転送されます。ユーザー管理キャッシュ表もAUTOREFRESHキャッシュ属性で定義されるため、Oracle Database表oratt.active_customerでコミットされた更新はすべて、キャッシュ表update_anywhere_customersに転送されます。
キャッシュ・マネージャ・ユーザーが、oratt.active_customer表をキャッシュするユーザー管理キャッシュ・グループを作成できるようにし、キャッシュされたOracle Database表からTimesTenキャッシュ表への自動リフレッシュ処理が実行されるようにするには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。TimesTenキャッシュ表からキャッシュされたOracle Database表に同期ライトスルー処理が実行されるようにするには、コンパニオンOracle Databaseユーザーにoratt.active_customer表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。
この例で、AUTOREFRESHキャッシュ・グループ属性は、キャッシュされたOracle Database表oratt.active_customerに対してコミットされた更新が、TimesTenのoratt.active_customer cache表に30秒ごとに自動的にリフレッシュされるように指定します。
Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成の説明に従って、AUTOREFRESH MODE INCREMENTALキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループの定義済動作を実行するためにOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。
次に、ttIsqlユーティリティのcachesqlgetコマンドを実行して、ユーザー管理キャッシュ・グループにキャッシュされるOracle Database表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトを生成する必要があります。
詳細は、「自動リフレッシュ・キャッシュ・グループ用のOracle Databaseオブジェクトの手動による作成」を参照してください。
次の文では、図4-9に示すように、oratt.active_customer、oratt.ordertab、oratt.cust_interestsおよびoratt.orderdetailsの各表をキャッシュするユーザー管理キャッシュ・グループwestern_customersが作成されます。
CREATE USERMANAGED CACHE GROUP western_customers FROM oratt.active_customer (custid NUMBER(6) NOT NULL, name VARCHAR2(50), addr VARCHAR2(100), zip VARCHAR2(12), region VARCHAR2(12), PRIMARY KEY(custid), PROPAGATE) WHERE (oratt.active_customer.region = 'West'), oratt.ordertab (orderid NUMBER(10) NOT NULL, custid NUMBER(6) NOT NULL, PRIMARY KEY(orderid), FOREIGN KEY(custid) REFERENCES oratt.active_customer(custid), PROPAGATE), oratt.cust_interests (custid NUMBER(6) NOT NULL, interest VARCHAR2(10) NOT NULL, PRIMARY KEY(custid, interest), FOREIGN KEY(custid) REFERENCES oratt.active_customer(custid), READONLY), oratt.orderdetails (orderid NUMBER(10) NOT NULL, itemid NUMBER(8) NOT NULL, quantity NUMBER(4) NOT NULL, PRIMARY KEY(orderid, itemid), FOREIGN KEY(orderid) REFERENCES oratt.ordertab(orderid)) WHERE (oratt.orderdetails.quantity >= 5);
同じ品目を5つ以上注文したWest地域の顧客のみがキャッシュされます。
キャッシュ・マネージャ・ユーザーが、oratt.active_customer、oratt.ordertab、oratt.cust_interestsおよびoratt.orderdetailsの各表すべてをキャッシュするユーザー管理キャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、これらの表に対するSELECT権限が付与されている必要があります。また、これらのTimesTenキャッシュ表からキャッシュされたOracle Database表に同期ライトスルー処理が実行されるようにするには、コンパニオンOracle Databaseユーザーにoratt.active_customer表およびoratt.ordertab表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。
western_customersキャッシュ・グループ内の各キャッシュ表には主キーがあります。各子表は、外部キー制約を使用して親表を参照します。oratt.active_customerルート表およびoratt.orderdetails子表には、それぞれキャッシュされる行を制限するWHERE句が含まれます。oratt.active_customerルート表とoratt.ordertab子表の両方でPROPAGATEキャッシュ表属性を使用しているため、これらのキャッシュ表でコミットされた更新は、キャッシュされたOracle Database表に自動的に伝播されます。oratt.cust_interests子表ではREADONLYキャッシュ表属性を使用しているため、この表は直接更新できません。
次に、AUTOREFRESHキャッシュ・グループ属性を使用する方法を示します。
AUTOREFRESHキャッシュ・グループ属性は、CREATE CACHE GROUP文を使用して読取り専用キャッシュ・グループまたはユーザー管理キャッシュ・グループを作成する場合に指定できます。AUTOREFRESHは、キャッシュされたOracle Database表でコミットされた更新が、TimesTenキャッシュ表に自動的にリフレッシュされるように指定します。読取り専用キャッシュ・グループには、デフォルトで自動リフレッシュが定義されます。
自動リフレッシュ属性のデフォルト設定は、次のとおりです。
自動リフレッシュ・モードはINCREMENTALです。
自動リフレッシュの間隔は5分です。
自動リフレッシュの状態はPAUSEDです。
TimesTenでは、2つの自動リフレッシュ・モードがサポートされています。
INCREMENTAL: キャッシュ・グループの自動リフレッシュ間隔に基づいて、キャッシュされたOracle Database表でコミットされた更新がTimesTenキャッシュ表に自動的にリフレッシュされます。増分自動リフレッシュ・モードでは、Oracle Databaseオブジェクトを使用して、キャッシュされたOracle Database表でコミットされた更新を追跡します。これらのオブジェクトの詳細は、「Oracle Databaseオブジェクトによるキャッシュ環境の管理」を参照してください。
FULL: キャッシュ・グループの自動リフレッシュ間隔に基づいて、すべての行をアンロードした後、キャッシュされたOracle Database表からリロードすることによって、すべてのキャッシュ表が自動的にリフレッシュされます。
増分自動リフレッシュ・モードを使用すると、キャッシュされたOracle Database表でコミットされた更新ごとにキャッシュ・グループをリフレッシュするためのオーバーヘッドが発生します。完全自動リフレッシュ・モードを使用すると、オーバーヘッドは発生しません。
増分自動リフレッシュ・モードを使用すると、キャッシュされたOracle Database表でコミットされた更新は、Oracle Database内の変更ログ表で追跡されます。特定の環境下では、変更ログ・レコードの一部が、TimesTenキャッシュ表に自動的にリフレッシュされる前に変更ログ表から削除される可能性があります。このような状況が発生すると、TimesTenはキャッシュ・グループの完全自動リフレッシュを開始します。
増分自動リフレッシュを使用するように構成された場合に完全自動リフレッシュ・リクエストを無効化する方法の詳細は、キャッシュ・グループの完全自動リフレッシュの無効化を参照してください。
変更ログ表が存在する表領域が一杯になった場合に実行するアクションを構成する方法の詳細は、「キャッシュ管理ユーザーの表領域の監視」を参照してください。
増分自動リフレッシュが設定された動的な読取り専用キャッシュ・グループがある場合は、DynamicLoadReduceContentionデータベース・システム・パラメータを有効にすることで、競合を減らし、パフォーマンスを改善できます。詳細は、「増分自動リフレッシュを使用した動的な読取り専用キャッシュ・グループに対するTimesTenの競合の削減」を参照してください。
Oracle Database内の変更ログ表では、パフォーマンス上の理由から、列レベルの解決を行いません。したがって、自動リフレッシュ処理により、行内のすべての列が更新されます。たとえ実際に各列でデータが変更されていなくても、XLAにより、行内のすべての列が変更されたことが報告されます。
自動リフレッシュ間隔では、自動リフレッシュ処理の実行頻度を分、秒またはミリ秒の単位で指定します。自動リフレッシュ間隔が同じキャッシュ・グループは、同じトランザクション内でリフレッシュされます。自動リフレッシュ間隔を0ミリ秒に設定すると、自動リフレッシュを連続するよう指定できます。連続自動リフレッシュを指定している場合、次の自動リフレッシュ・サイクルは、最後の自動リフレッシュ・サイクルの終了後、可能なかぎり早くスケジュールされます。
ttCacheAutorefresh組込みプロシージャを使用すると、即時自動リフレッシュ処理を手動で開始できます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAutorefreshに関する説明を参照してください。
自動リフレッシュ状態はON、PAUSEDまたはOFFに設定できます。自動リフレッシュ処理はキャッシュ・グループの自動リフレッシュ状態がONの場合に、TimesTenによりスケジュールされます。
キャッシュ・グループの自動リフレッシュ状態がOFFの場合、キャッシュされたOracle Database表でコミットされた更新は追跡されません。
キャッシュ・グループの自動リフレッシュ状態がPAUSEDの場合、キャッシュされたOracle Database表でコミットされた更新はOracle Database内で追跡されますが、状態がONに変更されるまでTimesTenキャッシュ表には自動的にリフレッシュされません。
AUTOREFRESHキャッシュ・グループ属性を使用する場合は、次の制限が適用されます。
キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。
キャッシュされたOracle Database表に対して発行されたTRUNCATE TABLE文は、TimesTenキャッシュ表に自動的にリフレッシュされません。キャッシュされたOracle Database表に対してTRUNCATE TABLE文を発行する前に、ALTER CACHE GROUP文を使用して、キャッシュ表を含むキャッシュ・グループの自動リフレッシュ状態をPAUSEDに変更してください。
ALTER CACHE GROUP文の詳細は、「キャッシュ・グループの変更によるAUTOREFRESHのモード、間隔または状態の変更」を参照してください。
キャッシュされたOracle Database表に対してTRUNCATE TABLE文を発行した後、REFRESH CACHE GROUP文を使用してキャッシュ・グループを手動でリフレッシュします。
キャッシュ・グループが動的である場合を除いて、LOAD CACHE GROUP文を発行できるのはキャッシュ表が空の場合のみです。
LOAD CACHE GROUP文およびREFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。
動的キャッシュ・グループの詳細は、「動的キャッシュ・グループ」を参照してください。
キャッシュ・グループが動的である場合を除いて、キャッシュ・グループに対してLOAD CACHE GROUP文を発行する前の自動リフレッシュ状態はPAUSEDである必要があります。キャッシュ・グループが動的である場合は、自動リフレッシュ状態はPAUSEDまたはONであることが必要です。キャッシュ・グループが動的である場合を除いて、LOAD CACHE GROUP文にWHERE句を含めることはできず、キャッシュ・グループが動的である場合は、WHERE句の後にCOMMIT EVERY n ROWS句を続ける必要があります。
キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。
REFRESH CACHE GROUP文をキャッシュ・グループに対して発行するには、自動リフレッシュ状態がPAUSEDになっている必要があります。REFRESH CACHE GROUP文にWHERE句を含めることはできません。
キャッシュ・グループの作成、ロードまたはアンロード時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name
ユーザー管理キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用するには、すべてのキャッシュ表にPROPAGATEキャッシュ表属性が指定されているか、またはすべてのキャッシュ表にREADONLYキャッシュ表属性が指定されている必要があります。
NOT PROPAGATEキャッシュ表属性を明示的に使用するキャッシュ表を含むユーザー管理キャッシュ・グループでは、AUTOREFRESHキャッシュ・グループ属性を指定できません。
ユーザー管理キャッシュ・グループにOracle Databaseマテリアライズド・ビューをキャッシュする場合は、AUTOREFRESHキャッシュ表属性を使用できません。
LRUエージングがデフォルトで定義されている、キャッシュ・グループが動的である場合を除いて、キャッシュ・グループにLRUエージングを指定できません。
LRUエージングの詳細は、「LRUエージング」を参照してください。
AUTOREFRESHキャッシュ・グループ属性を使用するキャッシュ・グループに対して一意索引を作成する場合は、制約違反を回避するために索引が非一意索引に変更されます。Oracle Database表に対して同じ文を実行すると更新競合が発生する可能性があるため、一意索引によって制約違反が発生する可能性がありますが、TimesTenでは各行の更新が個別に実行されます。キャッシュされているOracle Database表に一意索引が存在する場合は、Oracle Database表で一意性が確保されるため、TimesTenで再度確認する必要はありません。
例4-9では、update_anywhere_customersキャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用しています。
自動リフレッシュ・キャッシュ・グループを作成した後、ALTER CACHE GROUP文を使用すると、キャッシュ・グループの自動リフレッシュのモード、間隔または状態を変更できます。最初から自動リフレッシュを定義せずに作成されたキャッシュ・グループに対しては、ALTER CACHE GROUPを使用して自動リフレッシュをインスタンス化することはできません。
キャッシュ・グループの自動リフレッシュ状態をOFFに変更したり、自動リフレッシュ処理を実行中のキャッシュ・グループを削除した場合の動作は、次のとおりです。
LockWait接続属性設定が0(ゼロ)より大きな値である場合、自動リフレッシュ処理は停止します。ALTER CACHE GROUP文またはDROP CACHE GROUP文が自動リフレッシュ処理より優先して使用されます。
LockWait接続属性が0(ゼロ)に設定されている場合、自動リフレッシュ処理は続行します。自動リフレッシュ処理が完了するか、またロック・タイムアウト・エラーが発生して文が失敗するまで、ALTER CACHE GROUP文またはDROP CACHE GROUP文はブロックされます。
「データのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」の説明に従って、自動リフレッシュ・キャッシュ・グループの定義済動作を実行するためにOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。
次に、キャッシュ・マネージャ・ユーザーとして、INCREMENTAL_AUTOREFRESHオプションおよびINSTALLフラグを指定してttIsqlユーティリティのcachesqlgetコマンドを実行する必要があります。このコマンドを実行すると、自動リフレッシュ・キャッシュ・グループにキャッシュされたOracle Database表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトが生成されます。これらのOracle Databaseオブジェクトは、キャッシュされたOracle Database表の更新を追跡するため、キャッシュ表に対して更新を自動的にリフレッシュできます。
次に、SQL*Plusを使用して、ttIsqlユーティリティのcachesqlgetコマンドで生成されたスクリプトをsysユーザーとして実行します。その後、ALTER CACHE GROUP文を使用して、キャッシュ・グループの自動リフレッシュ状態をPAUSEDに変更します。
例4-12 Oracle Databaseオブジェクトを手動で作成した場合の読取り専用キャッシュ・グループの作成
最初の文で、自動リフレッシュ状態がOFFに設定された読取り専用キャッシュ・グループcustomer_ordersが作成されます。ttIsqlユーティリティのcachesqlgetコマンドで生成されたSQL*Plusスクリプトは、/tmp/obj.sqlファイルに保存されます。最後の文によって、キャッシュ・グループの自動リフレッシュ状態がPAUSEDに変更されます。
CREATE READONLY CACHE GROUP customer_orders
AUTOREFRESH STATE OFF
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region VARCHAR2(10),
name VARCHAR2(50),
address VARCHAR2(100),
PRIMARY KEY(cust_num)),
oratt.orders
(ord_num NUMBER(10) NOT NULL,
cust_num NUMBER(6) NOT NULL,
when_placed DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));
% ttIsql "DSN=cache1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> cachesqlget INCREMENTAL_AUTOREFRESH customer_orders INSTALL /tmp/obj.sql;
Command> exit
% sqlplus sys as sysdba
Enter password: password
SQL> @/tmp/obj
SQL> exit
ALTER CACHE GROUP customer_orders SET AUTOREFRESH STATE PAUSED;
キャッシュ・グループで増分自動リフレッシュ・モードを使用すると、キャッシュされたOracle Database表でコミットされた更新は、Oracle Database内の変更ログ表で追跡されます。特定のエラー・シナリオ下では、変更ログ・レコードの一部が、TimesTenキャッシュ表に自動的にリフレッシュされる前に変更ログ表から削除される(切り捨てられる)可能性があります。このような状況が発生すると、TimesTenはキャッシュ・グループの完全自動リフレッシュを開始します。
パフォーマンス上の理由から、一部のアプリケーションでは、完全自動リフレッシュではなく増分自動リフレッシュを選択します。完全自動リフレッシュは、次の理由でパフォーマンスに影響する可能性があります。
完全自動リフレッシュでさらに行がリフレッシュされます。
完全リフレッシュは、パラレル伝播なしで1つのトランザクション内で実行されます。
パフォーマンスが問題である場合は、DisableFullAutorefreshキャッシュ構成パラメータを1に設定して、増分自動リフレッシュで定義されたすべてのキャッシュ・グループに対する完全自動リフレッシュ・リクエストを禁止できます。この場合、各キャッシュ・グループの初期ロードには手動ロードが必要です。
|
ノート: DisableFullAutorefreshキャッシュ構成パラメータのデフォルト値は0で、通常の完全自動リフレッシュ動作を指定します。 |
call ttCacheConfig('DisableFullAutorefresh',,,'1');
DisableFullAutorefreshパラメータの現在の値を問い合せることができます。
call ttCacheConfig('DisableFullAutorefresh');
キャッシュ・グループに対して完全自動リフレッシュがトリガーされると、TimesTenによってキャッシュ・グループのステータスが「disabled」に変更されます。その後、キャッシュ・グループでの自動リフレッシュ操作はすべて停止します。このアクションは、デーモン・ログ・メッセージで通知されます。
TimesTenデータベース・ステータスは、少なくとも1つの自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスが「disabled」または「recovering」に設定されている場合は「recovering」に設定されます。データベースおよびキャッシュ・グループの状態は、ttCacheDbCgStatus組込みプロシージャを使用して確認できます。次に例を示します。
recovering: AUTOREFRESH属性が指定された、データベースのキャッシュ・グループの一部またはすべてがOracle Databaseサーバーと再同期化中です。少なくとも1つのキャッシュ・グループの状態がrecoveringです。
disabled: cg1キャッシュ・グループは「disabled」です。
Command> call ttCacheDbCgStatus('ttuser','cg1');
< recovering, disabled >
1 row found.
DisableFullAutorefreshキャッシュ構成パラメータを1に設定すると、DeadDbRecoveryキャッシュ構成パラメータが自動的に「Manual」に変更されます。DisableFullAutorefreshキャッシュ構成パラメータを0に変更すると、TimesTenはDeadDbRecoveryキャッシュ構成パラメータの元の設定をリストアします。
キャッシュ・グループの自動リフレッシュ・ステータスが「disabled」または「dead」である場合、そのキャッシュ表はキャッシュされたOracle Database表に対する更新がコミットされても、もう自動的にリフレッシュされません。キャッシュ表をキャッシュされたOracle Database表と再同期化するには、キャッシュ・グループをリカバリする必要があります。
自動リフレッシュ・ステータスが「disabled」になっている各キャッシュ・グループに対して自動リフレッシュ操作を再開するには、REFRESH CACHE GROUP文を発行する必要があります。
自動リフレッシュ・ステータスが「disabled」になっている各動的キャッシュ・グループに対して自動リフレッシュ操作を再開するには、UNLOAD CACHE GROUP文を発行する必要があります。
例4-13 無効化されたキャッシュ・グループの手動リフレッシュ
ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED文を使用して、キャッシュ・グループの自動リフレッシュを一時停止し、キャッシュ・グループのステータスを「OK」に戻します。その後、REFRESH CACHE GROUP文を使用して手動で完全リフレッシュをリクエストします(オプションでパラレル伝播を使用)。
ALTER CACHE GROUP cg_static SET AUTOREFRESH STATE PAUSED; REFRESH CACHE GROUP cg_static COMMIT EVERY 500 ROWS PARALLEL 3;
例4-14 動的キャッシュ・グループの再ロード
キャッシュ・グループのステータスを「OK」に戻すには、ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED文を使用してキャッシュ・グループの自動リフレッシュを一時停止します。
無効化された動的キャッシュ・グループを、UNLOAD CACHE GROUP文を使用してアンロードします。
オプションで、LOAD CACHE GROUP文を使用して(オプションでパラレル伝播を使用)キャッシュ・グループをロードするか、動的ロードを開始できます。動的ロード・リクエストの詳細は、キャッシュ・インスタンスの動的ロードを参照してください。
ALTER CACHE GROUP cg_dynamic SET AUTOREFRESH STATE PAUSED; UNLOAD CACHE GROUP cg_dynamic COMMIT EVERY 500 ROWS; LOAD CACHE GROUP cg_dynamic COMMIT EVERY 500 ROWS PARALLEL 3;
CREATE CACHE GROUP文内のキャッシュ表定義には、特定のキャッシュ・グループ・タイプについて、TimesTenデータベースにキャッシュする行を制限するWHERE句を含めることができます。
また、特定のキャッシュ・グループ・タイプの場合、LOAD CACHE GROUP文、UNLOAD CACHE GROUP文、REFRESH CACHE GROUP文またはFLUSH CACHE GROUP文にWHERE句を指定することもできます。LOAD CACHE GROUP文やREFRESH CACHE GROUP文などのいくつかの文では、キャッシュ表定義のWHERE句がLOAD CACHE GROUP文またはREFRESH CACHE GROUP文のWHERE句より前に評価される連結WHERE句が発生する場合があります。
キャッシュ表定義およびキャッシュ・グループ処理で使用されるWHERE句には、次の制限が適用されます。
CREATE CACHE GROUP文のキャッシュ表定義にWHERE句を指定できるのは、読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループの場合のみです。
明示的にロードされる自動リフレッシュ・キャッシュ・グループ以外では、LOAD CACHE GROUP文にWHERE句を指定できます。
LOAD CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。
自動リフレッシュ・キャッシュ・グループ以外では、REFRESH CACHE GROUP文にWHERE句を指定できます。
REFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。
TimesTenキャッシュ表でコミットされた更新を、キャッシュされたOracle Database表にフラッシュできるユーザー管理キャッシュ・グループでは、FLUSH CACHE GROUP文にWHERE句を指定できます。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。
CREATE CACHE GROUP文のWHERE句には、副問合せを使用できません。したがって、各WHERE句では、キャッシュ表定義内にある表以外の表を参照できません。ただし、LOAD CACHE GROUP文、UNLOAD CACHE GROUP文、REFRESH CACHE GROUP文またはFLUSH CACHE GROUP文のWHERE句には、副問合せが含まれる場合があります。
WHERE句に副問合せが含まれる場合を除いて、LOAD CACHE GROUP文、REFRESH CACHE GROUP文またはFLUSH CACHE GROUP文のWHERE句で参照できるのは、キャッシュ・グループのルート表のみです。
キャッシュ表定義内のWHERE句が実行されるのは、キャッシュ・グループが手動でロードまたはリフレッシュされた場合、あるいはキャッシュ表が動的にロードされた場合のみです。キャッシュ表が更新可能な場合は、行を挿入または更新すると、その行のキャッシュ表定義内のWHERE句の条件が満たされなくなります。
キャッシュ・グループの作成、ロード、リフレッシュ、アンロードまたはフラッシュ時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name
例4-10では、oratt.active_customer表とoratt.orderdetails表の両方にWHERE句が含まれます。
複数表のキャッシュ・グループでは、特定の表定義内のWHERE句で、キャッシュ・グループ内のその表以外の表を参照することはできません。たとえば、次のCREATE CACHE GROUP文は有効です。
CREATE READONLY CACHE GROUP customer_orders FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)) WHERE (oratt.customer.cust_num < 100), oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num), FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));
CREATE READONLY CACHE GROUP customer_orders FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)), oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num), FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num)); WHERE (oratt.orders.cust_num < 100)
次の文は、子表の定義内のWHERE句が親表を参照しているため無効です。
CREATE READONLY CACHE GROUP customer_orders FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)), oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num), FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num)) WHERE (oratt.customer.cust_num < 100);
同様に、次の文は、親表の定義内のWHERE句が子表を参照しているため無効です。
CREATE READONLY CACHE GROUP customer_orders FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)) WHERE (oratt.orders.cust_num < 100), oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num), FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));
Oracle Databaseのユーザー定義PL/SQLファンクションは、CREATE CACHE GROUP文、LOAD CACHE GROUP文またはREFRESH CACHE GROUP文のWHERE句で(動的キャッシュ・グループの場合のみ)、間接的に起動できます。ファンクションを作成した後、そのファンクションのパブリック・シノニムを作成します。次に、ファンクションのEXECUTE権限をPUBLICに付与します。
たとえば、Oracle Databaseでは、次のとおりです。
CREATE OR REPLACE FUNCTION get_customer_name (c_num oratt.customer.cust_num%TYPE) RETURN VARCHAR2 IS c_name oratt.customer.name%TYPE; BEGIN SELECT name INTO c_name FROM oratt.customer WHERE cust_num = c_num; RETURN c_name; END get_customer_name; CREATE PUBLIC SYNONYM retname FOR get_customer_name; GRANT EXECUTE ON get_customer_name TO PUBLIC;
次に、TimesTenデータベースでは、たとえば、このファンクション用に作成されたOracle Databaseパブリック・シノニムを参照するWHERE句を指定して、キャッシュ・グループを作成できます。
CREATE READONLY CACHE GROUP top_customer FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)) WHERE name = retname(100);
LOAD CACHE GROUP文またはREFRESH CACHE GROUP文にWHERE句を使用できるキャッシュ・グループ・タイプの場合は、ファンクション用に作成されたパブリック・シノニムを参照することによって、そのファンクションを間接的に起動できます。たとえば、次のLOAD CACHE GROUP文を使用して、AWTキャッシュ・グループnew_customersをロードできます。
LOAD CACHE GROUP new_customers WHERE name = retname(101) COMMIT EVERY 0 ROWS;
ON DELETE CASCADEキャッシュ表属性は、いずれのキャッシュ・グループ・タイプのキャッシュ表にも指定できます。ON DELETE CASCADEは、参照されるキー値を含む行が親表から削除されると、依存する外部キーを持つ子表の行も削除されるように指定します。
例4-15 ON DELETE CASCADEキャッシュ表属性の使用
次の文では、子表の外部キー定義でON DELETE CASCADEキャッシュ表属性が使用されます。
CREATE READONLY CACHE GROUP customer_orders FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)), oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num), FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num) ON DELETE CASCADE);
親表から子表へのすべてのパスは、削除パスまたは削除不可パスのいずれかである必要があります。1つの親表から1つの子表に対し、複数の削除パスおよび複数の削除不可パスは存在できません。ON DELETE CASCADEキャッシュ表属性は、削除パス上の子表に対して指定します。
ON DELETE CASCADEキャッシュ表属性を使用する場合は、次の制限が適用されます。
AWTおよびSWTキャッシュ・グループの場合およびPROPAGATEキャッシュ表属性を使用するユーザー管理キャッシュ・グループ内のTimesTenキャッシュ表の場合、ON DELETE CASCADEキャッシュ表属性を使用するキャッシュ表の外部キーは、ON DELETE CASCADE属性を使用するキャッシュされたOracle Database表の外部キーの適切なサブセットである必要があります。キャッシュされたOracle Database表に対するON DELETE CASCADEアクションは、個々の削除としてTimesTenキャッシュ表に適用されます。キャッシュ表に対するON DELETE CASCADEアクションは、カスケード処理としてキャッシュされたOracle Database表に適用されます。
TimesTenキャッシュ表とキャッシュされたOracle Database表間の外部キーの照合は、キャッシュ・グループの作成時にのみ実行されます。キャッシュされたOracle Database表の外部キーがキャッシュ・グループの作成後に変更された場合は、カスケード削除処理が機能しないことがあります。
ON DELETE CASCADEキャッシュ表属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE CACHE GROUP文に関する説明を参照してください。
UNIQUE HASH ONキャッシュ表属性は、いずれのキャッシュ・グループ・タイプのキャッシュ表にも指定できます。UNIQUE HASH ONは、キャッシュ表の主キー列に、範囲索引ではなくハッシュ索引が作成されるように指定します。ハッシュ索引で指定される列は、主キーの列と同じである必要があります。また、UNIQUE HASH ONキャッシュ表属性は、ハッシュ索引のサイズの指定にも使用されます。
例4-16 UNIQUE HASH ONキャッシュ表属性の使用
次の文では、キャッシュ表の定義でUNIQUE HASH ONキャッシュ表属性が使用されます。
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)) UNIQUE HASH ON (cust_num) PAGES = 100;
UNIQUE HASH ONキャッシュ表属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE CACHE GROUP文に関する説明を参照してください。
AUTOREFRESHキャッシュ・グループ属性を使用しないAWT、SWTまたはユーザー管理キャッシュ・グループでは、プライベート・シノニムをキャッシュできます。プライベート・シノニムは、パブリック・シノニムまたはプライベート・シノニムを参照できますが、実際にキャッシュされるのは表であるため、最終的には表を参照する必要があります。
キャッシュされたシノニムによって直接的または間接的に参照される表は、シノニムをキャッシュするキャッシュ・グループの所有者と同じ名前を持つOracle Databaseユーザー以外のユーザーによって所有されます。表は、シノニムと同じOracle Databaseに存在する必要があります。キャッシュされたシノニム自体は、シノニムをキャッシュするキャッシュ・グループの所有者と同じ名前のOracle Databaseユーザーによって所有されます。
Oracle Databaseラージ・オブジェクト(LOB)データをTimesTenキャッシュ・グループにキャッシュできます。TimesTenでは、次のようにデータをキャッシュします。
Oracle Database CLOBデータは、TimesTen VARCHAR2データとしてキャッシュされます。
Oracle Database BLOBデータは、TimesTen VARBINARYデータとしてキャッシュされます。
Oracle Database NCLOBデータは、TimesTen NVARCHAR2データとしてキャッシュされます。
例4-17 Oracle Database LOBデータのキャッシュ
LOBフィールドを持つOracle Databaseに表を作成します。
CREATE TABLE t ( i INT NOT NULL PRIMARY KEY , c CLOB , b BLOB , nc NCLOB);
Oracle Database表に値を挿入します。値は、暗黙的にTimesTen VARCHAR2、VARBINARYまたはNVARCHAR2データ型に変換されます。
INSERT INTO t VALUES (1
, RPAD('abcdefg8', 2048, 'abcdefg8')
, HEXTORAW(RPAD('123456789ABCDEF8', 4000, '123456789ABCDEF8'))
, RPAD('abcdefg8', 2048, 'abcdefg8')
);
1 row inserted.
動的AWTキャッシュ・グループを作成し、レプリケーション・エージェントを起動します。
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP cg1 FROM t (i INT NOT NULL PRIMARY KEY , c VARCHAR2(4194303) , b VARBINARY(4194303) , nc NVARCHAR2(2097152)); CALL ttrepstart;
TimesTenキャッシュ・グループに動的にデータをロードします。
SELECT * FROM t WHERE i = 1; I: 1 C: abcdefg8abcdefg8abcdefg8... B: 123456789ABCDEF8123456789... NC: abcdefg8abcdefg8abcdefg8... 1 row found.
Oracle Database LOBデータのキャッシュに対する制約
Oracle Database LOBデータをTimesTenキャッシュ・グループにキャッシュする場合は、次の制限が適用されます。
キャッシュ・グループの作成時に列サイズが適用されます。VARBINARY、VARCHAR2およびNVARCHAR2データ型のサイズ制限は4MBです。ユーザー定義の列のサイズを超える値は、通知なしに実行時に切り捨てられます。
CLOBおよびBLOBデータ型のフィールド内にある空の値は、初期化されますがデータは入力されません。空のCLOBフィールドおよびBLOBフィールドは次のように処理されます。
Oracle Databaseの空のLOBフィールドは、NULL値として返されます。
TimesTenのキャッシュ内の空のVARCHAR2フィールドおよびVARBINARYフィールドは、NULL値として伝播されます。
また、自動リフレッシュ処理を行うように構成されたキャッシュ・グループでは、LOBデータのキャッシュに対して次の制限が適用されます。
OCI関数またはDBMS_LOB PL/SQLパッケージによってOracle DatabaseでLOBデータが更新された場合、データはTimesTenキャッシュ・グループに自動的にはリフレッシュされません。これは、TimesTenのキャッシュがOracle Databaseトリガーに依存しているのに、Oracle Databaseトリガーはこのようなタイプの更新が発生しても実行されないためです。TimesTenは、更新が発生したもののTimesTenへのリフレッシュが行われなかったことをユーザーに通知しません。SQL文によってOracle DatabaseのLOBデータが更新された場合は、トリガーが起動され、自動リフレッシュによってその変更が反映されます。
自動リフレッシュ処理を行うと、TimesTenのキャッシュ内のすべての行が更新されます。したがって、Oracle DatabaseのLOBデータに変更が発生しなくても、キャッシュされたLOBデータがTimesTenで更新されるように見える場合があります。
キャッシュ・グループに対して、エージング・タイプ、エージング属性およびエージング状態を指定するエージング・ポリシーを定義できます。TimesTenでは、最低使用頻度(LRU)エージングおよび時間ベースのエージングの2つのエージング・タイプがサポートされています。
LRUエージングでは、指定されたデータベースの使用状況の範囲に基づいて、最低使用頻度または最低参照頻度のデータが削除されます。時間ベースのエージングでは、指定されたデータ存続期間およびエージング・プロセスの頻度に基づいてデータが削除されます。同じTimesTenデータベース内でLRUエージングと時間ベースのエージングの両方を使用できますが、特定のキャッシュ・グループに対して定義できるエージング・ポリシーは1つのみです。
エージングはキャッシュ・インスタンス・レベルで実行されるため、エージング・ポリシーはCREATE CACHE GROUP文内のルート表のキャッシュ表定義で指定され、キャッシュ・グループ内のすべてのキャッシュ表に適用されます。エージ・アウトによってキャッシュ表から行が削除されたとき、キャッシュされたOracle Database表の行は削除されません。
キャッシュ・グループにエージング・ポリシーを追加するには、ルート表に対してALTER TABLE文を使用します。キャッシュ・グループのエージング・ポリシーを変更するには、ルート表に対してALTER TABLE文を使用して既存のエージング・ポリシーを削除した後、新しいエージング・ポリシーを追加します。
この項では、エージング・ポリシーを含むキャッシュ・グループ定義について説明します。内容は次のとおりです。
LRUエージングを使用すると、最低使用頻度のデータを削除することによって、TimesTenデータベースで使用するメモリーの量を、指定されたしきい値の範囲内に維持できます。LRUエージングは、明示的にロードされる自動リフレッシュ・キャッシュ・グループを除いて、すべてのキャッシュ・グループ・タイプに対して定義できます。動的キャッシュ・グループには、デフォルトでLRUエージングが定義されます。
キャッシュ・グループに対してLRUエージング・ポリシーを定義するには、CREATE CACHE GROUP文のキャッシュ表定義でAGING LRU句を使用します。エージング状態がデフォルトのONに設定されている場合、エージングは自動的に発生します。
例4-18 キャッシュ・グループに対するLRUエージング・ポリシーの定義
次の文では、AWTキャッシュ・グループnew_customersに対してLRUエージング・ポリシーが定義されます。
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num)) AGING LRU ON;
ADMIN権限を持つユーザーとしてLRUエージング属性を設定するには、ttAgingLRUConfig組込みプロシージャを使用します。属性の設定は、TimesTenデータベース内でLRUエージング・ポリシーが定義されており、エージング状態がONであるすべての表に適用されます。
LRUエージング属性は、次のとおりです。
LowUsageThreshold: TimesTenデータベースの領域使用状況(領域の割当て済サイズに対する永続領域の使用サイズの割合)がこの値以下になると、LRUエージングが無効になります。デフォルトの下限しきい値は0.8(80パーセント)です。
HighUsageThreshold: TimesTenデータベースの領域使用状況がこの値を超えると、LRUエージングが有効になります。デフォルトの上限しきい値は0.9(90パーセント)です。
AgingCycle: エージングが発生する頻度(分)。デフォルトのエージング・サイクルは1分です。
例4-19 LRUエージング属性の設定
次の組込みプロシージャ・コールは、エージング・プロセスによって5分ごとにチェックが行われ、TimesTenデータベースの永続領域の領域使用量が95パーセントを超えているかどうかが確認されるように指定します。超えている場合は、領域使用状況が75パーセント以下になるまで、最低使用頻度のデータが自動的にエージ・アウトまたは削除されます。
Command> CALL ttAgingLRUConfig(.75, .95, 5);
キャッシュ・グループにLRUエージング・ポリシーを定義した後に、AgingCycleに新しい値を設定すると、次回のエージングは現在のシステム時刻と新しいエージング・サイクルに基づいて発生します。たとえば、元のエージング・サイクルが15分で10分前にLRUエージングが発生した場合、5分後に再度エージングが発生します。ただし、エージング・サイクルを30分に変更すると、新しいエージング・サイクル設定を指定してttAgingLRUConfig組込みプロシージャをコールしてから30分後に次のエージングが発生します。
最後のエージング・サイクル以降に行がアクセスされたり、参照された場合、その行は現在のエージング・サイクルではLRUエージングの対象になりません。次のいずれかの場合に、行がアクセスされた、または参照されたとみなされます。
行がSELECT文またはINSERT ... SELECT文の結果セットを作成するために使用された。
保留中のトランザクションで更新または削除の対象としてマークされている。
複数表のキャッシュ・グループでは、最後のエージング・サイクル以降に子表内の行がアクセスされたり参照された場合、現在のエージング・サイクルでは、親表の関連行も子表の行もLRUエージングの対象になりません。
ALTER TABLE文を使用すると、キャッシュ・グループのLRUエージング・ポリシーの変更または定義に関連する次のタスクを実行できます。
ルート表を指定し、SET AGING句を使用して、キャッシュ・グループのエージング状態を変更します。
ルート表を指定し、ADD AGING LRU句を使用して、エージング・ポリシーが定義されていないキャッシュ・グループにLRUエージング・ポリシーを追加します。
ルート表を指定し、DROP AGING句を使用して、キャッシュ・グループのLRUエージング・ポリシーを削除します。
キャッシュ・グループのエージング・ポリシーをLRUから時間ベースに変更するには、ルート表に対してALTER TABLE文とDROP AGING句を使用して、LRUエージング・ポリシーを削除します。次に、ルート表に対してALTER TABLE文とADD AGING USE句を使用して、時間ベースのエージング・ポリシーを追加します。
自動リフレッシュ・キャッシュ・グループでエージング・ポリシーを追加、変更または削除する前に、キャッシュ・エージェントを停止する必要があります。
時間ベースのエージングでは、エージング・ポリシーの指定されたデータ存続期間および頻度に基づいて、キャッシュ・グループからデータが削除されます。時間ベースのエージングは、すべてのキャッシュ・グループ・タイプに対して定義できます。
キャッシュ・グループに対して時間ベースのエージング・ポリシーを定義するには、CREATE CACHE GROUP文のキャッシュ表定義でAGING USE句を使用します。エージング状態がデフォルトのONに設定されている場合、エージングは自動的に発生します。
例4-21に定義されたAWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、例4-20で定義されています。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。
例4-20 Oracle Database表の定義
CREATE TABLE orders (ord_num NUMBER(10) NOT NULL PRIMARY KEY, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL); CREATE TABLE order_item (orditem_id NUMBER(12) NOT NULL PRIMARY KEY, ord_num NUMBER(10), prod_num VARCHAR2(6), quantity NUMBER(3));
キャッシュ・マネージャ・ユーザーが、oratt.orders表およびoratt.order_item表をキャッシュするAWTキャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、これらの表に対するSELECT権限が付与されている必要があります。Oracle Databaseに対して非同期ライトスルー処理を行うには、oratt.orders表およびoratt.order_item表においてキャッシュ管理ユーザーに、INSERT、UPDATEおよびDELETEのOracle Database権限が付与されている必要があります。
例4-21 キャッシュ・グループに対する時間ベースのエージング・ポリシーの定義
次の文では、AWTキャッシュ・グループordered_itemsに対して時間ベースのエージング・ポリシーが定義されます。
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP ordered_items FROM oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num)) AGING USE when_placed LIFETIME 45 DAYS CYCLE 60 MINUTES ON, oratt.order_item (orditem_id NUMBER(12) NOT NULL, ord_num NUMBER(10), prod_num VARCHAR2(6), quantity NUMBER(3), PRIMARY KEY(orditem_id), FOREIGN KEY(ord_num) REFERENCES oratt.orders(ord_num));
現在のシステム・タイムスタンプとoratt.orders表のwhen_placed列のタイムスタンプの差が45日を超えるキャッシュ・インスタンスは、エージングの対象となります。エージング・プロセスによって60分ごとにチェックが行われ、キャッシュ表から自動的にエージ・アウトまたは削除できるキャッシュ・インスタンスがあるかどうかが確認されます。
AGING USE句には、時間ベースのエージングに使用される、NULLを指定できないTIMESTAMP列またはDATE列の名前が必要です。この列は、タイムスタンプ列と呼ばれます。
各行のタイムスタンプ列の値には、その行が最後に挿入または更新された日付と時刻が保存されます。タイムスタンプ列の値は、アプリケーションによって保持されます。この列の値が不明な特定の行があり、それらの行を表からエージ・アウトしないときは、デフォルト値を大きくしてタイムスタンプ列を定義します。
タイムスタンプ列に索引を作成すると、エージング・プロセスのパフォーマンスを最適化できます。
追加された列はNULLを指定できない列として定義できないため、既存の表に列を追加して、その列をタイムスタンプ列として使用することはできません。定義された時間ベースのエージング・ポリシーが含まれている表からタイムスタンプ列を破棄することはできません。
存続期間は、AGING USE句のLIFETIMEキーワードの後に日、時間、分または秒の単位で指定します。
タイムスタンプ列の値は、現在のシステム・タイムスタンプから差し引かれます。結果は指定した存続期間の単位(日、時間、分、秒)まで切り捨てられ、指定した存続期間の値との比較が行われます。その結果が存続期間の値より大きい場合、行はエージングの対象となります。
CYCLEキーワードの後に、エージングが発生する頻度を日、時間、分または秒の単位で指定します。デフォルトのエージング・サイクルは5分です。エージング・サイクルに0(ゼロ)を指定した場合、連続的にエージングが行われます。
ALTER TABLE文を使用すると、キャッシュ・グループの時間ベースのエージング・ポリシーの変更または定義に関連する次のタスクを実行できます。
ルート表を指定し、SET AGING句を使用して、キャッシュ・グループのエージング状態を変更します。
ルート表を指定し、SET AGING LIFETIME句を使用して、存続期間を変更します。
ルート表を指定し、SET AGING CYCLE句を使用して、エージング・サイクルを変更します。
ルート表を指定し、ADD AGING USE句を使用して、エージング・ポリシーが定義されていないキャッシュ・グループに時間ベースのエージング・ポリシーを追加します。
ルート表を指定し、DROP AGING句を使用して、キャッシュ・グループの時間ベースのエージング・ポリシーを削除します。
キャッシュ・グループのエージング・ポリシーを時間ベースからLRUに変更するには、ルート表に対してALTER TABLE文とDROP AGING句を使用して、時間ベースのエージング・ポリシーを削除します。次に、ルート表に対してALTER TABLE文とADD AGING LRU句を使用して、LRUエージング・ポリシーを追加します。
自動リフレッシュ・キャッシュ・グループでエージング・ポリシーを追加、変更または削除する前に、キャッシュ・エージェントを停止する必要があります。
指定された表またはエージング・ポリシーが定義されているすべての表でワンタイム・エージング・プロセスを手動で開始するには、ttAgingScheduleNow組込みプロシージャを使用します。進行中のエージング・プロセスが存在する場合を除いて、組込みプロシージャをコールするとすぐにエージング・プロセスが開始されます。エージング・プロセスが進行中の場合、手動で開始したエージング・プロセスは、進行中のエージング・プロセスが完了したときに開始されます。手動で開始したエージング・プロセスが完了した後、表のエージング状態がONの場合は、その表の次のエージング・サイクルの開始がttAgingScheduleNowがコールされた時点に設定されます。
例4-22 ワンタイム・エージング・プロセスの開始
次の組込みプロシージャ・コールでは、ttAgingScheduleNowがコールされるタイミングに基づいて、oratt.orders表のワンタイム・エージング・プロセスが開始されます。
Command> CALL ttAgingScheduleNow('oratt.orders');
oratt.ordersルート表内でエージングの対象となる行は、oratt.order_item子表内の関連行と同様に削除されます。
ttAgingScheduleNow組込みプロシージャをコールすると、表のエージング状態がONかOFFかにかかわらず、エージング処理が開始されます。特定のキャッシュ・グループでエージング・プロセスを開始する場合は、組込みプロシージャをコールするとき、キャッシュ・グループのルート表の名前を指定します。パラメータを指定しないで組込みプロシージャttAgingScheduleNowがコールされた場合、エージング・プロセスが開始された後、TimesTenデータベース内のエージング・ポリシーが定義されたすべての表で、次のエージング・サイクルの開始がリセットされます。
ttAgingScheduleNow組込みプロシージャをコールしても、表のエージング状態は変わりません。組込みプロシージャをコールしたときに表のエージング状態がOFFの場合、エージング・プロセスは開始されますが、そのプロセスが完了した後にプロセスの実行が再度スケジュールされることはありません。エージング状態がOFFである表のエージングを続行するには、ttAgingScheduleNowを再度コールするか、または表のエージング状態をONに変更する必要があります。
キャッシュ・グループのエージングを手動で制御するには、ALTER TABLE文でSET AGING OFF句を指定して、ルート表のエージングを無効にします。次に、ttAgingScheduleNowをコールして、キャッシュ・グループに対してエージング・プロセスを開始します。
時間ベースのエージングを使用すると、キャッシュ・グループにスライド期間が実装されます。スライド期間構成では、表に特定の時間間隔を満たすデータのみが含まれるように、定期的に新しい行がキャッシュ表に挿入され、古い行がキャッシュ表から削除されます。
キャッシュ・グループにスライド期間を構成するには、増分自動リフレッシュ・モードを使用し、時間ベースのエージング・ポリシーを定義します。自動リフレッシュ処理では、キャッシュされたOracle Database表にある行のタイムスタンプをチェックして、TimesTenキャッシュ表に新しいデータをリフレッシュする必要があるかどうかが決定されます。システム時刻およびタイムゾーンは、Oracle DatabaseとTimesTenの各システムで同じである必要があります。
キャッシュ・グループで増分自動リフレッシュ・モードを使用しない場合、スライド期間を構成するには、LOAD CACHE GROUP文、REFRESH CACHE GROUP文またはINSERT文を使用するか、動的ロード処理を使用して、新しいデータをキャッシュ表に挿入します。
例4-23 スライド期間のプロパティを持つキャッシュ・グループの定義
次の文では、読取り専用キャッシュ・グループrecent_shipped_ordersに対してスライド期間が構成されます。
CREATE READONLY CACHE GROUP recent_shipped_orders AUTOREFRESH MODE INCREMENTAL INTERVAL 1440 MINUTES STATE ON FROM oratt.orders (ord_num NUMBER(10) NOT NULL, cust_num NUMBER(6) NOT NULL, when_placed DATE NOT NULL, when_shipped DATE NOT NULL, PRIMARY KEY(ord_num)) AGING USE when_shipped LIFETIME 30 DAYS CYCLE 24 HOURS ON;
キャッシュされたOracle Database表oratt.ordersの新しいデータは、1440分ごとにTimesTenキャッシュ表oratt.ordersに自動的にリフレッシュされます。現在のシステム・タイムスタンプとwhen_shipped列のタイムスタンプの差が30日を超えるキャッシュ・インスタンスは、エージングの対象となります。エージング・プロセスによって24時間ごとにチェックが行われ、キャッシュ表からエージ・アウトできるキャッシュ・インスタンスがあるかどうかが確認されます。したがって、このキャッシュ・グループには、過去30日以内に送信された注文が保存されます。
エージングに使用される自動リフレッシュ間隔および存続期間によって、特定の行がキャッシュ表内に保持される期間が決定します。キャッシュ表で存続期間が経過するのを待たずにデータがキャッシュ表からエージ・アウトされる可能性があります。たとえば、読取り専用キャッシュ・グループでは、自動リフレッシュ間隔が3日で存続期間が30日である場合、キャッシュ表にリフレッシュされたときにすでに3日経過しているデータは27日後に削除されますが、これはエージングがキャッシュ表にデータがリフレッシュされたときではなく、TimesTenキャッシュ表にロードされるキャッシュされたOracle Database表の行に保存されたタイムスタンプに基づいているためです。
動的キャッシュ・グループ内のデータは、リクエストに応じてロードされます。たとえば、コール・センター・アプリケーションでは、顧客の情報が非常に多い場合があるため、すべての顧客の情報をTimesTenに事前ロードしないことがあります。かわりに、動的キャッシュ・グループを使用すると、顧客から問合せがあった場合または顧客がシステムにログオンした場合など、必要な場合にのみ特定の顧客の情報をロードできます。
どのシステム管理キャッシュ・グループ・タイプ(読取り専用、AWT、SWT)も、動的キャッシュ・グループとして定義できます。ユーザー管理キャッシュ・グループは、AUTOREFRESHキャッシュ・グループ属性とPROPAGATEキャッシュ表属性の両方を使用している場合を除いて、動的キャッシュ・グループとして定義できます。
動的キャッシュ・グループを作成するには、CREATE DYNAMIC CACHE GROUP文を使用します。
次の文では、oratt.customer表をキャッシュする動的読取り専用キャッシュ・グループonline_customersが作成されます。
CREATE DYNAMIC READONLY CACHE GROUP online_customers FROM oratt.customer (cust_num NUMBER(6) NOT NULL, region VARCHAR2(10), name VARCHAR2(50), address VARCHAR2(100), PRIMARY KEY(cust_num));
明示的にロードされるキャッシュ・グループの場合は、まず、LOAD CACHE GROUP文を使用して、キャッシュされたOracle Database表からキャッシュ表にデータがロードされます。動的キャッシュ・グループの場合も、LOAD CACHE GROUP文を使用してデータをキャッシュ表にロードできます。ただし、動的キャッシュ・グループでは、通常、SELECT文、INSERT文またはUPDATE文でキャッシュ表が参照された場合に、表にデータが存在しないためにキャッシュ・ミスになると、データが自動的にロードされます。詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。
明示的にロードされるキャッシュ・グループと動的キャッシュ・グループの両方で、LOAD CACHE GROUP文は、キャッシュされたOracle Database表に存在してTimesTenキャッシュ表には存在しない対象データをキャッシュ表にロードします。ただし、キャッシュ表に行が存在する場合に、キャッシュされたOracle Database表にその行より新しいバージョンが存在すると、その行はLOAD CACHE GROUP文の条件を満たしていてもキャッシュ表にロードされません。
これに対して、REFRESH CACHE GROUP文では、キャッシュ表に存在する対象行をリロードし、キャッシュの内容を効率的にリフレッシュします。明示的にロードされるキャッシュ・グループの場合、リフレッシュされる行は、REFRESH CACHE GROUP文の条件を満たすすべての行です。ただし、動的キャッシュ・グループの場合、リフレッシュされる行は、条件を満たし、キャッシュ表にすでに存在する行です。つまり、最終的にリフレッシュされる行は、キャッシュされたOracle Database表で更新または削除された行であり、挿入された行ではありません。したがって、リフレッシュ処理では、キャッシュ表にすでに存在する行のみが処理されます。リフレッシュが行われても、動的キャッシュ・グループのキャッシュ表に新しい行はロードされません。
動的読取り専用キャッシュ・グループのキャッシュ・インスタンス内にあるデータは、Oracle Database表の対応する行内にあるデータと一貫性があります。自動リフレッシュの状態と間隔設定を考慮すると、明示的にロードされるキャッシュ・グループのキャッシュ・インスタンス内にあるデータは、Oracle Database表の対応する行内にあるデータと常に一貫性があります。
|
ノート: 増分自動リフレッシュが設定された動的な読取り専用キャッシュ・グループがある場合は、DynamicLoadReduceContentionデータベース・システム・パラメータを有効にすることで、競合を減らし、パフォーマンスを改善できます。詳細は、「増分自動リフレッシュを使用した動的な読取り専用キャッシュ・グループに対するTimesTenの競合の削減」を参照してください。 |
LRUエージングがデフォルトで定義されているため、動的キャッシュ・グループ内にあるデータはエージングの対象です。ttAgingLRUConfig組込みプロシージャを使用すると、エージング・サイクルおよびTimesTenデータベースの領域使用状況のしきい値に対するデフォルトまたは現在のLRUエージング属性設定を上書きできます。また、動的キャッシュ・グループに対して時間ベースのエージングを定義して、LRUエージングを上書きすることもできます。動的AWTキャッシュ・グループ内の行は、エージングの対象となる前に、Oracle Databaseに伝播される必要があります。
高可用性を実現するために、読取り専用キャッシュ・グループまたはAWTキャッシュ・グループのキャッシュ表に対してアクティブ・スタンバイ・ペアのレプリケーション・スキームを構成します。
これらのキャッシュ・グループ・タイプのいずれかからキャッシュ表をレプリケートするアクティブ・スタンバイ・ペアを使用すると、フェイルオーバーおよびリカバリの一部として、データ損失の可能性を最小限に抑えて、TimesTenデータベースのロールを自動的に変更できます。キャッシュ・グループ自体は、Oracle Databaseの停止からのリジリエンスを提供するため、システムの可用性がさらに強化されます。アクティブ・スタンバイ・ペアのレプリケーション・スキームを構成すると、TimesTenデータベースの高可用性を実現できます。
|
ノート: この項では、アクティブ・スタンバイ・ペアのレプリケーション・スキーム内にキャッシュ・グループを含めるシナリオの1つについて説明します。アクティブ・スタンバイ・ペアのレプリケーション・スキームにAWTおよび読取り専用キャッシュ・グループを含めるシナリオの詳細は、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のキャッシュ・グループを使用したアクティブ・スタンバイ・ペアの管理に関する項を参照してください。 |
Oracle Real Application Clusters(Oracle RAC)を構成すると、Oracle Databaseの高可用性を実現できます。Oracle RAC環境でTimesTen Cacheを使用する方法の詳細は、Oracle RAC環境でのTimesTen Cacheの使用を参照してください。
Oracle Database表をキャッシュするTimesTenデータベースに対してアクティブ・スタンバイ・ペアを構成するには、次のタスクを実行します。
次に、アクティブ・スタンバイ・ペアのアクティブ・データベースのcacheactive DSNの定義を示します。
[cacheactive] DataStore=/users/OracleCache/cacheact PermSize=64 OracleNetServiceName=orcl DatabaseCharacterSet=WE8ISO8859P1
ttIsqlユーティリティを開始して、cacheactive DSNにインスタンス管理者として接続し、データベースを作成します。次に、キャッシュ・マネージャ・ユーザーcacheuserを作成しますが、このユーザーの名前はコンパニオンOracle Databaseユーザーと同じです。この例では、キャッシュ管理ユーザーは、コンパニオンOracle Databaseユーザーとして機能します。
さらに、TimesTenデータベースにキャッシュされるOracle Database表を所有するOracle Databaseスキーマ・ユーザーと同じ名前でキャッシュ表ユーザーorattを作成します。
% ttIsql cacheactive Command> CREATE USER cacheuser IDENTIFIED BY timesten; Command> CREATE USER oratt IDENTIFIED BY timesten;
インスタンス管理者としてttIsqlユーティリティを使用して、例3-8に示されている処理を実行し、ADMIN権限を必要とするアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成するために必要な権限をキャッシュ・マネージャ・ユーザーcacheuserに付与します。
Command> GRANT CREATE SESSION, CACHE_MANAGER,
CREATE ANY TABLE, ADMIN TO cacheuser;
Command> exit
ttIsqlユーティリティを起動して、cacheactive DSNにキャッシュ・マネージャ・ユーザーとして接続します。ttCacheUidPwdSet組込みプロシージャをコールして、キャッシュ管理ユーザーの名前およびパスワードを設定します。
% ttIsql "DSN=cacheactive;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheUidPwdSet('cacheuser','oracle');
必要に応じて、「TimesTenデータベースとOracle Database間での接続テスト」に示した手順を使用して、アクティブ・データベースとOracle Database間の接続性をテストできます。
キャッシュ・マネージャ・ユーザーとしてttCacheStart組込みプロシージャをコールすることによって、アクティブ・データベースでキャッシュ・エージェントを起動します。
Command> CALL ttCacheStart;
次の文は、動的AWTキャッシュ・グループにキャッシュされるOracle Database表の定義です。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。
CREATE TABLE subscriber (subscriberid NUMBER(10) NOT NULL PRIMARY KEY, name VARCHAR2(100) NOT NULL, minutes_balance NUMBER(5) NOT NULL, last_call_duration NUMBER(4) NOT NULL);
キャッシュ・マネージャ・ユーザーが、oratt.subscriber表をキャッシュするAWTキャッシュ・グループを作成できるように、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。Oracle Databaseに対して非同期ライトスルー処理を行うには、oratt.subscriber表においてキャッシュ管理ユーザーに、INSERT、UPDATEおよびDELETEのOracle Database権限が付与されている必要があります。
次に、キャッシュ・マネージャ・ユーザーとしてCREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用して、TimesTenデータベースにキャッシュ・グループを作成します。たとえば、次の文では、oratt.subscriber表をキャッシュする動的AWTグローバル・キャッシュ・グループsubscriber_accountsが作成されます。
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP subscriber_accounts FROM oratt.subscriber (subscriberid NUMBER(10) NOT NULL PRIMARY KEY, name VARCHAR2(100) NOT NULL, minutes_balance NUMBER(5) NOT NULL, last_call_duration NUMBER(4) NOT NULL);
キャッシュ・マネージャ・ユーザーとして、CREATE ACTIVE STANDBY PAIR文を使用して、アクティブ・データベースにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
次の例では、cacheact、cachestandおよびsubscrはそれぞれ、アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバ・データベースのチェックポイント・ファイルおよびトランザクション・ログ・ファイルのファイル名接頭辞です。また、sys3、sys4およびsys5はそれぞれ、アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバ・データベースが存在するTimesTenシステムのホスト名です。
Command> CREATE ACTIVE STANDBY PAIR cacheact ON "sys3", cachestand ON "sys4" SUBSCRIBER subscr ON "sys5";
キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、アクティブ・データベースでレプリケーション・エージェントを起動します。次に、ttRepStateSet組込みプロシージャをコールすることによって、データベースをアクティブとして宣言します。
Command> CALL ttRepStart;
Command> CALL ttRepStateSet('active');
次に、アクティブ・スタンバイ・ペアのスタンバイ・データベースのcachestandby DSNの定義を示します。
[cachestandby] DataStore=/users/OracleCache/cachestand PermSize=64 OracleNetServiceName=orcl DatabaseCharacterSet=WE8ISO8859P1
インスタンス管理者として、スタンバイ・データベース・システムからttRepAdmin -duplicateユーティリティ・コマンドを実行することによって、スタンバイ・データベースをアクティブ・データベースの複製として作成します。アクティブ・データベースのインスタンスとスタンバイ・データベースのインスタンスのインスタンス管理者ユーザー名は同じである必要があります。
スタンバイ・データベースにはOracle Databaseとの接続性があるため、アクティブ・データベースのキャッシュ表がスタンバイ・データベースのキャッシュ表として複製されるように、-keepCGオプションを使用します。
例で使用される各要素の意味は、次のとおりです。
-fromオプションには、アクティブ・データベースのチェックポイント・ファイルおよびトランザクション・ログ・ファイルのファイル名接頭辞を指定します。
-hostオプションには、アクティブ・データベースが存在するTimesTenシステムのホスト名を指定します。
-uidオプションおよび-pwdオプションには、アクティブ・データベースに定義され、ADMIN権限が付与されているTimesTen内部ユーザーのユーザー名およびパスワードを指定します。
-cacheuidオプションおよび-cachepwdオプションには、キャッシュ管理ユーザーの名前およびパスワードを指定します。
cachestandbyは、スタンバイ・データベースのDSNです。
-keepCGオプションには、スタンバイ・データベースがアクティブ・データベースに定義されているキャッシュ・グループを保持することを指定します。
% ttRepAdmin -duplicate -from cacheact -host "sys3" -uid cacheuser -pwd timesten -cacheuid cacheuser -cachepwd oracle -keepCG cachestandby
ttIsqlユーティリティを起動して、cachestandby DSNにキャッシュ・マネージャ・ユーザーとして接続します。ttCacheUidPwdSet組込みプロシージャをコールして、キャッシュ管理ユーザーの名前およびパスワードを設定します。
% ttIsql "DSN=cachestandby;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheUidPwdSet('cacheuser','oracle');
必要に応じて、「TimesTenデータベースとOracle Database間での接続テスト」に示した手順を使用して、スタンバイ・データベースとOracle Database間の接続性をテストできます。
キャッシュ・マネージャ・ユーザーとしてttCacheStart組込みプロシージャをコールすることによって、スタンバイ・データベースでキャッシュ・エージェントを起動します。
Command> CALL ttCacheStart;
キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、スタンバイ・データベースでレプリケーション・エージェントを起動します。
Command> CALL ttRepStart;
次に、アクティブ・スタンバイ・ペアの読取り専用サブスクライバ・データベースのrosubscriber DSNの定義を示します。
[rosubscriber] DataStore=/users/OracleCache/subscr PermSize=64 DatabaseCharacterSet=WE8ISO8859P1
インスタンス管理者として、読取り専用サブスクライバ・データベース・システムからttRepAdmin -duplicateユーティリティ・コマンドを実行することによって、読取り専用サブスクライバ・データベースをスタンバイ・データベースの複製として作成します。スタンバイ・データベースと読取り専用サブスクライバ・データベースのインスタンス管理者ユーザー名は同じである必要があります。
読取り専用サブスクライバ・データベースにはOracle Databaseとの接続性がないため、スタンバイ・データベースのキャッシュ表が読取り専用サブスクライバ・データベースの通常の表として複製されるように、-noKeepCGオプションを使用します。
例で使用される各要素の意味は、次のとおりです。
-fromオプションには、スタンバイ・データベースのチェックポイント・ファイルおよびトランザクション・ログ・ファイルのファイル名接頭辞を指定します。
-hostオプションには、スタンバイ・データベースが存在するTimesTenシステムのホスト名を指定します。
-uidオプションおよび-pwdオプションには、スタンバイ・データベースに定義され、ADMIN権限が付与されているTimesTen内部ユーザーのユーザー名およびパスワードを指定します。
rosubscriberは、読取り専用サブスクライバ・データベースのDSNです。
% ttRepAdmin -duplicate -from cachestand -host "sys4" -uid cacheuser -pwd timesten -noKeepCG rosubscriber
キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、読取り専用サブスクライバ・データベースでレプリケーション・エージェントを起動します。
% ttIsql "DSN=rosubscriber;UID=cacheuser;PWD=timesten" Command> CALL ttRepStart; Command> exit
