我们都知道oracle的备份有几钟方式，冷备，热备，rman，imp等，我们注意到当我们采取热备的时候，需要对每个要备
份的表空间置为backup模式。通常的热备脚本都是这样的
alter tablespace XXX begin backup;
cp XXX ....
alter tablespace XXX end backup;
（这里需要注意一点，oracle的最小存储单位是一个数据块，一个块的大小通常设置为8k，而操作系统的块通常是512bytes，这样的话一个oracle的数据由很多个操作系统的块组成。而且对于一个数据文件来说，它的所有块对应的操作系统的块并不是按顺序存储的，当运行cp等操作系统命令时并不能指定从那个oracle数据块开始拷贝。）
当open数据库的时候，oracle会去比较控制文件中数据文件记录和数据文件头的checkpoint cnt，如果两者相同，则判断不需要介质恢复，如果不同，这时候oracle就会报某某文件需要介质恢复。然后拷贝回数据文件备份我们开始
recover，这时候就从上次做备份时的scn开始恢复，运用日志，直到恢复结束。当cp数据文件时，比如说我们拷贝的第一个块可能是scn为100的数据块，当我们完成这个块的拷贝后，这个块有可能被别的进程多次修改，scn变为900。我们知道当数据库发生检查点时会去更新数据文件头和控制文件中的checkpoint scn，如果当我们在cp数据文件的同时发生了n次checkpoint，这时候数据文件头的scn可能被更新了很多次。这时候cp的进程去拷贝数据文件头所在的操作系统块，可能这个数据文件头的块因为被checkpoint了很多次导致它的scn为1000，这时候整个数据文件会出现不一致，当用这个备份文件去恢复时，恢复进程会从scn＝1000开始恢复，这样的话开始那个scn=100的块将丢失从scn100-scn1000的数据，因为数据块并不应用scn在1000以前的日志,而且这样做的话可能出现一些数据块的corruption，所以不置成backup模式备份的话并不可取。当然，如果你能确保当cp的时候不发生checkpoint，或者你的操作系统块的大小不小于oracle的数据块大小，这些情况下不置backup mode拷贝出来的文件也是有效的。
现在我们知道了为什么不能不设置backup模式，下面来讲讲alter tablespace XXX begin backup做了什么？
当数据文件置于backup模式时，oracle会去锁定数据文件头，这时候数据库发生检查点的话将不会修改文件头的
checkpoint scn，而只是增加checkpoint cnt，所以不管执行cp的时候操作系统块的拷贝顺序是如何，oracle总会从文件
头的scn开始恢复，这样的话也就避免了数据丢失和数据块corruption.如果大家用的是rman来备份，那么就不会有这个问
题，因为rman备份的时候rman会去对比数据块的头尾标志，如果发现不一致，那么它将会再去读这个块，直到读到一致的
块才往备份集里写。
但是alter tablespace XXX begin backup带来的另一个问题是会导致产生多余的日志，通过一个小小的试验就可以
证明这一点。
SQL> select name,value from v$sysstat where name='redo size';
NAME VALUE
---------------------------------------------------------------- ----------
redo size 43408
SQL> update test set a=a;
1 row updated.
SQL> commit;
Commit complete.
SQL> select name,value from v$sysstat where name='redo size';
NAME VALUE
---------------------------------------------------------------- ----------
redo size 44060
SQL> ALTER SYSTEM DUMP LOGFILE '/netappredo/redo05.log';
System altered.
一个update的动作产生44060－43408＝652bytes的redo
把表空间置为backup mode
SQL> alter tablespace test begin backup;
Tablespace altered.
SQL> select name,value from v$sysstat where name='redo size';
NAME VALUE
---------------------------------------------------------------- ----------
redo size 44732
SQL> update test set a=a;
1 row updated.
SQL> commit;
Commit complete.
SQL> select name,value from v$sysstat where name='redo size';
NAME VALUE
---------------------------------------------------------------- ----------
redo size 53560
SQL> alter tablespace test end backup;
Tablespace altered.
一个update的动作产生53560－44732＝8828bytes的redo
看看到底是记了些什么？
SQL> ALTER SYSTEM DUMP LOGFILE '/netappredo/redo05.log';
System altered.
REDO RECORD - Thread:2 RBA: 0x00004e.000000b0.0128 LEN: 0x01b0 VLD: 0x01
SCN: 0x0000.19ed24f7 SUBSCN: 1 06/29/2004 15:05:32
CHANGE #1 TYP:0 CLS:29 AFN:33 DBA:0x08400029 SCN:0x0000.19ed24f2 SEQ: 1 OP:5.2
...... (改动向量1，记载对undo header事务表的修改)
CHANGE #2 TYP:0 CLS:30 AFN:33 DBA:0x0840002e SCN:0x0000.19ed24f0 SEQ: 1 OP:5.1
...... (改动向量2，记载对undo block的修改)
CHANGE #3 TYP:2 CLS: 1 AFN:51 DBA:0x0cc0000f SCN:0x0000.19ed24e8 SEQ: 1 OP:11.5
KTB Redo (改动向量3，记载对数据块的修改，也就是在数据块上执行update test set a=a）
op: 0x11 ver: 0x01
op: F xid: 0x0007.001.00014ece uba: 0x0840002e.0859.38
Block cleanout record, scn: 0x0000.19ed24f7 ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.19ed24e8
KDO Op code: URP row dependencies Disabled
xtype: XA bdba: 0x0cc0000f hdba: 0x0cc0000b
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 2 ckix: 0
ncol: 1 nnew: 1 size: 0
col 0: [ 2] c1 02
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
......(改动向量4，一些标记）
我们看到了正常的日志记录，此外还有些block cleanout及回滚段改变的日志记录，但是相比较不是backup模式的日
志来说多了这一部分。
Log block image redo entry
Dump of memory from 0x0AE48820 to 0x0AE4A808
AE48820 00280001 00002C32 19ED24E6 1FE80000 [..(.2,...$......]
AE48830 00321F02 0CC00009 00210005 000307F1 [..2.......!.....]
AE48840 0840000E 0021100C 00002001 19ED24E8 [..@...!.. ...$..]
AE48850 001F0016 0001A94C 0840007C 000D0C08 [....L...|.@.....]
AE48860 00008000 19ED2468 00000000 00000000 [....h$..........]
AE48870 00020100 00160001 1F791F8C 00001F79 [..........y.y...]
AE48880 1F920002 0F88FFFF 0ED00F2C 0E180E74 [........,...t...]
AE48890 0D600DBC 0CA80D04 0BF00C4C 0B380B94 [..`.....L.....8.]
AE488A0 0A800ADC 09C80A24 0910096C 085808B4 [....$...l.....X.]
AE488B0 07A007FC 06E40744 06240684 056405C4 [....D.....$...d.]
......
这一部分是对更改的数据块做的一个镜像，把这个块完全记录到redo里面去了，但是为什么要这么做呢。
这就又牵扯到一个概念，'block split'，当数据文件在备份cp时，因为oracle数据块和操作系统块的差异，一个数
据块可能由16个操作系统块组成（8k 数据块,512bytes 系统块），这样的话可能出现一个数据块包含了几个不同版本的
操作系统块，会导致数据块的不一致，所以在备份模式下如果有语句对备份块产生更新，那么oracle会先把当前块复制一
份到redo，当恢复的时候如果碰到数据块不一致就从redo把这个镜像拷贝回去，然后在这个一致性的镜像开始恢复。 如
果使用rman来备份可以避免产生过多的块，就像上面所说的，rman会去建议块的一致性，所以不用复制镜像块到日志。
=========================================
当日志切换或发生checkpoint（上述第五个步骤）时，从Low SCN到Next SCN之间的所有redo记录的数据就被DBWn进程写
入数据文件中，而CKPT进程则将所有数据文件（无论redo log中的数据是否影响到该数据文件）的文件头上记录的Start
SCN(通过视图v$datafile_header的字段checkpoint_change#可以查询)更新为Next SCN，同时将控制文件中的System
Checkpoint SCN（通过视图v$database的字段checkpoint_change#可以查询）、每个数据文件对应的Datafile
Checkpoint（通过视图v$datafile的字段checkpoint_change#可以查询）也更新为Next SCN。
=========================================
关于checkpoint cnt和checkpoint scn
通过试验说明checkpoint cnt 和checkpoint scn的关系
1.在不同条件下转储控制文件
SQL> alter session set events 'immediate trace name CONTROLF level 10';
Session altered.
SQL> alter tablespace system begin backup;
Tablespace altered.
SQL> alter session set events 'immediate trace name CONTROLF level 10';
Session altered.
SQL> alter system checkpoint;
System altered.
SQL> alter session set events 'immediate trace name CONTROLF level 10'
2 /
Session altered.
SQL> alter tablespace system end backup;
Tablespace altered.
SQL> alter session set events 'immediate trace name CONTROLF level 10';
Session altered.
notes:
alter session set events 'immediate trace name CONTROLF level 10';
用于转储控制文件.
?
2.获得以下跟踪文件信息(仅研究system表空间记录,请注意红色部分):
a.正常情况下转储控制文件
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1567 scn: 0x0000.0148181c 06/22/2004 18:58:46
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
b.执行Begin backup以后的
我们注意到Checkpoint cnt增加了1，此处触发了一次表空间检查点.
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1568 scn: 0x0000.01481939 06/22/2004 19:02:22
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
c.执行手工检查点
我们注意到,此时Checkpoint cnt增加，但是scn不再改变
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1569 scn: 0x0000.01481939 06/22/2004 19:02:22
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
?
d.End backup后的情况
此时数据文件头的冻结被取消,scn开始变化
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(blkno = 0x6, size = 180, max = 100, in-use = 24, last-recid= 574)
DATA FILE #1:
(name #4) /opt/oracle/oradata/hsjf/system01.dbf
creation size=32000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 04/23/2004 01:20:52
Checkpoint cnt:1570 scn: 0x0000.01481941 06/22/2004 19:02:39
Stop scn: 0xffff.ffffffff 06/22/2004 18:58:05
Creation Checkpointed at scn: 0x0000.000000ae 07/16/2003 03:40:10
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Offline scn: 0x0000.013b46fd prev_range: 0
Online Checkpointed at scn: 0x0000.013b46fe 05/28/2004 23:37:17
thread:1 rba:(0x1.2.0)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Checkpoint cnt用于保证在正常操作中使用的数据文件是当前版本
在恢复时防止恢复数据文件的错误版本.Checkpoint cnt是一直递增的,即使表空间处于热备份模式.
由于表空间的创建时间不尽相同,所以不同表空间/数据文件的Checkpoint cnt通常是不同的.
我们知道:
在数据库open的过程中,Oracle要进行两次检查.
第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.
如果相等,进行第二次检查.
第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致
如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.
对每个数据文件都完成检查后,打开数据库.同时将每个数据文件的结束SCN设置为无穷大.
=========================================
关于SCN的理解，未完成
dml一发生即使没有提交也会增加scn, job进程一样产生scn,只要对数据库中文件发生任何的改变都有可能产生scn,SCN:
system change number, not system commit number .也就是 系统发生变化 所产生的一个时间点标志。不是提交的标志，只是因为提交也是系统的变化之一而已
一般DBWn修改的是数据块但不是数据文件头，只有检查点发生的时候才更新数据文件头，也就是说只有 ckpt 进程更新数据文件头（oracle8以前如果没有ckpt进程就是lgwr更新），dbwr只写数据块
检查点的发生，跟写日志文件是没有必然联系的检查点通知 DBWR 写数据文件，写完后ckpt更新控制文件 和数据文件头
当DBWR 写 数据块的时候若发现 数据块的 相关 RDBA (位于日志文件的位置) 的 log block 还没有被写入日志文件，则在dbwr写块之前必须通知llgwr把log buffer 中日志写入日志文件(即还没有commit)
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-615585/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/35489/viewspace-615585/
1583
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
