OracleRAC高可用测试报告.docx

OracleRAC高可用测试报告.docx

《OracleRAC高可用测试报告.docx》由会员分享，可在线阅读，更多相关《OracleRAC高可用测试报告.docx（29页珍藏版）》请在冰豆网上搜索。

OracleRAC高可用测试报告

Oracle-RAC-高可用测试报告

高可用技术文件

技术文件名称：

OracleRAC测试报告

技术文件编号：

版本：

（包括封面）

拟制邵金龙

审核

会签

标准化

批准

深圳市中兴通讯股份有限公司

1测试目的

测试目的，在于验证多节点RAC的可用性、稳定性,以及多节点RAC相对于普通的Oracle环境性能的提升情况

2术语、定义和缩略语

2.1术语、定义

无。

2.2缩略语

本文件应用了以下缩略语：

RACRealApplicationClusterOracle公司数据库集群软件

CapsCallperSecond智能网名词，指每秒处理的呼叫数

3测试环境描述

本次测试，由4台IBM小型机（2台B80、2台P630）搭建了一个内部网络，组成4节点的RAC环境，网络内的各个节点通过10/100M网卡相互访问，包括RAC节点间的heartbeat信息；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和智能网应用

2．根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理

3．同时启动两台机器上的oracleinstance和智能网应用

4．根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理

测试结果：

单实例方式下，应用的最大呼叫处理能力可达到210caps，此时CPU达到100％，

而应用出现消息积压的情况；双节点方式下，每个节点应用的最大处理能力为210caps。

4.1.3两台B80和一台P630组成的三节点RAC性能测试

测试目的：

测试三节点的RAC的性能情况

测试步骤：

1．同时启动两台B90和一台P630上的oracleinstance和智能网应用

2．根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理

测试结果：

最终的处理结果是两台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任务对数据的大批量查询和修改。

测试前提：

节点zxin1和zxin2上正常处理呼叫，呼叫量均为100caps

测试步骤：

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．实例zxin1、zxin2正常运行，listener正常

2．实例zxin2启用Failover功能

3．主机zxin1、zxin2上的时间一致

测试步骤：

1．zxin2上运行zxstart，启动平台程序，有100caps的呼叫处理

2．启动模拟程序，不停通过sqlplus连接zxin2，记录无法连接zxin2实例的时间

3．通过正常、异常关闭zxin2实例，异常关闭zxin2主机进行测试

4．在zxin1上查看v$session中各SDF连接及logon_time

测试结果：

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的影响

测试步骤：

1．实例zxin1、zxin2启动，在zxin2上启动平台程序

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

FriNov1911:

09:

302004

Tracedumpingisperformingid=[900]

FriNov1911:

19:

022004

Evictinginstance2fromcluster

FriNov1911:

19:

062004

Reconfigurationstarted

Listofnodes:

0,

FriNov1911:

19:

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

FriNov1911:

19:

072004

Reconfigurationcomplete

PostSMONtostart1stpassIR

FriNov1911:

19:

072004

Instancerecovery:

lookingfordeadthreads

FriNov1911:

19:

072004

Beginninginstancerecoveryof1threads

FriNov1911:

19:

072004

Startedredoscan

FriNov1911:

19:

072004

Completedredoscan

246redoblocksread,42datablocksneedrecovery

FriNov1911:

19:

072004

Startedrecoveryat

Thread2:

logseq1032,block3,scn

RecoveryofOnlineRedoLog:

Thread2Group4Seq1032Readingmem0

Mem#0errs0:

/dev/rredolog2_2

FriNov1911:

19:

072004

Completedredoapplication

FriNov1911:

19:

072004

Endedrecoveryat

Thread2:

logseq1032,block249,scn

13datablocksread,42datablockswritten,246redoblocksread

Endinginstancerecoveryof1threads

SMON:

abouttorecoverundosegment11

SMON:

markundosegment11asavailable

SMON:

abouttorecoverundosegment12

SMON:

markundosegment12asavailable

SMON:

abouttorecoverundosegment13

SMON:

markundosegment13asavailable

SMON:

abouttorecoverundosegment14

SMON:

markundosegment14asavailable

SMON:

abouttorecoverundosegment15

SMON:

markundosegment15asavailable

SMON:

abouttorecoverundosegment16

SMON:

markundosegment16asavailable

SMON:

abouttorecoverundosegment17

SMON:

markundosegment17asavailable

SMON:

abouttorecoverundosegment18

SMON:

markundosegment18asavailable

SMON:

abouttorecoverundosegment19

SMON:

markundosegment19asavailable

SMON:

abouttorecoverundosegment20

SMON:

markundosegment20asavailable

FriNov1911:

08:

452004

Communicationsreconfiguration:

instance0

FriNov1911:

09:

022004

Waitingforclusterwaresplit-brainresolution

FriNov1911:

09:

152004

Tracedumpingisperformingid=[845]

FriNov1911:

19:

022004

Errorsinfile/oracle/admin/zxin/bdump/:

ORA-29740:

evictedbymember1,groupincarnation3

FriNov1911:

19:

022004

LMON:

terminatinginstanceduetoerror29740

InstanceterminatedbyLMON,pid=479324

4.4第二节点对第一实例的影响

4.4.1第二实例启动对第一实例的影响

测试前提：

zxin1上oracle实例和平台程序已经启动，无呼叫接入

测试步骤：

正常启动zxin2上的实例（startup）

测试结果：

第二实例的启动，对于第一实例的影响仅在重组的时候，重组时间基本上在1秒之内；智能网应用日志内，未发现sdf异常记录。

日志如所示：

FriNov1119:

24:

092004

Reconfigurationstarted

Listofnodes:

0,1,

GlobalResourceDirectoryfrozen

Communicationchannelsreestablished

Masterbroadcastedresourcehashvaluebitmaps

Non-localProcessblockscleanedout

Resourcesandenqueuescleanedout

Resourcesremastered942

1394GCSshadowstraversed,0cancelled,58closed

1336GCSresourcestraversed,0cancelled

39342GCSresourcesonfreelist,39981onarray,39981allocated

setmasternodeinfo

Submittedallremote-enqueuerequests

Updaterdomainvariables

Dwn-cvtsreplayed,VALBLKsdubious

Allgrantableenqueuesgra