这是一个发生在Oracle数据库上使用RMAN进行数据库操作因在默认配置中使用不合适的配置导致备份性能慢到不能接受的问题。
在整个问题解决过程中，涉及了存储商、网络、操作系统以及Oracle等等。解决过程复杂和艰难，甚至都开始怀疑自己了，到最后峰回路转，在RMAN备份的输出日志发现了关键信息，使得问题得以解决。
这个问题我们想复杂了。如果我们能仔细一点，多看看日志信息，就能节省很多时间和人力，就不会绕这么一个大圈子。
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？