RUI个人博客 首页>>Oracle ORA-xxxxx>>[原] 粗心导致数据库启动失败 DIA-49104 报错

[原] 粗心导致数据库启动失败 DIA-49104 报错

前记:细心 最重要!!! 无论是 解决问题的时候,还是搭建环境的时候!!!

起因:

        每季度对服务器进行切换演练,刚上线2个多月的数据库刚好赶上了这次切换演练,由于是做的2个节点的oracle 11.2.0.4 RAC,为了保证业务的不中断,所以进行单节点切换(所谓的单节点切换:先进行节点1的重启服务器,然后重启之后拉起应用,然后进行节点2重启服务器)

     当进行节点1的重启时,数据库正常关闭,集群正常关闭,服务器重启之后,集群启动正常,但是数据库启动就一直在报错。导致数据库启动失败。

集群状态正常,磁盘组对应的磁盘权限也都正常。

数据库:

11.2.0.4

操作系统

红旗 AX4.4 (redhat 6.5)

内核

2.6.32-431.20.3.el6.x86_64

报错信息:

SQL> startup

ORA-01078: failure in processing system parameters

DIA-49104: [LEAVE] is not a valid argument for event [kg_event]

DIA-49100: Failed to process event statement [28401 TRACE NAME CONTEXT FOREVER, LEAVE 1

排查思路:

1. 因为DIA相关的报错感觉像是诊断相关的报错,很少见,所以先从ORA的报错入手。

1-1. 先通过服务器上进行查看一下ORA-01078是什么错误。

1-2. 通过百度------>google------>mos 上查看是否有相关的案例。

2.通过下面的DIA-49104  DIA-49100定位错误。

具体排查过程:

通过操作系统层面查看了报错信息:

oracle@rac1[racdb1]/home/oracle$oerr ora 1078

01078, 00000, "failure in processing system parameters"

// *Cause:  Failure during processing of INIT.ORA parameters during

//          system startup.

// *Action:  Further diagnostic information should be in the error stack.

这个报错是读取系统的参数失败,导致报错的。

拓展:

数据库启动过程:

nomount (加载参数文件:spfileSID.oraàinitSID.oraàspfile.oraàinit.ora)

  à mount(加载控制文件(控制文件中记录一些数据文件的位置和数据库相关信息))

  à open (打开数据库,数据库当前 READ WRITE状态)

猜想一:难道是因为找不到参数文件了导致的这个问题?

查找了一下相关的文件

oracle@rac1[racdb1]/oracle/db11g/dbs$ls

hc_racdb1.dat  initracdb1.ora   init.ora   orapwracdb1   snapcf_racdb1.f

oracle@rac1[racdb1]/oracle/db11g/dbs$cat initracdb1.ora

SPFILE='+DGSYS/racdb/spfileracdb.ora'

[root@rac1 log]# su - grid

grid@rac1[+ASM1]/home/grid$asmcmd

ASMCMD> ls

........(省略部分无关信息)

DGSYS/

ASMCMD> cd dgsys

ASMCMD> ls

racdb/

........(省略部分无关信息)

ASMCMD> cd racdb

ASMCMD> ls -l

Type           Redund  Striped  Time             Sys  Name

                                                 Y    CONTROLFILE/

                                                 Y    DATAFILE/

                                                 Y    ONLINELOG/

                                                 Y    PARAMETERFILE/

                                                 Y    TEMPFILE/

                                                ........(省略部分无关信息)

                                                 N    spfileracdb.ora => +DGSYS/racdb/PARAMETERFILE/spfile.273.909166749

ASMCMD> cd PARAMETERFILE/

ASMCMD> ls

spfile.273.909166749

否决:

     参数文件都在,而且权限属主都正常。

猜想二:难道是参数文件中的参数有问题?

我尝试重建一下控制文件看一下pfile.ora文件是否真的有问题

(由于spfile是二进制文件,pfile是文本文件)

SQL> create pfile='/tmp/pfile.ora' from spfile;

create pfile='/tmp/pfile.ora' from spfile

*

ERROR at line 1:

ORA-01565: error in identifying file '?/dbs/spfile@.ora'

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

报错:

居然是 No such file or directory ,而且找的是?/dbs/spfile@.ora 这个文件。(这里不太理解为啥找的是 spfile@.ora 这个@啥意思。。。。。有知道可以给我留言,先谢过了。)

猜想三:当前节点1和节点2共用spfile文件,从节点2恢复出来一个pfile传到节点1尝试启动行不行?

节点2

SQL> create pfile='/tmp/pfile.ora' from spfile;

File created.

oracle@rac2[racdb2]/home/oracle$cd /tmp/

oracle@rac2[racdb2]/tmp$scp pfile.ora rac1:/tmp/

节点1

SQL> startup pfile='/tmp/pfile.ora';

DIA-49104: [LEAVE] is not a valid argument for event [kg_event]

DIA-49100: Failed to process event statement [28401 TRACE NAME CONTEXT FOREVER, LEAVE 1]

ORA-01078: failure in processing system parameters

还是报错,

不行!!!

答案:查看了pfile文件,找到了最终的罪魁祸首!!!

AVE] is no oracle@rac1[racdb1]/tmp$vi pfile.ora

........(省略部分无关信息)

*.audit_file_dest='/oracle/admin/racdb/adump'

*.audit_trail='NONE'

*.cluster_database=true

*.compatible='11.2.0.4.0'

*.control_files='+DGSYS/racdb/control01.ctl','+DGSYS/racdb/control02.ctl'

*.db_block_size=16384

*.db_domain=''

*.db_name='racdb'

*.deferred_segment_creation=FALSE

*.diagnostic_dest='/oracle'

*.event='28401 TRACE NAME CONTEXT FOREVER, LEAVE 1'

racdb2.instance_number=2

racdb1.instance_number=1

........(省略部分无关信息)

racdb1.thread=1

racdb2.thread=2

racdb2.undo_tablespace='UNDOTBS1'

*.event='28401 TRACE NAME CONTEXT FOREVER, LEAVE 1'  

一下吸引了我的注意力,尝试注释掉之后重启数据库,正常启动。

大家注意看:LEAVE 1  LEVEL 1 ?

最后询问,是由于我们之前一个同事在刚建完数据库进行参数调整的时候,自己手工输入的,导致输入错误,但是一直没有重启过,所以这一次刚好赶上了。还好不是大问题。可见作为DBA 细心是多么重要啊!!!



小扩展:

设置28401事件,避免应用的数据库用户登录错误造成数据库相关锁影响业务,重启数据库生效;

alter system set event ="28401 TRACE NAME CONTEXT FOREVER, LEVEL 1" scope=spfile sid='*';

   

  于北京   201699   王慧 tyger

昵  称:
邮  箱:
评论内容:
验 证 码:
可用[code][/code]插入代码
点击刷新验证码