ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 热备份(hot backup)期间做了什么?

热备份(hot backup)期间做了什么?

原创 Linux操作系统 作者:tolywang 时间:2007-07-05 00:00:00 0 删除 编辑

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

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



我们都知道,oracle block 是由多个OS blocks组成。比如,某个Unix 文件系统使用 512bytesblocksize,而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:

代码:


'--- 正常运行产生的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
大家有什么意见?

biti_rainy:

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

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

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

http://grassbell.itpub.net/post/26/942

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/35489/viewspace-84736/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle , MySQL, SAP IQ, SAP HANA, PostgreSQL, Tableau 技术讨论,希望在这里一起分享知识,讨论技术,畅谈人生 。

注册时间:2007-12-10

  • 博文量
    5595
  • 访问量
    13378484