赛门铁克NBU备份oracle慢的问题

环境是这样的：

   数据库是集群（RAC）的，用的是IBM的小型机两台，数据存储是通过光纤交换连接着磁盘阵列的，备份的走向是从小型机到备份服务器最后到磁带库。

   这个问题说起来还不算是ORACLE的问题，当时是用赛门铁克NBU做的备份，备份工程师发现备份很慢速度几乎在2-4M/S，200多G的数据呢，要备到什么时候去，而且备份一段时间后还自动停止了。后来备份工程师说是系统的IO慢问题，也可能是ORACLE的RMAN备份得慢，于是折腾了2个星期去请ORACLE工程师和IBM工程师来做检查测试，ORACLE特难请，因为售后期已经过了，人家基本不鸟人，后来说得很严重就远程测试了一下，说确实慢，没有报错信息，但RMAN配置没有问题（当然我先前也看过也没发现有什么问题就是慢，速度在4M/S）；于是就接着请了IBM工程师，这个更惨，IBM的软件服务是不给远程协助的也不会安排人到现场，而且AIX系统又没几个人懂，只给了个邮件过来，下载了个perfpmr工具，tar -xvf perf61.tar解压，然后运行#./perfpmr.sh 60；将生成的日志信息发回去；等了两天都没人回信息，第三天上午都没有回信息，下午后我就打电话去问，结果说收集的信息不够全要收集两台的，而且必需要在运行备份时收集，我说这信息不全，就早和我说嘛，搞得这么久，人家项目还急着验收呢；又过两二天，我打电话过去问了，这次有答案了，说是只有两个报错，链路和磁盘报错(link errer、disk)：

# errpt                                                    

Tue Nov 26 16:41:49 2013 I  hdisk7      SC_DISK_PCM_ERR9  

Tue Nov 26 16:41:49 2013 P  hdisk7      SC_DISK_ERR7      

Tue Nov 26 16:41:48 2013 T  hdisk5      SC_DISK_ERR4      

Tue Nov 26 16:41:46 2013 T  fscsi2      FCP_ERR4          

Tue Nov 26 16:41:46 2013 T  fscsi2      FCP_ERR4          

Tue Nov 26 16:41:46 2013 T  hdisk5      SC_DISK_ERR4      

Tue Nov 26 16:41:44 2013 T  fscsi2      FCP_ERR4          

Tue Nov 26 16:41:44 2013 T  hdisk5      SC_DISK_ERR4      

Tue Nov 26 16:41:42 2013 T  fscsi2      FCP_ERR4          

Tue Nov 26 16:41:42 2013 T  hdisk5      SC_DISK_ERR4

Tue Nov 26 16:41:40 2013 T  fscsi2      FCP_ERR4    

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

并且还说这不是系统和软件的问题，是硬件的问题；

   于是叫我去IBM报个硬件的单子，于是继续打客服，这个硬件的还不想安排人过来处理，发了个邮件过来邮件是这样说的：

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

查看了2台 AIX 主机的数据，每台主机的操作系统中都各有一块光纤卡报出链路相关错误，

P740A , fscsi2 , WWPN 10000000C9A25E44

P740B , fscsi2 , WWPN 10000000C9A25E4C

查看了 SAN  交换机的数据，在 "172.16.104.103" 这台交换机中，多个端口有大量的报错计数，

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

Index Port Address Media Speed State     Proto

==============================================

 0   0   010000   id    N8   Online      FC  F-Port  10:00:00:00:c9:a2:5e:44 ---> P740A fcs2

 1   1   010100   id    N8   Online      FC  F-Port  10:00:00:00:c9:a2:5e:4c ---> P740B fcs2

 2   2   010200   id    N8   Online      FC  E-Port  10:00:00:05:33:cb:0a:d9 "BladeCenter_Bay3_FC_SW" (downstream)

 3   3   010300   id    N8   Online      FC  F-Port  10:00:00:00:c9:dd:65:b6

 4   4   010400   id    N8   No_Light    FC  

 5   5   010500   id    N8   No_Light    FC  

 6   6   010600   id    N8   Online      FC  F-Port  50:05:07:68:02:15:a9:69 ---> V7000A_Node1_Port1

 7   7   010700   id    N8   Online      FC  F-Port  50:05:07:68:02:45:a9:58 ---> V7000B

porterrshow        :

         frames      enc    crc    crc    too    too    bad    enc   disc   link   loss   loss   frjt   fbsy

      tx     rx      in    err    g_eof  shrt   long   eof     out   c3    fail    sync   sig

    =========================================================================================================

 0:    1.1g 889.5m   1.9k   1.8k   1.8k   0      0     13     34.2k 420      0      1      2      0      0  

 1:  514.3m 132.3m  43.7k  26.4k  26.0k   0      0    325      1.2k 122      0      1      2      0      0  

 2:    1.0m   1.0m   0      0      0      0      0      0    100      0      0      1      2      0      0  

 3:   11.9m  22.2m   6      6      6      0      0      0    305      0      0      4      5      0      0  

 4:    0      0      0      0      0      0      0      0      0      0      0      0      2      0      0  

 5:    0      0      0      0      0      0      0      0      0      0      0      0      2      0      0  

 6:    2.5g   3.2g 755.2k 492.1k 435.1k  93      0     56.9k   4.4m 886     18      5      6      0      0  

 7:    1.5g   1.5g 226    191    182      0      0      9    794.8k 557      8      6      5      0      0  

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

从上表中可以看到，交换机中 port0, port1, port6, port7 都有大量的报错计数。

同时从数据中看到，V7000A 中的2个控制器，每个控制器仅使用了一个 fc port 连接交换机，这样的配置是不符合 V7000 的官方配置要求的。

每个控制器至少要使用2个fc port，且分别连到不同的2台交换机上，以此实现主机光纤卡到 V7000 2个控制器的多链路冗余。

建议首先增加 V7000 到交换机的连接数量，每个 V7000 的控制器至少使用2个 fc port 分别连接到2台交换机上，其次尝试更换有大量报错端口的光纤线，如果继续有链路报错，最后尝试更换交换机上的端口模块，并且咨询服务器方面支持，看是否需要更改主机光纤卡配置 或者 更换主机光纤卡。

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

结果因为我是负责软件，硬件的事情得硬件负责人去处理，后来就安排了个工程师过来看，看是看了，可还是处理不了，把整个存储的链路都换的换改的改，还是在不断的报错，就这样又搞了一个星期，这时间过得可真快；但是我还在不断的崔那个工程师，结果那工程师就说要换光纤卡了，这还不能立即换了，说小型机的配置信息和公司记录不一样，这又有得扯了，项目比较多公司插手，单买两台小型机就又一个公司；

   然后接下来的这个月就是崔这个买小型机的公司去更新配置信息了。一个月后更新完了，这时IBM之前的工程师拿着光纤卡过来了，准备想要装上去的，不过他也叫另一个做硬件公司去加重光纤线，他来到后就先检查了报错情况，也检查了加光纤线的事，还说不应该还报错的，就去检查了光纤交换机的配置，嘿，这下发现问题了，光纤交换机没配置好，线是加重了但没做好配置，结果他进去配置完了，再看了下小型机的报错，结果不报错了，光纤卡还没装上去呢，嘿！不报错了；我也去试做了下RMAN备份，上到90M/S，正常了！这问题最后是出现在没有加重光纤线！！

   最后，我体会最深的就是这种问题处理的方式，太多的时间是花在扯皮上面，而且需要多方的配合的时候更难处理，特别是IBM这种大牛！都没有人懂这种东西的，服务还这么差。哎，不过还是要提升自己的实力比较好，处理问题不用这么麻烦。。。

本文出自 “红月亮” 博客，请务必保留此出处http://hongyueliang.blog.51cto.com/8237377/1377611

赛门铁克NBU备份oracle慢的问题,古老的榕树,5-wow.com