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

记一次控制文件序列号满的分析处理过程，聊聊我的思路。技术人人都可以磨炼，但处理问题的思路和角度各有不同，希望这篇文章可以抛砖引玉。

以一个例子为切入点

---

一、问题背景

基础环境：

• 主机类型：x3850 X6
• 操作系统：DB:CentOS Linux release 7.4.1708、APP:CentOS Linux release 7.2.1511 (Core)
• 存储：IBM存储，2TB,MULTIPATH
• 内存：32 G
• CPU型号：E7-4830 v3 @ 2.10GHz ( 4 U * 12 core)
• CPU核数：32CORE
• 数据库环境：11.2.0.4（单机）

问题现象：测试环境数据库启动时出现报错。

 

二、分析说明

• 通过分析日志定位、分析故障原因；
• 追溯历史数据，分析关键指标的历史波动,这些关键指标可以用来做为数据库健康度参考指标。
• 用实际数据来验证推断，排除掉其它干扰因素，定位数据库问题的根本原因，帮助快速修复。

三、疑问点排查及分析思路

1、数据库启动报错。
数据库mount时出现报错，告警日志告诉我们控制文件序列号满了。

 

 

既然是控制文件出现问题，先尝试用rman准备恢复控制文件，但是测试环境没有做rman备份..

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

2、重建控制文件
启动不到mount状态，只能手动创建控制文件。慎重起见，先将当前控制文件做个备份。

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

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/test.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;

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

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

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

 

快速恢复区满和控制文件序列号有关系吗？
我做了一个实验。
查询控制文件当前序列号：序列号为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

 

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

 

总结

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