案例：控制文件序列号满故障处理和分析

墨墨导读：本文来自墨天轮用户罗海鸥的投稿，墨天轮主页：https://www.modb.pro/u/366206，分享 Oracle 11.2.0.4 版本的单机数据库无法启动处理的整个过程。

首先启动数据库

sqlplus / as sysdbastartup

数据库mount时出现报错，当时报错内容记不清了，应该是无法锁定控制文件。

随即我打开了告警日志，在告警日志中我发现了一些蛛丝马迹：

告警日志告诉我们控制文件序列号满了

这时猜测，问题可能是控制文件。然后便登录rman准备恢复控制文件，但是rman没有任何备份。

没有备份那就重建控制文件吧。

在nomount阶段，我尝试备份控制文件到trace

可惜nomount阶段无法备份控制文件，那就只能手工编辑然后重建控制文件了。

慎重起见，将现在的控制文件改名了（此步骤省略）

如下是根据日志文件，数据文件等信息编辑的。

CREATE CONTROLFILE REUSE DATABASE “ORCL” RESETLOGS ARCHIVELOGMAXLOGFILES 16MAXLOGMEMBERS 3MAXDATAFILES 100MAXINSTANCES 8MAXLOGHISTORY 292LOGFILEGROUP 1 ‘/data/orcl/redo01.log’ SIZE 50M BLOCKSIZE 512,GROUP 2 ‘/data/orcl/redo02.log’ SIZE 50M BLOCKSIZE 512,GROUP 3 ‘/data/orcl/redo03.log’ SIZE 50M BLOCKSIZE 512– STANDBY LOGFILEDATAFILE‘/data/orcl/system01.dbf’,‘/data/orcl/sysaux01.dbf’,‘/data/orcl/undotbs01.dbf’,‘/data/orcl/users01.dbf’,‘/data/orcl/assp.dbf’,‘/data/orcl/gap.dbf’,‘/data/orcl/estamp.dbf’CHARACTER SET ZHS16GBK;

控制文件创建好了，执行如下步骤打开了数据库。

RECOVER DATABASE；ALTER DATABASE OPEN RESETLOGS;ALTER TABLESPACE TEMP ADD TEMPFILE ‘/data/orcl/temp01.dbf’ SIZE 52428800 REUSE AUTOEXTEND ON NEXT 8192 MAXSIZE 32767M;

因为重建了控制文件，所以现在的序列号很小。

至此，问题已解决，数据库继续运行。

但为什么控制文件序列号会异常增长呢？

带着这个问题继续翻阅告警日志，发现控制文件序列号满是一个多月前开始报错的，这个报错前是快速恢复区满的报错，这个报错也持续了很长时间大概一个月。

快速恢复区满和控制文件序列号有关系吗？我做了一个实验。

查询控制文件当前序列号：序列号为12233

select CONTROLFILE_CREATED, CONTROLFILE_SEQUENCE#,CONTROLFILE_CHANGE#, CURRENT_SCN from v$database

修改快速恢复区大小，目的是让db_recovery_file_dest_size   is 100.00% used。

alter system set db_recovery_file_dest_size=200M; （对于这个数据已经足够小了）

告警日志立马打印如下信息

ORA-19815: WARNING: db_recovery_file_dest_size of 209715200 bytes is 100.00% used, and has 0 remaining bytes available.

手工切换一下日志，往快速恢复区存归档，触发一下；

alter system switch logfile;

继续查询控制文件序列号，发现序列号以大约200/s的速度异常增长，这样持续下去控制文件序列号很快会被用完。

select CONTROLFILE_CREATED, CONTROLFILE_SEQUENCE#,CONTROLFILE_CHANGE#, CURRENT_SCN from v$database

修改快速恢复区大小后，控制文件序列号不再异常增长。

总结

快速恢复区满会导致控制文件序列号异常增长，快速恢复区满应当及时处理。

作者

罗海鸥：中国DBA联盟（ACDU）成员，北京银信DBA工程师，Oracle 11g OCM，长期研究Oracle技术，擅长备份恢复和性能调优。