开篇首先明确一点:介质恢复需要人为的介入,而实例恢复则完全由ORACLE自己解决,不需要借助人力
实例恢复是指数据库的datafile开始SCN和controlfile的SCN相吻合,而结果scn为空的情况。常见于非法断电,abort关闭数据库等情况
SQL> shutdown abort
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 535662592 bytes
Fixed Size 1375792 bytes
Variable Size 322961872 bytes
Database Buffers 205520896 bytes
Redo Buffers 5804032 bytes
数据库装载完毕。
SQL> desc v$datafile;
名称 是否为空? 类型
----------------------------------------- -------- ----------------------------
FILE# NUMBER
CREATION_CHANGE# NUMBER
CREATION_TIME DATE
TS# NUMBER
RFILE# NUMBER
STATUS VARCHAR2(7)
ENABLED VARCHAR2(10)
CHECKPOINT_CHANGE# NUMBER
CHECKPOINT_TIME DATE
UNRECOVERABLE_CHANGE# NUMBER
UNRECOVERABLE_TIME DATE
LAST_CHANGE# NUMBER
LAST_TIME DATE
OFFLINE_CHANGE# NUMBER
ONLINE_CHANGE# NUMBER
ONLINE_TIME DATE
BYTES NUMBER
BLOCKS NUMBER
CREATE_BYTES NUMBER
BLOCK_SIZE NUMBER
NAME VARCHAR2(513)
PLUGGED_IN NUMBER
BLOCK1_OFFSET NUMBER
AUX_NAME VARCHAR2(513)
FIRST_NONLOGGED_SCN NUMBER
FIRST_NONLOGGED_TIME DATE
FOREIGN_DBID NUMBER
FOREIGN_CREATION_CHANGE# NUMBER
FOREIGN_CREATION_TIME DATE
PLUGGED_READONLY VARCHAR2(3)
PLUGIN_CHANGE# NUMBER
PLUGIN_RESETLOGS_CHANGE# NUMBER
PLUGIN_RESETLOGS_TIME DATE
SQL> select CHECKPOINT_CHANGE#,LAST_CHANGE# from v$datafile;
CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
2013799
2013799
2013799
2013799
2013799
2013799
2013799
2013799
2013799
已选择9行。
可以看到,在执行了shutdown abort之后,我的数据库没有正常关闭,导致数据库没有正常记录结束的SCN号,造成结束SCN号为空,这是在open的时候,数据库就会进行实例恢复,并生产一个起始的SCN号。
SQL> alter database open;
数据库已更改。
SQL> select CHECKPOINT_CHANGE#,LAST_CHANGE# from v$datafile;
CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
2046503
2046503
2046503
2046503
2046503
2046503
2046503
2046503
2046503
已选择9行。
可以看到,数据库打开,生产了一个新的scn。
介质恢复,为了不刻意破坏数据库,建议使用archive模式进行操作。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21416913/viewspace-749360/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/21416913/viewspace-749360/