ヘッダーをスキップ
Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド
リリース11.2.1
B56056-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

4 Oracle In-Memory Database Cacheのトラブルシューティング 

この章では、Oracle In-Memory Database Cache（IMDB Cache）の使用時に発生する可能性があるいくつかの問題の解決方法について説明します。内容は次のとおりです。

AWTキャッシュ・グループで問題が発生している場合は、「AWTキャッシュ・グループのトラブルシューティング」も参照してください。

キャッシュ・グループを作成できない

この項では、CREATE CACHE GROUP文の実行時に発生する可能性があるいくつかの問題について説明します。

考えられる原因 対処
ユーザーがキャッシュ・グループの型を作成するための正しいOracle権限を持っていない 「Oracle権限を確認する」を参照してください。
データ・ストアにアクセスするための十分な権限がユーザーにない キャッシュ・グループを作成するには、CACHE_MANAGER権限が必要です。
内部/外部ユーザーがOracleユーザーと一致しない TimesTenユーザー名は、Oracleユーザー名と同じである必要があります。
Oracleに接続できない 次の項を参照してください。

ネットワーク・ステータスを確認する。
キャッシュ管理ユーザーのIDまたはパスワードが設定されていない（AWTまたは自動リフレッシュ・キャッシュ・グループを作成しようとした場合） 「キャッシュ管理ユーザーのIDおよびパスワードを設定する」を参照してください。
サポートされていないデータ型マッピング 「サポートされていないデータ型マッピング」を参照してください。
OracleでのNULL値可能設定が異なる 「NULL制約がOracleと一致しない」を参照してください。
ルート表で主キーを指定できない キャッシュ・グループのルート表には、主キーが必要です。 『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュ・グループの定義に関する説明を参照してください。

キャッシュ・エージェントを起動または停止できない

この項では、キャッシュ・エージェントの起動時または停止時に発生する可能性があるいくつかの問題について説明します。

考えられる原因 対処
キャッシュ・エージェントがすでに稼働している 「キャッシュ・エージェントのステータスを確認する」を参照してください。
Oracleライブラリが見つからない
ORACLE_HOMEが無効。 「ORACLE_HOME環境変数を確認する」を参照してください。
権限が不足している キャッシュ・エージェントを起動または停止するには、CACHE_MANAGER権限が必要です。
OracleIDが間違っている DSN定義に設定したOracleIDが、TimesTenでキャッシュする表が含まれるOracleインスタンスのOracleサービス名と一致することを確認します。

キャッシュ・エージェントのステータスを確認する

キャッシュ・エージェントのステータスは、ttStatusユーティリティ（「ttStatusユーティリティの使用」を参照）を使用して確認します。

キャッシュ・エージェントが稼働していない場合は、起動します（『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する説明を参照）。キャッシュ・エージェントを起動できない場合は、考えられる原因を調査し、マシンを再起動してから起動してください。

ORACLE_HOME環境変数を確認する

UNIXまたはLinuxプラットフォームでは、キャッシュ・エージェントおよびTimesTenデーモンを起動しているシェルにORACLE_HOME環境変数が正しく設定されていることを確認します。 ORACLE_HOMEの設定を変更する必要がある場合は、ttmodinstallユーティリティを使用します。

詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の環境変数に関する説明を参照してください。

Oracleサービス名を解決できない

サービス名が解決できなかったことを示すOCIエラーORA-12514を受け取った場合は、次の内容を確認します。

接続識別子を解決できない

データ・ストアに接続しようとすると、ORA-12154「TNS: 指定された接続識別子を解決できませんでした」が表示されることがあります。

この問題は、IMDB CacheとOracleを同じマシン上で使用するときに、TNS_ADMIN環境変数がOracleの正しいtnsnames.oraファイルを指していない場合に発生することがあります。たとえば、ラップトップでOracle Databaseの複数のインスタンスが稼働している場合に、この問題が発生することがあります。

本番環境では、TimesTenとOracleは、通常、異なるマシン上で稼働させます。この場合、TimesTenが稼働しているマシン上のtnsnames.oraファイルを指すようにTNS_ADMIN環境変数を設定しなおさないようにしてください。Oracleクライアントは、接続の解決にTNS_ADMIN設定を使用しますが、TimesTenのメイン・デーモン、キャッシュ・エージェント、Webサーバーおよびレプリケーション・エージェントは、TNS_ADMIN設定を認識しません。 IMDB Cacheは、OracleクライアントとTimesTenが異なるtnsnames.oraファイルを使用する場合、正常に動作しません。

Windowsの場合、TNS_ADMIN環境変数は次のように設定します。

  1. 「マイ コンピュータ」を右クリックし、「プロパティ」を選択します。

  2. 「詳細設定」タブで、「環境変数」を選択します。

  3. 使用するtnsnames.oraファイルが格納されているディレクトリを指すようにTNS_ADMINをシステム環境変数として追加または編集します。INAMEコマンドを使用して、tnsnames.oraファイル内に他のtnsnames.oraファイルを組み込むことができます。

Oracleサーバーおよびクライアントのバージョンに互換性がない

ORA-12170やORA-12535などの接続タイムアウト・エラー、またはサーバーのバージョンがサポートされていないことを示すORA-03134を受け取った場合は、使用しているOracleクライアントおよびOracleサーバーのバージョンに互換性があることを確認します。

Metalinkのドキュメント・ノート207303.1「Client/Server/Interoperability Support Between Different Oracle Versions」に、Oracleでサポートされているクライアントとサーバーの組合せを示しています。

TimesTenで使用できるOracleクライアントおよびサーバーの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のOracle In-Memory Database Cacheに関する説明を参照してください。クライアント/サーバーのバージョンに関する既知の問題については、OracleおよびTimesTenのリリース・ノートも参照してください。

Oracleユーザー名とパスワードを検証できない

この項では、Oracleユーザー名およびパスワードの使用時に発生する可能性があるいくつかの問題について説明します。

考えられる原因 参照先
ライブラリ環境変数が正しく設定されていない 「ライブラリ・パス環境変数を確認する」
Oracleプロセスが稼働していない 「TNSリスナーおよびOracleサーバーのステータスを確認する」
ユーザーが正しいOracle権限を持っていない 「Oracle権限を確認する」
DSNの構成が正しくない 「DSN定義を確認する」
キャッシュ管理ユーザーのIDまたはパスワードに関する問題 「キャッシュ管理ユーザーのIDおよびパスワードを設定する」
ユーザー環境とシステム環境の整合性がとれていない 「ユーザー環境とシステム環境を確認する」
動的ライブラリがロードされていない 「ロードされた動的ライブラリを検証する」

ライブラリ・パス環境変数を確認する

使用しているプラットフォームのライブラリ・パス環境変数を確認します。

プラットフォーム 確認する変数
UNIX（HP-UXを除く） LD_LIBRARY_PATH

64-bitプラットフォームでは、LD_LIBRARY_PATH64がLD_LIBRARY_PATHより優先されます。ライブラリ・パスがLD_LIBRARY_PATH64に指定されていることを確認します。
HP-UX SHLIB_PATH
Windows PATH

ライブラリ・パス環境変数には、次の情報が含まれている必要があります。

TimesTenのビットとプラットフォームのビット 設定値
32-bitプラットフォーム上の64-bitまたは32-bitのTimesTen $ORACLE_HOME/LIBおよび$ORACLE_HOME/NETWORK/LIB
64-bitプラットフォーム上の32-bitのTimesTen $ORACLE_HOME/LIB32および$ORACLE_HOME/NETWORK/LIB32

TNSリスナーおよびOracleサーバーのステータスを確認する

SQL*Plusを使用してOracle Databaseに接続するか、またはOracle Enterprise Managerを使用してステータスを確認します。

Oracle権限を確認する

OracleのSQL*Plusコマンド・プロンプトから次のコマンドを入力して、現在自分に付与されているOracle権限を表示します。

SELECT * FROM SESSION_ROLES;
SELECT * FROM SESSION_PRIVS;

表示された権限と、様々なIMDB Cache操作で必要な権限（『Oracle In-Memory Database Cacheユーザーズ・ガイド』のOracleユーザーへの権限の付与に関する説明を参照）を比較します。追加の権限が必要な場合は、Oracle管理者に連絡してください。

DSN定義を確認する

  • DSN属性が正しく設定されていることを確認します（『Oracle In-Memory Database Cacheユーザーズ・ガイド』のOracle DatabaseからデータをキャッシュするTimesTenデータベースのDSNに関する説明を参照）。

  • IMDB CacheのDSN定義がシステムDSNであることを確認します。

  • IMDB CacheのDSNが1回のみ定義されていることを確認します。

  • Oracleのユーザー名とパスワードを確認します。 SQL*Plusを使用し、DSN定義で使用しているものと同じOracleIDとOraclePWDを使用してOracleに接続し、それらが正しいことを確認します。

TimesTenマシンを再起動する

Oracleクライアントをインストールしてから、マシンを再起動していない場合、TimesTenデーモンは、Oracleクライアントをインストールする前の古い環境で稼働しています。 マシンを再起動すると、新しい環境でTimesTenを起動できます。

キャッシュ管理ユーザーのIDおよびパスワードを設定する

ttIsqlセッションで、データ・ストアに接続して次のコマンドを入力します。

Command> call ttCacheUidPwdSet('scott','tiger');

エラーが返される場合は、Oracle ID、キャッシュ管理ユーザーIDおよびキャッシュ管理パスワードを確認します。また、Oracleインスタンスが実行されているかどうかも確認します。

ユーザー環境とシステム環境を確認する

問題の原因が、ユーザー環境とシステム環境の相違によるかどうかを確認するテストを行います。この手順では、2つのセッション・ウィンドウ（Windowsのコマンド・プロンプト・ウィンドウまたはUNIXのシェル・ウィンドウ）が必要です。

  1. TimesTenデーモンを停止します。

  2. 一方のセッション・ウィンドウで、通常のユーザーとしてTimesTenデーモンを起動します。

    Windowsの場合:

    % install_dir/srv/ttsrv1121.exe -d -verbose

    UNIXの場合:

    % install_dir/srv/timestend -d verbose

    いくつかのメッセージが一瞬表示され、待機状態になります。

  3. もう1つのセッション・ウィンドウで、キャッシュ・エージェントを再起動してみます。

  4. 手順3が成功したら、手順2で1つ目のセッションで起動したTimesTenデーモンを停止します。Windowsの場合は[Ctrl]+[C]、UNIXの場合はkillコマンドを使用して停止します。

  5. ユーザー環境とシステム環境を比較します。 たとえば、ユーザーとシステムの両方が同じoci.dllのコピーを参照しているかどうか、ユーザー環境とシステム環境でoci.dllライブラリのパス名に違いがないかどうかを確認します。

  6. 相違がある場合は、必要な修正を行います。

  7. システムを再起動し、TimesTenデーモンを再起動します。

ロードされた動的ライブラリを検証する

Visual C++がインストールされているWindowsシステムで実行中の場合は、ロードされた動的ライブラリを検証します。 次に示す検証は、キャッシュ・エージェントを自動リフレッシュなしで起動できる場合にのみ可能です。

  1. TimesTenが起動していることを確認します。

  2. 自動リフレッシュなしでキャッシュ・エージェントを起動します。

    Command> call ttCacheStart;
Command> create cache group cg1 from t1(c1 int not null primary key);

  3. Windowsの「タスク マネージャ」を開き、プロセスttora1121.exeを検索して選択します。 右クリックして「デバッグ」を選択します。 これでVisual C++が起動され、ロードされたDLLがデバッグ・ウィンドウに表示されます。「Oracleサービス名を解決できない」を参照してください。

  4. キャッシュ・グループをロードして、キャッシュ・エージェントとのキャッシュ接続を強制します。

    Command> load cache group cg1 commit every 100 rows;

  5. デバッグ・ウィンドウにロードされたDLLを、次の例4-1に示す部分的なリストと比較します。

例4-1 ロードされたDLLのリスト

この部分的なリストは、Oracleクライアントで作成されています。

Loaded 'E:\TimesTen\tt1121_32\bin\timestenorad1121.exe', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\kernel32.dll', no matching symbolic information found.
Loaded 'E:\TimesTen\tt1121_32\bin\tten1121.dll', no matching symbolic information found.
Loaded 'E:\TimesTen\tt1121_32\bin\ttcommon1121.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\wsock32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\ws2_32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\msvcrt.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\ws2help.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\advapi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\rpcrt4.dll', no matching symbolic information found.
...

OCIの初期化に失敗する

Oracle Databaseへの接続が必要な操作で、エラー5105「OCI initialization failed」が発生することがあります。たとえば、次の状況で発生します。

エラー5105には、エラーの原因に関する追加情報が含まれています。

サポートされていないデータ型マッピング

キャッシュ・グループを作成しようとすると、次のエラーが表示されることがあります。

5115: Unsupported type mapping for column name

たとえば、Oracleの表tabは、次のように記述できます。

COL1     NUMBER(38) NOT NULL
COL2     NUMBER(38)

次のようにしてキャッシュ・グループを作成します。

CREATE CACHE GROUP cg FROM tab(col1 CHAR(10) NOT NULL PRIMARY KEY);

文はNUMBERデータ型の列をCHARデータ型の列へのマップを試みるため、列エラー5119が表示され、キャッシュ・グループは作成されません。

詳細は、『Oracle In-Memory Database Cacheユーザーズ・ガイド』のデータ型マッピングに関する説明を参照してください。

NULL制約がOracleと一致しない

キャッシュ・グループを作成しようとすると、次の警告が表示されることがあります。

Warning 5119: Column name has different nullability setting in Oracle

たとえば、Oracleの表tabは、次のように記述できます。

COL1     NUMBER(38) NOT NULL
COL2     NUMBER(38)

次のようにしてキャッシュ・グループを作成します。

CREATE CACHE GROUP cg
    FROM tab(col1 INTEGER NOT NULL PRIMARY KEY, col2 INTEGER NOT NULL);

Oracleのcol2にはNULL制約がありませんが、キャッシュ・グループのcol2はNOT NULLとして定義されているため、警告5119が表示されます。

キャッシュされたOracle表へのDDL操作のため、キャッシュ・グループ操作が失敗する可能性がある

TimesTenにキャッシュされたOracle表へのDDL操作のため、キャッシュ・グループで障害が発生する可能性があります。 たとえば、TimesTenにキャッシュされたOracle表の列をユーザーが削除したとします。 キャッシュ・グループが伝播またはフラッシュされると、TimesTenはOracle表にすでに存在していない列を更新することになります。 キャッシュ・グループがロードまたはリフレッシュされると、TimesTenは削除された列からデータの取得を試行することになります。

次のキャッシュ・グループ操作は失敗する可能性があります。

Oracle実表に対してDDL操作が行われたため、キャッシュ・グループ操作が適切に実行されていない可能性がある場合は、DDL追跡を使用して問題を診断します。 DDL追跡では、キャッシュされたすべてのOracle表の変更履歴が保存されます。 SQL文およびその実行日時は、Oracleのキャッシュ管理ユーザー・スキーマ内のTimesTen表にそれぞれ書き込まれます。

DDL追跡オブジェクトを作成する方法およびOracle内の実表に対してDDL追跡を有効にする方法の詳細は、『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュされたOracle表へのDDL操作の監視に関する説明を参照してください。 DDL追跡の初期化および有効化に使用される組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。

キャッシュ・グループ内のオブジェクトの更新後に変更を表示できない

キャッシュ・グループ内のオブジェクトを変更した後に変更が後続のSQL文に表示されない場合は、次のいずれかの問題が発生した可能性があります。

たとえば、ユーザーがAWTキャッシュ・グループを作成したとします。 その後、このユーザーは表に行を追加しました。 このユーザーが表に対してSELECT * FROMを実行すると、それらの行が表示されませんでした。 ttmesg.logエラー・ファイルには、Oracleを使用できないというエラーは表示されていません。 かわりに、次のメッセージが表示されています。

12:09:02.10 Err : REP: 29934: CACHE1:meta.c(904): TT5221: TT5221: Oracle syntax error in OCIStmtExecute(): ORA-00942: table or view does not exist rc = -1 -- file "bdbStmt.c", lineno 1535, procedure "getOraOutTypesNLengths()"
12:09:02.27 Err : REP: 29934: CACHE1:receiver.c(1978): TT5250: Awt Initialization Failure. Could not compile meta data sql.
12:09:02.27 Warn: REP: 29934: CACHE1:transmitter.c(6505): TT16060: Failed to read data from the network. select() timed out

リカバリするには、次の手順を実行します。

  1. キャッシュ・グループへのすべての更新を停止します。

  2. AWTキャッシュ・グループを使用している場合は、キャッシュ・グループをフラッシュします。

  3. 削除および作成を行ってキャッシュ・グループを再作成します。

ロードまたはリフレッシュに失敗する

COMMIT EVERY n ROWSでnに0（ゼロ）より大きい値を指定した場合に、LOAD CACHE GROUPまたはREFRESH CACHE GROUP文の実行に失敗すると、ターゲット・キャッシュ・グループの内容が一貫性のない状態になることがあります。キャッシュ・インスタンスの一部だけがロードされる場合もあります。

キャッシュ・グループをアンロードしてから再ロードします。キャッシュ・グループを削除して再作成する方が簡単な場合もあります。

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

この項の内容は次のとおりです。

ttCacheAutorefreshStatsGetプロシージャの使用

ttCacheAutorefreshStatsGetプロシージャでは、指定したキャッシュ・グループで実行された最近10回の自動リフレッシュ操作に関する情報が返されます。

ttCacheAutorefreshStatsGetプロシージャで情報が返されるのは、キャッシュ・エージェントが実行中で、自動リフレッシュの状態がONまたはPAUSEDになっている場合のみです。キャッシュ・エージェントが再起動されたり、自動リフレッシュの状態がOFFに変更された場合、すべての戻りフィールドは0（ゼロ）に設定されます。

例4-2 ttCacheAutorefreshStatsGetのコール

この例では、testcacheを使用します。testcacheは、1つの表を持ち、増分自動リフレッシュ間隔が10秒のREADONLYキャッシュ・グループです。

Command> call ttcacheautorefreshstatsget('user1','testcache');

< 1164260, 2007-07-23 15:43:52.000000, 850280, 44, 0, 75464, 528255, 75464, 310, 110, 6800, 1890912, 12439795, 1890912, 160020, InProgress >
< 1164260, 2007-07-23 15:43:33.000000, 831700, 43, 13550, 108544, 759808, 108544, 1030, 230, 12290, 1815448, 11911540, 1815448, 160020, Complete >
< 1164260, 2007-07-23 15:43:12.000000, 810230, 42, 17040, 115712, 809984, 115712, 610, 330, 16090, 1706904, 11151732, 1706904, 146470, Complete >
< 1164260, 2007-07-23 15:42:52.000000, 790190, 41, 14300, 94208, 659456, 94208,560, 320, 13410, 1591192, 10341748, 1591192, 129430, Complete >
< 1164260, 2007-07-23 15:42:32.000000, 770180, 40, 12080, 99328, 695296, 99328,450, 290, 11340, 1496984, 9682292, 1496984, 115130, Complete >
< 1164260, 2007-07-23 15:42:12.000000, 750130, 39, 10380, 86016, 598368, 86016,430, 230, 9720, 1397656, 8986996, 1397656, 103050, Complete >
< 1164260, 2007-07-23 15:41:52.000000, 730130, 38, 13530, 112640, 700768, 112640, 530, 220, 12780, 1311640, 8388628, 1311640, 92670, Complete >
< 1164260, 2007-07-23 15:41:32.000000, 710120, 37, 9370, 56320, 326810, 56320, 310, 160, 8900, 1199000, 7687860, 1199000, 79140, Complete >
< 1164260, 2007-07-23 15:41:22.000000, 700120, 36, 2120, 10240, 50330, 10240, 50, 200, 1870, 1142680, 7361050, 1142680, 69770, Complete >
< 1164260, 2007-07-23 15:41:12.000000, 690110, 35, 0, 0, 0, 0, 0, 0, 0, 1132440, 7310720, 1132440, 67650, Complete >
10 rows found.

表4-1に、最初の行の出力の結果を示します。

表4-1 最後の自動リフレッシュ操作でのttCacheAutorefreshStatsGetの結果

結果 フィールド名 説明 
1164260

cgId

キャッシュ・グループID。

 
2007-07-23 15:43:52.000000

startTimestamp

この時間隔で自動リフレッシュが開始された時間のタイムスタンプ。

 
850280

cacheAgentUpTime

この時間隔で自動リフレッシュ・トランザクションが開始された時点でのキャッシュ・エージェントの経過時間（ミリ秒）。この値は累積され、キャッシュ・エージェント・プロセスが開始されるとリセットされます。

 
44

autorefNumber

自動リフレッシュ番号。

 
0

autorefDuration

この自動リフレッシュ操作にかかった時間（ミリ秒）。操作は現在進行中であるため、値は0（ゼロ）です。

 
75464

autorefNumRows

この自動リフレッシュ操作で自動リフレッシュされた行数。キャッシュ・グループに子表が存在する場合、ルート表および子表のすべての行が含まれます。

注意: 完全自動リフレッシュの場合、この情報は返されません。

 
528255

numOracleBytes

この自動リフレッシュ操作でOracleから転送されたバイト数。

注意: 完全自動リフレッシュの場合、この情報は返されません。

 
75464

autorefNumRootTblRows

この自動リフレッシュ操作で自動リフレッシュされたルート表の行数。

 
310

autorefQueryExecDuration

Oracleで自動リフレッシュ問合せの実行にかかった時間（ミリ秒）。

注意: 完全自動リフレッシュの場合、この情報は返されません。

 
110

autorefQueryFetchDuration

自動リフレッシュ問合せでOracleからの行フェッチにかかった時間（ミリ秒）。

注意: 完全自動リフレッシュの場合、この情報は返されません。

 
6800

autorefTtApplyDuration

TimesTenで、更新された行をキャッシュ・グループに適用するのにかかった時間（ミリ秒）。

注意: 完全自動リフレッシュの場合、この情報は返されません。

 
1890912

totalNumRows

キャッシュ・エージェントの起動後に自動リフレッシュされた行の総数。

注意: 完全自動リフレッシュの場合、この情報は返されません。

 
12439795

totalNumOracleBytes

キャッシュ・エージェントの起動後にOracleから転送された総バイト数。

注意: 完全自動リフレッシュの場合、この情報は返されません。

 
1890912

totalNumRootTblRows

キャッシュ・エージェントの起動後に自動リフレッシュされたルート表の行の総数。

 
160020

totalDuration

キャッシュ・エージェントの起動後の自動リフレッシュの総経過時間（ミリ秒）。

 
InProgress

autorefreshStatus

ステータス。 CompleteまたはFailedとなる場合もあります。

この例では子表がないため、自動リフレッシュされた行の総数（1890912）は、自動リフレッシュされたルート表の行の総数と同じになります。

Oracleで更新される行数が、TimesTenで自動リフレッシュされる行数に反映されるとはかぎりません。Oracleの更新がTimesTenで複数回適用されたり、Oracleの同じ行への複数の更新がTimesTenでは1回の更新として適用される場合もあります。

変更ログ表の情報の表示

TimesTenには、Oracle Databaseに存在する変更ログ表から、自動リフレッシュ・キャッシュ・グループの情報を収集するSQLスクリプトが用意されています。 変更ログ表の詳細は、『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュ・グループの管理に使用されるOracleオブジェクトに関する説明を参照してください。

スクリプトでは、キャッシュされた各表について次の情報が表示されます。

****************************
 * Host name: my-pc
 * Timesten datastore name: c:\data\tt1121
 * Cache table name: USER1.TESTCACHE
 * Change log table name: tt_03_55555_L
 * number of rows in change log table: 100000
 * Maximum logseq on the change log table: 38
 * Timesten has autorefreshed updates up to logseq: 38
 * Number of updates waiting to be autorefreshed: 0
 * Number of updates that has not been marked with a valid logseq: 0
****************************

ログ順序番号（logseq）は、自動リフレッシュ操作のマーカーとして機能します。

SQL*Plusを使用して、Oracle Databaseでキャッシュ管理ユーザーとしてスクリプトを実行します。別のユーザーとしてスクリプトを実行すると、変更ログ表が存在しないことがレポートされます。

スクリプトの場所は次のとおりです。

install_dir/oraclescripts/cacheInfo.sql

サポート・ログの自動リフレッシュに関するメッセージの理解

サポート・ログには、自動リフレッシュの処理状況を示すメッセージが含まれます。たとえば、自動リフレッシュ間隔が10秒（10,000ミリ秒）に設定されたREADONLYキャッシュ・グループtestcacheがあるとします。

自動リフレッシュが開始されると、サポート・ログには次のように表示されます。

15:43:33.96 Info: ORA:  5264: ora-5264-5676-refresh03918: Starting autorefresh number 43 for interval 10000ms

メッセージに含まれる情報は次のとおりです。

  • タイムスタンプ（15:43:33.96）

  • キャッシュ・エージェント・プロセスID（5264）

  • スレッドID（5676）

自動リフレッシュ番号は特定の時間隔に対してのみ一意であるため、スレッドIDは重要です。特定の自動リフレッシュ操作を追跡する際は、スレッドIDと自動リフレッシュ番号の両方を確認するようにしてください。

サポート・ログには、ttCacheAutorefreshStatsGetプロシージャに似た情報をレポートする長いメッセージも含まれます。この自動リフレッシュ間隔では、108544行が更新され、キャッシュ・エージェントの起動後に1815448行が更新されています。このメッセージでは、キャッシュ・グループの表が1つのみであるため、行の総数とルート表の行の総数が同じであることに注意してください。 Numberは自動リフレッシュ番号です。すべての時間はミリ秒単位で表されます。

15:43:51.81 Info: ORA:  5264: ora-5264-5676-refresh04387: Cache agent refreshed cache group USER1.TESTCACHE: Number - 43, Duration - 13550, NumRows - 108544, NumRootTblRows - 108544, NumOracleBytes - 759808, queryExecDuration - 230, queryFetchDuration - 1030, ttApplyDuration - 12290, totalNumRows - 1815448, totalNumRootTblRows - 1815448, totalNumOracleBytes - 11911540, totalDuration - 160020

追加メッセージに、自動リフレッシュ操作が正常に完了したことが示されます。

15:43:51.81 Info: ORA:  5264: ora-5264-5676-refresh04449: Autorefresh number 43 finished for interval 10000ms successfully
15:43:51.81 Info: ORA:  5264: ora-5264-5676-fresher01619: Autorefresh number 43 succeeded for interval 10000 milliseconds

タイムスタンプを調べ、自動リフレッシュが予想どおり処理されているかどうかを確認します。

サポート・ログの場所の設定方法については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモン・オプションの管理に関する説明を参照してください。

自動リフレッシュの失敗の診断

ttCacheAutorefreshStatsGetで自動リフレッシュ操作のステータスがFailedと表示された場合は、ttCacheAutorefreshStatsGetの出力に表示された番号の自動リフレッシュ操作に関連するメッセージをサポート・ログで確認します。自動リフレッシュ操作の開始後に発生したエラーがないかどうかを探します。

例4-3 ttCacheAutorefreshStatsGet出力に自動リフレッシュの失敗が示されている場合

ttCacheAutorefreshStatsGetの出力の次の行が、失敗した自動リフレッシュ操作を示しています。

< 1164260, 2007-08-01 14:56:36.000000, 959350, 9, 0, 0, 0, 0, 0, 0, 0, 1, 7, 1, 50, Failed >

自動リフレッシュ番号は9です。

サポート・ログに、自動リフレッシュ番号9の開始メッセージが表示されています。

14:56:36.10 Info: ORA:  5988: ora-5988-4724-refresh03926: Starting autorefresh number 9 for interval 15000ms

自動リフレッシュ番号9のスレッドIDは4724です。このスレッドIDを持つエラー・メッセージを検索します。

サポート・ログに次のメッセージが表示されています。

14:56:36.10 Info: ORA:  5988: ora-5988-4724-refresh03953: Autorefresh thread for interval 15000ms is connected to instance inst1 on host host1. Server handle 231976252
14:56:36.12 Err : ORA:  5988: ora-5988-4724-refresh07567: TimesTen error code:5901, msg The Oracle refresh log table, "USER2"."TT_03_81799_L", for base table, USER2.READTAB2, cannot be found.
14:56:36.12 Info: ORA:  5988: ora-5988-4724-refresh05559: Autorefresh rolled back.
14:56:36.12 Info: ORA:  5988: ora-5988-4724-refresh04458: Autorefresh number 9 finished for interval 15000ms with error.
14:56:36.12 Err : ORA:  5988: ora-5988-4724-fresher01606: Autorefresh number 9 failed for cache groups with interval 15000 ms after 10 retries.

スレッドID 4724のエラー・メッセージは、変更ログ表TT_03_81799_Lが欠落していることを示しています。 この状況での対処方法については、「自動リフレッシュ時に指定した間隔でキャッシュがリフレッシュされない」の表を参照してください。

自動リフレッシュのパフォーマンス問題の診断

ttTraceMonユーティリティを使用すると、自動リフレッシュのパフォーマンス問題を診断できます。 詳細は、「AUTOREFRESHトレース」を参照してください。

トレースの出力をファイルに行うと、TimesTenのトレース処理は、アプリケーションのパフォーマンスに大きく影響し、大量のディスク領域を消費します。診断が終了したら、トレースをデフォルト値にリセットしてください。

SNMPトラップによる自動リフレッシュの問題のアラート

SNMPトラップを有効にして、自動リフレッシュの問題が発生した場合にアラートが表示されるようにします。自動リフレッシュに関連するSNMPトラップは次のとおりです。

  • ttCacheAutoRefQueFullTrap

  • ttCacheIncAutoRefFailedTrap

  • ttCacheValidationErrorTrap

  • ttCacheValidationWarnTrap

  • ttCacheValidationAbortedTrap

詳細は、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップによる診断に関する説明を参照してください。

自動リフレッシュ時に指定した間隔でキャッシュがリフレッシュされない

自動リフレッシュの問題について、考えられる原因を次の表に示します。

考えられる原因 対処
キャッシュ・エージェントがキャッシュ管理ユーザーによって起動されていない キャッシュ・エージェントの起動時に、キャッシュ管理ユーザーのIDおよびパスワードを指定する（『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する説明を参照）。
実表のオブジェクトIDが変更された 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
自動リフレッシュ・トリガーが有効でない 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
TT_version_USER_COUNT表に記録されている現在のログ順序番号が、自動リフレッシュ・ログ表の最大ログ順序番号より小さい。 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
TT_version_USER_COUNT表に、すべてのアクティブな増分自動リフレッシュ表に対してusercount > 0である行はない。 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
変更ログ表が空である 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
ユーザー・カウントが0（ゼロ）未満か、またはTT_version_USER_ログ順序が異常である 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
キャッシュされた表に関連付けられている自動リフレッシュ・ログ表、トリガーまたは順序が存在しないか、有効でないキャッシュ・エージェントが、正しいキャッシュ管理ユーザーIDで起動されたかどうかを確認する。 キャッシュ・エージェントが、正しいキャッシュ管理ユーザーIDで起動されたかどうかを確認する。キャッシュ管理ユーザーIDが正しい場合は、「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」の手順に従う。

ユーザー・エラー・ログで、致命的な異常についてのメッセージを確認する。これには、Oracleオブジェクトの破損または欠落が示されている。
TT_version_USER_COUNT表がない キャッシュ・エージェントが、正しいキャッシュ管理ユーザーIDで起動されたかどうかを確認する。キャッシュ管理ユーザーIDが正しい場合は、「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」の手順に従う。

ユーザー・エラー・ログで、致命的な異常についてのメッセージを確認する。これには、Oracleオブジェクトの破損または欠落が示されている。
TT_version_USER_COUNT表に記録されている現在のログ順序番号が変化する場合は、ブックマークと異なり、関連付けられているキャッシュ表が次にコミットされる自動リフレッシュでリフレッシュされない。 キャッシュ・エージェントを再起動する。 これによって解決しない場合は、「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」の手順に従う。
リソースの問題 キャッシュ・エージェントを再起動する。

自動リフレッシュ状態をリセットする

増分自動リフレッシュは、Oracle実表でTRUNCATE文が使用されている場合は、正しく動作しません。 Oracle実表でTRUNCATE文が使用されている場合は、ALTER CACHE GROUP文を使用して自動リフレッシュをリセットし、自動リフレッシュの状態をOFFに設定してから、別のALTER CACHE GROUP文で自動リフレッシュの状態をONに戻します。

自動リフレッシュOracleオブジェクトをリカバリしてリセットする

問題の原因が、自動リフレッシュで使用するOracleオブジェクトにある場合、またはその可能性がある場合は、次の手順でOracleオブジェクトを再作成します。

  1. 問題のキャッシュ表があるすべてのデータ・ストア上のすべてのキャッシュ・グループについて、ALTER CACHE GROUPを使用して自動リフレッシュの状態をOFFにリセットします。

    ALTER CACHE GROUP cache_group_name SET AUTOREFRESH STATE OFF;

  2. 対象となるすべてのデータ・ストア上のすべてのキャッシュ・エージェントを停止します。

  3. キャッシュ・グループ内の各表について、ユーザー・カウントが0（ゼロ）かどうかを確認します。

    Oracle Databaseで、次の文を実行します。

    SELECT usercount FROM autorefresh_id.tt_version_user_count
    WHERE tablename ='owner.tablename';

    カウントが0（ゼロ）でない場合は、次の文を実行して0（ゼロ）に設定します。

    UPDATE autorefresh_id.tt_version_user_count SET usercount = 0
    WHERE tablename ='owner.tablename';

  4. いずれかのキャッシュ・エージェントを起動します。そのキャッシュ・エージェントによって、クリーンアップ操作が実行されます。クリーンアップが終了すると、次のメッセージがサポート・ログに表示されます。

    Cleanup of the Oracle objects completed

  5. キャッシュ・エージェントによるクリーンアップが終了したら、ALTER CACHE GROUPを使用して自動リフレッシュの状態をONに戻します。

    ALTER CACHE GROUP cache_group_name SET AUTOREFRESH STATE ON;

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

  7. すべてのデータ・ストアの対象となるすべてのキャッシュ・グループについて、ALTER CACHE GROUPを使用して自動リフレッシュの状態をONに戻します。

増分自動リフレッシュが進行中ではない

増分自動リフレッシュが進行していない場合は、次のことを確認します。

サポート・ログで、次の表に記載されている状態を調べます。

最初のヘッダー・セルに表の概要が示されています。

状態 対処
Oracleサーバーの接続エラーまたは警告 接続の問題の解決の詳細は、「クライアント/サーバーの問題のトラブルシューティング」を参照。
TimesTenでのロック・タイムアウト・エラーまたは警告 このことは、通常、キャッシュ・グループに対するオープンなDDLトランザクションが原因で発生する。自動リフレッシュが必要なロックを取得できるようにDDLトランザクションをコミットする。
TimesTenでの不十分な永続データ・パーティション・エラー PermSizeの値を大きくする。
自動リフレッシュOracleオブジェクトの検証エラーまたは警告 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
キャッシュ・エージェントが予期せず終了する テクニカル・サポートに連絡する。
メイン・デーモン・ディレクトリ内にコア・ファイルがある テクニカル・サポートに連絡する。
増分自動リフレッシュが完全リフレッシュになることに関する警告 「増分自動リフレッシュが完全自動リフレッシュになる」を参照。
自動リフレッシュが長時間経っても完了しないことを示す警告 前回の自動リフレッシュ以降に数多くのトランザクションが発生した場合は、自動リフレッシュ・トランザクションに長時間かかることがある。

注意: 同じ自動リフレッシュ間隔を持つキャッシュ・グループは、1つのトランザクションで自動リフレッシュされる。

自動リフレッシュOracleオブジェクトの検証

キャッシュ・エージェントは、自動リフレッシュが進行できるように、Oracleオブジェクトが存在するかどうか、およびOracleオブジェクトが有効かどうかを自動的に検証します。通常の操作では、ユーザー・エラー・ログにオブジェクトの検証エラーまたは警告が含まれることはありません。 次のいずれかの状態が発生した場合を除いて、オブジェクトの検証エラーが見つかったときは、テクニカル・サポートに連絡してください。

  • DROP CACHE GROUP文を使用せずに、TimesTenデータ・ストアを破棄した。

  • カスタマ・アプリケーションによって、直接Oracle Databaseにあるオブジェクトが不注意に変更された。

  • Oracle Databaseの実表に対してDDL操作を行う。これにより、自動リフレッシュ操作を制御するトリガーが無効になる。

上記のいずれかの状態が発生した場合は、キャッシュ・グループを再作成する必要があります。

増分自動リフレッシュが完全自動リフレッシュになる

キャッシュ管理ユーザーの表領域が一杯になると、増分自動リフレッシュが完全自動リフレッシュになる場合があります。

この項の内容は次のとおりです。

増分自動リフレッシュが完全自動リフレッシュになっている場合の検出

増分自動リフレッシュが完全自動リフレッシュになっていないかどうかは、いくつかの方法で検出できます。

  • サポート・ログで、完全自動リフレッシュ操作が行われていることを示すメッセージを確認します。 たとえば、次のようなメッセージです。

    2007-08-08 08:06:51.35 Warn: ORA: 22119: ora-22119-0015-refresh05652: A full autorefresh will be performed for Incremental autorefresh table USER1.READTAB because change log table T_03_55555_L on Oracle has been truncated.

  • ttCacheAutorefreshStatsGetプロシージャを使用します。

    • 自動リフレッシュが通常より長い時間InProgressの状態である場合、完全自動リフレッシュが行われている可能性があります。

    • 自動リフレッシュされた行数（autoRefNumRows）が通常よりはるかに多い場合、完全自動リフレッシュが行われた可能性があります。

    サポート・ログで、完全自動リフレッシュについてのメッセージを確認してください。

  • SNMPトラップが有効になっている場合、SNMPトラップttCacheRecoveryAutorefreshTrapによって完全自動リフレッシュが通知されます。

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

キャッシュ管理ユーザー用に個別の表領域を作成することを強くお薦めします。 この表領域は、キャッシュ管理ユーザーのデフォルトの表領域として使用されます。表領域には、各Oracle表の自動リフレッシュ・トリガー、各Oracle表の変更ログ表、およびTimesTenが各キャッシュ管理ユーザーに対して必要とするその他のオブジェクトが含まれます。個別の表領域を指定しない場合、これらのオブジェクトはOracleのシステム表領域に配置されます。

Oracleでのキャッシュ管理ユーザー作成時に表領域を指定します。また、OracleのALTER USER文のDEFAULT TABLESPACE句を使用してユーザーを作成した後も表領域を指定できます。

キャッシュされた各Oracle表の変更ログ表は、キャッシュ管理ユーザーの表領域に存在します。Oracle表の各更新では、1行（1つの変更ログ・レコード）がそのOracle表の変更ログ表に挿入されます。 変更ログ・レコードのサイズ（バイト）は次のようになります。

size of change log record = size of primary key on Oracle table + 250

変更ログ表のレコード数は、Oracle表での更新率、およびTimesTenでの自動リフレッシュ間隔によって異なります。関連付けられているOracle表をキャッシュしているすべてのデータ・ストアに適用済の変更ログ・レコードは、20秒ごとにTimesTenによって削除されます。

変更ログが削除されると、次のようなメッセージがサポート・ログに表示されます。

16:32:26.73 Info: ORA: 5652: ora-5652-4756-ogTblGC01036: Garbage collector deleted 1 rows from TT_03_383270_L where logseq < 1

キャッシュ管理ユーザーの表領域が一杯になった場合に発生する状況を管理するオプションがあります。 詳細は、「キャッシュ管理ユーザー表領域が一杯になった場合の考慮事項」を参照してください。

キャッシュ管理ユーザーの表領域が一杯になった場合の診断

キャッシュ管理ユーザーの表領域が一杯になった場合は、次の状態を確認します。

  • 自動リフレッシュの状態がPAUSEDに設定されていないかどうか。状態がPAUSEDの場合、変更ログ・レコードは蓄積されます。

  • 作成したキャッシュ・グループをロードしているかどうか。キャッシュ・グループ作成のデフォルトの自動リフレッシュの状態はPAUSEDです。

  • キャッシュ・グループを作成中かどうか、またはデータ・ストアを複製中かどうか。これらの両方の処理は、変更ログ表のクリーンアップ処理を一時的に停止します。

  • TimesTenデータ・ストア上のすべてのキャッシュ・エージェントが稼働中かどうか。キャッシュ・エージェントが稼働していない場合、変更ログ・レコードは蓄積されます。

  • データ・ストア内の自動リフレッシュ・キャッシュ・グループを削除せずにデータ・ストアを破棄していないかどうか。このようなデータ・ストアは、次のような場合に発生します。

    • ttDestroy -forceでデータ・ストアを破棄した場合。

    • Overwrite接続属性を1に設定したデータ・ストアにアプリケーションで接続したが、古いデータ・ストアに存在していたキャッシュ・グループが再作成されない場合。

    データ・ストアがまだ存在している場合は、破棄されたデータ・ストアに接続してキャッシュ・グループを削除してください。

cacheInfo.sqlスクリプトを使用して、キャッシュされたOracle表ごとに変更ログ表の大きさを確認します。出力を調べて、データ・ストアがまだ使用中かどうかを確認します。 詳細は、「変更ログ表の情報の表示」を参照してください。

データ・ストアがまだ使用中である場合は、キャッシュ・エージェントが稼働していることを確認します。

TimesTenでの自動リフレッシュの処理状況を、変更ログ表の最大ログ順序番号と比較します。 TimesTenの方が遅れている場合は、ttCacheAutorefreshStatsGetプロシージャをコールして、自動リフレッシュ操作が正常に行われているかどうかを確認します。 詳細は、「ttCacheAutorefreshStatsGetプロシージャの使用」を参照してください。

ステータスが通常より長い時間InProgressであるように思われる場合は、「自動リフレッシュのパフォーマンスが悪い」を参照してください。

場合によっては、自動リフレッシュ間隔を減らすか、キャッシュ管理ユーザーの表領域のサイズを大きくする必要があります。

キャッシュ管理ユーザーの表領域が一杯になった場合に発生する状況を管理するオプションがあります。 詳細は、「キャッシュ管理ユーザー表領域が一杯になった場合の考慮事項」を参照してください。

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

キャッシュ管理ユーザーの表領域を監視するには、Oracle Enterprise Managerアラートを使用するか、またはTimesTen表領域しきい値パラメータを設定します。

キャッシュ・エージェントは、表領域の使用量を定期的に監視し、使用量が指定したしきい値を超えたときに警告を発行するように構成できます。 ttCacheConfig組込みプロシージャのTblspaceThresholdパラメータを使用して表領域のしきい値の割合を設定します。 たとえば、TblspaceThresholdを80に設定した場合、表領域の使用量が80%を超えると警告が発行されます。

  • しきい値が0（ゼロ）に設定されている場合、警告は発行されません。 これがデフォルトです。

  • しきい値が1から99の間に設定されている場合、表領域のしきい値がその数値を超えると警告が発行されます。

  • しきい値が100に設定されている場合、表領域が一杯になると警告が発行されます。

たとえば、表領域の使用量が80%を超えると発行されるように警告を構成するには、次の操作を実行します。

call ttCacheConfig('TblspaceThreshold',,,'80');

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

キャッシュ管理ユーザーの表領域が一杯になった場合の考慮事項

TimesTenデータベースにキャッシュされたOracle表を使用する場合は、増分自動リフレッシュを使用するようにOracle表を構成できます。 これらの表では、キャッシュ管理ユーザーの表領域が一杯になった場合に発生する状況を次のいずれかに指定できます。

  • DMLを実行したアプリケーションが失敗する。 これがデフォルトです。

    表領域の完全リカバリがNoneに設定される。 アプリケーションは、表領域が一杯になるとOracleから「Out of Tablespace」エラーを受信します。 その時点で、アプリケーションは、トランザクションをロールバックする必要があります。

    ttCacheConfig組込みプロシージャでParamパラメータをTblSpaceFullRecovery、ValueパラメータをNoneに設定すると、表領域の完全リカバリがNoneに設定されます。 たとえば、次の例では、terryが所有するemployees表のParamをTblSpaceFullRecovery、ValueをNoneに設定します。

    call ttCacheConfig('TblSpaceFullRecovery','terry', 'employees','None');

  • 変更ログ表を切り捨てて領域を解放すると、完全自動リフレッシュが実行されます。

    キャッシュ管理ユーザーの表領域が一杯になっても、自動リフレッシュによってキャッシュされたOracle表でDML文を実行しているすべてのアプリケーションが続行されます。 トリガーが実行され、既存の変更ログ・レコードを削除して、新しい変更ログ・レコード用に領域を開放します。 これによって、増分自動リフレッシュ・モードが構成されたキャッシュ・グループに対して完全自動リフレッシュを実行できます。 ただし、オラクル表が増分自動リフレッシュ用に構成されていない場合、トリガーは実行されません。

    アプリケーションを続行し、アプリケーションで自動リフレッシュを実行できるようにする操作を設定するには、ttCacheConfigプロシージャでParamパラメータをTblSpaceFullRecovery、ValueパラメータをReloadに設定します。 ユーザーには、自動リフレッシュが完了するまで失効データが表示されます。

    ただし、ユーザーが値Reloadを指定してキャッシュ構成パラメータTblSpaceFullRecoveryを設定しても、索引が増大している場合はその索引を処理するための十分な空きを表領域に用意できないことがあります。 変更ログ表から行を削除することでは、変更ログ表の索引用に十分な領域が開放されない場合があります。 索引の増大が急激なため、表領域全体が索引に使用され、変更ログ表をパージしても効果がない状況になると、ユーザーのアプリケーションは次のエラーを受信する可能性があります。

    ORA-01654: unable to extend index <index> by 128 in tablespace <tblspace>

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

自動リフレッシュのパフォーマンスが悪い

自動リフレッシュのパフォーマンスの悪化は、通常、大規模な自動リフレッシュ操作が原因です。 ttCacheAutorefreshStatsGetプロシージャを使用して、自動リフレッシュの経過時間を調べ、ステータスが長時間InProgressのままになっていないかどうかを確認します。

大規模な自動リフレッシュ操作が行われる可能性のある要因は、次のとおりです。

AUTOREFRESHトレースを有効にして、自動リフレッシュのパフォーマンス問題を診断します。 詳細は、「AUTOREFRESHトレース」を参照してください。

レスポンスがないTimesTenデータベースまたは停止したTimesTenデータベースによる自動リフレッシュのパフォーマンスの低下


注意:

TimesTenキャッシュ・グループの自動リカバリは、AUTOREFRESHキャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループにのみ適用されます。 この項で対象としている自動リフレッシュ・キャッシュ・グループはすべて、AUTOREFRESHキャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループを指しています。

自動リフレッシュ・キャッシュ・グループを含んでいるすべてのTimesTenデータベースが破棄されているか、または使用されていない場合でも、TimesTenはキャッシュ・エージェントが実行されていないTimesTenデータベースに対して、Oracle表への自動リフレッシュによる変更の追跡を続行します。 これによって、アクティブなTimesTenのデータベース内のキャッシュ・グループへの自動リフレッシュが遅くなります。

キャッシュ・エージェントは、データベースからのレスポンスがない状態かどうか、またはデータベースが使用されていない状態かどうかの検出を行います。 停止したTimesTenデータベースのリカバリを行うかどうか、および行う場合の方法を指定できます。 ただし、すべてのOracleオブジェクトが削除されている場合、TimesTenデータベースをリカバリすることはできません。

次の項では、アクティブでないTimesTenデータベースで自動リフレッシュのパフォーマンスが低下しないようにする方法について説明します。

キャッシュされたTimesTenデータベースのタイムアウトの設定

特定のタイムアウト期間内にキャッシュ・エージェントがOracleサーバーと通信しなかった場合に、停止中および更新を受け入れないというマークをデータベースに付けるようにTimesTenに指示できます。

ttCacheConfig組込みプロシージャのAgentTimeOutパラメータを使用して、TimesTenデータベースのタイムアウトおよび各自動リフレッシュ・キャッシュ・グループのリカバリ方法を設定します。 タイムアウト値は、同じキャッシュ管理ユーザーを使用するすべてのTimesTenデータベースに適用されます。 タイムアウト値は、最初の接続時にTimesTenデータベースをメモリーにロードしてキャッシュ・エージェントを開始するためにかかる時間より長く設定する必要があります。 そうしないと、TimesTenデータベースは誤って停止中とマークされます。 TimesTenインスタンスのすべての計画メンテナンスで、AgentTimeOutの値を一時的に0（ゼロ）に設定して、タイムアウトを無効にすることができます。 ttCacheConfig組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。

たとえば、次の例では、TimesTenデータベースのタイムアウト値を6000秒（100分）に設定します。 キャッシュ・エージェントがOracleサーバーに100分以内に接続しなかった場合、TimesTenデータベースは停止中とマークされます。

ttIsql> call ttCacheConfig('AgentTimeOut',,,'6000');

特定のキャッシュ・グループに対するリカバリ方法の構成

TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループがOracle Databaseと同期化されていない場合は、TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループをリカバリすることができます。 同期が存在しない場合、Oracle表の更新は、対応するTimesTenキャッシュ表に自動的にはリフレッシュされません。

ttCacheConfig組込みプロシージャのDeadDbRecoveryパラメータを構成して、TimesTenデータベースおよびすべての自動リフレッシュ・キャッシュ・グループの同期のリカバリ方法を指定することができます。 DeadDbRecoveryの設定は、同じキャッシュ管理ユーザーを使用するすべてのTimesTenデータベースに適用されます。 TimesTenでデータベースおよびすべての自動リフレッシュ・キャッシュ・グループをリカバリする方法を指定するには、DeadDbRecoveryパラメータをNormal、ManualまたはNoneに設定します。 DeadDbRecoveryの設定は、同じキャッシュ管理ユーザーを使用するすべてのTimesTenデータベースに適用されます。 TimesTenでデータベースおよびその自動リフレッシュ・キャッシュ・グループのリカバリが行われている間、TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループのリカバリ・ステータスを示す、これらの各エンティティの自動リフレッシュのステータスが表示されます。 TimesTenデータベースの自動リフレッシュのステータスは、Alive、DeadまたはRecoveringになります。 自動リフレッシュ・キャッシュ・グループの自動リフレッシュのステータスは、OK、DeadまたはRecoveringになります。 TimesTenデータベースのステータスの変更は、自動リフレッシュ・キャッシュ・グループのステータスの変更に次のようにリンクされています。

  • リカバリ方法がNormalに設定されている場合にTimesTenが自動リフレッシュ・キャッシュ・グループに対して完全自動リフレッシュを開始すると、キャッシュ・グループのステータスはRecoveringに設定され、データベースのステータスもRecoveringに設定されます。

  • すべての自動リフレッシュ・キャッシュ・グループがOKにリカバリされた場合または削除された場合にのみ、TimesTenデータベースのステータスはAliveに設定されます。

  • データベースのステータスがDeadに設定されると、すべての自動リフレッシュ・キャッシュ・グループもDeadに設定されます。


注意:

ttCacheDbCgStatus組込みプロシージャ（『Oracle TimesTen In-Memory Databaseリファレンス』を参照）を使用して、TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループの自動リフレッシュのステータスを確認できます。

キャッシュ・エージェントとOracleサーバー間の接続が再度確立されるときに、TimesTenは、自動リフレッシュ・キャッシュ・グループのリカバリ方法を決定します。 TimesTenは、ttCacheConfig組込みプロシージャのDeadDbRecoveryパラメータに構成されたリカバリ方法に従います。 このパラメータは、次のいずれかに設定できます。

  • Normal: これがデフォルトです。 自動キャッシュ・グループは、それぞれ完全自動リフレッシュでリカバリされます。 最初の完全リフレッシュの後、キャッシュ・グループはリカバリされ、増分自動リフレッシュが実行されます。

    自動リフレッシュ間隔が同じ自動リフレッシュ・キャッシュ・グループではトランザクションの一貫性が保証されます。 完全リフレッシュのため、増分リフレッシュほどパフォーマンスはよくありません。

    自動リフレッシュを実行すると、ステータスはRecoveringに設定されます。 完全自動リフレッシュが正常に完了すると、自動リフレッシュ・キャッシュ・グループのステータスはOKに設定されます。

  • Manual: 自動リフレッシュ・キャッシュ・グループを手動でリフレッシュしてリカバリするか、またはキャッシュ・グループが動的な場合はアンロードする必要があります。

  • None: 自動リフレッシュ・キャッシュ・グループは、TimesTen自動リフレッシュによってリカバリされることはありません。 キャッシュ・グループをリカバリするには、キャッシュ・グループを削除して再作成します。

データベースのステータスは、最初の自動リフレッシュ・キャッシュ・グループのステータスが変更されると変更されます。 リカバリ処理中の1つ以上のキャッシュ・グループが存在する場合、データベースのステータスはRecoveringに設定されます。 すべてのキャッシュ・グループのリカバリが完了すると、TimesTenデータベースのステータスはAliveとマークされます。

次の例では、すべての自動リフレッシュ・キャッシュ・グループに対してDeadDbRecoveryパラメータをNormalに設定します。 完全自動リフレッシュでTimesTenデータベースのすべての自動リフレッシュ・キャッシュ・グループがそれぞれリカバリされたら、停止したTimesTenデータベースがリカバリされます。

ttIsql> call ttCacheConfig('DeadDbRecovery',,,'Normal');

アクティブ・スタンドバイ・ペア・レプリケーション・スキームに関連するTimesTenデータベースにキャッシュ・グループが含まれている場合に、アクティブ・マスター・データベースの自動リフレッシュのステータスがDeadで、スタンドバイ・マスター・データベースの自動リフレッシュのステータスがAliveであると、スタンドバイ・マスターは自動的にはアクティブ・マスターの役割を果たしません。 リカバリでは、キャッシュ・エージェントおよびレプリケーション・エージェントが実行されていることを手動で確認する必要があります。 各状況の詳細は次のとおりです。

表4-2 アクティブ・スタンドバイ・レプリケーション・ペアに関連するキャッシュ・グループのリカバリ

DeadDbRecoveryの設定 アクティブ・マスター スタンドバイ・マスター 実行される動作

Normal

Alive

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントがスタンドバイ・マスターで実行されていることを確認します。 キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。 これによって、データベースがRecoveringに設定されます。 単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。 すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、スタンドバイ・マスターを失敗させて、新しいスタンドバイ・マスターをロールアウトすることもできます。

Normal

Dead

Alive

キャッシュ・エージェントおよびレプリケーション・エージェントがアクティブ・マスターで実行されていることを確認します。 キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。 これによって、データベースがRecoveringに設定されます。 単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。 すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、アクティブ・マスターを失敗させて、スタンドバイ・マスターを新しいアクティブ・マスターとして切り替えてから、新しいスタンドバイ・マスターをロールアウトすることもできます。

Normal

Dead

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントが両方のマスターで実行されていることを確認します。 キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。 これによって、データベースがRecoveringに設定されます。 単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。 すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、新しいマスターをロールアウトすることもできます。

Manual

Alive

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントがスタンドバイ・マスターで実行されていることを確認します。 キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。 これによって、データベースがRecoveringに設定されます。 単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。 すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、スタンドバイ・マスターを失敗させて、新しいスタンドバイ・マスターをロールアウトすることもできます。

Manual

Dead

Alive

キャッシュ・エージェントおよびレプリケーション・エージェントがアクティブ・マスターで実行されていることを確認します。 手動リフレッシュを使用して、アクティブ・マスターの自動リフレッシュ・キャッシュ・グループをリカバリします。 すべてのキャッシュ・グループがOKに設定されたか、または削除された後で、データベースがAliveに設定されます。

Manual

Dead

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントがアクティブ・マスターで実行されていることを確認します。 手動リフレッシュを使用して、アクティブ・マスターの自動リフレッシュ・キャッシュ・グループをリカバリします。 すべてのキャッシュ・グループがOKに設定されたか、または削除された後で、データベースがAliveに設定されます。 その後、スタンドバイ・マスターに変更がレプリケートされます。

None

Alive

Dead

スタンドバイ・マスターをFailedとマークします。 スタンドバイ・マスター・データベースに対してttDestroyユーティリティを実行します。 アクティブ・マスターからttRepAdmin -duplicateユーティリティを実行して、アクティブ・マスターを複製します。

None

Dead

Alive

ttDesctroyユーティリティを使用して、停止したアクティブ・マスターを削除します。 ttRepAdmin -duplicateユーティリティでスタンドバイ・マスターを複製して、停止したアクティブ・マスターをリカバリします。

None

Dead

Dead

新しいマスターをロールアウトします。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引