RMAN不恰当配置导致Oracle数据库备份死慢

这是一个发生在Oracle数据库上使用RMAN进行数据库操作因在默认配置中使用不合适的配置导致备份性能慢到不能接受的问题。

在整个问题解决过程中，涉及了存储商、网络、操作系统以及Oracle等等。解决过程复杂和艰难，甚至都开始怀疑自己了，到最后峰回路转，在RMAN备份的输出日志发现了关键信息，使得问题得以解决。

这个问题我们想复杂了。如果我们能仔细一点，多看看日志信息，就能节省很多时间和人力，就不会绕这么一个大圈子。

 

(miki西游 @mikixiyou 原文链接: http://mikixiyou.iteye.com/blog/1576408 )

1. 环境

客户的数据库系统运行在Linux Redhat系统上。数据库系统为Oracle 10.2.0.5.6,三节点RAC。

数据库名称为WEBDB，归档模式运行。数据库目前大小约900GB，每天生成的归档日志量约50GB，但在最高峰时也会有100GB。

数据库备份采用RMAN工具备份到挂载到服务器的磁盘上。

2. 问题

数据库备份时，每秒钟只能写入4MB左右。

如备份88号文件，该文件大小为5GB。

 

RMAN> backup datafile 88 format '/u01/app/oracle/88.bk';

 

Starting backup at 14-3月 -12

using channel ORA_DISK_1

channel ORA_DISK_1: starting compressed full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00088 name=+DG/webdb/datafile/qlzq50.dbf

channel ORA_DISK_1: starting piece 1 at 14-3月 -12

channel ORA_DISK_1: finished piece 1 at 14-3月 -12

piece handle=/u01/app/oracle/88.bk tag=TAG20120314T113321 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:04:35

Finished backup at 14-3月 -12

 

Starting Control File and SPFILE Autobackup at 14-3月 -12

piece handle=/dbbackup/webdb/c-3243882293-20120314-04 comment=NONE

Finished Control File and SPFILE Autobackup at 14-3月 -12

备份时间为4分35秒，备份结果集为1.1GB。

多次备份测试，备份速度都是这样。

3. 分析

在新环境的10.2.0.4上的环境下，先期创建一个数据库，名称为WEBDB ，同原网站数据库名称一致。

这个数据库是新迁移的过来的，数据库版本也是新升级到10.2.0.5。以前的版本是10.2.0.4，那个时候备份并不慢。

新库和老库用的是一类服务器，同是64核CPU和32GB内存。新库接的存储柜子是扩展柜，而老库用的是主柜子。

我们首先分析RMAN备份过程中，会话的等待事件，发现其始终是“RMAN backup & recovery I/O”等待事件。

检查的方法是“select * from v$session_event a where a.SID=1450;”。

就是说从数据库层面看，系统在RMAN的IO上操作。

整个过程中，系统负载很低，很稳定。

我们再分析RMAN备份过程中的IO情况。这个从系统和数据库性能视图两个方面去分析。

一方面系统上，我们使用vmstat -1 ,iostat –m 1，结果显示系统IO很差，只有5MB每秒的写，读稍微大些，约30-40MB每秒。但不能完全达到存储正常的IO值。

经过存储工程师对存储性能的测试，证明其IO能力为每秒160MB的读，每秒120MB的写。但在RMAN的BACKUP备份时，这个性能从来没有出现过。

另一方面数据库上，我们查询性能系统视图，方法为“select * from v$backup_async_io where open_time >sysdate-1/2；”，发现RMAN备份的读为16MB每秒，而写为4MB每秒，很稳定。

在查询ORACLE RMAN的原理，发现在正常情况下，一个通道的RMAN IO就是这样的速度。并且，这个样写入也没消耗多少时间。（这段表述可能有误，请参考官方的RMAN_BUFFER.dbf文档）

到这个地步，从数据库的信息中，看不到备份过程在其他时间在干什么。备份的读写速度都很正常，但系统就不能快速完成备份。

这里使用的是RMAN BACKUP工具，我们又想到一种备份方法，RMAN COPY。这种COPY是单纯地拷贝文件，过程就是将ASM磁盘组上文件拷贝到文件系统上，不做任何更改。

经过测试，发现这种方法很快，在备份到本地硬盘时，5GB的文件时间只要55秒，而即使备份到存储上，时间也只要2分45秒。

以下是测试对照表。

RMAN copy 方式

节点3    备到本地   55秒

节点2    备到本地   56秒

节点1    备到本地   55秒

节点1    备到存储   2分45秒

RMAN backup 方式

节点1    备到本地   4分35秒

节点1    备到存储   4分35秒

在数据库层面上，无能为力之后，我们挖掘到更下一层，直接分析进程操作在操作系统层面都干了什么。

这里使用的是LINUX下的STRACE分析进程的工具。

此工具通用的完整用法是：

strace -o /tmp/output2.txt -T -tt -e trace=all -s 12 -p 17129

必须记住的参数：
1）strace -p pid  可以跟踪某个后台进程
2）strace -o filename 把跟踪结果输出到文件
3）strace -T 记录每个系统调用花费的时间，可以看看哪个系统调用时间长
4）strace -t （或者 -tt）记录每个系统调用发生是的时间（时分秒的格式）
5）strace -s 1024 显示系统调用参数时，对于字符串显示的长度， 默认是32，如果字符串参数很长，很多信息显示不出来。
6）strace -e trace=nanosleep 只记录相关的系统调用信息。    -e trace=network // 只记录和网络api相关的系统调用
    -e trace=file // 只记录涉及到文件名的系统调用
    -e trace=desc // 只记录涉及到文件句柄的系统调用
    还有其他的包括process，ipc，signal等。

我们将COPY和BACKUP两种方式的strace结果做了分析，发现pread和pwrite操作时间并没有出入。相反，BACKUP备份时，PWRITE的次数更少，但每次操作的时间没有多大出入。而最终结果却是一个55秒，一个4分35秒，相差有五六倍之多。

未采用的测试方法：

1、在WEBRAC环境上新搭建个数据库，测试一下是不是数据库配置导致，以判断是OS级别的配置还是DB级别的配置问题。但因为已经是生产环境而作罢。

2、调整RMAN BUFFER涉及的隐含参数。

如写的参数_db_file_direct_io_count 等。但因为是生产环境，风险大而作罢。

3、搭建测试环境，分析是不是10.2.0.5的问题。这是第一个采用10.2.0.5的项目。但客户有RYDRAC就是10.2.0.5，同样版本，但测试结果很正常，完全没有问题，虽然RYDRAC挂载的存储性能比这个存储要好一些。

RMAN BACKUP备份所消耗的时间去掉正常的读、写操作，还有读和写之间都做了什么操作？时间大部分都消耗在这读写之间的操作了。如将数据块从ASM磁盘组读取到内存中，做何种操作，再写入到文件系统磁盘中。

一度认为CPU的个数太多，会不会是超线程的问题？

一度认为这个存储是不是异步IO？

 

4. 解决

在苦苦探寻RMAN BACKUP在读和写之间做了什么操作时，突然从RMAN的备份日志中发现一条有价值的信息。

其实，这个时候，应该去看RMAN的工作原理。

这个备份日志如下，仔细看：

Starting backup at 14-3月 -12

using channel ORA_DISK_1

channel ORA_DISK_1: starting compressed full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00088 name=+DG/webdb/datafile/qlzq50.dbf

channel ORA_DISK_1: starting piece 1 at 14-3月 -12

channel ORA_DISK_1: finished piece 1 at 14-3月 -12

piece handle=/u01/app/oracle/88.bk tag=TAG20120314T113321 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:04:35

Finished backup at 14-3月 -12

发现关键字在这行“channel ORA_DISK_1: starting compressed full datafile backupset”，关键字就是“compressed“，这个channel启用了压缩机制。

检查RMAN的配置，发现disk的参数选项是这样的：

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;

 

默认的disk类型的设置居然是带压缩的。

将压缩取消，修改如下：

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;

 

old RMAN configuration parameters:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;

new RMAN configuration parameters:

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;

new RMAN configuration parameters are successfully stored

 

5. 测试

再使用RMAN BACKUP工具测试88号文件的备份。过程如下：

RMAN> backup datafile 88 format '/u01/app/oracle/88.bk';

 

Starting backup at 14-3月 -12

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00088 name=+DG/webdb/datafile/qlzq50.dbf

channel ORA_DISK_1: starting piece 1 at 14-3月 -12

channel ORA_DISK_1: finished piece 1 at 14-3月 -12

piece handle=/u01/app/oracle/88.bk tag=TAG20120314T133447 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45

Finished backup at 14-3月 -12

 

Starting Control File and SPFILE Autobackup at 14-3月 -12

piece handle=/dbbackup/webdb/c-3243882293-20120314-10 comment=NONE

Finished Control File and SPFILE Autobackup at 14-3月 -12

 

RMAN>

这次备份到本地硬盘的，时间和BACKUP COPY的时间几乎一样，为45秒，备份的结果集从1.1GB涨到5GB。这是没有压缩选项的备份。备份速度为每秒110MB。

这个可以解释，在读写之间的时间都消耗在压缩数据块上了。在没有压缩的备份操作过程中，系统的负载明显上升，系统出现排队堵塞的进程。这表示备份已经将IO资源基本占用。

测试一次到挂载的存储上的备份操作，如下：

RMAN> backup datafile 88 format '/test/88.bk';

 

Starting backup at 14-3月 -12

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00088 name=+DG/webdb/datafile/qlzq50.dbf

channel ORA_DISK_1: starting piece 1 at 14-3月 -12

channel ORA_DISK_1: finished piece 1 at 14-3月 -12

piece handle=/test/88.bk tag=TAG20120314T152831 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:56

Finished backup at 14-3月 -12

 

Starting Control File and SPFILE Autobackup at 14-3月 -12

piece handle=/dbbackup/webdb/c-3243882293-20120314-11 comment=NONE

Finished Control File and SPFILE Autobackup at 14-3月 -12

 

RMAN>

时间也只要56秒，备份结果集为5GB。

这个速度是每秒91MB的写入量，和存储工程师测试每秒120MB的值基本相当了，和以前的每秒4MB，提升了20倍。

6. 总结

这个性能问题，是一个非常隐蔽的不当设置导致的。

这个压缩设置，很有可能是在以前备份时，空间不够而选择设定的。当时的目的就是选择牺牲时间获取空间的方式。

在新环境下，我们使用RMAN迁移，RMAN的配置也一并迁移过来而没有察觉。随着库逐渐增大，到今天这个地步，而备份的空间又足够了，时间问题又浮现出来。

但压缩设置已经一两年前设置的，show all显示参数也很隐蔽，导致了我们从数据库分析到操作系统，从操作系统到存储，又从存储一路杀回来。其间过程之曲折，实在一言难尽。

警示：RMAN 备份 压缩机制 需要慎重使用。出现性能问题，首先检查有没有这个压缩设置。