Oracle-RAC-高可用测试报告

1、高可用技 术 文 件 技术文件名称：Oracle RAC 测试报告 技术文件编号： 版 本：V1.0 共 20 页 (包括封面) 拟 制 邵 金 龙 审 核 会 签 标准化 批 准 深圳市中兴通讯股份有限公司 目目 录录 1测试目的.2 2术语、定义和缩略语.2 2.1术语、定义.2 2.2缩略语.2 3测试环境描述.2 4测试过程描述.3 4.1性能测试.3 4.1.1两台 B80 组成的单、双节点 RAC 性能测试 .3 4.1.2两台 P630 组成的单、双节点 RAC 性能测试.3 4.1.3两台 B80 和一台 P630 组成的三节点 RAC 性能测试.3 4.2功能测试.4 4.2

2、.1RMAN 备份和恢复测试.4 4.2.2exp 备份和 imp 恢复测试.4 4.2.3正常呼叫时，smap 界面对数据的大批量查询和修改。.4 4.2.4正常呼叫时，后台 cron 任务对数据的大批量查询和修改。.5 4.2.5大事务测试 .5 4.2.6load balance 测试 .5 4.2.7connetc-time failover 的测试.6 4.2.8TAF 测试.6 4.3稳定性测试.7 4.3.1模拟呼叫，保持 24 小时 .7 4.3.2网线异常对实例的影响 .7 4.4第二节点对第一实例的影响.10 4.4.1第二实例启动对第一实例的影响 .10 4.4.2第二实

3、例正常关闭对第一实例的影响 .11 4.4.3第二实例异常关闭对第一实例的影响 .11 4.4.4第二实例所在机器异常关闭对第一实例的影响 .15 5测试总结.17 5.1测试中发现问题的说明.17 6获得的技术支持.18 第一篇 概 述.3 1范围.3 2设计依据.3 3术语定义.3 第二篇 方案比较.4 4备选方案说明.4 5方案选择.4 第三篇 系统总体设计.5 6系统体系结构.5 7体系结构概述.5 8子系统和模块的命名规则.5 9标准化设计.5 9.1模块标准化设计.5 9.2接口标准化设计.5 10系统版本规划.5 11系统处理流程.5 12子系统说明.6 12.111.1 子系统

4、 1（名称）.6 12.211.2 子系统 2（名称）.6 13模块说明.6 13.1模块 1（名称）.6 13.1.1输入 .6 13.1.2输出 .6 13.2模块 2（名称）.6 14开发和运行环境.6 14.1硬件环境.6 14.2软件环境.6 15可靠性设计.6 16可测试性设计.6 17安全性设计.7 第四篇 关键技术问题说明.8 18关键技术问题说明.8 第五篇 系统运行说明.9 19配置说明.9 20系统应用方式.9 1测试目的测试目的 测试目的，在于验证多节点 RAC 的可用性、稳定性,以及多节点 RAC 相对于普通的 Oracle 环境性能的提升情况 2术语、定义和缩略语术

5、语、定义和缩略语 2.1术语、定义术语、定义 无。 2.2缩略语缩略语 本文件应用了以下缩略语： RACReal Application ClusterOracle 公司数据库集群软件 CapsCall per Second 智能网名词，指每秒处理的呼叫数 3测试环境描述测试环境描述 本次测试，由 4 台 IBM 小型机（2 台 B80、2 台 P630）搭建了一个内部网络，组成 4 节 点的 RAC 环境，网络内的各个节点通过 10/100M 网卡相互访问，包括 RAC 节点间的 heart beat 信息；RAC 数据库以裸设备方式建在共享磁阵上，各节点通过光纤交换机访问磁阵； 呼叫测试时

6、，各节点上的智能网应用，则通过光纤交换机与模拟呼叫仪进行通讯。 硬件信息： 小型机：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 块为 HOT SPARE 光纤交换机：2 台，型号为 IBM 3534-F08 模拟呼叫仪：INET、MGTS 软件信息： 操作系统：IBM AIX 5.2 补丁级别 02 双机软件：IBM HACMP V5.1

7、 补丁级别 04 RAC 版本：Oracle 9.2.0.5.0 智能网平台版本：V3.50.05.06_0_2004/08/23 业务版本：IIN- GSM_PPSV2.01.01V3.50 4测试过程描述测试过程描述 本次 RAC 的测试，主要是分成三个阶段，第一是 RAC 的性能测试，第二个阶段，则 主要是针对在性能测试中发现问题的处理，第三个阶段是 RAC 的功能测试、稳定性测试。 4.1性能测试性能测试 由于受到模拟呼叫仪处理能力的限制，在性能测试过程中，4 节点的 RAC 中并没有所 有节点都同时使用的情况，大部分情况是启动其中的 2 个 instance，相当于两节点的 RAC。

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

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

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

11、两台 B90 和一台 P630 上的 oracle instance 和智能网应用 2 根据应用的处理情况逐步提供呼叫仪的呼叫数，直到应用无法及时处理 测试结果： 最终的处理结果是两台 B80 上的最大呼叫能力为 140caps，当时 CPU 为 100， 出 现消息积压情况；而受制于呼叫仪的处理能力，P630 上达到 160caps，而 cpu 占有率 为 81，消息处理正常。 4.2功能测试功能测试 4.2.1RMAN 备份和恢复测试备份和恢复测试 测试目的： 测试 RMAN 的备份 测试步骤： 1 使用 rman，执行语句，进行整个数据库的备份 2 使用 rman，执行语句，备份归档日志

12、 测试结果： 按照预期的结果，生成了备份文件。 测试目的： 测试 RMAN 的恢复 测试步骤： 1 使用 dd 破坏控制文件的设备/dev/rrcontrol1，使用 RMAN 恢复 2 删除表空间 zxin_data，利用之前的备份，使用 RMAN 恢复 测试结果： 对于删除 control file 的测试，恢复失败，因为使用的是 rman nocatalog 进行的备 份，在 nocatalog 方式下，备份信息是存放在 control file 中的，现在 control file 损坏，无法 通过 rman 进行恢复；oracle 建议在使用 nocatalog 方式备份时需将 co

13、ntrol file 和 spfile 单独 使用操作系统命令进行备份。后者的表空间恢复正常。 4.2.2exp 备份和备份和 imp 恢复测试恢复测试 测试目的： 验证 exp/imp 进行数据库的备份和恢复 测试步骤： 1 使用 exp 进行整库备份 2 删除用户 zxin，使用 imp 恢复 3 删除表空间 zxin_data，使用 imp 恢复 测试结果： exp 备份正常，恢复测试同样没有问题。 4.2.3正常呼叫时，正常呼叫时，smap 界面对数据的大批量查询和修改。界面对数据的大批量查询和修改。 测试前提： 节点 zxin1 和 zxin2 上正常处理呼叫，呼叫量均为 100ca

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

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

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

17、试结果： zxstart 多次测试的结果，12 个 SDF 连接基本是平均分布，有时则是 5 个在 zxin1 上，7 个在 zxin2 上；而手工建立的 sqlplus 连接，则是完全平均分布的。 4.2.7connetc-time failover 的测试的测试 测试目的： 验证在客户端连接时的 failover 功能 测试前提： 1 启动 zxin1、zxin2 上的实例 2 关闭 zxin2 的 listener，zxin1 机器上的 listener 正常 3 实例 zxin2 上的 tnsnames.ora 中配置 Address List= (ADDRESS = (PROTOCO

18、L = TCP)(HOST = zxin2)(PORT = 1521) (ADDRESS = (PROTOCOL = TCP)(HOST = zxin1)(PORT = 1521) 测试步骤： 1 在 zxin2 上启动 zxstart 2 利用测试程序，在 zxin2 上每隔几秒通过 sqlplus 建立 10 个连接 测试结果： 两种方式下，数据库连接都在 zxin1 实例上 4.2.8TAF 测试测试 测试目的： 验证 Transparent Application Failover 功能及切换时间 测试前提： 1 实例 zxin1、zxin2 正常运行，listener 正常 2 实例

19、 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，但是数据库连接的切换时间每

20、次都不太一样，从 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 上查看

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

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

23、 SDF 连接，进行 failover，切换到 zxin1 上， 客户端无法以 zx192_1_1_102 这个 connect string 连到实例 zxin2。待到重新加入 ip 或者插 上网线之后，恢复正常。 测试步骤： 测试私网 ip 异常对 RAC 的影响 测试步骤： 1 实例 zxin1、zxin2 启动，在 zxin2 上启动平台程序 2 使用 ifconfig en0 10.1.1.102 delete 删除 private ip 3 拔掉 zxin2 上用于 RAC 节点间通讯的 private 网线 测试结果： 无论是删除 ip 还是拔掉网线，对于 Oracle 来说，效

24、果一样。以其中一次测试的过 程为例：大概在 11：03 拔掉网线，然后在 oracle 日志显示，在实例 zxin1、zxin2 分别在 11：09 和 11：08：45 进行 Communication recofiguration，zxin1 等待 split-brain resolution；10 分钟之后，11：19 分，实例 zxin2 down 下来，zxin1 实例恢复正常。在多次 测试的结果中，发现在拔掉网线到实例进行 communication 重组之间、和实例等待 split- brain resolution 的过程中，除了有一次能够通过访问 zxin1 而不能访问 zx

25、in2 外，其他几次 都无法通过 sqlplus 访问 zxin1、zxin2，而且这两个阶段的时间都固定为 5 分钟跟 10 分钟。 后来，发现第二个阶段等待 split-brain 的时间跟数据库中参数的设置有关，修改 参数_imr_splitbrain_res_wait 为 60 秒后，等待时间由 10 分钟缩短为 1 分钟；但是， comminucation 重组之前的超时判断无法缩短，可能跟 tcp 有关，修改了 rto_high 等几个参 数设置后，时间依然为 5 分钟左右，没有改变。下附 oracle 日志 alert_zxin1.log： Fri Nov 19 11:09:00

26、 2004 Communications reconfiguration: instance 1 Waiting for clusterware split-brain resolution Fri Nov 19 11:09:30 2004 Trace dumping is performing id= Fri Nov 19 11:19:02 2004 Evicting instance 2 from cluster Fri Nov 19 11:19:06 2004 Reconfiguration started List of nodes: 0, Fri Nov 19 11:19:06 20

27、04 Reconfiguration started List of nodes: 0, Nested/batched reconfiguration detected. Global Resource Directory frozen one node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resour

28、ces remastered 732 861 GCS shadows traversed, 0 cancelled, 0 closed 418 GCS resources traversed, 0 cancelled set master node 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

29、unopened Submitted all GCS remote-cache requests 0 write requests issued in 861 GCS resources 0 PIs marked suspect, 0 flush PI msgs Fri Nov 19 11:19:07 2004 Reconfiguration complete Post SMON to start 1st pass IR Fri Nov 19 11:19:07 2004 Instance recovery: looking for dead threads Fri Nov 19 11:19:0

30、7 2004 Beginning instance recovery of 1 threads Fri Nov 19 11:19:07 2004 Started redo scan Fri Nov 19 11:19:07 2004 Completed redo scan 246 redo blocks read, 42 data blocks need recovery Fri Nov 19 11:19:07 2004 Started recovery at Thread 2: logseq 1032, block 3, scn 0.0 Recovery of Online Redo Log:

31、 Thread 2 Group 4 Seq 1032 Reading mem 0 Mem# 0 errs 0: /dev/rredolog2_2 Fri Nov 19 11:19:07 2004 Completed redo application Fri Nov 19 11:19:07 2004 Ended recovery at Thread 2: logseq 1032, block 249, scn 0. 13 data blocks read, 42 data blocks written, 246 redo blocks read Ending instance recovery

32、of 1 threads SMON: about to recover undo segment 11 SMON: mark undo segment 11 as available SMON: about to recover undo segment 12 SMON: mark undo segment 12 as available SMON: about to recover undo segment 13 SMON: mark undo segment 13 as available SMON: about to recover undo segment 14 SMON: mark

33、undo segment 14 as available SMON: about to recover undo segment 15 SMON: mark undo segment 15 as available SMON: about to recover undo segment 16 SMON: mark undo segment 16 as available SMON: about to recover undo segment 17 SMON: mark undo segment 17 as available SMON: about to recover undo segmen

34、t 18 SMON: mark undo segment 18 as available SMON: about to recover undo segment 19 SMON: mark undo segment 19 as available SMON: about to recover undo segment 20 SMON: mark undo segment 20 as available alert_zxin2.log Fri Nov 19 11:08:45 2004 Communications reconfiguration: instance 0 Fri Nov 19 11

35、:09:02 2004 Waiting for clusterware split-brain resolution Fri Nov 19 11:09:15 2004 Trace dumping is performing id= Fri Nov 19 11:19:02 2004 Errors in file /oracle/admin/zxin/bdump/zxin2_lmon_.trc: ORA-29740: evicted by member 1, group incarnation 3 Fri Nov 19 11:19:02 2004 LMON: terminating instanc

36、e due to error 29740 Instance terminated by LMON, pid = 4.4第二节点对第一实例的影响第二节点对第一实例的影响 4.4.1第二实例启动对第一实例的影响第二实例启动对第一实例的影响 测试前提： zxin1 上 oracle 实例和平台程序已经启动，无呼叫接入 测试步骤： 正常启动 zxin2 上的实例（startup） 测试结果： 第二实例的启动，对于第一实例的影响仅在重组的时候，重组时间基本上在 1 秒 之内；智能网应用日志 zxcom.log 内，未发现 sdf 异常记录。日志如 alert_zxin1.log 所 示： Fri Nov

37、 11 19:24:09 2004 Reconfiguration started List 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 remastered 942 1394 GCS shadows travers

38、ed, 0 cancelled, 58 closed 1336 GCS resources traversed, 0 cancelled 39342 GCS resources on freelist, 39981 on array, 39981 allocated set master node info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 1394 GCS shadows

39、 traversed, 697 replayed, 58 unopened Submitted all GCS remote-cache requests 0 write requests issued in 639 GCS resources 0 PIs marked suspect, 0 flush PI msgs Fri Nov 11 19:24:10 2004 Reconfiguration complete Post SMON to start 1st pass IR Fri Nov 11 19:24:10 2004 Instance recovery: looking for de

40、ad threads Instance recovery: lock domain invalid but no dead threads 测试前提： zxin1 上 oracle 实例和平台程序已经启动，正常呼叫，100caps 测试步骤： 启动 zxin2 上的 oracle 实例（startup） 测试结果： 在 zxin1 进行呼叫处理的情况下，zxin2 实例的启动，对于实例 zxin1 没有太大影 响，重组时间 1 秒内完成，从呼叫仪那边看，在重组的过程中，有从 10 到 80 不等的 呼叫断开，受到影响 4.4.2第二实例正常关闭对第一实例的影响第二实例正常关闭对第一实例的影响

41、测试前提： 1 zxin1 上 oracle 实例和平台程序已经启动，无呼叫接入 2 zxin2 上 oracle 实例和平台程序已经启动，无呼叫接入 测试步骤： 正常关闭 zxin2 上的实例（shutdown immediate） 测试结果： 第二实例的正常关闭，对于第一实例的影响仅在重组的时候，时间在 1 秒之内 测试前提： 1 zxin1 上 oracle 实例和平台程序已经启动，正常呼叫，100caps 2 zxin2 上 oracle 实例已启动 测试步骤： 正常关闭 zxin2 上的实例（shutdown immediate） 测试结果： 在 zxin1 进行呼叫处理的情况下，z

42、xin2 实例的正常关闭，对于实例 zxin1 没有太 大影响，重组时间 1 秒内完成，从呼叫仪那边看，有 80 以内的呼叫断开，受到影响 4.4.3第二实例异常关闭对第一实例的影响第二实例异常关闭对第一实例的影响 测试前提： 1 zxin1 上 oracle 实例和平台程序已经启动，无呼叫接入 2 zxin2 上 oracle 实例和平台程序已经启动，无呼叫接入 测试步骤： 异常关闭 zxin2 上的实例（shutdown abort） 测试结果： 第二实例的异常关闭后，第一实例进行资源重组和实例恢复，总时间在 1 秒左右 日志如 alert_zxin1.log 所示： Thu Nov 11

43、 19:42:26 2004 Reconfiguration started List of nodes: 0, Global Resource Directory frozen one node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remastered 917 1215 GCS s

44、hadows traversed, 0 cancelled, 53 closed 609 GCS resources traversed, 0 cancelled 39406 GCS resources on freelist, 39981 on array, 39981 allocated set master node info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 121

45、5 GCS shadows traversed, 0 replayed, 53 unopened Submitted all GCS remote-cache requests 0 write requests issued in 1162 GCS resources 0 PIs marked suspect, 0 flush PI msgs Thu Nov 11 19:42:26 2004 Reconfiguration complete Post SMON to start 1st pass IR Thu Nov 11 19:42:26 2004 Instance recovery: lo

46、oking for dead threads Thu Nov 11 19:42:26 2004 Beginning instance recovery of 1 threads Thu Nov 11 19:42:26 2004 Started redo scan Thu Nov 11 19:42:26 2004 Completed redo scan 114 redo blocks read, 51 data blocks need recovery Thu Nov 11 19:42:26 2004 Started recovery at Thread 2: logseq 961, block

47、 528, scn 0. Recovery of Online Redo Log: Thread 2 Group 3 Seq 961 Reading mem 0 Mem# 0 errs 0: /dev/rredolog2_1 Thu Nov 11 19:42:26 2004 Completed redo application Thu Nov 11 19:42:26 2004 Ended recovery at Thread 2: logseq 961, block 642, scn 0. 51 data blocks read, 51 data blocks written, 114 red

48、o blocks read Ending instance recovery of 1 threads SMON: about to recover undo segment 11 SMON: mark undo segment 11 as available SMON: about to recover undo segment 12 SMON: mark undo segment 12 as available SMON: about to recover undo segment 13 SMON: mark undo segment 13 as available SMON: about

49、 to recover undo segment 14 SMON: mark undo segment 14 as available SMON: about to recover undo segment 15 SMON: mark undo segment 15 as available SMON: about to recover undo segment 16 SMON: mark undo segment 16 as available SMON: about to recover undo segment 17 SMON: mark undo segment 17 as avail

50、able SMON: about to recover undo segment 18 SMON: mark undo segment 18 as available SMON: about to recover undo segment 19 SMON: mark undo segment 19 as available SMON: about to recover undo segment 20 SMON: mark undo segment 20 as available 测试前提： 1 zxin1 上 oracle 实例和平台程序已经启动，正常呼叫，100caps 2 zxin2 上

51、oracle 实例已启动，无呼叫接入 测试步骤： 异常关闭 zxin2 上的实例（shutdown abort） 测试结果： zxin2 实例异常关闭后，zxin1 实例进行资源重组（Reconfiguration）和实例恢复 （Instance Recovery） ，总时间在 5 秒左右，从呼叫仪看受到影响的现有呼叫在 100 个 左右（同时有可能导致的呼叫无法接入的情况，在呼叫仪无法统计得到） ，附 alert_zxin1.log Wed Nov 17 19:03:16 2004 Reconfiguration started List of nodes: 0, Global Resour

52、ce Directory frozen one node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remastered 3331 22065 GCS shadows traversed, 0 cancelled, 1203 closed 10217 GCS resources trave

53、rsed, 0 cancelled 29798 GCS resources on freelist, 39981 on array, 39981 allocated set master node info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 22065 GCS shadows traversed, 0 replayed, 1203 unopened Submitted al

54、l GCS remote-cache requests 0 write requests issued in 20862 GCS resources 1 PIs marked suspect, 0 flush PI msgs Wed Nov 17 19:03:17 2004 Reconfiguration complete Post SMON to start 1st pass IR Wed Nov 17 19:03:17 2004 Instance recovery: looking for dead threads Wed Nov 17 19:03:17 2004 Beginning in

55、stance recovery of 1 threads Wed Nov 17 19:03:17 2004 Started redo scan Wed Nov 17 19:03:19 2004 Completed redo scan 90 redo blocks read, 44 data blocks need recovery Wed Nov 17 19:03:21 2004 Started recovery at Thread 2: logseq 981, block 209, scn 0. Recovery of Online Redo Log: Thread 2 Group 3 Se

56、q 981 Reading mem 0 Mem# 0 errs 0: /dev/rredolog2_1 Wed Nov 17 19:03:21 2004 Completed redo application Wed Nov 17 19:03:21 2004 Ended recovery at Thread 2: logseq 981, block 299, scn 0. 44 data blocks read, 50 data blocks written, 90 redo blocks read Ending instance recovery of 1 threads SMON: abou

57、t to recover undo segment 11 SMON: mark undo segment 11 as available SMON: about to recover undo segment 12 SMON: mark undo segment 12 as available SMON: about to recover undo segment 13 SMON: mark undo segment 13 as available SMON: about to recover undo segment 14 SMON: mark undo segment 14 as avai

58、lable SMON: about to recover undo segment 15 SMON: mark undo segment 15 as available SMON: about to recover undo segment 16 SMON: mark undo segment 16 as available SMON: about to recover undo segment 17 SMON: mark undo segment 17 as available SMON: about to recover undo segment 18 SMON: mark undo se

59、gment 18 as available SMON: about to recover undo segment 19 SMON: mark undo segment 19 as available SMON: about to recover undo segment 20 SMON: mark undo segment 20 as available 4.4.4第二实例所在机器异常关闭对第一实例的影响第二实例所在机器异常关闭对第一实例的影响 测试前提： 1 zxin1 上 oracle 实例和平台程序已经启动，无呼叫接入 2 zxin2 上 oracle 实例和平台程序已经启动，无呼叫接

60、入 测试步骤： 重启机器 zxin2（shutdown Fr） 测试结果： 主机 zxin2 重启，同实例 zxin2 的 shutdown abort 类似，实例 zxin1 进行资源重组 和实例恢复，总时间在 1 秒左右 测试前提： 1 zxin1 上 oracle 实例和平台程序已经启动，正常呼叫，100caps 2 zxin2 上 oracle 实例已经启动 测试步骤： 重启机器 zxin2（shutdown Fr） 测试结果： 主机 zxin2 重启，实例 zxin1 进行资源重组和实例恢复，总时间在 2 秒左右，受到 影响的呼叫数目为 50 个左右。附 alert_zxin1.lo