最常见的 5 个导致节点重新启动、驱逐或 CRS 意外重启的问题 (文
适用于:Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 11.2.0.3 [发行版 10.1 到 11.2] 用途? 本文章简要概述了导致节点重新启动或者 CRS 意外重启的几个最常见问题 适用范围有节点重新启动问题的所有用户 详细信息
问题 1:节点重新启动,但是日志文件未显示任何错误或原因。原因: 如果节点重新启动是由于某个 Oracle 进程,但是日志文件没有显示任何错误,则故障位置为 oprocd、cssdmonitor 和 cssdagent 进程。当节点挂起一段时间或者一个或多个关键 CRS 进程无法被调度获得 CPU 时,会发生这种情况。因为那些进程都以实时优先级运行,所以问题可能是因为内存耗尽或者可用内存低,而不是因为 CPU 耗尽。也可能是由于内核交换页的工作量繁重或者正忙于扫描内存以标识要释放的页。也可能存在 OS 调度问题。? 解决方案:
问题 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 而重新启动。 ? 解决方案:修复 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 请求。 ? 解决方案:查找无法在数据库级别驱逐 asm 或数据库实例(lmon、lmd 和 lms 发起的驱逐)的原因。一个常见原因是实例正处于挂起状态,对远程实例的终止请求无法响应。另一个原因是无法终止多个实例进程中的某个进程。如进程处于不可中断的 IO 闲置状态就属于这样一个例子。
问题 5:CRS 自动重启,但是节点没有重新启动原因:从版本 11.2.0.2 开始,如果 CRS 由于此处列出的任何原因而需要重新启动节点,CRS 会在重新启动节点之前尝试先对自身进行重启。仅当它无法成功重启自身时,CRS 才重新启动节点来强制对自身进行重启。? 解决方案:检查此处列出的哪个节点重新启动原因适用,并按照针对该原因列出的解决方案进行操作。参考 NOTE:265769.1?- Troubleshooting 10g and 11.1 Clusterware Reboots (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |