| Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド
リリース7.0 E05173-01 |
|
 前へ |
 次へ |
この項では、アプリケーションからのレスポンスがなく、ハングしている可能性があるときに確認する事項を説明します。
| 考えられる原因
|
対処
|
|---|---|
| 内部アプリケーション・エラーが発生した | |
| データ・ストアとの接続を失った | |
| DSNに設定した接続属性が間違っている | |
| ロックの競合が過剰である | |
| 長いチェックポイントの実行中である | |
| スタックのオーバーラン | |
| 単一のプロセスに2つの接続が関連付けられている（Linuxのみ） | |
| その他の問題 |
すべてのアプリケーションで、SQLErrorファンクションが返したODBCエラーを確認し、それらのいずれかでハングの原因となる問題が発生していないかどうかを確認します。ODBCをコールした後に必ずSQLErrorをコールして、エラーまたは警告が初めて発生したときの状態を識別します。SQLErrorの使用例については、デモ・プログラム、および『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のエラーと警告の取得に関する説明を参照してください。
問題が再現可能な場合は、ttTraceMonを使用してSQLをトレースを生成し、アプリケーションがハングしている箇所を特定できます。詳細は、「SQLトレース」を参照してください。さらに極端な場合は、アプリケーションに対して、レベル4のERRトレースを生成し、TimesTenダイレクト・ドライバにプッシュされたすべてのエラー・メッセージを確認します。詳細は、「ERRトレース」を参照してください。
ttStatusユーティリティ（「ttStatusユーティリティの使用」を参照）を使用して、データ・ストアとの既存の接続の状態を確認します。アプリケーションが接続を切断した場合は、予期せず切断した原因を判断する方法について、「アプリケーションが予期せず切断または終了する」を参照してください。
接続の問題がない場合、デッドロックまたはタイムアウトが問題である可能性もあります。デッドロックとタイムアウトに関する情報は、SYS.MONITOR表に記録されます。この表の内容については、「TimesTen SYSTEM表の監視」を参照してください。また、ttXactAdminユーティリティを使用して、コミットされていないトランザクションが現在保持しているロックのタイプと、ロックが保持されているリソースを検出することもできます。デッドロックとタイムアウトの回数が多い場合、アプリケーションを変更してデッドロックを回避することを検討してください。
デッドロックが発生すると、TimesTenサブデーモンは、デッドロックに関係するアプリケーションにTimesTenエラー6002「Lock request denied because of deadlock」を生成させて問題を排除します。エラー・メッセージには、ロック・ホルダーが実行しているSQLが含まれるため、デッドロックの原因の診断に役立つ可能性があります。このエラーが発生した場合、アプリケーションはトランザクションをロールバックし、そのトランザクションの文を再発行する必要があります。循環待機が発生するような特定の順序で文を発行したことが、デッドロックの原因になることもあります。その場合は、文の発行順序を変更することで、デッドロックを防げることもあります。
DSNのLockWait属性またはアプリケーションのttLockWaitプロシージャで設定したロック・タイムアウト時間によって定義される時間内にロックを取得できないと、アプリケーションでTimesTenエラー6003「Lock request denied because of time-out」が発生します。タイムアウト・エラーの発生時に、アプリケーションは文を再発行する可能性があります。トランザクションを短くすると、ロック・タイムアウト・エラーが発生する可能性は低くなります。
システム表では、ロック競合がよく発生します。システム表での競合は、同じ文を何度も直接実行するのではなく、準備済の文を実行することで削減できます。
マルチ・スレッド・アプリケーションでは、同じデータ・ストアへの様々な接続ハンドルにリクエストを発行するスレッドで、それ自身とのロック競合が発生する可能性があります。TimesTenでは、ロック・タイムアウトを使用してこれらの競合を解消します。
TimesTenの機能はアプリケーションとスタック領域を共有します。マルチスレッド環境では、各スレッドに割り当てたスタックのオーバーランを避けることが重要です。これは、オーバーランによって、予想できないデバッグ結果になる可能性があるためです。TimesTenのコールで消費されるスタック領域の量は、使用するSQL機能によって異なります。ほとんどのアプリケーションでは、32-bitシステムで16KB、64-bitシステムで34KBから72KBのスタック領域が必要です。
スレッド当たりに割り当てられるスタック領域の量は、スレッドの作成時に、オペレーティング・システムによって指定されます。
Windowsでは、デバッグ・ドライバを使用して、Visual C++デバッグCライブラリにアプリケーションをリンクすると、スタック・プローブを有効にすることができます。これにより、スレッドが割り当てられた量を超えてそのスタックを増やそうとすると、識別可能な例外を発生します。
JDBCアプリケーションでは、スタックのオーバーランを避けるために、スレッドごとに100KB以上のネイティブ･スタック領域が必要です。オペレーティング･システムのデフォルトに加えて、スレッドごとに割り当てるネイティブ･スタック領域は、Javaコマンドライン･オプションでも指定できます。このオプションは、HP-UXシステムでは-ss、Solarisシステムでは-Xssです。
アプリケーションがハングする原因を特定できない場合は、デーモン・ログ（「ttDaemonLogユーティリティの使用」を参照）にエラー記録がないかどうかを確認します。また、トレース・ログを生成して、様々なTimesTenコンポーネントのアクティビティを検出することもできます。詳細は、「ttTraceMonユーティリティの使用」を参照してください。TimesTen以外のツールについては、「他のトレース・ツールの使用」を参照してください。
