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

热备期间日志文件记录的是修改的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 覆盖掉得以解决。以保证将来恢复的成功。


SPLIT BLOCK 的概念可以参考：http://tahiti.oracle.com/  中查找 fractured block

证实热备过程产生了更多的redo:

PHP code:



'--- 正常运行产生的redo---'





SQL> select value from v$sysstat where name='redo size';





     VALUE


----------


   2989820





SQL> insert into t select * from dba_objects;





24652 rows created.





SQL> commit;





Commit complete.





SQL> select value from v$sysstat where name='redo size';





     VALUE


----------


   5774388





SQL> select 5774388-2989820 from dual;





5774388-2989820


---------------


        2784568








'--- hot backup 期间产生的redo---'


SQL> truncate table t;





Table truncated.





SQL> show user;


USER is "SYS"


SQL> 


SQL> alter tablespace system begin backup;





Tablespace altered.





SQL> select value from v$sysstat where name='redo size';





     VALUE


----------


   5782896





SQL> insert into t select * from dba_objects;





24652 rows created.





SQL> commit;





Commit complete.





SQL> select value from v$sysstat where name='redo size';





     VALUE


----------


   8608520





SQL> select 8608520-5782896 from dual;





8608520-5782896


---------------


        2825624





SQL> alter tablespace system end backup;





Tablespace altered.








'--- 两者比较---'


SQL> select 2825624-2784568 from dual;





2825624-2784568


---------------


          41056





SQL>

我的问题：

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

我的理解和猜测：

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

大家有什么意见？

create or replace procedure print_redo( v_sql varchar2, v_commit boolean default true)
as
        v_redo1 number(17,2);
        v_redo2 number(17,2);
        v_redos number(17,2);
        v_redok number(17,2);
begin
  /*初始*/
        select m.value into v_redo1
   from v$mystat m,v$statname s
  where m.statistic#=s.statistic# and s.name like '%redo size%';
        /*exec sql*/
  execute immediate v_sql;
        /*结束*/
        select m.value into v_redo2
   from v$mystat m,v$statname s
  where m.statistic#=s.statistic# and s.name like '%redo size%';
        /*计算*/
        v_redos := v_redo2 - v_redo1;
        v_redok := v_redos/1024;
        dbms_output.put_line('            trans redo calc                ');
        dbms_output.put_line('-------------------------------------------');
        dbms_output.put_line('my redo size:  '||to_char(v_redos)||'  (Bytes)');
  dbms_output.put_line('my redo size:  '||to_char(v_redok)||'  (Kbytes)');
  dbms_output.put_line('-------------------------------------------');
        /*提交否*/
        if v_commit = true then
                commit;
        else
          rollback;
        end if;
end;

/*demo*/
exec print_redo('delete from a_test',false);

QUOTE:

---

最初由 grassbell 发布
我的问题：

我一直对为什么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中一个标志位所控制的。

QUOTE:

---

最初由 biti_rainy 发布

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

---

biti_rainy, 这句话我理解起来有困难

能否通俗一点，再来一便，多谢

QUOTE:

---

最初由 grassbell 发布


biti_rainy, 这句话我理解起来有困难

能否通俗一点，再来一便，多谢

---

对于同一个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 的情况。

The file's block was still being modified by Oracle.