备份的优化和调整

Posted 2021-09-12 diuxie

在了解备份优化之前首先要知道RMAN 备份的原理：

当RMAN 发起备份任务时，会开启相应的通道工作，每一个通道在数据库服务器都有一个相对应的服务进程，RMAN 会首先调用DBMS_RCVMAN 包读取控制文件，确定数据文件的存放位置等信息，获取该信息后，RMAN 将调用DBMS_BACKUP_RESTORE 包对数据文件进行读取并备份。读取过程就是基于RMAN 备份的算法规则来编译需要备份的文件列表。RMAN 执行备份操作时，会请求Oracle 的共享内存段来创建自己备份缓冲区，与通道相对应的服务进程会去扫描数据文件中的数据块，并且将需要备份的数据块读入到输入缓冲区中，当输入缓冲区被填满时，会被转移到输出缓冲区，在转移的过程中，也会对数据块进行检测，检测是否有损坏的数据块，当输出缓冲区被填满时，就会形成备份片，与通道相对应的服务进程最终会将其写入到指定备份片的位置。

所有的备份恢复不能千篇一律，需要契合不同客户的生产环境针对性的去调整和优化，否则很有可能会导致生产环境出现问题。生产环境场景有：备份磁盘空间不足、存储I/O 慢、存储很快且cpu 资源足够等。

RMAN 备份的优点如下（以11g 为例）：

1 ）RMAN 会检测数据坏块

2 ） 不需要开热备，额外的重做会减少

3 ）RMAN 备份只备份使用过的块

4 ）RMAN 备份具有压缩特性

5 ） 支持增量备份策略

对于不同的场景我们需要给出不同的优化方法：

场景一：划分的备份文件系统空间不足：
存在这么一种情况，查询数据库大小略大于备份空间大小我们怎么处理？

这就要从rman 的备份特性说起两个概念：

1 ）null block compression

2 ）unused block compression

10.1 版本 RMAN 的压缩方式为空值压缩（null compression ），当扫描数据块进行备份时，可以进行空值压缩，对块头为空的块，在从输入缓冲区转移到输出缓冲区时将其过滤掉，不会去备份已分配但未被格式化的块。

在10.2 版本RMAN 的压缩方式又出现一种未使用块压缩（unused block compression ），这种压缩方式是过滤掉不包含数据的数据块，就是该数据块已经被使用过（被格式化过），但是不包含数据。

只有在满足以下条件的时候，Unused Block Compression 会起作用:

1 ）初始化参数COMPATIBLE=10.2 或者更新的版本
2 ）数据文件是本地管理模式

3 ）完全备份或0 级备份

4 ）备份的指定位置在磁盘上

所以备份出来的备份片相当于被压缩过，所以这也是rman 游戏备份工具一个很重要的特性，减少不必要的空间浪费。

场景二：备份文件系统空间非常小
这时候我们很容易想到rman 的压缩特性，rman 能够使用二进制压缩算法进行备份，这个二进制的压缩算法能够大大的减少备份集所需要的磁盘空间，通常情况下压缩比会达到2-4 倍

使用这种压缩方式的命令如下:

rman> backup as compressed backupset database;

1 ）启用压缩将消耗更多的CPU 资源。。

2 ）启用压缩备份耗时略有增加

3 ）节省存储备份的空间

场景三：备份片很大，备份时间较长
加快备份速度的方法无非是开并行，这里涉及到两个关键词：通道、并行

自动分配通道（CHANNEL ）：

Configure 命令来完成通道配置。如果没有用手工方式为RMAN 分配通道，RMAN 将利用预定义的设置来为命令自动分配通道

RMAN>Configure channel device type disk format ‘xxx’;

可配置自动分配多个通道

手工分配通道（PARALLELISM ）：

allocate channel 命令进行分配通道，这个命令只能放在run 命令块中，并且它分配的通道也只作用于本run 块内的命令。

run {

Allocate channel d1 device type disk format ‘xxx’;

Allocate channel d2 device type disk format ‘xxx’;

Backup database;

release channel d1 ；

release channel d2 ；

}

注意 如果配置的通道个数据小于 PARALLELISM ，如 PARALLELISM 为 5 ， configure channl 1 ， 2 ， 3 则 1 ， 2 ， 3 指定的配置备份 4 ， 5 按默认的配置来备份。如果配置的通道大于 PARALLELISM ， PARALLELISM 为 3 ，配置 5 个通道，则通道 4 ， 5 被忽略

一个 CPU 任一时刻只能处理一个事务，并行度不能超过 CPU 数量。

场景四：数据库数据量很庞大，增量备份需要较长时间
这里需要打开一个数据库的特性：块跟踪

1 ）块修改跟踪会记录数据文件里每个块的更新信息，这些跟踪信息保存在跟踪文件里。当启动块修改跟踪后，RMAN 使用跟踪文件里的信息，只读取改变的www.sangpi.com块信息，而不用在对整个数据文件进行扫描，从而提高了RMAN 备份的性能。

2 ）块修改跟踪默认是禁用的，如果启用了增量备份，那么建议开启块修改跟踪。 启用BCT 后，不需要其他的维护操作。

3 ）在备份期间，修改跟踪会维护已经标记为更改的块的位图信息。Oracle 会自动管理修改跟踪文件的大小，只保留最近最近8 次块更改的信息。 超过8 次，那么最前面的块位图信息会被当前的更改覆盖。

4 ）第一个0 级的增量备份扫描整个数据文件。随后的增量备份使用块跟踪文件的信息，只扫描自上次备份以来被标记为更改的块。

5 ）如果是RAC 环境，块跟踪文件必须放在共享设备上。

6 ）数据库在open 或者 mounted 状态都可以启用块跟踪.

打开块跟踪：

（1 ） 查看是否设置路径

SQL> showparameter db_create_file_dest

NAME TYPE VALUE

---

db_create_file_dest string

（2 ） 设置存放块跟踪文件路径

SQL> alter system set db_create_file_dest = \'oracle/blkch\' scope=both sid=\'*\';

System altered.

（3 ） 检查设置路径

SQL> show parameter db_create_file_dest

NAME TYPE VALUE

---

db_create_file_dest string oracle/blkch

SQL>

（4 ） 打开块跟踪

SQL> alter database enable block change tracking;

Database altered.

也可以直接指定目录或者复用已存在的文件

SQL>alter database enable block change tracking using file \'oracle/blkch/blkch.chg\' reuse;

禁用块跟踪：

SQL>alter database disable block change tracking;

查看块跟踪是否可用：

SQL> select status, filename fromv$block_change_tracking;

STATUS FILENAME

---

ENABLED /oracle/blkch/blkch.chg

注意 快跟踪使用场景一般有两种： 1 、常规含有增量备份的 RMAN 备份策略； 2 、应用于 XTTS 迁移，可以有效加快增量数据的备份。

在使用 RMAN 增量备份的情况下，启用块跟踪，在做增量备份时会缩短 RMAN 备份的时间， 因为不用扫描整个数据文件。 但是块跟踪也会带来其他的一些开销。 所以要根据实际情况决定是否启用块跟踪。