Shutdown immediate命令長時間等待分析一例

 

對生產系統，特別是大型系統的正式環境，停機、升級和配置動作都是相當慎重的事情。shutdown命令雖然簡單，但對於運維部門來講，有時候一些shutdown過程中出現的問題也的確是讓人撓頭。

筆者的同事就遇到了這樣的難題。同事維護一套很老的網站系統，後臺使用資料庫10gR1，具體版本是10.2.0.1，前臺是J2EE框架的Web網站應用。由於系統比較老，一些長期的執行bug補丁沒有處理。由於網站很快就要被替換，所以也沒有過多進行干預，遇到問題往往見招拆招。

同事聯絡筆者，說關閉資料庫出現長時間等待，類似hang住狀態。前端應用是公司網站，長時間不能訪問是很大麻煩。

 

1、故障現象

 

系統版本10.2.0.1。

 

 

LICENSE_MAX_USERS = 0

SYS auditing is disabled

ksdpec: called for event 13740 prior to event group initialization

Starting up ORACLE RDBMS Version: 10.2.0.1.0.

 

 

同事希望將資料庫完整關閉後重啟，解決一個出現的bug問題。但是在sqlplus命令列提示中輸入shutdown immediate之後，就一直在等待狀態。持續時間已經超過半個小時，讓同事比較揪心。

說明：由於環境所限，後續筆者採取的操作沒有記錄下來，以步驟方式進行描述。

1)        後臺單獨啟動一個命令列連線，使用ps –ef | grep pmon命令，確定Oracle pmon程式是否存在。這個程式是Oracle例項的標記程式；

2)        從ps –ef命令，可以看到Oracle例項的pmon程式還存在，還在後臺執行；

3)        從另外的sqlplus /nolog登入，使用conn / as sysdba進入系統。結果顯示connect to idle instance；

 

從上面的情況看，Oracle Instance應該還處在終止狀態，沒有完成shutdown過程。Oracle shutdown immediate過程包括終止回滾當前執行事務transaction，不允許新連線連入。當前Oracle處在“半死半活”狀態。

 

2、問題解決

 

正常處理策略，應該是定位系統的alert log日誌，確定當前資料庫執行狀態和是否有錯誤資訊。如果有錯誤資訊，就可以進行見招拆招的處理。但是時間有限，筆者也沒有條件進行精細分析。於是，採用強制策略。

對資料庫進行startup force操作。startup force包括兩部分操作，shutdown abort和startup。之後，系統啟動，各項操作執行正常。

 

事後，筆者和同事索要了alert log記錄，進行進一步分析，希望發現問題關鍵。

 

3、Alert Log日誌分析

 

在日誌中，筆者很快定位到了最後一次關閉資料庫動作。

 

 

--停止開始，關閉例項

Fri Aug 14 12:47:45 2015

ERROR: Emon failed to start.

Shutting down instance: further logons disabled

Fri Aug 14 12:47:45 2015

Stopping background process QMNC

Fri Aug 14 12:47:45 2015

Stopping background process CJQ0

Fri Aug 14 12:47:47 2015

Stopping background process MMNL

Fri Aug 14 12:47:48 2015

Stopping background process MMON

 

--進一步關閉後臺程式

Fri Aug 14 12:47:49 2015

Shutting down instance (immediate)

License high water mark = 40

Fri Aug 14 12:47:49 2015

Stopping Job queue slave processes

Fri Aug 14 12:47:49 2015

Job queue slave processes stopped

Waiting for shared server 'S000' to die

All dispatchers and shared servers shutdown

--7分鐘之後，定位問題程式

Fri Aug 14 12:54:05 2015

Active process 5640 user 'oracle' program 'oracle@mcw (J000)'

Active process 20559 user 'oracle' program 'oraclemmweb@mcw'

Active process 20561 user 'oracle' program 'oraclemmweb@mcw'

Active process 20569 user 'oracle' program 'oraclemmweb@mcw'

Active process 20557 user 'oracle' program 'oraclemmweb@mcw'

Active process 20555 user 'oracle' program 'oraclemmweb@mcw'

Active process 20563 user 'oracle' program 'oraclemmweb@mcw'

Active process 20565 user 'oracle' program 'oraclemmweb@mcw'

Active process 20567 user 'oracle' program 'oraclemmweb@mcw'

Active process 20571 user 'oracle' program 'oraclemmweb@mcw'

Active process 6808 user 'oracle' program 'oraclemmweb@mcw'

Active process 6795 user 'oracle' program 'oraclemmweb@mcw'

Active process 6786 user 'oracle' program 'oraclemmweb@mcw'

Active process 20553 user 'oracle' program 'oraclemmweb@mcw'

Active process 6730 user 'oracle' program 'oraclemmweb@mcw'

Active process 6775 user 'oracle' program 'oraclemmweb@mcw'

SHUTDOWN: waiting for logins to complete.

Fri Aug 14 13:07:49 2015

MMNL absent for 1218 secs; Foregrounds taking over

Fri Aug 14 13:34:50 2015

Shutting down instance (abort)

License high water mark = 40

Instance terminated by USER, pid = 7652

 

 

每條log日誌，都可以看到對應的時間。消耗最多的是兩個部分，第一個是終止dispatcher和s000共享連線程式關閉，消耗7分鐘左右。另一部分是等待一系列active的活動程式中斷連線，持續接近30分鐘，直到筆者接入操作。

從程式格式來看，應該是前端網站系統連線進入的server process資訊。連結數量上還是比較接近應用設定連線池的。

這就有問題了，我們直到Oracle的shutdown有幾個選項。分別為：shutdown normal、transaction、immediate和abort，分別應對不同的操作動作。

ü  normal：禁止新連線連入，等待原有連入連線自行關閉斷開後才關閉資料庫；

ü  transaction：禁止新連線連入，原有空閒連線被強行斷開，正在執行的事務等待結束之後，才關閉資料庫；

ü  immediate：禁止新連線連入，原有空閒連線斷開，正在執行事務強行中斷，並且等待回滾結束後，才關閉資料庫；

ü  abort：禁止新連線連入，如同突發斷電；

 

同事使用的immediate關閉方式，如果有事務也被斷開回滾，怎麼還會等某些連線呢？

問題出現在已經連線的那些server process上，如果這些連線在執行長時間的查詢操作，的確是要等待的。同事在進行關閉資料庫操作的時候，似乎沒有關閉前臺應用，這樣的話，原來連入的server process依然可以執行長作業。

那麼，我們應該怎麼使用shutdown immediate呢？在過去，筆者讀過一位前輩的經驗：

1)        根據對應用系統的瞭解，確定“先關應用，後關庫”的操作順序；

2)        透過v$transaction，確定系統中時候有“大會滾”作業存在，如果有，要聯絡事務的使用者，進行系統外溝通；

3)        透過v$session_longops，確定系統中是否有長時間的查詢動作；

4)        關閉OEM。10g之後，OEM以Web應用的方式存在，OEM與資料庫的連線，也往往是阻斷shutdown immediate的一個重要因素；

 

 

經過這些確認，才能進行穩妥的shutdown immediate操作。注意：shutdown immedaite雖然可以進行回滾，但是長時間hang住也可能是在進行大事務操作的回滾操作。

 

4、結論

 

最後，我們討論一下如果已經進行shutdown immediate被hang住，從alert log中看到了程式資訊怎麼處理呢？

解決的方法是透過程式編號，分析程式性質和狀態，逐個解決。如果是前臺程式，可以考慮是應用連線斷開或者加速回滾過程。如果是後臺程式，可以考慮是資料庫bug或者內部執行問題。