Oracle Restart是11gR2中推出的重要高可用（High Availability）特性。在Single Instance情況下，Clusterware形成一個可用性維護框架，Oracle元件服務都是在這個維護管理框架上進行管理。

Oracle Restart從職責上負責兩方面的功能，一個是Oracle各個服務元件的自動啟動。鑑於元件間複雜的依賴關係，使用Restart自動的進行啟動順序調節是比較好的一種策略。另一個功能是高可用支援，如果某一個元件意外被終止執行，比如異常中斷，Oracle Restart是可以定期的檢查“治下”元件的生存情況，一旦檢查出問題就會進行自動的啟動。

目前單例項Oracle使用Oracle Restart支援的元件內容有：監聽器Listener、Oracle例項和資料庫、ASM例項、ASM磁碟組、資料庫服務Service和ONS（Oracle Notification Service）。

本篇記錄筆者遇到的一個故障場景，不甚複雜，和行業大牛們大作不敢相比。權當思路記錄，留待需要的朋友不時之需。

1、問題故障出現

在一臺11gR2的Oracle上，筆者部署了單例項ASM例項和磁碟組結構，並且在上面部署了Single Instance Oracle。由於是測試使用，筆者在上面進行過一些測試和實驗，今天啟動伺服器之後，發現問題。

[grid@SimpleLinux simplelinux]$ uptime

13:58:13 up 2:24, 1 user, load average: 0.03, 0.02, 0.00

[grid@SimpleLinux simplelinux]$ ps -ef | grep pmon

grid 3212 1 0 11:35 ? 00:00:01 asm_pmon_+ASM

grid 27724 27685 0 13:58 pts/0 00:00:00 grep pmon

根據標準的Oracle Restart配置，ASM例項、ASM磁碟組和資料庫例項都是在Restart管理範圍，應該是隨著伺服器啟動而自動啟動。但是從實際情況看，ASM例項已經自動啟動，資料庫例項沒有啟動。

同RAC結構一樣，Restart也是藉助伺服器啟動過程中，以ohasd為首的高可用守護程式進行步步啟動動作。

這種情況下，檢視日誌資訊是最好的選擇，看看那個環節出現問題。

[grid@SimpleLinux simplelinux]$ pwd

/u01/app/grid/product/11.2.0/grid/log/simplelinux

[grid@SimpleLinux simplelinux]$ ls -l | grep alert

-rw-rw---- 1 grid oinstall 14494 Oct 17 11:35 alertsimplelinux.log

對grid和clusterware的日誌，都是保留在$ORACLE_HOME/log下的目錄從中。Alert.log是主日誌，也是檢查的起始點。通常是裡面發現的問題，進行進一步的分析動作。

[ohasd(2744)]CRS-2767:Resource state recovery not attempted for 'ora.diskmon' as its target state is OFFLINE

2013-10-17 11:35:34.373

[cssd(3130)]CRS-1601:CSSD Reconfiguration complete. Active nodes are simplelinux .

2013-10-17 11:35:50.094

[/u01/app/grid/product/11.2.0/grid/bin/oraagent.bin(3072)]CRS-5010:Update of configuration file "/u01/app/oracle/product/11.2.0/db_1/dbs/initora11g.ora" failed: details at "(:CLSN00014:)" in "/u01/app/grid/product/11.2.0/grid/log/simplelinux/agent/ohasd/oraagent_grid/oraagent_grid.log"

2013-10-17 11:35:55.645

[/u01/app/grid/product/11.2.0/grid/bin/oraagent.bin(3072)]CRS-5010:Update of configuration file "/u01/app/oracle/product/11.2.0/db_1/dbs/initora11g.ora" failed: details at "(:CLSN00014:)" in "/u01/app/grid/product/11.2.0/grid/log/simplelinux/agent/ohasd/oraagent_grid/oraagent_grid.log"

2013-10-17 11:35:55.806

[ohasd(2744)]CRS-2807:Resource 'ora.ora11g.db' failed to start automatically.

我們定位到了問題片段，從上面標紅的內容看。Clusterware在啟動dismon服務之後，試圖啟動資料庫，也就是ora.ora11g.db。在訪問一個引數檔案（注意是pfile）過程中，發現問題。

進一步檢查指出的oraagent_grid.log日誌，也沒有過多的資訊提示。

2013-10-17 11:35:50.049: [ora.ora11g.db][3013430160] {0:0:2} [start] sclsnInstAgent::sUpdateOratab file updated with dbName ora11g value /u01/app/oracle/product/11.2.0/db_1:N

2013-10-17 11:35:50.049: [ora.ora11g.db][3013430160] {0:0:2} [start] sclsnInstAgent::sUpdateOratab CSS unlock

2013-10-17 11:35:50.090: [ora.ora11g.db][3013430160] {0:0:2} [start] (:CLSN00014:)Failed to open file /u01/app/oracle/product/11.2.0/db_1/dbs/initora11g.ora

2013-10-17 11:35:50.091: [ AGENT][3013430160] {0:0:2} UserErrorException: Locale is

2013-10-17 11:35:50.091: [ora.ora11g.db][3013430160] {0:0:2} [start] clsnUtils::error Exception type=2 string=

CRS-5010: Update of configuration file "/u01/app/oracle/product/11.2.0/db_1/dbs/initora11g.ora" failed: details at "(:CLSN00014:)" in "/u01/app/grid/product/11.2.0/grid/log/simplelinux/agent/ohasd/oraagent_grid/oraagent_grid.log"

從資訊上看，是對pfile沒有能夠開啟。

2、問題解決

Oracle Restart是一個很複雜的體系，在沒有經驗和資料的情況下，筆者也不能證明說是Oracle Bug之類的。

一種思路可以進行嘗試。對於Oracle Restart，各種元件都是在上面可插拔的。根據需要，我們可以進行動態的配置註冊過程。從之前的情況看，資料庫本身是沒有問題的，應該就是配置過程中的故障。那麼，modify配置是有問題的。可不可以將database ora11g剔除出Restart體系，之後再新增過來。

Srvctl的add和remove命令可以幫助我們實現功能。而且在add過程中，只有-o引數是強制的，輸入ORACLE_HOME目錄。

[oracle@SimpleLinux dbs]$ srvctl remove database -d ora11g

Remove the database ora11g? (y/[n]) y

[oracle@SimpleLinux dbs]$ srvctl add database -d ora11g -o /u01/app/oracle/product/11.2.0/db_1

[oracle@SimpleLinux dbs]$ srvctl config database -d ora11g

Database unique name: ora11g

Database name:

Oracle home: /u01/app/oracle/product/11.2.0/db_1

Oracle user: oracle

Spfile:

Domain:

Start options: open

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Database instance: ora11g

Disk Groups:

Services:

Spfile為空。試著重新啟動。

[oracle@SimpleLinux dbs]$ srvctl start database -d ora11g

[oracle@SimpleLinux dbs]$ ps -ef | grep pmon

grid 3215 1 0 14:47 ? 00:00:00 asm_pmon_+ASM

oracle 5265 1 0 15:22 ? 00:00:00 ora_pmon_ora11g

oracle 5386 3578 0 15:22 pts/0 00:00:00 grep pmon

[oracle@SimpleLinux dbs]$ srvctl config database -d ora11g

Database unique name: ora11g

Database name:

Oracle home: /u01/app/oracle/product/11.2.0/db_1

Oracle user: oracle

Spfile:

Domain:

Start options: open

Stop options: immediate

Database role: PRIMARY

Management policy: AUTOMATIC

Database instance: ora11g

Disk Groups: DATA,RECO

Services:

啟動成功！最後嘗試看看reboot系統時，能否自動啟動。

--重新啟動系統

[root@SimpleLinux simplelinux]# ps -ef | grep pmon

grid 3213 1 0 15:27 ? 00:00:00 asm_pmon_+ASM

oracle 3270 1 0 15:27 ? 00:00:00 ora_pmon_ora11g

root 3336 3042 0 15:27 pts/0 00:00:00 grep pmon

[grid@SimpleLinux ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 17-OCT-2013 15:32:07

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))

STATUS of the LISTENER

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

Alias LISTENER

Version TNSLSNR for Linux: Version 11.2.0.3.0 - Production

Start Date 17-OCT-2013 15:27:06

Uptime 0 days 0 hr. 5 min. 0 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File /u01/app/grid/product/11.2.0/grid/network/admin/listener.ora

Listener Log File /u01/app/grid/diag/tnslsnr/SimpleLinux/listener/alert/log.xml

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SimpleLinux.localdomain)(PORT=1521)))

Services Summary...

Service "+ASM" has 1 instance(s).

Instance "+ASM", status READY, has 1 handler(s) for this service...

Service "ora11g" has 1 instance(s).

Instance "ora11g", status READY, has 1 handler(s) for this service...

Service "ora11gXDB" has 1 instance(s).

Instance "ora11g", status READY, has 1 handler(s) for this service...

The command completed successfully

SQL> show parameter spfile

NAME TYPE VALUE

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

spfile string /u01/app/oracle/product/11.2.0/db_1/dbs/spfileora11g.ora

問題解決。

3、結論和反思

從直觀的感覺看，這應該是Restart和原有命令協調的一個故障。原有create pfile之後，Restart似乎不能夠支援pfile的啟動了。另外，在修復過程中，我們始終看到不能對spfile修改引數生效，也是一個疑惑點。

能夠肯定的是，在新增資料庫ora11g的時候，沒有明確指定啟動spfile的位置，那麼應該是進入了自動檢索目錄spfile-pfile的過程。所以系統得到修復。

Oracle Restart啟動資料庫例項故障一例

相關文章