oracle中的SCN

显示全部楼层 · 2005-10-30 17:05:33

看了一个下午，总算有点收获，跟大家分享，见笑
1．
系统SCN号
查询系统SCN号的方法：
select dbms_flashback.get_system_change_number from dual
commit后系统SCN号会增长，但是即使没有commit操作，因为有许多后台进程在运行，所以系统SCN号也会增长。
2．
检查点SCN
有4种检查点SCN，其中除了文件头中的启动SCN外，其他三种保存在控制文件中。可以通过：alter system set events ‘immediate trace name controlf level 10’导出控制文件到udump目录的跟踪文件，来查看控制文件的内容。
1)
系统检查点SCN(区别于上面的系统SCN，chekpoint发出后这些SCN号才受影响，如发出：alter system checkpoint),当一个检查点动作完成后，Oracle就把系统检查点的SCN存储到控制文件中，查询方法：
Select checkpoint_change# from v$database
2)
数据文件检查点SCN
当一个检查点动作完成后，Oracle就把每个数据文件的SCN号单独存放在控制文件中，查询方法：
Select checkpoint_change# from v$datafile
3)
文件头中的启动SCN
Oracle把这个检查点的SCN号存储在每一个数据文件的文件头中。主要用于数据库实例启动时，检查是否需要执行数据库恢复。查询方法：
Select name,chekpoint_change# from v$datafile_header
4)
终止SCN
每个数据文件的SCN号都存储在控制文件中，查询方法：
Select name,last_change# from v$datafile
在正常的数据库操作过程中，所有处于联机读写模式下的数据文件的终止SCN都为NULL。
3．
几个检查点SCN号的关系
1)
几个检查点SCN都相同：在数据库打开并运行之后，控制文件中的系统检查点SCN、控制文件中的数据文件检查点SCN及每个数据文件头中的启动SCN都是相同的，控制文件中的每个数据文件的终止SCN都是NULL。
2)
数据库正常关闭时，系统会执行一个检查点动作，这时所有数据文件的终止SCN号会设置为数据文件头的那个启动SCN。数据库重新启动时，Oracle将数据文件头中的启动SCN与数据文件检查点SCN比较，如果这两个值匹配，Oracle接下来再比较数据文件头中的SCN和控制文件中数据文件的终止SCN，如果这个值也匹配，就意味着所有数据块已经提交，因此数据库不需要进行恢复，此时数据库直接打开。当所有的数据文件都打开之后，终止SCN再次被设置为NULL，表示数据文件已经打开并能够正常使用了。
3)
数据库非正常关闭(或称为实例崩溃)时，终止SCN不会被设置，依然为NULL，这可以通过把数据库启动至mount状态查询出来。这样Oracle通过这个信息就可以知道实例上次运行时崩溃了，检查点没有执行。这样重新启动时，Oracle会执行实例恢复工作，即先执行前滚、回滚操作，再把数据库打开。
4)
数据文件检查点SCN及系统检查点SCN比文件头启动SCN大：这时的情况是：系统发生介质故障，数据文件被以前的备份代替，控制文件中的数据文件检查点SCN肯定比文件头中的启动SCN要大，这样Oracle就知道要对这个文件进行介质恢复。这时要通过下面语句恢复数据库：
recover database ……
5)
系统检查点SCN比数据文件SCN及文件头启动SCN大：
有些表空间是只读的，这时控制文件中的系统检查点SCN号会不断增长，而数据文件SCN号和文件头中的启动SCN号会停止更新(直到表空间又设置为可读写)，显然这时系统检查点SCN号会大于数据文件SCN和文件头启动SCN。
6)
系统检查点SCN及数据文件SCN比文件头启动SCN小：
在数据库恢复时，控制文件可能不是最新的，即把一个较早的控制文件还原为当前的控制文件，然后再执行恢复操作，这时控制文件中的系统检查点SCN和数据文件SCN可能比文件头的启动SCN小。这时恢复数据库要用下面命令：
recover database using Backup Controlfile或其他的恢复语句。
SCN还有很多内容这里没清楚，比如数据块中的SCN和这几种SCN是什么关系，烦请高手补充完整。[/COLOR]

千问 · 2005-10-30 17:05:33

上面帖子太乱，给一个word文档

千问 · 2005-10-30 17:05:33

[QUOTE]
数据库非正常关闭(或称为实例崩溃)时，终止SCN不会被设置，依然为NULL
/QUOTE]
这句好像应该是：数据库非正常关闭(或称为实例崩溃)时，控制文件中的终止SCN依然是无穷大吧。
数据块中的SCN号应该是在查询时使用的。
比如在一个查询开始时，当前的系统SCN是100，那么在查找数据块的过程中，有其他dml更新了属于该查询范围的数据块，于是当查询进行到该已经变化了的数据块时，发现该数据块的SCN已经大于100了，于是oracle会去rollback segment中去找更新之前的数据。

千问 · 2005-10-30 17:05:33

最初由 hanson 发布
[B][QUOTE]
数据库非正常关闭(或称为实例崩溃)时，终止SCN不会被设置，依然为NULL
/QUOTE]
这句好像应该是：数据库非正常关闭(或称为实例崩溃)时，控制文件中的终止SCN依然是无穷大吧。
[/B]
应该是NULL，可以把数据库启动到mount状态，去查询，
last_change#为空。

千问 · 2005-10-30 17:05:33

哪位斑竹大侠，解释一下数据块中的SCN是怎么回事

千问 · 2005-10-30 17:05:33

支持爱钻研的人

千问 · 2005-10-30 17:05:33

最初由 lawzjf 发布
[B]
应该是NULL，可以把数据库启动到mount状态，去查询，
last_change#为空。 [/B]
但是如果從dump出來的控制文件中看的話,確實是無窮大的值!

千问 · 2005-10-30 17:05:33

最初由 akenjiang 发布
[B]
但是如果從dump出來的控制文件中看的話,確實是無窮大的值! [/B]
控制文件中的导出结果是stop scn: 0xffff.ffffffff
但是查询时却是空，这是怎么回事？？
另外数据块的SCN怎么没人说说。

千问 · 2005-10-30 17:05:33

ding

千问 · 2005-10-30 17:05:33

其实这玩意呢……千头万绪比较多
关于所有的问题，都零散地存在于以前的讨论中
就是不知道你需要知道什么
既然你想到了这个层次，如果面对你给我块白板，30分钟就能让你所有的全弄明白
但是要这么用文字表述……太麻烦了
关于 block 上的 SCN ,请先了解ITL / consistent reads /blockclean out/transaction tables 几个部分的相关内容