Oracle联机热备份的原理及rman增量备份原理

要求归档模式
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 filename,d.tablespace_name ts_name,b.status
2 from dba_data_files d,v$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一直到现在的日志（完全恢复的话）
举个例子：
a,b两个数据文件，把a置于备份模式，b正常这时候两个change scn都是100，然后开始备份这期间有数据库的修改，备份完成的时候，Scn变成了200。但是由于a的备份模式，所以a的文件头中记录的scn还是100，b是200。某个时间，假设scn 500这时候a丢失
copy回a的备份，然后recover,完全恢复的话数据库就应用100—500这段的日志，自然也就不会丢失数据了。因为不管在我copy备份的过程中你做什么操作，总之都在锁定的时change scn之后，所以应用的日志就不会有遗漏了。这时候应该能理解为什么要数据库处于archived模式了

看看数据文件头的change scn
SQL>;select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_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 NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_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 checkpoint;
System altered.

SQL>;select NAME,TABLESPACE_NAME,STATUS,CHECKPOINT_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 00:00:02 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级备份的时候，需要扫描所有的数据块并且用块中记录修改的SCN跟level 0备份时的SCN做比较(备份记录中的Ckp SCN)，来确定这个块是否需要备份。所以扫描整个数据文件是不可避免的 ！
这是传统的rman做增量备份
在10g中rman做增量备份不再需要扫描整个数据文件了
10g引入的新特性 block change tracking：
Block 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_id,block_id,blocks
2 from dba_extents
3 where segment_name='EMPLOYEES';

FILE_ID BLOCK_ID BLOCKS
---------- ---------- ----------
5 81 8

dump一个块到udump的trc文件
SQL>; alter system dump datafile 5 block 81;

System altered.

在udump目录找到对应的trc文件，找到dump那段
Start dump data blocks tsn: 6 file#: 5 minblk 81 maxblk 81
buffer tsn: 6 rdba: 0x01400051 (5/81)
scn: 0x0000.00086c4d seq: 0x01 flg: 0x04 tail: 0x4b502001后面省略了


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

在Oracle备份中，我们可以使用alter tablespace ... begin backup将表空间置于联机备份模式，然后用操作系统命令进行数据文件的物理拷贝，达到备份的目的，这个过程中数据文件还是照样联机，并进行正常的数据插入，但会导致比平常更多的REDO记录的产生
产生较多的REDO记录是由热备引起的，因为在热备过程中，我们采用copy/ocopy命令，这个是属于操作系统的命令，他和Oracle是不相关的，不能和Oracle的内部进程如dbwr进行交互，这样就可能导致热碑块的出现，因为操作系统读取数据文件时，他的IO尺寸并不是block size的大小，一般会更小，这样会导致一个数据块被读取多次，而每次获取的部分都不一致(数据不断更新)，为了恢复这种断裂的热碑块，Oracle进行了数据块前映象这个操作，对于backup模式的数据文件块，在第一次受到DML影响时，先将数据块整个COPY到REDO中，后续的DML在进行UNDO，正常REDO信息的记录，当恢复数据文件时，会先应用最先的数据块前映像，然后才是后续的REDO记录信息，更多的日志记录就是这个前映像产生的，这个不能和UNDO弄混淆，他是整个数据块，而不是简单的行记录，由于Oracle本身不知道在拷贝时那些块可能出现热碑，所以只要是BACKUP期间有DML的块，就按照上面的情况处理，所以如果在backup期间运行大量的批处理程序，日志信息会集聚增多
还有就是为什么alter tablespace ... begin backup要冻结文件头的SCN?
这个主要是以后数据文件做恢复的起始SCN，在BEGIN BACKUP下达后，系统要对表空间执行检查点，并将该检查点前的所有事务应用都固化到数据文件，然后冻结这个SCN，直到使用END BACKUP，使备份过程结束，再更新为新的SCN，冻结的原因是因为使用操作系统命令拷贝数据文件时，他不能保证第一个读取的块就是数据文件头，如果不冻结，则可能从备份开始，已经多次更新了文件头，而此时文件头还没有被拷贝，这样等文件头被拷贝后，他的SCN已经远远大于了数据文件中其他数据块的SCN，这样从文件头的SCN来定位恢复起点就不现实了
从上面可以看出，热备与RMAN的联机备份是存在本质区别的，RMAN是连接目标数据库，产生Oracle用户进程，调用他自身的过程包，与dbwr进行交互，使用Oracle的SGA或PGA进行备份，这样他首先会保证每个块都是一致的，不会出现热碑现象，这样就减少了REDO记录的产生，他也不需要冻结文件头SCN，因为RMAN总是能先读取数据文件头的块，做为DBA，RMAN工具都不能使用的话是很可笑的!!!

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

转载于:http://blog.itpub.net/35489/viewspace-84398/