hot backup 中alter tablespace XXXX begin backup做了什么?

 大家在做hotbackup的时候, 一般是
alter tablespace XXXX begin backup;
!cp ....
alter tablespace XXXX end backup;
我们都知道在hotbackup 的同时是允许对正在备份的文件写入的, 那么随着cp的进行, 复制下来的文件从时间的角度看是在不同的时间段有cp 读出来的, 里面的数据一定是不一致的. 那么hot backup如何保证恢复时的一致性呢? 这要从begin backup说起. 
begin backup 做了什么呢? 基本上, 当我们begin backup时, oracle 会把这个ts中的所有数据文件都标记为hot-backup-in-progress, 同时这个命令会checkpoint这个ts的所有文件. 也就是说, 所有的dirty block 都会被写回到所属的数据文件. 这时候, 文件头中的checkpoint scn 记录这时的scn. 尽管在整个backup 过程中, oracle 可能会发生多次checkpoint, begin backup 的数据文件的checkpoint scn不会随之改变, 而其它文件的scn会被更新, 也就是说, begin backup的文件的scn被锁定于开始备份的scn.　虽然checkpoint 不会改变备份文件的头, checkpoint还是会把数据写入到这些文件中去, 也就是说, cp复制的文件无论如何都是不一致的. 那么怎样保证我们恢复的时候, 能够恢复到开始备份时的scn呢? 原来当备份中的文件中的某个块发生第一次修改的时候, oracle会把这个块(与开始备份时的数据一致)复制到redo log中. 当我们在恢复的时候, oracle 会把redolog 应用到这些数据文件, 相当于把这些修改过的块的数据再复制会数据文件. 从而, 把文件恢复到开始备份是的一致状态. 有个内部init parameter _LOG_BLOCKS_DURING_BACKUP控制是否将block写到redo log.这个参数默认是true.
相关的几个视图
v$backup
v$datafile_header
v$log