oracle system change number(SCN)
一.概念
SCN是当oracle资料更新后，由DBMS自动去累计递增的一个数字。
当一个事物commit,LGWR就会将log buffer写入redo log file,同时也会将该事物的scn号redo log file.
在未完成该动作之前,commit是不会成功的。
查询系统最新的scn.
select dbms_flashback.get_system_change_number from dual;
这里返回的scn号，就是目前redo log file最新的scn记录
二.checkpoint和scn的关联
checkpoint发生的目的就是要把存储在buffer内的已提交的事物写会disk,否在一旦Instance creash,就需要从redo log file里面恢复数据，严重影响到db的效率
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.Dbwm always performs that work
commit一个事物时，只会立即将redo buffer写入redo log file内，但是并不会马上将该update后的block写入disk datafile,这是为了减少disk io的考量，
所以采用batch(批量)的方式写入disk
在shutdown normal or shutdown immediate下，也就是说clean shutdown,checkpoint也会自动触发，并且把scn记录写会。当发生checkpoint时，
会将scn写到四个地方去，三个地方在controlfile内，一个在datafile hearder
controlfile
1.system checkpoint scn
SQL> select checkpoint_change# from v$database;
2.datafile checkpoint scn
SQL> select name,checkpoint_change# from v$datafile
3.stop scn
SQL> select name,last_change#
from v$datafile ;
正常情况下 在read-write mode下 该last_change#一定是空的，因为datafile scn会中会一直变化
datafile
start scn
SQL> select name,checkpoint_change#
from v$datafile_header where name like '%users01%';
需要特别注意的一点是
为什么存储在controlfile 要分为system checkpoint scn和datafile checkpoint scn ,因为
当你把一个tbs设为redo-only的时候，datfile checkpoint scn是不会在变的，但是整体的system chckpoint仍然会增加
clean shutdown 时，checkpoint会进行，此时datafile 的stop scn和start scn是一致的，再次开启数据库时
oracle会检查datafile header中的start scn和控制文件中的datafile scn是否一致，接着检查start scn和stop scn是否相同，如果仍然相同
数据库正常开启，否则需要recovery
正常shutdown database后，scn的情况
此时，控制文件中的三个scn位置都是相同的，而stop scn不会是null,而是等于start scn
crash recovery
必须先从roll forward（从redo log file中从目前的start scn开始，重做后面的已提交之交易）
在从roll back segment 做rollback 未完成(dead transation)的交易
完成后，controlfile中的scn会等于datafile header的scn
crash recovery 对比media recovery
启动数据库时，如果发现stop scn为null,表示需要进行crash recovery,如果发现datafile header的start scn的start scn不等于存储在controlfile中的
datafile scn，表示需要进行media recovery
recovery database的两种常见问题
a.recover database until cancel=>open database resetlog
如果数据库进行过restore datafile,则该restore的datafile header一定小于目前contreolfile的datafile scn,必须进行介质恢复，
重做archivelog 直到datasfile header的scn=current scn
b.recover database until cancel using backup controlfile:=>open database resetlog
=>datafile header scn一定会大于controlfile 的datafile scn
使用场景，某个tablespace或datafile被drop掉，因为档案数据已经破坏，目前的controlfile已经
没有该datafile的信息，这时候就算用restore recovery也没有用
只能restore以前备份的controlfile
这时候controlfile的scn号一定会小于系统当前的scn,也不等于log file内的scn,
就必须使用recover database until cancel using backup controlfile 到drop tablespace或datafile的scn