- 论坛徽章:
- 0
|
1、scn是系统发生变化所产生的一个时间点标志，其值不断增加的原因有：事务的结束、开始、aq/job、同一block上在一个事务中连续发生255个dml后、某些内部操作（ex:buffer块的清除）
实验发现：db只要运行着，我多次select dbms_flashback.get_system_change_number，所得scn值都会一次比一次大，所以具体是什么原因导致scn不断递增，还很难理解？
Scn有checkpoint scns(end of checkpoint)
Commit scns(end of transaction)
Snapshot scns(begging of the query)
System scn
etc……
以保证statement level read consistency
Multiversioning
Transaction rollback
Instance recovery etc etc
所以检查点scn只是当我们发生检查点的时候scn所具有的值，在概念上scn和checkpoint是完全不同的两样东西
另：block scn在块头和块尾都有，若不一致，意味数据块损坏（所以热备时要alter tablespace …… begin backup以避免），如何查看块头和块尾的block scn？
2、检查点是同步内存中修改的脏数据块到数据文件的一个事件并更新控制文件、数据文件，与事务提交无关，有两个作用：建立数据一致性，fast instance recovery（因为检查点时不但会写脏块，还会在控制文件中记录迄今为止写入的进度，所以在instance reovery时不需重做日志中早于该进度的部分，缩短恢复时间）
checkpoint cnt（检查点记数器）区Checkpoint scn，cnt用于保证在正常操作中使用的数据文件是当前版本，在恢复时防止恢复数据文件的错误版本，其值一直递增，即使表空间处于热备（即alter tablespace …… begin backup只会冻结scn直至end backup）,由于表空间建立的时间不同，所以不同数据文件、表空间的cnt是不同的（ex实验新建一表空间后，dump控制文件发现新文件的cnt才3，而老文件们cnt都已经38，这个时候新文件scn大于老文件们，但各老文件们的scn都相等，再重启数据库，dump控制文件发现cnt对于新、老文件还是各增各的，但scn却已统一成一个相同的值了。疑惑：“在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值……”等等所云启动scn是指dump file_hdrs文件里的哪一行？启动scn的值自己又是谁赋给的？该值能等于Select dbms_flashback所查询到值吗？猜想dbms_flashback反映的是不是某个最新被改数据块的状态scn？）这便是数据库启动时所做一致性检查工作的第一步，如果各数据文件头部cnt不等于控制文件中记录的相应文件的cnt，那么要进行介质恢复（“例如冷备替换数据文件、数据文件offline了又online”？），否则做第二步，各数据文件头部scn是否等于控制文件中记录的相应文件的结束scn，若不相等便会要求线程恢复（并行服务器时）/崩溃恢复（单实例时）（当db down、shutdown abort时，便会出现这种scn不一致的情况）。
只有检查点发生时才更新（由 lgwr执行，8i无ckpt用lgwr）数据文件头的scn，代表着当恢复的时候从这个scn点开始在log file中寻找相映记录做恢复（“在定位到底使用哪个日志文件的时候，其实并不是用数据文件中的 low scn 去框，在日志文件的low scn and next scn 之间就利用该日志文件。而是在数据文件头中有 RBA 的记录，RBA 包含了日志序号、block number 、slot number 。 这样可以直接定位到日志文件（归档日志文件）和具体的位置。”Dump到的数据文件头里的哪些行是指代日志序号、block number、slot number的呀？）直到redo log的末尾（末尾指什么，有待学习？）
看别人说：日志切换（不论满后自己切还是手动切）后，一个组不是current态，但可能还是active，说明lgwr未把所有修改都写入redo log files（是这样吗？这时如果断电，那岂不是要丢数据？），而手工强制checkpoint（完全）（增量方式不行，什么概念？下一步深入学习）后，该组变为inactive。
检查点还有什么局部、全局、文件检查点之分，完全、增量检查点之分等等 |
|
免费注册
发表于 2005-12-28 17:58
