| Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド
リリース7.0 E05173-02 |
|
 前へ |
 次へ |
この項では、アプリケーションからのレスポンスがなく、ハングしている可能性があるときに確認する事項を説明します。
| 考えられる原因
|
対処
|
|---|---|
| すべての問題 | |
| 内部アプリケーション・エラーが発生した | ODBCエラーを確認する |
| DSNに設定した接続属性が間違っている | 接続モードを検討する |
| ロックの競合が過剰である |
アプリケーションがハングした場合、ttXactAdminユーティリティを使用してトランザクション・ログを確認します。詳細は、「ttXactAdminユーティリティの使用」を参照してください。
また、エラーのユーザー・エラー・ログ（「TimesTenデーモンによって生成されたログの使用」を参照）を確認します。
また、トレース・ログを生成して、様々なTimesTenコンポーネントのアクティビティを検出することもできます。詳細は、「ttTraceMonユーティリティの使用」を参照してください。
すべてのアプリケーションで、SQLErrorファンクションが返したODBCエラーを確認し、それらのいずれかでハングの原因となる問題が発生していないかどうかを確認します。ODBCをコールした後に必ずSQLErrorをコールして、エラーまたは警告が初めて発生したときの状態を識別します。SQLErrorの使用例については、デモ・プログラム、および『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のエラーと警告の取得に関する説明を参照してください。
問題が再現可能な場合は、ttTraceMonを使用してSQLをトレースを生成し、アプリケーションがハングしている箇所を特定します。詳細は、「SQLトレース」を参照してください。さらに極端な場合は、アプリケーションに対して、レベル4のERRトレースを生成し、TimesTenダイレクト・ドライバにプッシュされたすべてのエラー・メッセージを確認します。詳細は、「ERRトレース」を参照してください。
接続の問題がない場合、デッドロックまたはタイムアウトが問題である可能性もあります。デッドロックとタイムアウトに関する情報は、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では、ロック・タイムアウトを使用してこれらの競合を解消します。
