ヘッダーをスキップ
Oracle® TimesTen In-Memory Databaseトラブルシューティング・ガイド
11g リリース2(11.2.2)
B66722-02
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

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

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

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

考えられる原因 対処
キャッシュ・エージェントがすでに稼働している 「キャッシュ・エージェントのステータスを確認する」を参照してください。
Oracleライブラリが見つからない
ORACLE_HOMEが無効。 「ORACLE_HOME環境変数を確認する」を参照してください。
権限が不足している キャッシュ・エージェントを起動または停止するには、CACHE_MANAGER権限が必要です。
OracleNetServiceNameが間違っている DSN定義に設定したOracleNetServiceNameが、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インストレーション・ガイド』の環境変数に関する説明を参照してください。

NLS環境変数を確認する

TimesTen はNLS環境変数を使用していませんが、TimesTenアプリケーションが実行している環境でNLS環境変数を設定します。NLS環境変数の設定を解除し、TimesTenデーモン、キャッシュ・エージェントおよびレプリケーション・エージェントを再起動します。

予期しないシステム・シャットダウン後のキャッシュ・グリッドのリカバリ

停電などが起きた場合、サーバーにシステム障害や予期せぬ再起動が発生する可能性があります。このような場合、キャッシュ・グリッドは通常のシャットダウンを行わずに、予期せず終了します。

次の項では、システムが予期せずシャットダウンする2つのシナリオについてのリカバリ方法を説明します。

キャッシュ・グリッド・ノードの一部が実行中である場合

キャッシュ・グリッド・ノートは、サーバーがシャットダウンすると予期せず終了する場合がありますが、アクティブなままである場合もあります。このような場合、次の手順のように、アタッチされたノードからttGridDetachListを実行して、まず機能していないノードをデタッチする必要があります。

  1. アクティブなグリッド・ノードに接続し、ttGridDetachListを実行して、機能していないノードすべてをグリッドからデタッチします。

  2. 再起動したサーバーのデータベースに接続します。ttRepStartを起動して、レプリケーション・エージェントを起動します。

  3. ttGridAttachを実行して、キャッシュ・グリッド・ノードをアタッチします。

  4. 通常のデータベース操作を再開します。

すべてのキャッシュ・グリッド・ノードが予期せず終了した場合

サーバーがシャットダウンした時にすべてのキャッシュ・グリッド・ノードが予期せず終了した場合、次のタスクを実行してキャッシュ・グリッドをリカバリします。

  1. 起動したサーバーのデータベースに接続して、各グリッド・ノードにログオンします。ttRepStartを起動して、レプリケーション・エージェントを起動します。ログが現行であれば、レプリケーション・エージェントは既存のログをフラッシュします。

  2. 各ノードにttGridAttachをコールすると、他のメンバーと通信できないために通信エラーが発生して失敗します。失敗したアタッチはノード情報をクリーンアップします。

  3. ttGridAttachを実行した最後のノードは成功します。この時点で、すべてのノードがクリーンアップされるので、再びすべてのノードにttGridAttachを実行して、各ノードをグリッドにアタッチします。

  4. 通常のデータベース操作を再開します。

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

サービス名が解決できなかったことを示すエラー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でサポートされているクライアントとサーバーの組合せを示しています。

クライアント/サーバーのバージョンに関する既知の問題については、OracleおよびTimesTenのリリース・ノートを参照してください。

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

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

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

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

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

プラットフォーム 確認する変数
UNIX LD_LIBRARY_PATH

64-bitプラットフォームでは、LD_LIBRARY_PATH64がLD_LIBRARY_PATHより優先されます。ライブラリ・パスがLD_LIBRARY_PATH64に指定されていることを確認します。
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;

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

DSN定義を確認する

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

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

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

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

TimesTenマシンを再起動する

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

キャッシュ管理ユーザーの名前およびパスワードの設定

キャッシュ管理ユーザーの名前とパスワードは、TimesTenデータベースに1回のみ設定する必要があります。ただし、TimesTenデータベースが破棄されて再作成された場合、またはOracle Databaseでキャッシュ管理ユーザーの名前が削除されて再作成された場合は、変更する必要があります。

TimesTenデータベースでキャッシュ・エージェントを実行している場合、またはデータベース内にキャッシュ・グループが存在する場合は、キャッシュ管理ユーザーの名前およびパスワードを変更できません。キャッシュ管理ユーザーの名前およびパスワードを変更する前に、キャッシュ・グループを削除する必要があります。また、キャッシュ管理ユーザーの名前およびパスワードを変更する前に、キャッシュ・エージェントを停止し、ユーザー名およびパスワードを変更した後でキャッシュ・エージェントを再起動する必要があります。

ttIsqlセッションから、キャッシュ・マネージャ・ユーザーとしてデータベースに接続し、ttCacheUidPwdSet組込みプロシージャをコールして、次のようにOracleキャッシュ管理ユーザーの名前とパスワードを設定します。

Command> call ttCacheUidPwdSet('cacheuser','oracle');

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

また、ttAdmin -cacheUidPwdSetユーティリティ・コマンドを、CACHE_MANAGERを持つTimesTen外部ユーザーとして実行して、ユーザー名およびパスワードを設定することもできます。

% ttAdmin -cacheUidPwdSet -cacheUid cacheuser -cachePwd oracle cachealone1

-cachePwdオプションを指定しなかった場合、ttAdminユーティリティによってキャッシュ管理ユーザーのパスワードを入力するように求められます。ユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

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

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

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

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

    Windowsの場合:

    % install_dir/srv/ttsrv1122.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タスク・マネージャを開いて、プロセスttora1122.exeを見つけたら強調表示します。強調表示したプロセスを右クリックして、「デバッグ」を選択します。これにより、Visual C++が起動し、「Oracleサービス名を解決できない」で説明されているように、デバッグ・ウィンドウにロードされたDLLが表示されます。

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

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

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

install_dir/oraclescripts/cacheInfo.sql

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

% cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheInfo
*************Autorefresh Objects Information ***************
Host name: sys1
Timesten datastore name: /users/OracleCache/alone1
Cache table name: ORATT.ORDERS
Change log table name: tt_06_69245_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
****************************

変更ログ表ごとに戻される情報には、変更ログ表の名前、それに対応するTimesTenキャッシュ表の名前、変更ログ表の行数、変更ログ表内の更新のうちキャッシュ表に自動的にリフレッシュされなかった更新の数などが含まれています。

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

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

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

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

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

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

  • メッセージ番号: TT47118

  • タイムスタンプ(15:43:33.96)

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

  • スレッドID(5676)

メッセージ番号は、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』で参照できます。たとえば、上記のログ・メッセージで、TT47118のエラー・メッセージ番号は47118です。

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

サポート・ログには、ttCacheAutorefreshStatsGetプロシージャと同様の情報をレポートする長いメッセージが含まれています。108544行がこの自動リフレッシュ間隔で更新されたこと、およびキャッシュ・エージェントの開始後、1815448行が更新されていることを示しています。キャッシュ・グループには表が1つしかないため、このメッセージ内の行の総数およびルート表の行の総数は同じになります。Numberは、自動リフレッシュ番号を表します。時間はすべてミリ秒単位で表現されます。

15:43:51.81 Info: CAC: 5264: TT47087-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: CAC: 5264: TT47119-5264-5676-refresh04449: Autorefresh 
number 43 finished for interval 10000ms successfully
15:43:51.81 Info: CAC: 5264: TT47119-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: CAC: 5988: TT47118-5988-4724-refresh03926: Starting 
autorefresh number 9 for interval 15000ms

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

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

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

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

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

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

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

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

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

  • ttCacheAutoRefQueFullTrap

  • ttCacheIncAutoRefFailedTrap

  • ttCacheValidationErrorTrap

  • ttCacheValidationWarnTrap

  • ttCacheValidationAbortedTrap

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

IMDBキャッシュのパフォーマンスを最適化する

次の推奨事項を実行すると、IMDB Cacheのパフォーマンスを最適化できる場合があります。


注意:

これらの推奨事項はどれも、パフォーマンス上のトレードオフがあるため、パフォーマンスを最適化できるとはかぎりません。ユーザー独自の構成環境に応じて、それぞれのパフォーマンス推奨事項を検討し、テストを実施してください。

Oracle表に対する大規模なバッチ・ジョブでパフォーマンスやメモリーの問題が起きるのを回避する

お客様は、増分自動リフレッシュを設定した読取り専用のキャッシュ・グループにキャッシュされているOracle表に対して、月末または年末に大規模なバッチ・ジョブを実行する場合があります。その場合、事前に予防策を行わないと、自動リフレッシュ操作やレプリケーションにパフォーマンスやメモリーの問題が発生する可能性があります。

この項で説明するタスクは、次のIMDB Cache構成のコンポーネントではサポートされません。

キャッシュされたOracle表で大規模なバッチ・ジョブを実行する必要がある場合は、次のタスクを実行します。

  1. バッチ・ジョブの影響を受けるAUTOREFRESH属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSEDに設定します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。

    ALTER CACHE GROUP sampecg SET AUTOREFRESH STATE PAUSED;
COMMIT;

  2. バッチ・ジョブの影響を直接受けないAUTOREFRESH属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSEDに設定します。これにより、バッチ処理中のデータは一貫性のあるビューになります。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。

  3. キャッシュされたOracle表でバッチ・ジョブを実行します。

  4. すべての自動リフレッシュ変更ログ記録が有効なログ順序番号(logseq)に割り当てられていることを確認します。cacheInfo.sqlスクリプトをコールします。

    % cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheInfo

    有効なログ順序番号でマークされていない更新の数を確認します。自動リフレッシュが一時停止の状態であるキャッシュ・グルーブのすべての表で、その数が0(ゼロ)または小さい(100未満)のが理想的です。次に例を示します。

    *************Autorefresh Objects Information  ***************
Host name: host1
Timesten datastore name: /scratch/ttuser/ds/mydsn
Cache table name: TTUSER.NOTAFFECTED
Change log table name: tt_05_460491_L
Number of rows in change log table: 1
Maximum logseq on the change log table: 1
Timesten has autorefreshed updates up to logseq: 1
Number of updates waiting to be autorefreshed: 0
Number of updates that has not been marked with a valid logseq: 0
****************************
Host name: host2
Timesten datastore name: /scratch/ttuser/ds/mydsn
Cache table name: TTUSER.AFFECTED
Change log table name: tt_05_460489_L
Number of rows in change log table: 100
Maximum logseq on the change log table: 213
Timesten has autorefreshed updates up to logseq: 213
Number of updates waiting to be autorefreshed: 10000
Number of updates that has not been marked with a valid logseq: 0
****************************

  5. 構成にアクティブ・スタンバイ・ペア・グリッド・メンバーが含まれている場合は、スタンバイの状態が、すべてのスタンバイ・ノードでPAUSEDに設定されていることを確認してください。ttIsql cachegroupsコマンドを使用します。

  6. 手順1で変更された各キャッシュ・グループについて、パラレル・モードでキャッシュ・グルーブを手動でリフレッシュします。トランザクション・サイズ(一度にコミットされる行数)および並列度に適切な値を選択します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。

    REFRESH CACHE GROUP samplecg
 COMMIT EVERY n ROWS PARALLEL m;
COMMIT;

    この操作は、自動更新リフレッシュの状態を自動的にONにリセットします。

  7. 手順2で変更された各キャッシュ・グループについて、自動リフレッシュの状態をONに設定します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。

    ALTER CACHE GROUP sampecg2 SET AUTOREFRESH ON;
COMMIT;

自動リフレッシュ・ログ表の索引を定期的に結合することをお薦めします。『Oracle Database SQL言語リファレンス』のALTER INDEXに関する説明を参照してください。

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

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

考えられる原因 対処
キャッシュ・エージェントがキャッシュ管理ユーザーによって起動されていない 『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する説明を参照して、キャッシュ・エージェントの起動時に、キャッシュ管理ユーザIDおよびパスワードを指定します。
実表のオブジェクトIDが変更された 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
自動リフレッシュ・トリガーが有効でない 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
TT_version_USER_COUNT表に記録されている現在のログ順序番号が、自動リフレッシュ・ログ表の最大ログ順序番号より小さい。 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
TT_version_USER_COUNT 表に、すべてのアクティブな自動リフレッシュ表に対してusercount > 0である行がない。 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
変更ログ表が空である 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
ユーザー・カウントが0(ゼロ)未満か、またはTT_version_USER_COUNTログ順序が異常である 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。
キャッシュされた表に関連付けられている自動リフレッシュ・ログ表、トリガーまたは順序が存在しないか、有効でない キャッシュ・エージェントが、正しいキャッシュ管理ユーザー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: CAC: 11384: TT47166-11384-1087179104-lMarker01403:
A full autorefresh will be performed for Incremental autorefresh table 
USER1.READTAB because change log table TT_06_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: CAC: 5652: TT47112-5652-4756-ogTblGC01036: Garbage collector 
deleted 1 rows from TT_06_383270_L where logseq < 1

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

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

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

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

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

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

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

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

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

    • アプリケーションが、1に設定されたOverwrite接続属性を持つデータベースに接続されているが、古いデータベースにあったキャッシュ・グルーブが再生成されていない場合。

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

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リファレンス』のttCacheConfigに関する項を参照してください。

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

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リファレンス』のttCacheConfigに関する項を参照してください。

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

自動リフレッシュのパフォーマンスの悪化は、通常、大規模な自動リフレッシュ操作が原因です。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リファレンス』のttCacheConfigに関する項を参照してください。

たとえば、次の例では、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リファレンス』のttCacheDbCgStatusの項を参照)を使用して、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に設定されます。

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

手動

Alive

Dead

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

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

手動

Dead

Alive

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

手動

Dead

Dead

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

None

Alive

Dead

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

None

Dead

Alive

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

None

Dead

Dead

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

リソースにおける自動リフレッシュ・キャッシュ・グループ・リフレッシュの待機時間が長すぎる

Oracle Databaseの更新時に、自動リフレッシュ・キャッシュ・グループ・リフレッシュ中のバッファ・ビジー・待機および行ロック待機が非常に長くなったり、デッドロックが発生する場合があり、これが原因でスループット・パフォーマンスが悪影響を受ける場合があります。自動リフレッシュログ表を使用するOracle Databaseの更新時に、複数のデッドロックが発生すると、サポート・ログに次のように表示される場合があります。

Oracle native error code = 60, msg = ORA-00060: deadlock detected while waiting
for resource
An error occurred while preparing or executing the following Oracle sql 
statement: <some statement involving <cache admin user>.TT_##_#######_L  where 
the # is some number>

INITRANSおよびFREELISTS設定を変更すると、自動リフレッシュ・ログ表への同時挿入や、これらの表の内部管理に影響を与えて、パフォーマンスを向上させることができます。これらの設定が適切に構成されていない場合、自動リフレッシュ中の実表を更新しているアプリケーションのスループット・パフォーマンスが低下します。

これらの設定は、次のように操作すると、自動または手動のいずれかで管理できます。

  • FREELISTSを自動で管理するASSM表領域を使用する。

  • Oracle Databaseの自動リフレッシュ・ログ表に対して、FREELISTSおよびINITRANSを手動で調整する。

次では、Oracle Databaseの自動リフレッシュ・ログ表のINITRANSおよびFREELISTSを手動で変更する方法の詳細を説明しています。

  1. Oracle Databaseにある自動リフレッシュ・ログ表の名前を取得します。

    キャッシュ管理ユーザーでログインし、自動リフレッシュの変更ログ表名およびその他のアイテムを表示しているSQL*PlusスクリプトcacheInfo.sqlを実行します。次の例では、太字で示されたtt_06_1216726_Lを、自動リフレッシュの変更ログ表名として表示しているcacheInfo.sqlスクリプトを実行します。

    SQL> @cacheInfo.sql
*************Autorefresh Objects Information  ***************
Host name: syst
Timesten datastore name: /users/OracleCache/alone1
Cache table name: ORATT.ORDERS
Change log table name: tt_06_1216726_L 
Number of rows in change log table: 1
Maximum logseq on the change log table: 2
Timesten has autorefreshed updates upto logseq: 1
Number of updates waiting to be autorefreshed: 1
Number of updates that has not been marked with a valid logseq: 0
****************************
Host name: consyst
Timesten datastore name: /users/OracleCache/alone1
Cache table name: ORATT.ITEMS
Change log table name: tt_06_1279699_L
Number of rows in change log table: 7
Maximum logseq on the change log table: 0
Timesten has autorefreshed updates upto logseq: 0
Number of updates waiting to be autorefreshed: 5
Number of updates that has not been marked with a valid logseq: 5
****************************

  2. Oracle Databaseの表を手動で変更します。次の例では、前回の例の表を使用します。この例では、bar.tt_06_1279699_L表のINITRANSおよびFREELISTS設定を変更します。


    注意:

    これらの設定を構成するための正しい値については、『Oracle Database SQL言語リファレンス』のINITRANS整数およびFREELISTSに関する説明を参照してください。    		 

    ALTER TABLE BAR.TT_06_1279699_L INITRANS 10;
ALTER TABLE BAR.TT_06_1279699_L STORAGE(FREELISTS 5);
or
ALTER TABLE BAR.TT_06_1279699_L MOVE STORAGE(FREELISTS 5);

  3. この表の索引のINITRANSおよびFREELISTS設定を変更します(この表の名前は自動リフレッシュ変更ログ表と同じで、末尾に「L」がもう1つ付きます)。たとえば、表bar.tt_06_1279699_Lの索引はbar.tt_06_1279699_LLです。

    これらの設定は、自動リフレッシュ変更ログ表に設定した内容と同じである必要があります。

    ALTER INDEX BAR.TT_06_1279699_LL INITRANS 10;
ALTER INDEX BAR.TT_06_1279699_LL STORAGE(FREELISTS 5);

変更ログや実表が異常に大きいと、自動リフレッシュのパフォーマンスが低下する

キャッシュ・スレッドSQLリフレッシュは、変更ログおよび実表を結合し、TimesTenにリフレッシュされる必要のある行を特定します。実表および変更ログ表のカーディナリティが大きくなると、この結合の実施に必要な時間が長くなります。変更ログ表または実表のいずれかが異常に大きい場合、パフォーマンスの低下が発生する場合があります。

次では、変更ログ表が異常に大きくなる場合のシナリオについて説明します。

  • 変更ログ表が、複数のDSNのキャッシュ・グループすべてが同じ実表を参照している構成でパージされない場合、変更ログ表のサイズは無限に増大します。これらのグループの1つ以上のキャッシュ・エージェントを無効にすると、それらのDSNは適切にキャッシュ・グループをリフレッシュせず、変更ログ表はパージされません。複数のノードのうちのいずれかで自動リフレッシュの状態を一時停止にした場合、他のノードは遅くなる場合があります。

  • 変更ログ表は、キャッシュ・エージェントの一部がシャットダウンした場合、異常に大きくなることがあります。この問題を解決するには、キャッシュを再起動して、すべてのキャッシュ・グループのリフレッシュ・サイクルが完了した後、パージされるバックログされたログのすべての行と、同期されるすべてのキャッシュ・グループをパージします。

  • 変更ログ表は、変更ログ表に挿入された行がパージされない場合や、通常の処理ではパージできない場合に、異常に大きくなることがあります。これは、1つ以上のDSNが壊れているか、最初にキャッシュ・グループを削除せずに再構築すると発生します。Oracle Databaseのキャッシュ・グループ表には、キャッシュ・グループが壊れているかを示す情報はないため、これによりキャッシュ・グループ全体が破損します。この実表に関連付けられたすべてのキャッシュ・グループを再構築および再初期化してください。また、キャッシュ・グループと一緒にDSNを破壊しないでください。必ずキャッシュ・グループを削除してから、DSNを破壊します。

断片化した自動リフレッシュの変更ログ表領域

たとえば、TimesTenのシャットダウン時に変更ログが構築された結果として最高水位標が発生すると、変更ログ表は断片化される場合があります。変更ログ表が断片化された場合、次の操作を実行できます。

  • 索引を結合します。これは、実表へのDMLの変更に影響を与えずに行うことができます。

  • オンラインでセグメントの縮小を行います。これは、実表へのDMLの変更に影響を与えずに行うことができます。『Oracle Database管理者ガイド』を参照してください。

  • 変更ログ表を再構築します。

無駄な領域がないか確認します。

  1. Oracle DatabaseにcacheInfo.sqlスクリプトを実行して、変更ログ表の名前を確認します。

  2. 変更ログ表のサイズを計算します。結果Aをコールします。この例では、変更ログ表の名前を適合させます。

    SELECT table_name, ROUND((BLOCKS*8),2)||'KB' "size" 
 FROM user_tables
 WHERE table_name LIKE 'TT_05_%_L";

  3. 変更ログ表のデータのサイズを計算します。結果Bをコールします。この例では、変更ログ表の名前を適合させます。

    SELECT table_name, ROUND((num_rows*avg_row_length/1024),2)|| 'KB' "size"
 FROM user_tables
 WHERE table_name LIKE 'TT_05_%_L';

  4. (B/A)*100が50パーセントより大きい場合、少なくとも40パーセントの領域が無駄になっています(PCTFREEストレージ・パラメータが10に設定されていると仮定)。少なくとも40パーセントの領域が無駄になっている場合、変更ログ表の断片化が推奨されます。

変更ログ表を断片化するには、次の手順を実行します。

  1. 自動リフレッシュの状態をPAUSEDに設定するようキャッシュ・グループを変更します。

  2. 変更ログ表の行を一時表にコピーします。

  3. 変更ログ表を切り捨てます。

  4. 一時表から変更ログ表に行を挿入します。

  5. 自動リフレッシュの状態をONに設定するようキャッシュ・グループを変更します。

自動リフレッシュ間隔が小さいと、パフォーマンスが低下します。

ログ表や実表の大規模なエントリーに対して数百ミリセカンドのような比較的短いリフレッシュ間隔を使用すると、キャッシュ・リフレッシュ操作は、予定されている次のリフレッシュ操作が開始するまでに完了しません。このような場合、現在の自動リフレッシュ・サイクルが終了すると、ログ表のエントリーのマークが解除されます。

このように、行にマークが付けられる時までに、同一の行を実表から次の自動リフレッシュ・サイクルのキャッシュ・グループにリフレッシュすることができます。リフレッシュにかかる時間がリフレッシュ間隔よりも大きくなっているか確認してください。リフレッシュ間隔を、冗長なリフレッシュが起きないような値に設定します。

制約にNOVALIDATEを宣言すると、グループの作成に失敗する

キャッシュ・グループを作成するOracle表が、主キー、UNIQUEまたはNOT NULL制約を持つ列にNOVALIDATEを宣言すると、キャッシュ・グループの作成は失敗します。


注意:

これは、外部キー制約にはあてはまりません。ただし、TimesTenは、一致する外部キーを、有効化されたVALIDATE状態にすることを推奨します。外部キー列を、有効化されたVALIDATE状態に変更すると、ワークロード・パフォーマンスに影響する場合があります。

TimesTenは、主キーのNOVALIDATEまたはNOT NULL表の列の定義を、NULLとして認識するため、キャッシュ・グループを作成する列として見なされません。これにより、Oracle表からキャッシュ・グループを作成する際、主キー、UNIQUEおよびNOT NULL列制約を持つすべての列は、VALIDATE状態に有効化されている必要があります。

これらのうち1つ以上の制約を持つOracle表からキャッシュ・グループを作成すると、次のエラーが発生します。

5124: Autorefresh/propagate are not allowed on restricted cache group
5168: Restricted cache groups are deprecated
5120: No matching unique index with not null columns, unique key constraint
 with not null columns, or primary key constraint on table EVENTLOG, cache
 operations are restricted.

これらのエラーを受信した場合、SELECT文を実行して、Oracle表に既存のNOVALIDATE制約がないかを確認することができます。次のSELECT文を実行すると、MyTable表にある制約がすべて表示されます。

SQL> select constraint_name, constraint_type, validated, status from 
        all_constraints where table_name = 'MyTable';
 
CONSTRAINT_NAME                C VALIDATED     STATUS
------------------------------ - ------------- --------
REFID_CONSTRAINT               C VALIDATED     ENABLED
PKEY_CONSTRAINT                P NOT VALIDATED DISABLED

キャッシュ表の主キーとなる表の列がNOVALIDATEとして有効化されている場合、次の手順を実行して、列をVALIDATE状態に有効化します。

  1. 主キー列に対してNOVALIDATE状態を有効化します。

    SQL> alter table MyTable modify constraint PKEY_CONSTRAINT 
           enable novalidate;
Table altered.
 
SQL> select constraint_name, constraint_type, validated, status 
          from all_constraints where table_name = 'MyTable';
 
CONSTRAINT_NAME                C VALIDATED     STATUS
------------------------------ - ------------- --------
REFID_CONSTRAINT               C VALIDATED     ENABLED
PKEY_CONSTRAINT                P NOT VALIDATED ENABLED

  2. 主キー列に対してVALIDATE状態を有効化します。

    SQL> alter table MyTable modify constraint PKEY_CONSTRAINT validate;
Table altered.
 
SQL> select constraint_name, constraint_type, validated, status 
          from all_constraints where table_name = 'MyTable';
 
CONSTRAINT_NAME                C VALIDATED     STATUS
------------------------------ - ------------- --------
REFID_CONSTRAINT               C VALIDATED     ENABLED
PKEY_CONSTRAINT                P VALIDATED     ENABLED

DBMS_LOCKとのロック競合を表示するAWRレポート

Automated Workload Repository(AWR)レポートにDBMS_LOCKが表示された場合、ロック競合に関していくつか問題がある可能性があります。ただし、このDBMS_LOCK待機イベントは、AWRレポートでデータベースの時間消費が大きくなっていても、IMDB キャッシュ・グリッドのアプリケーション・パフォーマンスには影響しません。この待機イベントは、別のデータベースの別のガベージ・コレクタ・セッションがすでにロックしたリソースを予約待ちしようとしているガベージ・コレクタ・セッションです。そのため、現在のガーベージ・コレクタのみが待機します。ガーベージ・コレクタ処理の待機は、他のガーベージ・コレクタの処理を妨げますが、それ以外の処理を妨げることはありません。

たとえば、次では、AWRレポートの競合イベントを示しています。

AWR 
 
Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
enq: UL - contention                  2,388       6,997   2930   72.0 Application

また、PERF AWRレポートの「SQL ordered by CPU Time」の項に表示されているように、ガーベージ・コレクタには、非常に短いCPU時間が使用されています。

SQL ordered by CPU Time              DB/Inst: REM0LNX/REM  Snaps: 14976-14977
-> Resources reported for PL/SQL code includes the resources used by all SQL
   statements called by the code.
-> % Total DB Time is the Elapsed Time of the SQL statement divided
   into the Total Database Time multiplied by 100
 
    CPU      Elapsed                  CPU per  % Total
  Time (s)   Time (s)  Executions     Exec (s) DB Time    SQL Id
---------- ---------- ------------ ----------- ------- -------------
         0      3,508          120        0.00    36.1 0mt5pk2501gph
Module: timestenorad@etcpro01.oracle.com (TNS V1-V3)
DECLARE v_lockHandle VARCHAR2(200); BEGIN dbms_lock.allocate_unique(
'ORATT$ORA_GC1_CACHEADMIN', v_lockHandle); :retval := dbms_lock.request(
v_lockHandle, dbms_lock.x_mode, 30, FALSE); END;
         0      3,499          120        0.00    36.0 bb07h2a1v817x
Module: timestenorad@etcpro01.oracle.com (TNS V1-V3)
DECLARE v_lockHandle VARCHAR2(200); BEGIN dbms_lock.allocate_unique(
'ORATT$ORA_DDSMONITOR1_CACHEADMIN', v_lockHandle); :retval := 
dbms_lock.request(v_lockHandle, dbms_lock.x_mode, 30, FALSE); END;
  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引