热备期间最大的特点就是产生了比平常更多的日志文件，为什么会这样？在恢复的时候有什么用呢？

热备期间日志文件记录的是修改的row所在的整个block的image，而不仅仅是修改的row的信息。
这样做的目的是为了尽量避免热备份的数据文件中因为包含SPLIT BLOCK ，而不能用于恢复的可能性。
为了理解这段话，还要提一下SPLIT BLOCK的概念.

我们都知道，oracle 的block 是由多个OS blocks组成。比如，某个Unix 文件系统使用 512bytes
的blocksize，而oracle 使用8k 的db_block_size. 当热备份数据文件的时候，我们使用文件
系统的命令工具copy 拷贝文件，并且使用文件系统的blocksize 读取数据文件。

假设这种情况：当我们拷贝数据文件的同时，数据库正好向数据文件写数据。这就使得拷贝的文件中
包含这样的database block，它的一部分OS block 来自于数据库向数据文件(这个db block)写操作之前，
另一部分来自于写操作之后。这个database block就是一个SPLIT BLOCK.

所以，通过在日志中记录整个变化的db block 的image，可以保证在恢复的过程中，任何在热备的数据文件中出现的
SPLIT BLOCK可以通过日志文件中的full image of the block 覆盖掉得以解决。以保证将来恢复的成功。

我的问题：

我一直对为什么begin backup后要锁定这个数据文件的checkpoint scn 不太明确？

我的理解和猜测：

热备过程中使用统一的checkpoint scn ，可以在日至文件中很方便的找到哪些日志是hot backup时产生的日志，这个过程中的有可能产生SPLIT BLOCK ，需要在恢复时特别注意。而不需要影响到其他的block。

大家有什么意见？

冻结的checkpoint  scn , 使得备份出来的文件可以从该scn（实际上对应了日志文件的RBA）开始恢复，这样保证所有的block都能得到完好的恢复（当然包括split  block）。另：文件被拷贝的时候，并不能确保文件头是最先被完整地拷贝成功的。


BTW: 文件置于热备份状态之后，当buffer第一次被修改的时候产生整个块的before image。注意是buffer而不是block。 也就是说，当buffer被写入文件再读进来，再发生变化的时候将重新产生 block 的 before image。 这是由block中一个标志位所控制的。

对于同一个block依次发生如下情景

file  block  ---server  process  read  from  file--- into  sga  buffer
buffer  ----  server  process modify  the buffer  --- generate  redo  (whole   block   before  image)
buffer  ---- server  process modify  the  buffer  agin  --- no  redo   for  block  before  image
sga buffer  --- dbwr write the  buffer  to  file  ----  file

file  block  ---server  process  read  from  file--- into  sga  buffer
buffer  ----  server  process modify  the buffer  --- genarate  redo  (whole   block   before  image)
……
……

在热备过程中虽然数据文件文件头中checkpoint scn更新被冻结,但数据文件块还是会被更新,导致在使用OS命令备份数据文件时,备份的数据文件会产生split现象,即在拷贝某个数据块的过程中数据块被更新,因此oracle就必须将数据块的past image写入日志文件中以用于重建SPLIT的数据块.从而导致了日志文件的增大.past image的写入受init.ora参数log_blocks_during_backup控制,缺省值是true,表示须写入日志文件

RMAN的热备就取消了 alter tablespace... begin backup; 命令，不必锁定数据文件；而且不会产生多余的日志文件。

这是因为：
RMAN采取了类似于 sql 查询时的一致性读的原理进行热备的，所以不必要在日志中产生整个快的image；并且将开始热备时的scn 记录在rman 目录或者控制文件中，不必要冻结数据文件头。

我的问题：
RMAN采取的一致性读是什么范围的？
整个数据文件？不应该，这样跨越的范围太大，对回滚段的要求太高；
还有，既然RMAN采取 oracle server process 读取数据块，我觉得本身就不会产生split block 的情况。

rman 使用了 large_pool_size 进行缓冲，写出之前要再检查 block 的一致性，如果是split  block 则重新读取该块，直到一致为止
实际上一致指的是block

rman 读的时候不是读整个块吗？ 如果是使用的 server process 读的话，应该是读整个block呀，为什么还有split block的情况？

rman 读的时候依然可能这个块在发生变化，server  process 读难道就能避免吗？  如果正常情况的查询，dbwr 在写入文件的时刻，server  process 在 data  buffer 中就可以得到自然不会去文件中读了 。而只要去文件中读，都可能出现不一致的情况，文件有人在读有人在修改都可能这样的，因为读写并不阻塞，更没有锁定  oracle 的 block

rman 在把数据块写出去之前，会校验块的

如果是普通用户的查询，多个进程对于同一个块的访问，在8i中是串行的，在9i 中也只有 READ & READ 才可以，READ&write 也是串行的。  所以  server  process 读数据的时候肯定不会有 正在发生变化的块

其实也就是无所谓校验split block了？
因为当RMAN在写出一个block的时候，这个block一定是一致的
那么是不是可以这样认为，RMAN和老方式热备区别只是在于，前者是oracle用后台process在写出数据文件，而后者是操作系统的命令在copy数据文件。
因为RMAN是oracle在帮你作copy block，所以无需记录整个block image