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 '[email protected] (J000)'

Active process 20559 user 'oracle' program '[email protected]'

Active process 20561 user 'oracle' program '[email protected]'

Active process 20569 user 'oracle' program '[email protected]'

Active process 20557 user 'oracle' program '[email protected]'

Active process 20555 user 'oracle' program '[email protected]'

Active process 20563 user 'oracle' program '[email protected]'

Active process 20565 user 'oracle' program '[email protected]'

Active process 20567 user 'oracle' program '[email protected]'

Active process 20571 user 'oracle' program '[email protected]'

Active process 6808 user 'oracle' program '[email protected]'

Active process 6795 user 'oracle' program '[email protected]'

Active process 6786 user 'oracle' program '[email protected]'

Active process 20553 user 'oracle' program '[email protected]'

Active process 6730 user 'oracle' program '[email protected]'

Active process 6775 user 'oracle' program '[email protected]'

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或者内部運作問題。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/17203031/viewspace-1775643/，如需轉載，請注明出處，否則将追究法律責任。

轉載于:http://blog.itpub.net/17203031/viewspace-1775643/