scn说明

SCN是��Oracle�Y料更新後，由DBMS自�泳S�o去累�e�f增的一���底帧� ��一��交易commit�r，LGWR����log buffer��入redo log file，同�r也���⒃��P交易的 SCN同步��入到redo log file��(wait-until-completed)。因此��你commit transaction�r， 在交易成功的�息返回之前，LGWR必�先完整的完成上述行�橹�後，否�t你是看不到提交成功的回���息。

我��可以查�目前系�y最新的SCN

select dbms_flashback.get_system_change_number from dual;

可以理解的，�@�e返回的SCN，也是目前redo log file最新的SCN�o�。 因��commit後的交易才��有SCN，而一旦commit就��立刻��入redo log file中。

CHECKPOINT 和 SCN 的�P�B

checkpoint�l生的目的就是要把�Υ嬖�buffer�鹊囊烟峤唤灰��回disk，否�t一旦�l生crash，需要 �M行recovery�r，你就必�花很多的�r�g��redo log file�茸钺岬�SCN交易�_始�M行recovery，�@�� 在商�I��用上是很浪�M�r�g和�]有效率的。

重�c在於��commit一��交易�r，只��立刻��redo buffer��入redo log file�龋�但是�K不���R上�� �update後的block(dirty block)同步��回disk datafile中，�@是�榱�p少�^多disk IO的考量，所以�袢�batch的方式��入。

When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk; DBWn always performs that work.

在shutdown normal or shutdown immediate下，也就是所�^的clean shutdown，checkpoint也��自�佑|�l，�K且把SCN�o���回。 ���l生checkpoint�r，��把SCN��到四��地方去。 三��地方於control file�龋�一��在datafile header。

Control file三��地方��

1.System checkpoint SCN ===========> (SYSTEM CHECKPOINT SCN in control file)

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
--------------------
292767

2.Datafile checkpoint SCN ===============> (DATAFILE CHECKPOINT SCN in control file)

SQL> select name,checkpoint_change#
from v$datafile where name like '%users01%';

NAME CHECKPOINT_CHANGE#
----------------------------------- --------------------
/u02/oradata/OMFD1/users01.dbf 292767

3.Stop SCN ======================> (STOP SCN in control file)

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

NAME LAST_CHANGE#
----------------------------------- ------------
/u02/oradata/OMFD1/users01.dbf

正常datafile在read-write mode咦飨拢�Last_change#一定是NULL

另外一��地方在datafile header��

4.Start SCN ================================> (DATAFILE HEADER)

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

NAME CHECKPOINT_CHANGE#
----------------------------------- --------------------
/u02/oradata/OMFD1/users01.dbf 292767

�槭颤N�Υ嬖�CONTROL FILE中要分����地方(SYSTEM CHECKPOINT SCN,DATAFILE CHECKPOINT SCN ?) ��你把一��tbs�O��read-only�r，他的SCN���鼋Y停止，此�rDATAFILE CHECKPOINT SCN是不��再�f增改�的， 但是整�w的SYSTEM CHECKPOINT SCN�s仍然��不�噙f增前�M。
所以，�@就是�槭颤N需要分�e在���地方�Υ�SCN。

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

正常shutdown database後，SCN���l生什�N�化？

我��可以把�Y料�扉_在mount mode

select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
--------------------
293184

select name,checkpoint_change#,last_change# from v$datafile where name like '%user%';

NAME CHECKPOINT_CHANGE# LAST_CHANGE#
----------------------------------- -------------------- --------------
/u02/oradata/OMFD1/users01.dbf 293184 293184

可以看到�Υ嬖�control file中的三��SCN位置都是相同，注意此�r的stop scn不��是NULL，而是等於start scn

我��也�聿樵�datafile header SCN:

select name,checkpoint_change# from v$datafile_header where name like '%users01%';

NAME CHECKPOINT_CHANGE#
----------------------------------- --------------------
/u02/oradata/OMFD1/users01.dbf 293184

��clean shutdown �r，checkpoint���M行，�K且此�rdatafile的stop scn和start scn��相同。 等到我�T�_�①Y料��r，Oracle�z查datafile header中的start scn和存於control file中的datafile的scn是否相同， 如果相同，接著�z查start scn和stop scn是否相同，如果仍然相同，�Y料�炀��正常�_��，否�t就需要recovery... 等到�Y料�扉_�⑨幔��Υ嬖�control file中的stop scn就��恢���NULL值，此�r表示datafile是open在正常模式下了。

如果不正常SHUTDOWN (shutdown abort)，�tmount�Y料�灬幔�你���l�Fstop scn�K不是等於其他位置的scn， 而是等於NULL，�@表示Oracle在shutdown�r�]有�M行checkpoint，下次�_�C必��M行crash recovery。

crash recovery

必�先�M行roll forward(��redo log file中�哪壳暗�start SCN�_始，重做後面的已提交之交易)
再��roll back segment 做rollback未完成(dead transaction)交易

�z�controlfile中的SCN��等於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 293188
file header /u02/oradata/OMFD1/users01.dbf 293188

crash recovery vs media recovery

��淤Y料��r，如果�l�FSTOP SCN = NULL，表示需要�M行crash recovery；��淤Y料��r，如果�l�F有datafile header的START SCN 不等於�Υ骒�CONTROLFILE的DATAFILE SCN，表示需要�M行Media recovery

STOP SCN equal NULL ==> NEED CRASH RECOVERY
DATAFILE HEADER START SCN not equal CONTROLFILE SCN ==> NEED MEDIA RECOVERY

RECOVERY DATABASE �煞N常����}

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

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

如果你有�M行RESTORE DATAFILE，�t�RESTORE的DATAFILE HEADER SCN一定��小於目前CONTROLFILE的DATAFILE SCN，此�r���o法
�_�①Y料�欤�必��M行media recovery~~重做archive log直到�datafile header的SCN=current scn

restore datafile後，可以mount database然後去�z查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掉，�]有破�馁Y料�煺��w�Y料�Y��，�可以用INCOMPLETE RECOVERY解�Q 如果是某��TABLESPACE OR DATAFILE被DROP掉，因��n案�Y��已�破�模�目前的CONTROL FILE�纫呀��]有 �DATAFILE的�Y�，就算你只RESTORE DATAFILE然後�M行INCOMPLETE RECOVERY也�o法救回被DROP的DATA FILE。

只好RESOTRE 之前�浞莸�CONTROL FILE(�e�^被DROP DATAFILE Metadata此�r�存在)，不�^RESTOREC CONTROL FILE後 此�rOracle���l�FCONTROL FILE�鹊�SYSTEM SCN��小於目前的DATAFILE HEADER SCN，也不等於目前�Υ骒�LOG FILE�鹊�SCN， 此�r就必�使用RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE到DROP DATAFILE OR DROP TABLESPACE之前的SCN。

另一�N特殊��r就是，�f一不幸地所有CONTROL FILE都�z失了，也必�用�@�N方式救回，所以�做MULTIPLEXING。

0人

了这篇文章

类别：未分类┆阅读( 0)┆评论( 0) ┆ 返回博主首页┆ 返回博客首页

上一篇 checkpoint说明 下一篇 PGA自动管理原理深入分析及性能调整