ITPub博客

首页 > 数据库 > Oracle > Oracle Restart启动数据库实例故障一例

Oracle Restart启动数据库实例故障一例

Oracle 作者:luashin 时间:2016-01-14 11:31:31 0 删除 编辑

    Oracle Restart11gR2中推出的重要高可用(High Availability)特性。在Single Instance情况下,Clusterware形成一个可用性维护框架,Oracle组件服务都是在这个维护管理框架上进行管理。 

    Oracle Restart从职责上负责两方面的功能,一个是Oracle各个服务组件的自动启动。鉴于组件间复杂的依赖关系,使用Restart自动的进行启动顺序调节是比较好的一种策略。另一个功能是高可用支持,如果某一个组件意外被终止运行,比如异常中断,Oracle Restart是可以定期的检查“治下”组件的生存情况,一旦检查出问题就会进行自动的启动。

    目前单实例Oracle使用Oracle Restart支持的组件内容有:监听器ListenerOracle实例和数据库、ASM实例、ASM磁盘组、数据库服务ServiceONSOracle Notification Service)。

本篇记录笔者遇到的一个故障场景,不甚复杂,和行业大牛们大作不敢相比。权当思路记录,留待需要的朋友不时之需。

1、问题故障出现

    在一台11gR2Oracle上,笔者部署了单实例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

gridclusterware的日志,都是保留在$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体系,之后再添加过来。

Srvctladdremove命令可以帮助我们实现功能。而且在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

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

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的过程。所以系统得到修复。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9034054/viewspace-1976355/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2015-02-18

  • 博文量
    290
  • 访问量
    1085658