SCN研究报道（1）

这几天做一些恢复实验是遇到一些SCN的问题，查了一些文档，加上一点自己的理解总结如下（如果有些什么错误请GGJJ们帮我指出来）。

1、  commit时产生的scn

我们都知道为了减少IO Oracle在commit 时发生的是LGWR将log buffer写到redo log file，而不是DBWn写，也就是说LGWR也会同步的讲每一笔提交的交易SCN写入redo log file，因此这个SCN也就是系统内最新的一个SCN
在恢复数据库是如果数据库处在不一致的状态将用它把数据恢复到一个一致状态

select dbms_flashback.get_system_change_number from dual;

2、System checkpoint SCN

当checkpoint时发生CKPT和DBWn写并同时记录下此时SCN，此刻redo log file中的SCN和System checkpoint SCN应该是一致的

这个SCN应该是写在control file中

select checkpoint_change# from v$database;

3、Datafile checkpoint SCN

肯定要问为什么为什么checkpoint 时会产生两个SCN吧
原因很简单当你把一个tbs設為read-only时，他的SCN会冻结停止，此时DATAFILE CHECKPOINT SCN是不会再递增改变的， 但是整体的SYSTEM CHECKPOINT SCN卻仍然会不断递增前进。这个SCN也应该是存在control file中

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

4、Stop SCN
Stop SCN 可以理解为一个状态值，其实当数据库关闭的时候也会发生checkpoint的，这就好理解了，当数据库正常关闭时会将checkpoint之后的SCN值，但当数据库非正常关闭时，他将不能得到值，且当数据库启动后会将Stop SCN值设为NULL。
他也是存在control file中，因此可见control file中在恢复中的重要性

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

5、Start SCN
也称为datafile header  SCN，可以想象datafile header  SCN是数据文件的实际值，而Datafile checkpoint SCN是数据文件的正常值，如果datafile header  SCN不等于Datafile checkpoint SCN则说明数据库需要恢复

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

 

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

转载于:http://blog.itpub.net/9421572/viewspace-206114/