欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

ORA-01113问题的简单分析

程序员文章站 2022-06-14 19:46:38
...

在启动数据库的时候,open阶段总是可能出现各种各样的问题,比如让人胆战心惊的错误。ORA-01113: file 1 needs media recovery

在启动数据库的时候,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 858940

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 858940
2 858940
3 858940
4 858940
5 858940

SQL> 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 859017

SQL> 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 879019

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
879019

其实这个过程中,恢复的基准就是检查点,也就是SCN.

当然在有些操作依赖于归档模式,介质恢复还是依赖于一些归档文件的。
像在非归档模式尝试下面的操作就不可行。