次のクエリが数日間ハングしたように見えるマシンからのトレースバックがあります。
SELECT table_name FROM user_tables
何がそのようなロックを生成する可能性がありますか?ユーザーはこのテーブルを変更できません。そして、正常に実行されたこのクエリの後続のインスタンスがたくさんありました。
次のクエリが数日間ハングしたように見えるマシンからのトレースバックがあります。
SELECT table_name FROM user_tables
何がそのようなロックを生成する可能性がありますか?ユーザーはこのテーブルを変更できません。そして、正常に実行されたこのクエリの後続のインスタンスがたくさんありました。
したがって、条件が存在しなくなったため、何が起こったのかを知る方法はありません。
ただし、将来、これまたは同様のことが再び発生した場合は、Oracleの待機インターフェースを使用することをお勧めします。つまり、を見てくださいV$SESSION
。
まず、プロセスが回転している(つまり、CPU上にある)かブロックしている(つまり、待機イベントを待機している)かを判断する必要があります。それを判断する方法は、次のSTATE
列を確認することです。
'WAITING'
の場合、セッションはブロックされます。その場合、EVENT列には、セッションが待機しているイベントを記述します。'WAITED KNOWN TIME'
、の場合、WAIT_TIMEはセンチ秒単位の待機時間です。'WAITED SHORT TIME'
の場合、セッションの待機時間は1センチ秒未満です。'WAITED UNKNOWN TIME'
の場合、セッションのtimed_statisticsがFALSEに設定されているため、待機時間は不明です。お役に立てば幸いです。