ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SCN研究报告(2)

SCN研究报告(2)

原创 Linux操作系统 作者:lr850525 时间:2008-03-13 23:24:48 0 删除 编辑

实验1:数据库正常运行时的各个SCN值

SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
                  547250

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
            546296

SQL>  select name,checkpoint_change# from v$datafile_header where name like '%USERS01%';
NAME                                                                                   CHECKPOINT_CHANGE#
------------------------------------------------------                      ---------------------------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF         546296

SQL> select name,last_change# from v$datafile where name like '%USERS01%';
NAME                                                                                    LAST_CHANGE#
------------------------------------------------------                      ------------------------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF

SQL> select name,checkpoint_change# from v$datafile_header where name like '%USERS01%';
NAME                                                                                   CHECKPOINT_CHANGE#
------------------------------------------------------                     ----------------------------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF        546296

我们得到如下证实:
redo file中的SCN是略大于其他SCN(当然也有可能相等的)
System checkpoint SCN=Datafile checkpoint SCN=Start SCN
Stop SCN是一个NULL值

 

实验2:数据库正常关闭后的各scn值
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
            549670

SQL> select name,checkpoint_change# from v$datafile_header where name like '%USERS01%';

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF
            549670


SQL> select name,last_change# from v$datafile where name like '%USERS01%';

NAME
--------------------------------------------------------------------------------
LAST_CHANGE#
------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF
      549670


SQL> select name,checkpoint_change# from v$datafile_header where name like '%USERS01%';

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF
            549670

System checkpoint SCN=Datafile checkpoint SCN=Start SCN=Stop SCN

实验3:数据库非正常关闭后的个scn之比较

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
            549671

SQL> select name,checkpoint_change# from v$datafile_header where name like '%USERS01%';

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF
            549671


SQL> select name,last_change# from v$datafile where name like '%USERS01%';

NAME
--------------------------------------------------------------------------------
LAST_CHANGE#
------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF

SQL> select name,checkpoint_change# from v$datafile_header where name like '%USERS01%';

NAME
--------------------------------------------------------------------------------
CHECKPOINT_CHANGE#
------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\LRDB\USERS01.DBF
            549671

System checkpoint SCN=Datafile checkpoint SCN=Start SCN
Stop SCN是一个NULL值

当clean shutdown 时,checkpoint会进行,并且此时datafile的stop scn和start scn会相同。 等到我们开启数据库时,Oracle检查datafile header中的start scn和存于control file中的datafile的scn是否相同,如果相同,接著检查start scn和stop scn是否相同,如果仍然相同,数据库正常开启,否则就需要recovery... 等到数据库开启后,存于在control file中的stop scn就会恢复为NULL值,此时表示datafile是open在正常模式下了。

如果不正常SHUTDOWN (shutdown abort),则mount数据库后,你会发现stop scn并不是等于其他位置的scn,而是等于NULL,这表示Oracle在shutdown时沒有进行checkpoint,下次开启数据库时必须crash recovery。

实验4:crash recovery vs media recovery
STOP SCN equal NULL ==> NEED CRASH RECOVERY
DATAFILE HEADER START SCN not equal CONTROLFILE SCN ==> NEED MEDIA RECOVERY

RECOVERY DATABASE 两种常见问题

1) RECOVER DATABASE UNTIL CANCEL ==> OPEN DATABASE RESETLOG

==> DATAFILE HEADER SCN一定會小於CONTROLFILE的DATAFILE SCN

如果你有进行RESTORE DATAFILE,则该RESTORE的DATAFILE HEADER SCN一定会小于目前CONTROLFILE的DATAFILE SCN,此时会无法
开启数据库,必须进行media recovery~~重做archive log直到该datafile header的SCN=current scn

restore datafile后,可以mount database然后去检查controlfile and datafile header的SCN

select 'controlfile' "SCN location",name,checkpoint_change#
from v$datafile where name like '%users01%'
union
select 'file header',name,checkpoint_change#
from v$datafile_header where name like '%users01%';

SCN location NAME CHECKPOINT_CHANGE#
-------------- ----------------------------------- --------------------
controlfile /u02/oradata/OMFD1/users01.dbf 313551
file header /u02/oradata/OMFD1/users01.dbf 313401

2) RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; ===> OPEN DATABASE RESETLOG
==> DATAFILE HEADER SCN一定会大于CONTROLFILE的DATAFILE SCN

如果只是某TABLE被DROP掉,沒有破坏数据库文件,还可以用INCOMPLETE RECOVERY解決 如果是某个TABLESPACE OR DATAFILE被DROP掉,因为数据文件遭到破坏,目前的CONTROL FILE內已经沒有 该DATAFILE的信息,就算你只RESTORE DATAFILE然后进行INCOMPLETE RECOVERY也无法救回被DROP的DATA FILE。

只好RESOTRE 之前备份的CONTROL FILE(里头呗DROP DATAFILE Metadata此时还存在),不过RESTOREC CONTROL FILE后此时Oracle会发现CONTROL FILE內的SYSTEM SCN会小于目前的DATAFILE HEADER SCN,也不等于目前存于LOG FILE內的SCN,此时就必须使用RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE到DROP DATAFILE OR DROP TABLESPACE之前的SCN。


另一种特殊情况就是,万一不幸地所有CONTROL FILE都遗失了,也必须用这种方式救回

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9421572/viewspace-206239/,如需转载,请注明出处,否则将追究法律责任。

上一篇: SCN研究报道(1)
下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2008-02-22

  • 博文量
    5
  • 访问量
    3961