PRMSCAN ORACLE碎片扫描合并工具

2016/08/04 by admin Leave a Comment

prmscan 是诗檀软件独立研发的ORACLE数据块碎片扫描合并工具，其适用于以下的场景：

误手动删除了文件系统（任意文件系统 NTFS、FAT、EXT、UFS、JFS等）或ASM上的数据文件
文件系统损坏，导致数据文件大小变成0 bytes即数据文件被清零
文件系统损坏，导致文件系统无法MOUNT加载
ASM存储元数据损坏，导致diskgroup无法mount加载
文件系统或ASM其中的LV或PV被物理破坏或丢失

以上场景均可以利用prmscan直接扫描文件系统或ASM对应的 PV、LV 中的残余未被覆盖的oracle block，来实现对这些oracle数据块的合并重组，以达到数据恢复的目的。

PRMSCAN是基于JAVA语言开发的，可以跨一切支持JDK 1.6以后操作系统，包括Windows、Linux、Solaris、AIX、HP-UX。

prmscan 是诗檀软件独立研发的ORACLE数据块碎片扫描合并工具，目前该产品不独立销售，可以联系诗檀软件（13764045638）以服务形式提供恢复服务。

例如下面的例子中/dev/sdb1为ext4文件系统的分区，但是由于ext4文件系统损坏，导致SDB1无法被MOUNT，但该文件系统上存放了一套oracle数据库的数据文件，若无法MOUNT文件系统则oracle数据库也将无法使用。

这里我们使用prmscan的扫描oracle数据文件块和合并功能，从损坏的文件系统中直接将数据文件都重组出来。

扫描整个磁盘

[oracle@dbdao01 ~]$ java -jar PRMScan.jar –scan /dev/sdb1 –guess 8k

–scan 选项代表扫描 /dev/sdb1 设备，并指定Oracle blocksize 为8k

[oracle@dbdao01 ~]$ java -jar PRMScan.jar –outputsh ./8kfull.txt

–outputsh 代表写出一个可以合并已扫描到信息的SHELL文件即这里的8kfull.txt

[oracle@dbdao01 ~]$ sh 8kfull.txt

执行8kfull.txt即可以在当前目录下生成所有需要合并的数据文件

如下

[oracle@dbdao01 ~]$ ls -ll PD*

-rw-r–r– 1 oracle oinstall 295428096 Jul 28 00:37 PD_DBF1.dbf

-rw-r–r– 1 oracle oinstall 83427328 Jul 28 00:37 PD_DBF2.dbf

-rw-r–r– 1 oracle oinstall 220266496 Jul 28 00:37 PD_DBF3.dbf

-rw-r–r– 1 oracle oinstall 1324482560 Jul 28 00:38 PD_DBF4.dbf

使用PRM-DUL扫描这些数据文件

核对数据量

Filed Under: Oracle

Parnassus Data诗檀软件成为Solix 大数据合作伙伴

2016/08/01 by admin Leave a Comment

http://www.prweb.com/releases/2016/03/prweb13280231.htm

加利福尼亚州圣克拉拉市。 2016年3月21日

Solix Technologies, Inc., 美商Solix科技公司是信息生命周期管理软件(Information Lifecycle Management (ILM))领域的领导者，其提供面向Apache hadoop的整体解决方案。 Solix近日宣布中国地区的数据库服务商Parnassus Data诗檀软件选择Solix Big data 大数据方案，作为其面向客户的数据归档、应用程序退休和基于apache hadoop高级分析的交付主要产品。

Apache hadoop是ILM 信息生命周期管理的理想平台，源于其所提供的高可扩展性、低成本、以及对企业数据的海量存储。Parnassus Data诗檀软件将提供基于Solix 大数据套件的软件销售和服务以帮助用户改善应用性能，降低成本，满足政府要求和风险控制。作为一个企业的常规数据平台，Solix大数据套件提供面向大数据集（包括结构化数据和非架构化数据）的高级分析功能。

“作为一个常规数据平台，Apache hadoop 针对高级企业分析和ILM应用是十分理想的，”　Solix科技的执行高管John Ottman 告诉我们。”我们尝试与Parnassus Data诗檀软件在大中华市场深层合作！“

“Solix是当前唯一能针对所有企业数据提供综合Information Lifecycle Management (ILM) 的供应商。我们很高兴能在国际上有这样一个给力的合作伙伴。” 诗檀软件的CEO 刘相兵说道。

如欲了解更多Solix大数据套件信息，点击这里。

关于Solix 索利克斯科技

Solix Technologies, Inc., 美商Solix科技公司是信息生命周期管理软件(Information Lifecycle Management (ILM))领域的领导者，其提供面向Apache hadoop的整体解决方案。Solix致力于帮助资方采用优化后的架构来组织企业内部信息。Solix Big Data大数据套件是一个ILM 应用解决方案框架包括企业归档和企业数据湖(data lake)，应用程序退役，和测试数据管理（database subsetting）和　数据脱敏（data masking)。Solix 科技，总部位于加利福尼亚圣克拉拉市，拥有分布全球的经销商和集成商。如欲了解更多，可以访问http://www.solix.com.

关于 Parnassus Data 诗檀软件

Parnassus Data 诗檀软件是总部位于中国上海的数据库服务公司，提供数据库部署、应用、管理和紧急救助、灾难恢复服务。Parnassus Data诗檀软件精于数据优化、监控、分析和开发。Parnassus Data诗檀软件独立开发了自主产权的Oracle 数据库恢复软件PRM-DUL。如欲了解更多，可以访问http://www.parnassusdata.com/

Filed Under: Oracle

MACOS OSX苹果操作系统上的Oracle

2016/08/01 by admin Leave a Comment

oracle server software针对MACOS OSX已经多年未提供更新，其服务器版一直停留在10.2.0.4版本。目前版本的MACOS 例如 Yosemite基本是装不上这个版本的Oracle DB SERVER软件的。

虽然oracle不提供Server software给MACOS了，但还是提供Instant Client的，下载地址在这里： http://www.oracle.com/technetwork/topics/intel-macsoft-096467.html

这意味着你没法直接在MACOS 上运行oracle数据库实例了，但还是能把你的mac本子当做客户端的，你也可以只用sqldeveloper和sqlcl这些基于jdbc的客户端，不需要安装Instant Client。

所以对于目前版本的macos ，如果你实在想要能运行oracle instance的话：

基于例如virtualbox 这样的虚拟机安装linux然后运行oracle db
回退MACOS到比较老的版本（不太可能，也不推荐）

Filed Under: Oracle

LGWR写redo的伪代码

2016/06/29 by admin Leave a Comment

本文地址：https://www.askmac.cn/archives/fast-path-redo-algorithms.html

LGWR写redo的伪代码

while(1)
{
/* The RBA can be stored into rba_pga; The pic keeps meta-data
   corresponding to each write. */

Read RBA corresponding to end of last write issued and store into rba_pga;
	for (each strand)
	{
		/* Start address for the write and is a pointer within the 
                   strand buffer up to which the last write went to disk. 
                   The LGWR then does a dirty read of the pointer within the
                   strand buffer where the latest redo block is being allocated.
                   The range of redo from the start address  to the dirty read is
                   referred to as the  "potential range" because it will most
                   likely make it to disk. The final range within each strand that
                   together forms a consistent set of redo will be determined by 
    		   the "extend" range step under the redo alloc latch (RAL). */
  	           Pick potential range within strand that will go into the next
                   write issued to the logfile;

		kcrfa[strand#].potential_end = ptr to latest redo;
	}

	/* Bumping the SCN after picking the range in the above step makes it
           unnecessary to contract the range in the "extend" step below. 
           Range expansion  is easy because strand meta-data points to the
           start of a LWN. */
	

     Bump SCN and store into scn_pga;
	for (each strand)
	{
		/* Get redo alloc latch for strand */
Get RAL[strand#];
		kcrfa[strand#].rba = rba_pga;
		kcrfa[strand#].scn = scn_pga;
   /* This uses kcrfa[strand#].potential_end as an optimized starting
      point to traverse the forward redo block allocation links  including all blocks of redo with SCN less than scn_pga. */
      Extend strand write range to include all  redo with SCN less than
      scn_pga;
		/* Free redo alloc latch for strand */
		Free RAL[strand#];
	}
	Issue write to logfile;
}

Filed Under: Oracle

Oracle中的历史公案之翻案：dead transaction到底是谁做recover的？

2016/06/29 by admin Leave a Comment

本文地址：https://www.askmac.cn/archives/ga1.html

作者: Maclean 刘相兵，非授权禁止转载！

很多同学在学习ORACLE OCP的过程中遇到如下的问题：

In the middle of a transaction,a user session was abnormally terminated but the instance is 
still up and the database is open. Which two statements are true in the scenario（方案）? (Choose two).
A. Event viewer gives more details on the failure.
B. The alert log file gives detailed information about the failure.
C. PMON rolls back the transaction and releases the locks.
D. SMON rolls back the transaction and releases the locks.
E. The transaction is rolled backup by the next session that refers to any of the blocks updated by the failed transaction.
F. Data modified by the transaction up to the last commit before the abnormal termination is retained in the database.

标准答案为：C F ，也就是说ocp教材对于会话异常终止锁导致的事务回滚这个情况，认为是由PMON进程做回滚和释放锁的。

但如果我们去实际做个试验看看呢，在这个实验中我们模拟一个会话在做了一个较大的DELETE后被KILL掉，此时DELETE相关的事务需要被回滚，到底是不是PMON出手呢？

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL> select  * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
www.askmac.cn

SQL>alter system set fast_start_parallel_rollback=false;
System altered.

设置10500，10046事件以跟踪SMON进程的行为

SQL> alter system set events '10500 trace name context forever,level 8';
System altered.

SQL> oradebug setospid 4424
Oracle pid: 8, Unix process pid: 4424, image: oracle@rh2.oracle.com (SMON)

SQL> oradebug event 10046 trace name context forever,level 8;
Statement processed.

在一个新的terminal中执行大批量的删除语句，在执行一段时间后使用操作系统命令将执行该删除操作的
服务进程kill掉，模拟一个大的dead transaction的场景

SQL> delete large_rb;
delete large_rb

[oracle@rh2 bdump]$ kill -9 4535

等待几秒后pmon进程会找出dead process:

[claim lock for dead process][lp 0x7000003c70ceff0][p 0x7000003ca63dad8.1290666][hist x9a514951]

在x$ktube内部视图中出现ktuxecfl(Transaction flags)标记为DEAD的记录:

SQL> select sum(distinct(ktuxesiz)) from x$ktuxe where ktuxecfl = 'DEAD';

SUM(DISTINCT(KTUXESIZ))
-----------------------
                  29386

SQL> /

SUM(DISTINCT(KTUXESIZ))
-----------------------
                  28816

以上KTUXESIZ代表事务所使用的undo块总数(number of undo blocks used by the transaction)

==================smon trace content==================
SMON: system monitor process posted
WAIT #0: nam='log file switch completion' ela= 0 p1=0 p2=0 p3=0 obj#=1 tim=1278243332801935
WAIT #0: nam='log file switch completion' ela= 0 p1=0 p2=0 p3=0 obj#=1 tim=1278243332815568
WAIT #0: nam='latch: row cache objects' ela= 95 address=2979418792 number=200 tries=1 obj#=1 tim=1278243333332734
WAIT #0: nam='latch: row cache objects' ela= 83 address=2979418792 number=200 tries=1 obj#=1 tim=1278243333356173
WAIT #0: nam='latch: undo global data' ela= 104 address=3066991984 number=187 tries=1 obj#=1 tim=1278243347987705
WAIT #0: nam='latch: object queue header operation' ela= 89 address=3094817048 number=131 tries=0 obj#=1 tim=1278243362468042
WAIT #0: nam='log file switch (checkpoint incomplete)' ela= 0 p1=0 p2=0 p3=0 obj#=1 tim=1278243419588202
Dead transaction 0x00c2.008.0000006d recovered by SMON

=====================
PARSING IN CURSOR #3 len=358 dep=1 uid=0 oct=3 lid=0 tim=1278243423594568 hv=3186851936 ad='ae82c1b8'
select smontabv.cnt,
       smontab.time_mp,
       smontab.scn,
       smontab.num_mappings,
       smontab.tim_scn_map,
       smontab.orig_thread
  from smon_scn_time smontab,
       (select max(scn) scnmax,
               count(*) + sum(NVL2(TIM_SCN_MAP, NUM_MAPPINGS, 0)) cnt
          from smon_scn_time
         where thread = 0) smontabv
 where smontab.scn = smontabv.scnmax
   and thread = 0

END OF STMT
PARSE #3:c=0,e=1354526,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1278243423594556
EXEC #3:c=0,e=106,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1278243423603269
FETCH #3:c=0,e=47065,p=0,cr=319,cu=0,mis=0,r=1,dep=1,og=4,tim=1278243423650375
*** 2011-06-24 21:19:25.899
WAIT #0: nam='smon timer' ela= 299999999 sleep time=300 failed=0 p3=0 obj#=1 tim=1278243716699171
kglScanDependencyHandles4Unpin():
  cumscan=3 cumupin=4 time=776 upinned=0

通过一个10500 trace level 8可以很容易让SMON开口，如上的试验给出了2个最重要的信息：

等待几秒后pmon进程会找出dead process:

[claim lock for dead process][lp 0x7000003c70ceff0][p 0x7000003ca63dad8.1290666][hist x9a514951]

Dead transaction 0x00c2.008.0000006d recovered by SMON

即负责找出dead process异常终止进程的当然是PMON，但实际这个dead transaction 是由SMON做recover的。

如果完全按照试验的结论可以发现,OCP教材上对于此题的答案其实是错误的，即选项C (C. PMON rolls back the transaction and releases the locks.)是错误的，
实际做rollback transaction的是SMON，SMON还会在回滚过程中必要的释放row lock行锁，当然其他内存锁资源还需要PMON去释放。

这是最终的事实吗？ OCP教材误导了学生好多年？
不完全是，其实这里受到隐藏参数_rollback_cleanup_entries 的影响，其大致算法如下：
PMON会负责找到dead transaction 的state object临时对象
如果dead transaction 涉及到的undo记录未超过隐藏参数_rollback_cleanup_entries(默认为100)，则PMON将负责回滚
否则PMON将post SMON，让SMON完成超过_rollback_cleanup_entries的部分
SMON 可以发起并行SLAVE帮助它一起完成rollback

分析ORACLE 源代码Undo事务管理头文件 ktucts.h – Kernel Transaction Undo Compile Time Services 可以看到：


   2904 /* Starting with 8.1.3, cleanup_rollback_entries is an underscore parameter */
   2905 KSPPAR_OBSOLETE("cleanup_rollback_entries", KSPPARM_MADE_UNDERSCORE)
   2906 
   2907 #define ktunud KSPPARDN(ktunud_)
   2908 KSPPARDV("_cleanup_rollback_entries", ktunud_, ktunud_s, ktunud_l, ktunud_p,
   2909          LCCMDINT,
   2910           0, NULLP(const text), 100, KSPLS1(NULLP(text)), KSPLS1(UB4MAXVAL), 0,
   2911           KSPLS1(NULLP(sword)),
   2912           "no. of undo entries to apply per transaction cleanup")

cleanup_rollback_entries参数是从版本8.1.3开始变成隐藏参数的，显然ORACLE当时已经认识到小的dead事务直接让PMON回滚，如果事务较大那么让PMON直接委托SMON来做，同时黄金的比例就是cleanup_rollback_entries=100的经典值。

由于OCP作为入门教材并不过分强调学习者对ORACLE内部原理的理解，所以只需要大众记住由PMON负责做dead transaction recover即可。

但如果我们更进一步地去观察ORACLE就会发现并不是那么回事。所以在过去20多年中对于到底是SMON还是PMON做dead transaction的rollback有着无休止的讨论，因为教材与实际的表现有着较大的差异。

在某些特殊的情况下ORACLE Support会建议你将_cleanup_rollback_entries设置为400或1000，这种情况并不多见，主要是为了调试一些性能问题。

通过这篇文章或许可以为此ORACLE历史公案小小的翻一下案，让幕后功臣SMON的默默功绩不至于彻底埋没。

Filed Under: Oracle

ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册v2

2016/06/20 by admin Leave a Comment

ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册v2

在原文档的基础上增加了修复坏块等内容：

ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册v2

Filed Under: Oracle

Oracle数据库性能诊断课程.pdf

2016/05/20 by admin Leave a Comment

Oracle数据库性能诊断课程.pdf

Filed Under: Oracle, Oracle SQL性能调优

Oracle视角：旁观某电信客户升级/迁移项目

2016/04/13 by admin 1 Comment

作者为:

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

本文永久地址：https://www.askmac.cn/archives/oracle视角：旁观某电信客户升级迁移项目.html

不得已而为之的数据库升级和迁移项目

多年来，某省电信运营商虽然对其核心CRM系统进行了持续优化工作，但仍然满足不了业务高速发展需求，尤其是每月出账期系统压力越来越大，故障频频，以至于每当账期来临，局方各级领导、各业务部门和技术人员，以及应用开商和维护保障公司人员都是如坐针毡，甚至如临大敌。

在2015年下半年连续几个月账期均出现不稳定状况之后，各方一致认为数据库系统和应用软件优化工作已经持续了几年，优化空间已经非常有限了，是到了系统软硬件平台升级换代的时候了。

该系统现有硬件平台为HP PA-RISC小型机，数据库版本为10g R2，可见无论硬件还是系统软件都已经属于落后淘汰的技术了，现有硬件配置和性能甚至低于当下最新的X86服务器。作为Oracle公司服务部门，我们更是喋喋不休地讲述数据库升级到11g R2的必要性、可行性、方法论和风险控制策略等，特别是介绍了大量成功案例的实施经验。于是，领导终于下决心了！升级到11g R2并迁移到最高配置的X86服务器！项目实施周期确定为2个月，而且还横跨2016年春节！

本人无意点评领导决策的欠科学，甚至拍脑袋，其实我们深深理解领导的苦衷：已经连续优化这么长时间了，还是艰难度日，万一下个月账期系统彻底瘫痪，怎么办？

于是，尽管各方技术人员向领导和各业务部门力陈升级和迁移的难度和风险，但最后大家还是迫于业务压力，决定赶鸭子上架了！

麻雀虽小，五脏俱全

虽然项目实施周期非常短暂，但局方还是组建了由业务部门、应用开发商、运维团队等多方组成的项目组。在数据库迁移方面决定采用DSG公司的相关产品和技术，在应用测试方面也决定进行全面的功能和压力测试。喏，这就是该项目实施计划表的部分内容：

主要任务	序号	功能描述
准备工作	1	提供主机和数据库集成方案
	2	梳理全场景测试方案
	3	梳理系统所有的外围接口
	4	统计梳理营业库中的所有表，按照表容量大小进行排名（刘书荣）。分析存储空间超过100m的表，若其为分区表，则继续细化到表空间，明确可以优先迁移的表。
	5	梳理所有数据库主机的shell、C程序
	6	梳理所有was主机的tns和数据源指向，提供上线时所有主机的tns和数据源修改方案。
	7	梳理接口机的改造点。
	8	梳理所有应用营业主机上部署的脚本，评估是否需要修改。
	9	梳理所有应用账务主机上部署的脚本，评估是否需要修改。
	10	梳理营业所有应用程序的配置文件和jar包，评估分析是否需要修改，包括BSS、爱营销(代理商)
	11	梳理计费账务所有应用程序的配置文件和jar包，评估分析是否需要修改
	12	梳理营业数据库所有配置表有无数据库IP指向，评估分析是否需要修改
	13	梳理计费账务数据库所有配置表有无数据库IP指向，评估分析是否需要修改
	14	梳理mq等内部接口改造点。
	15	局方确认crm库上的job和dblink由应用开发商完成迁移
硬件部署	16	硬件到货
	17	完成上架加电，达到可以交付实施集成标准
	18	环境集成实施完毕，可以进行迁移工作
数据迁移	19	DSG队列规划，拆分复制同步范围
	20	活动数据同步，活动数据部分，这里按照40%的数据量是静态数据估算，且按照6个并发任务估算，每小时能够导出的数据为250GB左右，CPU占用2个cpu，MEM为 1GB，IO资源估算为85MB/s。如果按现在CRM库的压力，我们建议使用1－2个通道来导出数据，可能时间上不能保障在2月14日前一定同步完成。
	21	历史数据同步
测试环境应用搭建与联调	22	迁移应用开发商负责的数据库对象
	23	数据库对象完整性核查
	24	应用主机测试准备：将64主机从web页面群组拆下来，调整数据源和TNS指向，在主机上部署job、工作流、外围接口程序。
	25	修改新搭建数据库内配置表
	26	修改各个接口程序配置指向
	27	在新搭建的数据库主机上部署shell、C程序进行测试；
	28	调整测试环境MQ程序等内部接口配置指向；
	29	调整账务测试环境dblink指向、账务主机TNS配置指向
	30	协调oss、ocs配合测试
	31	根据测试方案全流程测试
	32	估算压力测试需要多少台主机，向局方提出申请，申请多台主机进行测试。

上述计划表由应用开发商主要从应用整体角度提出，尽管我们省略了原有表格中局方负责人、厂商负责人、预计完成时间等敏感信息，但大家还是一定能感受到升级/迁移项目的复杂性：硬件、网络、系统软件、数据库软件、应用软件… …面面俱到，一个也不能少，真是个庞大的系统工程。

数据由DSG迁移了，应用开发商负责应用功能和压力测试，作为Oracle服务团队的我们还能做什么呢？难道就是安装一下Linux平台的11g R2 RAC，然后提供一些现场技术支持吗？喏，这就是我们制定的Oracle服务计划：

序号	主要任务	功能描述
1	11g R2 RAC安装和配置检查和完善服务	负责2台新服务器的11.2.0.4 RAC软件安装，以及Oracle公司推荐的补丁安装，并基于Oracle最佳实践经验以及其它客户的实施经验，对数据库初始化参数和隐含参数进行检查和完善。
2	11g R2 RAC服务器的替换	通过RAC增加节点、删除节点操作，实现对RAC服务器的替换
3	性能优化和性能管理方案设计和测试	性能优化和性能管理方案设计，特别是11g SPA技术方案的设计和测试
4	正式环境上线前封装检查及性能基线收集	针对新建CRM系统，通过ORACHK等工具进行全面的配置检查和封版检查，并进行相应的完善，同时进行性能基线收集。
5	正式迁移和割接期间技术支持	新建CRM系统正式上线期间现场技术支持

可见，作为Oracle服务实施团队，我们的优势主要发挥在两个方面：第一就是在Oracle数据库环境安装和确保稳定性方面，包括11g R2 RAC专业化的安装、补丁分析和实施、初始化参数和隐含参数的设置等。第二个方面则是Oracle服务团队的另一个独特优势，因为我们深知升级和迁移项目最大的风险其实是来自于应用软件的性能衰减，而Oracle从11g开始推出了SPA工具，即通过该工具，可进行升级前后的应用性能对比分析，这样在测试阶段就能提前诊断出执行计划变化和性能衰减的SQL语句，并加以优化和改造，从而降低升级之后性能问题的出现概率，确保整个升级项目实施的成功。

各方不乏经验、方法论和人力资源投入，局方也提供了测试环境，但是大家都痛感最缺乏的只有一样东西：时间！时间！时间！在两个月的项目实施周期中，刨去春节假期，还有DSG的两次数据同步时间窗口（一次是将现有生产系统数据同步到测试环境，一次是正式割接前的数据同步），有效测试时间连一个月都不到！

艰难的测试过程

就在这一个月不到的时间里，各方要开展应用功能测试、应用压力测试，还有SPA测试。由于工期和项目计划组织问题，各项应用测试还与DSG的数据同步测试出现了时间上的重叠和冲突。于是，数据同步尚未完成，索引还未同步过去呢，压力测试和SPA测试就开始了，这些测试哪能跑得下去？于是，测试初期各方在不断磨合，尤其是解决各类数据同步问题，宝贵的测试时间又一点点流失掉了，真是欲速不达。经验啊！

测试期间正好横跨2016年春节，各方人员依然以饱满的工作激情、可贵的职业精神，协同作战，每天大家几乎都统一加班到晚上11：00，基本圆满完成了各类测试任务。作为Oracle服务团队，我们也第一次为该客户展现了SPA工具的价值：通过SPA测试，我们发现了若干条SQL语句出现了性能衰减，并加以有效解决，防止了这些问题在正式割接上线时爆发。

1个月的测试时间不知不觉就这么过去了。真是成也萧何，败也萧何。不久之后的正式割接期间的事实证明：大量的测试付出，的确有效地防范了各类问题的发生，但也正是因为测试时间太短，导致测试工作的不充分，尤其是当时对测试期间发现的问题没有深入探究，为正式割接埋下了深深的隐患！

惊心动魄的正式上线割接

大家在倾情投入了近两个月之后，终于以兴奋同时也是忐忑不安的心情，迎来了正式升级/迁移的割接上线日子。于是，各路神仙云集客户现场，本人作为旁观者也亲眼目睹了整个割接上线过程的跌宕起伏和惊心动魄。兴奋、刺激、纠结、无奈、痛苦、开心、喜悦、感慨，无数情感和心境在短短的2天多时间内不断变换，实乃精彩的人生写照！且听下面的娓娓到来。

上线第一天上午业务刚开始，似乎总体还算正常，但作为Oracle服务团队，包括我自己在内还是发现了一些SQL语句出现了性能衰减，好在我们已经有预案，例如多数语句的性能衰减是由于优化器改变为CBO之后出现的执行计划变化，于是我们采取了删除相关表统计数据，暂时回退到RBO的策略，留待事后再解决。事实证明，相比后面将要表述的系统层面问题，SQL语句问题仅仅是局部性问题而已。

就在第一天上午10：00多业务压力逐渐增加之后，我们首先获悉了前台应用反应非常慢的投诉，其次我们发现数据库服务器压力并不大，而在数据库和中间件层面均发现了网络问题，例如数据库服务器的公网延时居然达到了50ms！而私网也出现了丢包问题。由于硬件厂商网络工程师第一天晚上才能赶到现场，大家只能在等待、无奈、无助，甚至煎熬的心情中度过第一个白天，业务更是缓慢爬行了一整天。

事后我们回想起来，其实在压力测试阶段，大家已经发现了公网延时和私网丢包问题，甚至还导致了RAC宕机，但的确由于测试周期太短，这些问题都没有深入探究其根本原因，就这么带病上岗了。经验教训啊！

好在网络工程师第一天晚上赶到现场之后，很快诊断出网络问题，在调整、配置了几个网络参数之后，网络延时和丢包问题解决了。于是，大家又以轻松、期盼的心情迎来了第二天的业务。可是，这种愉悦的心情几乎是稍纵即逝，第二天上午随着业务高峰的来临，数据库服务器不堪重负，Top显示的Load居然达到500以上，IO Wait更是高达50%！经验告诉我们，IO Wait超过10%就不正常了，难道I/O压力很大，抑或存储系统I/O能力不够、配置不当？大家很快就否定了这些判断，而事实上数据库服务器中最消耗资源的根本不是Oracle进程，而是root用户下的CPU调度程序，这属于主机或操作系统层面问题，硬件厂商工程师在倾力分析和解决中，而第二天的业务比第一天更加艰难，全省CRM系统前端几乎完全瘫痪！

到了第二天日终，问题依然如故，领导终于做出了最简单，事后也证明是最有效的决策：换机器！于是，各方又开始通宵达旦地协同工作了，Oracle服务团队具体负责RAC环境下的删除节点、增加节点操作。我们的同事事后自我调侃道：我已经成了RAC增删节点的高手了！

第三天立竿见影了：一切都恢复正常！原来的数据库服务器硬件或操作系统到底出现了什么问题？我们作为旁观者，无权评述。但听局方系统工程师介绍，这是由于Linux处理中断机制跟UNIX不一样，大部分资源都消耗在处理中断上了，并发越大、处理越慢、越来越恶化。测试阶段是否出现过该问题呢？据了解，还真没有出现过，原因就是测试环境的硬件条件有限，没有模拟出生产系统的真实压力。经验啊！真实模拟测试的重要性！

更多的感慨

本人讲述完这个刚刚发生的惊心动魄的升级/迁移故事，无意渲染升级/迁移项目的高风险和难度，更不是要吓退那些对升级操作本来就心存疑虑和担忧的决策者们，而是试图通过这个真实案例的总结，大家来共同来感悟如下的经验教训：

Oracle数据库系统升级和迁移的确是一项机遇和风险并存的系统工程，战略上藐视，战术上重视是基本策略。也就是说升级/迁移项目肯定是能成功的，但科学的升级/迁移方法论指导、需求的全面分析、完备的技术方案和全面测试是项目成功的重要保障。
我们虽然一直强调应用性能问题是升级过程中需要特别关注的问题，但相比主机、操作系统、网络等层面而言，SQL语句问题只是局部性问题，而系统层面问题却是全局性问题。任何一个全局性问题的爆发，都将是灾难性的。
真实模拟测试、测试方法、测试手段的重要性，不要放过测试中出现的每一个问题。最后再重复一句名言：无论如何强调测试工作的重要性都不为过。

2016年3月27日于高铁上

Filed Under: Oracle

Oracle RAC集群Grid Infrastructure 启动的五大问题(Doc ID 1526147.1)

2016/04/06 by admin Leave a Comment

适用于:

Oracle Database – Enterprise Edition – 版本 11.2.0.1 和更高版本
Oracle Database Cloud Schema Service – 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine – 版本 N/A 和更高版本
Oracle Cloud Infrastructure – Database Service – 版本 N/A 和更高版本
Oracle Database Cloud Exadata Service – 版本 N/A 和更高版本
本文档所含信息适用于所有平台

用途

本文档的目的是总结可能阻止 Grid Infrastructure (GI) 成功启动的 5 大问题。

适用范围

本文档仅适用于 11gR2 Grid Infrastructure。

要确定 GI 的状态，请运行以下命令：

1. $GRID_HOME/bin/crsctl check crs
2. $GRID_HOME/bin/crsctl stat res -t -init
3. $GRID_HOME/bin/crsctl stat res -t
4. ps -ef | egrep 'init|d.bin'

详细信息

问题 1：CRS-4639：无法连接 Oracle 高可用性服务，ohasd.bin 未运行或 ohasd.bin 虽在运行但无 init.ohasd 或其他进程

症状：

1. 命令“$GRID_HOME/bin/crsctl check crs”返回错误：

CRS-4639: Could not contact Oracle High Availability Services

2. 命令“ps -ef | grep init”不显示类似于如下所示的行：

root 4878 1 0 Sep12 ? 00:00:02 /bin/sh /etc/init.d/init.ohasd run

3. 命令“ps -ef | grep d.bin”不显示类似于如下所示的行：

root 21350 1 6 22:24 ? 00:00:01 /u01/app/11.2.0/grid/bin/ohasd.bin reboot


或者它只显示 "ohasd.bin reboot" 进程而没有其他进程

4. 日志 ohasd.log 中出现以下信息:

2013-11-04 09:09:15.541: [ default][2609911536] Created alert : (:OHAS00117:) : TIMED OUT WAITING FOR OHASD MONITOR

5. 日志 ohasOUT.log 中出现以下信息:

2013-11-04 08:59:14 Changing directory to /u01/app/11.2.0/grid/log/lc1n1/ohasd
OHASD starting Timed out waiting for init.ohasd script to start; posting an alert

6. ohasd.bin 一直处于启动状态，ohasd.log 信息：

2014-08-31 15:00:25.132: [  CRSSEC][733177600]{0:0:2} Exception: PrimaryGroupEntry constructor failed to validate group name with error: 0 groupId: 0x7f8df8022450 acl_string: pgrp:spec:r-x
2014-08-31 15:00:25.132: [  CRSSEC][733177600]{0:0:2} Exception: ACL entry creation failed for: pgrp:spec:r-x
2014-08-31 15:00:25.132: [    INIT][733177600]{0:0:2} Dump State Starting ...

7. 只有ohasd.bin运行，但是ohasd.log没有任何信息。 OS 日志/var/log/messages显示

2015-07-12 racnode1 logger: autorun file for ohasd is missing

可能的原因：

1. 文件“/etc/inittab”并不包含行(对于OL5/RHEL5以及以下版本，内容也会因版本的不同而不同)
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2. 未达到运行级别 3，一些 rc3 脚本挂起
3. Init 进程 (pid 1) 并未衍生 /etc/inittab (h1) 中定义的进程，或 init.ohasd 之前的不当输入，如 xx:wait:<process> 阻碍了 init.ohasd 的启动
4. CRS 自动启动已禁用
5. Oracle 本地注册表 ($GRID_HOME/cdata/<node>.olr) 丢失或损坏(root用户执行命令检查 “ocrdump -local /tmp/olr.log”, 文件 /tmp/olr.log 应该包含所有GI进程有关信息,对比一个正常工作的集群环境)
6. root用户之前在”spec”组，但是现在”spec”组被删除，但是旧组仍然记录在OLR中，可以通过OLR dump验证。
7. 节点重启后当init.ohasd启动时 HOSTNAME 为空。

解决方案：

1. 将以下行添加至 /etc/inittab （对于OL5/RHEL5以及以下版本）

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

并以 root 用户身份运行“init q”。对于Linux OL6/RHEL6, 请参考文档 note 1607600.1

2. 运行命令“ps -ef | grep rc”，并kill看起来受阻的所有 rc3 脚本。

3. 删除 init.ohasd 前的不当输入。如果“init q”未衍生“init.ohasd run”进程，请咨询 OS 供应商

4. 启用 CRS 自动启动：

# crsctl enable crs
# crsctl start crs

5. 以 root 用户身份从备份中恢复 OLR（Oracle 本地注册表）：(参考Note 1193643.1)

# crsctl stop crs -f
# touch $GRID_HOME/cdata/<node>.olr
# chown root:oinstall $GRID_HOME/cdata/<node>.olr
# ocrconfig -local -restore$GRID_HOME/cdata/<node>/backup_<date>_<num>.olr
# crsctl start crs如果出于某种原因，OLR 备份不存在，要重建 OLR 就需要以 root 用户身份执行 deconfig 并重新运行 root.sh：
# $GRID_HOME/crs/install/rootcrs.pl -deconfig -force
# $GRID_HOME/root.sh

6. 需要重新初始化/创建OLR, 使用命令与前面创建OLR命令相同。

7. 重启init.ohasd进程或者在init.ohasd中添加”sleep 30″，这样允许在启动集群前输出hostname信息，参考Note 1427234.1.

8. 如果上面方法不能解决问题，请检查OS messages中有关ohasd.bin日志信息，按照OS message中提示信息，

设置LD_LIBRARY_PATH = <GRID_HOME>/lib，并且手动执行crswrapexece.pl命令。

问题 2：CRS-4530：联系集群同步服务守护进程时出现通信故障，ocssd.bin 未运行

症状：

1. 命令“$GRID_HOME/bin/crsctl check crs”返回错误：

CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager

2. 命令“ps -ef | grep d.bin”不显示类似于如下所示的行：

oragrid 21543 1 1 22:24 ? 00:00:01 /u01/app/11.2.0/grid/bin/ocssd.bin

3. ocssd.bin 正在运行，但在 ocssd.log 中显示消息“CLSGPNP_CALL_AGAIN”后又中止运行

4. ocssd.log 显示如下内容：

   2012-01-27 13:42:58.796: [ CSSD][19]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 223132864, wrtcnt, 1112, LATS 783238209,
lastSeqNo 1111, uniqueness 1327692232, timestamp 1327693378/787089065

5. 对于 3 个或更多节点的情况，2 个节点形成的集群一切正常，但是，当第 3 个节点加入时就出现故障，ocssd.log 显示如下内容：

   2012-02-09 11:33:53.048: [ CSSD][1120926016](:CSSNM00008:)clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 2 nodes with leader 2, racnode2, is smaller than
cohort of 2 nodes led by node 1, racnode1, based on map type 2
2012-02-09 11:33:53.048: [ CSSD][1120926016]###################################
2012-02-09 11:33:53.048: [ CSSD][1120926016]clssscExit: CSSD aborting from thread clssnmRcfgMgrThread

6. 10 分钟后 ocssd.bin 启动超时

   2012-04-08 12:04:33.153: [    CSSD][1]clssscmain: Starting CSS daemon, version 11.2.0.3.0, in (clustered) mode with uniqueness value 1333911873
......
2012-04-08 12:14:31.994: [    CSSD][5]clssgmShutDown: Received abortive shutdown request from client.
2012-04-08 12:14:31.994: [    CSSD][5]###################################
2012-04-08 12:14:31.994: [    CSSD][5]clssscExit: CSSD aborting from thread GMClientListener
2012-04-08 12:14:31.994: [    CSSD][5]###################################
2012-04-08 12:14:31.994: [    CSSD][5](:CSSSC00012:)clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally

7. alert<node>.log 显示:

2014-02-05 06:16:56.815
[cssd(3361)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds; Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/bdprod2/cssd/ocssd.log
...
2014-02-05 06:27:01.707
[ohasd(2252)]CRS-2765:Resource 'ora.cssdmonitor' has failed on server 'bdprod2'.
2014-02-05 06:27:02.075
[ohasd(2252)]CRS-2771:Maximum restart attempts reached for resource 'ora.cssd'; will not restart.
>

可能的原因：

1. 表决磁盘丢失或无法访问
2. 多播未正常工作（对于版本11.2.0.2，这是正常的情况。对于 11.2.0.3 PSU5/PSU6/PSU7 和 12.1.0.1 版本，是由于Bug 16547309）
3. 私网未工作，ping 或 traceroute <private host> 显示无法访问目标。或虽然 ping/traceroute 正常工作，但是在私网中启用了防火墙
4. gpnpd 未出现，卡在 dispatch 线程中， Bug 10105195
5. 通过 asm_diskstring 发现的磁盘太多，或由于 Bug 13454354 导致扫描太慢（仅在 Solaris 11.2.0.3 上出现）

解决方案：

1. 通过检查存储存取性、磁盘权限等恢复表决磁盘存取。如果表决盘在 OS 级别无法访问，请敦促操作系统管理员恢复磁盘访问。
如果 OCR ASM 磁盘组中的 voting disk已经丢失，以独占模式启动 CRS，并重建表决磁盘：

# crsctl start crs -excl
# crsctl replace votedisk <+OCRVOTE diskgroup>

2. 请参考 Document 1212703.1 ，了解多播功能的测试及修正。对于版本 11.2.0.3 PSU5/PSU6/PSU7 和12.1.0.1，您可以为集群私网启用多播或者应用补丁16547309 或最新的PSU。更多信息请参考Document 1564555.1

3. 咨询网络管理员，恢复私网访问或禁用私网防火墙（对于 Linux，请检查服务 iptables 状态和服务 ip6tables 状态）

4. 终止正常运行节点上的 gpnpd.bin 进程，请参考 Document 10105195.8

一旦以上问题得以解决，请重新启动 Grid Infrastructure。

如果 ping/traceroute 对私网均可用，但是问题发生在从 11.2.0.1 至 11.2.0.2 升级过程中，请检查Bug 13416559 获取解决方法。

5. 通过提供更加具体的 asm_diskstring，限制 ASM 扫描磁盘的数量，请参考 bug 13583387

对于 Solaris 11.2.0.3，请应用补丁 13250497，请参阅 Document 1451367.1.

问题 3：CRS-4535：无法与集群就绪服务通信，crsd.bin 未运行

症状：

1. 命令“$GRID_HOME/bin/crsctl check crs”返回错误：

CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4534: Cannot communicate with Event Manager

2. 命令“ps -ef | grep d.bin”不显示类似于如下所示的行：

root 23017 1 1 22:34 ? 00:00:00 /u01/app/11.2.0/grid/bin/crsd.bin reboot

3. 即使存在 crsd.bin 进程，命令“crsctl stat res -t –init”仍然显示：

ora.crsd
1    ONLINE     INTERMEDIATE

可能的原因：

1. ocssd.bin 未运行，或资源 ora.cssd 不在线
2. +ASM<n> 实例无法启动
3. OCR 无法访问
4. 网络配置已改变，导致 gpnp profile.xml 不匹配
5. Crsd 的 $GRID_HOME/crs/init/<host>.pid 文件已被手动删除或重命名，crsd.log 显示：“Error3 -2 writing PID to the file”
6. ocr.loc 内容与其他集群节点不匹配。crsd.log 显示：“Shutdown CacheLocal. my hash ids don’t match”
7.当巨帧（Jumbo Frame）在集群私网被启用时，节点私网能够通过“ping”命令互相联通，但是无法通过巨帧尺寸ping通（例如：ping -s 8900 <私网 ip>）或者
集群中的其他节点已经配置巨帧(MTU: 9000)，而出现问题的节点没有配置巨帧(MTU:1500)。
8.对于平台 AIX 6.1 TL08 SP01 和 AIX 7.1 TL02 SP01，由于多播数据包被截断。

解决方案：

1. 检查问题 2 的解决方案，确保 ocssd.bin 运行且 ora.cssd 在线

2. 对于 11.2.0.2 以上版本，确保资源 ora.cluster_interconnect.haip 在线，请参考 Document 1383737.1 了解和HAIP相关的，ASM无法启动的问题。

3. 确保 OCR 磁盘可用且可以访问。如果由于某种原因丢失 OCR，请参考 Document 1062983.1 了解如何恢复OCR。

4. 恢复网络配置，与 $GRID_HOME/gpnp/<node>/profiles/peer/profile.xml 中定义的接口相同，请参考Document 283684.1 了解如何修改私网配置。

5. 请使用 touch 命令，在 $GRID_HOME/crs/init 目录下创建名为 <host>.pid 的文件。

对于 11.2.0.1，该文件归 <grid> 用户所有。

对于 11.2.0.2，该文件归 root 用户所有。

6. 使用 ocrconfig 命令修正 ocr.loc 内容：

例如，作为 root 用户：

# ocrconfig -repair -add +OCR2 （添加条目）
# ocrconfig -repair -delete +OCR2 （删除条目）

以上命令需要 ohasd.bin 启动并运行。一旦以上问题得以解决，请通过以下命令重新启动 GI 或启动 crsd.bin：

# crsctl start res ora.crsd -init

7. 如果巨帧只是在网卡层面配置了巨帧，请敦促网络管理员在交换机层面启动巨帧。如果您不需要使用巨帧，请将集群中所有节点的私网MTU值设置为1500，之后重启所有节点。

8. 对于平台 AIX 6.1 TL08 SP01 和 AIX 7.1 TL02 SP01，根据下面的note应用对应的 AIX 补丁
Document 1528452.1 AIX 6.1 TL8 or 7.1 TL2: 11gR2 GI Second Node Fails to Join the Cluster as CRSD and EVMD are in INTERMEDIATE State

问题 4：Agent 或者 mdnsd.bin, gpnpd.bin, gipcd.bin 未运行

症状：

1. orarootagent 未运行. ohasd.log 显示:

2012-12-21 02:14:05.071: [    AGFW][24] {0:0:2} Created alert : (:CRSAGF00123:) :  Failed to start the agent process: /grid/11.2.0/grid_2/bin/orarootagent Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/grid/11.2.0/grid_2/bin/orarootagent]
2. mdnsd.bin, gpnpd.bin 或者 gipcd.bin 未运行, 以下是 mdnsd log中显示的一个例子:
2012-12-31 21:37:27.601: [  clsdmt][1088776512]Creating PID [4526] file for home /u01/app/11.2.0/grid host lc1n1 bin mdns to /u01/app/11.2.0/grid/mdns/init/
2012-12-31 21:37:27.602: [  clsdmt][1088776512]Error3 -2 writing PID [4526] to the file []
2012-12-31 21:37:27.602: [  clsdmt][1088776512]Failed to record pid for MDNSD

或者

2012-12-31 21:39:52.656: [  clsdmt][1099217216]Creating PID [4645] file for home /u01/app/11.2.0/grid host lc1n1 bin mdns to /u01/app/11.2.0/grid/mdns/init/
2012-12-31 21:39:52.656: [  clsdmt][1099217216]Writing PID [4645] to the file [/u01/app/11.2.0/grid/mdns/init/lc1n1.pid]
2012-12-31 21:39:52.656: [  clsdmt][1099217216]Failed to record pid for MDNSD

3. oraagent 或 appagent 未运行, 日志crsd.log显示:

2012-12-01 00:06:24.462: [    AGFW][1164069184] {0:2:27} Created alert : (:CRSAGF00130:) :  Failed to start the agent /u01/app/grid/11.2.0/bin/appagent_oracle

可能的原因：

1. orarootagent 缺少执行权限
2. 缺少进程相关的 <node>.pid 文件或者这个文件的所有者/权限不对
3. GRID_HOME 所有者/权限不对

解决方案：

1. 和一个好的GRID_HOME比较所有者/权限，并做相应的改正，或者以root用户执行:

# cd <GRID_HOME>/crs/install
# ./rootcrs.pl -unlock
# ./rootcrs.pl -patch


这将停止集群软件，对需要的文件的所有者/权限设置为root用户，并且重启集群软件。

2. 如果对应的 <node>.pid 不存在, 就用touch命令创建一个具有相应所有者/权限的文件, 否则就按要求改正文件<node>.pid的所有者/权限, 然后重启集群软件.
这里是<GRID_HOME>下，所有者属于root:root 权限 644的<node>.pid 文件列表：


./ologgerd/init/<node>.pid
./osysmond/init/<node>.pid
./ctss/init/<node>.pid
./ohasd/init/<node>.pid
./crs/init/<node>.pid
所有者属于<grid>:oinstall，权限644
./mdns/init/<node>.pid
./evm/init/<node>.pid
./gipc/init/<node>.pid
./gpnp/init/<node>.pid3.

对第3种原因，请参考解决方案1

问题 5：ASM 实例未启动，ora.asm 不在线

症状：

1. 命令“ps -ef | grep asm”不显示 ASM 进程

2. 命令“crsctl stat res -t –init”显示：

ora.asm
1    ONLINE    OFFLINE

可能的原因：

1. ASM spfile 损坏
2. ASM discovery string不正确，因此无法发现 voting disk/OCR
3. ASMlib 配置问题
4. ASM实例使用不同的cluster_interconnect, 第一个节点 HAIP OFFLINE 导致第二个节点ASM实例无法启动

解决方案：

1. 创建临时 pfile 以启动 ASM 实例，然后重建 spfile，请参考 Document 1095214.1 了解更多详细信息。
2. 请参考 Document 1077094.1 以更正 ASM discovery string。
3. 请参考 Document 1050164.1 以修正 ASMlib 配置。
4. 请参考 Document 1383737.1 作为解决方案。请参考 Document 1210883.1 了解更多HAIP信息

要进一步调试 GI 启动问题，请参考 Document 1050908.1 Troubleshoot Grid Infrastructure Startup Issues.

Filed Under: Oracle, Oracle RAC

诊断 Oracle RAC集群Grid Infrastructure 启动问题 (Doc ID 1623340.1)

2016/04/06 by admin Leave a Comment

适用于:

Oracle Database – Enterprise Edition – 版本 11.2.0.1 和更高版本
Oracle Database Cloud Schema Service – 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine – 版本 N/A 和更高版本
Oracle Cloud Infrastructure – Database Service – 版本 N/A 和更高版本
Oracle Database Backup Service – 版本 N/A 和更高版本
本文档所含信息适用于所有平台

用途

本文提供了诊断 11GR2 和 12C Grid Infrastructure 启动问题的方法。对于新安装的环境（root.sh 和 rootupgrade.sh 执行过程中）和有故障的旧环境都适用。针对 root.sh 的问题，我们可以参考 note 1053970.1 来获取更多的信息。

适用范围

本文适用于集群/RAC数据库管理员和 Oracle 支持工程师。

详细信息

启动顺序：

简而言之，操作系统负责启动 ohasd 进程，ohasd 进程启动 agents 用来启动守护进程(gipcd, mdnsd, gpnpd, ctssd, ocssd, crsd, evmd ,asm …) ，crsd 启动 agents 用来启动用户资源(database,SCAN,Listener 等)。

如果需要了解更详细的 Grid Infrastructure Cluster 启动顺序，请参阅 note 1053147.1。

集群状态

查询集群和守护进程的状态:

$GRID_HOME/bin/crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

$GRID_HOME/bin/crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
1        ONLINE  ONLINE       rac1                  Started
ora.crsd
1        ONLINE  ONLINE       rac1
ora.cssd
1        ONLINE  ONLINE       rac1
ora.cssdmonitor
1        ONLINE  ONLINE       rac1
ora.ctssd
1        ONLINE  ONLINE       rac1                  OBSERVER
ora.diskmon
1        ONLINE  ONLINE       rac1
ora.drivers.acfs
1        ONLINE  ONLINE       rac1
ora.evmd
1        ONLINE  ONLINE       rac1
ora.gipcd
1        ONLINE  ONLINE       rac1
ora.gpnpd
1        ONLINE  ONLINE       rac1
ora.mdnsd
1        ONLINE  ONLINE       rac1

对于11.2.0.2 和以上的版本，会有以下两个额外的进程：

ora.cluster_interconnect.haip
1        ONLINE  ONLINE       rac1
ora.crf
1        ONLINE  ONLINE       rac1

对于11.2.0.3 以上的非EXADATA的系统，ora.diskmon会处于offline的状态，如下：

ora.diskmon
1        OFFLINE  OFFLINE       rac1

对于 12c 以上的版本, 会出现ora.storage资源：

ora.storage
1 ONLINE ONLINE racnode1 STABLE

如果守护进程 offline 我们可以通过以下命令启动:

$GRID_HOME/bin/crsctl start res ora.crsd -init

问题 1: OHASD 无法启动

由于 ohasd.bin 的责任是直接或者间接的启动集群所有的其它进程，所以只有这个进程正常启动了，其它的进程才能起来，如果 ohasd.bin 的进程没有起来，当我们检查资源状态的时候会报错 CRS-4639 (Could not contact Oracle High Availability Services); 如果 ohasd.bin 已经启动了，而再次尝试启时，错误 CRS-4640 会出现；如果它启动失败了，那么我们会看到以下的错误信息：

CRS-4124: Oracle High Availability Services startup failed.
CRS-4000: Command Start failed, or completed with errors.

自动启动 ohasd.bin 依赖于以下的配置：

1. 操作系统配置了正确的 run level:

OS 需要在 CRS 启动之前设置成指定的 run level 来确保 CRS 的正常启动。

我们可以通过以下方式找到 CRS 需要 OS 设置的 run level：

cat /etc/inittab|grep init.ohasd
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

注意：Oracle Linux 6 (OL6) 和 Red Hat Linux 6 (RHEL6) 上已经不使用inittab，init.ohasd已经被/etc/init/oracle-ohasd.conf替代，不过 /etc/init.d/init.ohasd run 应该仍然可用。Oracle Linux 7 (以及 Red Hat Linux 7) 使用 systemd 来启动/关闭服务 (比如: /etc/systemd/system/oracle-ohasd.service)

以上例子展示了，CRS 需要 OS 运行在 run level 3 或 5；请注意，由于操作系统的不同，CRS 启动需要的 OS 的 run level 也会不同。

找到当前 OS 正在运行的 run level:

who -r

2. “init.ohasd run” 启动

在 Linux/Unix 平台上，由于”init.ohasd run” 是配置在 /etc/inittab中，进程 init（进程id 1，linux，Solars和HP-UX上为/sbin/init ，Aix上为/usr/sbin/init）会启动并且产生”init.ohasd run”进程，如果这个过程失败了，就不会有”init.ohasd run”的启动和运行，ohasd.bin 也是无法启动的：

ps -ef|grep init.ohasd|grep -v grep
root      2279     1  0 18:14 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run

如果任何 rc Snncommand 的脚本（在 rcn.d 中，如 S98gcstartup）在启动的过程中挂死，此时 init 的进程可能无法启动”/etc/init.d/init.ohasd run”；您需要寻求 OS 厂商的帮助，找到为什么 Snncommand 脚本挂死或者无法正常启动的原因；

错误”[ohasd(<pid>)] CRS-0715:Oracle High Availability Service has timed out waiting for init.ohasd to be started.” 可能会在 init.ohasd 无法在指定时间内启动后出现

如果系统管理员无法在短期内找到 init.ohasd 无法启动的原因，以下办法可以作为一个临时的解决办法：

cd <location-of-init.ohasd>
nohup ./init.ohasd run &

3. Clusterware 自动启动；–自动启动默认是开启的

默认情况下 CRS 自动启动是开启的，我们可以通过以下方式开启：

$GRID_HOME/bin/crsctl enable crs

检查这个功能是否被开启:

$GRID_HOME/bin/crsctl config crs

如果以下信息被输出在OS的日志中

Feb 29 16:20:36 racnode1 logger: Oracle Cluster Ready Services startup disabled.
Feb 29 16:20:36 racnode1 logger: Could not access /var/opt/oracle/scls_scr/racnode1/root/ohasdstr

原因是由于这个文件不存在或者不可访问，产生这个问题的原因一般是人为的修改或者是打 GI 补丁的过程中使用了错误的 opatch (如：使用 Solaris 平台上的 opatch 在 Linux 上打补丁)

4. syslogd 启动并且 OS 能够执行 init 脚本 S96ohasd

节点启动之后，OS 可能停滞在一些其它的 Snn 的脚本上，所以可能没有机会执行到脚本 S96ohasd；如果是这种情况，我们不会在 OS 日志中看到以下信息

Jan 20 20:46:51 rac1 logger: Oracle HA daemon is enabled for autostart.

如果在 OS 日志里看不到上面的信息，还有一种可能是 syslogd（(/usr/sbin/syslogd）没有被完全启动。GRID 在这种情况下也是无法正常启动的，这种情况不适用于 AIX 的平台。

为了了解 OS 启动之后是否能够执行 S96ohasd 脚本，可以按照以下的方法修改该脚本：

From:

    case `$CAT $AUTOSTARTFILE` in
enable*)
$LOGERR "Oracle HA daemon is enabled for autostart."

To:

    case `$CAT $AUTOSTARTFILE` in
enable*)
/bin/touch /tmp/ohasd.start."`date`"
$LOGERR "Oracle HA daemon is enabled for autostart."

重启节点后，如果您没有看到文件 /tmp/ohasd.start.timestamp 被创建，那么就是说 OS 停滞在其它的 Snn 的脚本上。如果您能看到 /tmp/ohasd.start.timestamp 生成了，但是”Oracle HA daemon is enabled for autostart”没有写入到messages 文件里，就是 syslogd 没有被完全启动了。以上的两种情况，您都需要寻求系统管理员的帮助，从 OS 的层面找到问题的原因，对于后一种情况，有个临时的解决办法是“休眠”2分钟，按照以下的方法修改 ohasd 脚本：

From:

    case `$CAT $AUTOSTARTFILE` in
enable*)
$LOGERR "Oracle HA daemon is enabled for autostart."

To:

    case `$CAT $AUTOSTARTFILE` in
enable*)
/bin/sleep 120
$LOGERR "Oracle HA daemon is enabled for autostart."

5. GRID_HOME 所在的文件系统在执行初始化脚本 S96ohasd 的时候在线；正常情况下一旦 S96ohasd 执行结束，我们会在 OS message 里看到以下信息：

Jan 20 20:46:51 rac1 logger: Oracle HA daemon is enabled for autostart.
..
Jan 20 20:46:57 rac1 logger: exec /ocw/grid/perl/bin/perl -I/ocw/grid/perl/lib /ocw/grid/bin/crswrapexece.pl /ocw/grid/crs/install/s_crsconfig_rac1_env.txt /ocw/grid/bin/ohasd.bin "reboot"

如果您只看到了第一行，没有看到最后一行的信息，很可能是 GRID_HOME 所在的文件系统在脚本 S96ohasd 执行的时候还没有正常挂载。

6. Oracle Local Registry (OLR, $GRID_HOME/cdata/${HOSTNAME}.olr) 有效并可以正常读写

ls -l $GRID_HOME/cdata/*.olr
-rw------- 1 root  oinstall 272756736 Feb  2 18:20 rac1.olr

如果 OLR 是不可读写的或者损坏的，我们会在 ohasd.log 中看到以下的相关信息

..
2010-01-24 22:59:10.470: [ default][1373676464] Initializing OLR
2010-01-24 22:59:10.472: [  OCROSD][1373676464]utopen:6m':failed in stat OCR file/disk /ocw/grid/cdata/rac1.olr, errno=2, os err string=No such file or directory
2010-01-24 22:59:10.472: [  OCROSD][1373676464]utopen:7:failed to open any OCR file/disk, errno=2, os err string=No such file or directory
2010-01-24 22:59:10.473: [  OCRRAW][1373676464]proprinit: Could not open raw device
2010-01-24 22:59:10.473: [  OCRAPI][1373676464]a_init:16!: Backend init unsuccessful : [26]
2010-01-24 22:59:10.473: [  CRSOCR][1373676464] OCR context init failure.  Error: PROCL-26: Error while accessing the physical storage Operating System error [No such file or directory] [2]
2010-01-24 22:59:10.473: [ default][1373676464] OLR initalization failured, rc=26
2010-01-24 22:59:10.474: [ default][1373676464]Created alert : (:OHAS00106:) :  Failed to initialize Oracle Local Registry
2010-01-24 22:59:10.474: [ default][1373676464][PANIC] OHASD exiting; Could not init OLR

或者

..
2010-01-24 23:01:46.275: [  OCROSD][1228334000]utread:3: Problem reading buffer 1907f000 buflen 4096 retval 0 phy_offset 102400 retry 5
2010-01-24 23:01:46.275: [  OCRRAW][1228334000]propriogid:1_1: Failed to read the whole bootblock. Assumes invalid format.
2010-01-24 23:01:46.275: [  OCRRAW][1228334000]proprioini: all disks are not OCR/OLR formatted
2010-01-24 23:01:46.275: [  OCRRAW][1228334000]proprinit: Could not open raw device
2010-01-24 23:01:46.275: [  OCRAPI][1228334000]a_init:16!: Backend init unsuccessful : [26]
2010-01-24 23:01:46.276: [  CRSOCR][1228334000] OCR context init failure.  Error: PROCL-26: Error while accessing the physical storage
2010-01-24 23:01:46.276: [ default][1228334000] OLR initalization failured, rc=26
2010-01-24 23:01:46.276: [ default][1228334000]Created alert : (:OHAS00106:) :  Failed to initialize Oracle Local Registry
2010-01-24 23:01:46.277: [ default][1228334000][PANIC] OHASD exiting; Could not init OLR

或者

..
2010-11-07 03:00:08.932: [ default][1] Created alert : (:OHAS00102:) : OHASD is not running as privileged user
2010-11-07 03:00:08.932: [ default][1][PANIC] OHASD exiting: must be run as privileged user

或者

ohasd.bin comes up but output of "crsctl stat res -t -init"shows no resource, and "ocrconfig -local -manualbackup" fails

或者

..

2010-08-04 13:13:11.102: [   CRSPE][35] Resources parsed
2010-08-04 13:13:11.103: [   CRSPE][35] Server [] has been registered with the PE data model
2010-08-04 13:13:11.103: [   CRSPE][35] STARTUPCMD_REQ = false:
2010-08-04 13:13:11.103: [   CRSPE][35] Server [] has changed state from [Invalid/unitialized] to [VISIBLE]
2010-08-04 13:13:11.103: [  CRSOCR][31] Multi Write Batch processing...
2010-08-04 13:13:11.103: [ default][35] Dump State Starting ...

..

2010-08-04 13:13:11.112: [   CRSPE][35] SERVERS:

:VISIBLE:address{{Absolute|Node:0|Process:-1|Type:1}}; recovered state:VISIBLE. Assigned to no pool

------------- SERVER POOLS:
Free [min:0][max:-1][importance:0] NO SERVERS ASSIGNED

2010-08-04 13:13:11.113: [   CRSPE][35] Dumping ICE contents...:ICE operation count: 0
2010-08-04 13:13:11.113: [ default][35] Dump State Done.

解决办法就是使用下面的命令，恢复一个好的备份 “ocrconfig -local -restore <ocr_backup_name>”。

默认情况下，OLR 在系统安装结束后会自动的备份在 $GRID_HOME/cdata/$HOST/backup_$TIME_STAMP.olr 。

7. ohasd.bin可以正常的访问到网络的 socket 文件:

2010-06-29 10:31:01.570: [ COMMCRS][1206901056]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=procr_local_conn_0_PROL))

2010-06-29 10:31:01.571: [  OCRSRV][1217390912]th_listen: CLSCLISTEN failed clsc_ret= 3, addr= [(ADDRESS=(PROTOCOL=ipc)(KEY=procr_local_conn_0_PROL))]
2010-06-29 10:31:01.571: [  OCRSRV][3267002960]th_init: Local listener did not reach valid state

在 Grid Infrastructure 环境中，和 ohasd 有关的 socket 文件属主应该是 root 用户，但是在 Oracle Restart 的环境中，他们应该是属于 grid 用户的，关于更多的关于网络 socket 文件权限和属主，请参考章节”网络 socket 文件，属主和权限” 给出的例子.

8. ohasd.bin 能够访问日志文件的位置:

OS messages/syslog 显示以下信息:

Feb 20 10:47:08 racnode1 OHASD[9566]: OHASD exiting; Directory /ocw/grid/log/racnode1/ohasd not found.

请参考章节”日志位置, 属主和权限”部分的例子，并确定这些必要的目录是否有丢失的，并且是按照正确的权限和属主创建的。

9. 节点启动后，在 SUSE Linux 的系统上，ohasd 可能无法启动，此问题请参考 note 1325718.1 – OHASD not Starting After Reboot on SLES

10. OHASD 无法启动，使用 “ps -ef| grep ohasd.bin” 显示 ohasd.bin 的进程已经启动，但是 $GRID_HOME/log/<node>/ohasd/ohasd.log 在好几分钟之后都没有任何信息更新,使用 OS 的 truss 工具可以看到该进程一致在循环的执行关闭从未被打开的文件句柄的操作:

..
15058/1:         0.1995 close(2147483646)                               Err#9 EBADF
15058/1:         0.1996 close(2147483645)                               Err#9 EBADF
..

通过 ohasd.bin 的 Call stack ，可以看到以下信息:

_close  sclssutl_closefiledescriptors  main ..

这是由于 bug 11834289 导致的，该问题在 11.2.0.3 和之上的版本已经被修复,该 bug 的其它症状还有：集群的进程无法启动，而且做 call stack 和 truss 查看的时候也会看到相同的情况(循环的执行 OS 函数 “close”) . 如果该 bug 发生在启动其它的资源时，我们会看到错误信息： “CRS-5802: Unable to start the agent process” 提示。

11. 其它的一些潜在的原因和解决办法请参见 note 1069182.1 – OHASD Failed to Start: Inappropriate ioctl for device

12. ohasd.bin 正常启动，但是, “crsctl check crs” 只显示以下一行信息:

CRS-4638: Oracle High Availability Services is online

并且命令 “crsctl stat res -p -init” 无法显示任何信息

这个问题是由于 OLR 损坏导致的，请参考 note 1193643.1 进行恢复。

13. EL7/OL7上: note 1959008.1 – Install of Clusterware fails while running root.sh on OL7 – ohasd fails to start

14. 对于 EL7/OL7, patch 25606616 is needed: TRACKING BUG TO PROVIDE GI FIXES FOR OL7

15. 如果 ohasd 仍然无法启动，请参见 ohasd 的日志 <grid-home>/log/<nodename>/ohasd/ohasd.log 和 ohasdOUT.log 来获取更多的信息；

问题 2: OHASD Agents 未启动

OHASD.BIN 会启动 4 个 agents/monitors 来启动其它的资源:

oraagent: 负责启动 ora.asm, ora.evmd, ora.gipcd, ora.gpnpd, ora.mdnsd 等
orarootagent: 负责启动 ora.crsd, ora.ctssd, ora.diskmon, ora.drivers.acfs 等
cssdagent / cssdmonitor: 负责启动 ora.cssd(对应 ocssd.bin) 和 ora.cssdmonitor(对应 cssdmonitor)

如果 ohasd.bin 不能正常地启动以上任何一个 agents，集群都无法运行在正常的状态。

1. 通常情况下，agents 无法启动的原因是 agent 的日志或者日志所在的目录没有正确设置属主和权限。

关于日志文件和文件夹的权限和属主设置，请参见章节 “日志文件位置, 属主和权限” 中的介绍。

一个例子是在手工打补丁时忘记执行 “rootcrs.pl -patch/postpatch” 会导致agent启动失败:

2015-02-25 15:43:54.350806 : CRSMAIN:3294918400: {0:0:2} {0:0:2} Created alert : (:CRSAGF00123:) : Failed to start the agent process: /ocw/grid/bin/orarootagent Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/ocw/grid/bin/orarootagent]

2015-02-25 15:43:54.382154 : CRSMAIN:3294918400: {0:0:2} {0:0:2} Created alert : (:CRSAGF00123:) : Failed to start the agent process: /ocw/grid/bin/cssdagent Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/ocw/grid/bin/cssdagent]

2015-02-25 15:43:54.384105 : CRSMAIN:3294918400: {0:0:2} {0:0:2} Created alert : (:CRSAGF00123:) : Failed to start the agent process: /ocw/grid/bin/cssdmonitor Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/ocw/grid/bin/cssdmonitor]

解决方案是执行缺失的步骤。

2. 如果 agent 的二进制文件（oraagent.bin 或者 orarootagent.bin 等）损坏, agent 也将无法启动，从而导致相关的资源也无法启动：

2011-05-03 11:11:13.189

[ohasd(25303)]CRS-5828:Could not start agent '/ocw/grid/bin/orarootagent_grid'. Details at (:CRSAGF00130:) {0:0:2} in /ocw/grid/log/racnode1/ohasd/ohasd.log.

2011-05-03 12:03:17.491: [    AGFW][1117866336] {0:0:184} Created alert : (:CRSAGF00130:) :  Failed to start the agent /ocw/grid/bin/orarootagent_grid
2011-05-03 12:03:17.491: [    AGFW][1117866336] {0:0:184} Agfw Proxy Server sending the last reply to PE for message:RESOURCE_START[ora.diskmon 1 1] ID 4098:403
2011-05-03 12:03:17.491: [    AGFW][1117866336] {0:0:184} Can not stop the agent: /ocw/grid/bin/orarootagent_grid because pid is not initialized
..
2011-05-03 12:03:17.492: [   CRSPE][1128372576] {0:0:184} Fatal Error from AGFW Proxy: Unable to start the agent process
2011-05-03 12:03:17.492: [   CRSPE][1128372576] {0:0:184} CRS-2674: Start of 'ora.diskmon' on 'racnode1' failed

..

2011-06-27 22:34:57.805: [    AGFW][1131669824] {0:0:2} Created alert : (:CRSAGF00123:) :  Failed to start the agent process: /ocw/grid/bin/cssdagent Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/ocw/grid/bin/cssdagent]
2011-06-27 22:34:57.805: [    AGFW][1131669824] {0:0:2} Created alert : (:CRSAGF00126:) :  Agent start failed
..
2011-06-27 22:34:57.806: [    AGFW][1131669824] {0:0:2} Created alert : (:CRSAGF00123:) :  Failed to start the agent process: /ocw/grid/bin/cssdmonitor Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/ocw/grid/bin/cssdmonitor]

解决办法：您可以和正常节点上的 agent 文件进行比较，并且恢复一个好的副本回来。

3. Agent 可能会因为 bug 11834289 而启动失败，伴有错误 “CRS-5802: Unable to start the agent process”, 参考 “OHASD 无法启动”的第10条

4. 参考: note 1964240.1 – CRS-5823:Could not initialize agent framework

问题 3: OCSSD.BIN 无法启动

cssd.bin 的正常启动依赖于以下几个必要的条件:

1. GPnP profile 可正常读写 – gpnpd 需要完全正常启动来为profile服务。

如果 ocssd.bin 能够正常的获取 profile，通常情况下，我们会在 ocssd.log 中看到以下类似的信息：

2010-02-02 18:00:16.251: [    GPnP][408926240]clsgpnpm_exchange: [at clsgpnpm.c:1175] Calling "ipc://GPNPD_rac1", try 4 of 500...
2010-02-02 18:00:16.263: [    GPnP][408926240]clsgpnp_profileVerifyForCall: [at clsgpnp.c:1867] Result: (87) CLSGPNP_SIG_VALPEER. Profile verified.  prf=0x165160d0
2010-02-02 18:00:16.263: [    GPnP][408926240]clsgpnp_profileGetSequenceRef: [at clsgpnp.c:841] Result: (0) CLSGPNP_OK. seq of p=0x165160d0 is '6'=6
2010-02-02 18:00:16.263: [    GPnP][408926240]clsgpnp_profileCallUrlInt: [at clsgpnp.c:2186] Result: (0) CLSGPNP_OK. Successful get-profile CALL to remote "ipc://GPNPD_rac1" disco ""

否则，我们会看到以下信息显示在 ocssd.log 中。

2010-02-03 22:26:17.057: [    GPnP][3852126240]clsgpnpm_connect: [at clsgpnpm.c:1100] GIPC gipcretConnectionRefused (29) gipcConnect(ipc-ipc://GPNPD_rac1)
2010-02-03 22:26:17.057: [    GPnP][3852126240]clsgpnpm_connect: [at clsgpnpm.c:1101] Result: (48) CLSGPNP_COMM_ERR. Failed to connect to call url "ipc://GPNPD_rac1"
2010-02-03 22:26:17.057: [    GPnP][3852126240]clsgpnp_getProfileEx: [at clsgpnp.c:546] Result: (13) CLSGPNP_NO_DAEMON. Can't get GPnP service profile from local GPnP daemon
2010-02-03 22:26:17.057: [ default][3852126240]Cannot get GPnP profile. Error CLSGPNP_NO_DAEMON (GPNPD daemon is not running).
2010-02-03 22:26:17.057: [    CSSD][3852126240]clsgpnp_getProfile failed, rc(13)

解决方案是确保 gpnpd 是启动并且正常运行的。

2. Voting Disk 可以正常读写

在 11gR2 的版本中， ocssd.bin 通过 GPnP profile 中的记录获取 Voting disk 的信息, 如果没有足够多的选举盘是可读写的，那么 ocssd.bin 会终止掉自己。

2010-02-03 22:37:22.212: [    CSSD][2330355744]clssnmReadDiscoveryProfile: voting file discovery string(/share/storage/di*)
..
2010-02-03 22:37:22.227: [    CSSD][1145538880]clssnmvDiskVerify: Successful discovery of 0 disks
2010-02-03 22:37:22.227: [    CSSD][1145538880]clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2010-02-03 22:37:22.227: [    CSSD][1145538880]clssnmvFindInitialConfigs: No voting files found
2010-02-03 22:37:22.228: [    CSSD][1145538880]###################################
2010-02-03 22:37:22.228: [    CSSD][1145538880]clssscExit: CSSD signal 11 in thread clssnmvDDiscThread

如果所有节点上的 ocssd.bin 因为以下错误无法启动，这是因为 voting file 正在被修改:

2010-05-02 03:11:19.033: [ CSSD][1197668093]clssnmCompleteInitVFDiscovery: Detected voting file add in progress for CIN 0:1134513465:0, waiting for configuration to complete 0:1134513098:0

解决的办法是，参照 note 1364971.1 中的步骤，以 exclusive 模式启动 ocssd.bin。

如果选举盘的位置是非 ASM 的设备，它的权限和属主应该是如下显示：

-rw-r----- 1 ogrid oinstall 21004288 Feb  4 09:13 votedisk1

3. 网络功能是正常的，并且域名解析能够正常工作:

如果 ocssd.bin 无法正常的绑定到任何网络上，我们会在 ocssd.log 中看到以下类似的日志信息：

2010-02-03 23:26:25.804: [GIPCXCPT][1206540320]gipcmodGipcPassInitializeNetwork: failed to find any interfaces in clsinet, ret gipcretFail (1)
2010-02-03 23:26:25.804: [GIPCGMOD][1206540320]gipcmodGipcPassInitializeNetwork: EXCEPTION[ ret gipcretFail (1) ]  failed to determine host from clsinet, using default
..
2010-02-03 23:26:25.810: [    CSSD][1206540320]clsssclsnrsetup: gipcEndpoint failed, rc 39
2010-02-03 23:26:25.811: [    CSSD][1206540320]clssnmOpenGIPCEndp: failed to listen on gipc addr gipc://rac1:nm_eotcs- ret 39
2010-02-03 23:26:25.811: [    CSSD][1206540320]clssscmain: failed to open gipc endp

如果私网上出现了联通性的故障（包含多播功能关闭），我们会在 ocssd.log 中看到以下类似的日志信息：

2010-09-20 11:52:54.014: [    CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 453, LATS 328297844, lastSeqNo 452, uniqueness 1284979488, timestamp 1284979973/329344894
2010-09-20 11:52:54.016: [    CSSD][1078421824]clssgmWaitOnEventValue: after CmInfo State  val 3, eval 1 waited 0
..  >>>> after a long delay
2010-09-20 12:02:39.578: [    CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 1037, LATS 328883434, lastSeqNo 1036, uniqueness 1284979488, timestamp 1284980558/329930254
2010-09-20 12:02:39.895: [    CSSD][1107286336]clssgmExecuteClientRequest: MAINT recvd from proc 2 (0xe1ad870)
2010-09-20 12:02:39.895: [    CSSD][1107286336]clssgmShutDown: Received abortive shutdown request from client.
2010-09-20 12:02:39.895: [    CSSD][1107286336]###################################
2010-09-20 12:02:39.895: [    CSSD][1107286336]clssscExit: CSSD aborting from thread GMClientListener
2010-09-20 12:02:39.895: [    CSSD][1107286336]###################################

验证网络是否正常，请参见：note 1054902.1

如果在网络修改后CSSD不能启动，请使用 (“gpnptool get”) 检查gpnp profile里定义的cluster_interconnect和真正的网卡名字是否一致
在11.2.0.1上，如果私网不可用，ocssd.bin可能会使用公网

4. 第三方的集群管理软件是启动的 (如果使用了第三方 clusterware)

Grid Infrastructure 可以提供所有的集群功能，不需要安装第三方集群软件。但是如果在您的环境里GI是基于第三方的集群管理软件的，那么需要确保CRS启动前第三方的集群管理软件已经启动了，可以使用grid用户执行下面的命令来验证

$GRID_HOME/bin/lsnodes -n
racnode1    1
racnode1    0

如果第三方的集群管理软件没有完全正常启动，我们在 ocssd.log 中看到以下类似的日志信息：

2010-08-30 18:28:13.207: [    CSSD][36]clssnm_skgxninit: skgxncin failed, will retry
2010-08-30 18:28:14.207: [    CSSD][36]clssnm_skgxnmon: skgxn init failed
2010-08-30 18:28:14.208: [    CSSD][36]###################################
2010-08-30 18:28:14.208: [    CSSD][36]clssscExit: CSSD signal 11 in thread skgxnmon

未安装集群管理软件之前，请使用 grid 用户执行以下操作验证:

$INSTALL_SOURCE/install/lsnodes -v

hp-ux上的一个案例: note 2130230.1 – Grid infrastructure startup fails due to vendor Clusterware did not start (HP-UX Service guard)

5. 在错误的 GRID_HOME 下执行命令”crsctl”

命令”crsctl” 必须在正确的 GRID_HOME 下执行，才能正常启动其它进程,否则我们会看到以下的错误信息提示：

2012-11-14 10:21:44.014: [    CSSD][1086675264]ASSERT clssnm1.c 3248
2012-11-14 10:21:44.014: [    CSSD][1086675264](:CSSNM00056:)clssnmvStartDiscovery: Terminating because of the release version(11.2.0.2.0) of this node being lesser than the active version(11.2.0.3.0) that the cluster is at
2012-11-14 10:21:44.014: [    CSSD][1086675264]###################################
2012-11-14 10:21:44.014: [    CSSD][1086675264]clssscExit: CSSD aborting from thread clssnmvDDiscThread#

问题 4: CRSD.BIN 无法启动

如果”crsctl stat res -t -init”显示 ora.crsd 处于intermediate状态，并且另一个节点正在运行着，那么很可能原因是当前这个节点的crsd.bin无法和另一个节点的master crsd.bin通信。
此时，master crsd.bin很可能有异常，杀掉那个master crsd.bin很可能解决问题。
执行 “grep MASTER crsd.trc” 来找到master crsd.bin在哪个节点运行，杀掉那个节点的crsd.bin
之后crsd.bin会被自动启动，不过其它节点的crsd.bin会变成master crsd.bin

crsd.bin 的正常启动依赖于以下几个必要的条件:

1. ocssd 已经完全正常启动

如果 ocssd.bin 没有完全正常启动，我们会在 crsd.log 中看到以下提示信息:

2010-02-03 22:37:51.638: [ CSSCLNT][1548456880]clssscConnect: gipc request failed with 29 (0x16)
2010-02-03 22:37:51.638: [ CSSCLNT][1548456880]clsssInitNative: connect failed, rc 29
2010-02-03 22:37:51.639: [  CRSRTI][1548456880] CSS is not ready. Received status 3 from CSS. Waiting for good status ..

2. OCR 可以正常读写

如果 OCR 保存在 ASM 中,那么 ora.asm 资源(ASM 实例) 必须已经启动而且 OCR 所在的磁盘组必须已经被挂载,否则我们在 crsd.log 会看到以下的类似信息：

2010-02-03 22:22:55.186: [  OCRASM][2603807664]proprasmo: Error in open/create file in dg [GI]

[  OCRASM][2603807664]SLOS : SLOS: cat=7, opn=kgfoAl06, dep=15077, loc=kgfokge

ORA-15077: could not locate ASM instance serving a required diskgroup

2010-02-03 22:22:55.189: [  OCRASM][2603807664]proprasmo: kgfoCheckMount returned [7]
2010-02-03 22:22:55.189: [  OCRASM][2603807664]proprasmo: The ASM instance is down
2010-02-03 22:22:55.190: [  OCRRAW][2603807664]proprioo: Failed to open [+GI]. Returned proprasmo() with [26]. Marking location as UNAVAILABLE.
2010-02-03 22:22:55.190: [  OCRRAW][2603807664]proprioo: No OCR/OLR devices are usable
2010-02-03 22:22:55.190: [  OCRASM][2603807664]proprasmcl: asmhandle is NULL
2010-02-03 22:22:55.190: [  OCRRAW][2603807664]proprinit: Could not open raw device
2010-02-03 22:22:55.190: [  OCRASM][2603807664]proprasmcl: asmhandle is NULL
2010-02-03 22:22:55.190: [  OCRAPI][2603807664]a_init:16!: Backend init unsuccessful : [26]
2010-02-03 22:22:55.190: [  CRSOCR][2603807664] OCR context init failure.  Error: PROC-26: Error while accessing the physical storage ASM error [SLOS: cat=7, opn=kgfoAl06, dep=15077, loc=kgfokge
ORA-15077: could not locate ASM instance serving a required diskgroup] [7]

2010-02-03 22:22:55.190: [    CRSD][2603807664][PANIC] CRSD exiting: Could not init OCR, code: 26

注意：在11.2 的版本中 ASM 会比 crsd.bin 先启动，并且会把含有 OCR 的磁盘组自动挂载。

如果您的 OCR 在非 ASM 的存储中，该文件的属主和权限如下：

-rw-r----- 1 root  oinstall  272756736 Feb  3 23:24 ocr

如果 OCR 是在非 ASM 的存储中，并且不能被正常访问，在 crsd.log 会看到以下的类似信息

2010-02-03 23:14:33.583: [  OCROSD][2346668976]utopen:7:failed to open any OCR file/disk, errno=2, os err string=No such file or directory
2010-02-03 23:14:33.583: [  OCRRAW][2346668976]proprinit: Could not open raw device
2010-02-03 23:14:33.583: [ default][2346668976]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:14:34.587: [  OCROSD][2346668976]utopen:6m':failed in stat OCR file/disk /share/storage/ocr, errno=2, os err string=No such file or directory
2010-02-03 23:14:34.587: [  OCROSD][2346668976]utopen:7:failed to open any OCR file/disk, errno=2, os err string=No such file or directory
2010-02-03 23:14:34.587: [  OCRRAW][2346668976]proprinit: Could not open raw device
2010-02-03 23:14:34.587: [ default][2346668976]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:14:35.589: [    CRSD][2346668976][PANIC] CRSD exiting: OCR device cannot be initialized, error: 1:26

如果 OCR 是坏掉了，在 crsd.log 会看到以下的类似信息:

2010-02-03 23:19:38.417: [ default][3360863152]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:19:39.429: [  OCRRAW][3360863152]propriogid:1_2: INVALID FORMAT
2010-02-03 23:19:39.429: [  OCRRAW][3360863152]proprioini: all disks are not OCR/OLR formatted
2010-02-03 23:19:39.429: [  OCRRAW][3360863152]proprinit: Could not open raw device
2010-02-03 23:19:39.429: [ default][3360863152]a_init:7!: Backend init unsuccessful : [26]
2010-02-03 23:19:40.432: [    CRSD][3360863152][PANIC] CRSD exiting: OCR device cannot be initialized, error: 1:26

如果您的 grid 用户的权限或者所在组发生了变化，尽管 ASM 还是可以访问的，在 crsd.log 会看到以下的类似信息:

2010-03-10 11:45:12.510: [  OCRASM][611467760]proprasmo: Error in open/create file in dg [SYSTEMDG]

[  OCRASM][611467760]SLOS : SLOS: cat=7, opn=kgfoAl06, dep=1031, loc=kgfokge

ORA-01031: insufficient privileges

2010-03-10 11:45:12.528: [  OCRASM][611467760]proprasmo: kgfoCheckMount returned [7]
2010-03-10 11:45:12.529: [  OCRASM][611467760]proprasmo: The ASM instance is down
2010-03-10 11:45:12.529: [  OCRRAW][611467760]proprioo: Failed to open [+SYSTEMDG]. Returned proprasmo() with [26]. Marking location as UNAVAILABLE.
2010-03-10 11:45:12.529: [  OCRRAW][611467760]proprioo: No OCR/OLR devices are usable
2010-03-10 11:45:12.529: [  OCRASM][611467760]proprasmcl: asmhandle is NULL
2010-03-10 11:45:12.529: [  OCRRAW][611467760]proprinit: Could not open raw device
2010-03-10 11:45:12.529: [  OCRASM][611467760]proprasmcl: asmhandle is NULL
2010-03-10 11:45:12.529: [  OCRAPI][611467760]a_init:16!: Backend init unsuccessful : [26]
2010-03-10 11:45:12.530: [  CRSOCR][611467760] OCR context init failure.  Error: PROC-26: Error while accessing the physical storage ASM error [SLOS: cat=7, opn=kgfoAl06, dep=1031, loc=kgfokge
ORA-01031: insufficient privileges] [7]

如果grid用户无法写ORACLE_BASE目录，以及GRID_HOME 下的 oracle 二进制文件的属主或者权限错误，尽管 ASM 正常启动并运行，在 crsd.log 会看到以下的类似信息：

2012-03-04 21:34:23.139: [  OCRASM][3301265904]proprasmo: Error in open/create file in dg [OCR]

[  OCRASM][3301265904]SLOS : SLOS: cat=7, opn=kgfoAl06, dep=12547, loc=kgfokge

2012-03-04 21:34:23.139: [  OCRASM][3301265904]ASM Error Stack : ORA-12547: TNS:lost contact

2012-03-04 21:34:23.633: [  OCRASM][3301265904]proprasmo: kgfoCheckMount returned [7]
2012-03-04 21:34:23.633: [  OCRASM][3301265904]proprasmo: The ASM instance is down
2012-03-04 21:34:23.634: [  OCRRAW][3301265904]proprioo: Failed to open [+OCR]. Returned proprasmo() with [26]. Marking location as UNAVAILABLE.
2012-03-04 21:34:23.634: [  OCRRAW][3301265904]proprioo: No OCR/OLR devices are usable
2012-03-04 21:34:23.635: [  OCRASM][3301265904]proprasmcl: asmhandle is NULL
2012-03-04 21:34:23.636: [    GIPC][3301265904] gipcCheckInitialization: possible incompatible non-threaded init from [prom.c : 690], original from [clsss.c : 5326]
2012-03-04 21:34:23.639: [ default][3301265904]clsvactversion:4: Retrieving Active Version from local storage.
2012-03-04 21:34:23.643: [  OCRRAW][3301265904]proprrepauto: The local OCR configuration matches with the configuration published by OCR Cache Writer. No repair required.
2012-03-04 21:34:23.645: [  OCRRAW][3301265904]proprinit: Could not open raw device
2012-03-04 21:34:23.646: [  OCRASM][3301265904]proprasmcl: asmhandle is NULL
2012-03-04 21:34:23.650: [  OCRAPI][3301265904]a_init:16!: Backend init unsuccessful : [26]
2012-03-04 21:34:23.651: [  CRSOCR][3301265904] OCR context init failure.  Error: PROC-26: Error while accessing the physical storage
ORA-12547: TNS:lost contact

2012-03-04 21:34:23.652: [ CRSMAIN][3301265904] Created alert : (:CRSD00111:) :  Could not init OCR, error: PROC-26: Error while accessing the physical storage
ORA-12547: TNS:lost contact

2012-03-04 21:34:23.652: [    CRSD][3301265904][PANIC] CRSD exiting: Could not init OCR, code: 26

正常的 GRID_HOME 下该文件的属主和权限应该是如下显示：

-rwsr-s--x 1 grid oinstall 184431149 Feb  2 20:37 /ocw/grid/bin/oracle

如果 OCR 文件或者它的镜像文件无法正常访问 (可能是 ASM 已经启动, 但是 OCR/mirror 所在的磁盘组没有挂载),在 crsd.log 会看到以下的类似信息:

2010-05-11 11:16:38.578: [  OCRASM][18]proprasmo: Error in open/create file in dg [OCRMIR]
[  OCRASM][18]SLOS : SLOS: cat=8, opn=kgfoOpenFile01, dep=15056, loc=kgfokge
ORA-17503: ksfdopn:DGOpenFile05 Failed to open file +OCRMIR.255.4294967295
ORA-17503: ksfdopn:2 Failed to open file +OCRMIR.255.4294967295
ORA-15001: diskgroup "OCRMIR
..
2010-05-11 11:16:38.647: [  OCRASM][18]proprasmo: kgfoCheckMount returned [6]
2010-05-11 11:16:38.648: [  OCRASM][18]proprasmo: The ASM disk group OCRMIR is not found or not mounted
2010-05-11 11:16:38.648: [  OCRASM][18]proprasmdvch: Failed to open OCR location [+OCRMIR] error [26]
2010-05-11 11:16:38.648: [  OCRRAW][18]propriodvch: Error  [8] returned device check for [+OCRMIR]
2010-05-11 11:16:38.648: [  OCRRAW][18]dev_replace: non-master could not verify the new disk (8)
[  OCRSRV][18]proath_invalidate_action: Failed to replace [+OCRMIR] [8]
[  OCRAPI][18]procr_ctx_set_invalid_no_abort: ctx set to invalid
..
2010-05-11 11:16:46.587: [  OCRMAS][19]th_master:91: Comparing device hash ids between local and master failed
2010-05-11 11:16:46.587: [  OCRMAS][19]th_master:91 Local dev (1862408427, 1028247821, 0, 0, 0)
2010-05-11 11:16:46.587: [  OCRMAS][19]th_master:91 Master dev (1862408427, 1859478705, 0, 0, 0)
2010-05-11 11:16:46.587: [  OCRMAS][19]th_master:9: Shutdown CacheLocal. my hash ids don't match
[  OCRAPI][19]procr_ctx_set_invalid_no_abort: ctx set to invalid
[  OCRAPI][19]procr_ctx_set_invalid: aborting...
2010-05-11 11:16:46.587: [    CRSD][19] Dump State Starting ...

3. crsd.bin 的进程号文件（<GRID_HOME>/crs/init/<节点名>.pid）存在，但是却指向其它的进程

如果进程号文件不存在,在日志 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我们会看到以下的提示信息:

2010-02-14 17:40:57.927: [ora.crsd][1243486528] [check] PID FILE doesn't exist.
..
2010-02-14 17:41:57.927: [  clsdmt][1092499776]Creating PID [30269] file for home /ocw/grid host racnode1 bin crs to /ocw/grid/crs/init/
2010-02-14 17:41:57.927: [  clsdmt][1092499776]Error3 -2 writing PID [30269] to the file []
2010-02-14 17:41:57.927: [  clsdmt][1092499776]Failed to record pid for CRSD
2010-02-14 17:41:57.927: [  clsdmt][1092499776]Terminating process
2010-02-14 17:41:57.927: [ default][1092499776] CRSD exiting on stop request from clsdms_thdmai

解决办法，我们可以手工创建一个进程号文件：使用 grid 用户执行 “touch” 命令，然后重新启动 ora.crsd 资源。

如果进程号文件存在，但是记录的 PID 是指向了其它的进程，而不是 crsd.bin 的进程，在日志 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我们会看到以下的提示信息:

2011-04-06 15:53:38.777: [ora.crsd][1160390976] [check] PID will be looked for in /ocw/grid/crs/init/racnode1.pid
2011-04-06 15:53:38.778: [ora.crsd][1160390976] [check] PID which will be monitored will be 1535                               >> 1535 is output of "cat /ocw/grid/crs/init/racnode1.pid"
2011-04-06 15:53:38.965: [ COMMCRS][1191860544]clsc_connect: (0x2aaab400b0b0) no listener at (ADDRESS=(PROTOCOL=ipc)(KEY=racnode1DBG_CRSD))
[  clsdmc][1160390976]Fail to connect (ADDRESS=(PROTOCOL=ipc)(KEY=racnode1DBG_CRSD)) with status 9
2011-04-06 15:53:38.966: [ora.crsd][1160390976] [check] Error = error 9 encountered when connecting to CRSD
2011-04-06 15:53:39.023: [ora.crsd][1160390976] [check] Calling PID check for daemon
2011-04-06 15:53:39.023: [ora.crsd][1160390976] [check] Trying to check PID = 1535
2011-04-06 15:53:39.203: [ora.crsd][1160390976] [check] PID check returned ONLINE CLSDM returned OFFLINE
2011-04-06 15:53:39.203: [ora.crsd][1160390976] [check] DaemonAgent::check returned 5
2011-04-06 15:53:39.203: [    AGFW][1160390976] check for resource: ora.crsd 1 1 completed with status: FAILED
2011-04-06 15:53:39.203: [    AGFW][1170880832] ora.crsd 1 1 state changed from: UNKNOWN to: FAILED
..
2011-04-06 15:54:10.511: [    AGFW][1167522112] ora.crsd 1 1 state changed from: UNKNOWN to: CLEANING
..
2011-04-06 15:54:10.513: [ora.crsd][1146542400] [clean] Trying to stop PID = 1535
..
2011-04-06 15:54:11.514: [ora.crsd][1146542400] [clean] Trying to check PID = 1535

在 OS 层面检查该问题:

ls -l /ocw/grid/crs/init/*pid
-rwxr-xr-x 1 ogrid oinstall 5 Feb 17 11:00 /ocw/grid/crs/init/racnode1.pid
cat /ocw/grid/crs/init/*pid
1535
ps -ef| grep 1535
root      1535     1  0 Mar30 ?        00:00:00 iscsid                  >> 注意：进程 1535 不是 crsd.bin

解决办法是，使用 root 用户，创建一个空的进程号文件，然后重启资源 ora.crsd：

# > $GRID_HOME/crs/init/<racnode1>.pid
# $GRID_HOME/bin/crsctl stop res ora.crsd -init
# $GRID_HOME/bin/crsctl start res ora.crsd -init

4. 网络功能是正常的，并且域名解析能够正常工作：

如果网络功能不正常，ocssd.bin 进程仍然可能被启动, 但是 crsd.bin 可能会失败，同时在 crsd.log 中会提示以下信息:

2010-02-03 23:34:28.412: [    GPnP][2235814832]clsgpnp_Init: [at clsgpnp0.c:837] GPnP client pid=867, tl=3, f=0
2010-02-03 23:34:28.428: [  OCRAPI][2235814832]clsu_get_private_ip_addresses: no ip addresses found.
..
2010-02-03 23:34:28.434: [  OCRAPI][2235814832]a_init:13!: Clusterware init unsuccessful : [44]
2010-02-03 23:34:28.434: [  CRSOCR][2235814832] OCR context init failure.  Error: PROC-44: Error in network address and interface operations Network address and interface operations error [7]
2010-02-03 23:34:28.434: [    CRSD][2235814832][PANIC] CRSD exiting: Could not init OCR, code: 44

或者:

2009-12-10 06:28:31.974: [  OCRMAS][20]proath_connect_master:1: could not connect to master  clsc_ret1 = 9, clsc_ret2 = 9
2009-12-10 06:28:31.974: [  OCRMAS][20]th_master:11: Could not connect to the new master
2009-12-10 06:29:01.450: [ CRSMAIN][2] Policy Engine is not initialized yet!
2009-12-10 06:29:31.489: [ CRSMAIN][2] Policy Engine is not initialized yet!

或者:

2009-12-31 00:42:08.110: [ COMMCRS][10]clsc_receive: (102b03250) Error receiving, ns (12535, 12560), transport (505, 145, 0)

关于网络和域名解析的验证，请参考：note 1054902.1

5. crsd 可执行文件(crsd.bin 和 crsd in GRID_HOME/bin) 的权限或者属主正确并且没有进行过手工的修改, 一个简单可行的检查办法是对比好的节点和坏节点的以下命令输出 “ls -l <grid-home>/bin/crsd <grid-home>/bin/crsd.bin”.

6. crsd可能因为下面的原因无法启动

note 1552472.1 -CRSD Will Not Start Following a Node Reboot: crsd.log reports: clsclisten: op 65 failed and/or Unable to get E2E port
note 1684332.1 - GI crsd Fails to Start: clsclisten: op 65 failed, NSerr (12560, 0), transport: (583, 0, 0)

7. 关于CRSD进程启动问题的进一步深入诊断，请参考 note 1323698.1 – Troubleshooting CRSD Start up Issue

问题 5: GPNPD.BIN 无法启动

1. 网络的域名解析不正常

gpnpd.bin 进程启动失败，以下信息提示在 gpnpd.log 中:

2010-05-13 12:48:11.540: [    GPnP][1171126592]clsgpnpm_exchange: [at clsgpnpm.c:1175] Calling "tcp://node2:9393", try 1 of 3...
2010-05-13 12:48:11.540: [    GPnP][1171126592]clsgpnpm_connect: [at clsgpnpm.c:1015] ENTRY
2010-05-13 12:48:11.541: [    GPnP][1171126592]clsgpnpm_connect: [at clsgpnpm.c:1066] GIPC gipcretFail (1) gipcConnect(tcp-tcp://node2:9393)
2010-05-13 12:48:11.541: [    GPnP][1171126592]clsgpnpm_connect: [at clsgpnpm.c:1067] Result: (48) CLSGPNP_COMM_ERR. Failed to connect to call url "tcp://node2:9393"

以上的例子，请确定当前节点能够正常的 ping 到“node2” ，并且确认两个节点之间没有任何防火墙。

2. bug 10105195

由于 bug 10105195, gpnp 的调度线程（dispatch thread）可能被阻断，例如：网络扫描。这个 bug 在 11.2.0.2 GI PSU2，11.2.0.3 及以上版本被修复，具体信息，请参见 note 10105195.8。

问题 6: 其它的一些守护进程无法启动

常见原因:

1. 守护进程的日志文件或者日志所在的路径权限或者属主不正确。

如果日志文件或者日志文件所在的路径权限或者属主设置有问题，通常我们会看到进程尝试启动，但是日志里的信息却始终没有更新.

关于日志位置和权限属主的限制，请参见 “日志文件位置, 属主和权限” 获取更多的信息。

2. 网络的 socket 文件权限或者属主错误

这种情况下，守护进程的日志会显示以下信息:

2010-02-02 12:55:20.485: [ COMMCRS][1121433920]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=rac1DBG_GIPCD))

2010-02-02 12:55:20.485: [  clsdmt][1110944064]Fail to listen to (ADDRESS=(PROTOCOL=ipc)(KEY=rac1DBG_GIPCD))

3. OLR 文件损坏

这种情况下，守护进程的日志会显示以下信息(以下是个 ora.ctssd 无法启动的例子):

2012-07-22 00:15:16.565: [ default][1]clsvactversion:4: Retrieving Active Version from local storage.
2012-07-22 00:15:16.575: [    CTSS][1]clsctss_r_av3: Invalid active version [] retrieved from OLR. Returns [19].
2012-07-22 00:15:16.585: [    CTSS][1](:ctss_init16:): Error [19] retrieving active version. Returns [19].
2012-07-22 00:15:16.585: [    CTSS][1]ctss_main: CTSS init failed [19]
2012-07-22 00:15:16.585: [    CTSS][1]ctss_main: CTSS daemon aborting [19].
2012-07-22 00:15:16.585: [    CTSS][1]CTSS daemon aborting

解决办法，请恢复一个好的OLR的副本，具体办法请参见 note 1193643.1

4. 其它情况:

note 1087521.1 – CTSS Daemon Aborting With “op 65 failed, NSerr (12560, 0), transport: (583, 0, 0)”

问题 7: CRSD Agents 无法启动

CRSD.BIN 会负责衍生出两个 agents 进程来启动用户的资源，这两个 agents 的名字和 ohasd.bin 的 agents 的名字相同：

orarootagent: 负责启动 ora.netn.network, ora.nodename.vip, ora.scann.vip 和 ora.gns
oraagent: 负责启动 ora.asm, ora.eons, ora.ons, listener, SCAN listener, diskgroup, database, service 等资源

我们可以通过以下命令查看用户的资源状态:

$GRID_HOME/crsctl stat res -t

如果 crsd.bin 无法正常启动以上任何一个 agent，用户的资源都将无法正常启动.

1. 通常这些 agent 无法启动的常见原因是 agent 的日志或者日志所在的路径没有设置合适的权限或者属主。

请参见以下 “日志文件位置, 属主和权限” 部分关于日志权限的设置。

2. agent 可能因为 bug 11834289 无法启动，此时我们会看到 “CRS-5802: Unable to start the agent process”错误信息，请参见 “OHASD 无法启动” #10 获取更多信息。

问题 8: HAIP 无法启动

HAIP 无法启动的原因有很多,例如：

[ohasd(891)]CRS-2807:Resource ‘ora.cluster_interconnect.haip’ failed to start automatically.

请参见 note 1210883.1 获取更多关于 HAIP 的信息。

网络和域名解析的验证

CRS 的启动，依赖于网络功能和域名解析的正常工作，如果网络功能或者域名解析不能正常工作，CRS 将无法正常启动。

关于网络和域名解析的验证，请参考： note 1054902.1

日志文件位置, 属主和权限

正确的设置 $GRID_HOME/log 和这里的子目录以及文件对 CRS 组件的正常启动是至关重要的。

在 Grid Infrastructure 的环境中:

我们假设一个 Grid Infrastructure 环境，节点名字为 rac1, CRS 的属主是 grid, 并且有两个单独的 RDBMS 属主分别为： rdbmsap 和 rdbmsar，以下是 $GRID_HOME/log 中正常的设置情况:

drwxrwxr-x 5 grid oinstall 4096 Dec  6 09:20 log
drwxr-xr-x  2 grid oinstall 4096 Dec  6 08:36 crs
drwxr-xr-t 17 root   oinstall 4096 Dec  6 09:22 rac1
drwxr-x--- 2 grid oinstall  4096 Dec  6 09:20 admin
drwxrwxr-t 4 root   oinstall  4096 Dec  6 09:20 agent
drwxrwxrwt 7 root    oinstall 4096 Jan 26 18:15 crsd
drwxr-xr-t 2 grid  oinstall 4096 Dec  6 09:40 application_grid
drwxr-xr-t 2 grid  oinstall 4096 Jan 26 18:15 oraagent_grid
drwxr-xr-t 2 rdbmsap oinstall 4096 Jan 26 18:15 oraagent_rdbmsap
drwxr-xr-t 2 rdbmsar oinstall 4096 Jan 26 18:15 oraagent_rdbmsar
drwxr-xr-t 2 grid  oinstall 4096 Jan 26 18:15 ora_oc4j_type_grid
drwxr-xr-t 2 root    root     4096 Jan 26 20:09 orarootagent_root
drwxrwxr-t 6 root oinstall 4096 Dec  6 09:24 ohasd
drwxr-xr-t 2 grid oinstall 4096 Jan 26 18:14 oraagent_grid
drwxr-xr-t 2 root   root     4096 Dec  6 09:24 oracssdagent_root
drwxr-xr-t 2 root   root     4096 Dec  6 09:24 oracssdmonitor_root
drwxr-xr-t 2 root   root     4096 Jan 26 18:14 orarootagent_root
-rw-rw-r-- 1 root root     12931 Jan 26 21:30 alertrac1.log
drwxr-x--- 2 grid oinstall  4096 Jan 26 20:44 client
drwxr-x--- 2 root oinstall  4096 Dec  6 09:24 crsd
drwxr-x--- 2 grid oinstall  4096 Dec  6 09:24 cssd
drwxr-x--- 2 root oinstall  4096 Dec  6 09:24 ctssd
drwxr-x--- 2 grid oinstall  4096 Jan 26 18:14 diskmon
drwxr-x--- 2 grid oinstall  4096 Dec  6 09:25 evmd
drwxr-x--- 2 grid oinstall  4096 Jan 26 21:20 gipcd
drwxr-x--- 2 root oinstall  4096 Dec  6 09:20 gnsd
drwxr-x--- 2 grid oinstall  4096 Jan 26 20:58 gpnpd
drwxr-x--- 2 grid oinstall  4096 Jan 26 21:19 mdnsd
drwxr-x--- 2 root oinstall  4096 Jan 26 21:20 ohasd
drwxrwxr-t 5 grid oinstall  4096 Dec  6 09:34 racg
drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgeut
drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgevtf
drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgmain
drwxr-x--- 2 grid oinstall  4096 Jan 26 20:57 srvm

请注意，绝大部分的子目录都继承了父目录的属主和权限，以上仅作为一个参考，来判断 CRS HOME 中是否有一些递归的权限和属主改变，如果您已经有一个相同版本的正在运行的工作节点，您可以把该运行的节点作为参考。

在 Oracle Restart 的环境中:

这里显示了在 Oracle Restart 环境中 $GRID_HOME/log 目录下的权限和属主设置:

drwxrwxr-x 5 grid oinstall 4096 Oct 31  2009 log
drwxr-xr-x  2 grid oinstall 4096 Oct 31  2009 crs
drwxr-xr-x  3 grid oinstall 4096 Oct 31  2009 diag
drwxr-xr-t 17 root   oinstall 4096 Oct 31  2009 rac1
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 admin
drwxrwxr-t 4 root   oinstall  4096 Oct 31  2009 agent
drwxrwxrwt 2 root oinstall 4096 Oct 31  2009 crsd
drwxrwxr-t 8 root oinstall 4096 Jul 14 08:15 ohasd
drwxr-xr-x 2 grid oinstall 4096 Aug  5 13:40 oraagent_grid
drwxr-xr-x 2 grid oinstall 4096 Aug  2 07:11 oracssdagent_grid
drwxr-xr-x 2 grid oinstall 4096 Aug  3 21:13 orarootagent_grid
-rwxr-xr-x 1 grid oinstall 13782 Aug  1 17:23 alertrac1.log
drwxr-x--- 2 grid oinstall  4096 Nov  2  2009 client
drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 crsd
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 cssd
drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 ctssd
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 diskmon
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 evmd
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 gipcd
drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 gnsd
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 gpnpd
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 mdnsd
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 ohasd
drwxrwxr-t 5 grid oinstall  4096 Oct 31  2009 racg
drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgeut
drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgevtf
drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgmain
drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 srvm

对于12.1.0.2及以上版本，参考 note 1915729.1 – Oracle Clusterware Diagnostic and Alert Log Moved to ADR

网络socket文件的位置，属主和权限

网络的 socket 文件可能位于目录： /tmp/.oracle, /var/tmp/.oracle or /usr/tmp/.oracle 中。

当网络的 socket 文件权限或者属主设置不正确的时候，我们通常会在守护进程的日志中看到以下类似的信息:

2011-06-18 14:07:28.545: [ COMMCRS][772]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=racnode1DBG_EVMD))

2011-06-18 14:07:28.545: [  clsdmt][515]Fail to listen to (ADDRESS=(PROTOCOL=ipc)(KEY=lena042DBG_EVMD))
2011-06-18 14:07:28.545: [  clsdmt][515]Terminating process
2011-06-18 14:07:28.559: [ default][515] EVMD exiting on stop request from clsdms_thdmai

以下错误也有可能提示:

CRS-5017: The resource action "ora.evmd start" encountered the following error:
CRS-2674: Start of 'ora.evmd' on 'racnode1' failed
..

解决的办法：请使用 root 用户停掉 GI，删除这些 socket 文件，并重新启动 GI。

我们假设一个 Grid Infrastructure 环境，节点名为 rac1, CRS 的属主是 grid，以下是 socket 文件夹(../.oracle)正常的设置情况:

在 Grid Infrastructure cluster 环境中:

以下例子是集群环境中的例子：

drwxrwxrwt  2 root oinstall 4096 Feb  2 21:25 .oracle

./.oracle:
drwxrwxrwt 2 root  oinstall 4096 Feb  2 21:25 .
srwxrwx--- 1 grid oinstall    0 Feb  2 18:00 master_diskmon
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 mdnsd
-rw-r--r-- 1 grid oinstall    5 Feb  2 18:00 mdnsd.pid
prw-r--r-- 1 root  root        0 Feb  2 13:33 npohasd
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 ora_gipc_GPNPD_rac1
-rw-r--r-- 1 grid oinstall    0 Feb  2 13:34 ora_gipc_GPNPD_rac1_lock
srwxrwxrwx 1 grid oinstall    0 Feb  2 13:39 s#11724.1
srwxrwxrwx 1 grid oinstall    0 Feb  2 13:39 s#11724.2
srwxrwxrwx 1 grid oinstall    0 Feb  2 13:39 s#11735.1
srwxrwxrwx 1 grid oinstall    0 Feb  2 13:39 s#11735.2
srwxrwxrwx 1 grid oinstall    0 Feb  2 13:45 s#12339.1
srwxrwxrwx 1 grid oinstall    0 Feb  2 13:45 s#12339.2
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 s#6275.1
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 s#6275.2
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 s#6276.1
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 s#6276.2
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 s#6278.1
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 s#6278.2
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 sAevm
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 sCevm
srwxrwxrwx 1 root  root        0 Feb  2 18:01 sCRSD_IPC_SOCKET_11
srwxrwxrwx 1 root  root        0 Feb  2 18:01 sCRSD_UI_SOCKET
srwxrwxrwx 1 root  root        0 Feb  2 21:25 srac1DBG_CRSD
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 srac1DBG_CSSD
srwxrwxrwx 1 root  root        0 Feb  2 18:00 srac1DBG_CTSSD
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 srac1DBG_EVMD
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 srac1DBG_GIPCD
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 srac1DBG_GPNPD
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 srac1DBG_MDNSD
srwxrwxrwx 1 root  root        0 Feb  2 18:00 srac1DBG_OHASD
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 sLISTENER
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 sLISTENER_SCAN2
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:01 sLISTENER_SCAN3
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 sOCSSD_LL_rac1_
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 sOCSSD_LL_rac1_eotcs
-rw-r--r-- 1 grid oinstall    0 Feb  2 18:00 sOCSSD_LL_rac1_eotcs_lock
-rw-r--r-- 1 grid oinstall    0 Feb  2 18:00 sOCSSD_LL_rac1__lock
srwxrwxrwx 1 root  root        0 Feb  2 18:00 sOHASD_IPC_SOCKET_11
srwxrwxrwx 1 root  root        0 Feb  2 18:00 sOHASD_UI_SOCKET
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 sOracle_CSS_LclLstnr_eotcs_1
-rw-r--r-- 1 grid oinstall    0 Feb  2 18:00 sOracle_CSS_LclLstnr_eotcs_1_lock
srwxrwxrwx 1 root  root        0 Feb  2 18:01 sora_crsqs
srwxrwxrwx 1 root  root        0 Feb  2 18:00 sprocr_local_conn_0_PROC
srwxrwxrwx 1 root  root        0 Feb  2 18:00 sprocr_local_conn_0_PROL
srwxrwxrwx 1 grid oinstall    0 Feb  2 18:00 sSYSTEM.evm.acceptor.auth

在 Oracle Restart 环境中:

以下是 Oracle Restart 环境中的输出例子:

drwxrwxrwt  2 root oinstall 4096 Feb  2 21:25 .oracle

./.oracle:
srwxrwx--- 1 grid oinstall 0 Aug  1 17:23 master_diskmon
prw-r--r-- 1 grid oinstall 0 Oct 31  2009 npohasd
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 s#14478.1
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 s#14478.2
srwxrwxrwx 1 grid oinstall 0 Jul 14 08:02 s#2266.1
srwxrwxrwx 1 grid oinstall 0 Jul 14 08:02 s#2266.2
srwxrwxrwx 1 grid oinstall 0 Jul  7 10:59 s#2269.1
srwxrwxrwx 1 grid oinstall 0 Jul  7 10:59 s#2269.2
srwxrwxrwx 1 grid oinstall 0 Jul 31 22:10 s#2313.1
srwxrwxrwx 1 grid oinstall 0 Jul 31 22:10 s#2313.2
srwxrwxrwx 1 grid oinstall 0 Jun 29 21:58 s#2851.1
srwxrwxrwx 1 grid oinstall 0 Jun 29 21:58 s#2851.2
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sCRSD_UI_SOCKET
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 srac1DBG_CSSD
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 srac1DBG_OHASD
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sEXTPROC1521
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sOCSSD_LL_rac1_
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sOCSSD_LL_rac1_localhost
-rw-r--r-- 1 grid oinstall 0 Aug  1 17:23 sOCSSD_LL_rac1_localhost_lock
-rw-r--r-- 1 grid oinstall 0 Aug  1 17:23 sOCSSD_LL_rac1__lock
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sOHASD_IPC_SOCKET_11
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sOHASD_UI_SOCKET
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sgrid_CSS_LclLstnr_localhost_1
-rw-r--r-- 1 grid oinstall 0 Aug  1 17:23 sgrid_CSS_LclLstnr_localhost_1_lock
srwxrwxrwx 1 grid oinstall 0 Aug  1 17:23 sprocr_local_conn_0_PROL

诊断文件收集

如果通过本文没有找到问题原因，请使用 root 用户，在所有的节点上执行 $GRID_HOME/bin/diagcollection.sh ，并上传在当前目录下生成所有的 .gz 压缩文件来做进一步诊断。

Filed Under: Oracle, Oracle RAC