Oracle RAC 测试报告.docx

1、Oracle RAC 测试报告 技 术 文 件 技术文件名称：Oracle RAC测试报告 技术文件编号： 版 本：V1.0 共 1 页(包括封面) 拟 制 邵 金 龙 审 核 会 签 标准化 批 准 深圳市中兴通讯股份有限公司 1测试目的测试目的，在于验证多节点RAC的可用性、稳定性,以及多节点RAC相对于普通的Oracle环境性能的提升情况2术语、定义和缩略语2.1术语、定义无。2.2缩略语本文件应用了以下缩略语：RAC Real Application Cluster Oracle公司数据库集群软件Caps Call per Second 智能网名词，指每秒处理的呼叫数3测试环境描述本次

2、测试，由4台IBM小型机（2台B80、2台P630）搭建了一个内部网络，组成4节点的RAC环境，网络内的各个节点通过10/100M网卡相互访问，包括RAC节点间的heart beat信息；RAC数据库以裸设备方式建在共享磁阵上，各节点通过光纤交换机访问磁阵；呼叫测试时，各节点上的智能网应用，则通过光纤交换机与模拟呼叫仪进行通讯。硬件信息：小型机：IBM B80 2台，每台2颗450M主频的POWER3 CPU 和1G内存小型机：IBM P630 2台，每台 2颗1.2G主频的POWER4 CPU；2G内存存储：StorageTek的D240磁阵，6块72G的硬盘，其中4块做RAID 0+1，2

3、块为HOT SPARE光纤交换机：2台，型号为IBM 3534-F08模拟呼叫仪：INET、MGTS软件信息：操作系统：IBM AIX 5.2 补丁级别 02双机软件：IBM HACMP V5.1 补丁级别04RAC版本：Oracle 9.2.0.5.0智能网平台版本：V3.50.05.06_0_2004/08/23 业务版本：IIN-GSM_PPSV2.01.01V3.504测试过程描述本次RAC的测试，主要是分成三个阶段，第一是RAC的性能测试，第二个阶段，则主要是针对在性能测试中发现问题的处理，第三个阶段是RAC的功能测试、稳定性测试。4.1性能测试由于受到模拟呼叫仪处理能力的限制，在性

4、能测试过程中，4节点的RAC中并没有所有节点都同时使用的情况，大部分情况是启动其中的2个instance，相当于两节点的RAC。测试前提：1智能网应用与Oracle的instance同时在同一台主机上运行2智能网的数据库连接为指定连到本机的instance，没有做load balance和failover3测试时业务表s1cardinf的记录数为32万4双节点时测试时，每个节点上的应用分别处理不同的号段，无交叉现象4.1.1两台B80组成的单、双节点RAC性能测试测试目的：测试在B80上，两节点的RAC相对于单机方式的性能提高情况测试步骤：1启动一台机器上的oracle instance和智能

5、网应用2根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理3同时启动两台机器上的oracle instance和智能网应用4根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理测试结果： 单实例方式下，应用的最大呼叫处理能力可达到140caps，此时CPU达到100，而应用出现消息积压的情况；双节点方式下，每个节点应用的最大处理能力为140caps。4.1.2两台P630组成的单、双节点RAC性能测试测试目的：测试在P630上，两节点的RAC相对于单机方式的性能提高情况测试步骤：1动一台机器上的oracle instance和智能网应用2根据应用的处理情况逐步提供呼叫仪的

6、呼叫数，直到应用无法及时处理3同时启动两台机器上的oracle instance和智能网应用4根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理测试结果： 单实例方式下，应用的最大呼叫处理能力可达到210caps，此时CPU达到100，而应用出现消息积压的情况；双节点方式下，每个节点应用的最大处理能力为210caps。4.1.3两台B80和一台P630组成的三节点RAC性能测试测试目的：测试三节点的RAC的性能情况测试步骤：1同时启动两台B90和一台P630上的oracle instance和智能网应用2根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理测试结果： 最终

7、的处理结果是两台B80上的最大呼叫能力为140caps，当时CPU为100，出现消息积压情况；而受制于呼叫仪的处理能力，P630上达到160caps，而cpu占有率为81，消息处理正常。4.2功能测试4.2.1RMAN备份和恢复测试测试目的： 测试RMAN的备份测试步骤：1使用rman，执行语句，进行整个数据库的备份2使用rman，执行语句，备份归档日志测试结果： 按照预期的结果，生成了备份文件。测试目的： 测试RMAN的恢复测试步骤：1使用dd破坏控制文件的设备/dev/rrcontrol1，使用RMAN恢复2删除表空间zxin_data，利用之前的备份，使用RMAN恢复测试结果： 对于删除

8、control file的测试，恢复失败，因为使用的是rman nocatalog 进行的备份，在nocatalog方式下，备份信息是存放在control file中的，现在control file损坏，无法通过rman进行恢复；oracle建议在使用nocatalog方式备份时需将control file和spfile单独使用操作系统命令进行备份。后者的表空间恢复正常。4.2.2exp备份和imp恢复测试测试目的： 验证exp/imp 进行数据库的备份和恢复测试步骤：1使用exp进行整库备份2删除用户zxin，使用imp恢复3删除表空间zxin_data，使用imp恢复测试结果： exp备份

9、正常，恢复测试同样没有问题。4.2.3正常呼叫时，smap界面对数据的大批量查询和修改。测试前提：节点zxin1和zxin2上正常处理呼叫，呼叫量均为100caps测试步骤：1查询某卡号段的信息2另外同时通过sqlplus，按照卡号段查询s1cardinf信息测试结果： 由于只使用了一个smap界面程序操作，因此看不出影响。4.2.4正常呼叫时，后台cron任务对数据的大批量查询和修改。测试前提：节点zxin1和zxin2上正常处理呼叫，呼叫量均为100caps测试步骤：1利用shell通过sqlplus，按照卡号段循环查询s1cardinf信息2通过sqlplus修改s1cardinf信息，

10、按照卡号段循环update s1cardinf信息测试结果： 后台对同一个表的连续的大数据查询、修改，对呼叫影响很大，查询时cpu占有率上升了5，如有多个同时运行的话，消息处理积压的现象将会非常明显。4.2.5大事务测试测试目的： 测试在异常情况下数据的一致性、完整性测试步骤： 在节点zxin1和zxin2上同时运行同一事务批量修改数据，数据有交叉测试结果： 多次测试，数据更新正常。 测试步骤：1在节点zxin1和zxin2上同时运行同一事务，在zxin2回滚事务2在节点zxin1和zxin2上同时运行同一事务，在zxin2 kill该session测试结果： 测试结果正常，未见数据异常。测试

11、步骤： 在节点zxin1和zxin2上同时运行模拟程序，通过sqlplus连到数据库，批量更新数据，然后退出重连；此过程循环一晚测试结果： 根据处理的日志看，操作正常。4.2.6load balance测试测试目的： 验证oracle的负载均衡功能测试前提：1在zxin1、zxin2上启动实例2修改zxin2上tnsnames.ora，启用load balance测试步骤：1在zxin2上运行zxstart，建立SDF连接2利用测试程序，每隔几秒通过sqlplus建立10个连接测试结果： zxstart多次测试的结果，12个SDF连接基本是平均分布，有时则是5个在zxin1上，7个在zxin2

12、上；而手工建立的sqlplus连接，则是完全平均分布的。4.2.7connetc-time failover的测试测试目的： 验证在客户端连接时的failover功能测试前提：1启动zxin1、zxin2上的实例2关闭zxin2的listener，zxin1机器上的listener正常3实例zxin2上的tnsnames.ora中配置Address List=(ADDRESS = (PROTOCOL = TCP)(HOST = zxin2)(PORT = 1521) (ADDRESS = (PROTOCOL = TCP)(HOST = zxin1)(PORT = 1521)测试步骤：1在zxi

13、n2上启动zxstart2利用测试程序，在zxin2上每隔几秒通过sqlplus建立10个连接测试结果：两种方式下，数据库连接都在zxin1实例上4.2.8TAF测试测试目的： 验证Transparent Application Failover功能及切换时间测试前提：1实例zxin1、zxin2正常运行，listener正常2实例zxin2启用Failover功能3主机zxin1、zxin2上的时间一致测试步骤：1Zxin2上运行zxstart，启动平台程序2启动模拟程序，不停通过sqlplus连接zxin2，记录无法连接zxin2实例的时间3通过正常、异常关闭zxin2实例，异常关闭zxi

14、n2主机进行测试4在zxin1上查看v$session中各SDF连接及logon_time测试结果： zxin2实例在正常、异常关闭或者zxin2主机被异常关闭之后，所有连到实例zxin2的数据库连接自动切换到了zxin1，但是数据库连接的切换时间每次都不太一样，从8秒到59秒不等，维持在1分钟之内。测试目的： 测试正常呼叫情况下TAF的切换时间测试前提：1实例zxin1、zxin2正常运行，listener正常2实例zxin2启用Failover功能3主机zxin1、zxin2上的时间一致测试步骤：1zxin2上运行zxstart，启动平台程序，有100caps的呼叫处理2启动模拟程序，不停

15、通过sqlplus连接zxin2，记录无法连接zxin2实例的时间3通过正常、异常关闭zxin2实例，异常关闭zxin2主机进行测试4在zxin1上查看v$session中各SDF连接及logon_time测试结果： zxin2实例在正常、异常关闭或者zxin2主机被异常关闭之后，所有连到实例zxin2的数据库连接自动切换到了zxin1，而且切换时间非常快，很多情况下都在12秒左右，没有超过10秒的，可能跟呼叫有关，在有操作的情况下，zxin1实例能够更快的获取zxin2实例down的情况，从而更快的切换。4.3稳定性测试4.3.1模拟呼叫，保持24小时测试目的： 测试RAC在长时间的呼叫处理

16、下是否正常测试步骤：1在节点zxin1、zxin2上启动数据库2在节点zxin1、zxin2上分别启动平台程序，接受呼叫3模拟呼叫仪接入，模拟100caps的呼叫量，连续呼叫24小时测试结果： 系统运行正常，数据库访问正常，业务处理正常。4.3.2网线异常对实例的影响测试目的： 测试公网ip异常对RAC的影响测试步骤：1实例zxin1、zxin2启动，在zxin2上启动平台程序2使用ifconfig en1 192.1.1.102 delete 删除public ip3拔掉zxin2上public网线测试结果： zxin2上建立的到数据库实例zxin2的SDF连接，进行failover，切换到

17、zxin1上，客户端无法以zx192_1_1_102这个connect string连到实例zxin2。待到重新加入ip 或者插上网线之后，恢复正常。测试步骤： 测试私网ip异常对RAC的影响测试步骤：1实例zxin1、zxin2启动，在zxin2上启动平台程序2使用ifconfig en0 10.1.1.102 delete 删除private ip3拔掉zxin2上用于RAC节点间通讯的private网线测试结果： 无论是删除ip还是拔掉网线，对于Oracle来说，效果一样。以其中一次测试的过程为例：大概在11：03拔掉网线，然后在oracle日志显示，在实例zxin1、zxin2分别在1

18、1：09 和11：08：45进行Communication recofiguration，zxin1等待split-brain resolution；10分钟之后，11：19分，实例zxin2 down下来，zxin1实例恢复正常。在多次测试的结果中，发现在拔掉网线到实例进行communication重组之间、和实例等待split-brain resolution的过程中，除了有一次能够通过访问zxin1而不能访问zxin2外，其他几次都无法通过sqlplus访问zxin1、zxin2，而且这两个阶段的时间都固定为5分钟跟10分钟。 后来，发现第二个阶段等待split-brain的时间跟数据库

19、中参数的设置有关，修改参数_imr_splitbrain_res_wait为60秒后，等待时间由10分钟缩短为1分钟；但是，comminucation重组之前的超时判断无法缩短，可能跟tcp有关，修改了rto_high等几个参数设置后，时间依然为5分钟左右，没有改变。下附oracle日志alert_zxin1.log：Fri Nov 19 11:09:00 2004Communications reconfiguration: instance 1Waiting for clusterware split-brain resolutionFri Nov 19 11:09:30 2004Trac

20、e dumping is performing id=41119110900Fri Nov 19 11:19:02 2004Evicting instance 2 from clusterFri Nov 19 11:19:06 2004Reconfiguration startedList of nodes: 0,Fri Nov 19 11:19:06 2004Reconfiguration startedList of nodes: 0, Nested/batched reconfiguration detected. Global Resource Directory frozenone

21、node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remastered 732 861 GCS shadows traversed, 0 cancelled, 0 closed 418 GCS resources traversed, 0 cancelled set master nod

22、e info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 861 GCS shadows traversed, 0 replayed, 0 unopened Submitted all GCS remote-cache requests 0 write requests issued in 861 GCS resources 0 PIs marked suspect, 0 flush

23、 PI msgsFri Nov 19 11:19:07 2004Reconfiguration complete Post SMON to start 1st pass IRFri Nov 19 11:19:07 2004Instance recovery: looking for dead threadsFri Nov 19 11:19:07 2004Beginning instance recovery of 1 threadsFri Nov 19 11:19:07 2004Started redo scanFri Nov 19 11:19:07 2004Completed redo sc

24、an 246 redo blocks read, 42 data blocks need recoveryFri Nov 19 11:19:07 2004Started recovery at Thread 2: logseq 1032, block 3, scn 0.0Recovery of Online Redo Log: Thread 2 Group 4 Seq 1032 Reading mem 0 Mem# 0 errs 0: /dev/rredolog2_2Fri Nov 19 11:19:07 2004Completed redo applicationFri Nov 19 11:

25、19:07 2004Ended recovery at Thread 2: logseq 1032, block 249, scn 0.533566592 13 data blocks read, 42 data blocks written, 246 redo blocks readEnding instance recovery of 1 threadsSMON: about to recover undo segment 11SMON: mark undo segment 11 as availableSMON: about to recover undo segment 12SMON:

26、 mark undo segment 12 as availableSMON: about to recover undo segment 13SMON: mark undo segment 13 as availableSMON: about to recover undo segment 14SMON: mark undo segment 14 as availableSMON: about to recover undo segment 15SMON: mark undo segment 15 as availableSMON: about to recover undo segment

27、 16SMON: mark undo segment 16 as availableSMON: about to recover undo segment 17SMON: mark undo segment 17 as availableSMON: about to recover undo segment 18SMON: mark undo segment 18 as availableSMON: about to recover undo segment 19SMON: mark undo segment 19 as availableSMON: about to recover undo

28、 segment 20SMON: mark undo segment 20 as available alert_zxin2.logFri Nov 19 11:08:45 2004Communications reconfiguration: instance 0Fri Nov 19 11:09:02 2004Waiting for clusterware split-brain resolutionFri Nov 19 11:09:15 2004Trace dumping is performing id=41119110845Fri Nov 19 11:19:02 2004Errors i

29、n file /oracle/admin/zxin/bdump/zxin2_lmon_479324.trc:ORA-29740: evicted by member 1, group incarnation 3Fri Nov 19 11:19:02 2004LMON: terminating instance due to error 29740Instance terminated by LMON, pid = 4793244.4第二节点对第一实例的影响4.4.1第二实例启动对第一实例的影响测试前提：zxin1上oracle 实例和平台程序已经启动，无呼叫接入测试步骤：正常启动zxin2上的

30、实例（startup）测试结果：第二实例的启动，对于第一实例的影响仅在重组的时候，重组时间基本上在1秒之内；智能网应用日志zxcom.log内，未发现sdf异常记录。日志如alert_zxin1.log所示：Fri Nov 11 19:24:09 2004Reconfiguration startedList of nodes: 0,1, Global Resource Directory frozen Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remaste