都能得到完好的恢复（当然包括split block）。另：文件被拷贝的时候，并不能确保文件头是最先被完整地拷贝成功的。
BTW: 文件置于热备份状态之后，当buffer第一次被修改的时候产生整个块的before image。注意是buffer而不是block。 也就是说，当buffer被写入文件再读进来，再发生变化的时候将重新产生 block 的 before image。 这是由block中一个标志位所控制的。IXDBA.NET技术社区
grassbell:
RMAN的热备就取消了 alter tablespace... begin backup; 命令，不必锁定数据文件；而且不会产生多余的日志文件。
这是因为：
RMAN采取了类似于 sql 查询时的一致性读的原理进行热备的，所以不必要在日志中产生整个快的image；并且将开始热备时的scn 记录在rman 目录或者控制文件中，不必要冻结数据文件头。
我的问题：
RMAN采取的一致性读是什么范围的？
整个数据文件？不应该，这样跨越的范围太大，对回滚段的要求太高；
还有，既然RMAN采取 oracle server process 读取数据块，我觉得本身就不会产生split block 的情况。
biti_rainy:
rman 使用了 large_pool_size 进行缓冲，写出之前要再检查 block 的一致性，如果是split block 则重新读取该块，直到一致为止
实际上一致指的是block
grassbell:
rman 读的时候不是读整个块吗？ 如果是使用的 server process 读的话，应该是读整个block呀，为什么还有split block的情况？
biti_rainy:
rman 读的时候依然可能这个块在发生变化，server process 读难道就能避免吗？ 如果正常情况的查询，dbwr 在写入文件的时刻，server process 在 data buffer 中就可以得到自然不会去文件中读了 。而只要去文件中读，都可能出现不一致的情况，文件有人在读有人在修改都可能这样的，因为读写并不阻塞，更没有锁定 oracle 的 block
热备期间最大的特点就是产生了比平常更多的日志文件，为什么会这样？在恢复的时候有什么用呢？
热备期间日志文件记录的是修改的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 覆盖掉得以解决。以保证将来恢复的成功。
记得如果使用RMAN就没有这个弊端
SPLIT BLOCK 的概念可以参考：http://tahiti.oracle.com/ 中查找 fractured block
http://www.itpub.net/252974,4.html
