这是实际生产系统中关于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文件的麻烦，减少了犯错的可能。
