本文共 6147 字，大约阅读时间需要 20 分钟。
在启动数据库的时候,open阶段总是可能出现各种各样的问题，
比如让人胆战心惊的错误。ORA-01113: file 1 needs media recovery 自己留意了一下，其实还是有蛮多的场景会出现这个问题，有些细节可能没有注意到就会出现这个问题，比如我们重建控制文件的时候。 在重建控制文件之前做了shutdown abort的操作。 SQL> shutdown abort ORACLE instance shut down. SQL> startup nomount ORACLE instance started.Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes Variable Size 163577860 bytes Database Buffers 142606336 bytes Redo Buffers 7127040 bytes SQL> CREATE CONTROLFILE REUSE DATABASE "TEST10G" NORESETLOGS NOARCHIVELOG ..... 26 '/u02/oracle/oradata/data02.dbf' 27 CHARACTER SET US7ASCII 28 ;Control file created.
尝试启动数据库的时候就会抛出这个错误。SQL> alter database open;
alter database open * ERROR at line 1:ORA-01113: file 1 needs media recovery ORA-01110: data file 1: '/u02/oracle/oradata/TEST10G/disk5/system01.dbf'其实这个时候简单分析一下就会明白，上次是shutdown abort的方式，则对应的检查点信息无法写入数据文件，在open阶段smon会做这个校验。
开始在后台做数据的前滚，然后应用redo日志的数据，对某些操作做相应的回滚。 从下面的地方可以看出 last_change#没有任何值，表明上次断电重启后检查点信息没有写入。 SQL> select file#,checkpoint_change#,last_change# from v$datafile;FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------ 1 858940 2 858940 3 858940 4 858940 5 858940SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------ 1 858940 2 858940 3 858940 4 858940 5 858940SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------ 858939 这个时候尝试恢复数据库，再次观察，则相应的检查点信息就做了校正。SQL> recover database;
Media recovery complete. SQL> select checkpoint_change# from v$database;CHECKPOINT_CHANGE#
------------------ 858939 SQL> select file#,checkpoint_change#,last_change# from v$datafile;FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------ 1 859017 859017 2 859017 859017 3 859017 859017 4 859017 859017 5 859017 859017SQL> alter database open;
Database altered.
数据库启动之后，last_change#的值又回归零。等待稍后的检查点写入。SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------ 1 879019 2 879019 3 879019 4 879019 5 879019SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------ 879019其实这个过程中，恢复的基准就是检查点，也就是SCN.
当然在有些操作依赖于归档模式，介质恢复还是依赖于一些归档文件的。 像在非归档模式尝试下面的操作就不可行。SQL> alter tablespace data offline immediate;
alter tablespace data offline immediate * ERROR at line 1: ORA-01145: offline immediate disallowed unless media recovery enabledSQL> alter tablespace data begin backup; alter tablespace data begin backup * ERROR at line 1: ORA-01123: cannot start online backup; media recovery not enabled
这个时候还是启用归档。
SQL> shut immediate
Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started.Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes Variable Size 163577860 bytes Database Buffers 142606336 bytes Redo Buffers 7127040 bytes Database mounted. SQL> alter database archivelog ;Database altered.
SQL> alter database open;
Database altered.
如果在归档模式中，使用热备份，需要声明begin backup,为了能够修复在热备份过程中可能产生的分裂数据块。SQL> alter tablespace data begin backup;
Tablespace altered.
这个时候停库就会抛错。SQL> shutdown immediate;
ORA-01149: cannot shutdown - file 5 has online backup set ORA-01110: data file 5: '/u02/oracle/oradata/data02.dbf' 如果发生断电现象，则在重启的时候出现ORA-01113: file 5 needs media recovery就需要明辨这个错误背后的意思 SQL> shutdown abort ORACLE instance shut down. SQL> startup ORACLE instance started.Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes Variable Size 163577860 bytes Database Buffers 142606336 bytes Redo Buffers 7127040 bytes Database mounted.ORA-01113: file 5 needs media recovery ORA-01110: data file 5: '/u02/oracle/oradata/data02.dbf'其实碰到这个错误，还是需要结合多种场景来考虑，比如查看是否热备份已经正常完成，之前的操作是什么样的？
SQL> desc v$backup Name Null? Type ----------------------------------------- -------- ---------------------------- FILE# NUMBER STATUS VARCHAR2(18) CHANGE# NUMBER TIME DATESQL> select *from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------- 1 NOT ACTIVE 0 2 NOT ACTIVE 0 3 NOT ACTIVE 0 4 NOT ACTIVE 0 5 ACTIVE 879352 20-JUL-15 可以从SCN的地方看出和重建控制文件的场景还是存在一定的差别。 SQL> select file#,checkpoint_change#,last_change# from v$datafile;FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------ 1 879275 2 879275 3 879275 4 879275 5 879352SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------ 1 879275 2 879275 3 879275 4 879275 5 879352SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------ 879275 明白了问题，修复就很容易了，果断结束热备份。SQL> alter tablespace data end backup;
Tablespace altered.
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------ 1 879275 2 879275 3 879275 4 879275 5 879352SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------ 879275 这个时候启动数据库就没有问题了。SQL> alter database open;
Database altered.
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------ 899361SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------ 1 899361 2 899361 3 899361 4 899361 5 899361 其实热备份的这个错误也可以这么来处理。SQL> alter tablespace data begin backup;
Tablespace altered.
SQL> shutdown abort
ORACLE instance shut down. SQL> startup ORACLE instance started.Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes Variable Size 163577860 bytes Database Buffers 142606336 bytes Redo Buffers 7127040 bytes Database mounted. ORA-01113: file 5 needs media recovery ORA-01110: data file 5: '/u02/oracle/oradata/data02.dbf'SQL> recover datafile 5; Media recovery complete. SQL> alter database open;Database altered.
SQL> select *from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------- 1 NOT ACTIVE 0 2 NOT ACTIVE 0 3 NOT ACTIVE 0 4 NOT ACTIVE 0 5 NOT ACTIVE 899488 20-JUL-15总之解决问题就行，SCN的部分着实是需要关注的一个重点，这也是备份恢复的基石。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1742631/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-1742631/