oracle_最常见的 5 个导致节点重新启动、驱逐或 CRS 意外重启的问题
Purpose |
Scope |
Details |
| 问题 1:节点重新启动,但是日志文件未显示任何错误或原因。 |
| 问题 2:节点重新启动,该节点是由于丢失网络心跳而被逐出。 |
| 问题 3:在出现存储问题后节点重新启动。 |
| 问题 4:asm 或数据库实例被挂起或驱逐后节点重新启动。 |
| 问题 5:CRS 自动重启,但是节点没有重新启动 |
References |
Applies to:
Oracle Database - Enterprise Edition - Version 10.1.0.2 to 11.2.0.3 [Release 10.1 to 11.2]Information in this document applies to any platform.
Purpose
本文章简要概述了导致节点重新启动或者 CRS 意外重启的几个最常见问题
Scope
有节点重新启动问题的所有用户
Details
问题 1:节点重新启动,但是日志文件未显示任何错误或原因。
原因: 如果节点重新启动是由于某个 Oracle 进程,但是日志文件没有显示任何错误,则故障位置为 oprocd、cssdmonitor 和 cssdagent 进程。当节点挂起一段时间或者一个或多个关键 CRS 进程无法被调度获得 CPU 时,会发生这种情况。因为那些进程都以实时优先级运行,所以问题可能是因为内存耗尽或者可用内存低,而不是因为 CPU 耗尽。也可能是由于内核交换页的工作量繁重或者正忙于扫描内存以标识要释放的页。也可能存在 OS 调度问题。
解决方案:
1) 如果 CRS 版本为 11.1 或者更低,请将 diagwait 设置为 13。
2) 如果平台为 AIX,请参照文章 811293.1(RAC and Oracle Clusterware Best Practices and Starter Kit (AIX))中所建议的方法优化 AIX VM 参数。
3) 如果平台为 Linux,请设置 Hugepage 并将内核参数 vm.min_free_kbytes 设置为保留“512MB”,将 swappiness 设置为 100。
请注意,使用 Hugepage 时无法设置 memory_target。
4) 检查是否有大量内存分配给了操作系统的 IO 缓冲区高速缓存。与 OS 供应商联系,建议一些方法来减少 IO 缓冲区高速缓存量,或者增加从 IO 缓冲区高速缓存回收内存的比率。
5) 增加内存量。
1) 如果 CRS 版本为 11.1 或者更低,请将 diagwait 设置为 13。
2) 如果平台为 AIX,请参照文章 811293.1(RAC and Oracle Clusterware Best Practices and Starter Kit (AIX))中所建议的方法优化 AIX VM 参数。
3) 如果平台为 Linux,请设置 Hugepage 并将内核参数 vm.min_free_kbytes 设置为保留“512MB”,将 swappiness 设置为 100。
请注意,使用 Hugepage 时无法设置 memory_target。
4) 检查是否有大量内存分配给了操作系统的 IO 缓冲区高速缓存。与 OS 供应商联系,建议一些方法来减少 IO 缓冲区高速缓存量,或者增加从 IO 缓冲区高速缓存回收内存的比率。
5) 增加内存量。
问题 2:节点重新启动,该节点是由于丢失网络心跳而被逐出。
这是因为丢失网络心跳或 发生了脑裂。在双节点环境中,节点 2 的重复重新启动通常意味着节点 2 由于 脑裂而被驱逐。在节点重新启动前,ocssd.log 会显示丢失网络心跳或一条脑裂消息。
原因:节点之间通过私网互连的网络通信失败。故障可能是单向或者双向的。
解决方案:修复网络问题。确保交换机和 NIC 卡等所有网络组件都正常运行。确保 ssh 能通过私网互连工作。请注意,网络通常在节点重新启动后可以恢复正常。
注意: 如果您使用了巨帧(Jumbo Frame),请参考文章341788.1 (Recommendation for the Real Application Cluster Interconnect and Jumbo Frames)。如果交换机的巨帧设置与集群私网NIC卡的MTU(巨帧)设置不同,会出现网络问题,并导致节点驱逐或CRS无法启动。有时,如果您使用的交换机和NIC卡来自不同的厂商,它们对巨帧的支持也可能不同。
问题 3:在出现存储问题后节点重新启动。
ocssd.log 文件显示节点因为无法访问大部分 voting disks 而重新启动。
原因:CRS 必须能够访问大部分 voting disks 。如果 CRS 无法正常访问大部分 voting disks ,则 CRS 无法确保群集的一致性,所以 CRS 重新启动节点。
解决方案:修复 voting disks 的问题。确保用户 oracle 或 grid,或者CRS 或 GI HOME 的拥有者可以使用和访问 voting disks 。如果 voting disks 未在 ASM 中,请使用 "dd if= of=/dev/null bs=1024 count=10240" 测试可访问性。
问题 4:asm 或数据库实例被挂起或驱逐后节点重新启动。
正常运行节点的 ocssd.log 显示一个 member kill 请求升级到了 node kill 请求。
原因:从版本 11.1 开始,如果无法在数据库级别驱逐数据库或 asm 实例,则意味 CRS 将介入来尝试终止问题实例,这被称之为 member kill 请求。如果 CRS 无法终止该问题实例,则 CRS 会重新启动节点,因为 meber kill 请求被升级到了 node kill 请求。
解决方案:查找无法在数据库级别驱逐 asm 或数据库实例(lmon、lmd 和 lms 发起的驱逐)的原因。一个常见原因是实例正处于挂起状态,对远程实例的终止请求无法响应。另一个原因是无法终止多个实例进程中的某个进程。如进程处于不可中断的 IO 闲置状态就属于这样一个例子。
问题 5:CRS 自动重启,但是节点没有重新启动
原因:从版本 11.2.0.2 开始,如果 CRS 由于此处列出的任何原因而需要重新启动节点,CRS 会在重新启动节点之前尝试先对自身进行重启。仅当它无法成功重启自身时,CRS 才重新启动节点来强制对自身进行重启。
解决方案:检查此处列出的哪个节点重新启动原因适用,并按照针对该原因列出的解决方案进行操作。
References
NOTE:341788.1NOTE:1050693.1
NOTE:265769.1
NOTE:452326.1
NOTE:811293.1