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的最佳实践》,下载地址:

 

https://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

【转】导致 Scan VIP 和 Scan Listener(监听程序)出现故障的最常见的 5 个问题 (Doc ID 1602038.1)

【转】导致 Scan VIP 和 Scan Listener(监听程序)出现故障的最常见的 5 个问题 (Doc ID 1602038.1)

 

适用于:

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

用途

本说明简要总结了导致 SCAN VIP 和 SCAN LISTENERS 故障的最常见问题

适用范围

所有遇到 SCAN 问题的用户

详细信息

 

问题 1:SCAN VIP 显示状态“UNKNOWN – CHECK TIMED OUT”

在其中一个节点上,SCAN VIP 显示状态“UNKNOWN”和“CHECK TIMED OUT”
另两个 SCAN VIP 在其他节点上启动,显示状态“ONLINE”

crsctl stat res -t
——————————————————————————–
Cluster Resources
——————————————————————————–
ora.scan1.vip 1 ONLINE UNKNOWN rac2 CHECK TIMED OUT
ora.scan2.vip 1 ONLINE ONLINE rac1
ora.scan3.vip 1 ONLINE ONLINE rac1

原因:
/etc/resolv.conf 在所有节点上不一致
该问题是由于所有指定的 DNS 都不可用而导致的。

 

解决方案:
1) 让所有节点上的 /etc/resolv.conf 保持一致
2) 减少查找超时的值,使总查找时间小于 VIP 资源的检查超时
– 示例:添加到 /etc/resolv.conf: 选项 timeout:1

 

问题 2:在安装 GRID 之前需要对 SCAN VIPS 检查什么?在安装之后需要检查什么

SCAN VIP 是 11.2 版本集群件的新功能。

原因:
安装集群件之前,请按以下所示检查网络定义

 

解决方案:
在安装前
1) /etc/resolv.conf 必须在所有节点上保持一致
2) SCAN 应在 DNS 上配置为指向 3 个有效地址
示例:“ping scan-name”应在 3 次ping之后返回 3 个有效地址
3) SCAN 不应在 /etc/hosts 中定义:如果这样定义,只有一个 SCAN 能够运行
4) SCAN 应使用和集群公网相同的网络掩码。
5) “nslookup scan-name”应返回名DNS和 3 个 IP 地址
6) 如果 GI Home 的 sqlnet.ora 文件中的 参数 tcp.validnode_checking = yes,则 TCP.INVITED_NODES 需要将 SCAN VIP 和 节点 Vip 添加到
Grid Infrastructure(集群件)的 SQLNET.ORA 文件。
7) 如果使用 11gR2 之前的客户端,您将无法完全享受到 SCAN 带来的优势。
详细信息:
http://www.oracle.com/technetwork/database/clustering/overview/scan-129069.pdf
8) “hosts”文件不应包含任何已在 DNS 中定义的 IP。

安装之后,验证 SCAN 配置和状态:
– crsctl status resource -w ‘TYPE = ora.scan_vip.type’ -t
必须显示3 个SCAN 地址 ONLINE
ora.scan1.vip 1 ONLINE ONLINE rac2
ora.scan2.vip 1 ONLINE ONLINE rac1
ora.scan3.vip 1 ONLINE ONLINE rac1
– crsctl status resource -w ‘TYPE = ora.scan_vip.type’ -t
应显示 LISTENER_SCAN<x> ONLINE
– srvctl config scan /srvctl config scan_listener
显示 SCAN 和 SCAN listener(监听程序)配置:scan 名称、网络和所有 SCAN VIP(名称和 IP)、端口
– cluvfy comp scan

 

问题 3:在 SCAN listener 发生故障切换(failover)后,服务未注册到 SCAN listener

在执行 SCAN VIP 和 SCAN listener故障切换后,实例未注册到 SCAN listener。这种情况只会发生在其中1 个 scan listener上。客户机连接间歇性出现“ORA-12514 TNS:listener does not currently know of service requested in connect descriptor”。

原因:

1. 未发布的 Bug 12659561:在执行 scan listener故障切换后,数据库实例可能未注册到 scan listener(请参阅 Note 12659561.8),这一问题已在 11.2.0.3.2 中修复,针对 11.2.0.2 的 Merge patch13354057 适用于特定平台。
2. 未发布的 Bug 13066936:在执行 scan 故障切换时,实例未注册服务(请参阅 Note 13066936.8)。

 

解决方案:

1) 对于以上两个 Bug,解决方法是执行以下步骤,在未注册到 SCAN listener的数据库实例上注销并重新注册remote_listener。
show parameter remote_listener
alter system set remote_listener=”;
alter system register;
alter system set remote_listener='<scan>:<port>’;
alter system register;

2) 服务未注册到 SCAN listener(监听程序)时要检查的其他要点:
a. 正确定义了 remote_listener 和 local_listener
b. sqlnet.ora 中定义了 EZCONNECT,示例:NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
c. /etc/hosts 或 DNS 中定义了 SCAN,并且如果在两处都定义,则检查是否存在任何不匹配情况
d. nslookup <scan> 应以 round-robin (循环)方式显示 SCAN VIP
e. 如果未配置 Secure transports (COST) 的类,则不要在 listener.ora 中设置 SECURE_REGITER_<listener>。

 

问题 4:公网关闭时,SCAN VIPS 不执行故障切换(failover)

公网关闭时,Scan Vip 应切换到下一个节点。在 11.2.0.1 的一些环境中,Scan Vip 可能会停留在错误的节点上。

原因:Bug 9488744: OCE: MULTIPLE PUBLIC NETWORK, PULL PRIMARY PUBLIC CABLE, VIP DOES NOT FAILOVER

 

解决方案:

安装最新的 11.2.0.1 PSU 或 升级到11.2.0.2/11.2.0.3

 

问题 5:SCAN Listener 故障

原因:
1) listener.ora 存在于 /etc 或 /var/opt/oracle 中
2) 未使用默认端口 1521

 

解决方案:
1) 将 listener.ora 移动到其他位置。
已在 11.2.0.3 和最新的 11.2.0.2 PSU 中修复
2) 从较低发行版升级到 11.2.0.3 GI 之后,SCAN listener端口已更改为默认值 1521

 

Database – RAC/Scalability 社区
为了与 Oracle 专家和业内同行进一步讨论这个话题,我们建议您加入 My Oracle Support 的 Database – RAC/Scalability 社区参与讨论。

10.2.0.4以后vip不会自动relocate back回原节点

10.2.0.4以后vip不会自动relocate back回原节点, 原因是ORACLE开发人员发现在实际使用中会遇到这样的情况: relocate back回原节点 需要停止VIP并在原始节点再次启动该VIP,但是如果原始节点上的公共网络仍不可用,则这个relocate的尝试将再次失败而failover到第二节点。 在此期间VIP将不可用,所以从10.2.0.4和11.1开始,默认的实例检查将不会自动relocate vip到原始节点。

 

 

 

详细见下面的Note介绍:

 

 

 

Applies to:
Oracle Server – Enterprise Edition – Version 10.2.0.4 to 11.1.0.7 [Release 10.2 to 11.1]
Information in this document applies to any platform.
Symptoms

Starting from 10.2.0.4 and 11.1, VIP does not fail-over back to the original node even after the public network problem is resolved.  This behavior is the default behavior in 10.2.0.4 and 11.1 and is different from that of 10.2.0.3
Cause

This is actually the default default behavior in 10.2.0.4 and 11.1

In 10.2.0.3, on every instance check, the instance attempted to relocate the VIP back to the preferred node (original node), but that required stopping the VIP and then attempt to restart the VIP on the original node. If the public network on the original node is still down, then the attempt to relocate VIP to the original node will fail and the VIP will fail-over back to the secondary node.  During this time, the VIP is not available, so starting from 10.2.0.4 and 11.1, the default behavior is that the instance check will not attempt to relocate the VIP back to the original node.
Solution

If the default behavior of 10.2.0.4 and 11.1 is not desired and if there is a need to have the VIP relocate back to the original node automatically when the public network problem is resolved, use the following workaround
Uncomment the line
ORA_RACG_VIP_FAILBACK=1 && export ORA_RACG_VIP_FAILBACK

in the racgwrap script in $ORACLE_HOME/bin

With the above workaround, VIP will relocate back to the original node when CRS performs the instance check, so in order for the VIP to relocate automatically, the node must have at least one instance running.

The instance needs to be restarted or CRS needs to be restarted to have the VIP start relocating back to the original node automatically if the change is being made on the existing cluster.

Relying on automatic relocation of VIP can take up to 10 minutes because the instance check is performed once every 10 minutes.  Manually relocating the VIP is only way to guarantee quick relocation of VIP back to the original node.
To manually relocate the VIP, start the nodeapps by issuing
srvctl start nodeapps -n <node name>

Starting the nodeapps does not harm the online resources such as ons and gsd.

沪ICP备14014813号

沪公网安备 31010802001379号