針對留言中，有朋友說“再做個hanganalyze，具體分析下”，趁今天星期天再把這個問題再探討下。

當時執行shutdown命令，alert日誌的資訊有：

Sat Oct 22 02:21:27 2011
Active call for process 2674792 user 'oracle' program 'oracle@■■■(J006)'
SHUTDOWN: waiting for active calls to complete.

這個資訊很明白了，就是說SHUTDOWN正在等待active call完成，指的就是OS程式2674792。在Oracle後臺程式中也可以找到：

■■db1:/home/oracle>ps -ef | grep ora_
oracle 663606       1   0   Jun 22      - 3018:50 ora_lms8_■db1
oracle 1773750       1   0   Jun 22      - 3822:32 ora_lms2_■db1
oracle 2256938       1   0   Jun 22      - 120:13 ora_dbw2_■db1
oracle 2674792       1   5 01:10:48      - 5:07 ora_j006_■db1
oracle 295196       1   0   Jun 22      - 120:07 ora_dbw1_■db1
oracle 340320       1   1   Jun 22      - 3009:44 ora_lms7_■db1
oracle 356740       1   0   Jun 22      - 1632:38 ora_lmd0_■db1
oracle 381358       1   1   Jun 22      - 727:09 ora_lmon_■db1
………………………

就是因為有這個job程式在跑，所以才hang住了shutdown命令。

之前也沒少在生產庫上做起停操作，但都“幸運的”沒有碰到job相關的程式，所以這次也就是忽視了在停庫前將執行的job程式kill掉。通常，我在停庫之前，都會在停掉LISTENER後，就開始殺程式，起碼把LOCAL=NO的客戶端連線程式都殺掉，再將資料庫checkpoint下，這樣就基本可以保證資料庫下次啟動時，不會出太的問題。

關於alert中的SHUTDOWN: waiting for active calls to complete.這個資訊，在metalink上也有對其的解釋：

Explanation:
The database is waiting for pmon to clean up processes,but pmon is nuable to clean them.The client connections to the server are causing the shutdown immediate or normal to hang.Killing them allows pmon to clean up and release the associated Oracle processes and resources.

What resources are we talking about?
1) Any non committed transactions must be rolled back.
2) Any temporary space (sort segments / lobs / session temporary tables)must be freed.
3) The session itself and any associated memory consumed by the session.
4) Internal locks / enqueues must be cleaned up

完整的文件資訊可參考：metalink ID 1039389.6

在shutdown業務比較繁忙的生產庫時，必須首先要kill process，否則時間之長，令人無法忍受，之前有聽說因長時間未正常shutdown，最後又取消了，重新執行了abort命令，這是一種很危險的做法。

在此之後，我也注意到了，要提前把OS中的執行的JOB程式也清理下。

shutdown命令被job程式hang住(續)

相關文章