clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1

cssd.log中的报错信息如下:
2013-09-25 08:46:03.739: [    CSSD][2834](:CSSNM00018:)clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1
2013-09-25 08:46:03.749: [    CSSD][2834]###################################
2013-09-25 08:46:03.749: [    CSSD][2834]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
2013-09-25 08:46:03.749: [    CSSD][2834]###################################
2013-09-25 08:46:03.749: [    CSSD][2834](:CSSSC00012:)clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally
2013-09-25 08:46:03.753: [    CSSD][2834]
 
 
该报错与BUG 13869978  较为一致
 
该BUG 13869978的特点是 当仅有一个votedisk时才会触发, 当使用ASM DISKGROUP存放votedisk时:
external redundancy  => 1份votedisk
normal   redundancy  => 3份
High     redundancy  => 5份
当使用external redundancy 时由于只有1份votedisk 所以可能触发该BUG
该bug 目前在11.2.0.3.3 +AIX上有补丁可以打
建议:
考虑使用 normal redundancy  的diskgroup存放votedisk ,或者 应用补丁13869978
 
 

Bug 13869978  OCSSD reports that the voting file is offline without reporting the reason

 

Affects:

Product (Component) Oracle Server (PCW)
Range of versions believed to be affected Versions BELOW 12.1
Versions confirmed as being affected
  • 11.2.0.3
  • 11.2.0.2
Platforms affected Generic (all / most platforms affected)

Fixed:

This issue is fixed in
  • 12.1.0.1 (Base Release)
  • 11.2.0.4 (Future Patch Set)
  • 11.2.0.3.4 Grid Infrastructure Patch Set Update (GI PSU)
  • 11.2.0.3 Patch 11 on Windows Platforms

Symptoms:

Related To:

  • (None Specified)
  • Cluster Ready Services / Parallel Server Management

Description

When we have a single voting file CSSD report the file offline, but thre is no IO error or hung condition
previous to taking the voting file offline:

[    CSSD][29](:CSSNM00018:)clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1
[    CSSD][29]###################################
[    CSSD][29]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
[    CSSD][29]###################################
[    CSSD][29](:CSSSC00012:)clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally

Rediscovery Notes:

If there is no IO error or IO hung that caused to set the voting file offline, then we may be getting this bug.

Workaround
Use more than 1 voting file.

Oracle RAC/Clusterware 多种心跳heartbeat机制介绍 RAC超时机制分析

ORACLE RAC中最主要存在2种clusterware集群件心跳 &  RAC超时机制分析:

1、Network Heartbeat 网络心跳 每秒发生一次; 10.2.0.4以后网络心跳超时misscount为60s,;11.2以后网络心跳超时misscount为30s。

2、Disk Heartbeat 磁盘心跳  每秒发生一次; 10.2.0.4以后 磁盘心跳超时DiskTimeout为200s。

注意不管是磁盘心跳还是网络心跳都依赖于cssd.bin进程来实施这些操作,在真实世界中任何造成cssd.bin这个普通用户进程无法正常工作的原因均可能造成上述2种心跳超时, 原因包括但不局限于 CPU无法分配足够的时间片、内存不足、SWAP、网络问题、Votedisk IO问题、本次磁盘IO问题等等(askmaclean.com)。

 

此外在使用ASM的情况下,DB作为ASM实例的Client客户; ASM实例会对DB实例的ASMB等进程进行监控, 以保证DB与ASM之间通信正常。 若DB的ASMB进程长期无响应(大约为200s)则ASM实例将考虑KILL DB的ASMB进程,由于ASMB是关键后台进程所以将导致DB实例重启。

也存在其他可能的情况,例如由于ASMB 被某些latch block, 会阻塞其他进程,导致PMON进行强制清理。

 

综上所述不管是Clusterware的 cssd.bin进程还是ASMB进程,他们都是OS上的普通用户进程,OS本身出现的问题、超时、延迟均可能造成它们无法正常工作导致。建议在确认对造成OS长时间的网络、IO延时的维护操作,考虑先停止节点上的Clusterware后再实施。

另可以考虑修改misscount、Disktimeout等 心跳超时机制为更大值,但修改这些值并不能保证就可以不触发Node Evication。

 

关于RAC /CRS对于本地盘的问题,详见如下的SR回复:

Does RAC/CRS monitor Local Disk IO ?

 

Oracle software use local ORACLE_HOME / GRID_HOME library files for main process operations.

 

 

There are some socket files under /tmp or /var/tmp needed for CRS communication.

 

Also, the init processes are all depending on the /etc directory to spawn the child processes.

 

Again, this is a complicated design for a cluster software which mainly rely on the OS stability including local file system.

 

Any changes to storage / OS are all recommended to stop CRS services since those are out of our release Q/A tests.

 

由于10.2的环境已经超出我们开发的支持服务期限,建议考虑升级到11.2.0.3来获得更全面的技术支持。

Oracle Acs资深顾问罗敏 老罗技术核心感悟:Clusterware是成熟产品吗?

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

 

Oracle公司自10g版本开始就推出了集群管理软件CRS,以后又升级改造成Clusterware,到11g版本之后更是大动干戈,内部架构进行了大幅度改造,并与ASM技术整合在一起,称之为GI(Grid Infrastructure)。Clusterware替代了硬件厂商和第三方厂商的集群软件功能,也使得Oracle RAC与Clusterware集成为一体,在产品的整体性、服务支持一体化等方面具有显著优势。

作为新产品、新技术,稳定性、成熟性略差,情有可原。但到了11g仍然如此,则让人难以理解了。

本人最近在Windows 2012平台实施了2节点11.2.0.4 RAC,并通过增加节点方式扩展到了4节点RAC,在国内实属罕见案例。期间一些波折,表明 Clusterware产品仍然不成熟。

话说那天我在实施节点扩展操作之前,先花费了半天时间进行了新节点的环境准备之后,并通过如下命令进行了环境检查:

cluvfy stage -pre nodeadd -n hsedb3 –verbose

 

… …

节点 “hsedb3” 上的共享存储检查成功

 

硬件和操作系统设置 的后期检查成功。

哟,一切都“成功”,开练了!于是,我按照Oracle文档标准流程在节点1开始运行AddNode.bat脚本了,一切“正常”!我继续在节点3运行了gridconfig.bat等脚本。

待所有脚本顺利运行完之后检查环境时,却发现节点3根本没有加入到集群环境中,节点3上的Clusterware服务也根本没有启动。—– 这就是产品的严重不成熟,明明出问题了,所有脚本却不显示任何一条返回错误,显示一切正常!更可气的是,AddNode.bat脚本的日志文件(addNodeActions2014-09-07_04-52-22PM.log)也居然显示一切正常,最后还来一句:

*** 安装 结束 页***

C:\app\11.2.0\grid 的 添加集群节点 已成功。

我知道Oracle支持在Windows平台进行RAC加节点操作,但现在没有成功,一定是我犯什么错误了,也肯定知道有什么错误信息藏在什么鸟日志文件里了。无奈天色已晚,忙乎一天了,于是先打道回府了。

隔日,待我回到现场仔细分析各类Clusterware日志文件信息时,首先在alerthsedb3.log文件中大海捞针般地发现了出错信息:

[cssd(4484)]CRS-1649:表决文件出现 I/O 错误: \\.\ORCLDISKORADG0; 详细信息见 (:CSSNM00059:) (位于 C:\app\11.2.0\grid\log\hsedb3\cssd\ocssd.log)。

于是,按图索骥继续去查询ocssd.log文件中的信息。又像侦探一样,在ocssd.log文件8千多行的日志信息中发现了如下错误信息:

2014-09-07 17:00:06.192: [   SKGFD][4484]ERROR: -9(Error 27070, OS Error (OSD-04016: 异步 I/O 请求排队时出错。

O/S-Error: (OS 19) 介质受写入保护。)

此时,其实本人已经觉察出问题了:可能是节点3对存储设备只有读权限,连表决盘(Voting Disk)都没有写入功能,从而导致失败了。为保险期间,还是根据上述出错信息在Metalink中进行了一番搜索,果然如此!《Tablespace (Datafile) Creation On ASM Diskgroup Fails With “[ORA-15081: Failed To Submit An I/O Operation To A Disk] : [ O/S-Error: (OS 19) The media Is Write Protected]” On Windows. ( Doc ID 1551766.1 )》详细描述了原委和解决方案。于是,按照该文档的建议,我将节点3对所有共享存储设备的权限从只读状态修改为可读、可写的联机状态。也明白一个细节:新节点对共享存储设备的权限缺省为只读状态。无论如何,安装之前没有仔细检查共享存储设备的权限是我犯的一个错误。

接下来该是重新进行节点增加操作了。且慢!因为前面已经错误地进行了节点增加操作,而且居然显示成功了,那么运行AddNode.bat脚本的节点1肯定已经在OCR、Voting Disk等集群文件中写入节点3不正确的信息了。因此,需要先实施从集群中删除节点3的操作,但是发现Oracle标准文档中的删除节点操作的如下第一条命令有错误!

C:\>Grid_home\perl\bin\perl -I$Grid_home\perl\lib -I$Grid_home\crs\install

Grid_home\crs\install\rootcrs.pl -deconfig -force

 

又是一番折腾,将上述命令修改如下:

cd \app\11.2.0\grid

 

C:\>perl\bin\perl -I perl\lib -I crs\install crs\install\rootcrs.pl -deconfig –force

终于顺利删除了节点3!

现在可以重新来一遍了。这次一马平川地成功增加了节点3的Clusterware以及RAC,还有节点4的Clusterware和RAC。

 

感悟之一:明明节点3对共享存储只有读权限,而cluvfy却说:节点 “hsedb3” 上的共享存储检查成功!一定是cluvfy只检查了读权限,而没有检查写权限。很可能是cluvfy的Bug!

感悟之二:明明增加节点3的操作失败了。但不仅AddNode.bat没有在命令行及时显示错误,而且对应的日志文件还显示“添加集群节点已成功”。极大地误导客户!罪不可恕!

感悟之三:诊断Clusterware问题太难了!Oracle公司没有告诉客户Clusterware问题的诊断思路,特别是日志文件太多了,不知道先看哪个日志文件,后看哪个日志文件。此次本人完全是凭经验,先看了alerthsedb3.log文件,才找到问题的蛛丝马迹,进而逐步确认问题并加以解决。

… …

总之,Clusterware仍然是一个非常不成熟的产品!

诗檀软件Biot 分享《使用VirtualBox在Oracle Linux 5.7上安装Oracle Database 11g Release 2 RAC的最佳实践》

诗檀软件Biot 分享《使用VirtualBox在Oracle Linux 5.7上安装Oracle Database 11g Release 2 RAC的最佳实践》,下载地址:

 

http://www.askmaclean.com/wp-content/uploads/2014/09/使用VirtualBox在Oracle-Linux-5.7上安装Oracle-Database-11g-Release-2-RAC的最佳实践.pdf

 

GC FREELIST等待事件

GC FREELIST等待事件 freelist empty

kclevrpg  Lock element event number is the name hash bucket the LE belongs to.

kclnfndnew – Find an le for a given name

ORACLE RAC节点意外重启Node Eviction诊断流程图

ORACLE RAC节点意外重启Node Eviction诊断流程图

 

oracle rac Node Evictions

 

 

 

导致实例逐出的五大问题 (Doc ID 1526186.1)

 

适用于:

Oracle Database – Enterprise Edition – 版本 10.2.0.1 到 11.2.0.3 [发行版 10.2 到 11.2]
本文档所含信息适用于所有平台

用途

 

本文档针对导致实例驱逐的主要问题为 DBA 提供了一个快速概述。

适用范围

DBA

详细信息

 

问题 1:警报日志显示 ora-29740 是实例崩溃/驱逐的原因

 

症状:

实例崩溃,警报日志显示“ORA-29740:evicted by member …(被成员…驱逐)”错误。

 

可能的原因:

一个实例将另一个实例从 RAC 数据库驱逐时,出现了 ORA-29740 错误。被驱逐的实例会在警报日志中报告 ora-29740 错误。
此问题的部分原因是集群中的通信错误、向控制文件发送“心跳”失败以及其它原因。

检查所有实例的 lmon 跟踪文件,这对确定实例驱逐的原因代码而言非常重要。查找包含“kjxgrrcfgchk:Initiating reconfig”的行。
这将提供一个原因代码,如“kjxgrrcfgchk:Initiating reconfig, reason 3”。实例驱逐时发生的大多数 ora-29740 错误是由于原因 3(“通信故障”) 造成的。

Document 219361.1 (Troubleshooting ORA-29740 in a RAC Environment) 介绍了以下几种可能造成原因 3的 ora-29740 错误原因:

a) 网络问题。
b) 资源耗尽(CPU、I/O 等)
c) 严重的数据库争用。
d) Oracle bug。

 

解决方案:

1) 检查网络,确保无网络错误,如 UDP 错误或 IP 数据包丢失或故障错误。
2) 检查网络配置,确保所有节点上的所有网络配置均设置正确。
例如,所有节点上 MTU 的大小必须相同,并且如果使用巨帧,交换机也能够支持大小为 9000 的 MTU。
3) 检查服务器是否存在 CPU 负载问题或可用内存不足。
4) 检查数据库在实例驱逐之前是否正处于挂起状态或存在严重的性能问题。
5) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在特定平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
6) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

 

 

问题 2:警报日志在实例崩溃或驱逐前显示“ipc send timeout”错误

 

症状:

实例驱逐时,警报日志显示许多“IPC send timeout”错误。此消息通常伴随数据库性能问题。

 

可能的原因:

在 RAC 中,数据库进程,例如 lmon、lmd 和 lms 会不断地和其他实例的进程通信。lmd0 进程负责管理 enqueue,而 lms 进程负责管理数据块资源并传输数据块以支持 Cache Fusion。如果这些进程中的一个或多个受阻、死循环或异常繁忙,则可能导致“IPC send timeout(IPC 发送超时)”错误。

lmon、lms 和 lmd 进程报告“IPC send timeout”错误的另一个原因是网络问题或服务器资源(CPU 和内存)问题。这些进程可能无法获得 CPU 运行调度或这些进程发送的网络数据包丢失。

涉及 lmon、lmd 和 lms 进程的通信问题导致实例驱逐。被驱逐实例的警报日志显示的信息类似于如下示例

IPC Send timeout detected.Sender: ospid 1519
Receiver: inst 8 binc 997466802 ospid 23309

如果某实例被驱逐,警报日志中的“IPC Send timeout detected(检测到 IPC 发送超时)”通常伴随着其它问题,如 ora-29740 和“Waiting for clusterware split-brain resolution(等待集群件“脑裂”解决方案)”

 

解决方案:

此处的解决方案与问题 1 相似。

1) 检查网络,确保无网络错误,如 UDP 错误或 IP 数据包丢失或故障错误。
2) 检查网络配置,确保所有节点上的所有网络配置均设置正确。
例如,所有节点上 MTU 的大小必须相同,并且如果使用巨帧,交换机也能够支持大小为 9000 的 MTU。
3) 检查服务器是否存在 CPU 负载问题或可用内存不足。
4) 检查数据库在实例驱逐之前是否正处于挂起状态或存在严重的性能问题。
5) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在特定平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
6) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

 

 

问题 3:在实例崩溃或驱逐前,问题实例处于挂起状态

 

症状:

在实例崩溃/驱逐前,该实例或数据库正处于挂起状态。当然,也可能是节点挂起。

 

可能的原因:

由于 lmon、lmd 和 lms 等不同进程与其它实例上对应的进程通信,因此当实例和数据库挂起时,这些进程可能正在等待某个资源,如 latch、enqueue 或数据块。这些等待中的进程得不到网络响应,或无法通过网络向远程实例发送任何通信。因此,其它实例将驱逐问题实例。

在执行驱逐其他实例动作的实例警报日志中,您可能会看到与以下消息类似的消息:
Remote instance kill is issued [112:1]:8
或者
Evicting instance 2 from cluster

 

解决方案:

1) 查找数据库或实例挂起的原因。对数据库或实例挂起问题进行故障排除时,获取全局 systemstate 转储和全局hang analyze 转储是关键。如果无法获取全局 systemstate 转储,则应获取在大致相同时间所有实例的本地 systemstate 转储。
2) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在某些平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
3) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

 

 

问题 4:在一个或多个实例崩溃或驱逐前,警报日志显示“Waiting for clusterware split-brain resolution(等待集群“脑裂”解决方案)”

 

症状:

在一个或多个实例崩溃之前,警报日志显示“Waiting for clusterware split-brain resolution(等待集群件“脑裂”解决方案)”。这通常伴随着“Evicting instance n from cluster(从集群驱逐实例 n)”,其中 n 是指被驱逐的实例编号。

 

可能的原因:

lmon 进程向远程实例发送一个网络 ping,如果远程实例上的 lmon 进程不响应,则出现实例级别的“脑裂”。因此,查找 lmon 不能相互通信的原因对解决此问题而言非常重要。

常见原因有:
1) 实例级别的“脑裂”通常由网络问题导致,因此检查网络设置和连接非常重要。但是,因为如果网络已关闭,集群件 (CRS) 就会出现故障,所以只要 CRS 和数据库使用同一网络,则网络不太可能会关闭。
2) 服务器非常繁忙和/或可用内存量低(频繁的交换和内存扫描),将阻止 lmon 进程被调度。
3) 数据库或实例正处于挂起状态,并且 lmon 进程受阻。
4) Oracle bug

以上原因与问题 1的原因相似(警报日志显示 ora-29740 是实例崩溃/驱逐的原因)。

 

解决方案:

此处的解决方案与问题 1 相似。

1) 检查网络,确保无网络错误,如 UDP 错误或 IP 数据包丢失或故障错误。
2) 检查网络配置,确保所有节点上的所有网络配置均设置正确。
例如,所有节点上 MTU 的大小必须相同,并且如果使用巨帧,交换机也能够支持大小为 9000 的 MTU。
3) 检查服务器是否存在 CPU 负载问题或可用内存不足。
4) 检查数据库在实例驱逐之前是否正处于挂起状态或存在严重的性能问题。
5) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在特定平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
6) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

 

 

问题 5:另一个实例尝试驱逐问题实例,但由于一些原因未能成功驱逐,最终CRS会终止该问题实例。

 

症状:

一个实例驱逐其他实例时,在问题实例自己关闭之前,所有实例都处于等待状态,但是如果问题实例因为某些原因不能终止自己,发起驱逐的实例将发出 Member Kill 请求。Member Kill 请求会要求 CRS 终止问题实例。此功能适用于 11.1 及更高版本。

 

可能的原因:

要求 CRS 终止问题实例的实例警报日志显示
Remote instance kill is issued [112:1]:8

例如,以上消息表示终止实例 8 的 Member Kill 请求已发送至 CRS。

问题实例由于某种原因正处于挂起状态且无响应。这可能是由于节点存在 CPU 和内存问题,并且问题实例的进程无法获得 CPU 运行调度。

第二个常见原因是数据库资源争用严重,导致问题实例无法完成远程实例驱逐该实例的请求。

另一个原因可能是由于实例尝试中止自己时,一个或多个进程“幸存”了下来。除非实例的所有进程全部终止,否则 CRS 不认为该实例已终止,而且不会通知其它实例该问题实例已经被终止。这种情况下的一个常见问题是一个或多个进程变成僵尸进程且未终止。
并导致CRS通过节点重启或 rebootless restart( CRS 重新启动但节点不重启)进行重新启动。这种情况下,问题实例的警报日志显示
Instance termination failed to kill one or more processes
Instance terminated by LMON, pid = 23305
(实例终止未能终止一个或多个进程
实例被 LMON, pid = 23305 终止)

 

解决方案:

此问题的解决方案与问题 3 相似

1) 查找数据库或实例挂起的原因。对数据库或实例挂起问题进行故障排除时,获取全局 systemstate 转储和全局hang analyze 转储是关键。如果无法获取全局 systemstate 转储,则应获取在大致相同时间所有实例的本地 systemstate 转储。
2) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在某些平台和版本中使用,因此请参阅 CHM 常见问题Document 1328466.1
3) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助.

ORACLE RAC clusterware/GI 启动诊断流程图

troubleshooting cluster startup

ORACLE RAC安装故障的诊断流程图

ORACLE RAC安装故障的诊断流程图

 

troubleshooting rac installation

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569