墨墨导读:本文来自墨天轮用户罗海鸥的投稿,墨天轮主页:https://www./u/366206,分享 Oracle 11.2.0.4 版本的单机数据库无法启动处理的整个过程。 sqlplus / as sysdba startup 这时猜测,问题可能是控制文件。然后便登录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; 至此,问题已解决,数据库继续运行。但为什么控制文件序列号会异常增长呢? 带着这个问题继续翻阅告警日志,发现控制文件序列号满是一个多月前开始报错的,这个报错前是快速恢复区满的报错,这个报错也持续了很长时间大概一个月。 快速恢复区满和控制文件序列号有关系吗?我做了一个实验。 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; select CONTROLFILE_CREATED, CONTROLFILE_SEQUENCE#,CONTROLFILE_CHANGE#, CURRENT_SCN from v$database 修改快速恢复区大小后,控制文件序列号不再异常增长。 总结 快速恢复区满会导致控制文件序列号异常增长,快速恢复区满应当及时处理。 作者 罗海鸥:中国DBA联盟(ACDU)成员,北京银信DBA工程师,Oracle 11g OCM,长期研究Oracle技术,擅长备份恢复和性能调优。 |
|