ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle联机热备原理及rman增量备份原理

oracle联机热备原理及rman增量备份原理

原创 Linux操作系统 作者:波罗2009 时间:2011-03-25 19:57:39 0 删除 编辑

要求归档模式

SQL>; archive log list

Database log mode              

Archive Mode Automatic archival             

Enabled Archive destination            

USE_DB_RECOVERY_FILE_DEST Oldest online log sequence     14 

Next log sequence to archive   16 Current log sequence           16

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

       先看用户管理的热备份

看看下面这个关键的操作,将备份的内容置于backup模式,用户管理的联机热备份必需的操作,不然copy备份的数据文件不能用来恢复,即使用某些时恢复了也会丢数据

    SQL>; alter tablespace users begin backup

Tablespace altered. 

SQL>; list 1  

select d.file_name filenamed.tablespace_name ts_nameb.status 2  

from dba_data_files dv$backup b 3* 

where d.file_id=b.file# 

SQL>; 

/ FILENAME                   TS_NAME    STATUS

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

/u02/oradata/sales/system01.dbf    SYSTEM     NOT ACTIVE 

/u02/oradata/sales/undotbs01.dbf    UNDOTBS1   NOT ACTIVE 

/u02/oradata/sales/sysaux01.dbf     SYSAUX     NOT ACTIVE 

/u02/oradata/sales/users01.dbf       

USERS      ACTIVE /u02/oradata/sales/example01.dbf    

EXAMPLE    NOT ACTIVE /u02/oradata/sales/perfstat.dbf        

PERFSTAT   NOT ACTIVE

 

       USERS表空间现在处于backup模式,究竟这时候怎么了?

       在我们alter tablespace users begin backup 的时候是锁定了users表空间对应的数据文件头的change scn.首先考虑一下数据库怎么用日志文件做恢复:查找不一致的数据文件(根据文件头中旧的scn

       如果锁定了文件头,这个文件头中的scn就不会改变(当然了数据块还是会变化的,还可以做读写)。 然后就会应用这个scn到现在的日志。

       那我锁定了scn,不管你后边怎么修改,总之做恢复的时候是应用锁定的时候的scn一直到现在的日志(完全恢复的话)

 

       举个例子:ab两个数据文件,把a置于备份模式,b正常这时候两个change scn都是100,然后开始备份这期间有数据库的修改,备份完成的时候,Scn变成了200.但是由于a的备份模式,所以a的文件头中记录的scn还是100b200.某个时间,假设scn 500这时候a丢失copya的备份,然后recover,完全恢复的话数据库就应用100—500这段的日志,自然也就不会丢失数据了。

       因为不管在我copy备份的过程中你做什么操作,总之都在锁定的时change scn之后,所以应用的日志就不会有遗漏了。

       这时候应该能理解为什么要数据库处于archived模式了

 

看看数据文件头的change scn 

SQL>select NAMETABLESPACE_NAMESTATUSCHECKPOINT_CHANGE# 

from v$datafile_header

NAME               TABLESPACE STATUS       CHECKPOINT_CHANGE#

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

/u02/oradata/sales/system01.dbf  SYSTEM     ONLINE                     545926 /u02/oradata/sales/undotbs01.dbf UNDOTBS1   ONLINE                     545926 /u02/oradata/sales/sysaux01.dbf  SYSAUX     ONLINE                     545926 /u02/oradata/sales/users01.dbf   USERS      ONLINE                     545498 /u02/oradata/sales/example01.dbf EXAMPLE    ONLINE                     545926 /u02/oradata/sales/perfstat.dbf  PERFSTAT   ONLINE                     545926

    6 rows selected.

      显然,在将users表空间置于backup状态的时候,相应的datafile的文件头的scn就不会再发生改变,发生检查点也不会改变。

SQL>; alter system checkpoint

System altered.

SQL>; select NAMETABLESPACE_NAMESTATUSCHECKPOINT_CHANGE# 

from v$datafile_header

NAME                TABLESPACE STATUS       CHECKPOINT_CHANGE#

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

/u02/oradata/sales/system01.dbf  SYSTEM     ONLINE                     546196 /u02/oradata/sales/undotbs01.dbf UNDOTBS1   ONLINE                     546196 /u02/oradata/sales/sysaux01.dbf  SYSAUX     ONLINE                     546196 /u02/oradata/sales/users01.dbf   USERS      ONLINE                     545498 /u02/oradata/sales/example01.dbf EXAMPLE    ONLINE                     546196 /u02/oradata/sales/perfstat.dbf  PERFSTAT   ONLINE                     546196

6 rows selected.

 

      下面end backup,看看scn

SQL>; alter tablespace users end backup

Tablespace altered.

    SQL>; alter system checkpointSystem altered.

    SQL>select NAMETABLESPACE_NAMESTATUSCHECKPOINT_CHANGE# from v$datafile_header

    NAME               TABLESPACE STATUS         CHECKPOINT_CHANGE#

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

/u02/oradata/sales/system01.dbf  SYSTEM     ONLINE                     546467 /u02/oradata/sales/undotbs01.dbf UNDOTBS1   ONLINE                     546467 /u02/oradata/sales/sysaux01.dbf  SYSAUX     ONLINE                     546467 /u02/oradata/sales/users01.dbf   USERS      ONLINE                     546467 /u02/oradata/sales/example01.dbf EXAMPLE    ONLINE                     546467 /u02/oradata/sales/perfstat.dbf  PERFSTAT   ONLINE                     546467

    6 rows selected.

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

 

       再说说rman备份个人认为理解了用户管理的热备份,rman就已经理解了一大半了rman 备份是针对块一级的,支持增量备份,稍后说怎么做的增量备份

 

Rman备份并不需要将数据库或者表空间置于backup状态,但是它会把scn记录在catalog中对应你的backupset准备在恢复的时候来使用

users表空间做一个完全备份

$ rman target sys/oracle nocatalog 

RMAN>; run { 

2>; allocate channel d1 type disk

3>; backup 

4>; format=''/u03/oraclebk/%d_%N_%s.bk'' tablespace users

5>; release channel d1

6>; }

看一下备份集里都有什么,注意看Ckp SCN  546792

RMAN>; list backup of tablespace users

List of Backup Sets

 =================== 

BS Key  Type LV Size       

Device Type Elapsed Time Completion Time

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

3       Full    1M         DISK        000002     31-MAR-05 

BP Key: 3   

Status: AVAILABLE  

Compressed: NO  

Tag: TAG20050331T153729 

Piece Name: /u03/oraclebk/SALES_USERS_4.bk 

List of Datafiles in backup set 3 

File LV Type  Ckp SCN    Ckp Time  Name

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

4       Full 546792     31-MAR-05 /u02/oradata/sales/users01.dbf

      恢复的时候应用546792开始到现在的归档日志和重做日志。

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

rman的增量备份的基本原理其实很简单,主要就是弄明白在做增量备份时确定某个数据块需要备份,哪个不需要rman在做1级备份的时候怎么来确定0级备份之后都有哪些数据块做了修改呢?

 

看下面一段Each data block in a datafile contains a system change number SCN), which is the SCN at which the most recent change was made to the block. During an incremental backup,RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block.

原来block里边也有一个change scn也就是说在做level 1级备份的时候,需要扫描所有的数据块并且用块中记录修改的SCNlevel 0备份时的SCN做比较(备份记录中的Ckp SCN),来确定这个块是否需要备份。

所以扫描整个数据文件是不可避免的 !

       这是传统的rman做增量备份

       10grman做增量备份不再需要扫描整个数据文件了10g引入的新特性 block change trackingBlock change tracking进程记录自从上一次备份以来数据块的变化,并把这些信息记录在跟踪文件中。RMAN使用这个文件判断增量备份中需要备份的变更数据。这极大的促进了备份性能,RMAN可以不再扫描整个文件以查找变更数据。

RMAN''s change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a change tracking file. If change tracking is enabled,RMAN uses the change tracking file to identify changed blocks for incremental backup,thus avoiding the need to scan every block in the datafile.

估计是使用的位图文件做的记录!

 

       附:有兴趣的可以看看dump的数据块

通过下面的查询找一个表对应的数据块

SQL>; select file_idblock_idblocks 2  

from dba_extents 3  

where segment_name=''EMPLOYEES''

    FILE_ID   BLOCK_ID     BLOCKS

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

    5         81          8

dump一个块到udumptrc文件

SQL>; alter system dump datafile 5 block 81

    System altered.

udump目录找到对应的trc文件,找到dump那段

Start dump data blocks tsn: 

file#: 5 minblk 81 maxblk 81 buffer 

tsn: 

rdba: 0x01400051 5/81

scn: 0x0000.00086c4d 

seq: 0x01 

flg: 0x04 

tail: 0x4b502001后面省略了

scn: 0x0000.00086c4d16进制你可以换算过来552013你可以尝试做一下修改,不过一定要保证对应的块被修改了,并且被写了,才能反映出来。

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

上一篇: lun参考
下一篇: Solaris系统日志
请登录后发表评论 登录
全部评论

注册时间:2009-05-13

  • 博文量
    22
  • 访问量
    77510