質問: sql*plusからsqlを実行し、1000万レコードくらいのtableから500万レコードくらいを削除する場合のcommitを、最後の最後で1回実行したところcommitのレスポンスが返って来なくなりました。 このtableには、blobのカラムもあって、データ容量も大きいのが関係しているんでしょうか? 上記のようなcommitが終わらない場合の対処方法をお教えください。 現状を把握する知識も持ち合わせておりません。 dba table群の中身を確認することで、現状を把握することもできるのでしょうか? ここをチェックすれば良いなどの情報も教えていただきたいです。 個人的には、現状から復帰させるには、サービスの再起動やosの再起動しか手段が無さそうに思うのですが、そうした場合、やはりdatabaseが壊れる可能性もあるのでしょうか? commitを中断したり、強制的に終了させる方法もあるのでしょうか? 最後に、大量の処理をcommitする場合のcommitのタイミングはどのように決めれば良いのでしょうか? 今回の場合だと、100万レコードずつcommitすれば良かったなどの可能性もあるのでしょうか? 申し訳ありませんが、よろしくご教示下さい。 --- windows server 2008R2 Oracle Database 11gR2
回答: 大変遅くなりましたが、対処した時の手順をメモっておきます。 まず、sqlplusの強制終了を試みる。 どうも、接続が強制終了されると要求だしてたのが、強制的に元に戻されるらしいので... sqlplusを実行してるコマンドプロンプトを強制終了してから、別のコマンドプロンプトを起動して再びsqlplusで接続。 ``` SQL> SELECT * FROM V$SESSION WHERE PROGRAM='sqlplus.exe'; ``` で、現在接続してるヤツを調べたら複数レコードが見つかりました。 接続が実行してるSQLを調べてみたら... ``` SQL> SELECT S.*, Q.SQL_TEXT FROM V$SESSION S, V$SQL Q WHERE PROGRAM = 'sqlplus.exe' AND S.SQL_ID = Q.SQL_ID; ``` 片方は、応答なくなったsqlplusだと分かったので、その接続の強制終了を試みます。 先のSQLで、問題の接続のSIDとSERIAL#がわかるので、 ``` SQL> ALTER SYSTEM KILL SESSION '【SID】,【SERIAL#】'; ``` を実行。 再び、現在の接続を確認。 ``` SQL> SELECT * FROM V$SESSION WHERE PROGRAM='sqlplus.exe'; ``` しばらく...数分くらいかな?の間、問題の接続が残っていましたが、消えてくれました。 要求出してたテーブルを調べてみましたが、要求前の状態のようでしたので、事なきを得ました。 自分の対処方法はこのような感じです。 全ての場合で同様の対処方法が成功するとは思いませんが、参考になれば嬉しいです。