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

接到客户电话说一个11.2.0.4版本的单机数据库无法启动，但是为什么无法启动客户没说。带着无法启动的疑惑，我投入了战斗。
首先启动数据库
sqlplus / as sysdba
startup

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

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

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

这时大概明白了，问题可能是控制文件。我登录rman准备恢复控制文件，但是rman没有任何备份，很无奈。

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

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

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

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

如下是重建控制文件语句，是根据数据文件，日志文件等信息编辑的

CREATE CONTROLFILE REUSE DATABASE “ORCL” RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 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 LOGFILE
DATAFILE
‘/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;

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

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

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

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

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

查询控制文件当前序列号：序列号为8745
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;

继续查询控制文件序列号，发现序列号以大约40/s的速度异常增长，这样持续下去控制文件序列号很快会被用完。
select CONTROLFILE_CREATED, CONTROLFILE_SEQUENCE#,CONTROLFILE_CHANGE#, CURRENT_SCN from v$database

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

总结：
快速恢复区满会导致控制文件序列号异常增长。

快速恢复区满应当及时处理，如果长时间未处理导致序列号满，需要重建控制文件。
复制