OracleRAC高可用测试报告Word文档格式.docx
《OracleRAC高可用测试报告Word文档格式.docx》由会员分享,可在线阅读,更多相关《OracleRAC高可用测试报告Word文档格式.docx(29页珍藏版)》请在冰点文库上搜索。
RAC数据库以裸设备方式建在共享磁阵上,各节点通过光纤交换机访问磁阵;
呼叫测试时,各节点上的智能网应用,则通过光纤交换机与模拟呼叫仪进行通讯。
硬件信息:
小型机:
IBMB802台,每台2颗450M主频的POWER3CPU和1G内存
IBMP6302台,每台2颗主频的POWER4CPU;
2G内存
存储:
StorageTek的D240磁阵,6块72G的硬盘,其中4块做RAID0+1,2块为HOTSPARE
光纤交换机:
2台,型号为IBM3534-F08
模拟呼叫仪:
INET、MGTS
软件信息:
操作系统:
IBMAIX补丁级别02
双机软件:
IBMHACMP补丁级别04
RAC版本:
Oracle.0
智能网平台版本:
V_0_2004/08/23业务版本
4测试过程描述
本次RAC的测试,主要是分成三个阶段,第一是RAC的性能测试,第二个阶段,则主要是针对在性能测试中发现问题的处理,第三个阶段是RAC的功能测试、稳定性测试。
4.1性能测试
由于受到模拟呼叫仪处理能力的限制,在性能测试过程中,4节点的RAC中并没有所有节点都同时使用的情况,大部分情况是启动其中的2个instance,相当于两节点的RAC。
测试前提:
1.智能网应用与Oracle的instance同时在同一台主机上运行
2.智能网的数据库连接为指定连到本机的instance,没有做loadbalance和failover
3.测试时业务表s1cardinf的记录数为32万
4.双节点时测试时,每个节点上的应用分别处理不同的号段,无交叉现象
4.1.1两台B80组成的单、双节点RAC性能测试
测试目的:
测试在B80上,两节点的RAC相对于单机方式的性能提高情况
测试步骤:
1.启动一台机器上的oracleinstance和智能网应用
2.根据应用的处理情况逐步提供呼叫仪的呼叫数,直到应用无法及时处理
3.同时启动两台机器上的oracleinstance和智能网应用
4.根据应用的处理情况逐步提供呼叫仪的呼叫数,直到应用无法及时处理
测试结果:
单实例方式下,应用的最大呼叫处理能力可达到140caps,此时CPU达到100%,
而应用出现消息积压的情况;
双节点方式下,每个节点应用的最大处理能力为140caps。
4.1.2两台P630组成的单、双节点RAC性能测试
测试在P630上,两节点的RAC相对于单机方式的性能提高情况
1.动一台机器上的oracleinstance和智能网应用
单实例方式下,应用的最大呼叫处理能力可达到210caps,此时CPU达到100%,
双节点方式下,每个节点应用的最大处理能力为210caps。
4.1.3两台B80和一台P630组成的三节点RAC性能测试
测试三节点的RAC的性能情况
1.同时启动两台B90和一台P630上的oracleinstance和智能网应用
最终的处理结果是两台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恢复
对于删除controlfile的测试,恢复失败,因为使用的是rmannocatalog进行的备份,在nocatalog方式下,备份信息是存放在controlfile中的,现在controlfile损坏,无法通过rman进行恢复;
oracle建议在使用nocatalog方式备份时需将controlfile和spfile单独使用操作系统命令进行备份。
后者的表空间恢复正常。
4.2.2exp备份和imp恢复测试
验证exp/imp进行数据库的备份和恢复
1.使用exp进行整库备份
2.删除用户zxin,使用imp恢复
3.删除表空间zxin_data,使用imp恢复
exp备份正常,恢复测试同样没有问题。
4.2.3正常呼叫时,smap界面对数据的大批量查询和修改。
节点zxin1和zxin2上正常处理呼叫,呼叫量均为100caps
1.查询某卡号段的信息
2.另外同时通过sqlplus,按照卡号段查询s1cardinf信息
由于只使用了一个smap界面程序操作,因此看不出影响。
4.2.4正常呼叫时,后台cron任务对数据的大批量查询和修改。
1.利用shell通过sqlplus,按照卡号段循环查询s1cardinf信息
2.通过sqlplus修改s1cardinf信息,按照卡号段循环updates1cardinf信息
后台对同一个表的连续的大数据查询、修改,对呼叫影响很大,查询时cpu占有率上升了5%,如有多个同时运行的话,消息处理积压的现象将会非常明显。
4.2.5大事务测试
测试在异常情况下数据的一致性、完整性
在节点zxin1和zxin2上同时运行同一事务批量修改数据,数据有交叉
多次测试,数据更新正常。
1.在节点zxin1和zxin2上同时运行同一事务,在zxin2回滚事务
2.在节点zxin1和zxin2上同时运行同一事务,在zxin2kill该session
测试结果正常,未见数据异常。
在节点zxin1和zxin2上同时运行模拟程序,通过sqlplus连到数据库,批量更新数据,然后退出重连;
此过程循环一晚
根据处理的日志看,操作正常。
4.2.6loadbalance测试
验证oracle的负载均衡功能
1.在zxin1、zxin2上启动实例
2.修改zxin2上,启用loadbalance
1.在zxin2上运行zxstart,建立SDF连接
2.利用测试程序,每隔几秒通过sqlplus建立10个连接
zxstart多次测试的结果,12个SDF连接基本是平均分布,有时则是5个在zxin1上,7个在zxin2上;
而手工建立的sqlplus连接,则是完全平均分布的。
4.2.7connetc-timefailover的测试
验证在客户端连接时的failover功能
1.启动zxin1、zxin2上的实例
2.关闭zxin2的listener,zxin1机器上的listener正常
3.实例zxin2上的中配置AddressList=
(ADDRESS=(PROTOCOL=TCP)(HOST=zxin2)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=zxin1)(PORT=1521))
1.在zxin2上启动zxstart
2.利用测试程序,在zxin2上每隔几秒通过sqlplus建立10个连接
两种方式下,数据库连接都在zxin1实例上
4.2.8TAF测试
验证TransparentApplicationFailover功能及切换时间
1.实例zxin1、zxin2正常运行,listener正常
2.实例zxin2启用Failover功能
3.主机zxin1、zxin2上的时间一致
1.Zxin2上运行zxstart,启动平台程序
2.启动模拟程序,不停通过sqlplus连接zxin2,记录无法连接zxin2实例的时间
3.通过正常、异常关闭zxin2实例,异常关闭zxin2主机进行测试
4.在zxin1上查看v$session中各SDF连接及logon_time
zxin2实例在正常、异常关闭或者zxin2主机被异常关闭之后,所有连到实例zxin2的数据库连接自动切换到了zxin1,但是数据库连接的切换时间每次都不太一样,从8秒到59秒不等,维持在1分钟之内。
测试正常呼叫情况下TAF的切换时间
1.zxin2上运行zxstart,启动平台程序,有100caps的呼叫处理
zxin2实例在正常、异常关闭或者zxin2主机被异常关闭之后,所有连到实例zxin2的数据库连接自动切换到了zxin1,而且切换时间非常快,很多情况下都在1-2秒左右,没有超过10秒的,可能跟呼叫有关,在有操作的情况下,zxin1实例能够更快的获取zxin2实例down的情况,从而更快的切换。
4.3稳定性测试
4.3.1模拟呼叫,保持24小时
测试RAC在长时间的呼叫处理下是否正常
1.在节点zxin1、zxin2上启动数据库
2.在节点zxin1、zxin2上分别启动平台程序,接受呼叫
3.模拟呼叫仪接入,模拟100caps的呼叫量,连续呼叫24小时
系统运行正常,数据库访问正常,业务处理正常。
4.3.2网线异常对实例的影响
测试公网ip异常对RAC的影响
1.实例zxin1、zxin2启动,在zxin2上启动平台程序
2.使用ifconfigen1delete删除publicip
3.拔掉zxin2上public网线
zxin2上建立的到数据库实例zxin2的SDF连接,进行failover,切换到zxin1上,客户端无法以zx192_1_1_102这个connectstring连到实例zxin2。
待到重新加入ip或者插上网线之后,恢复正常。
测试私网ip异常对RAC的影响
2.使用ifconfigen0delete删除privateip
3.拔掉zxin2上用于RAC节点间通讯的private网线
无论是删除ip还是拔掉网线,对于Oracle来说,效果一样。
以其中一次测试的过程为例:
大概在11:
03拔掉网线,然后在oracle日志显示,在实例zxin1、zxin2分别在11:
09和11:
08:
45进行Communicationrecofiguration,zxin1等待split-brainresolution;
10分钟之后,11:
19分,实例zxin2down下来,zxin1实例恢复正常。
在多次测试的结果中,发现在拔掉网线到实例进行communication重组之间、和实例等待split-brainresolution的过程中,除了有一次能够通过访问zxin1而不能访问zxin2外,其他几次都无法通过sqlplus访问zxin1、zxin2,而且这两个阶段的时间都固定为5分钟跟10分钟。
后来,发现第二个阶段等待split-brain的时间跟数据库中参数的设置有关,修改参数_imr_splitbrain_res_wait为60秒后,等待时间由10分钟缩短为1分钟;
但是,comminucation重组之前的超时判断无法缩短,可能跟tcp有关,修改了rto_high等几个参数设置后,时间依然为5分钟左右,没有改变。
下附oracle日志
:
FriNov1911:
09:
002004
Communicationsreconfiguration:
instance1
Waitingforclusterwaresplit-brainresolution
302004
Tracedumpingisperformingid=[900]
19:
022004
Evictinginstance2fromcluster
062004
Reconfigurationstarted
Listofnodes:
0,
Nested/batchedreconfigurationdetected.
GlobalResourceDirectoryfrozen
onenodepartition
Communicationchannelsreestablished
Masterbroadcastedresourcehashvaluebitmaps
Non-localProcessblockscleanedout
Resourcesandenqueuescleanedout
Resourcesremastered732
861GCSshadowstraversed,0cancelled,0closed
418GCSresourcestraversed,0cancelled
setmasternodeinfo
Submittedallremote-enqueuerequests
Updaterdomainvariables
Dwn-cvtsreplayed,VALBLKsdubious
Allgrantableenqueuesgranted
861GCSshadowstraversed,0replayed,0unopened
SubmittedallGCSremote-cacherequests
0writerequestsissuedin861GCSresources
0PIsmarkedsuspect,0flushPImsgs
072004
Reconfigurationcomplete
PostSMONtostart1stpassIR
Instancerecovery:
lookingfordeadthreads
Beginninginstancerecoveryof1threads
Startedredoscan
Completedredoscan
246redoblocksread,42datablocksneedrecovery
Startedrecoveryat
Thread2:
logseq1032,block3,scn
RecoveryofOnlineRedoLog:
Thread2Group4Seq1032Readingmem0
Mem#0errs0:
/dev/rredolog2_2
Completedredoapplication
Endedrecoveryat
logseq1032,block249,scn
13datablocksread,42datablockswritten,246redoblocksread
Endinginstancerecoveryof1threads
SMON:
abouttorecoverundosegment11
markundosegment11asavailable
abouttorecoverundosegment12
markundosegment12asavailable
abouttorecoverundosegment13
markundosegment13asavailable
abouttorecoverundosegment14
markundosegment14asavailable
abouttorecoverundosegment15
markundosegment15asavailable
abouttorecoverundosegment16
markundosegment16asavailable
abouttorecoverundosegment17
markundosegment17asavailable
abouttorecoverundosegment18
markundosegment18asavailable
abouttorecoverundosegment19
markundosegment19asavailable
abouttorecoverundosegment20
markundosegment20asavailable
08:
452004
instance0
152004
Tracedumpingisperformingid=[845]
Errorsinfile/oracle/admin/zxin/bdump/:
ORA-29740:
evictedbymember1,groupincarnation3
LMON:
terminatinginstanceduetoerror29740
InstanceterminatedbyLMON,pid=479324
4.4第二节点对第一实例的影响
4.4.1第二实例启动对第一实例的影响
zxin1上oracle实例和平台程序已经启动,无呼叫接入
正常启动zxin2上的实例(startup)
第二实例的启动,对于第一实例的影响仅在重组的时候,重组时间基本上在1秒之内;
智能网应用日志内,未发现sdf异常记录。
日志如所示:
FriNov1119:
24:
092004
0,1,
Resourcesremastered942
1394GCSshadowstraversed,0cancelled,58closed
1336GCSresourcestraversed,0cancelled
39342GCSresourcesonfreelist,39981onarray,39981allocated
setmasternodeinfo
Allgrantableenqueuesgra