rman Oracle Recovery Manager新说

vs. 存储功能备份
备份的全面损坏的风险
备份的性能与负荷
管理性
破损块对策
ASMrebalance的影响
restore& recovery的灵活性

D2D（Storage Backup） vs. Oracle Recovery Manager

		D2D	RMAN
备份的全部损坏风险		× 有全部损坏风险	◎ 可以通过高速增量备份回避
备份的性能与负荷	消費资源	◎ 仅限存储的资源	△ 使用服务器的资源
	总I/O量	○ 仅限sector单位中的差分	○ 仅限块单位中的差分
	保持数据总量	△ 与正式volume同等的尺寸	○ 可以压缩、减少
	Redo生成量	× 备份中増加	◎ 与一般的情况相同
管理性		× 人工管理比较麻烦	○ 自动管理
泛用性		△ 依赖于存储供应商	○ 从H/W结构中独立出来
破损块对策		× 不可以区分正常or破损	◎ 备份时可以检测
ASMrebalance的影响		× 差分数据量大幅増加	◎ 没有影响
备份的加密		× 因为是正式volume的拷贝，所以无法加密	○ 可以加密
价格		× 数千万～数亿	○ EE标准功能
restore& recovery	灵活性	△ 最小也是LU单位	○ 可以对应块单位
restore& recovery	管理性	× 依赖于DBA的技能	○ 通过建议器自动判断

备份方式的讨论結果重新理解RMAN的优点

上一页的比较表是D2D中长期使用某巨大系统备份的优秀的Sier的同志们评价的结果。

–9ià11g的升级案例 –决定了大部分D2D的备份对策的状态 –通过联合使用OCS & SC & Dev ，仅过2个多月，就采用了RMAN 之后我将介绍RMAN的优点 D2D（Disk to Disk）备份 顺序

通过RMAN进行的高速增量备份 使用顺序

D2D vs. RMAN（高速增量备份） 使用顺序的比較与D2D的缺点

实际上，备份的数据量与复制时间都几乎相同

–D2D虽然给客户瞬间就可以完成备份的错觉。但实际上是后台进行数据拷贝

然后客户会提出这样的疑问，觉得二者是完全相同的！！

–使用D2D备份时，正式volume坏了的话，是否可以修复？ NG：因为会被覆盖，所以没有有效备份 必须有两个备份or tape备份 一方面，RMAN的分割增量与更新的Phase也没有问题 D2D（Disk to Disk）备份 同步中的发生故障的话就无法修复

备份的性能与负荷 消費资源

总I/O量

Block Change Tracking 的结构 BCT File的尺寸

BCT的文件尺寸非常小

–数据库的尺寸以及Redo的线程数的比例 –与数据库更新频率无关 –初始尺寸10MB –通常、数据库的块尺寸（?）约1/30,000 x节点数

300GB以内为10MB、600GB时为20MB+α

–不依赖于数据文件的尺寸（每个都在320KB以上） =》因为bitmap管理中尺寸都较小，所有没有较大的I/O

对BCT File写出时，不仅DBWR，CTWR也会执行事务与非同步

–不会影响Commit的响应时间 –DBWR对数据文件写入之前是否需要一起使用?

CTWR进程仅仅在BCT有効的情况下启动

–经过Large Pool(不足时的Shared Pool)内的「CTWR dba buffer」

SQL> select pool,name,sum(bytes)/1024 from v$sgastat where name like 'CTWR';
POOL NAME SUM(BYTES)/1024
-------------------- ------------------ ---------------
large pool CTWR dba buffer 1392

Block Change Tracking 的结构备份时的I/O尺寸

备份时的I/O尺寸（块数）的最优化

–高速增量备份时仅仅读取更新块的操作 –变成随机I/O，通过完整备份，比较多块I/O的话吞吐量就会降低 –但是根据更新量不同，需要查看将I/O尺寸最优化的操作 备份的性能与负荷 保持数据总量

Redo生成量

备份的性能与负荷 Begin backup命令的高速化（虽然与RMAN无关）

Oracle 9i Database中、Begin backup命令的响应时间较缓慢的问題（Oracle Database 10g Release1中解决完成）

–KROWN#120942

缓冲区高速缓存尺寸、数据文件数的比例，BEGIN BACKUP也需要时间
例） R9.2.0.8中，一个数据文件的Begin Backup所需要的时间

–缓冲区高速缓存10GB时：約0.06秒 –缓冲区高速缓存24GB时：約0.15秒（11gR2中0.00秒） 管理性 数据文件以外的备份相关文件

RMAN> DELETE OBSOLETE命令的修正

RMAN的DELETE OBSOLETE命令是遵循删除对策，删除归档日志的命令

–可能出现无视删除对策，没有传送到Standby Site（或者没有完成应用）的归档日志被删除的情况 –通过Bug#12357315修正 破损块对策 是否是可以恢复的备份？

RMAN的块破损检测默认设定中，检测到一个块破损的话就终止

RMAN> -- 执行增量备份
backup incremental level 1 tablespace RTEST1;

Backup开始(开始时间: 12-07-23)
使用channelORA_DISK_1
使用channelORA_DISK_2
channelORA_DISK_1: 开始设定增量水平1的数据文件备份
channelORA_DISK_1: 在备份设定中指定数据文件
入力数据文件文件番号=00010 名前=+DATA/o11g/datafile/rtest1.282.789398885
channelORA_DISK_1: 启动piece 1(12-07-23)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: backup命令(ORA_DISK_1channel上) 在07/23/2012 16:22:00失败了
ORA-19566: 超过了破损块的限制0(文件+DATA/o11g/datafile/rtest1.282.789398885)

SQL> select * from V$DATABASE_BLOCK_CORRUPTION;

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
---------- ---------- ---------- ------------------ ---------------------------
 10 14980 1 6681461 FRACTURED


RMAN> --特定块的修復
recover datafile 10 block 14980 ;

开始recover (开始时间: 12-07-23)
使用channelORA_DISK_1
使用channelORA_DISK_2
Stand by搜索完成，restore了1个块

Media Recovery开始
Media Recovery完成。消耗时间: 00:00:01

recover完成 (完成时间: 12-07-23)

SQL> --查看破损对象
SELECT SEGMENT_TYPE, OWNER||'.'||SEGMENT_NAME "SCHEMA.TABLE"
  FROM DBA_EXTENTS
 WHERE 10 = FILE_ID 
   AND 14996 BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS -1 ;

SEGMENT_TYPE   SCHEMA.TABLE
-------------  -------------
TABLE          RUSER.RTBL1

多个块出现破损时的注意事项需要重复破损块的次数、以及下一个处理开始备份检测块破损 终止备份修复破损块可以设定破损块检测数的上限（MAXCORRUPT）

RMAN> -- 总之先无视，完成备份。
 RUN
 {
 SET MAXCORRUPT FOR DATAFILE 10 TO 128 ;
 backup incremental level 1 tablespace RTEST1;
 }

MAXCORRUPT的弱点

通过设定MAXCORRUPT，可以一边检测多个快破损一边完成备份

–已检测到的破损块可以通过以下命令来一起修复 RMAN> RECOVER CORRUPTION LIST;

但是，备份是否是正常的呢？
重新执行一次高速增量备份，是否可以备份修复完成的状态呢？

由于以下两个原因，可能会出现无法获得修复完成的块的备份的情况。

–因为RMAN的backup完成所以BCT的版本切换了

由于MAXCORRUPT设定，即使检测到块破损，如果backup命令正常完成的话，通过切换BCT的版本，就无法获得同样范围的备份。

–RMAN的块修复没有在BCT中tracking

通过RMAN的recover corruption命令修复破损块的I/Oは、因为没有在BCT中tracking，只要应用没有更新，就不会对块进行高速增量备份

通过与其他Oracle的数据破损对策（ASM镜像等）与的併用

–备份时时将检测到的破损块数最小化 –MAXCORRUPT的设定是默认的 –检测到2次时（循环）对数据库整体执行VALIDATE

请开发RMAN的结构

–备份时如果检测到了破损块就自动修复

（附赠）只是检测到一个破损块

–BCT文件中tracking完成的块全部修复完成（高速增量备份对象的块）通过BCT查看tracking完成的块

SQL> update RTBL1 set COL2='hoge' where COL1=100;
commit;
select dbms_rowid.rowid_relative_fno(rowid,'SMALLFILE') "FNO",　dbms_rowid.rowid_block_number(rowid,'SMALLFILE') "BNO" 
 from RTBL1 where COL1=100;
 FNO BNO
---------- ----------
 10 146
variable FNO number;
execute :FNO := 10
select B.* from X$KRCFDE A, X$KRCBIT B
where A.FNO = B.FNO and A.FNO = :FNO and A.CURR_VERCNT = B.VERCNT ;

ADDR INDX INST_ID CTFBNO VERCNT VERTIME CSNO FNO BNO BCT
---------------- ---------- ---------- ---------- ---------- -------- ---------- ---------- ---------- ----------
00002B7E775BAED8 2519 1 4096 16 12-07-23 1 10 144 4
===> 144~148(144+4)的块被BCT File追踪了。

ASMrebalance的影响 与之前备份你的差分数据量的差异

查看BCT File中是否完成tracking(4

本环境中，因为Fileno=3是UNDO表区域，所以推测为UNDO表区域的変更已经被Tracking了。



SQL> -- 将BCT有效化
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+DATA(CHANGETRACKING)' REUSE;

SQL> -- 有效化完成之后的Bitmap Extent供应商的状态
set linesize 150 pagesize 5000
select CTFBNO, FNO, VERCNT, to_char(VERTIME, 'YYYY/MM/DD HH24:MI:SS'), 
       HIST_FIRST, HIST_LAST, HIST_EXTCNT, HIST_VERCNT, HIST_VERTIME,
       LOW, HIGH from X$KRCFBH;
       
    CTFBNO        FNO     VERCNT TO_CHAR(VERTIME,'YY HIST_FIRST  HIST_LAST HIST_EXTCNT HIST_VERCNT HIST_VER        LOW       HIGH
---------- ---------- ---------- ------------------- ---------- ---------- ----------- ----------- -------- ---------- ----------
      2304          0          0                              0          0           0           0                   0          0
      2368          0          0                              0          0           0           0                   0          0
      2432          3          1 2012/06/18 19:03:39          0          0           0           0                   0          0
      2496          0          0                              0          0           0           0                   0          0
      2560          0          0                              0          0           0           0                   0          0
      2624          0          0                              0          0           0           0                   0          0
      
	  
	  本环境中、Fileno=9，构成制成段的SSD_TBS_1表区域的数据文件


	  SQL> -- 制成一个段。
create table TEST1 (col1 number) segment creation immediate tablespace SSD_TBS_1;

SQL> -- 是否完成tracking
select CTFBNO, FNO, VERCNT, to_char(VERTIME, 'YYYY/MM/DD HH24:MI:SS'), 
       HIST_FIRST, HIST_LAST, HIST_EXTCNT, HIST_VERCNT, HIST_VERTIME,
       LOW, HIGH from X$KRCFBH;

    CTFBNO        FNO     VERCNT TO_CHAR(VERTIME,'YY HIST_FIRST  HIST_LAST HIST_EXTCNT HIST_VERCNT HIST_VER        LOW       HIGH
---------- ---------- ---------- ------------------- ---------- ---------- ----------- ----------- -------- ---------- ----------
      2304          1          1 2012/06/18 19:03:39          0          0           0           0                   0          0
      2368          2          1 2012/06/18 19:03:39          0          0           0           0                   0          0
      2432          3          1 2012/06/18 19:03:39          0          0           0           0                   0          0
 ......................
      4352          0          0                              0          0           0           0                   0          0
      4416          9          1 2012/06/18 19:03:40          0          0           0           0                   0          0
      4480          0          0                              0          0           0           0                   0          0

	  
	  本环境中、Fileno=9是构成制成段的SSD_TBS_1表区域的数据文件

	  
	  
	  SQL> --制成一个段。
create table TEST1 (col1 number) segment creation immediate tablespace SSD_TBS_1;

SQL> --是否完成tracking
select CTFBNO, FNO, VERCNT, to_char(VERTIME, 'YYYY/MM/DD HH24:MI:SS'), 
       HIST_FIRST, HIST_LAST, HIST_EXTCNT, HIST_VERCNT, HIST_VERTIME,
       LOW, HIGH from X$KRCFBH;

    CTFBNO        FNO     VERCNT TO_CHAR(VERTIME,'YY HIST_FIRST  HIST_LAST HIST_EXTCNT HIST_VERCNT HIST_VER        LOW       HIGH
---------- ---------- ---------- ------------------- ---------- ---------- ----------- ----------- -------- ---------- ----------
      2304          1          1 2012/06/18 19:03:39          0          0           0           0                   0          0
      2368          2          1 2012/06/18 19:03:39          0          0           0           0                   0          0
      2432          3          1 2012/06/18 19:03:39          0          0           0           0                   0          0
 ......................
      4352          0          0                              0          0           0           0                   0          0
      4416          9          1 2012/06/18 19:03:40          0          0           0           0                   0          0
      4480          0          0                              0          0           0           0                   0          0

	  
	  
	  SQL> -- 对ASM Diskgroup追加磁盘，执行rebalance
alter diskgroup SSDG drop disk SSDG_0001 rebalance power 11 wait;

SQL> -- 确认tracking信息是否被变更
select CTFBNO, FNO, VERCNT, to_char(VERTIME, 'YYYY/MM/DD HH24:MI:SS'), 
       HIST_FIRST, HIST_LAST, HIST_EXTCNT, HIST_VERCNT, HIST_VERTIME,
       LOW, HIGH from X$KRCFBH
 where FNO > 3 and FNO != 9 ;
no rows selected

通过ASM rebalance查看tracking信息是否发生变化
换言之，通过RMAN，不会影响高速增量备份




restore& recovery的灵活性

根据故障范围，以最优的单位进行restore& recovery

D2D（Storage Backup） vs. Oracle Recovery Manager

		D2D	RMAN
备份的全部损坏风险		× 有全部损坏的风险	◎ 通过高速增量备份回避
备份的性能与负荷	消費资源	◎ 仅限存储的资源	△ 使用服务器的资源
	总I/O量	○ 仅限sector单位中的差分	○ 仅限块单位中的差分
	保持数据总量	△ 正volume与同等的尺寸	○ 可以压缩/减少
	Redo生成量	× 备份中会增加	◎ 与一般情况相等
管理性		× 手动管理变得复杂	○ 世代管理的自动化
汎用性		△ 依赖于存储供应商	○ 从H/W结构中独立
破损块对策		× 正常or破损的区別も不可	◎ 备份时可以检测
ASMrebalance的影响		× 几乎对整个备份都有	◎ 没有影响
备份的加密		× 正volume的拷贝，所以不可以	○ 可以加密
价格		× 数千万～数亿	○ EE标准功能
restore& recovery	灵活性	△ 最小也是LU单位	○ 可以通过块单位处理
restore& recovery	管理性	× 依赖DBA的skill	○ 通过建议器自动判断