昨天晚上生產(chǎn)的兩套10.2.0.4的數(shù)據(jù)庫(kù)修改了參數(shù)，需要重啟。在發(fā)出shutdown immediate命令后等了大概10分鐘的時(shí)間，數(shù)據(jù)庫(kù)還沒有down下來。檢查后臺(tái)alert日志，發(fā)現(xiàn)從開始shutdown到最后只輸出幾條日志，其中最后一條日志是：SHUTDOWN: Active processes prevent shutdown operation。

圖為在虛擬機(jī)上還原場(chǎng)景時(shí)的截圖。

開一個(gè)新的會(huì)話連接顯示已連接，但無(wú)法查視圖，又提示未連接。再次執(zhí)行shutdown immediate命令得到報(bào)錯(cuò)如下：

立馬百度了一下這個(gè)問題，隨便點(diǎn)開一個(gè)去看，說是因?yàn)樵趕qlplus / as sysdba 連接的情況下又執(zhí)行host命令導(dǎo)致的。如下圖這種情況

馬上想到我這邊也是這種情況，趕緊把相應(yīng)的會(huì)話從操作系統(tǒng)中kill掉。kill掉之后，數(shù)據(jù)庫(kù)又正常關(guān)閉了(這是在虛擬機(jī)上的情況)。

在實(shí)際的生產(chǎn)中卻是，把會(huì)話kill掉之后又等了幾分種，還是沒有返應(yīng)，于是只得強(qiáng)制shutdown abort了。好在業(yè)務(wù)都是提前停了，不過在執(zhí)行這條命令是還是有些忐忑的，就怕數(shù)據(jù)庫(kù)起不來。

在看貼子的時(shí)候，作者提到了他在停庫(kù)前做了切換日志，歸檔和checkpoint的操作來以防萬(wàn)一，我覺得這也是一個(gè)可取的地方，以后在停生產(chǎn)庫(kù)時(shí)不應(yīng)該業(yè)務(wù)停了就立馬停數(shù)據(jù)庫(kù)，也應(yīng)該做這些操作來保護(hù)數(shù)據(jù)。

俗話說禍不單行，真是沒錯(cuò)，就在第一個(gè)數(shù)據(jù)庫(kù)成功重啟后，在shutdown第二套數(shù)據(jù)庫(kù)也hang住了，但這次報(bào)錯(cuò)與上次還不一樣！！！(我的小心臟啊。。)

alert輸出信息如下：

從輸出信息可以了解到有進(jìn)行還沒有執(zhí)行完，但業(yè)務(wù)都已經(jīng)停了，會(huì)是什么進(jìn)行呢。由于還有其他事情，就沒去管是什么進(jìn)行，就直接kill掉了，但數(shù)據(jù)庫(kù)還是停不下來啊。

最后還是只得shutdown abort了，還是依然的忐忑。最后平安無(wú)事。

這個(gè)問題最后也沒有在虛擬機(jī)上模擬出來，始終不知道是什么。

總結(jié)一下：

1、自己給自己挖坑的滋味真是不好受啊。

2、關(guān)閉數(shù)據(jù)庫(kù)前做一些切換日志文件、歸檔和checkpoint的操作，來保證數(shù)據(jù)的安全性

3、關(guān)閉數(shù)據(jù)庫(kù)前一定做好檢查，是否有未解決的事務(wù)、JOB、或其他進(jìn)程，避免出現(xiàn)類似第二種的情況

4、要有一顆強(qiáng)大的內(nèi)心，相信自己:)

事后在MOS上查到了一些相關(guān)信息：

MOS文檔

Troubleshooting Shutdown Immediate/Normal Hanging Issues (文檔 ID 1906014.1)

列舉四種shutdown Hang的情況。

第一種情況的原因和給出的解決方案

Shutdown Immediate Hangs / Active Processes Prevent Shutdown (文檔 ID 416658.1)

CAUSE

This is not a bug.

If the DB Control repository is running on the database target against which shutdown immediate was attempted then an incorrect order of events seems used.

You should stop DB Control first to get rid of all connections between DB Control and the repository database and then shutdown the database with 'shutdown immediate'.

Current database sessions may show:

SQL> select SID, USERNAME, PROGRAM from v$session;

SID?? USERNAME?????????????? PROGRAM

----- ---------------------- ----------------------------------

243 SYSTEM???????????????? SQL Developer

246 SYSMAN???????????????? OMS

247??????????????????????? oracle@lgiora09 (q001)

248??????????????????????? oracle@lgiora09 (q000)

251 DBSNMP???????????????? emagent@lgiora09 (TNS V1-V3)

252 SYSMAN???????????????? OMS

253 SYSMAN???????????????? OMS

254 DBSNMP???????????????? emagent@lgiora09 (TNS V1-V3)

255 SYSTEM???????????????? java.exe

256 SYSMAN???????????????? OMS

Clearly OMS and OEM are connected (Oracle Enterprise Manager Grid Control or DBConsole) via users SYSMAN and DBSNMP.

These sessions should be de-activated (that is to log off any OEM, OMS, SYSMAN and DBSNMP) before the shutdown immediate is attempted.

Oracle Enterprise Manager, Grid Control, Dbconsole and agents keep doing internal processing.

This may include a few PLSQL notification procedures running on the database by database control like

BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;

As per internal documentation of the shutdown immediate, if there are active calls then it would wait for all the active calls to finish.

SOLUTION

To implement the solution:

1. Given OEM connections are active (SYSMAN and DBSNMP), de-activate these sessions, i.e. by stopping the agent/DBConsole

2. Then shutdown immediate as normal

- OR -

There may be processes still running and holding locks at the time a shutdown is issued.

Sometimes these are failed jobs or transactions, which are effectively 'zombies', which are not able to receive a signal from Oracle.

If this occurs, the only way to shutdown the database is by doing:

sql>

shutdown abort

startup restrict

shutdown normal

The startup does any necessary recovery and cleanup, so that a valid cold backup can be taken afterward.

If this issue occurs frequently, it would be a good practice to see if there are any active user processes running in v$session or v$process before shutting down the instance.

If the problem persists, and no apparent user processes are active, you can set this event prior to issuing the shutdown command in order to see what is happening. This will dump a systemstate every 5 minutes while shutdown is hanging

SQL>

connect / as sysdba

alter session set events '10400 trace name context forever, level 1';

Then issue the shutdown command.

3.?You can kill the sessions preventing shutdown. Refer:?Alert Log: Shutdown Waiting for Active Calls to Complete (Doc ID 1039389.6)

總結(jié)

以上是生活随笔為你收集整理的oracle关闭rs,Oracle 关闭(shutdown immediate)时hang住的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。