参数文件诊断案例

Eygle 2019-07-24
13
0 0
摘要:参数文件诊断案例

这是实际生产系统中关于spfile的一个案例问题,具体的问题诊断和主要解决步骤说明如下。系统情况说明:

    操作 系统:SUN Solaris 8

    数据库版本:Oracle 9.2.0.3

    问题描述:工程人员报告,数据库在重新启动时无法正常启动,检查发现UNDO表空间丢失。

登陆系统检查告警日志文件文件

在此有必要简单的介绍一下告警日志文件。告警日志文件由按时间顺序排列的消息和错误的记录组成。

下列信息会记录在警报日志文件中

    内部错误 (ORA-600,ORA-07445等错误信息) 和块损坏错误 (ORA-1578)

    影响数据库结构和参数的操作和诸如 CREATE DATABASE,STARTUP,SHUTDOWN,ARCHIVE LOG 和 RECOVER 之类的语句

    例程启动时所有非缺省的初始化参数值

数据库管理员定期检查告警日志文件是很重要的,这样就可以在问题变得严重之前发现它们,并及时处理,在我们的生产环境中,告警日志按照以5分钟为间隔进行检测,如果发现任何错误提示或警报信息,就发送邮件给数据库管理员,请求人为介入管理。

由于告警日志文件是不停累计的,所以在检查以后可以按照规定备份或整理告警日志文件。告警日志文件的存储位置由始化参数BACKGROUND_DUMP_DEST定义:

SQL> show parameter background_dump_dest
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
background_dump_dest                 string      /opt/oracle/admin/danaly/bdump
其缺省文件名为 alert_<ORACLE_SID>.log

注意:由于告警日志文件的重要作用,当数据库出现故障时,通常我们最先的处理步骤是检查该文件,以发现相关错误信息或线索,快速找到问题所在。这是DBA必须明确的一个知识点。

此次故障诊断,首先检查告警日志文件,发现其中包含如下错误信息:

Thu Apr  1 11:11:28 2004
Errors in file /oracle/admin/gzhs/udump/gzhs_ora_27781.trc:
ORA-30012: undo tablespace 'UNDOTBS1' does not exist or of wrong type  
Thu Apr  1 11:11:28 2004
Error 30012 happened during db open, shutting down database
USER: terminating instance due to error 30012
Instance terminated by USER, pid = 27781
ORA-1092 signalled during: alter database open...

在告警日志末尾显示了数据库在Open状态因为错误而异常终止.最后出错的错误号是ORA-30012,该错误的含义是:

[oracle@jumper oracle]$ oerr ora 30012
30012, 00000, "undo tablespace '%s' does not exist or of wrong type"
// *Cause:   the specified undo tablespace does not exist or of the
//           wrong type.
// *Action:  Correct the tablespace name and reissue the statement.

这说明是UNDO表空间不存在导致出现问题。


尝试重新启动数据库

尝试重新启动数据库,检查问题是否仍然存在:

bash-2.03$ sqlplus "/ as sysdba"
 
SQL*Plus: Release 9.2.0.3.0 - Production on 星期四 4月 1 11:43:52 2004
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
已连接到空闲例程。
 
SQL> startup
ORACLE 例程已经启动。
 
Total System Global Area 4364148184 bytes
Fixed Size                   736728 bytes
Variable Size            1845493760 bytes
Database Buffers         2516582400 bytes
Redo Buffers                1335296 bytes
数据库装载完毕。
ORA-01092: ORACLE 例程终止。强行断开连接
在Open步骤,例程终止,问题重现。

检查数据文件

既然是UNDO表空间丢失,接下来需要确认一下相关数据文件,看UNDO表空间数据文件是否存在:

bash-2.03$ cd /u01/ oradata/gzhs
bash-2.03$ ls -l
total 55702458
-rw-r-----   1 oracle   dba      1073750016 Apr  1 11:44 UNDOTBS2.dbf
-rw-r-----   1 oracle   dba      1073750016 Apr  1 11:44 WAP12_BILLINGDETAIL.dbf
-rw-r-----   1 oracle   dba      1073750016 Apr  1 11:44 WAP12_MAIN.dbf
………………
-rw-r-----   1 oracle   dba      1073750016 Apr  1 11:44 WAP12_MVIEW.dbf

通过检查发现存在文件UNDOTBS2.dbf ,大小约为1G。

mount数据库,检查系统参数

既然存在一个UNDO表空间文件,用户又没有主动执行删除操作,那么极其可能的就是参数设置出了问题,将数据库启动到Mount状态,检查一下当前参数设置:

SQL> startup mount;
ORACLE 例程已经启动。
………
数据库装载完毕。
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/u01/oradata/gzhs/system01.dbf
……..
/u01/oradata/gzhs/UNDOTBS2.dbf
SQL> show parameter undo
NAME                            TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                    string      AUTO
undo_retention                     integer     10800
undo_suppress_errors               boolean     FALSE
undo_tablespace                    string      UNDOTBS1
SQL> show parameter spfile
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string
检查发现系统没有使用spfile,,初始化参数设置的undo表空间为UNDOTBS1,数据库中登记的UNDO文件为UNDOTBS2.dbf。
检查参数文件
检查一下pfile文件中的设置,发现undo表空间参数设置的是UNDOTBS1.
bash-2.03$ cd $ORACLE_HOME/dbs
bash-2.03$ vi initgzhs.ora
"initgzhs.ora" [Incomplete last line] 105 lines, 3087 characters
…………
###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_retention=10800
undo_tablespace=UNDOTBS1

这个设置是极其可疑的,也就是说,参数设置可能和数据库的实际情况不符。

再次检查alert文件

告警日志文件中记录了对于数据库重要操作的信息,可以从中查找对于UNDO表空间的操作。

 

第一部分,创建数据库时的信息:

Sat Feb  7 20:30:12 2004
CREATE DATABASE gzhs
MAXINSTANCES 1 MAXLOGHISTORY 1 MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 100
DATAFILE '/u01/oradata/gzhs/system01.dbf' SIZE 500M REUSE AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/u01/oradata/gzhs/temp01.dbf' SIZE 1000M REUSE AUTOEXTEND ON NEXT  250M MAXSIZE UNLIMITED
UNDO TABLESPACE "UNDOTBS1" DATAFILE '/u01/oradata/gzhs/undotbs01.dbf' SIZE 1000M REUSE AUTOEXTEND ON NEXT  100M MAXSIZE UNLIMITED
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 ('/u01/oradata/gzhs/redo01.log') SIZE 256M,
GROUP 2 ('/u01/oradata/gzhs/redo02.log') SIZE 256M,
GROUP 3 ('/u01/oradata/gzhs/redo03.log') SIZE 256M

 

第二部分,发现创建UNDOTBS2的记录信息:

Wed Mar 24 20:20:58 2004
/* OracleOEM */ CREATE UNDO TABLESPACE "UNDOTBS2" DATAFILE '/u01/oradata/gzhs/UNDOTBS2.dbf' SIZE 1024M AUTOEXTEND ON NEXT  100M MAXSIZE UNLIMITED
Wed Mar 24 20:22:37 2004
Created Undo Segment _SYSSMU11$
Created Undo Segment _SYSSMU12$
Created Undo Segment _SYSSMU13$
Completed: /* OracleOEM */ CREATE UNDO TABLESPACE "UNDOTBS2"
Wed Mar 24 20:24:25 2004
Undo Segment 11 Onlined
Undo Segment 12 Onlined
Undo Segment 13 Onlined
Successfully onlined Undo Tablespace 15.
Undo Segment 1 Offlined
Undo Segment 2 Offlined
Undo Segment 3 Offlined
Undo Tablespace 1 successfully switched out.

第三部分,新的UNDO表空间被应用

Wed Mar 24 20:24:25 2004
ALTER SYSTEM SET undo_tablespace='UNDOTBS2' SCOPE=MEMORY;

问题就在这里,创建了新的UNDO表空间以后,因为使用的是pfile文件,切换表空间的修改的只对当前实例生效,操作人员忘记了修改pfile文件。

如果使用spfile,缺省的修改范围是both,会同时修改spfile文件,就可以避免以上问题的出现。

 

第四部分,删除了UNDOTBS1的信息

Wed Mar 24 20:25:01 2004
/* OracleOEM */ DROP TABLESPACE "UNDOTBS1" INCLUDING CONTENTS  AND DATAFILES  CASCADE CONSTRAINTS
Wed Mar 24 20:25:03 2004
Deleted file /u01/oradata/gzhs/undotbs01.dbf
Completed: /* OracleOEM */ DROP TABLESPACE "UNDOTBS1" INCLUDI

这样再次重新启动数据库的时候,问题出现了,pfile中定义的UNDOTBS1找不到了,而且操作实在很久以前,没人能回忆起来,甚至无法得知是什么人的操作。

 

修正 pfile

找到了问题的根源,解决起来就简单了,我们修改pfile参数文件,就可以启动数据库:

bash-2.03$ vi initgzhs.ora
"initgzhs.ora" [Incomplete last line] 105 lines, 3087 characters
………………
###########################################
# System Managed Undo and Rollback Segments
###########################################
undo_management=AUTO
undo_retention=10800
undo_tablespace=UNDOTBS2
 
~
"initgzhs.ora" 105 lines, 3088 characters

 

启动数据库

重新启动,数据库可以正常打开,问题解决:

bash-2.03$ sqlplus "/ as sysdba"
 
SQL*Plus: Release 9.2.0.3.0 - Production on 星期四 4月 1 11:55:11 2004
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
SQL> select * from v$version where rownum <2;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production

经过了一系列的诊断过程,问题得以完满解决。在这里我们可以看到,使用spfile可以免去手工修改pfile文件的麻烦,减少了犯错的可能。


「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
Oracle
订阅
欢迎订阅Oracle频道,订阅之后可以获取最新资讯和更新通知。
墨值排行
今日本周综合
热门文章
近期活动
全部
相关课程
全部