ヘッダーをスキップ
Oracle® In-Memory Database Cacheユーザーズ・ガイド
11gリリース2 (11.2.2)
B66442-05
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

7 キャッシュ環境の管理

次の各項では、キャッシュ・グリッド、キャッシュ・グループ、キャッシュ・エージェント・プロセスなどのキャッシュ・システムの様々な情報を管理して監視する方法について説明します。

キャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

ttAdminユーティリティまたはttStatusユーティリティを使用すると、TimesTenキャッシュ・エージェント・プロセスおよびレプリケーション・エージェント・プロセスが実行されているかどうかをチェックできる以外に、各エージェントの起動ポリシーを確認できます。

例7-1 ttAdminによるキャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

ttAdmin -queryユーティリティ・コマンドを使用すると、キャッシュ・エージェントおよびレプリケーション・エージェントが実行されているかどうか、およびTimesTenデータベース用のキャッシュ・エージェントとレプリケーション・エージェントの起動ポリシーを確認できます。

% ttAdmin -query cachealone1
RAM Residence Policy            : inUse
Replication Agent Policy        : manual
Replication Manually Started    : True
Cache Agent Policy              : always
Cache Agent Manually Started    : True

ttAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

例7-2 ttStatusによるキャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

ttStatusユーティリティを使用すると、キャッシュ・エージェントおよびレプリケーション・エージェントが実行されているかどうか、およびインストール済インスタンスにおける、すべてのTimesTenデータベース用のキャッシュ・エージェントとレプリケーション・エージェントの起動ポリシーを確認できます。

% ttStatus
TimesTen status report as of Thu May  7 13:42:01 2009

Daemon pid 9818 port 4173 instance myinst
TimesTen server pid 9826 started on port 4175
------------------------------------------------------------------------
Data store /users/OracleCache/alone1
There are 38 connections to the data store
Shared Memory KEY 0x02011c82 ID 895844354
PL/SQL Memory KEY 0x03011c82 ID 895877123 Address 0x10000000
Type            PID     Context     Connection Name              ConnID
Cache Agent     1019    0x0828f840  Handler                           2
Cache Agent     1019    0x083a3d40  Timer                             3
Cache Agent     1019    0x0842d820  Aging                             4
Cache Agent     1019    0x08664fd8  Garbage Collector(-1580741728)    5
Cache Agent     1019    0x084d6ef8  Marker(-1580213344)               6
Cache Agent     1019    0xa5bb8058  DeadDsMonitor(-1579684960)        7
Cache Agent     1019    0x088b49a0  CacheGridEnv                     14
Cache Agent     1019    0x0896b9d0  CacheGridSend                    15
Cache Agent     1019    0x089fb020  CacheGridSend                    16
Cache Agent     1019    0x08a619f8  CacheGridSend                    17
Cache Agent     1019    0x08ace538  CacheGridRec                     18
Cache Agent     1019    0x08b42e88  CacheGridRec                     19
Cache Agent     1019    0x08bb77d8  CacheGridRec                     20
Cache Agent     1019    0x08c2c128  CacheGridRec                     21
Cache Agent     1019    0x08ca0a78  CacheGridRec                     22
Cache Agent     1019    0x08d153c8  CacheGridRec                     23
Cache Agent     1019    0x08d89d18  CacheGridRec                     24
Cache Agent     1019    0x08dfe668  CacheGridRec                     25
Cache Agent     1019    0x08e72fb8  CacheGridRec                     26
Cache Agent     1019    0x08ee8020  CacheGridRec                     27
Cache Agent     1019    0x08f5d088  CacheGridRec                     28
Cache Agent     1019    0x08fd23f8  CacheGridRec                     29
Cache Agent     1019    0x09047768  CacheGridRec                     30
Replication     18051   0x08c3d900  RECEIVER                          8
Replication     18051   0x08b53298  REPHOLD                           9
Replication     18051   0x08af8138  REPLISTENER                      10
Replication     18051   0x08a82f20  LOGFORCE                         11
Replication     18051   0x08bce660  TRANSMITTER                      12
Subdaemon       9822    0x080a2180  Manager                        2032
Subdaemon       9822    0x080ff260  Rollback                       2033
Subdaemon       9822    0x08548c38  Flusher                        2034
Subdaemon       9822    0x085e3b00  Monitor                        2035
Subdaemon       9822    0x0828fc10  Deadlock Detector              2036
Subdaemon       9822    0x082ead70  Checkpoint                     2037
Subdaemon       9822    0x08345ed0  Aging                          2038
Subdaemon       9822    0x083a1030  Log Marker                     2039
Subdaemon       9822    0x083fc190  AsyncMV                        2040
Subdaemon       9822    0x084572f0  HistGC                         2041
Replication policy  : Manual
Replication agent is running.
Cache Agent policy  : Always
TimesTen's Cache agent is running for this data store
PL/SQL enabled.
------------------------------------------------------------------------

ttStatusユーティリティによって表示される情報は次のとおりです(いずれも、インストール済インスタンスのTimesTenデータベースごとに用意されるIMDB Cacheに関する情報です)。

  • TimesTenデータベースに接続されているキャッシュ・エージェント・プロセス・スレッドの名前

  • TimesTenデータベースに接続されているレプリケーション・エージェント・プロセス・スレッドの名前

  • キャッシュ・エージェントが実行されているかどうかに関するステータス

  • レプリケーション・エージェントが実行されているかどうかに関するステータス

  • キャッシュ・エージェント起動ポリシー

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

ttStatusユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatusに関する説明を参照してください。

キャッシュ・エージェントおよびレプリケーションの接続

キャッシュ・エージェントからOracle Databaseへの接続が失敗すると、キャッシュ・エージェントが10秒ごとに接続を試行します。キャッシュ・エージェントがOracle Databaseに接続できない場合は、10分後にキャッシュ・エージェントが再起動します。この動作は永久に繰り返されます。

レプリケーション・エージェントからOracle Databaseへの接続が失敗すると、レプリケーション・エージェントが120秒後にOracle Databaseへの再接続を試行します。120秒後に再接続できない場合、レプリケーション・エージェントは停止し、再起動しません。

Oracle DatabaseでFast Application Notification(FAN)が有効化されている場合、キャッシュ・エージェントおよびレプリケーション・エージェントは、接続が失敗したことを知らせる通知を即座に受け取ります。FANが有効化されていない場合、これらのエージェントは、接続の失敗に気付かずに、TCPタイムアウト発生まで待機してしまう可能性があります。

Oracle DatabaseでFANおよびTransparent Application Failover (TAF)とともにOracle Real Application Clusters (Oracle RAC)が有効化されている場合は、TAFによって新規Oracle Databaseインスタンスへの接続が管理されます。第11章「Oracle RAC環境でのOracle In-Memory Database Cacheの使用」を参照してください。

キャッシュ・グループおよびキャッシュ・グリッドの監視

次の項では、キャッシュ・グリッドおよびキャッシュ・グループに関する情報を取得する方法およびキャッシュ・グループ処理のステータスを監視する方法について説明します。

ttIsqlユーティリティのcachegroupsコマンドの使用

TimesTenデータベースのキャッシュ・グループに関する情報を取得するには、ttIsqlユーティリティのcachegroupsコマンドを使用します。

例7-3 ttIsqlユーティリティのcachegroupsコマンド

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

Cache Group CACHEUSER.RECENT_SHIPPED_ORDERS:

  Cache Group Type: Read Only
  Autorefresh: Yes
  Autorefresh Mode: Incremental
  Autorefresh State: On
  Autorefresh Interval: 1440 Minutes
  Autorefresh Status: ok
  Aging: Timestamp based uses column WHEN_SHIPPED lifetime 30 days cycle 24 hours on

  Root Table: ORATT.ORDERS
  Table Type: Read Only


Cache Group CACHEUSER.SUBSCRIBER_ACCOUNTS:

  Cache Group Type: Asynchronous Writethrough global (Dynamic)
  Autorefresh: No
  Aging: LRU on

  Root Table: ORATT.SUBSCRIBER
  Table Type: Propagate

Cache Group CACHEUSER.WESTERN_CUSTOMERS:

  Cache Group Type: User Managed
  Autorefresh: No
  Aging: No aging defined

  Root Table: ORATT.ACTIVE_CUSTOMER
  Where Clause: (oratt.active_customer.region = 'West')
  Table Type: Propagate

  Child Table: ORATT.ORDERTAB
  Table Type: Propagate

  Child Table: ORATT.ORDERDETAILS
  Where Clause: (oratt.orderdetails.quantity >= 5)
  Table Type: Not Propagate

  Child Table: ORATT.CUST_INTERESTS
  Table Type: Read Only

3 cache groups found.

ttIsqlユーティリティのcachegroupsコマンドによって表示される情報は、次のとおりです。

  • キャッシュ・グループが動的であるかグローバルであるかを含むキャッシュ・グループ・タイプ

  • 自動リフレッシュ属性(モード、状態、間隔)およびステータス(適用可能な場合)

  • エージング・ポリシー(適用可能な場合)

  • ルート表の名前および(適用可能な場合は)子表の名前

  • キャッシュ表のWHERE句(適用可能な場合)

  • キャッシュ表属性(読取り専用、伝播、伝播なし)

ttIsqlユーティリティのcachegroupsコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttIsqlに関する説明を参照してください。

キャッシュ・グループでの自動リフレッシュ処理の監視

キャッシュ・グループの自動リフレッシュ処理に関する情報および統計を取得するために、TimesTenではいくつかのメカニズムを用意しています。Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドの自動リフレッシュ・キャッシュ・グループの監視に関する説明を参照してください。

AWTキャッシュ・グループの監視

AWTキャッシュ・グループの処理に関する情報および統計を取得するために、TimesTenではいくつかのメカニズムを用意しています。Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドのAWTパフォーマンスの監視に関する説明を参照してください。

AWTキャッシュ・グループのトランザクション・ログ・ファイルのしきい値の設定

レプリケーション・エージェントは、トランザクション・ログを使用して、AWTキャッシュ・グループのキャッシュ表に対するどの更新がキャッシュされたOracle Database表に伝播され、どの更新が伝播されていないかを判別します。障害が原因で更新がOracle Databaseに自動的に伝播されていない場合は、トランザクション・ログ・ファイルがディスクに蓄積されます。伝播を妨げる障害の例としては、レプリケーション・エージェントが実行されていない場合、Oracle Databaseサーバーが使用不可能である場合などがあります。トランザクション・ログ・ファイルの蓄積の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの蓄積の監視に関する説明を参照してください。

蓄積可能なトランザクション・ログ・ファイルの数のしきい値を設定し、その値を超えた場合にAWTキャッシュ・グループのキャッシュ表に対する更新の追跡を停止するには、キャッシュ管理ユーザーとしてttCacheAWTThresholdSet組込みプロシージャをコールします。デフォルトのしきい値は0です。この組込みプロシージャをコールできるのは、TimesTenデータベースにAWTキャッシュ・グループが含まれている場合のみです。

このしきい値を超えた後は、UNLOAD CACHE GROUP文の後にLOAD CACHE GROUP文を続けて使用することによって、キャッシュ表を、キャッシュされたOracle Database表と手動で同期化する必要があります。トランザクション・ログ・ファイルに、キャッシュされたOracle Database表に伝播されなかった更新が含まれている場合も、TimesTenによってそのファイルが消去されることがあります。

例7-4 AWTキャッシュ・グループのトランザクション・ログ・ファイルのしきい値の設定

この例では、AWTキャッシュ・グループのキャッシュ表に対する更新を含むトランザクション・ログ・ファイルの数が5を超えると、更新の追跡が停止され、伝播されない更新が含まれている可能性のあるトランザクション・ログ・ファイルが消去されることがあります。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheAWTThresholdSet(5);

現在のトランザクション・ログ・ファイルのしきい値設定を確認するには、ttCacheAWTThresholdGet組込みプロシージャをコールします。

Command> CALL ttCacheAWTThresholdGet;
< 5 >
Command> exit

キャッシュ・グリッド情報の取得

次のメカニズムを使用して、任意のキャッシュ・グリッドおよびそのグリッド・メンバーに関する情報を表示できます。

  • 指定のキャッシュ・グリッドまたはすべての既存のキャッシュ・グリッドについて、グリッド名、キャッシュ管理ユーザー名、オペレーティング・システム・プラットフォームおよびTimesTenメジャー・リリース番号を戻すには、キャッシュ・マネージャ・ユーザーとしてttGridInfo組込みプロシージャをコールします。

    % ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
    Command> CALL ttGridInfo('ttGrid');
    < TTGRID, CACHEUSER, Linux Intel x86, 32-bit, 11, 2, 1 >
    

    ttGridInfo組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttGridInfoに関する説明を参照してください。

  • 指定のキャッシュ・グリッドまたはすべての既存のキャッシュ・グリッドのすべてのメンバーについて、グリッド名、メンバーID、ノード番号、ノードがグリッドにアタッチされているかどうかの表示、ホスト名、ノード名、IPアドレスおよびキャッシュ・エージェントTCP/IPポート番号を戻すには、キャッシュ・マネージャ・ユーザーとしてttGridNodeStatus組込みプロシージャをコールします。

    % ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
    Command> CALL ttGridNodeStatus;
    < TTGRID, 1, 1, T, sys1, TTGRID_alone1_1, 140.87.0.201, 5001, <NULL>, <NULL>,
    <NULL>, <NULL>, <NULL> >
    < TTGRID, 2, 1, T, sys2, TTGRID_alone2_2, 140.87.0.202, 5002, <NULL>, <NULL>,
    <NULL>, <NULL>, <NULL> >
    < TTGRID, 3, 1, T, sys3, TTGRID_cacheact_3A, 140.87.0.203, 5003, T, sys4,
    TTGRID_cachestand_3B, 140.87.0.204, 5004 >
    

    ttGridNodeStatus組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttGridNodeStatusに関する説明を参照してください。

グローバルAWTキャッシュ・グループの処理の一時停止

グローバルAWTキャッシュ・グループの次の処理を一時的にブロックするには、ttGridGlobalCGSuspend組込みプロシージャを使用します。

  • 動的ロード

  • キャッシュ・インスタンスの削除

これらの処理を再度有効化するには、ttGridGlobalCGResume組込みプロシージャを使用します。

キャッシュされたOracle Database表に対して発行されたDDL文の追跡

キャッシュされたOracle Database表にDDL文が発行された場合、Oracle Database表に行を挿入するためにOracle Database TT_version_schema-ID_DDL_Tトリガー(versionはTimesTenの内部バージョン番号、schema-IDはキャッシュされたOracle Database表を所有するユーザーのID)が起動されたとき、そのDDL文をOracle Database TT_version_DDL_L表で追跡できます。トリガーは、キャッシュされたOracle Database表を所有するOracle Databaseユーザーごとに作成されます。DDL追跡表が1つ作成され、キャッシュされたすべてのOracle Database表に対して発行されたDDL文が格納されます。キャッシュ管理ユーザーは、TT_version_DDL_L表およびTT_version_schema-ID_DDL_Tトリガーを所有します。

キャッシュされたOracle Database表に対して発行されたDDL文を追跡できるようにするには、キャッシュ・マネージャ・ユーザーとしてttCacheDDLTrackingConfig組込みプロシージャをコールします。デフォルトでは、DDL文は追跡されません。

ttCacheDDLTrackingConfig組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheDDLTrackingConfigに関する説明を参照してください。

例7-5 キャッシュされたOracle Database表に対して発行されたDDL文の追跡の有効化

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheDDLTrackingConfig('enable');

キャッシュ管理ユーザーにRESOURCECREATE ANY TRIGGERなどの必要な権限のセットが付与されている場合は、TT_version_DDL_L表およびTT_version_schema-ID_DDL_Tトリガーが自動的に作成されます。DDL文の追跡が有効化されている場合、キャッシュ・グループを作成したとき、これらのOracle Databaseオブジェクトが作成されます。

Oracle Databaseデータのキャッシュを管理するために使用するOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティのcachesqlgetコマンドにORACLE_DDL_TRACKINGオプションおよびINSTALLフラグを指定して実行する必要があります。このコマンドは、DDL文を追跡する対象のキャッシュされたOracle Database表を所有するOracle Databaseユーザーごとに実行する必要があります。このコマンドを実行すると、TT_version_DDL_L表およびTT_version_schema-ID_DDL_Tトリガーを作成するために使用するSQL*Plusスクリプトが生成されます。

スクリプトの生成後、SQL*Plusを使用してsysユーザーとしてスクリプトを実行します。

例7-6 Oracle Databaseオブジェクトを手動で作成した場合のDDL追跡表およびトリガーの作成

この例では、ttIsqlユーティリティのcachesqlgetコマンドによって生成されるSQL*Plusスクリプトは、/tmp/trackddl.sqlファイルに保存されます。キャッシュされたOracle Database表orattの所有者が、引数としてこのコマンドに渡されます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> cachesqlget ORACLE_DDL_TRACKING oratt INSTALL /tmp/trackddl.sql;
Command> exit

% sqlplus sys as sysdba
Enter password: password
SQL> @/tmp/trackddl
SQL> exit

Oracle Databaseスキーマに変更を加えるために、キャッシュされたOracle Database表に対してCREATEDROPALTERなどのDDL文を発行する必要がある場合は、Oracle Databaseスキーマを変更する前に、処理対象のキャッシュ・グループを削除します。削除しないと、自動リフレッシュなどの処理が失敗する場合があります。列を追加するためにOracle Database表を変更する場合は、キャッシュ・グループを削除する必要はありません。Oracle Database表で他のDDL文を発行するには、最初に次のタスクを実行します。

  1. DROP CACHE GROUP文を使用して、処理対象のOracle Database表をキャッシュするすべてのキャッシュ・グループを削除します。AWTキャッシュ・グループを削除する場合は、そのキャッシュ・グループを削除する前に、ttRepSubscriberWait組込みプロシージャを使用して、そのグループのキャッシュ表にコミットされたすべての更新をキャッシュされたOracle Database表に伝播します。

    % ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
    Command> CALL ttRepSubscriberWait('_AWTREPSCHEME','TTREP','_ORACLE','sys1',-1);
    
  2. キャッシュ・エージェントを停止します。

  3. Oracle Databaseスキーマに必要な変更を加えます。

  4. CREATE CACHE GROUP文を使用してキャッシュ・グループを再作成します(可能な場合)。

自動リフレッシュ・キャッシュ・グループにキャッシュされるOracle Database表を切り捨てる場合は、次のタスクを実行します。

  1. ALTER CACHE GROUP文を使用して、キャッシュ・グループの自動リフレッシュ状態をPAUSEDに設定します。

  2. Oracle Database表を切り捨てます。

  3. WHERE句またはWITH ID句を指定せずにREFRESH CACHE GROUP文を使用して、キャッシュ・グループを手動でリフレッシュします。

キャッシュ・グループをリフレッシュすると、自動リフレッシュ処理が再開されます。

キャッシュ管理ユーザーとしてSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/cacheInfo.sqlを実行し、キャッシュされたOracle Database表で発行されたDDL文を追跡するのに使用するOracle Databaseオブジェクトに関する情報を表示します。

% cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheInfo
*************DDL Tracking Object Information  ***************
Common DDL Log Table Name: TT_05_DDL_L
DDL Trigger Name: TT_05_315_DDL_T
Schema for which DDL Trigger is tracking: ORATT
Number of cache groups using the DDL Trigger: 10
****************************

キャッシュされたOracle Database表を所有するOracle Databaseユーザーごとに戻される情報には、DDL追跡表の名前、その対応するDDLトリガーの名前、DDLトリガーが関連付けられているユーザーの名前、DDLトリガーに関連付けられているユーザーが所有する表をキャッシュするキャッシュ・グループの数などがあります。

特定の表が複数のグリッド・メンバーにキャッシュされる場合、各グリッド・メンバーがキャッシュ・グループの数にカウントされます。アクティブ・スタンバイ・ペアは、1つのグリッド・メンバーとしてカウントされます。1つのキャッシュ・グループに複数のキャッシュ表が含まれている場合、DDLトリガーに関連付けられているユーザーが所有する各キャッシュ表がキャッシュ・グループの数にカウントされます。

Oracle Databaseオブジェクトによるキャッシュ環境の管理

自動リフレッシュ・キャッシュ・グループの場合、TimesTenはキャッシュ・グループの各キャッシュ表についてOracle Database内に変更ログ表とトリガーを作成します。トリガーは、キャッシュされたOracle Database表で挿入、更新または削除処理がコミットされるたびに起動されます。そのトリガーは、更新行の主キーを変更ログ表に記録します。キャッシュ・エージェントは、定期的に変更ログ表で更新キーをスキャンし、変更ログ表をキャッシュされたOracle Database表と結合して最新の更新のスナップショットを取得します。


注意:

2つ以上のTimesTenデータベースで同じOracle表をキャッシュしている場合のパフォーマンス考慮事項については、「2つ以上のTimesTenデータベースにおける同じOracle表のキャッシュ」を参照してください。

「データのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成」の説明に従って、AUTOREFRESH MODE INCREMENTALキャッシュ・グループ属性でキャッシュ・グループを作成するときは、自動リフレッシュ・ライトスルー処理に使用するOracle Databaseオブジェクトを、TimesTenが自動的に作成できます。また、セキュリティを確保するために、これらのオブジェクトの自動作成に必要なRESOURCEおよびCREATE ANY TRIGGER権限をキャッシュ管理ユーザーに付与しない場合は、キャッシュ・グリッド処理またはキャッシュ・グループ処理を実行する前に、これらのオブジェクトを手動で作成することもできます(「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」を参照)。

Oracle Databaseオブジェクトを自動または手動で作成するには、次の処理を実行する必要があります。

TimesTenは、キャッシュ管理ユーザーごとに次のOracle Database表を作成します(ここで、versionはTimesTenの内部バージョン番号、object-IDはキャッシュされたOracle Database表のIDです)。

表名 説明
TT_version_AGENT_STATUS 最初のキャッシュ・グループの作成時に作成されます。自動リフレッシュ・キャッシュ・グループにキャッシュされた各Oracle Database表に関する情報を保存します。
TT_version_AR_PARAMS キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュ管理ユーザーの表領域が一杯になったときに実行するアクションを保存します。
TT_version_CACHE_STATS キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。
TT_version_DATABASES キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。Oracle DatabaseからデータをキャッシュするすべてのTimesTenデータベースの自動リフレッシュ・ステータスを保存します。
TT_version_DB_PARAMS キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュ・エージェント・タイムアウト、使用不可能なキャッシュ・グループのリカバリ方法およびキャッシュ管理ユーザーの表領域使用量しきい値を保存します。
TT_version_DBSPECIFIC_PARAMS 内部使用。
TT_version_DDL_L キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュされたOracle Database表に対して発行されたDDL文を追跡します。
TT_version_DDL_TRACKING キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュされたOracle Database表に対するDDL文の追跡が有効であるか無効であるかを示すフラグを保存します。
TT_version_REPACTIVESTANDBY 最初のAWTキャッシュ・グループの作成時に作成されます。アクティブ・スタンバイ・ペアのレプリケーション・スキームでレプリケートされるAWTキャッシュ・グループのキャッシュ表を含むTimesTenデータベースの状態およびロールを追跡します。
TT_version_REPPEERS 最初のAWTキャッシュ・グループの作成時に作成されます。キャッシュされたOracle Database表に非同期に伝播されたキャッシュ表に対する最終更新の時間およびコミット順序番号を追跡します。
TT_version_SYNC_OBJS 最初のキャッシュ・グループの作成時に作成されます。
TT_version_USER_COUNT 最初のキャッシュ・グループの作成時に作成されます。各キャッシュされたOracle Database表に関する情報を保存します。
TT_version_object-ID_L 自動リフレッシュ・キャッシュ・グループを作成すると、そのキャッシュ・グループにキャッシュされるOracle Database表ごとに変更ログ表が1つ作成されます。キャッシュされたOracle Database表に対する更新を追跡します。

TimesTenは、キャッシュ管理ユーザーごとに次のOracleトリガーを作成します(ここで、versionはTimesTenの内部バージョン番号、object-IDはキャッシュされたOracle Database表のID、schema-IDはキャッシュされたOracle Database表を所有するユーザーのIDです)。

トリガー名 説明
TT_version_REPACTIVESTANDBY_T 最初のAWTキャッシュ・グループの作成時に作成されます。起動されると、TT_version_REPACTIVESTANDBY表に行を挿入します。
TT_version_object-ID_T 自動リフレッシュ・キャッシュ・グループを作成すると、そのキャッシュ・グループにキャッシュされるOracle Database表ごとにトリガーが1つ作成されます。キャッシュされたOracle Database表に対して挿入、削除または更新処理が発行されるたびに起動され、TT_version_object-ID_L変更ログ表で処理を追跡します。
TT_version_schema-ID_DDL_T キャッシュされたOracle Database表を所有するユーザーごとに1つ存在します。DDL文の追跡を有効にした後、キャッシュ・グループを作成すると作成されます。キャッシュされたOracle Database表に対してDDL文が発行されるたびに起動され、TT_version_DDL_L表で処理を追跡します。

TimesTenは、timestenユーザー用に次のOracle Database表を作成します。

表名 説明
TT_GRIDID SQL*PlusスクリプトinitCacheGlobalSchema.sqlを実行すると作成されます。最近作成したキャッシュ・グリッドに割り当てられているID番号を保存します。
TT_GRIDINFO SQL*PlusスクリプトinitCacheGlobalSchema.sqlを実行すると作成されます。すべての既存のキャッシュ・グリッドのグリッド名、グリッドIDおよびキャッシュ管理ユーザー名を保存します。

TimesTenは、キャッシュ管理ユーザーごとに次のOracle Database表を作成します(ここで、versionはTimesTenの内部バージョン番号、grid-IDはキャッシュ・グリッドのID番号です)。

表名 説明
TT_version_grid-name_grid-IDCGNODEID グリッドが作成されると、キャッシュ・グリッドごとに1つの表が作成されます。オペレーティング・システムの名前、そのバージョンおよびTimesTenリリース番号を保存します。
TT_version_grid-name_grid-IDCGNODEINFO グリッドが作成されると、キャッシュ・グリッドごとに1つの表が作成されます。すべてのアタッチ済グリッド・メンバーのホスト名、メンバー名、IPアドレスおよびキャッシュ・エージェントTCP/IPポートを保存します。
TT_version_grid-name_grid-IDCGGROUPDEFS グリッドが作成されると、キャッシュ・グリッドごとに1つの表が作成されます。キャッシュ・グリッドに関連付けられているスタンドアロンTimesTenデータベースまたはアクティブ・スタンバイ・ペアのすべてのグローバル・キャッシュ・グループのキャッシュ・グループ名、所有者、参照カウントおよびSQLテキストを保存します。

TimesTenデータベースでの自動リフレッシュ処理の失敗による影響

変更ログ表は、自動リフレッシュ・キャッシュ・グループにキャッシュされるOracle Database表ごとに、キャッシュ管理ユーザーの表領域に作成されます。これらのキャッシュされたOracle Database表に対して更新処理が発行されるたびに、対応する変更ログ表に行が1つ挿入され、これにより、次回の増分自動リフレッシュ・サイクルにおいて、TimesTenキャッシュ表に適用する必要がある更新を常時監視できるようになります。TimesTenは、キャッシュ表に適用された変更ログ表の行を定期的に削除します。

1つのOracle Database表をTimesTenデータベース内の複数のキャッシュ・グループに、キャッシュすることはできません。ただし、1つのOracle Database表を複数のTimesTenデータベースにキャッシュすることはできます。これによって、1つのOracle Database表が複数のTimesTenキャッシュ表に対応することになります。Oracle Database表がキャッシュされる1つ以上のTimesTenデータベースでキャッシュ・エージェントが実行されていないために、キャッシュされたOracle Database表に対する更新が対応するすべてのキャッシュ表に自動的にリフレッシュされない場合、それぞれの変更ログ表の行はデフォルトでは削除されません。キャッシュ・エージェントが明示的に停止されたか、または起動されていなかったため、あるいはデータベースが破棄されたか、データベースがあるインストール済インスタンスが停止しているために、キャッシュ・エージェントが特定のTimesTenデータベースで実行されない場合があります。この結果、変更ログ表に行が蓄積し、キャッシュ・エージェントが実行されているTimesTenデータベースのキャッシュ表に対する自動リフレッシュ処理のパフォーマンスが低下します。また、キャッシュ管理ユーザーの表領域が一杯になる場合もあります。

キャッシュ・エージェント・タイムアウトを設定すると、行が変更ログ表に蓄積されて削除されない状態を回避できます。TimesTenデータベースでキャッシュ・エージェントが実行されておらず、キャッシュ・エージェント・タイムアウトを設定している場合、変更ログ表の行を削除するには、次の基準が満たされている必要があります。

  • Oracle Database表は、複数のTimesTenデータベース内の自動リフレッシュ・キャッシュ・グループにキャッシュされています。

  • キャッシュ・エージェントは、TimesTenデータベースの少なくとも1つで実行されていますが、別のデータベースでは実行されていません。

  • 変更ログ表の行が、キャッシュ・エージェントが実行されているすべてのTimesTenデータベースのキャッシュ表に適用されています。

  • キャッシュ・エージェントが実行されていないデータベースで、エージェント・プロセスが停止したままとなり、その期間がキャッシュ・エージェント・タイムアウトを超えています。

Oracle Databaseからのデータをキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。AgentTimeout文字列をParamパラメータに渡し、タイムアウト設定を数値文字列としてValueパラメータに渡します。キャッシュ・エージェント・タイムアウトの設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

例7-7 キャッシュ・エージェント・タイムアウトの設定

次の例では、キャッシュ・エージェント・タイムアウトを900秒(15分)に設定しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('AgentTimeout',,,'900');

現在のキャッシュ・エージェント・タイムアウト設定を確認するには、AgentTimeout文字列のみをParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('AgentTimeout');
< AgentTimeout, <NULL>, <NULL>, 900 >

デフォルトのキャッシュ・エージェント・タイムアウトは0秒であり、変更ログ表の行はすべてのキャッシュ表に適用されるまで削除されません。キャッシュ・エージェント・タイムアウトを1から600秒のいずれかの値に設定すると、タイムアウトは600秒に設定されます。キャッシュ・エージェント・タイムアウトは、同じOracle Databaseからデータをキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースに適用されます。

適切なキャッシュ・エージェント・タイムアウト設定を決定するときは、TimesTenデータベースをメモリーにロードするために要する時間、キャッシュ・エージェント・プロセスを開始するための時間、ネットワーク停止の可能性がある期間および計画メンテナンス作業の所要見積時間を考慮してください。

各TimesTenデータベースおよびそのすべての自動リフレッシュ・キャッシュ・グループには自動リフレッシュ・ステータスがあり、変更ログ表から削除された行がキャッシュ・グループのキャッシュ表に適用されたかどうかを判別できるようになっています。変更ログ表から行が削除されたものの、データベース上のキャッシュ・エージェントがキャッシュ・エージェント・タイムアウトを超える期間停止していたために、それがキャッシュ表に適用されなかった場合、そのキャッシュ表はキャッシュされたOracle Database表と同期化されなくなります。キャッシュされたOracle Database表に対する以後の更新は、付随するキャッシュ・グループがリカバリされるまで、キャッシュ表に自動的にはリフレッシュされません。

自動リフレッシュ・キャッシュ・グループの有効なステータスは、次のとおりです。

  • ok: 変更ログ表から削除されたすべての行がキャッシュ表に適用されました。増分自動リフレッシュ処理が引き続きキャッシュ・グループに対して実行されます。

  • dead: 変更ログ表から削除された行の一部がキャッシュ表に適用されなかったため、キャッシュ表はキャッシュされたOracle Database表と同期化されません。キャッシュ・グループに対する自動リフレッシュ処理は停止し、キャッシュ・グループがリカバリするまで再開されません。

  • recovering: キャッシュ・グループはリカバリ中です。リカバリが完了すると、キャッシュ表がキャッシュされたOracle Database表と同期化され、キャッシュ・グループの自動リフレッシュ・ステータスがokに設定され、増分自動リフレッシュ処理がキャッシュ・グループで再開されます。

TimesTenデータベースの有効な自動リフレッシュ・ステータスは、次のとおりです。

  • alive: すべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがOKに設定されています。

  • dead: すべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがdeadに設定されています。

  • recovering: 自動リフレッシュ・キャッシュ・グループの少なくとも1つの自動リフレッシュ・ステータスがrecoveringに設定されています。

TimesTenデータベース上のキャッシュ・エージェントがキャッシュ・エージェント・タイムアウトを超える期間停止していると、そのTimesTenデータベースの自動リフレッシュ・ステータスはdeadに設定されます。また、そのデータベース内のすべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがdeadに設定されます。

SNMPトラップを有効にしている場合、データベースの自動リフレッシュ・ステータスがdeadに設定されると、トラップがスローされます。

キャッシュ・グループおよびその付随するTimesTenデータベースの自動リフレッシュ・ステータスを確認するには、キャッシュ・マネージャ・ユーザーとしてttCacheDbCgStatus組込みプロシージャをコールします。キャッシュ・グループの所有者をcgOwnerパラメータに、キャッシュ・グループの名前をcgNameパラメータにそれぞれ渡します。

例7-8 キャッシュ・グループおよびTimesTenデータベースの自動リフレッシュ・ステータスの確認

次の例では、データベースの自動リフレッシュ・ステータスはaliveとなっており、cacheuser.customer_orders読取り専用キャッシュ・グループの自動リフレッシュ・ステータスはokとなっています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheDbCgStatus('cacheuser','customer_orders');
< alive, ok >

データベースの自動リフレッシュ・ステータスのみを表示し、特定のキャッシュ・グループの自動リフレッシュ・ステータスは表示しないようにするには、パラメータを指定せずにttCacheDbCgStatusをコールします。

Command> CALL ttCacheDbCgStatus;
< dead, <NULL> >

キャッシュ・グループの自動リフレッシュ・ステータスがokである場合、そのキャッシュ表は自動リフレッシュ間隔に基づいて自動的にリフレッシュされます。データベースの自動リフレッシュ・ステータスがaliveである場合、そのデータベースのすべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがokとなります。

キャッシュ・グループの自動リフレッシュ・ステータスがdeadである場合、そのキャッシュ表はキャッシュされたOracle Database表に対する更新がコミットされても、自動的にはリフレッシュされません。キャッシュ表をキャッシュされたOracle Database表と再同期化するには、キャッシュ・グループをリカバリする必要があります。

自動リフレッシュ・ステータスがdeadになっているキャッシュ・グループ用にリカバリ方法を構成できます。

Oracle Databaseからのデータをキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。DeadDbRecovery文字列をParamパラメータに渡し、リカバリ方法を文字列としてValueパラメータに渡します。deadとなっているキャッシュ・グループのリカバリ方法の設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

有効なリカバリ方法は次のとおりです。

  • Normal: キャッシュ・エージェントを起動すると、自動リフレッシュ・ステータスがdeadであるキャッシュ・グループに対して完全自動リフレッシュ処理が実行され、キャッシュ・グループがリカバリされます。これがデフォルトのリカバリ方法です。

  • Manual: 自動リフレッシュ・ステータスがdeadとなっている明示的にロードされる各キャッシュ・グループをリカバリするには、キャッシュ・エージェントの起動後に、REFRESH CACHE GROUP文を発行する必要があります。

    自動リフレッシュ・ステータスがdeadとなっている各動的キャッシュ・グループをリカバリするには、キャッシュ・エージェントの起動後、REFRESH CACHE GROUP文またはUNLOAD CACHE GROUP文を発行する必要があります。

  • None: 自動リフレッシュ・ステータスがdeadとなっているキャッシュ・グループをリカバリするには、キャッシュ・エージェントの起動後、そのグループを削除してから再作成する必要があります。

例7-9 deadとなっているキャッシュ・グループのリカバリ方法の構成

次の例では、自動リフレッシュ・ステータスがdeadとなっているキャッシュ・グループのリカバリ方法をManualに設定しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('DeadDbRecovery',,,'Manual');

deadとなっているキャッシュ・グループの現在のリカバリ方法を確認するには、DeadDbRecovery文字列のみをParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('DeadDbRecovery');
< DeadDbRecovery, <NULL>, <NULL>, manual >

このリカバリ方法は、同じOracle Databaseからデータをキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースのすべての自動リフレッシュ・キャッシュ・グループに適用されます。

SNMPトラップを有効にしている場合、キャッシュ・エージェントが起動し、リカバリ方法をManualまたはNoneに設定すると、トラップがスローされ、REFRESH CACHE GROUPDROP CACHE GROUPなどの文を手動で発行して、データベース内で自動リフレッシュ・ステータスがdeadとなっているキャッシュ・グループをリカバリするよう警告されます。

キャッシュ・グループがリカバリ・プロセスを開始すると、その自動リフレッシュ・ステータスがdeadからrecoveringに変更され、付随するTimesTenデータベースのステータスが現在deadである場合にはrecoveringに変更されます。

キャッシュ・グループのリカバリが完了すると、その自動リフレッシュ・ステータスがrecoveringからokに変更されます。すべてのキャッシュ・グループがリカバリされ、それらの自動リフレッシュ・ステータスがokであると、付随するTimesTenデータベースのステータスがrecoveringからaliveに変更されます。

リフレッシュする更新が少量で、かつキャッシュ表に多数の行が存在する場合、完全自動リフレッシュ処理には増分自動リフレッシュ処理よりも多くのシステム・リソースが必要となります。メンテナンス作業のためにTimesTenデータベースを停止する必要があり、その停止中、自動リフレッシュ・キャッシュ・グループにキャッシュされるOracle Database表に対して実行される更新の量が少ないと予測される場合は、一時的にキャッシュ・エージェント・タイムアウトを0に設定してみることをお薦めします。データベースが稼働状態に戻り、キャッシュ・エージェントが再起動すると、増分自動リフレッシュ処理が自動リフレッシュ・キャッシュ・グループのキャッシュ表で再開されます。付随するキャッシュ・グループの自動リフレッシュ・ステータスがokからdeadに変更されなかったため、完全自動リフレッシュ処理が回避されますので、付随するキャッシュ・グループのリカバリ・プロセスは必要ありません。データベースが稼働状態に戻り、キャッシュ・エージェントが起動された後、キャッシュ・エージェント・タイムアウトを元の値に戻します。

自動リフレッシュ・キャッシュ・グループで使用されているOracle Databaseオブジェクトの削除

自動リフレッシュ・キャッシュ・グループを含むTimesTenデータベースが使用できなくなっても、自動リフレッシュ処理の実装に使用される変更ログ表やトリガーなどのOracle Databaseオブジェクトは引き続きOracle Databaseに存在します。TimesTenデータベースは、たとえば、TimesTenシステムがオフラインになったり、自動リフレッシュ・キャッシュ・グループを削除せずにデータベースを破棄すると使用不可能になります。

TimesTenデータベースが使用されなくなっても、自動リフレッシュ・キャッシュ・グループを含んでいる場合は、自動リフレッシュ処理の実装に使用されるOracle DatabaseオブジェクトもOracle Databaseに引き続き存在します。行が引き続き変更ログ表に蓄積されます。これは、他のTimesTenデータベースに対する自動リフレッシュのパフォーマンスに影響を与えます。このため、使用不可能になったり破棄されたTimesTenデータベースに関連付けられているこれらのOracle Databaseオブジェクトを削除することをお薦めします。

自動リフレッシュ処理の実装に使用されるOracle Databaseオブジェクトを削除するには、キャッシュ管理ユーザーとしてSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/cacheCleanUp.sqlを実行します。TimesTenシステムのホスト名およびTimesTenデータベースのパス名を引数としてcacheCleanUp.sqlスクリプトに渡します。TimesTenシステムのホスト名およびデータベース・パス名を確認するには、キャッシュ管理ユーザーとしてcacheInfo.sqlスクリプトを実行します。また、cacheInfo.sqlスクリプトは、自動リフレッシュ処理の実装に使用されるオブジェクトがOracle Databaseに存在するかどうかを確認する場合にも使用できます。

例7-10 自動リフレッシュ・キャッシュ・グループのOracle Databaseオブジェクトの削除

次の例では、TimesTenデータベースを削除した後も、TimesTenデータベースにキャッシュ表oratt.customerおよびoratt.ordersを含む読取り専用キャッシュ・グループcustomer_ordersが1つ存在しています。cacheCleanUp.sqlスクリプトは、この2つのキャッシュ表に関連付けられている変更ログ表およびトリガーを削除します。

% cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheCleanUp "sys1" "/users/OracleCache/alone1"

*****************************OUTPUT**************************************
Performing cleanup for object_id: 69959 which belongs to table : CUSTOMER
Executing: delete from tt_05_agent_status where host = sys1 and datastore =
/users/OracleCache/alone1 and object_id = 69959
Executing: drop table tt_05_69959_L
Executing: drop trigger tt_05_69959_T
Executing: delete from tt_05_user_count where object_id = object_id1
Performing cleanup for object_id: 69966 which belongs to table : ORDERS
Executing: delete from tt_05_agent_status where host = sys1 and datastore =
/users/OracleCache/alone1 and object_id = 69966
Executing: drop table tt_05_69966_L
Executing: drop trigger tt_05_69966_T
Executing: delete from tt_05_user_count where object_id = object_id1
**************************************************************************

キャッシュ管理ユーザーの表領域の監視

次の各項ではキャッシュ管理ユーザーの表領域を管理する方法を説明します。

表領域の変更ログ表の最適化

自動リフレッシュ・キャッシュ・グループの変更ログ表を長期間にわたって使用したり過度なワークロードを与えたりすると、表領域が断片化する場合があります。表領域が劣化して変更ログ表が断片化するのを防ぐために、TimesTenは、領域の合計サイズに対する使用済の領域の割合として、変更ログ表の断片化の比率を計算します。この割合が定義されたしきい値を下回ると、TimesTenは、メッセージをログに記録して変更ログ表の最適化が必要であることを示すアラートを通知し、SNMPトラップが有効である場合は、SNMPトラップttCacheAutorefreshLogSpaceDeFragDetectedTrapをスローします。デフォルトでは、このしきい値は40%に設定されています。ttCacheConfig組込みプロシージャにより設定する断片化しきい値を構成できます。


注意:

メッセージは、ユーザーおよびサポート・エラー・ログに記録されます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の情報メッセージの変更に関する説明を参照してください。

断片化しきい値を設定するには、Oracle DatabaseのデータをキャッシュするいずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。AutoRefreshLogFragmentationWarningPCT文字列をParamパラメータに渡し、しきい値設定を数値文字列としてValueパラメータに渡します。


注意:

断片化しきい値の設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

例7-11 断片化しきい値の設定

次の例では、断片化しきい値が50%に設定されています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('AutoRefreshLogFragmentationWarningPCT',,,'50');
< AutoRefreshLogFragmentationWarningPCT, <NULL>, <NULL>, 50 >
1 row found.

現在の断片化しきい値の設定を確認するには、AutoRefreshLogFragmentationWarningPCT文字列をParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('AutoRefreshLogFragmentationWarningPCT');
< AutoRefreshLogFragmentationWarningPCT, <NULL>, <NULL>, 50 >

最適化を自動で実行するかまたは手動で開始するかのいずれかにTimesTenを構成できます。前述の割合が断片化しきい値を下回ったときに実行するアクションを構成するには、次のようにして、AutoRefreshLogDeFragmentAction文字列をParamパラメータに渡し、該当するアクションをValueパラメータで指定してttCacheConfig組込みプロシージャをコールします。


注意:

最適化アクションの設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

  • 手動:これがデフォルトです。変更ログ表を最適化するためのアクションは実行されません。ttCacheAutoRefreshLogDeFrag組込みプロシージャを実行して、手動で最適化を行う必要があります。詳細は、「自動リフレッシュ・キャッシュ・グループ用の変更ログ表の手動による最適化」を参照してください。

  • Compact: TimesTenが変更ログ表をデフラグします。

  • CompactAndReclaim: TimesTenが変更ログ表を最適化し、領域を再生します。


    注意:

    領域を再生すると変更ログ表が短時間ロックされ、実表への書込みが一時的に停止されます。

例7-12 断片化のときに実行するアクションの構成

次の例では、アクションがCompactAndReclaimに設定されているため、断片化の割合がしきい値を下回ったときに、TimesTenは変更ログ表を最適化して領域を再生します。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('AutoRefreshLogDeFragmentAction',,,'CompactAndReclaim');
< AutoRefreshLogDeFragmentAction, <NULL>, <NULL>, compactandreclaim >
1 row found.

現在の断片化しきい値の設定を確認するには、AutoRefreshLogDeFragmentAction文字列をParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('AutoRefreshLogDeFragmentAction');
< AutoRefreshLogDeFragmentAction , <NULL>, <NULL>, compactandreclaim >

表領域の断片化の比率およびttCacheAutorefreshStatsGet組込みプロシージャから次の列が返される最適化処理が最後に実行されたタイミングを確認できます。

  • AutoRefreshLogFragmentationPCT: 表領域の現在の断片化の比率。

  • AutoRefreshLogFragmentationTS: 断片化の比率が最後に計算されたときのタイムスタンプ。

  • autorefLogDeFragCnt: この特定のキャッシュ・グループの表が最適化された回数。

詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAutorefreshStatsGetに関する説明を参照してください。

自動リフレッシュ・キャッシュ・グループ用の変更ログ表の手動による最適化

変更ログ表の最適化を手動で開始するには、Oracle DatabaseのデータをキャッシュするいずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheAutoRefreshLogDeFrag組込みプロシージャをコールします。パラメータとして次の文字列のいずれかを渡します。

  • Compact: 変更ログ表をデフラグします。

  • CompactAndReclaim: 変更ログ表を最適化して、領域を再生します。


    注意:

    領域を再生すると変更ログ表が短時間ロックされ、実表への書込みが一時的に停止されます。

例7-13 変更ログ表の手動による最適化

次の例では、ユーザーがttCacheAutoRefreshLogDeFrag組込みプロシージャにCompactAndReclaimオプションを指定してコールしています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheAutoRefreshLogDeFrag('CompactAndReclaim');

表領域使用量通知の受信

表領域が一杯になるのを防ぐため、UPDATE文、INSERT文またはDELETE文などの更新処理をキャッシュされたOracle Database表に対して発行したために、キャッシュ管理ユーザーの表領域の使用量が指定のしきい値を超えた場合に、アプリケーションに警告が返されるようにTimesTenを構成できます。

Oracle Databaseからのキャッシュ表をキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。TblSpaceThreshold文字列をParamパラメータに渡し、しきい値を数値文字列としてValueパラメータに渡します。しきい値はキャッシュ管理ユーザーの表領域に使用されている領域の比率であり、この値に達すると、キャッシュされたOracle Database表に更新処理を発行したときにアプリケーションに警告が返されます。キャッシュ管理ユーザーの表領域使用量警告しきい値の設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

キャッシュ・マネージャ・ユーザーがキャッシュ管理ユーザーの表領域使用量警告しきい値を設定し、キャッシュ管理ユーザーがその表領域を監視して構成済のしきい値を超えたかどうかを確認できるようにするには、キャッシュ管理ユーザーにOracle Database表SYS.DBA_DATA_FILESに対するSELECT権限を付与する必要があります。

例7-14 キャッシュ管理ユーザーの表領域使用量警告しきい値の設定

次の例では、キャッシュされたOracle Database表に更新処理を発行した結果、キャッシュ管理ユーザーの表領域の使用量が80%を超えた場合には、発行元のアプリケーションに警告を返すように構成しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('TblSpaceThreshold',,,'80');

キャッシュ管理ユーザーの表領域使用量警告しきい値の現在の設定を確認するには、TblSpaceThreshold文字列のみをParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('TblSpaceThreshold');
< TblspaceThreshold, <NULL>, <NULL>, 80 >

キャッシュ管理ユーザーのデフォルトの表領域使用量警告しきい値は0%であるため、表領域使用量に関係なく、アプリケーションには警告が返されません。キャッシュ管理ユーザーの表領域使用量警告しきい値は、同じOracle Databaseから表をキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースに適用されます。

SNMPトラップを有効にしている場合、キャッシュ管理ユーザーの表領域使用量が構成済のしきい値を超えると、トラップがスローされます。

一杯になった表領域のリカバリ

デフォルトでは、キャッシュ管理ユーザーの表領域が一杯になったときに、特定のキャッシュされたOracle Database表に対してUPDATE文、INSERT文またはDELETE文などのDML処理を試行すると、Oracle Databaseアプリケーションにエラーが返されます。

キャッシュ管理ユーザーの表領域が一杯になったときにTimesTenがOracle Databaseアプリケーションにエラーを返すのではなく、更新処理が特定のキャッシュされたOracle Database表に発行されたときに変更ログ表から既存の行を削除して、新規行のための領域を確保するようにTimesTenを構成できます。変更ログ表から削除した行の一部がTimesTenキャッシュ表に適用されなかった場合、次回の自動リフレッシュ・サイクルにおいて、そのキャッシュ表を含む各TimesTenデータベースのキャッシュ表に完全自動リフレッシュ処理が実行されます。

Oracle Databaseからのキャッシュ表をキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。TblSpaceFullRecovery文字列をParamパラメータに渡し、キャッシュ管理ユーザーの表領域が一杯になった場合に実行するアクションを構成するキャッシュされたOracle Database表の所有者および名前をtblOwnerパラメータおよびtblNameパラメータにそれぞれ渡し、さらに、そのアクション自体を文字列としてValueパラメータに渡します。

有効なアクションは次のとおりです。

  • None: キャッシュされたOracle Database表に更新処理が発行されたときに、アプリケーションにOracle Databaseエラーを返します。これがデフォルトのアクションです。

  • Reload: キャッシュされたOracle Database表に更新処理が発行されると、次回の自動リフレッシュ・サイクルにおいて、変更ログ表から行を削除し、キャッシュ表に対して完全自動リフレッシュ処理を実行します。

例7-15 キャッシュ管理ユーザーの表領域が一杯になった場合のアクションの構成

次の例では、キャッシュされたOracle Database表oratt.customerに更新処理が発行されたときにキャッシュ管理ユーザーの表領域が一杯である場合、次回の自動リフレッシュ・サイクルにおいて、変更ログ表から行が削除され、キャッシュ表に対して完全自動リフレッシュ処理が実行されます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('TblSpaceFullRecovery','oratt','customer','Reload');

キャッシュ管理ユーザーの表領域が一杯である場合に、特定のキャッシュされたOracle Database表に対して更新処理を発行すると実行される現在のアクションを確認するには、TblSpaceFullRecovery文字列のみをParamパラメータに、キャッシュされたOracle Database表の所有者および名前をtblOwnerパラメータおよびtblNameパラメータにそれぞれ渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('TblSpaceFullRecovery','oratt','customer');
< TblSpaceFullRecovery, ORATT, CUSTOMER, reload >

キャッシュ管理ユーザーの表領域が一杯である場合に、キャッシュされたOracle Database表に対して更新処理を発行すると実行されるアクションは、同じOracle Databaseから表をキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースに適用されます。

SNMPトラップを有効にしている場合、キャッシュされたOracle Database表に対して更新処理を発行し、キャッシュ管理ユーザーの表領域が一杯であると、トラップがスローされます。

グリッド・ノードの障害後のリカバリ

スタンドアロン・データベース・グリッド・メンバーに障害が発生した場合、キャッシュ・エージェント起動ポリシーがmanualまたはalwaysであれば、キャッシュ・エージェントは自動的に再起動されます。グリッド・メンバーは、データベースのリカバリ時に自動的にグリッドに再アタッチされます。キャッシュ・エージェント起動ポリシーがnorestartである場合は、キャッシュ・エージェントを再起動してから、ttGridAttach組込みプロシージャをコールしてメンバーをグリッドに再アタッチする必要があります。「キャッシュ・エージェント起動ポリシーの設定」を参照してください。

スタンドアロン・データベース・グリッド・メンバーがグリッドにアタッチされていることを確認するには、ttRepStateGet組込みプロシージャをコールします。アタッチされている場合は、次の出力が表示されます。

Command> CALL ttRepStateGet;
< IDLE, AVAILABLE >
1 row found.

Oracle Clusterwareによりグリッド内のノードが管理されているときに、アクティブ・スタンバイ・ペア・グリッド・メンバーのアクティブ・データベース・ノードまたはスタンバイ・データベース・ノードに障害が発生した場合は、キャッシュ・エージェントの再起動時にグリッド・ノードが自動的にグリッドに再アタッチされます。Oracle Clusterwareによる障害の処理方法の詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の障害からのリカバリに関する説明を参照してください。

アクティブ・スタンバイ・ペア・グリッド・メンバーがOracle Clusterwareによって管理されていない場合は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のアクティブ・データベースの障害からのリカバリに関する説明またはスタンバイ・データベースの障害からのリカバリに関する説明の手順を実行します。キャッシュ・エージェント起動ポリシーがmanualまたはalwaysである場合は、データベースのリカバリ後、グリッド・ノードが自動的にグリッドに再アタッチされます。キャッシュ・エージェント起動ポリシーがnorestartである場合は、ttGridAttach組込みプロシージャをコールしてメンバーをグリッドに再アタッチします。

アクティブ・データベースが使用可能で、アクティブ・スタンバイ・ペアがグリッドにアタッチされていることを確認するには、アクティブ・データベースからttRepStateGet組込みプロシージャをコールします。

Command> CALL ttRepStateGet;
< ACTIVE, AVAILABLE >
1 row found.

詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepStateGetに関する説明を参照してください。

たとえば、ハードウェアの障害またはネットワークの障害が原因で、複数ノード障害が発生する場合があります。複数ノード障害の発生後、再アタッチが必要なメンバーごとに、ttGridAttach組込みプロシージャをコールします。この組込みプロシージャを、再アタッチする最後のグリッド・メンバーに対してコールするまで、各グリッド・メンバーに対する処理は失敗します。まだアタッチされていないグリッド・メンバーに対して再度ttGridAttachをコールすれば、処理が成功します。互いの状態を認識していないグリッド・メンバーでスプリットブレイン状況が発生するのを回避するためには、この順序が必須です。

キャッシュ・グループを持つデータベースのバックアップおよびリストア

キャッシュ・グループを含むデータベースは、ttBackupユーティリティを使用してバックアップできます。ただし、このバックアップのリカバリでは、キャッシュ・グループ内のリストア済データが古くなり、バックエンドOracle Databaseのデータと同期しなくなるために、追加のアクションが必要です。

  • リカバリしたデータベースが同じバックエンドOracle Databaseに接続する場合は、リストア済TimesTenデータベース内のすべてのキャッシュ・グループを削除して再作成します。これらが静的キャッシュ・グループの場合は再ロードを要求される場合があります。動的キャッシュ・グループの場合は、再ロードはオプションとなります。これは、データは参照されるときにOracle Databaseからプルされるためです。

  • リストアされたデータベースが元々接続していたデータベースとは別のバックエンドOracle Databaseに接続する場合は、次の手順を実行します。

    1. ttCacheUidPwdSet組込みプロシージャを使用してキャッシュ管理者ユーザー名およびパスワードを指定します。

    2. キャッシュ・エージェントを起動します。

    3. すべてのキャッシュ・グループを削除します。エラーが報告される場合もありますが、これは無視しても差し支えありません。

    4. キャッシュ・エージェントを停止します。

    5. 新しいOracle Databaseに対してcacheCleanUp.sql SQL*Plusスクリプトを実行して、残っているすべてのオブジェクトを削除します。リストアしたTimesTenデータベースのホストとパスを指定します。

    6. キャッシュ・エージェントを起動します。

    7. キャッシュ・グループを再作成し、必要があれば再ロードします。


    注意:

    リストアされたTimesTenデータベースがいずれのバックエンドOracle Databaseにも接続できない場合は、キャッシュ・グループを削除したりキャッシュしたデータを削除することはできません。

元のバックエンドOracle Databaseに接続するために使用したTimesTenデータベースをもう接続せず、そのTimesTenデータベース内のすべてのキャッシュ・グループが完全に削除されなかった場合は、残っているすべてのオブジェクトを削除するために、元のOracle Databaseに対してcacheCleanUp.sql SQL*Plusスクリプトを実行します。元のTimesTenデータベースのホストとパスを指定します。