| Oracle® TimesTen In-Memory Databaseトラブルシューティング・ガイド リリース18.1 E98632-04 |
|
 前 |
 次 |
この章の次の項は、TimesTen Application-Tier Database Cache (TimesTen Cache)の使用時に発生する可能性があるいくつかの問題の解決方法について説明します。
AWTキャッシュ・グループで問題が発生している場合は、第5章「AWTキャッシュ・グループのトラブルシューティング」を参照してください。
|
ノート: この章の例で示すとおり、キャッシュ・エージェント・デーモンからのエラー・ログは、CACでメッセージ内に指定されます。ttDaemonLogユーティリティのCACHEコンポーネントを無効化しないかぎり、これらのメッセージは有効です。WindowsおよびLinuxまたはUNIXシステムのttDaemonLogオプションの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttDaemonLogを参照してください。 |
この項では、CREATE CACHE GROUP文の実行時に発生する可能性がある問題について説明します。
| 考えられる原因 | 対処 |
|---|---|
| ユーザーが、キャッシュ・グループ・タイプを作成するための正しいOracle Database権限を持っていない。 | 「Oracle Database権限を確認する」を参照してください。 |
| ユーザーがデータベースにアクセスする十分な権限を持っていない。 | キャッシュ・グループを作成するには、CACHE_MANAGER権限が必要です。 |
| 内部/外部ユーザーがOracle Databaseユーザーと一致しない | TimesTenと、Oracle Databaseは、同一のユーザー名を指定する必要があります。 |
| Oracle Databaseに接続できない | 次の項を参照してください。
ネットワーク・ステータスを確認する。 |
| キャッシュ管理ユーザーのIDまたはパスワードが設定されていない(AWTまたは自動リフレッシュ・キャッシュ・グループを作成しようとした場合) | 「キャッシュ管理ユーザーの名前およびパスワードを設定する」を参照してください。 |
| データ型マッピングがサポートされていない。 | 「サポートされていないデータ型マッピング」を参照してください。 |
| Oracle DatabaseでのNULL値可能設定が異なる。 | 「Null制約がOracle Databaseと一致しない」を参照してください。 |
| ルート表の主キーが指定されていない | キャッシュ・グループのルート表には、主キーが必要です。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・グループの定義に関する説明を参照してください。 |
この項では、キャッシュ・エージェントの起動時または停止時に発生する可能性がある問題について説明します。
| 考えられる原因 | 対処 |
|---|---|
| キャッシュ・エージェントがすでに稼働している。 | 後述の「キャッシュ・エージェントのステータスを確認する」を参照してください。 |
| Oracle Databaseライブラリが見つからない。 |
|
ORACLE_HOMEが無効。 |
後述の「ORACLE_HOME環境変数を確認する」を参照してください。 |
| 権限が十分ではない。 | キャッシュ・エージェントを起動または停止するには、CACHE_MANAGER権限が必要です。 |
OracleNetServiceNameが正しくない。 |
DSN定義に設定したOracleNetServiceNameが、TimesTenでキャッシュする表が含まれるOracle DatabaseインスタンスのOracleサービス名と一致することを確認します。 |
キャッシュ・エージェントのステータスは、ttStatusユーティリティ(「ttStatusユーティリティの使用」を参照)を使用して確認します。
キャッシュ・エージェントが実行されていない場合は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する項を参照して、キャッシュ・エージェントを起動します。キャッシュ・エージェントを起動できない場合は、考えられる原因を調査し、システムを再起動してからキャッシュ・エージェントを起動してください。
LinuxおよびUNIXシステムでは、キャッシュ・エージェントおよびTimesTenデーモンを起動しているシェルにORACLE_HOME環境変数が正しく設定されていることを確認します。
詳細は、Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドの環境変数を参照してください。
サービス名が解決できなかったことを示すエラーORA-12514を受け取った場合は、次の内容を確認します。
Oracle Database TNSPINGユーティリティを使用して、サービスが到達可能であることを確認します。
DSN定義に設定したOracleNetServiceNameが、TimesTenでキャッシュする表が含まれるOracle DatabaseインスタンスのOracleサービス名と一致することを確認します。
定義したサービス名が存在することを確認します。Windows Oracleクライアントの場合は、Oracle Net Configuration Assistantを使用してサービス名を構成します。Oracle Net Configuration Assistantで、「Oracle Net Configuration」→「Local」→「Service Naming」に進み、使用するOracle Databaseサーバーを選択して、サーバー名またはOracle Databaseサーバーを特定するSIDが存在するかどうか確認します。サービス名を追加または変更した場合は、再起動する必要があります。
Oracle Databaseのキャッシュ管理ユーザーの名前およびパスワードでSQL*Plusを使用して、サービス名が正しいかどうか確認します。次に例を示します。
%sqlplus cache_admin_user/cache_admin_pwd@OracleHost
ここで、cache_admin_userはキャッシュ管理ユーザーのユーザー名、cache_admin_pwdはキャッシュ管理ユーザーのパスワード、OracleHostはDSN定義で指定されているOracleNetServiceNameです。
|
ノート: 使用するキャッシュ管理ユーザーが、通常のOracle databaseユーザーと異なる場合があります。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseでのユーザーの作成に関する説明を参照してください。 |
TimesTenシステムに、単一のtnsnames.oraのコピーのみがあることを確認します。また、tnsnames.oraに対する権限も確認します。
TimesTenをLinuxまたはUNIXシステムで実行する場合、ORACLE_HOME環境変数が正しく定義されていることを確認します。次に例を示します。
ORACLE_HOME=/products/oracle11g
Oracle Databaseクライアントおよびサーバーのバージョンを確認します。後述の、「Oracle Databaseサーバーおよびクライアントのバージョンに互換性がない」を参照してください。
データベースへの接続試行時に、ORA-12154「TNS: 指定された接続識別子を解決できませんでした。」というエラーを受け取る場合があります。
これは、TimesTen CacheおよびOracle Databaseを同一のシステムで使用し、TNS_ADMIN環境変数がOracle Databaseの正しいtnsnames.oraファイルを指していない場合に発生します。たとえば、ラップトップでOracle Databaseの複数のインスタンスが稼働している場合に、この問題が発生することがあります。
本番環境では、TimesTenとOracle Databaseは、通常、異なるシステム上で稼働させます。この場合、TimesTenが稼働するシステム上のtnsnames.oraファイルを指すようにするために、TNS_ADMIN環境変数をリセットしないでください。Oracle Databaseクライアントは、接続の解決にTNS_ADMIN設定を使用しますが、TimesTenのメイン・デーモン、キャッシュ・エージェント、Webサーバーおよびレプリケーション・エージェントは、TNS_ADMIN設定を認識しません。TimesTen Cacheは、Oracle DatabaseクライアントとTimesTenが異なるtnsnames.oraファイルを使用する場合、正常に動作しません。
Windowsの場合、TNS_ADMIN環境変数は次のように設定します。
「マイ コンピュータ」を右クリックし、「プロパティ」を選択します。
「詳細設定」タブで、「環境変数」を選択します。
使用するtnsnames.oraファイルが格納されているディレクトリを指すようにTNS_ADMINをシステム環境変数として追加または編集します。INAMEコマンドを使用して、tnsnames.oraファイル内に他のtnsnames.oraファイルを組み込むことができます。
ORA-12170またはORA-12535などの接続タイムアウト・エラー、またはORA-03134 (サーバー・バージョンがサポートされていません)を受け取った場合、互換性のあるOracle DatabaseクライアントとOracle Databaseサーバー・バージョンを使用していることを確認します。
この項では、Oracle Databaseユーザー名およびパスワードの使用時に発生する可能性がある問題について説明します。
| 考えられる原因 | 参照先 |
|---|---|
| ライブラリ環境変数が正しく設定されていない。 | 後述の「ライブラリ・パス環境変数を確認する」 |
| Oracle Databaseプロセスが稼働していない。 | 後述の「TNSリスナーおよびOracle Database Serverのステータスを確認する」 |
| ユーザーが、正しいOracle Database権限を持っていない。 | 後述の「Oracle Database権限を確認する」 |
| DSNの定義が正しくない。 | 「DSN定義を確認する」 |
| キャッシュ管理ユーザーのIDまたはパスワードに問題がある。 | 「キャッシュ管理ユーザーの名前およびパスワードを設定する」 |
| ユーザー環境とシステム環境の整合性がとれていない。 | 「ユーザー環境とシステム環境を確認する」 |
| 動的ライブラリがロードされていない。 | 「ロードされた動的ライブラリを検証する」 |
使用しているプラットフォームのライブラリ・パス環境変数を確認します。
| プラットフォーム | 確認する変数 |
|---|---|
| LinuxまたはUNIX | LD_LIBRARY_PATH |
| Windows | PATH |
SQL*Plusを使用してOracle Databaseに接続するか、またはOracle Enterprise Managerを使用してステータスを確認します。
次を入力して、付与されている現在のOracle Database権限の一覧を、Oracle SQL*Plusコマンド・プロンプトから表示します。
SELECT * FROM SESSION_ROLES; SELECT * FROM SESSION_PRIVS;
一覧表示された権限を、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseユーザーへの権限の付与に関する説明の中で指定されている、TimesTen Cache操作に必要な各権限と比較します。追加の権限が必要な場合は、Oracle Database管理者に連絡してください。
『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle DatabaseからデータをキャッシュするTimesTenデータベースのDSNに関する説明の例などを参照して、DSN属性が正しく設定されていることを確認します。
TimesTen CacheのDSN定義がシステムDSNであることを確認します。
TimesTen CacheのDSNが1回のみ定義されていることを確認します。
Oracle Databaseユーザー名およびパスワードを確認します。SQL*Plusを使用し、DSN定義で使用しているものと同じOracleNetServiceNameとOraclePWDを使用してOracle Databaseに接続し、それらが正しいことを確認します。
Oracle Databaseクライアントのインストール後に、システムを再起動していない場合、TimesTenデーモンはOracle Databaseクライアントをインストールする前の「古い」環境下で稼働しています。システムを再起動すると、TimesTenは「新しい」環境下で開始されます。
キャッシュ管理ユーザーの名前とパスワードは、TimesTenデータベースに1回のみ設定する必要があります。ただし、TimesTenデータベースが破棄されて再作成された場合、またはOracle Databaseでキャッシュ管理ユーザーの名前が削除されて再作成された場合は、変更する必要があります。
TimesTenデータベースでキャッシュ・エージェントを実行している場合、またはデータベース内にキャッシュ・グループが存在する場合は、キャッシュ管理ユーザーの名前およびパスワードを変更できません。キャッシュ管理ユーザーの名前およびパスワードを変更する前に、キャッシュ・グループを削除する必要があります。また、キャッシュ管理ユーザーの名前およびパスワードを変更する前に、キャッシュ・エージェントを停止し、ユーザー名およびパスワードを変更した後でキャッシュ・エージェントを再起動する必要があります。
ttIsqlセッションから、キャッシュ・マネージャ・ユーザーとしてデータベースに接続し、ttCacheUidPwdSet組込みプロシージャをコールして、次のようにOracle Databaseキャッシュ管理ユーザーの名前とパスワードを設定します。
Command> call ttCacheUidPwdSet('cacheuser','oracle');
エラーが戻される場合、Oracle Database ID、キャッシュ管理ユーザーIDおよびキャッシュ管理パスワードを確認します。加えて、Oracle Databaseインスタンスが稼働しているかどうか確認します。
また、ttAdmin -cacheUidPwdSetユーティリティ・コマンドを、CACHE_MANAGERを持つTimesTen外部ユーザーとして実行して、ユーザー名およびパスワードを設定することもできます。
% ttAdmin -cacheUidPwdSet -cacheUid cacheuser -cachePwd oracle cachealone1
-cachePwdオプションを指定しなかった場合、ttAdminユーティリティによってキャッシュ管理ユーザーのパスワードを入力するように求められます。ユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。
問題の原因が、ユーザー環境とシステム環境の相違によるかどうかを確認するテストを行います。この手順では、2つのセッション・ウィンドウ(Windowsのコマンド・プロンプト・ウィンドウあるいはLinuxまたはUNIXのシェル・ウィンドウ)が必要です。
TimesTenデーモンを停止します。
一方のセッション・ウィンドウで、通常のユーザーとしてTimesTenデーモンを起動します。
Windowsの場合:
% timesten_home/install/srv/ttsrv181.exe -d -verbose
LinuxまたはUNIXの場合:
% timesten_home/install/srv/timestend -d verbose
いくつかのメッセージが一瞬表示され、待機状態になります。
もう1つのセッション・ウィンドウで、キャッシュ・エージェントを再起動してみます。
ステップ3が成功したら、Windowsの場合は[Ctrl]+[C]、LinuxまたはUNIXの場合はkillコマンドを使用して、ステップ2で1つ目のセッションで起動したTimesTenデーモンを停止します。
ユーザー環境およびシステム環境を比較します。たとえば、ユーザーとシステムはどちらも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タスク・マネージャを開いて、プロセスttora181.exeを見つけたら強調表示します。強調表示したプロセスを右クリックして、「デバッグ」を選択します。これにより、Visual C++が起動し、「Oracleサービス名を解決できない」で説明されているように、デバッグ・ウィンドウにロードされたDLLが表示されます。
キャッシュ・グループをロードして、キャッシュ・エージェントとのキャッシュ接続を強制します。
Command> load cache group cg1 commit every 100 rows;
デバッグ・ウィンドウでロードされたDLLを確認します。
Oracle Databaseへの接続が必要な操作で、エラー5105「OCI initialization failed」が発生することがあります。たとえば、次の状況で発生します。
キャッシュ・エージェントの起動時
キャッシュ管理ユーザーのIDまたはパスワードの設定時
TimesTenでのSQL文の入力時(autocommit=0、PassThrough=3の場合)
エラー5105には、エラーの原因に関する追加情報が含まれています。
OCIでOracle Databaseライブラリが見つからない。「ライブラリ・パス環境変数を確認する」を参照して、エラー・メッセージに示されたライブラリに対する権限を確認してください。
ORACLE_HOMEが無効。「ORACLE_HOME環境変数を確認する」を参照してください。
NLS環境変数は、TimesTenアプリケーションが稼働している環境に設定されます。TimesTenでNLS環境変数を使用しているかどうか、確認します。
キャッシュ・グループを作成しようとすると、次のエラーが表示されることがあります。
5115: Unsupported type mapping for column name
たとえば、Oracle Database上の表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 TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキー列で許可されるデータ型マッピングに関する説明を参照してください。
キャッシュ・グループを作成しようとすると、次の警告が表示されることがあります。
Warning 5119: Column name has different nullability setting in Oracle
たとえば、Oracle Database上の表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 Database上のcol2にはNULL制約を持たず、キャッシュ・グループのcol2はNOT NULLと定義されているため、警告5119が表示されます。
TimesTenにキャッシュされたOracle Database表へのDDL操作のため、キャッシュ・グループで障害が発生する可能性があります。たとえば、ユーザーがTimesTenにキャッシュされているOracle Database表上の列を削除する場合です。キャッシュ・グループが伝播またはフラッシュされると、TimesTenはOracle Database表にすでに存在していない列を更新することになります。キャッシュ・グループがロードまたはリフレッシュされると、TimesTenは削除された列からデータの取得を試行することになります。
次のキャッシュ・グループ操作は失敗する可能性があります。
自動リフレッシュは発生しません。
AWTキャッシュ・グループ操作は、Oracle Databaseから伝播またはリフレッシュされることも、Oracle Databaseへ伝播またはリフレッシュされることもありません。
キャッシュ・グループのロードまたは伝播は失敗します。
Oracle Database実表に対してDDL操作が行われたため、キャッシュ・グループ操作が適切に実行されていない可能性がある場合は、DDL追跡を使用して問題を診断します。DDL追跡では、キャッシュされたすべてのOracle Database表の変更履歴が保存されます。SQL文およびその実行日時は、Oracle Databaseのキャッシュ管理ユーザー・スキーマ内のTimesTen表にそれぞれ書き込まれます。
DDL追跡オブジェクトの作成方法や、Oracle Database内の実表に対してDDL追跡を有効にする方法の詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュされたOracle Database表に対して発行されたDDL文の追跡に関する説明を参照してください。DDL追跡の有効化または無効化に使用される組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheDDLTrackingConfigに関する説明を参照してください。
キャッシュ・グループ内のオブジェクトを変更した後に変更が後続のSQL文に表示されない場合は、次のいずれかの問題が発生した可能性があります。
そのオブジェクトが、Oracle Databaseから削除されたか、またはなんらかの原因で破損された。
Oracle Databaseが、そのオブジェクトの作成時より前の時点までリストアまたはリカバリされた。
Oracle Databaseが停止した。
キャッシュ・グループを作成したOracle Database以外のOracle Databaseにポイントするキャッシュ・グループを作成した後に、ユーザーがOracleNetServiceName DSNまたは接続属性を変更した。
たとえば、ユーザーがAWTキャッシュ・グループを作成したとします。その後、このユーザーは表に行を追加しました。このユーザーが表に対してSELECT * FROMを実行すると、それらの行が表示されませんでした。ttmesg.logエラー・ファイルには、Oracle Databaseを使用できないというエラーは表示されていません。かわりに、次のメッセージが表示されています。
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(ゼロ)に設定されます。
例3-1 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.
表3-1に、最初の行の出力の結果を示します。
表3-1 最後の自動リフレッシュ操作でのttCacheAutorefreshStatsGetの結果
| 結果 | フィールド名 | 説明 |
|---|---|---|
1164260 |
|
キャッシュ・グループID。 |
2007-07-23 15:43:52.000000 |
|
この時間隔で自動リフレッシュが開始された時間のタイムスタンプ。 |
850280 |
|
この時間隔で自動リフレッシュ・トランザクションが開始された時点でのキャッシュ・エージェントの経過時間(ミリ秒) この値は累積され、キャッシュ・エージェント・プロセスが開始されるとリセットされます。 |
44 |
|
自動リフレッシュ番号。 |
0 |
|
この自動リフレッシュ操作にかかった時間(ミリ秒) 操作は現在進行中であるため、値は0(ゼロ)です。 |
75464 |
|
この自動リフレッシュ操作で自動リフレッシュされた行数 キャッシュ・グループに子表が存在する場合、ルート表および子表のすべての行が含まれます。 ノート: 完全自動リフレッシュの場合、この情報は返されません。 |
528255 |
|
この自動リフレッシュ操作でOracle Databaseから転送されたバイト数 ノート: 完全自動リフレッシュの場合、この情報は返されません。 |
75464 |
|
この自動リフレッシュ操作で自動リフレッシュされたルート表の行数 |
310 |
|
Oracle Databaseで自動リフレッシュ問合せの実行にかかった時間(ミリ秒) ノート: 完全自動リフレッシュの場合、この情報は返されません。 |
110 |
|
自動リフレッシュ問合せでOracle Databaseからの行フェッチにかかった時間(ミリ秒) ノート: 完全自動リフレッシュの場合、この情報は返されません。 |
6800 |
|
TimesTenで、更新された行をキャッシュ・グループに適用するのにかかった時間(ミリ秒) ノート: 完全自動リフレッシュの場合、この情報は返されません。 |
1890912 |
|
キャッシュ・エージェントの起動後に自動リフレッシュされた行の総数 ノート: 完全自動リフレッシュの場合、この情報は返されません。 |
12439795 |
|
キャッシュ・エージェントの起動後にOracle Databaseから転送された総バイト数 ノート: 完全自動リフレッシュの場合、この情報は返されません。 |
1890912 |
|
キャッシュ・エージェントの起動後に自動リフレッシュされたルート表の行の総数 |
160020 |
|
キャッシュ・エージェントの起動後の自動リフレッシュの総経過時間(ミリ秒) |
InProgress |
|
ステータス ステータスは、 |
この例では子表がないため、自動リフレッシュされた行の総数(1890912)は、自動リフレッシュされたルート表の行の総数と同じになります。
Oracle Databaseで更新される行数が、TimesTenで自動リフレッシュされる行数に反映されるとはかぎりません。Oracle Databaseの更新がTimesTenで複数回適用されたり、Oracle Databaseの同じ行への複数の更新がTimesTenでは1回の更新として適用される場合もあります。
TimesTenには、Oracle Databaseに存在する変更ログ表から、自動リフレッシュ・キャッシュ・グループの情報を収集するcacheInfo SQLスクリプトが用意されています。変更ログ表の詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseオブジェクトのキャッシュ環境の管理に関する項を参照してください。
SQL*Plusを使用して、Oracle Databaseでキャッシュ管理ユーザーとしてスクリプトを実行します。別のユーザーとしてスクリプトを実行すると、変更ログ表が存在しないことがレポートされます。
timesten_home/install/oraclescripts/cacheInfo.sql
cacheInfoスクリプトでは、キャッシュされた各表について次の情報が表示されます。
% cd timesten_home/install/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の出力に表示された番号の自動リフレッシュ操作に関連するメッセージをサポート・ログで確認します。自動リフレッシュ操作の開始後に発生したエラーがないかどうかを探します。
例3-2 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のトレース処理は、アプリケーションのパフォーマンスに大きく影響し、大量のファイル・システム領域を消費します。診断が終了したら、トレースをデフォルト値にリセットしてください。
また、自動リフレッシュが機能している場合と機能していない場合の自動ワークロード・リポジトリ(AWR)レポートを比較することもお薦めします。
次の推奨事項を実行すると、TimesTen Cacheのパフォーマンスを最適化できる場合があります。
|
ノート: これらの推奨事項はどれも、パフォーマンス上のトレードオフがあるため、パフォーマンスを最適化できるとはかぎりません。ユーザー独自の構成環境に応じて、それぞれのパフォーマンス推奨事項を検討し、テストを実施してください。 |
ALTER TABLE table_name CACHE文を実行し、Oracle Databaseに対して、TimesTen Cacheメタ表およびキャッシュ・グループ実表がSGAバッファ・キャッシュのKEEP領域に格納される必要があることを示すことで、これらの表をSGAに配置します。SGAにTimesTen Cache表を配置すると、リフレッシュが実行される場合にTimesTen Cacheリフレッシュ操作に必要な任意のデータブロックをSGA内で利用できる可能性が高くなり、ファイル・システムの読取りは行われなくなる可能性が高くなります。これによって、TimesTenキャッシュのリフレッシュ操作時に実行される物理ファイル・システムの読取りの時間が最小になります。
dbms_shared_pool.keepプロシージャを使用して、共有プールにTimesTen Cacheトリガーを配置します。キャッシュ・グループ実表を頻繁には更新しないアプリケーションの共有プールにトリガーを配置すると、トリガーが再ロードや再解析の必要性がなくなります。トリガーが頻繁に実行され、常に共有プールに存在しているような揮発性の高い表では、これを行う必要はありません。
パラレル問合せを有効化します。1000万以上の行を持つ大規模な実表の場合は、Oracle Databaseのパラレル問合せ機能の使用を検討してください。ログ表と実表の間で行う主結合問合せは、Oracle Databaseのパラレル問合せが処理されるように設計された問合せです。パラレル処理が有効な場合、パラレル問合せオプティマイザは、他のパラレル問合せのワーカー・プロセスで同時に実行できるように元の問合せを分割できる問合せ計画を生成します。パラレル問合せを使用する際、ユーザーは、キャッシュ・グループ実表のデフォルトの並列度である(2*N)を割り当てる必要があります(「N」はシステムのCPUの数です)。次に、ユーザーの環境に最適な並列レベルを確認するための実験を行います。次に示すように様々な表構造の実表で試します。
表の作成時またはALTER TABLE PARALLELコマンドを使用して割り当てられるデフォルトの並列度を持つ標準的なヒープ表を使用します。表に対してNパーティションの主キー索引を構築します。
表の主キーまたは主キーの上位列(主キーが結合されている場合)のいずれかに基づいたパーティション・レンジ・キーを持つ、N通りにパーティション化された表構造を使用します。パーティションの数は、並列度に設定する必要があります。パーティションの数が同じローカル主キー索引を使用します。
ハッシュ・キーとして主キーを使用し、ローカルのパーティション化された主キー索引、および並列度と同じ索引パーティションと表パーティションの両方を持つ、N通りにハッシュされたパーティション構造を使用します。ログ表のカーディナリティは、パーティション化されたログ表にパフォーマンス上のメリットがもたらされるほど十分に大きくならないため、ログ表はパーティション化されている必要があります。さらに、ログ表の主キー列の値が増加し続けている場合、レンジ・パーティションは使用できません。
お客様は、増分自動リフレッシュを設定した読取り専用のキャッシュ・グループにキャッシュされているOracle Database表に対して、月末または年末に大規模なバッチ・ジョブを実行する場合があります。その場合、事前に予防策を行わないと、自動リフレッシュ操作やレプリケーションにパフォーマンスやメモリーの問題が発生する可能性があります。
この項で説明するタスクは、次のTimesTen Cache構成のコンポーネントではサポートされません。
アクティブ・スタンドバイ・ペア・レプリケーション
戻りサービスが指定されたアクティブ・スタンドバイ・ペア
障害時リカバリ・サブスクライバが指定されたアクティブ・スタンドバイ・ペア
物理的な同期Oracle Data Guard
Oracle RAC
キャッシュされたOracle Database表で大規模なバッチ・ジョブを実行する必要がある場合、次のタスクを実行します。
バッチ・ジョブの影響を受けるAUTOREFRESH属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSEDに設定します。
バッチ・ジョブの影響を直接受けないAUTOREFRESH属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSEDに設定します。これにより、バッチ処理中のデータは一貫性のあるビューになります。
キャッシュされたOracle Database表でバッチ・ジョブを実行します。
すべての自動リフレッシュ変更ログ記録が有効なログ順序番号(logseq)に割り当てられていることを確認します。cacheInfo.sqlスクリプトをコールします。
% cd timesten_home/install/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 ****************************
ステップ1で変更された各キャッシュ・グループについて、パラレル・モードでキャッシュ・グルーブを手動でリフレッシュします。トランザクション・サイズ(一度にコミットされる行数)および並列度に適切な値を選択します。次に例を示します。
REFRESH CACHE GROUP samplecg COMMIT EVERY n ROWS PARALLEL m; COMMIT;
この操作は、自動更新リフレッシュの状態を自動的にONにリセットします。
ステップ2で変更された各キャッシュ・グループについて、自動リフレッシュの状態をONに設定します。次に例を示します。
ALTER CACHE GROUP sampecg2 SET AUTOREFRESH ON; COMMIT;
自動リフレッシュの問題について、考えられる原因を次の表に示します。
| 考えられる原因 | 対処 |
|---|---|
| キャッシュ・エージェントがキャッシュ管理ユーザーによって起動されていない。 | 『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する項を参照して、キャッシュ・エージェントの起動時に、キャッシュ管理ユーザーIDおよびパスワードを指定する。『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheStartに関する項および『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenデータベースでのキャッシュ管理ユーザー名およびパスワードの設定に関する項も参照。 |
| 実表のオブジェクトIDが変更された | 後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。 |
| 自動リフレッシュ・トリガーが有効でない。 | 後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。 |
TT_version_USER_COUNT表に記録されている現在のログ順序番号が、自動リフレッシュ・ログ表の最大ログ順序番号より小さい。 |
後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。 |
TT_version_USER_COUNT表に、すべてのアクティブな自動リフレッシュ表に対してusercount > 0である行がない。 |
後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。 |
| 変更ログ表が空である | 後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。 |
ユーザー・カウントが0(ゼロ)未満か、またはTT_version_USER_COUNTログ順序が異常である。 |
後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。 |
| キャッシュされた表に関連付けられている自動リフレッシュ・ログ表、トリガーまたは順序が存在しないか、有効でない | キャッシュ・エージェントが、正しいキャッシュ管理ユーザーIDで起動されたかどうかを確認する。キャッシュ管理ユーザーIDが正しい場合は、後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」の手順に従う。
ユーザー・エラー・ログで、致命的な異常についてのメッセージを確認する。これには、Oracle Databaseオブジェクトの破損または欠落が示されている。 |
TT_version_USER_COUNT表がない |
キャッシュ・エージェントが、正しいキャッシュ管理ユーザーIDで起動されたかどうかを確認する。キャッシュ管理ユーザーIDが正しい場合は、後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」の手順に従う。
ユーザー・エラー・ログで、致命的な異常についてのメッセージを確認する。これには、Oracle Databaseオブジェクトの破損または欠落が示されている。 |
TT_version_USER_COUNT表に記録されている現在のログ順序番号が変更され、ブックマークと異なり、関連付けられているキャッシュ表が次にコミットされる自動リフレッシュでリフレッシュされない。 |
キャッシュ・エージェントを再起動する。問題が解決されない場合は、後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」の手順に従う。 |
| 自動リフレッシュのモード、状態または間隔を変更した時に、自動リフレッシュが同時に実行された場合、同一の表がそれぞれのアクションにより変更されるため、ロック・タイムアウトが発生する可能性がある。 | 自動リフレッシュのモード、状態または間隔を変更する前に、キャッシュ・エージェントを停止する。「自動リフレッシュ・モード、状態または間隔の変更時にロック・タイムアウト状態を回避する」を参照。 |
| リソースに問題がある。 | キャッシュ・エージェントを再起動する。 |
増分自動リフレッシュは、Oracle Database実表でTRUNCATE文が使用されている場合は、正しく動作しません。Oracle Database実表でTRUNCATEが使用されている場合は、ALTER CACHE GROUP文を使用して自動リフレッシュをリセットし、自動リフレッシュの状態をOFFに設定してから、別のALTER CACHE GROUPで自動リフレッシュの状態をONに戻します。
自動リフレッシュで使用するOracle Databaseオブジェクトが問題の原因と特定できる、または可能性がある場合、次の手順を実行してOracle Databaseオブジェクトを再作成します。
問題のキャッシュ表があるすべてのデータベース上のすべてのキャッシュ・グループについて、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にリセットします。
ALTER CACHE GROUP文を使用して自動リフレッシュのモード、状態または間隔を変更するのと同時に、スケジュール済自動リフレッシュが開始されると(自動リフレッシュ間隔によるスケジュール)、ロック・タイムアウトが発生する場合があります。
自動リフレッシュは、キャッシュ表およびSYS.CACHE_GROUP表内の行をロックします。
ALTER CACHE GROUP SET AUTOREFRESH文が、SYS.CACHE_GROUP表内のキャッシュ・グル・ステートを更新します。
これにより、次のエラーが発生します。
Error TT6003: Lock request denied because of time-out.
次の回避策を実行します。
ttLockWait組込みプロシージャを使用して、ロック・タイムアウトを増加します。
ALTER CACHE GROUP SET AUTOREFRESH文を実行して、自動リフレッシュのモード、状態または間隔を変更する前に、キャッシュ・エージェントを停止します。次の例では、自動リフレッシュ状態を停止する設定を説明します。
キャッシュ・エージェントを停止します。
Command> call ttCacheStop;
自動リフレッシュ状態を、目的の状態に変更します。この例では、自動リフレッシュ状態を停止するように設定します。
Command> ALTER CACHE GROUP new_customers SET AUTOREFRESH STATE PAUSED;
キャッシュ・エージェントを起動します。
Command> call ttCacheStart;
ALTER CACHE GROUPの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER CACHE GROUPに関する説明を参照してください。ttLockWait組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttLockWaitに関する項を参照してください。
増分自動リフレッシュが進行していない場合は、次のことを確認します。
自動リフレッシュの状態がONになっているかどうか。
キャッシュ・エージェントが稼働しているかどうか。
サポート・ログで、次の表に記載されている状態を調べます。
最初のヘッダー・セルに表の概要が示されています。
| 状態 | 対処 |
|---|---|
| Oracle Databaseサーバー接続エラーまたは警告 | 接続の問題の解決の詳細は、「クライアント/サーバーの問題のトラブルシューティング」を参照。 |
| TimesTenでのロック・タイムアウト・エラーまたは警告 | このことは、通常、キャッシュ・グループに対するオープンなDDLトランザクションが原因で発生する。自動リフレッシュが必要なロックを取得できるようにDDLトランザクションをコミットする。 |
| TimesTenの不十分な永続メモリー領域エラー | PermSizeの値を大きくする。 |
| 自動リフレッシュOracle Databaseオブジェクトの検証エラーまたは警告 | 「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。 |
| キャッシュ・エージェントの予期せぬ終了 | Oracleサポート・サービスに連絡してください。 |
| メイン・デーモン・ディレクトリ内にコア・ファイルがある | Oracleサポート・サービスに連絡してください。 |
| 増分自動リフレッシュが完全リフレッシュになることに関する警告 | 「増分自動リフレッシュが完全自動リフレッシュになる」を参照。 |
| 自動リフレッシュが長時間経っても完了しないことを示す警告 | 前回の自動リフレッシュ以降に数多くのトランザクションが発生した場合は、自動リフレッシュ・トランザクションに長時間かかることがある。
ノート: 同じ自動リフレッシュ間隔を持つキャッシュ・グループは、1つのトランザクションで自動リフレッシュされる。 |
キャッシュ・エージェントは、自動リフレッシュが進行できるように、Oracle Databaseオブジェクトが存在するかどうか、およびOracleオブジェクトが有効かどうかを自動的に検証します。通常の操作では、ユーザー・エラー・ログにオブジェクトの検証エラーまたは警告が含まれることはありません。次のいずれかの状態が発生した場合を除いて、オブジェクトの検証エラーが見つかったときは、TimesTenカスタマ・サポートに連絡してください。
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)が通常よりはるかに多い場合、完全自動リフレッシュが行われた可能性があります。
サポート・ログで、完全自動リフレッシュについてのメッセージを確認してください。
キャッシュ管理ユーザー用に個別の表領域を作成することを強くお薦めします。この表領域は、キャッシュ管理ユーザーのデフォルトの表領域として使用されます。この表領域には、それぞれのOracle Database表に対する自動リフレッシュ・トリガー、それぞれのOracle Database表に対する変更ログ表、およびそれぞれのキャッシュ管理ユーザーでTimesTenが必要とするその他のオブジェクトが含まれます。個別の表領域を指定しない場合、これらのオブジェクトはOracle Databaseのシステム表領域に配置されます。
Oracle Databaseでキャッシュ管理ユーザーを作成する時に、表領域を指定します。また、Oracle DatabaseのALTER USER文のDEFAULT TABLESPACE句を使用してユーザーを作成した後も表領域を指定できます。
キャッシュされた各Oracle Database表の変更ログ表は、キャッシュ管理ユーザーの表領域に存在します。Oracle Database表を更新するたびに、1列(変更ログ・レコード)が該当するOracle Database表の変更ログ表に挿入されます。変更ログ・レコードのサイズ(バイト)は次のようになります。
size of change log record = size of primary key on Oracle table + 250
変更ログ表のレコード数は、Oracle Database表での更新率、およびTimesTenでの自動リフレッシュ間隔によって異なります。関連付けられているOracle Database表をキャッシュしているすべてのデータベースに適用済の変更ログ・レコードは、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接続属性を持つデータベースに接続されているが、古いデータベースにあったキャッシュ・グルーブが再生成されていない場合。
データベースがまだ存在している場合は、破棄されたデータベースに接続してキャッシュ・グループを削除してください。
それぞれのキャッシュされたOracle Database表に対してcacheInfo.sqlスクリプトを使用して、変更ログ表の大きさを特定します。出力を調べて、データベースがまだ使用中かどうかを確認します。詳細は、「変更ログ表の情報の表示」を参照してください。
データベースがまだ使用中である場合は、キャッシュ・エージェントが稼働していることを確認します。
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 Database表を使用する場合は、増分自動リフレッシュを使用するようにOracle Database表を構成できます。これらの表では、キャッシュ管理ユーザーの表領域が一杯になった場合に発生する状況を次のいずれかに指定できます。
DMLを実行したアプリケーションが失敗する。これがデフォルトです。
表領域の完全リカバリがNoneに設定される。アプリケーションは、表領域が一杯になるとOracle Databaseから「Out of Tablespace」エラーを受信します。その時点で、アプリケーションは、トランザクションをロールバックする必要があります。
ttCacheConfig組込みプロシージャでParamパラメータをTblSpaceFullRecovery、ValueパラメータをNoneに設定すると、表領域の完全リカバリがNoneに設定されます。たとえば、次の例では、terryが所有するemployees表のParamをTblSpaceFullRecovery、ValueをNoneに設定します。
call ttCacheConfig('TblSpaceFullRecovery','terry', 'employees','None');
変更ログ表を切り捨てて領域を解放すると、完全自動リフレッシュが実行されます。
キャッシュ管理ユーザーの表領域が一杯になっても、自動リフレッシュによってキャッシュされたOracle Database表でDML文を実行しているすべてのアプリケーションが続行されます。トリガーが実行され、既存の変更ログ・レコードを削除して、新しい変更ログ・レコード用に領域を開放します。これによって、増分自動リフレッシュ・モードが構成されたキャッシュ・グループに対して完全自動リフレッシュを実行できます。ただし、Oracle Database表が増分自動リフレッシュ用に構成されていない場合、トリガーは実行されません。
アプリケーションを続行し、アプリケーションで自動リフレッシュを実行できるようにする操作を設定するには、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 Database表の変更頻度が高い
キャッシュ・グループに含まれる子表の世代の数
キャッシュされたOracle Database表の列の数
キャッシュされたOracle Database表の列の大きさ
AUTOREFRESHトレースを有効にして、自動リフレッシュのパフォーマンス問題を診断します。詳細は、「AUTOREFRESHトレース」を参照してください。
|
ノート: TimesTenキャッシュ・グループの自動リカバリは、AUTOREFRESHキャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループにのみ適用されます。この項で対象としている自動リフレッシュ・キャッシュ・グループはすべて、AUTOREFRESHキャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループを指しています。 |
自動リフレッシュ・キャッシュ・グループを含んでいるすべてのTimesTenデータベースが破棄されているか、または使用されていない場合でも、TimesTenはキャッシュ・エージェントが実行されていないTimesTenデータベースに対して、Oracle Database表への自動リフレッシュによる変更の追跡を続行します。これによって、アクティブなTimesTenのデータベース内のキャッシュ・グループへの自動リフレッシュが遅くなります。
キャッシュ・エージェントは、データベースからのレスポンスがない状態かどうか、またはデータベースが使用されていない状態かどうかの検出を行います。停止したTimesTenデータベースのリカバリを行うかどうか、および行う場合の方法を指定できます。ただし、すべてのOracle Databaseオブジェクトが削除されている場合、TimesTenデータベースをリカバリすることはできません。
次の項では、アクティブでないTimesTenデータベースで自動リフレッシュのパフォーマンスが低下しないようにする方法について説明します。
特定のタイムアウト期間内にキャッシュ・エージェントがOracle Databaseサーバーと通信しなかった場合に、停止中および更新を受け入れないというマークをデータベースに付けるようにTimesTenに指示できます。
ttCacheConfig組込みプロシージャのAgentTimeOutパラメータを使用して、TimesTenデータベースのタイムアウトおよび各自動リフレッシュ・キャッシュ・グループのリカバリ方法を設定します。タイムアウト値は、同じキャッシュ管理ユーザーを使用するすべてのTimesTenデータベースに適用されます。タイムアウト値は、最初の接続時にTimesTenデータベースをメモリーにロードしてキャッシュ・エージェントを開始するためにかかる時間より長く設定する必要があります。そうしないと、TimesTenデータベースは誤って停止中とマークされます。TimesTenインスタンスのすべての計画メンテナンスで、AgentTimeOutの値を一時的に0(ゼロ)に設定して、タイムアウトを無効にすることができます。ttCacheConfig組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する項を参照してください。
たとえば、次の例では、TimesTenデータベースのタイムアウト値を6000秒(100分)に設定します。キャッシュ・エージェントがOracle Databaseサーバーに100分以内に接続しなかった場合、TimesTenデータベースは停止中とマークされます。
ttIsql> call ttCacheConfig('AgentTimeOut',,,'6000');
TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループがOracle Databaseと同期化されていない場合は、TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループをリカバリすることができます。同期が存在しない場合、Oracle Database表の更新は、対応する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 Databaseサーバー間の接続が再度確立されるときに、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であると、スタンドバイ・マスターは自動的にはアクティブ・マスターの役割を果たしません。リカバリでは、キャッシュ・エージェントおよびレプリケーション・エージェントが実行されていることを手動で確認する必要があります。各状況の詳細は次のとおりです。
表3-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設定を変更します。
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に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 Database表が、主キー、UNIQUEまたはNOT NULL制約を持つ列にNOVALIDATEを宣言すると、キャッシュ・グループの作成は失敗します。
|
ノート: これは、外部キー制約にはあてはまりません。ただし、TimesTenは、一致する外部キーを、有効化されたVALIDATE状態にすることを推奨します。外部キー列を、有効化されたVALIDATE状態に変更すると、ワークロード・パフォーマンスに影響する場合があります。 |
TimesTenは、主キーのNOVALIDATEまたはNOT NULL表の列の定義を、NULLとして認識するため、キャッシュ・グループを作成する列としてみなされません。したがって、Oracle Database表からキャッシュ・グループを作成する際に、主キーのすべての列、UNIQUEおよびNOT NULL列制約をVALIDATE状態で有効化する必要があります。
これらのうち1つ以上の制約を持つOracle Database表からキャッシュ・グループを作成すると、次のエラーが発生します。
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 Database表に既存の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が表示された場合、ロック競合に関していくつか問題がある可能性があります。この待機イベントは、別のデータベースの別のガベージ・コレクタ・セッションがすでにロックしたリソースを予約待ちしようとしているガベージ・コレクタ・セッションです。そのため、現在のガベージ・コレクタのみが待機します。ガベージ・コレクタ処理の待機は、他のガベージ・コレクタの処理を妨げますが、それ以外の処理を妨げることはありません。
たとえば、次では、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;
