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
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1