| Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド
リリース6.0 B25774-01 |
|
 前へ |
 次へ |
この項では、1つ以上のTimesTenプロセスが使用不可能であると考えられるときに確認する事項を説明します。
ttStatusユーティリティ（「ttStatusユーティリティの使用」を参照）を使用して、TimesTenデーモンのステータスとすべてのTimesTen接続の状態を確認できます。
TimesTenデーモンが稼働していない場合、Windowsでは次のメッセージが表示されます。
% ttStatus ttStatus: Could not connect to TimesTen service: No errorTimesTenデーモンが予期せず停止した場合、次に説明するように、デーモン・ログを確認します。TimesTenデータ・ストアへのすべてのアプリケーション接続を終了してから、デーモンを再起動します。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のOracle TimesTen Data Managerデーモンでの処理に関する項を参照してください。
TimesTenサブデーモンまたはエージェントが停止したことを示すエラーを受け取った場合は、TimesTenデーモン・ログを調べて、障害の理由を示すエラー・メッセージがないかどうかを確認できます。詳細は、「ttDaemonLogユーティリティの使用」を参照してください。
TimesTenデーモンがクラッシュした場合、そのTimesTenデーモンからデーモン・ログに送信を行うことはできませんが、サブデーモンでは、メイン・デーモンがクラッシュしたことを示すメッセージをログに送信してから終了します。
09:24:13 Err : 4375 ------------------: Main daemon has vanishedデータ・ストアへのすべてのアプリケーション接続を終了するまで、デーモンを再起動しないでください。TimesTenデーモン/サービス・プロセスを終了すると、残りの接続は終了または切断されるため、データ・ストアを無効にすることができます。すべての接続が終了したら、プロセスを再起動できます。
すべてのアプリケーションが終了した後に、デーモンを再起動できます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のOracle TimesTen Data Managerデーモンでの処理に関する項を参照してください。次に各データ・ストアに接続するときに、TimesTenはチェックポイントおよびログ・ファイルからリカバリを実行します。
UNIXシステムでいずれかのTimesTenプロセスによってクラッシュが発生し、すべての診断方法を試しても問題が解決しない場合は、TimesTenがコア・ファイルを生成していないかどうか確認します。コア・ファイルが生成されている場合、コア・ファイルはコア・ダンプの原因となった実行可能ファイルと同じ場所（ほとんどの場合は/var/TimesTen/instanceディレクトリ）に格納されています。コア・ファイルがあった場合は、システムのデバッガにアタッチし、コア・ファイルからスタック・トレースを抽出して、そのトレース結果をオラクル社カスタマ・サポート・センターに送付します。
Windowsシステムの場合は、「サービス」メニューでTimesTen Data Managerのプロパティ・ダイアログの「デスクトップとの対話をサービスに許可」オプションを有効にすることで、サービス障害の診断情報を取得できます。TimesTen Data Managerサービスでセグメンテーション・フォルトが発生すると、デバッガを起動するかどうかを尋ねるポップアップが表示されます。オラクル社カスタマ・サポート・センターに、デバッガの出力を送付します。また、TimesTen Data Managerサービスで生成されたエラーは、イベント・ビューアで参照することもできます。イベント・ビューアに記録されたイベントの解釈方法については、Windowsのドキュメントを参照してください。
