rman备份_Oracle RMAN(Recovery Manager) – 备份的优化

最新推荐文章于 2024-05-14 12:14:46 发布

weixin_39816024

最新推荐文章于 2024-05-14 12:14:46 发布

阅读量231

点赞数

文章标签： rman备份 rman备份恢复

Oracle RMAN(Recovery Manager) – 备份的优化

看到标题有些人可能疑惑，RMAN不就是备份恢复管理器么？我只要写好几个命令去执行就行了，还有什么可优化的？

但，RMAN备份的优化其实也很重要的，那优化目标是什么：让备份更节省空间、让备份的速度更快、让还原或恢复的速度更快。

备份集备份

备份集备份有压缩功能，这是镜像复制备份没有具备的功能。为了节省磁盘或磁带的空间，备份集可以采取3种压缩方式：空块压缩、未使用块压缩和二进制压缩。

空块压缩

空块压缩发生在通道工作的复制阶段，RMAN将块读入输出缓冲时会检查该块是否为从来没有修改并保存过数据的块，如果是，则RMAN会跳出此块，结果是空块没有进入备份片。此操作与全表扫描后再过滤类似。

未使用块压缩

未使用块压缩发生在通道的读阶段，RMAN读取数据文件头部的区分配位图(Bitmap)，以此获知哪些区(Extent，是由多个连续的数据块组成的一种空间分配单位)已经分配给段使用了，然后仅读取这些区中的块。此操作与利用索引访问表很类似。

如果下面条件符合就会发生未使用块压缩：数据库没有确保的还原点、数据文件的区是本地管理的、备份集的形式是全备或等级0的增量备份、通道的类型是DISK或OSB实现的SBT。

二进制压缩

RMAN支持3个等级的二进制压缩：LOW(低)、BASIC或MEDIUM(中)、HIGH(高)。等级越高，备份时CPU开销越大。

使用configure命令可以设置二进制压缩的等级。

将压缩等级改为CPU消耗最小的LOW：

RMAN> configure compression algorithm 'LOW';

new RMAN configuration parameters:

CONFIGURE COMPRESSION ALGORITHM 'LOW' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;

new RMAN configuration parameters are successfully stored

并行度

RMAN的并行度和通道数有紧密的联系，当然也不是越多越好，每个站点总有一个最佳的通道数的值：SBT设备可以使驱动器的数量；DISK设备主要取决于磁盘书和条带的情况，经过测试找到一个瓶颈最小的最大通道数，可以显著提高备份与还原(大量数据文件)的速度。必要的时候，针对一个数据文件，一般是一个比较大的数据文件，RMAN可以通过"section size"子句利用多个通道对其进行并行备份。

SQL> set pagesize 999

SQL> set line 150

SQL> col name for a60

SQL> select bytes/1024/1024, name from v$datafile where file# = 2;

BYTES/1024/1024 NAME

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

600 +MSDATA/maa/datafile/sysaux.261.792009871

设置为200M是因为数据文件大小600M，而且我设置了3个通道。

RMAN> run{

2> allocate channel a1 device type disk;

3> allocate channel a2 device type disk;

4> allocate channel a3 device type disk;

5> backup section size 200M datafile 2;

6> }

allocated channel: a1

channel a1: SID=45 device type=DISK

allocated channel: a2

channel a2: SID=25 device type=DISK

allocated channel: a3

channel a3: SID=34 device type=DISK

Starting backup at 06-NOV-2012 23:55:43

channel a1: starting full datafile backup set

channel a1: specifying datafile(s) in backup set

input datafile file number=00002 name=+MSDATA/maa/datafile/sysaux.261.792009871

backing up blocks 1 through 25600

channel a1: starting piece 1 at 06-NOV-2012 23:55:43

channel a2: starting full datafile backup set

channel a2: specifying datafile(s) in backup set

input datafile file number=00002 name=+MSDATA/maa/datafile/sysaux.261.792009871

backing up blocks 25601 through 51200

channel a2: starting piece 2 at 06-NOV-2012 23:55:45

channel a3: starting full datafile backup set

channel a3: specifying datafile(s) in backup set

input datafile file number=00002 name=+MSDATA/maa/datafile/sysaux.261.792009871

backing up blocks 51201 through 76800

channel a3: starting piece 3 at 06-NOV-2012 23:55:46

channel a1: finished piece 1 at 06-NOV-2012 23:55:53

piece handle=/u01/recovery/MAA/backupset/2012_11_06/o1_mf_nnndf_TAG20121106T235543_89ldqzk0_.bkp tag=TAG20121106T235543 comment=NONE

channel a1: backup set complete, elapsed time: 00:00:10

channel a2: finished piece 2 at 06-NOV-2012 23:55:58

piece handle=/u01/recovery/MAA/backupset/2012_11_06/o1_mf_nnndf_TAG20121106T235543_89ldr1x0_.bkp tag=TAG20121106T235543 comment=NONE

channel a2: backup set complete, elapsed time: 00:00:13

channel a3: finished piece 3 at 06-NOV-2012 23:55:58

piece handle=/u01/recovery/MAA/backupset/2012_11_06/o1_mf_nnndf_TAG20121106T235543_89ldr49f_.bkp tag=TAG20121106T235543 comment=NONE

channel a3: backup set complete, elapsed time: 00:00:12

Finished backup at 06-NOV-2012 23:55:58

released channel: a1

released channel: a2

released channel: a3

Todd Bao在书中也稍微花些功夫介绍了优化SBT设备备份内容，但我这里省略。

数据块变更跟踪

为了加快等级1增量备份的速度，DBA可以创建一种由位图构成的名为数据块变更跟踪(Block Change Tracking，简称BCT)的文件，该文件以比特位自动标记自最近一次增量备份以来经过变更的数据块在数据文件中的位置。有了这种文件，进行等级1增量备份时，RMAN无须扫描整个数据文件，而只要扫描数据块变更跟踪文件即可发现什么数据块需要备份了。这对缩短增量备份的时间有显而易见的作用，然而，这并非毫无代价，实例必须额外启动一个名为CTWR的后台进程修改数据块变更跟踪文件，对OLTP的应用来说这额外的压力不可以忽略。启用此功能的命令是"alter database enable block change tracking"，比如将跟踪文件取名为BCT:

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bak/disk/BCT' reuse;

关闭该功能的命令为：

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

使用v$backup_datafile视图能够验证增量备份的效率，如下所示blocks_read与datafile_blocks的比值越小说明增量备份读取数据块的数量占文件总数据块的数量就越小，增量备份的效率则越高，启用数据块变更跟踪回报就越高：

SQL> select FILE#, SUM(BLOCKS_READ)/SUM(DATAFILE_BLOCKS) RATIO FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 GROUP BY FILE#;

FILE# RATIO

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

1 1

6 1

2 1

5 1

4 1

3 1

7 1

7 rows selected.

若比值相当高甚至接近于1，就没有理由进行增量备份，不如直接全备，更不用说数据块变更跟踪文件了。

而我这里全部显示为1，因为从0备份到1备份，我的数据库什么变化也没所致。

镜像复制备份优化

镜像复制备份的优点在以前已经说过，而它最大的缺点是浪费空间，根据输入文件大小决定着镜像复制备份文件的大小。但正因为这个备份时的缺点，才造就了其还原时的优点 — 镜像复制利用文件路径的重命名可以使还原操作的时间忽略不计。RMAN的switch命令能够将当前数据文件与其镜像复制备份文件快速互换。

但是这样会带来另一个问题，如果镜像复制备份的频率不高，那么恢复的时候会消耗大量时间，你的镜像复制备份文件是多长时间前的，那么得应用这个时间段所有的归档日志，这基本抹去了镜像复制备份快速还原的好处。但很难找到哪个公司哪个DBA以高频率进行镜像复制备份，尤其是数据库又多又大。

Oracle的给了个优化方案：使用等级1增量备份"更新"镜像复制。

比如这样的方案：

第一次执行整个数据库所有数据文件的镜像复制，并标记为EVERYDAY:

RMAN> backup incremental level 1 for recover of copy with tag 'EVERYDAY' database;

第二次执行相同命令得到以"EVERYDAY"镜像为基础的等级1增量备份：

RMAN> backup incremental level 1 for recover of copy with tag 'EVERYDAY' database;

第二次接着执行以下命令，RMAN会使用增量备份恢复标签为"EVERYDAY"的数据库镜像复制，即所谓的更新镜像复制备份。

RMAN> recover copy of database with tag 'EVERYDAY';

以后，只要保证执行上面的"backup incremental"命令和"recover copy of"命令，就能获得一个"新鲜"的数据库镜像复制，即增量备份的时间换取新的数据库的镜像复制。

下面看具体示例：

先产生一些数据：

SQL> create table luocs.test as select * from dba_objects;

Table created.

SQL> select count(*) from luocs.test;

COUNT(*)

----------

22716

进行一次备份：

RMAN> backup incremental level 1 for recover of copy with tag 'EVERYDAY' database;

Starting backup at 07-NOV-2012 16:49:09

using channel ORA_DISK_1

no parent backup or copy of datafile 1 found

no parent backup or copy of datafile 2 found

no parent backup or copy of datafile 3 found

no parent backup or copy of datafile 5 found

no parent backup or copy of datafile 6 found

no parent backup or copy of datafile 7 found

no parent backup or copy of datafile 4 found