备份的优化和调整

在了解备份优化之前首先要知道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 备份的时间, 因为不用扫描整个数据文件。 但是块跟踪也会带来其他的一些开销。 所以要根据实际情况决定是否启用块跟踪。

你可能感兴趣的:(备份的优化和调整)