ヘッダーをスキップ

Oracle TimesTen In-Memory Databaseアーキテクチャ概要 リリース6.0 B25763-01 |
| 目次 | 索引

前へ | 次へ |

## キャッシュ・グループのロードと更新

Oracleのデータは、最初にTimesTenにロードされキャッシュ・グループに移入されます。キャッシュ・グループへのロードが終了したら、そのキャッシュ・データは、TimesTenキャッシュ・グループとOracleデータベースのいずれでも更新できます。Cache Connectでは、キャッシュ・グループからOracleへの更新の伝播とOracleからキャッシュ・グループへのリフレッシュを、いずれも自動的に実行できます。

図9.2 データのロードおよび更新の伝播/リフレッシュ

## OracleからTimesTenへの更新（リフレッシュ）

次のメカニズムを使用して、TimesTenキャッシュ・グループを、Orable実表の最新状態と同じ状態に維持できます。

- 完全自動リフレッシュ: CREATE CACHE GROUP文のAUTOREFRESH MODE FULL句で指定します（この文では、リフレッシュの頻度を示すINTERVAL値もオプションで指定できます）。自動リフレッシュを有効にすると、TimesTenは、指定された時間間隔でキャッシュ・グループ全体またはキャッシュ・インスタンスを自動的にリフレッシュします。
- 増分自動リフレッシュ: CREATE CACHE GROUP文のAUTOREFRESH MODE INCREMENTAL句で指定します。全自動リフレッシュとは異なり、増分自動リフレッシュでは、前回のリフレッシュ以降にOracleで変更されたレコードのみが更新されます。INTERVALを指定すると、全自動リフレッシュの場合と同様に、増分リフレッシュが自動的に実行される頻度を指示できます。（READONLYキャッシュ・グループでは、増分自動リフレッシュがデフォルトの動作です。詳細は、「システム管理キャッシュ・グループ」を参照してください。）
- 手動リフレッシュ: アプリケーションで、REFRESH CACHE GROUP文を明示的に発行して、キャッシュ・グループ全体または特定のキャッシュ・インスタンスをリフレッシュするアプリケーションで指定します。これはUNLOAD CACHE GROUP処理の後に、LOAD CACHE GROUP処理を続けた場合と同じです。

各リフレッシュ・メカニズムにはメリットとデメリットがあります。増分自動リフレッシュでは変更のあった行のみがリフレッシュされますが、更新を常時監視するにはOracleでのトリガーの使用が必要です。このため、オーバーヘッドが増え、更新が遅くなります。完全自動リフレッシュでは、Oracleで更新を常時監視する必要はありませんが、キャッシュ内であらゆるものが一度に更新されます。手動リフレッシュは、アプリケーションで制御されるリフレッシュで、リフレッシュを実行するタイミングを決定するために必要なロジックによって、アプリケーションのオーバーヘッドが増えます。

様々な状況で、この3種類のリフレッシュ・メカニズムは有効です。たとえば、Oracle表の更新が1日に1度のみ行われ、更新される行数が多い場合は、完全自動リフレッシュが最適です。Oracle表の更新頻度は高いものの、それぞれの更新で変更される行数が少ない場合は、増分自動リフレッシュが最適です。また、リフレッシュを実行する必要のあるタイミングがアプリケーションのロジックで既知の場合は、手動リフレッシュが最適です。

## TimesTenからOracleへの更新（伝播）

TimesTenキャッシュ・グループで更新されるデータについては、次のメカニズムを使用することで、Oracleデータベースの状態を最新のキャッシュ・グループと同じ状態に維持できます。

- 伝播: 次のいずれかの方法で指定できます。

- CREATE USERMANAGED CACHE GROUP文でPROPAGATEオプションを指定します。
- CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用して、同期のWRITETHROUGH（SWT）キャッシュ・グループを作成します。
- CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用して、非同期のWRITETHROUGH（AWT）キャッシュ・グループを作成します。

PROPAGATEオプションを有効にすると、キャッシュ・グループに対するすべての変更が自動的にOracleデータベースに伝播されます。PROPAGATEオプションが有効になっている1つ以上のキャッシュ・グループ、またはSWTキャッシュ・グループの1つ以上のキャッシュ・グループを変更したトランザクションをアプリケーションで終了した場合、TimesTenはまずOracleでトランザクションをコミットし、次にTimesTenでコミットします。この方法では、Oracleが常に最新のデータのイメージを反映できるように、データがTimesTenでコミットされる前に、Oracleはデータに関係する必要なロジックを適用できます。PROPAGATEオプションまたはSWTキャッシュ・グループは、キャッシュとOracleを常に同期する必要がある場合に使用します。

AWTキャッシュ・グループへの変更は、Oracleへの適用を待機せずにコミットされます。AWTキャッシュ・グループは、レスポンス時間が短くパフォーマンスも良好ですが、変更は非同期でOracleに適用されるため、キャッシュとOracleのデータは必ずしも同一ではありません。

- フラッシュ: アプリケーションでFLUSH CACHE GROUP文を明示的に発行して指定します。フラッシュ処理を使用すると、更新をTimesTenのキャッシュ・グループからOracleに手動で伝播できます。フラッシュ処理は、特定の時間内に複数のレコードに対する更新が頻繁に行われる場合に有効です。各トランザクションの更新を個々に伝播するのではなく、フラッシュ処理によって更新がすべて一度に処理されます。フラッシュ処理を実行するには、CREATE CACHE GROUP文のPROPAGATEオプションが無効（NOT PROPAGATE）になっている必要があります。フラッシュ処理では、削除は伝播されません。

## パススルー機能

TimesTenアプリケーションでは、TimesTenへの単一接続を介して、TimesTenキャッシュ・グループまたはOracleデータベースのいずれかにSQL文を送信できます。このような単一接続は、図9.3に示すパススルー機能で、SQL文はTimesTenのキャッシュ表でローカルに処理できるのか、またはOracleに転送する必要があるのかをチェックすることによって使用可能になります。パススルー機能の設定では、パススルーの対象とする文の種類とそれを実行する状況が指定されます。

図9.3 TimesTenパススルー機能

パススルー機能の具体的な動作は、データ・ストア属性PassThroughで制御されます。この動作は、PassThroughフラグを指定してttOptSetFlagプロシージャをコールすることで、プログラムで再設定できます。