对Oracle rac 上线前进行测试非常必要,有利于后期rac更加稳定的运行和运维。 通过系列测试,可以验证rac整体功能、性能、可用性、可靠性及业务方面情况,为后续运维提供更好的依据。
主要测试项具体如下:
序号 |
测试内容 |
步骤 |
预期结果 |
评估内容 |
1 |
计划内重启单个节点 |
逐个启动实例所在的节点 对于AIX、HPUX、Windows:“shutdown –r”; 对于Linux: “shutdown –r now”; 对于Solaris: “reboot”。 |
1 、在该节点上运行的实例和其他 Clusterware 资源离线(crsctl stat res -t 输出的'SERVER'字段没有数值 2 、该节点的VIP故障转移到其中一个幸存的节点上,并显示状态为 "INTERMEDIATE","state_details "为 "FAILED_OVER" 3 、在重新启动的节点上运行的SCAN VIP将故障转移到幸存的节点上。 4 、运行在该节点上的SCAN监听器将故障转移到幸存的节点上。 5 、实例恢复由另一个实例执行。 6 、如果停机的实例被指定为首选实例,服务将被转移到可用的实例上。 7 、客户端连接被转移/重新连接到幸存的实例(程序和时间取决于客户端类型和配置)。在配置了TAF的情况下,选择语句应该继续。活动的DML将被中止。 8 、在数据库重新配置后,幸存的实例继续处理它们的工作负荷。 |
1. 检测节点或实例故障的时间; 2. 完成实例恢复的时间, 检查执行恢复的实例的警报日志; 3. 将客户端活动恢复到相同级别的时间(假设剩余节点有足够的容量运行工作负载); 4. 数据库重新配置的持续时间; 5.Clusterware 自动重新启动失败实例并接受新连接之前的时间; 6.SCAN VIP 和SCAN侦听器的成功故障切换。 7. 检测业务是否受影响,影响的范围 |
2 |
重启宕机节点 |
滚动拔掉服务器电源 |
1. 在具有3个或更少节点的集群上,当Oracle Clusterware启动时,其中一个SCAN VIP和侦听器将重新定位到重新启动的节点; 2.VIP 将迁移回重新启动的节点; 3. 由于节点故障而发生故障切换的服务不会自动重新定位; 4. 失败的资源(asm、侦听器、实例等)将由Clusterware重新启动。 |
1. 所有资源再次可用的时间, 检查“crsctl stat res–t” 2. 检测业务是否受影响,影响的范围 |
3 |
同时重启所有节点 |
同时在所有节点上重新启动。 对于AIX、HPUX、Windows:“shutdown –r”; 对于Linux: “shutdown –r now”; 对于Solaris: “reboot”。 |
1. 重新启动所有节点、实例和资源时不会出现问题。 |
1. 所有资源再次可用的时间, 检查“crsctl stat res–t” 2. 检测业务是否受影响,影响的范围 |
4 |
实例意外故障 |
1. 启动客户端工作负载 2. 找到具有大多客户端连接的实例,异常终止该实例 对于AIX、HPUX、Linux、Solaris: 获得pmon进程的进程号,终止该进程; # ps –ef | grep pmon
# kill –9 对于Windows: 获得pmon线程的线程id,杀死该线程; SQL> select b.name, p.spid from v$bgprocess b, v$process p where b.paddr=p.addr and b.name=’PMON’;
cmd> orakill |
1. 其他实例中的一个执行实例恢复 2. 如果一个首选的实例发生故障,服务将被转移到可用的实例上 3. 客户端连接被转移/重新连接到幸存的实例(程序和时间取决于客户端类型和配置 ) 4. 短暂冻结后,幸存的实例继续处理工作负载 5. 失败的实例将由Oracle集群软件重新启动,除非该功能已被禁用。 |
1. 检测实例故障的时间 2. 完成实例恢复的时间。检查恢复实例的警报日志 3. 将客户活动恢复到相同水平的时间(假设剩余节点有足够的能力来运行工作负载 ) 4. 故障切换期间数据库冻结的时间。 5. 在失败的实例被Oracle Clusterware自动重启并接受新连接之前的时间 6. 检测业务是否受影响,影响的范围 |
5 |
重启故障实例 |
1. 如果是不受控制的故障,则由Oracle Clusterware自动重新启动; 2. 如果发出“关机”命令,则需要手动重启; 3. 当相关实例的“自动启动”选项被禁用时,手动重新启动。 |
1. 实例在没有任何问题的情况下重新加入RAC集群(查看警报日志等); 2. 客户端连接和工作负载将在新实例中进行负载平衡(如果长时间运行/永久连接,则可能需要手动过程来重新分配工作负载)。 |
1. 跨所有实例重新平衡服务和工作负载之前的时间(包括任何手动步骤)。 |
6 |
单个节点公网故障 |
1. 拔下公用网络的所有网线; 注意:使用NIS的配置也必须实现NSCD,以便此测试成功,并获得预期结果。 注意:建议不要使用ifconfig来关闭接口,这可能会导致地址仍然被连接到接口上,从而产生意外的结果。 |
1. 检查“crsctl stat res –t” 节点的ora.*.network和listener资源将脱机。 SCAN VIP 和在节点上运行的侦听器将故障转移到幸存的节点。 节点的VIP将故障转移到幸存节点。 2. 数据库实例将保持运行,但将在远程侦听器中注销。 3. 数据库服务将故障转移到其他可用节点之一。 4. 如果配置了TAF,客户端应故障转移到可用的实例。 |
1. 检测网络故障和重新定位资源的时间。 2. 检测业务是否受影响,影响的范围 |
7 |
心跳网络故障 |
1. 拔下心跳网络的所有网线 注意:建议不要使用ifconfig来关闭接口,这可能会导致地址仍然被连接到接口上,从而产生意外的结果 |
1. 对于11g,11.2.0.2及以上版本: CSSD 将检测脑裂情况并执行以下操作之一: 1.1 在两节点集群中,节点数最低的节点将继续存在; 1.2 在多节点集群中,最大的子集群继续存在。 2. 对于12c,12.1.0.2开始,监测脑裂时,权重高的节点将继续存在; 3. 在被逐出的节点上,将尝试正常关闭Oracle Clusterware。 2.1 将终止所有具有I/O功能的客户端进程,并清理所有资源。如果进程终止和/或资源清理未成功完成,则将重新启动节点。 2.2 假设上述工作已成功完成, OHASD 将尝试重新启动堆栈。在这种情况下堆栈的网络连接完成后将重新启动已恢复专用互联网络。 3. 查看以下日志:
$GI_HOME/log/
$GI_HOME/log/ |
1. 检测业务是否受影响,影响的范围 |
8 |
心跳交换机故障(冗余交换机配置) |
1. 在冗余网络交换机配置中,关闭一个交换机的电源 |
网络流量应故障转移到其他交换机,而不影响互连流量或实例。 |
1. 故障转移到其他网卡的时间。如果配置了bonding/teaming/11.2冗余互连,则应小于100ms。 2. 检测业务是否受影响,影响的范围 |
9 |
节点无法访问磁盘子系统的单一路径(OCR、Voting Device、数据库文件) |
1. 拔一根存储连接线路 |
1. 如果启用了多路径,则多路径配置应提供故障透明性; 2. 对数据库实例没有影响。 |
1. 监视数据库在负载下的状态,以确保不发生服务中断; 2. 路径故障转移应该在操作系统日志文件中可见。 3. 检测业务是否受影响,影响的范围 |
10 |
ASM 磁盘丢失 |
1. 假设ASM正常冗余; 2. 关闭/拉出/脱机(取决于配置)一个ASM磁盘。 |
1. 对数据库实例没有影响; 2.ASM 开始重新平衡(查看ASM警报日志)。 |
1.Monitor progress: select * from v$asm_operation 2. 检测业务是否受影响,影响的范围 |
11 |
监听故障 |
1. 对于AIX、HPUX、Linux、Solaris: 获得监听进程的进程号,终止该进程; # ps –ef | grep tnslsnr
# kill –9 2. 对于Windows: 找到tnslistener.exe进程,右键终止进程 |
1. 对连接的数据库会话没有影响; 2. 新连接重定向到其他节点上的监听器(取决于客户端配置); 3. 如果使用共享服务器,本地数据库实例将接收新连接。如果使用专用服务器,本地数据库实例将不会接收新连接; 4. 监听器故障由ORAAGENT检测并自动重新启动; 查看以下日志:
$GI_HOME/log/
$GI_HOME/log/ |
1.Clusterware 检测失败并重新启动侦听器的时间。 2. 检测业务是否受影响,影响的范围 |
12 |
Scan 监听失败 |
对于AIX、HPUX、Linux和Solaris: 获取扫描侦听器进程的PID: #ps–ef | grep tnslsnr 终止侦听器进程:
#kill –9 •对于Windows: 使用Process Explorer来标识 扫描侦听器的tnslistener.exe进程。可以通过任务管理器kill进程。 |
1. 对连接的数据库会话没有影响。 2. 新连接被重定向到其他节点上的侦听器 (取决于客户端配置) 3.CRSD ORAAGENT 检测到侦听器故障,并且 自动重新启动。查看以下日志:
4.$GI_HOME/log/
5.
$GI_HOME/log/
oraagent_ |
1. 检测应用连接配置情况 2. 分析scan 监听失败原因 3. 检测业务影响程度和范围 |