4 キャッシュ・グループの定義

この章では、様々なタイプのキャッシュ・グループおよびその定義方法について説明します。内容は次のとおりです。

• キャッシュ・グループおよびキャッシュ表

• キャッシュ・グループの作成

• キャッシュ・グループでのエージングの実装

• 動的キャッシュ・グループ

• グローバル・キャッシュ・グループ

キャッシュ・グループおよびキャッシュ表

TimesTenデータベースにキャッシュするOracleデータは、キャッシュ・グループによって定義されます。 キャッシュ・グループを作成すると、キャッシュされたOracle表に対応するキャッシュ表がTimesTenデータベースに作成されます。

キャッシュ・グループ定義には、キャッシュされるOracle表ごとに個別の表定義を指定する必要があります。 TimesTenキャッシュ表の所有者、表名およびキャッシュされる列の名前は、対応するキャッシュ対象のOracle表の所有者、表名および列名と一致している必要があります。 キャッシュ表には、キャッシュされるOracle表のすべての列および行、または列および行のサブセットを含めることができます。

TimesTenにキャッシュされる各Oracle表には、NULLを指定できない列に主キーまたは一意索引が定義されている必要があります。 また、各TimesTenキャッシュ表に定義された主キーまたは一意索引が、キャッシュされたOracle表の主キーまたは一意索引と一致している必要があります。 たとえば、キャッシュされたOracle表の列C1、C2およびC3に複合主キーがある場合、TimesTenキャッシュ表の列C1、C2およびC3にも複合主キーが必要です。 したがって、キャッシュされたOracle表と同様に、キャッシュ表にも、NULLを指定できない列に主キーまたは一意索引が定義されている必要があります。

また、TimesTenキャッシュ表に対して非一意索引を作成できます。 キャッシュ表に索引を作成すると、TimesTenの通常の表の場合と同様に、表に対して発行された特定の問合せを高速化できます。

キャッシュ表には、キャッシュされたOracle表の一意索引と一致しない一意索引を作成しないでください。 このような一意索引を作成すると、キャッシュされたOracle表では発生しない一意制約による障害がキャッシュ表で発生する可能性があります。その結果、自動リフレッシュ処理が実行されたときに、2つのデータベース内でこれらの表が互いに同期化されなくなります。

TimesTenデータベースには、複数のキャッシュ・グループを含めることができます。 キャッシュ・グループには、1つ以上のキャッシュ表を含めることができます。Oracle表は、同じTimesTenデータベースにある複数のキャッシュ・グループにキャッシュすることはできません。

単一表のキャッシュ・グループ

最も単純なキャッシュ・グループは、単一のOracle表をキャッシュするキャッシュ・グループです。 単一表のキャッシュ・グループには、ルート表はありますが子表はありません。

図4-1に、customer表をキャッシュする単一表キャッシュ・グループtarget_customersを示します。

図4-1 単一表のキャッシュ・グループ

「図4-1 単一表のキャッシュ・グループ」の説明

複数表のキャッシュ・グループ

複数表のキャッシュ・グループは、1つのルート表および1つ以上の子表を定義するキャッシュ・グループです。 キャッシュ・グループに含めることのできるルート表は、1つのみです。 各子表は、外部キー制約を使用して、キャッシュ・グループ内のルート表または別の子表について、主キーまたは一意索引を参照する必要があります。 複数表のキャッシュ・グループ内の表は、TimesTenデータベース内で外部キー制約によって相互に関連付けられている必要がありますが、Oracle Database内で相互に関連付けられている必要はありません。 ルート表は、外部キー制約を使用してキャッシュ・グループ内の表を参照することはありません。

図4-2に、customer、ordersおよびorder_itemの各表をキャッシュする複数表のキャッシュ・グループcustomer_ordersを示します。 customer_ordersキャッシュ・グループ内の各親表が持つ主キーは、外部キー制約を介して子表によって参照されます。 customer表は外部キー制約を使用してキャッシュ・グループ内の表を参照していないため、この表がキャッシュ・グループのルート表です。 ルート表の主キーは、キャッシュ・グループの主キーとみなされます。 orders表は、customerルート表の子表です。 order_item表は、orders子表の子表です。

図4-2 複数表のキャッシュ・グループ

「図4-2 複数表のキャッシュ・グループ」の説明

複数表のキャッシュ・グループ内の表階層で、子表を他の子表の親に指定できます。 子表は2つ以上の親表を参照できません。 ただし、親表は2つ以上の子表から参照されることがあります。

図4-3に、不適切なキャッシュ表階層を示します。 customer表およびproduct表は、どちらも外部キー制約を介してキャッシュ・グループ内の表を参照していません。 これにより、キャッシュ・グループは2つのルート表を持つことになるため無効です。

図4-3 問題: 2つのルート表を含むキャッシュ・グループ

「図4-3 問題: 2つのルート表を含むキャッシュ・グループ」の説明

この問題を解決してすべての表をキャッシュするには、図4-4に示すように、customer、ordersおよびorder_itemの各表を含むキャッシュ・グループと、productおよびinventoryの各表を含む2つ目のキャッシュ・グループを作成します。

図4-4 解決策: 2つのキャッシュ・グループの作成

「図4-4 解決策: 2つのキャッシュ・グループの作成」の説明

キャッシュ・グループの作成

キャッシュ・グループは、システム管理またはユーザー管理のいずれかとして識別されます。 システム管理キャッシュ・グループでは特定の動作が実行されますが、ユーザー管理キャッシュ・グループの動作はカスタマイズできます。 システム管理キャッシュ・グループには、次のタイプがあります。

• 読取り専用キャッシュ・グループ

• ASYNCHRONOUS WRITETHROUGH（AWT）キャッシュ・グループ

• SYNCHRONOUS WRITETHROUGH（SWT）キャッシュ・グループ

ユーザー管理キャッシュ・グループの詳細は、「ユーザー管理キャッシュ・グループ」を参照してください。

キャッシュ・グループの作成には、次の内容も適用されます。

• AUTOREFRESHキャッシュ・グループ属性

• WHERE句の使用

• ON DELETE CASCADEキャッシュ表属性

• UNIQUE HASH ONキャッシュ表属性

キャッシュ・グループは、キャッシュ・マネージャ・ユーザーが作成して所有する必要があります。

読取り専用キャッシュ・グループ

読取り専用キャッシュ・グループでは、図4-5に示すように、TimesTenキャッシュ表を直接更新できない場合、キャッシュ動作が実行されて、キャッシュされたOracle表でコミットされた更新をキャッシュ表に自動的にリフレッシュします。

図4-5 読取り専用キャッシュ・グループ

「図4-5 読取り専用キャッシュ・グループ」の説明

なんらかの理由でTimesTenデータベースを利用できない場合でも、読取り専用キャッシュ・グループにキャッシュされているOracle表は更新できます。 TimesTenデータベースが処理を再開すると、TimesTenデータベースが利用できなかった間にキャッシュされたOracle表でコミットされた更新が、TimesTenキャッシュ表に自動的にリフレッシュされます。

例4-1、例4-10、例4-11、例4-17および例4-18に定義された読取り専用キャッシュ・グループにキャッシュされるOracle表の定義は、次のとおりです。 このOracle表はスキーマ・ユーザー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表からTimesTenキャッシュ表への自動リフレッシュ処理が実行されるようにするには、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のOracleユーザーに、これらの表に対するSELECT権限が付与されている必要があります。

読取り専用キャッシュ・グループを作成するには、CREATE READONLY CACHE GROUP文を使用します。

例4-1 読取り専用キャッシュ・グループの作成

次の文では、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表上で処理してから、更新を自動的にキャッシュ表にリフレッシュできます。

パススルー・レベルを設定する方法の詳細は、「パススルー・レベルの設定」を参照してください。

読取り専用キャッシュ・グループ内のキャッシュ表に対する、パススルーされた文の影響は、更新処理が発行されたトランザクションでは発生しません。 かわりに、この影響は、パススルーされた更新処理がOracle Databaseにコミットされ、キャッシュ・グループの次の自動リフレッシュが実行された後に発生します。 パススルーされた更新処理が、キャッシュされたOracle表で処理されるようにするには、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のOracleユーザーに、読取り専用キャッシュ・グループにキャッシュするOracle表に対するINSERT、UPDATEおよびDELETEの各権限が付与されている必要があります。

「Oracleデータのキャッシュ管理に使用されるOracleオブジェクトの手動による作成」の説明に従って、自動リフレッシュ・キャッシュ・グループの定義済動作を実行するためにOracleオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。

次に、ttIsqlユーティリティのcachesqlgetコマンドを実行して、読取り専用キャッシュ・グループにキャッシュされるOracle表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトを生成する必要があります。

これらのオブジェクトの作成方法の詳細は、「自動リフレッシュ・キャッシュ・グループ用のOracleオブジェクトの手動による作成」を参照してください。

読取り専用キャッシュ・グループの使用の制限

読取り専用キャッシュ・グループを使用する場合は、次の制限が適用されます。

• キャッシュ表は直接更新できません。

• キャッシュ表定義では、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表に対して発行された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エージング」を参照してください。

ASYNCHRONOUS WRITETHROUGH（AWT）キャッシュ・グループ

ASYNCHRONOUS WRITETHROUGH（AWT）キャッシュ・グループでは、図4-6に示すように、TimesTenキャッシュ表でコミット済の更新が、キャッシュされたOracle表に非同期で自動的に伝播されるというキャッシュ動作が実行されます。

図4-6 ASYNCHRONOUS WRITETHROUGHキャッシュ・グループ

「図4-6 ASYNCHRONOUS WRITETHROUGHキャッシュ・グループ」の説明

TimesTenデータベースでのトランザクションのコミットは、Oracle Databaseでのコミットとは非同期に実行されます。 これにより、アプリケーションはOracleトランザクションの完了を待機することなく、継続してTimesTenデータベースに対してトランザクションを発行できます。 ただし、アプリケーションでは、Oracle Database上でトランザクションが完了するタイミングを確認できません。

AWTキャッシュ・グループ内のキャッシュ表は、Oracle Databaseが利用できない場合も更新できます。 Oracle Databaseが処理を再開すると、Oracle Databaseが利用できなかった間にキャッシュ表でコミットされた更新が、キャッシュされたOracle表に自動的に伝播されます。

例4-2、例4-12および例4-13に定義されたAWTキャッシュ・グループにキャッシュされるOracle表の定義は、次のとおりです。このOracle表はスキーマ・ユーザー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ユーザーに、この表に対するSELECT権限が付与されている必要があります。 TimesTenキャッシュ表からキャッシュされたOracle表に非同期ライトスルー処理が実行されるようにするには、Oracleキャッシュ管理ユーザーに、oratt.customer表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

AWTキャッシュ・グループを作成するには、CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用します。

例4-2 AWTキャッシュ・グループの作成

次の文では、oratt.customer表をキャッシュするASYNCHRONOUS WRITETHROUGHキャッシュ・グループ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キャッシュ・グループを含むTimesTenデータベース上でレプリケーション・エージェントが実行されている必要があります。 CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を実行すると、TimesTenキャッシュ表上でコミットされた更新を、キャッシュされたOracle表に非同期に伝播できるレプリケーション・スキームが作成されます。

AWTキャッシュ・グループを作成した後、TimesTenデータベース上でレプリケーション・エージェントを起動します。

例4-3 レプリケーション・エージェントの起動

キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、レプリケーション・エージェントをプログラムから手動で起動できます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttRepStart;

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -repStartユーティリティ・コマンドを実行することによって、コマンドラインから起動することもできます。

% ttAdmin -repStart cachealone1

TimesTenデータベースに1つ以上のAWTキャッシュ・グループまたはレプリケーション・スキームがない場合、レプリケーション・エージェントは起動しません。

レプリケーション・エージェントが実行されている場合は、AWTキャッシュ・グループに対して別のCREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文またはDROP CACHE GROUP文を発行する前にエージェントを停止する必要があります。

例4-4 レプリケーション・エージェントの停止

キャッシュ・マネージャ・ユーザーとしてttRepStop組込みプロシージャをコールすることによって、レプリケーション・エージェントをプログラムから手動で停止できます。

Command> call ttRepStop;

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -repStopユーティリティ・コマンドを実行することによって、コマンドラインから停止することもできます。

% ttAdmin -repStop cachealone1

レプリケーション・エージェント起動ポリシーを設定して、TimesTenデータベースでレプリケーション・エージェント・プロセスを起動する方法およびタイミングを決定できます。

デフォルトの起動ポリシーはmanualであり、これはttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行することによって、手動でレプリケーション・エージェントを起動する必要があることを意味します。 実行しているレプリケーション・エージェント・プロセスを手動で停止するには、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行します。

起動ポリシーをalwaysに設定すると、TimesTenメイン・デーモン・プロセスの起動時にレプリケーション・エージェントを自動的に起動できます。 always起動ポリシーを使用しているときは、メイン・デーモンを実行している間、レプリケーション・エージェントを停止できません。ただし、起動ポリシーをmanualまたはnorestartに変更した後、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行して手動停止を発行すると、レプリケーション・エージェントを停止できます。

manualおよびalways起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後、レプリケーション・エージェントは自動的に再起動されます。

起動ポリシーをnorestartに設定することもできます。この場合、レプリケーション・エージェントを手動で起動するには、ttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行する必要があります。また、手動で停止するには、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行する必要があります。

norestart起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後でも、レプリケーション・エージェントは自動的に再起動されません。 ttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行して、レプリケーション・エージェントを手動で再起動する必要があります。

例4-5 レプリケーション・エージェント起動ポリシーの設定

インスタンス管理者として、キャッシュ・マネージャ・ユーザーにADMIN権限を付与します。

% ttIsql cachealone1
Command> GRANT ADMIN TO cacheuser;
Command> exit

レプリケーション・エージェント起動ポリシーは、キャッシュ・マネージャ・ユーザーとしてttRepPolicySet組込みプロシージャをコールすることによって、プログラムで設定できます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttRepPolicySet('manual');
Command> exit

また、ADMIN権限を持つTimesTen外部ユーザーとしてttAdmin -repPolicyユーティリティ・コマンドを実行することによって、コマンドラインから設定することもできます。

% ttAdmin -repPolicy always cachealone1

AWTキャッシュ・グループによって保証されることおよび保証されないこと

AWTキャッシュ・グループでは、次のことが保証されます。

• TimesTenデータベースとOracle Databaseの間の通信障害が原因でトランザクションが失われないこと。

• レプリケーション・エージェントが実行されていない場合、またはOracle Databaseへの接続を失った場合は、エージェントが再起動された後、またはOracle Databaseに再接続できた後に、TimesTenキャッシュ表に対してコミットされた更新を、キャッシュされたOracle表に自動伝播する処理が再開されること。

• トランザクションが、TimesTenデータベースでコミットされた順序と同じ順序で、Oracle Databaseでもコミットされること。

AWTキャッシュ・グループでは、次のことが保証されません。

• TimesTenデータベースでコミットが成功したすべてのトランザクションが、Oracle Databaseに正しく伝播され、コミットされること。 Oracleで実行エラーが発生すると、Oracle Databaseのトランザクションがロールバックされます。 たとえば、一意制約違反のためにOracleでの更新が失敗する可能性があります。 実行エラーが発生したトランザクションは再試行されません。

  実行エラーは、TimesTenデータベースのチェックポイント・ファイルと同じディレクトリに存在するTimesTenDatabaseFileName.awterrsファイルにレポートされます。 このファイルの内容については、『Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド』のTimesTenからレポートされる永続的なOracleエラーに関する説明を参照してください。

• Oracle更新の絶対順序が保存されること。これは、TimesTenは更新競合を解決しないためです。 次に例を示します。

  • AWTキャッシュ・グループ内のキャッシュ表で更新がコミットされます。 この同じ更新が、パススルー処理を使用して、キャッシュされたOracle表でコミットされます。 キャッシュ表の更新は、Oracleに自動的に非同期で伝播されますが、伝播された更新とパススルーされた更新をOracleで処理するタイミングによっては、キャッシュされたOracle表で直接処理される、パススルーされた更新を上書きする場合があります。

  • 2つの異なるTimesTenデータベース（DB1およびDB2）で、異なるAWTキャッシュ・グループが同じOracle表をキャッシュしています。 DB1内のキャッシュ表で、更新がコミットされます。 次に、DB2内のキャッシュ表で、更新がコミットされます。 2つのキャッシュ表は異なるTimesTenデータベースに存在し、同じOracle表をキャッシュしています。 ライトスルー処理は非同期であるため、DB2の更新がOracle Databaseに伝播されてから、DB1の更新が伝播される場合があります。この結果、DB1の更新によって、DB2の更新が上書きされます。

    動的AWTグローバル・キャッシュ・グループを使用すると、このような書込みの非一貫性が解決されます。 グローバル・キャッシュ・グループの詳細は、「グローバル・キャッシュ・グループ」を参照してください。

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キャッシュ・グループを作成または削除する前にレプリケーション・エージェントを停止する必要があります。

  レプリケーション・エージェントの停止方法および起動方法の詳細は、「レプリケーション・エージェントの管理」を参照してください。

• レプリケーション・エージェントが実行されていない場合、TimesTenキャッシュ表でコミットされた更新は、キャッシュされたOracle表に伝播されません。

• AWTキャッシュ・グループを作成するには、TimesTenデータベースの絶対パス名の長さを248文字以内にする必要があります。

• AWTキャッシュ・グループのキャッシュ表内に定義されたVARCHAR2、NVARCHAR2およびVARBINARYの列は、4MB（4,194,304バイト）以内にする必要があります。

• TimesTenでは、Oracleで発生する更新競合は検出または解決されません。 キャッシュされたOracle表で直接コミットされた更新は、キャッシュ表の更新がOracleに伝播されたときに、TimesTenキャッシュ表でコミットされた更新によって上書きされる場合があります。

• TimesTenでは、単一のSQL文によって一意索引の制約違反が発生するかどうかを判別するときに、遅延チェックを実行します。

  たとえば、キャッシュされたOracle表のNUMBER列に一意索引があり、TimesTenキャッシュ表の同じNUMBER列にも一意索引があるとします。 キャッシュされたOracle表には5つの行があり、キャッシュ表にも同じ5つの行があります。 NUMBER列の値の範囲は1から5です。

  キャッシュ表に対してUPDATE文を発行し、すべての行のNUMBER列の値を1増分します。 この処理は、キャッシュ表では成功しますが、キャッシュされたOracle表に伝播されると失敗します。

  これは、TimesTenでは、一意索引の制約のチェックが、すべての行が更新された後、文の実行の最後に行われるためです。 ただし、Oracleでは、1行更新されるたびに制約のチェックが実行されます。

  したがって、NUMBER列の値が1であるキャッシュ表の行が2に変更され、この更新がOracleに伝播されると、キャッシュされたOracle表のNUMBER列の値が2となった行で一意制約違反が発生します。

SYNCHRONOUS WRITETHROUGH（SWT）キャッシュ・グループ

SYNCHRONOUS WRITETHROUGH（SWT）キャッシュ・グループでは、図4-7に示すように、TimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle表に自動的に同期して伝播されるというキャッシュ動作が実行されます。

図4-7 SYNCHRONOUS WRITETHROUGHキャッシュ・グループ

「図4-7 SYNCHRONOUS WRITETHROUGHキャッシュ・グループ」の説明

TimesTenデータベースでのトランザクションのコミットは、Oracle Databaseでのコミットと同期して実行されます。 アプリケーションによってTimesTenデータベースでトランザクションがコミットされると、このトランザクションは、TimesTenで処理される前にOracle Databaseで処理されます。 Oracle DatabaseとTimesTenデータベースの両方でトランザクションが完了するまで、アプリケーションはブロックされます。

Oracleでトランザクションのコミットが失敗した場合は、アプリケーションでTimesTenのトランザクションをロールバックする必要があります。 Oracleトランザクションのコミットが成功し、TimesTenトランザクションのコミットが失敗した場合、SWTキャッシュ・グループ内のキャッシュ表は、キャッシュされたOracle表と同期化されなくなります。 キャッシュされたOracle表とキャッシュ表を手動で再同期化するには、ttCachePropagateFlagSet組込みプロシージャをコールして更新の伝播を無効にしてから、TimesTenでトランザクションのコミットが失敗した原因となった問題を修正した後、TimesTenデータベースでトランザクションを再発行します。 また、付随するキャッシュ・グループをリロードすることによって、キャッシュされたOracle表とキャッシュ表を再同期化することもできます。

例4-6に定義されたSWTキャッシュ・グループにキャッシュされるOracle表の定義は、次のとおりです。 このOracle表はスキーマ・ユーザー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ユーザーに、この表に対するSELECT権限が付与されている必要があります。 TimesTenキャッシュ表からキャッシュされたOracle表に同期ライトスルー処理が実行されるようにするには、このOracleユーザーにoratt.product表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

SWTキャッシュ・グループを作成するには、CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用します。

例4-6 SWTキャッシュ・グループの作成

次の文では、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))

SWTキャッシュ・グループの使用の制限

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文を発行できません。

ユーザー管理キャッシュ・グループ

システム管理キャッシュ・グループ（読取り専用、AWT、SWT）がアプリケーションの要件を満たさない場合は、カスタマイズされたキャッシュ動作を定義するユーザー管理キャッシュ・グループを作成できます。次に例を示します。

• ユーザー管理キャッシュ・グループは、AUTOREFRESHキャッシュ・グループ属性およびPROPAGATEキャッシュ表属性を使用することによって、コミットされた更新をOracle DatabaseとTimesTenデータベースの間で自動的にリフレッシュおよび伝播するように定義できます。 両方の属性を使用すると、双方向送信が可能になるため、TimesTenキャッシュ表またはキャッシュされたOracle表に対してコミットされた更新が、相互に伝播またはリフレッシュされます。

• LOAD CACHE GROUP文、REFRESH CACHE GROUP文およびFLUSH CACHE GROUP文を使用して、Oracle DatabaseとTimesTenデータベースの間でのコミットされた更新の送信を手動で制御できます。

• ユーザー管理キャッシュ・グループ内の各キャッシュ表に対してREADONLYまたはPROPAGATEキャッシュ表属性を指定すると、表レベルで読取り専用または同期ライトスルーの動作を定義できます。

例4-7および例4-8に定義されたユーザー管理キャッシュ・グループにキャッシュされるOracle表の定義は、次のとおりです。このOracle表はスキーマ・ユーザー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-7 単一表のユーザー管理キャッシュ・グループの作成

次の文では、図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)

例4-8 単一表のユーザー管理キャッシュ・グループ

「図4-8 単一表のユーザー管理キャッシュ・グループ」の説明

regionを除いて、すべての列がキャッシュされます。 顧客は、顧客IDが1001以上である場合にのみキャッシュされます。 キャッシュ表oratt.active_customerまたはキャッシュされたOracle表oratt.active_customerでコミットされた更新は、対応する表に送信されます。

キャッシュ・マネージャ・ユーザーが、oratt.active_customer表をキャッシュするユーザー管理キャッシュ・グループを作成できるようにし、キャッシュされたOracle表からTimesTenキャッシュ表への自動リフレッシュ処理が実行されるようにするには、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のOracleユーザーに、この表に対するSELECT権限が付与されている必要があります。 TimesTenキャッシュ表からキャッシュされたOracle表に同期ライトスルー処理が実行されるようにするには、このOracleユーザーにoratt.active_customer表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

この例で、AUTOREFRESHキャッシュ・グループ属性は、キャッシュされたOracle表oratt.active_customerに対してコミットされた更新が、TimesTenのoratt.active_customerキャッシュ表に30秒ごとに自動的にリフレッシュされるように指定します。 PROPAGATEキャッシュ表属性は、キャッシュ表に対してコミットされた更新が、キャッシュされたOracle表に自動的に同期して伝播されるように指定します。

自動リフレッシュのモード、間隔および状態の定義の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

「Oracleデータのキャッシュ管理に使用されるOracleオブジェクトの手動による作成」の説明に従って、AUTOREFRESH MODE INCREMENTALキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループの定義済動作を実行するためにOracleオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。

次に、ttIsqlユーティリティのcachesqlgetコマンドを実行して、ユーザー管理キャッシュ・グループにキャッシュされるOracle表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトを生成する必要があります。

詳細は、「自動リフレッシュ・キャッシュ・グループ用のOracleオブジェクトの手動による作成」を参照してください。

例4-8 複数表のユーザー管理キャッシュ・グループの作成

次の文では、図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)

例4-9 複数表のユーザー管理キャッシュ・グループ

「図4-9 複数表のユーザー管理キャッシュ・グループ」の説明

同じ品目を5つ以上注文したWest地域の顧客のみがキャッシュされます。

キャッシュ・マネージャ・ユーザーが、oratt.active_customer、oratt.ordertab、oratt.cust_interestsおよびoratt.orderdetailsの各表すべてをキャッシュするユーザー管理キャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のOracleユーザーに、これらの表に対するSELECT権限が付与されている必要があります。 また、これらのTimesTenキャッシュ表からキャッシュされたOracle表に同期ライトスルー処理が実行されるようにするには、このOracleユーザーにoratt.active_customer表およびoratt.ordertab表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

western_customersキャッシュ・グループ内の各キャッシュ表には主キーがあります。 各子表は、外部キー制約を使用して親表を参照します。 oratt.active_customerルート表およびoratt.orderdetails子表には、それぞれキャッシュされる行を制限するWHERE句が含まれます。 oratt.active_customerルート表とoratt.ordertab子表の両方でPROPAGATEキャッシュ表属性を使用しているため、これらのキャッシュ表でコミットされた更新は、キャッシュされたOracle表に自動的に伝播されます。 oratt.cust_interests子表ではREADONLYキャッシュ表属性を使用しているため、この表は直接更新できません。

PROPAGATEキャッシュ表属性

PROPAGATEキャッシュ表属性は、ユーザー管理キャッシュ・グループ内のキャッシュ表に対してのみ指定できます。 PROPAGATEは、TimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle表に自動的に同期して次のように伝播されるように指定します。

1. 最初に、Oracle Databaseでコミットが試行されます。 Oracleでコミットが失敗すると、TimesTenデータベースではコミットが試行されず、アプリケーションはTimesTenトランザクションをロールバックする必要があります。 このため、Oracle DatabaseはTimesTenでコミットされた更新を見落とすことがなくなります。

2. Oracle Databaseでコミットが成功すると、TimesTenデータベースでコミットが試行されます。 TimesTenでコミットが失敗すると、失敗の原因を示すエラー・メッセージがTimesTenから返されます。 この場合は、手動でキャッシュ表をOracle表と再同期化する必要があります。

   キャッシュ表をOracle表と再同期化する方法の詳細は、「SYNCHRONOUS WRITETHROUGH（SWT）キャッシュ・グループ」を参照してください。

デフォルトでは、ユーザー管理キャッシュ・グループ内のキャッシュ表は、NOT PROPAGATEキャッシュ表属性を使用して作成されるため、キャッシュ表でコミットされた更新は、キャッシュされたOracle表に伝播されません。

キャッシュ表でPROPAGATEキャッシュ表属性を使用しているとき、キャッシュされたOracle表に伝播しない更新を、キャッシュ表でコミットすることが必要となる場合があります。 ttCachePropagateFlagSet組込みプロシージャを使用して自動伝播を無効にし、キャッシュ表でコミットされた更新が、キャッシュされたOracle表に伝播されないようにしてください。

自動伝播を無効にした場合は、FLUSH CACHE GROUP文を使用すると、ユーザー管理キャッシュ・グループ内のキャッシュ表でコミットされた挿入および更新を、キャッシュされたOracle表に手動で伝播できます（「ユーザー管理キャッシュ・グループのフラッシュ」を参照）。

PROPAGATEキャッシュ表属性を使用する場合は、次の制限が適用されます。

• キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、すべてのキャッシュ表でPROPAGATEキャッシュ表属性を指定するか、またはいずれのキャッシュ表にもPROPAGATEキャッシュ表属性を指定しないようにする必要があります。

  AUTOREFRESHキャッシュ・グループ属性の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

• キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、いずれのキャッシュ表に対してもNOT PROPAGATEキャッシュ表属性を明示的に指定できません。

• PROPAGATEとREADONLYキャッシュ表属性の両方を同じキャッシュ表で使用することはできません。

  READONLYキャッシュ表属性の詳細は、「READONLYキャッシュ表属性」を参照してください。

• 1つ以上のキャッシュ表でPROPAGATEキャッシュ表属性もREADONLYキャッシュ表属性も使用していない場合を除いて、キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。

  FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

• キャッシュ表にPROPAGATEキャッシュ表属性が指定されると、キャッシュ・グループを削除して再度作成する場合を除いて、この属性を変更できません。

• TimesTenでは、キャッシュされたOracle表で直接更新されたデータが、伝播処理によって上書きされないようにするための競合チェックを実行しません。 したがって、TimesTenキャッシュ表またはキャッシュされたOracle表で更新を直接実行し、両方の表では更新を実行しないようにしてください。

例4-7では、oratt.active_customerキャッシュ表でPROPAGATEキャッシュ表属性を使用しています。

READONLYキャッシュ表属性

READONLYキャッシュ表属性は、ユーザー管理キャッシュ・グループ内のキャッシュ表に対してのみ指定できます。 READONLYは、キャッシュ表が直接更新されないように指定します。 デフォルトでは、ユーザー管理キャッシュ・グループ内のキャッシュ表は更新可能です。

すべてのキャッシュ表が読取り専用である読取り専用キャッシュ・グループとは異なり、ユーザー管理キャッシュ・グループでは、READONLYキャッシュ表属性を使用して、個々のキャッシュ表を読取り専用に指定できます。

READONLYキャッシュ表属性を使用する場合は、次の制限が適用されます。

• キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、すべてのキャッシュ表でREADONLYキャッシュ表属性を指定するか、またはいずれのキャッシュ表にもREADONLYキャッシュ表属性を指定しないようにする必要があります。

  AUTOREFRESHキャッシュ・グループ属性の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

• READONLYとPROPAGATEキャッシュ表属性の両方を同じキャッシュ表で使用することはできません。

  PROPAGATEキャッシュ表属性の詳細は、「PROPAGATEキャッシュ表属性」を参照してください。

• 1つ以上のキャッシュ表でREADONLYキャッシュ表属性もPROPAGATEキャッシュ表属性も使用していない場合を除いて、キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。

  FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

• キャッシュ表にREADONLYキャッシュ表属性が指定されると、キャッシュ・グループを削除して再度作成する場合を除いて、この属性を変更できません。

例4-8では、oratt.cust_interestsキャッシュ表でREADONLYキャッシュ表属性を使用しています。

AUTOREFRESHキャッシュ・グループ属性

AUTOREFRESHキャッシュ・グループ属性は、CREATE CACHE GROUP文を使用して読取り専用キャッシュ・グループまたはユーザー管理キャッシュ・グループを作成する場合に指定できます。 AUTOREFRESHは、キャッシュされたOracle表でコミットされた更新が、TimesTenキャッシュ表に自動的にリフレッシュされることを示します。 読取り専用キャッシュ・グループには、デフォルトで自動リフレッシュが定義されます。

自動リフレッシュ属性のデフォルト設定は、次のとおりです。

• 自動リフレッシュ・モードはINCREMENTALです。

• 自動リフレッシュ間隔は5分です。

• 自動リフレッシュ状態はPAUSEDです。

TimesTenでは、2つの自動リフレッシュ・モードがサポートされています。

• INCREMENTAL: キャッシュ・グループの自動リフレッシュ間隔に基づいて、キャッシュされたOracle表でコミットされた更新がTimesTenキャッシュ表に自動的にリフレッシュされます。 INCREMENTAL自動リフレッシュ・モードでは、Oracleオブジェクトを使用して、キャッシュされたOracle表でコミットされた更新を追跡します。 これらのオブジェクトの詳細は、「キャッシュ環境の管理に使用するOracleオブジェクト」を参照してください。

• FULL: キャッシュ・グループの自動リフレッシュ間隔に基づいて、すべての行をアンロードした後、キャッシュされたOracle表からリロードすることによって、すべてのキャッシュ表が自動的にリフレッシュされます。

INCREMENTAL自動リフレッシュ・モードを使用すると、キャッシュされたOracle表でコミットされた更新ごとにキャッシュ・グループをリフレッシュするためのオーバーヘッドが発生します。 完全自動リフレッシュ・モードで使用すると、オーバーヘッドは発生しません。

INCREMENTAL自動リフレッシュ・モードを使用すると、キャッシュされたOracle表でコミットされた更新は、Oracle Database内の変更ログ表で追跡されます。 特定の環境下では、変更ログ・レコードの一部が、TimesTenキャッシュ表に自動的にリフレッシュされる前に変更ログ表から削除される可能性があります。 このような状況が発生すると、TimesTenはキャッシュ・グループの完全自動リフレッシュを開始します。 変更ログ表が存在する表領域が一杯になった場合に実行するアクションを構成する方法の詳細は、「キャッシュ管理ユーザーの表領域の監視」を参照してください。

自動リフレッシュ間隔では、自動リフレッシュ処理の実行頻度を分、秒またはミリ秒の単位で指定します。 自動リフレッシュ間隔が同じキャッシュ・グループは、同じトランザクション内でリフレッシュされます。

自動リフレッシュ状態は、ON、PAUSEDまたはOFFに設定できます。 キャッシュ・グループの自動リフレッシュ状態がONの場合、自動リフレッシュ処理はTimesTenによってスケジュールされます。

キャッシュ・グループの自動リフレッシュ状態がOFFの場合、キャッシュされたOracle表でコミットされた更新は追跡されません。

キャッシュ・グループの自動リフレッシュ状態がPAUSEDの場合、キャッシュされたOracle表でコミットされた更新はOracle Database内で追跡されますが、状態がONに変更されるまでTimesTenキャッシュ表には自動的にリフレッシュされません。

AUTOREFRESHキャッシュ・グループ属性を使用する場合は、次の制限が適用されます。

• キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。

  FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

• キャッシュされたOracle表に対して発行されたTRUNCATE TABLE文は、TimesTenキャッシュ表に自動的にリフレッシュされません。 キャッシュされたOracle表に対してTRUNCATE TABLE文を発行する前に、ALTER CACHE GROUP文を使用して、キャッシュ表を含むキャッシュ・グループの自動リフレッシュ状態をPAUSEDに変更してください。

  ALTER CACHE GROUP文の詳細は、「キャッシュ・グループの変更」を参照してください。

  次に、キャッシュされたOracle表に対して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キャッシュ・グループ属性を指定できません。

• LRUエージングがデフォルトで定義されている、キャッシュ・グループが動的である場合を除いて、キャッシュ・グループにLRUエージングを指定できません。

  LRUエージングの詳細は、「LRUエージング」を参照してください。

例4-7では、update_anywhere_customersキャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用しています。

キャッシュ・グループの変更

自動リフレッシュ・キャッシュ・グループを作成した後、ALTER CACHE GROUP文を使用すると、キャッシュ・グループの自動リフレッシュのモード、間隔または状態を変更できます。 最初から自動リフレッシュを定義せずに作成されたキャッシュ・グループに対しては、ALTER CACHE GROUPを使用して自動リフレッシュをインスタンス化することはできません。

キャッシュ・グループの自動リフレッシュ状態をOFFに変更したり、自動リフレッシュ処理を実行中のキャッシュ・グループを削除した場合の動作は、次のとおりです。

• LockWait DSN属性の設定が0（ゼロ）より大きな値である場合、自動リフレッシュ処理は停止します。ALTER CACHE GROUP文またはDROP CACHE GROUP文が自動リフレッシュ処理より優先して使用されます。

• LockWait属性が0（ゼロ）に設定されている場合は、自動リフレッシュ処理が続行されます。自動リフレッシュ処理が完了するか、またロック・タイムアウト・エラーが発生して文が失敗するまで、ALTER CACHE GROUP文またはDROP CACHE GROUP文はブロックされます。

例4-9 キャッシュ・グループの自動リフレッシュ属性の変更

次の文では、customer_ordersキャッシュ・グループの自動リフレッシュのモード、間隔および状態が変更されます。

ALTER CACHE GROUP customer_orders SET AUTOREFRESH MODE FULL
ALTER CACHE GROUP customer_orders SET AUTOREFRESH INTERVAL 30 SECONDS
ALTER CACHE GROUP customer_orders SET AUTOREFRESH STATE ON

自動リフレッシュ・キャッシュ・グループ用のOracleオブジェクトの手動による作成

「Oracleデータのキャッシュ管理に使用されるOracleオブジェクトの手動による作成」の説明に従って、自動リフレッシュ・キャッシュ・グループの定義済動作を実行するためにOracleオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。

次に、キャッシュ・マネージャ・ユーザーとして、INCREMENTAL_AUTOREFRESHオプションおよびINSTALLフラグを指定してttIsqlユーティリティのcachesqlgetコマンドを実行する必要があります。 このコマンドを実行すると、自動リフレッシュ・キャッシュ・グループにキャッシュされたOracle表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトが生成されます。 これらのOracleオブジェクトを使用して、キャッシュされたOracle表の更新が追跡されるため、更新はキャッシュ表に自動的にリフレッシュされます。

次に、SQL*Plusを使用して、ttIsqlユーティリティのcachesqlgetコマンドで生成されたスクリプトをsysユーザーとして実行します。 その後、ALTER CACHE GROUP文を使用して、キャッシュ・グループの自動リフレッシュ状態をPAUSEDに変更します。

例4-10 Oracleオブジェクトを手動で作成した場合の読取り専用キャッシュ・グループの作成

最初の文で、自動リフレッシュ状態が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=cachealone1;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

WHERE句の使用

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表にフラッシュできるユーザー管理キャッシュ・グループでは、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-8では、oratt.active_customer表とoratt.orderdetails表の両方にWHERE句が含まれます。

CREATE CACHE GROUP文での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))

WHERE句でのOracle PL/SQLファンクションの参照

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データベースでは、たとえば、このファンクション用に作成されたパブリック・シノニムを参照する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キャッシュ表属性は、いずれのキャッシュ・グループ・タイプのキャッシュ表にも指定できます。 ON DELETE CASCADEは、参照されるキー値を含む行が親表から削除されると、依存する外部キーを持つ子表の行も削除されるように指定します。

例4-11 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表の外部キーの適切なサブセットである必要があります。 キャッシュされたOracle表に対するON DELETE CASCADEアクションは、個々の削除としてTimesTenキャッシュ表に適用されます。 キャッシュ表に対するON DELETE CASCADEアクションは、カスケード処理としてキャッシュされたOracle表に適用されます。

• TimesTenキャッシュ表とキャッシュされたOracle表間の外部キーの照合は、キャッシュ・グループの作成時にのみ実行されます。 キャッシュされたOracle表の外部キーがキャッシュ・グループの作成後に変更された場合は、カスケード削除処理が機能しないことがあります。

ON DELETE CASCADEキャッシュ表属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE CACHE GROUPに関する説明を参照してください。

UNIQUE HASH ONキャッシュ表属性

UNIQUE HASH ONキャッシュ表属性は、いずれのキャッシュ・グループ・タイプのキャッシュ表にも指定できます。 UNIQUE HASH ONは、キャッシュ表の主キー列に、範囲索引ではなくハッシュ索引が作成されるように指定します。ハッシュ索引で指定される列は、主キーの列と同じである必要があります。 また、UNIQUE HASH ONキャッシュ表属性は、ハッシュ索引のサイズの指定にも使用されます。

例4-12 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に関する説明を参照してください。

Oracleシノニムのキャッシュ

AUTOREFRESHキャッシュ・グループ属性を使用しないAWT、SWTまたはユーザー管理キャッシュ・グループでは、プライベート・シノニムをキャッシュできます。 プライベート・シノニムは、パブリック・シノニムまたはプライベート・シノニムを参照できますが、実際にキャッシュされるのは表であるため、最終的には表を参照する必要があります。

キャッシュされたシノニムによって直接的または間接的に参照される表は、シノニムをキャッシュするキャッシュ・グループの所有者と同じ名前を持つOracleユーザー以外のユーザーによって所有されます。 表は、シノニムと同じOracle Databaseに存在する必要があります。 キャッシュされたシノニム自体は、シノニムをキャッシュするキャッシュ・グループの所有者と同じ名前のOracleユーザーによって所有されます。

キャッシュ・グループでのエージングの実装

キャッシュ・グループには、エージング・タイプ、エージング属性およびエージング状態を指定するエージング・ポリシーを定義できます。 TimesTenでは、最低使用頻度（LRU）エージングおよび時間ベースのエージングの2つのエージング・タイプがサポートされています。

LRUエージングでは、指定されたデータベースの使用状況の範囲に基づいて、最低使用頻度または最低参照頻度のデータが削除されます。 時間ベースのエージングでは、指定されたデータ存続期間およびエージング・プロセスの頻度に基づいてデータが削除されます。 同じTimesTenデータベース内でLRUエージングと時間ベースのエージングの両方を使用できますが、特定のキャッシュ・グループに対して定義できるエージング・ポリシーは1つのみです。

エージングはキャッシュ・インスタンス・レベルで実行されるため、エージング・ポリシーはCREATE CACHE GROUP文内のルート表のキャッシュ表定義で指定され、キャッシュ・グループ内のすべてのキャッシュ表に適用されます。 キャッシュ表から行がエージ・アウトまたは削除されたとき、キャッシュされたOracle表の行は削除されません。

キャッシュ・グループにエージング・ポリシーを追加するには、ルート表に対してALTER TABLE文を使用します。 キャッシュ・グループのエージング・ポリシーを変更するには、ルート表に対してALTER TABLE文を使用して既存のエージング・ポリシーを削除した後、新しいエージング・ポリシーを追加します。

この項では、エージング・ポリシーを含むキャッシュ・グループ定義について説明します。内容は次のとおりです。

• LRUエージング

• 時間ベースのエージング

• エージング・プロセスの手動によるスケジューリング

• スライド期間の構成

LRUエージング

LRUエージングを使用すると、最低使用頻度のデータを削除することによって、TimesTenデータベースで使用するメモリーの量を、指定されたしきい値の範囲内に維持できます。 LRUエージングは、明示的にロードされる自動リフレッシュ・キャッシュ・グループを除いて、すべてのキャッシュ・グループ・タイプに対して定義できます。 動的キャッシュ・グループには、デフォルトでLRUエージングが定義されます。

キャッシュ・グループに対してLRUエージング・ポリシーを定義するには、CREATE CACHE GROUP文のキャッシュ表定義でAGING LRU句を使用します。エージング状態がデフォルトのONに設定されている場合、エージングは自動的に発生します。

例4-13 キャッシュ・グループに対する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-14 LRUエージング属性の設定

次のプロシージャ・コールは、エージング・プロセスによって5分ごとにチェックが行われ、TimesTenデータベースの永続パーティションの領域使用状況が95パーセントを超えているかどうかが確認されるように指定します。 超えている場合は、領域使用状況が75パーセント以下になるまで、最低使用頻度のデータが自動的にエージ・アウトまたは削除されます。

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-15に定義されたAWTキャッシュ・グループにキャッシュされるOracle表の定義は、次のとおりです。このOracle表はスキーマ・ユーザーorattによって所有されています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。

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ユーザーに、これらの表に対するSELECT権限が付与されている必要があります。 TimesTenキャッシュ表からキャッシュされたOracle表に非同期ライトスルー処理が実行されるようにするには、Oracleキャッシュ管理ユーザーにoratt.orders表およびoratt.order_item表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

例4-15 キャッシュ・グループに対する時間ベースのエージング・ポリシーの定義

次の文では、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-16 ワンタイム・エージング・プロセスの開始

次のプロシージャ・コールでは、ttAgingScheduleNowがコールされるタイミングに基づいて、oratt.orders表のワンタイム・エージング・プロセスが開始されます。

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をコールして、キャッシュ・グループに対してエージング・プロセスを開始します。

スライド期間の構成

時間ベースのエージングを使用すると、キャッシュ・グループにスライド期間が実装されます。 スライド期間構成では、表に特定の時間間隔を満たすデータのみが含まれるように、定期的に新しい行がキャッシュ表に挿入され、古い行がキャッシュ表から削除されます。

キャッシュ・グループにスライド期間を構成するには、INCREMENTAL自動リフレッシュ・モードを使用し、時間ベースのエージング・ポリシーを定義します。 自動リフレッシュ処理では、キャッシュされたOracle表にある行のタイムスタンプをチェックして、TimesTenキャッシュ表に新しいデータをリフレッシュする必要があるかどうかが決定されます。 システム時刻およびタイムゾーンは、OracleとTimesTenの各システムで同じである必要があります。

キャッシュ・グループでINCREMENTAL自動リフレッシュ・モードを使用しない場合、スライド期間を構成するには、LOAD CACHE GROUP文、REFRESH CACHE GROUP文またはINSERT文を使用するか、動的ロード処理を使用して、新しいデータをキャッシュ表に挿入します。

例4-17 スライド期間のプロパティを持つキャッシュ・グループの定義

次の文では、読取り専用キャッシュ・グループ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表oratt.ordersの新しいデータは、1440分ごとにTimesTenキャッシュ表oratt.ordersに自動的にリフレッシュされます。 現在のシステム・タイムスタンプとwhen_shipped列のタイムスタンプの差が30日を超えるキャッシュ・インスタンスは、エージングの対象となります。 エージング・プロセスによって24時間ごとにチェックが行われ、キャッシュ表からエージ・アウトできるキャッシュ・インスタンスがあるかどうかが確認されます。 したがって、このキャッシュ・グループには、過去30日以内に送信された注文が保存されます。

エージングに使用される自動リフレッシュ間隔および存続期間によって、特定の行がキャッシュ表内に保持される期間が決定します。 キャッシュ表で存続期間が経過するのを待たずにデータがキャッシュ表からエージ・アウトされる可能性があります。 たとえば、読取り専用キャッシュ・グループでは、自動リフレッシュ間隔が3日で、存続期間が30日である場合、キャッシュ表にリフレッシュされたときにすでに3日経過しているデータは27日後に削除されます。これは、エージングが、キャッシュ表にデータがリフレッシュされたときではなく、TimesTenキャッシュ表にロードされるキャッシュされたOracle表の行に保存されたタイムスタンプに基づいているためです。

動的キャッシュ・グループ

動的キャッシュ・グループ内のデータは、リクエストに応じてロードされます。 たとえば、コール・センター・アプリケーションでは、顧客の情報が非常に多い場合があるため、すべての顧客の情報をTimesTenに事前ロードしないことがあります。 かわりに、動的キャッシュ・グループを使用すると、顧客から問合せがあった場合または顧客がシステムにログオンした場合など、必要な場合にのみ特定の顧客の情報をロードできます。

どのシステム管理キャッシュ・グループ・タイプ（読取り専用、AWT、SWT）も、動的キャッシュ・グループとして定義できます。 ユーザー管理キャッシュ・グループは、AUTOREFRESHキャッシュ・グループ属性とPROPAGATEキャッシュ表属性の両方を使用している場合を除いて、動的キャッシュ・グループとして定義できます。

動的キャッシュ・グループを作成するには、CREATE DYNAMIC CACHE GROUP文を使用します。

例4-18 動的読取り専用キャッシュ・グループ

次の文では、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表からキャッシュ表にデータがロードされます。 動的キャッシュ・グループの場合も、LOAD CACHE GROUP文を使用してデータをキャッシュ表にロードできます。 ただし、動的キャッシュ・グループでは、通常、SELECT文、INSERT文またはUPDATE文でキャッシュ表が参照された場合に、表にデータが存在しないためにキャッシュ・ミスになると、データが自動的にロードされます。 詳細は、「キャッシュ・グループの動的ロード」を参照してください。

明示的にロードされるキャッシュ・グループと動的キャッシュ・グループの両方で、LOAD CACHE GROUP文は、キャッシュされたOracle表に存在しTimesTenキャッシュ表には存在しない対象データをキャッシュ表にロードします。 ただし、キャッシュ表に行が存在する場合に、キャッシュされたOracle表にその行より新しいバージョンが存在すると、その行はLOAD CACHE GROUP文の条件を満たしていてもキャッシュ表にロードされません。

これに対して、REFRESH CACHE GROUP文では、キャッシュ表に存在する対象行をリロードし、キャッシュの内容を効率的にリフレッシュします。 明示的にロードされるキャッシュ・グループの場合、リフレッシュされる行は、REFRESH CACHE GROUP文の条件を満たすすべての行です。 ただし、動的キャッシュ・グループの場合、リフレッシュされる行は、条件を満たし、キャッシュ表にすでに存在する行です。 つまり、最終的にリフレッシュされる行は、キャッシュされたOracle表で更新または削除された行であり、挿入された行ではありません。 したがって、リフレッシュ処理では、キャッシュ表にすでに存在する行のみが処理されます。 リフレッシュが行われても、動的キャッシュ・グループのキャッシュ表に新しい行はロードされません。

動的読取り専用キャッシュ・グループのキャッシュ・インスタンス内にあるデータは、Oracle表の対応する行内にあるデータと一貫性があります。 自動リフレッシュの状態と間隔設定を考慮すると、明示的にロードされるキャッシュ・グループのキャッシュ・インスタンス内にあるデータは、Oracle表の対応する行内にあるデータと常に一貫性があります。

LRUエージングがデフォルトで定義されているため、動的キャッシュ・グループ内にあるデータはエージングの対象です。 ttAgingLRUConfig組込みプロシージャを使用すると、エージング・サイクルおよびTimesTenデータベースの領域使用状況のしきい値に対するデフォルトまたは現在のLRUエージング属性設定を上書きできます。 また、動的キャッシュ・グループに対して時間ベースのエージングを定義して、LRUエージングを上書きすることもできます。

グローバル・キャッシュ・グループ

Oracle表は、同じTimesTenデータベースにある複数のキャッシュ・グループにキャッシュすることはできません。 ただし、異なるTimesTenデータベースにある別々のキャッシュ・グループにキャッシュすることは可能です。 別々のAWTキャッシュ・グループに表がキャッシュされており、同じキャッシュ・インスタンスが複数のTimesTenデータベースで同時に更新された場合、キャッシュされたOracle表にこの更新が伝播される順序は保証されません。 また、TimesTenデータベース間で、更新されたキャッシュ表の内容に一貫性がなくなります。

TimesTenのキャッシュ・グリッドを使用すると、Oracle Databaseを使用するユーザーが、TimesTenデータベース全体で読取り/書込みデータの一貫性を保持しながら、複数のシステムにまたがって横方向にキャッシュ・グループを拡大できるようになり、この問題が回避されます。 キャッシュ・グリッドは、アプリケーション・データを一括管理する一連のTimesTenデータベースです。

キャッシュ・グループのキャッシュ表で更新がコミットされたとき、キャッシュ・グリッドでグリッド・メンバー全体のキャッシュ・インスタンスの一貫性を管理するには、異なるTimesTenデータベース内の別々のキャッシュ・グループにキャッシュされる表をグローバル・キャッシュ・グループにキャッシュする必要があります。

グローバル・キャッシュ・グループとして定義できるのは、動的AWTキャッシュ・グループのみです。

例4-19に定義された動的AWTグローバル・キャッシュ・グループにキャッシュされるOracle表の定義は、次のとおりです。このOracle表はスキーマ・ユーザー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ユーザーに、この表に対するSELECT権限が付与されている必要があります。 TimesTenキャッシュ表からキャッシュされたOracle表に非同期ライトスルー処理が実行されるようにするには、Oracleキャッシュ管理ユーザーにoratt.subscriber表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

動的AWTグローバル・キャッシュ・グループを作成するには、CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP文を使用します。

例4-19 動的AWTグローバル・キャッシュ・グループ

次の文では、oratt.subscriber表をキャッシュする動的AWTグローバル・キャッシュ・グループsubscriber_accountsが作成されます。

CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH GLOBAL 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)

プリペイド電話アカウントのサブスクライバが電話をかけると、その人のアカウント残高を含むキャッシュ・インスタンスが、キャッシュ・グリッド・メンバーのいずれかにあるsubscriber_accountsグローバル・キャッシュ・グループのoratt.subscriberキャッシュ表にロードされます。 キャッシュ・インスタンスのロード先となるグリッド・メンバーは、そのキャッシュ・インスタンスの所有者となります。 所有者が残り時間および最後の通話の長さを更新して、コミットされた更新がキャッシュされたOracle表に伝播されるまで、他のグリッド・メンバーはキャッシュ・インスタンスにアクセスできません。

グリッド・メンバー間の一貫性を確保するため、TimesTenデータベースのグローバル・キャッシュ・グループにキャッシュされるOracle表は、同じキャッシュ・グリッド内にある別のTimesTenデータベースのローカル・キャッシュ・グループにキャッシュしないでください。 また、異なるキャッシュ・グリッド内にある別のTimesTenデータベースのグローバル・キャッシュ・グループに、Oracle表をキャッシュしないでください。

動的AWTグローバル・キャッシュ・グループのキャッシュ表の場合、1つのグリッド・メンバーが一度に読取りまたは更新ができるのは特定のキャッシュ・インスタンスのみです。これを、キャッシュ・インスタンスの所有者と呼びます。 この所有者に、キャッシュ・インスタンスの行に対する保留中のトランザクションがなくなると、別のグリッド・メンバーがそのインスタンスを読み取るか更新して所有権を得ます。 所有者は、次の結果によってグリッド・メンバーからこのインスタンスが削除されると、キャッシュ・インスタンスの所有権を放棄します。

• エージング

• キャッシュ表に対して発行されたDELETE文

• キャッシュ・グループに対して発行されたUNLOAD CACHE GROUP文

• そのインスタンスの所有権を得るための別のグリッド・メンバーからのリクエスト

このグリッド・メンバーがキャッシュ・グリッドからデタッチされた場合、所有者はすべてのキャッシュ・インスタンスの所有権を放棄します。

キャッシュ・インスタンスが読み取られるノードでSERIALIZABLE分離レベルを使用する場合は、キャッシュ・グリッドのノード間における読取りデータ一貫性のみが保証されます。 デフォルトのREAD COMMITTED分離レベルを使用する場合、キャッシュ・インスタンスを読み取るグリッド・ノードに対する接続では、同じノードまたは異なるノードの別の接続によって、データ値が後で新しい値に更新されていることがあります。

動的AWTグローバル・キャッシュ・グループ内のキャッシュ表は、次のいずれかの処理を使用して移入できます。

• 動的ロード処理

• キャッシュ表に対するINSERT文（INSERT INTO .. SELECT FROM文を除く）

• LOAD CACHE GROUP .. COMMIT EVERY n ROWS文（他のすべてのグリッド・メンバーが、ロードされるキャッシュ・インスタンスのいずれも所有していない場合にのみ使用可能）

動的ロード処理の詳細は、「キャッシュ・グループの動的ロード」を参照してください。

グリッド・メンバーは、次のいずれかの処理を使用して、現在別のグリッド・メンバーに所有されているキャッシュ・インスタンスの所有権を得ることができます。

• 動的ロード処理

• LOAD CACHE GROUP .. WITH ID文

グローバル・キャッシュ・グループに対してREFRESH CACHE GROUP文を発行できるのは、WITH ID句が含まれている場合のみです。

CacheGridMsgWait DSN属性は、キャッシュ・インスタンスの所有権を獲得する動的ロード処理を実行するグリッド・メンバーが、所有者がインスタンスを放棄するのを待機する最大秒数に設定できます。 いずれかの行に対して保留中のトランザクションがあるキャッシュ・インスタンスの場合、所有者はそのキャッシュ・インスタンスの所有権を放棄できません。 デフォルトの最大待機時間は60秒です。

挿入された行の一意のキー値が、キャッシュされたOracle表内にすでに存在する場合、動的AWTグローバル・キャッシュ・グループ内のキャッシュ表に対して発行されたINSERT文は失敗します。

LOAD CACHE GROUP .. COMMIT EVERY n ROWS文を使用する場合は、トランザクション内でロードされるキャッシュ・インスタンスのいずれかが別のグリッド・メンバーに所有されていると、エラーが返されます。 この場合、トランザクションはロールバックされ、失敗したトランザクション内でキャッシュ・インスタンスはロードされません。

TimesTenキャッシュ表とキャッシュされたOracle表で同じ行を同時に更新することによる競合が発生しないようにするには、キャッシュ表のみを更新します。 キャッシュされたOracle表は直接更新しないでください。

キャッシュ・グリッドのメンバーであるTimesTenデータベースには、ローカルおよびグローバルのキャッシュ・グループを含めることができます。 グリッド・メンバー間で一貫性が保証されるのは、グローバル・キャッシュ・グループ内のキャッシュ表のみです。

レプリケーション・エージェントの起動

動的AWTグローバル・キャッシュ・グループを作成した後、レプリケーション・エージェントがまだ実行されていない場合は、キャッシュ・マネージャ・ユーザーとしてTimesTenデータベースでレプリケーション・エージェントを起動します。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttRepStart;
Command> exit

キャッシュ・グリッドへのTimesTenデータベースのアタッチ

グローバル・キャッシュ・グループのキャッシュ表を更新するには、すべてのスタンドアロンTimesTenデータベースと、グローバル・キャッシュ・グループを含む、アクティブ・スタンバイ・ペアのアクティブ・マスター・データベースおよびスタンバイ・マスター・データベースが、関連付けられているキャッシュ・グリッドにアタッチされている必要があります。 データベースをグリッドにアタッチすると、データベースをグリッド・メンバーにすることができます。その結果、グリッド内のデータベース間で、グローバル・キャッシュ・グループのキャッシュ表内にあるキャッシュ・インスタンスの一貫性を保持できます。

例4-20 キャッシュ・グリッドへのTimesTenデータベースのアタッチ

最初のスタンドアロン・データベースを、関連付けられているttGridキャッシュ・グリッドにアタッチするには、キャッシュ・マネージャ・ユーザーとしてttGridAttach組込みプロシージャをコールします。スタンドアロンのTimesTenデータベースのノード番号は1です。

次の例で、alone1はグリッド・メンバーを一意に識別するために使用する名前を、sys1は最初のスタンドアロン・データベースが存在するTimesTenシステムのホスト名を、5001は最初のスタンドアロン・データベースのキャッシュ・エージェント・プロセスのTCP/IPポートを示しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttGridAttach(1,'alone1','sys1',5001);
Command> exit

グリッドにアタッチされる各TimesTenデータベースのキャッシュ・エージェントに、一意のポートを指定します。 ttGridAttach組込みプロシージャをコールすると、TimesTenデータベースでキャッシュ・エージェントがまだ起動されていない場合に、エージェントが自動的に起動されます。

キャッシュ・エージェント・プロセスが停止される前にグリッド・メンバーがグリッドからデタッチされていない場合、キャッシュ・エージェント起動ポリシーがmanualまたはalwaysであれば、キャッシュ・エージェントが自動または手動で再起動されたときにメンバーが自動的にグリッドに再アタッチされます。

キャッシュ・グリッドの詳細は、「キャッシュ・グリッドの構成」を参照してください。