この章の次の項は、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ユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する説明を参照して、キャッシュ・エージェントを起動します。キャッシュ・エージェントを起動できない場合は、考えられる原因を調査し、マシンを再起動してから起動してください。
UNIXまたはLinuxプラットフォームでは、キャッシュ・エージェントおよびTimesTenデーモンを起動しているシェルにORACLE_HOME
環境変数が正しく設定されていることを確認します。ORACLE_HOME
の設定を変更する必要がある場合は、ttmodinstall
ユーティリティを使用します。
詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の環境変数に関する説明を参照してください。
停電などが起きた場合、サーバーにシステム障害や予期せぬ再起動が発生する可能性があります。このような場合、キャッシュ・グリッドは通常のシャットダウンを行わずに、予期せず終了します。
次の項では、システムが予期せずシャットダウンする2つのシナリオについてのリカバリ方法を説明します。
キャッシュ・グリッド・ノートは、サーバーがシャットダウンすると予期せず終了する場合がありますが、アクティブなままである場合もあります。このような場合、次の手順のように、アタッチされたノードからttGridDetachList
を実行して、まず機能していないノードをデタッチする必要があります。
サーバーがシャットダウンした時にすべてのキャッシュ・グリッド・ノードが予期せず終了した場合、次のタスクを実行してキャッシュ・グリッドをリカバリします。
起動したサーバーのデータベースに接続して、各グリッド・ノードにログオンします。ttRepStart
を起動して、レプリケーション・エージェントを起動します。ログが現行であれば、レプリケーション・エージェントは既存のログをフラッシュします。
各ノードにttGridAttach
をコールすると、他のメンバーと通信できないために通信エラーが発生して失敗します。失敗したアタッチはノード情報をクリーンアップします。
ttGridAttach
を実行した最後のノードは成功します。この時点で、すべてのノードがクリーンアップされるので、再びすべてのノードにttGridAttach
を実行して、各ノードをグリッドにアタッチします。
通常のデータベース操作を再開します。
サービス名が解決できなかった
ことを示すエラーORA-12514
を受け取った場合は、次の内容を確認します。
Oracle TNSPING
ユーティリティを使用して、サービスが到達可能であることを確認します。
DSN定義に設定したOracleNetServiceName
が、TimesTenでキャッシュする表が含まれるOracleインスタンスのOracleサービス名と一致することを確認します。
定義したサービス名が存在することを確認します。Windows Oracleクライアントの場合は、Oracle Net Configuration Assistantを使用してサービス名を構成します。Oracle Net Configuration Assistantで、「Oracle Netの構成」→「ローカル」→「サービス・ネーミング」に移動し、Oracleサーバーを選択して、Oracleサーバーを識別するサービス名またはSIDがあることを確認します。サービス名を追加または変更した場合は、再起動する必要があります。
SQL*Plusを使用して、Oracleのキャッシュ管理ユーザーのユーザー名とパスワードを確認し、このサービス名が機能することを確認します。次に例を示します。
%sqlplus cache_admin_user/cache_admin_pwd@OracleHost
ここで、cache_admin_user
はキャッシュ管理ユーザーのユーザー名、cache_admin_pwd
はキャッシュ管理ユーザーのパスワード、OracleHost
はDSN定義で指定されているOracleNetServiceName
です。
注意: キャッシュ管理ユーザーは、通常のOracleユーザーと異なってもかまいません。『Oracle In-Memory Database Cacheユーザーズ・ガイド』のOracleユーザーの作成に関する説明を参照してください。 |
TimesTenマシン上にtnsnames.ora
のコピーが複数存在しないことを確認します。また、tnsnames.ora
に対する権限も確認します。
TimesTenをUNIXシステムで実行している場合は、ORACLE_HOME
環境変数が、正しいOracleインストール・ディレクトリを指していることを確認します。次に例を示します。
ORACLE_HOME=/products/oracle10g
Oracleクライアントおよびサーバーのバージョンを確認します。詳細は、「Oracleサーバーおよびクライアントのバージョンに互換性がない」を参照してください。
データベースへの接続試行時に、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
環境変数は次のように設定します。
「マイ コンピュータ」を右クリックし、「プロパティ」を選択します。
「詳細設定」タブで、「環境変数」を選択します。
使用するtnsnames.ora
ファイルが格納されているディレクトリを指すようにTNS_ADMIN
をシステム環境変数として追加または編集します。INAME
コマンドを使用して、tnsnames.ora
ファイル内に他のtnsnames.ora
ファイルを組み込むことができます。
ORA-12170
やORA-12535
などの接続タイムアウト・エラー、またはサーバーのバージョンがサポートされていないことを示すORA-03134
を受け取った場合は、使用しているOracleクライアントおよびOracleサーバーのバージョンに互換性があることを確認します。
Metalinkのドキュメント・ノート207303.1「Client/Server/Interoperability Support Between Different Oracle Versions」に、Oracleでサポートされているクライアントとサーバーの組合せを示しています。
クライアント/サーバーのバージョンに関する既知の問題については、OracleおよびTimesTenのリリース・ノートを参照してください。
この項では、Oracleユーザー名およびパスワードの使用時に発生する可能性があるいくつかの問題について説明します。
考えられる原因 | 参照先 |
---|---|
ライブラリ環境変数が正しく設定されていない | 「ライブラリ・パス環境変数を確認する」 |
Oracleプロセスが稼働していない | 「TNSリスナーおよびOracleサーバーのステータスを確認する」 |
ユーザーが正しいOracle権限を持っていない | 「Oracle権限を確認する」 |
DSNの構成が正しくない | 「DSN定義を確認する」 |
キャッシュ管理ユーザーのIDまたはパスワードに関する問題 | 「キャッシュ管理ユーザーの名前およびパスワードを設定する」 |
ユーザー環境とシステム環境の整合性がとれていない | 「ユーザー環境とシステム環境を確認する」 |
動的ライブラリがロードされていない | 「ロードされた動的ライブラリを検証する」 |
使用しているプラットフォームのライブラリ・パス環境変数を確認します。
プラットフォーム | 確認する変数 |
---|---|
UNIX | LD_LIBRARY_PATH
64-bitプラットフォームでは、 |
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 |
SQL*Plusを使用してOracle Databaseに接続するか、またはOracle Enterprise Managerを使用してステータスを確認します。
OracleのSQL*Plusコマンド・プロンプトから次のコマンドを入力して、現在自分に付与されているOracle権限を表示します。
SELECT * FROM SESSION_ROLES; SELECT * FROM SESSION_PRIVS;
一覧表示された権限を、『Oracle In-Memory Database Cacheユーザーズ・ガイド』のOracleユーザへの権限の付与に関する説明の中で指定されている、IMDB Cache操作に必要な各権限と比較します。追加の権限が必要な場合は、Oracle管理者に連絡してください。
『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に接続し、それらが正しいことを確認します。
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のシェル・ウィンドウ)が必要です。
TimesTenデーモンを停止します。
一方のセッション・ウィンドウで、通常のユーザーとしてTimesTenデーモンを起動します。
Windowsの場合:
% install_dir/srv/ttsrv1122.exe -d -verbose
UNIXの場合:
% install_dir/srv/timestend -d verbose
いくつかのメッセージが一瞬表示され、待機状態になります。
もう1つのセッション・ウィンドウで、キャッシュ・エージェントを再起動してみます。
手順3が成功したら、手順2で1つ目のセッションで起動したTimesTenデーモンを停止します。Windowsの場合は[Ctrl]+[C]、UNIXの場合はkill
コマンドを使用して停止します。
ユーザー環境およびシステム環境を比較します。たとえば、ユーザーとシステムはどちらもoci.dll
の同じコピーを見ているでしょうか。oci.dll
ライブラリに対するパス名は、ユーザーとシステム環境の間で違いがあるでしょうか。
相違がある場合は、必要な修正を行います。
システムを再起動し、TimesTenデーモンを再起動します。
Visual C++がインストールされているWindowsシステムで実行中の場合は、ロードされた動的ライブラリを検証します。次に示す検証は、キャッシュ・エージェントを自動リフレッシュなしで起動できる場合にのみ可能です。
TimesTenが起動していることを確認します。
自動リフレッシュなしでキャッシュ・エージェントを起動します。
Command> call ttCacheStart; Command> create cache group cg1 from t1(c1 int not null primary key);
Windowsタスク・マネージャを開いて、プロセスttora1122.exe
を見つけたら強調表示します。強調表示したプロセスを右クリックして、「デバッグ」を選択します。これにより、Visual C++が起動し、「Oracleサービス名を解決できない」で説明されているように、デバッグ・ウィンドウにロードされたDLLが表示されます。
キャッシュ・グループをロードして、キャッシュ・エージェントとのキャッシュ接続を強制します。
Command> load cache group cg1 commit every 100 rows;
デバッグ・ウィンドウにロードされた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. ...
Oracle Databaseへの接続が必要な操作で、エラー5105「OCI initialization failed
」が発生することがあります。たとえば、次の状況で発生します。
キャッシュ・エージェントの起動時
キャッシュ管理ユーザーのIDまたはパスワードの設定時
TimesTenでのSQL文の入力時(autocommit=0、PassThrough=3の場合)
エラー5105には、エラーの原因に関する追加情報が含まれています。
OCIでOracleライブラリが見つからない。「ライブラリ・パス環境変数を確認する」を参照して、エラー・メッセージに示されたライブラリに対する権限を確認してください。
ORACLE_HOME
が無効。「ORACLE_HOME環境変数を確認する」を参照してください。
TimesTen はNLS環境変数を使用していませんが、TimesTenアプリケーションが実行している環境でNLS環境変数を設定します。NLS環境変数の設定を解除し、TimesTenデーモン、キャッシュ・エージェントおよびレプリケーション・エージェントを再起動します。
キャッシュ・グループを作成しようとすると、次のエラーが表示されることがあります。
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ユーザーズ・ガイド』のキー列で許可されるデータ型マッピングに関する説明を参照してください。
キャッシュ・グループを作成しようとすると、次の警告が表示されることがあります。
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が表示されます。
TimesTenにキャッシュされたOracle表へのDDL操作のため、キャッシュ・グループで障害が発生する可能性があります。たとえば、TimesTenにキャッシュされたOracle表の列をユーザーが削除したとします。キャッシュ・グループが伝播またはフラッシュされると、TimesTenはOracle表にすでに存在していない列を更新することになります。キャッシュ・グループがロードまたはリフレッシュされると、TimesTenは削除された列からデータの取得を試行することになります。
次のキャッシュ・グループ操作は失敗する可能性があります。
自動リフレッシュは発生しません。
AWTキャッシュ・グループ操作は、Oracleから伝播またはリフレッシュされることも、Oracleへ伝播またはリフレッシュされることもありません。
キャッシュ・グループのロードまたは伝播は失敗します。
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文に表示されない場合は、次のいずれかの問題が発生した可能性があります。
そのオブジェクトが、Oracle Databaseから削除されたか、またはなんらかの原因で破損された。
Oracle Databaseが、そのオブジェクトの作成時より前の時点までリストアまたはリカバリされた。
Oracle Databaseが停止した。
キャッシュ・グループを作成したOracle Database以外のOracle Databaseにポイントするキャッシュ・グループを作成した後に、ユーザーがOracleNetServiceName
DSNまたは接続属性を変更した。
たとえば、ユーザーが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
リカバリするには、次の手順を実行します。
キャッシュ・グループへのすべての更新を停止します。
AWTキャッシュ・グループを使用している場合は、キャッシュ・グループをフラッシュします。
削除および作成を行ってキャッシュ・グループを再作成します。
COMMIT EVERY
n
ROWS
でn
に0(ゼロ)より大きい値を指定した場合に、LOAD CACHE GROUP
またはREFRESH CACHE GROUP
文の実行に失敗すると、ターゲット・キャッシュ・グループの内容が一貫性のない状態になることがあります。キャッシュ・インスタンスの一部だけがロードされる場合もあります。
キャッシュ・グループをアンロードしてから再ロードします。キャッシュ・グループを削除して再作成する方が簡単な場合もあります。
この項の内容は次のとおりです。
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 |
|
キャッシュ・グループID。 |
2007-07-23 15:43:52.000000 |
|
この時間隔で自動リフレッシュが開始された時間のタイムスタンプ。 |
850280 |
|
この時間隔で自動リフレッシュ・トランザクションが開始された時点でのキャッシュ・エージェントの経過時間(ミリ秒)。この値は累積され、キャッシュ・エージェント・プロセスが開始されるとリセットされます。 |
44 |
|
自動リフレッシュ番号。 |
0 |
|
この自動リフレッシュ操作にかかった時間(ミリ秒)。操作は現在進行中であるため、値は0(ゼロ)です。 |
75464 |
|
この自動リフレッシュ操作で自動リフレッシュされた行数。キャッシュ・グループに子表が存在する場合、ルート表および子表のすべての行が含まれます。 注意: 完全自動リフレッシュの場合、この情報は返されません。 |
528255 |
|
この自動リフレッシュ操作でOracleから転送されたバイト数。 注意: 完全自動リフレッシュの場合、この情報は返されません。 |
75464 |
|
この自動リフレッシュ操作で自動リフレッシュされたルート表の行数。 |
310 |
|
Oracleで自動リフレッシュ問合せの実行にかかった時間(ミリ秒)。 注意: 完全自動リフレッシュの場合、この情報は返されません。 |
110 |
|
自動リフレッシュ問合せでOracleからの行フェッチにかかった時間(ミリ秒)。 注意: 完全自動リフレッシュの場合、この情報は返されません。 |
6800 |
|
TimesTenで、更新された行をキャッシュ・グループに適用するのにかかった時間(ミリ秒)。 注意: 完全自動リフレッシュの場合、この情報は返されません。 |
1890912 |
|
キャッシュ・エージェントの起動後に自動リフレッシュされた行の総数。 注意: 完全自動リフレッシュの場合、この情報は返されません。 |
12439795 |
|
キャッシュ・エージェントの起動後にOracleから転送された総バイト数。 注意: 完全自動リフレッシュの場合、この情報は返されません。 注意: 完全自動リフレッシュの場合、この情報は返されません。 注意: 完全自動リフレッシュの場合、この情報は返されません。 |
1890912 |
|
キャッシュ・エージェントの起動後に自動リフレッシュされたルート表の行の総数。 |
160020 |
|
キャッシュ・エージェントの起動後の自動リフレッシュの総経過時間(ミリ秒)。 |
InProgress |
|
ステータス。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トラップは次のとおりです。
ttCacheAutoRefQueFullTrap
ttCacheIncAutoRefFailedTrap
ttCacheValidationErrorTrap
ttCacheValidationWarnTrap
ttCacheValidationAbortedTrap
『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップを使用した診断に関する説明を参照してください。
次の推奨事項を実行すると、IMDB Cacheのパフォーマンスを最適化できる場合があります。
注意: これらの推奨事項はどれも、パフォーマンス上のトレードオフがあるため、パフォーマンスを最適化できるとはかぎりません。ユーザー独自の構成環境に応じて、それぞれのパフォーマンス推奨事項を検討し、テストを実施してください。 |
ALTER TABLE
<table_name CACHE
文を実行し、Oracle Databaseに対して、IMDB Cacheメタ表およびキャッシュ・グループ実表がSGAバッファ・キャッシュのKEEP領域に格納される必要があることを示すことで、これらの表をSGAに配置します。SGAにIMDB Cache表を配置すると、リフレッシュが実行される場合にIMDB Cacheリフレッシュ操作に必要な任意のデータブロックをSGA内で利用できる可能性が高くなり、ディスク読取りは行われなくなる可能性が高くなります。これによって、TimesTenキャッシュのリフレッシュ操作時に実行される物理ディスク読取りの時間が最小になります。Oracleバッファ・キャッシュ管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のメモリーの構成と使用に関する説明を参照してください。
dbms_shared_pool.keep
プロシージャを使用して、共有プールにIMDB Cacheトリガーを配置します。キャッシュ・グループ実表を頻繁には更新しないアプリケーションの共有プールにトリガーを配置すると、トリガーが再ロードや再解析の必要性がなくなります。トリガーが頻繁に実行され、常に共有プールに存在しているような揮発性の高い表では、これを行う必要はありません。
パラレル問合せを有効化します。1000万以上の行を持つ大規模な実表の場合は、Oracle Databaseのパラレル問合せ機能の使用を検討してください。ログ表と実表の間で行う主結合問合せは、Oracle Databaseのパラレル問合せが処理されるように設計された問合せです。パラレル処理が有効な場合、パラレル問合せオプティマイザは、他のパラレル問合せのスレーブ・プロセスで同時に実行できるように元の問合せを分割できる問合せ計画を生成します。パラレル問合せを使用する際、ユーザーは、キャッシュ・グループ実表のデフォルトの並列度である(2*N)を割り当てる必要があります(「N」はマシンのCPUの数です)。次に、ユーザーの環境に最適な並列レベルを確認するための実験を行います。次に示すように様々な表構造の実表で試します。
表の作成時またはALTER TABLE PARALLEL
コマンドを使用して割り当てられるデフォルトの並列度を持つ標準的なヒープ表を使用します。表に対してNパーティションの主キー索引を構築します。
表の主キーまたは主キーの上位列(主キーが結合されている場合)のいずれかに基づいたパーティション・レンジ・キーを持つ、N通りにパーティション化された表構造を使用します。パーティションの数は、並列度に設定する必要があります。パーティションの数が同じローカル主キー索引を使用します。
ハッシュ・キーとして主キーを使用し、ローカルのパーティション化された主キー索引、および並列度と同じ索引パーティションと表パーティションの両方を持つ、N通りにハッシュされたパーティション構造を使用します。ログ表のカーディナリティは、パーティション化されたログ表にパフォーマンス上のメリットがもたらされるほど十分に大きくならないため、ログ表はパーティション化されている必要があります。さらに、ログ表の主キー列の値が増加し続けている場合、レンジ・パーティションは使用できません。
お客様は、増分自動リフレッシュを設定した読取り専用のキャッシュ・グループにキャッシュされているOracle表に対して、月末または年末に大規模なバッチ・ジョブを実行する場合があります。その場合、事前に予防策を行わないと、自動リフレッシュ操作やレプリケーションにパフォーマンスやメモリーの問題が発生する可能性があります。
この項で説明するタスクは、次のIMDB Cache構成のコンポーネントではサポートされません。
キャッシュ・グリッドにない読取り専用キャッシュ・グループまたはアクティブ・スタンドバイ・ペアによってレプリケートされていない読取り専用キャッシュ・グループ
キャッシュ・グリッド
アクティブ・スタンドバイ・ペア・レプリケーション
戻りサービスが指定されたアクティブ・スタンドバイ・ペア
障害時リカバリ・サブスクライバが指定されたアクティブ・スタンドバイ・ペア
物理的な同期Oracle Data Guard
Oracle RAC
キャッシュされたOracle表で大規模なバッチ・ジョブを実行する必要がある場合は、次のタスクを実行します。
バッチ・ジョブの影響を受けるAUTOREFRESH
属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSED
に設定します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。
ALTER CACHE GROUP sampecg SET AUTOREFRESH STATE PAUSED; COMMIT;
バッチ・ジョブの影響を直接受けないAUTOREFRESH
属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSED
に設定します。これにより、バッチ処理中のデータは一貫性のあるビューになります。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。
キャッシュされたOracle表でバッチ・ジョブを実行します。
すべての自動リフレッシュ変更ログ記録が有効なログ順序番号(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 ****************************
構成にアクティブ・スタンバイ・ペア・グリッド・メンバーが含まれている場合は、スタンバイの状態が、すべてのスタンバイ・ノードでPAUSED
に設定されていることを確認してください。ttIsql cachegroups
コマンドを使用します。
手順1で変更された各キャッシュ・グループについて、パラレル・モードでキャッシュ・グルーブを手動でリフレッシュします。トランザクション・サイズ(一度にコミットされる行数)および並列度に適切な値を選択します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。
REFRESH CACHE GROUP samplecg COMMIT EVERY n ROWS PARALLEL m; COMMIT;
この操作は、自動更新リフレッシュの状態を自動的にON
にリセットします。
手順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オブジェクトを再作成します。
問題のキャッシュ表があるすべてのデータベース上のすべてのキャッシュ・グループについて、ALTER CACHE GROUP
を使用して自動リフレッシュの状態をOFF
にリセットします。
ALTER CACHE GROUP cache_group_name SET AUTOREFRESH STATE OFF;
対象となるすべてのデータベース上のすべてのキャッシュ・エージェントを停止します。
キャッシュ・グループ内の各表について、ユーザー・カウントが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';
いずれかのキャッシュ・エージェントを起動します。そのキャッシュ・エージェントによって、クリーンアップ操作が実行されます。クリーンアップが終了すると、次のメッセージがサポート・ログに表示されます。
Cleanup of the Oracle objects completed
キャッシュ・エージェントによるクリーンアップが終了したら、ALTER CACHE GROUP
を使用して自動リフレッシュの状態をON
に戻します。
ALTER CACHE GROUP cache_group_name SET AUTOREFRESH STATE ON;
他のすべてのキャッシュ・エージェントを起動します。
すべてのデータベース上の問題のキャッシュ・グループすべてについて、ALTER CACHE GROUP
を使用して自動リフレッシュの状態をON
にリセットします。
増分自動リフレッシュが進行していない場合は、次のことを確認します。
自動リフレッシュの状態がON
になっているかどうか
キャッシュ・エージェントが稼働しているかどうか
サポート・ログで、次の表に記載されている状態を調べます。
最初のヘッダー・セルに表の概要が示されています。
状態 | 対処 |
---|---|
Oracleサーバーの接続エラーまたは警告 | 接続の問題の解決の詳細は、「クライアント/サーバーの問題のトラブルシューティング」を参照。 |
TimesTenでのロック・タイムアウト・エラーまたは警告 | このことは、通常、キャッシュ・グループに対するオープンなDDLトランザクションが原因で発生する。自動リフレッシュが必要なロックを取得できるようにDDLトランザクションをコミットする。 |
TimesTenでの不十分な永続データ・パーティション・エラー | PermSize の値を大きくする。 |
自動リフレッシュOracleオブジェクトの検証エラーまたは警告 | 「自動リフレッシュOracleオブジェクトをリカバリしてリセットする」を参照。 |
キャッシュ・エージェントが予期せず終了する | テクニカル・サポートに連絡する。 |
メイン・デーモン・ディレクトリ内にコア・ファイルがある | テクニカル・サポートに連絡する。 |
増分自動リフレッシュが完全リフレッシュになることに関する警告 | 「増分自動リフレッシュが完全自動リフレッシュになる」を参照。 |
自動リフレッシュが長時間経っても完了しないことを示す警告 | 前回の自動リフレッシュ以降に数多くのトランザクションが発生した場合は、自動リフレッシュ・トランザクションに長時間かかることがある。
注意: 同じ自動リフレッシュ間隔を持つキャッシュ・グループは、1つのトランザクションで自動リフレッシュされる。 |
キャッシュ・エージェントは、自動リフレッシュが進行できるように、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のままになっていないかどうかを確認します。
大規模な自動リフレッシュ操作が行われる可能性のある要因は、次のとおりです。
レスポンスがないTimesTenデータベースまたは停止したTimesTenデータベースによる自動リフレッシュのパフォーマンスの低下
自動リフレッシュ間隔が大きい
同じ時間隔で処理されるキャッシュ・グループの数が多い
Oracle表に対する変更の頻度が高い
キャッシュ・グループに含まれる子表の世代の数
キャッシュされたOracle表の行数
キャッシュされたOracle表の行のサイズ
AUTOREFRESH
トレースを有効にして、自動リフレッシュのパフォーマンス問題を診断します。詳細は、「AUTOREFRESHトレース」を参照してください。
注意: TimesTenキャッシュ・グループの自動リカバリは、AUTOREFRESH キャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループにのみ適用されます。この項で対象としている自動リフレッシュ・キャッシュ・グループはすべて、AUTOREFRESH キャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループを指しています。 |
自動リフレッシュ・キャッシュ・グループを含んでいるすべてのTimesTenデータベースが破棄されているか、または使用されていない場合でも、TimesTenはキャッシュ・エージェントが実行されていないTimesTenデータベースに対して、Oracle表への自動リフレッシュによる変更の追跡を続行します。これによって、アクティブなTimesTenのデータベース内のキャッシュ・グループへの自動リフレッシュが遅くなります。
キャッシュ・エージェントは、データベースからのレスポンスがない状態かどうか、またはデータベースが使用されていない状態かどうかの検出を行います。停止したTimesTenデータベースのリカバリを行うかどうか、および行う場合の方法を指定できます。ただし、すべてのOracleオブジェクトが削除されている場合、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とマークします。スタンドバイ・マスター・データベースに対して |
None |
Dead |
Alive |
|
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
を手動で変更する方法の詳細を説明しています。
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
****************************
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);
この表の索引の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管理者ガイド』を参照してください。
変更ログ表を再構築します。
無駄な領域がないか確認します。
Oracle DatabaseにcacheInfo.sql
スクリプトを実行して、変更ログ表の名前を確認します。
変更ログ表のサイズを計算します。結果Aをコールします。この例では、変更ログ表の名前を適合させます。
SELECT table_name, ROUND((BLOCKS*8),2)||'KB' "size" FROM user_tables WHERE table_name LIKE 'TT_05_%_L";
変更ログ表のデータのサイズを計算します。結果Bをコールします。この例では、変更ログ表の名前を適合させます。
SELECT table_name, ROUND((num_rows*avg_row_length/1024),2)|| 'KB' "size" FROM user_tables WHERE table_name LIKE 'TT_05_%_L';
(B/A)*100が50パーセントより大きい場合、少なくとも40パーセントの領域が無駄になっています(PCTFREE
ストレージ・パラメータが10に設定されていると仮定)。少なくとも40パーセントの領域が無駄になっている場合、変更ログ表の断片化が推奨されます。
変更ログ表を断片化するには、次の手順を実行します。
自動リフレッシュの状態をPAUSED
に設定するようキャッシュ・グループを変更します。
変更ログ表の行を一時表にコピーします。
変更ログ表を切り捨てます。
一時表から変更ログ表に行を挿入します。
自動リフレッシュの状態をON
に設定するようキャッシュ・グループを変更します。
ログ表や実表の大規模なエントリーに対して数百ミリセカンドのような比較的短いリフレッシュ間隔を使用すると、キャッシュ・リフレッシュ操作は、予定されている次のリフレッシュ操作が開始するまでに完了しません。このような場合、現在の自動リフレッシュ・サイクルが終了すると、ログ表のエントリーのマークが解除されます。
このように、行にマークが付けられる時までに、同一の行を実表から次の自動リフレッシュ・サイクルのキャッシュ・グループにリフレッシュすることができます。リフレッシュにかかる時間がリフレッシュ間隔よりも大きくなっているか確認してください。リフレッシュ間隔を、冗長なリフレッシュが起きないような値に設定します。
キャッシュ・グループを作成する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
状態に有効化します。
主キー列に対して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
主キー列に対して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
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;