clusterware启动顺序——CRSD
CRSD层面
1.启动过程
CRSD层面的主要工作是启动crsd.bin守护进程，然后由crsd.bin读取OCR中的信息并和PE master节点通信，之后与crsd.bin对应的代理进程被启动，同时还启动集群所有的应用程序资源。CRSD管理的应用程序之间的依赖关系（启动顺序）可以通过以下图形了解。
具体的启动过程如下
1） crsd.bin从OCR中获得所需要启动的资源列表。
2） crsd.bin启动对应的代理进程。
3） 代理进程oraagent_root启动集群的公网资源，之后集群的VIP和SCAN VIP资源也被启动。
4） 代理进程oraagent_grid启动和VIP对应的Listener资源，以及和SCAN VIP对应的SCAN Listener资源。
5） 代理进程oraagent_grid启动ONS资源。
6） 代理进程oraagent_grid启动ora.asm资源，并启动其他的磁盘组资源。
7） 代理进程oraagent_oracle启动数据库资源，之后启动对应的数据库服务资源。
8） 代理进程script_agent启动ora.cvu资源。
2.可能出现的问题
（1）导致CRSD无法启动集群的应用程序资源的可能原因有：
原因1：/etc/oracle/ocr.loc指向了错误的OCR文件
[grid@ebsdb1 11.2.0]$ cat
/etc/oracle/ocr.loc
ocrconfig_loc=+VOTE_DG
local_only=FALSE
原因2：OCR损坏或者已经丢失。
原因3：代理进程对应的二进制文件丢失或者损坏。
原因4：集群的私网出现问题，从而导致crsd.bin无法和远程节点通信。
原因5：$GRID_HOME/bin/crsd.bin文件的权限错误或者文件已经损坏。
原因6：$GRID_HOME/crs/init/*.pid的文件指向了其他的运行中的进程。
相应的解决方法如下：
方法1：修改/etc/oracle/ocr.loc中的OCR位置，使其指向正确的OCR磁盘组，如果使用了裸设备或集群文件系统，则确认它指向了正确的裸设备名或文件系统名。
方法2：从正常的OCR备份中恢复OCR。
方法3：从正常的节点上复制代理进程的二进制文件到有问题的节点。
方法4：确认私网能够正常工作。
方法5：确认$GRID_HOME/bin/crsd.bin文件的权限正确。如果问题是crsd.bin文件损坏，可以从正常的节点上复制该文件到问题节点。
[grid@ebsdb1 11.2.0]$ ls -l
$GRID_HOME/bin/crsd.bin
-rwxr----x 1 root oinstall 106051083 Jun
16 2014 /ebsdb/grid/11.2.0/bin/crsd.bin
方法6：删除有问题的$GRID_HOME/crs/init/*.pid文件，之后重新启动CRSD，例如
crsctl stop res ora.crsd -init
crsctl start res ora.crsd -init
（2）导致VIP或SCAN VIP无法正常启动的可能原因：
原因1：由于网络问题导致集群公网资源无法启动。
原因2：由于DNS问题导致无法正常解析VIP和SCAN VIP。
原因3：VIP或SCAN VIP地址已经被网络中的其他主机占用。
原因4：OCR中记录的VIP或SCAN VIP信息和OS层面不一致。
对应的解决问题方法如下：
方法1：确认集群公网能够正常工作，而且公网资源ora.net1.network正常工作。
方法2：确认DNS能够正常工作，而且能够正确地解析VIP和SCAN VIP，例如使用nslookup <VIP或SCAN VIP对应的主机名>验证。
方法3：使用ping或者nslookup命令找到占用了VIP或SCAN VIP的主机，以解决地址冲突问题。
方法4：使用ifconfig命令和/etc/hosts中的信息确认OS层面的公网配置，之后通过以下的命令检查OCR中的配置
[grid@ebsdb1 11.2.0]$ oifcfg getif -global
eth0172.28.1.0 global public
eth1192.168.10.0 global cluster_interconnect
[grid@ebsdb1 11.2.0]$ srvctl config
nodeapps -a
Network exists:
1/172.28.1.0/255.255.255.0/eth0, type static
VIP exists:
/ebsdbvip1/172.28.1.223/172.28.1.0/255.255.255.0/eth0, hosting node ebsdb1
VIP exists:
/ebsdbvip2/172.28.1.224/172.28.1.0/255.255.255.0/eth0, hosting node ebsdb2
[grid@ebsdb1 11.2.0]$ srvctl config scan
SCAN name: ebsscan, Network:
1/172.28.1.0/255.255.255.0/eth0
SCAN VIP name: scan1, IP:
/ebsscan/172.28.1.225
（3）导致Listener或SCAN Listener无法正常启动的可能原因
由于Listener和SCAN Listener是依赖于VIP和SCAN VIP的，所以绝大部分Listener或SCAN Listener无法启动的问题都是由于VIP和SCAN VIP的问题导致的。
（4）ora.asm和磁盘组资源无法正常启动的可能原因
对于ora.asm，由于这个资源实际上是初始化资源ora.asm的一个代理资源，这个资源可能出现问题的原因可以参考之前的内容。而对于磁盘组资源ora.<磁盘组名>.dg，它实际上是用于反映对应ASM磁盘组的状态，如果这个资源无法启动，那在绝大部分情况下表明对应的ASM磁盘组没有被挂载，而磁盘组无法挂载的主要原因就是底层对应的ASM磁盘出现了问题，例如：某些磁盘的权限和属主错误、磁盘头信息错误、磁盘无法访问等。
解决办法如下：
方法1：修正ASM磁盘的权限和属主信息，对应的基本原则是：ASM磁盘的属主应该是grid用户，对应的组应该是asmadmin，而且grid用户和asmadmin组都应该对磁盘组有读写权限。
方法2：从11.1.0.7版本开始，ASM磁盘头信息会自动备份到AU#1的倒数第二个块中。对于AU大小为1MB的磁盘组，每个AU包括的块数量=1024KB/4KB=256个，备份信息位于AU#1的第254号块（从0号开始）。可以使用下面的命令手动恢复备份的磁盘头信息：
kfed repair /dev/oracleasm/disks/DATA1
aus=1048576
方法3：如果磁盘无法被访问，那绝大部分情况下都是由操作系统或存储层面的问题导致的。
（5）数据库资源或数据库服务资源无法启动的可能原因
对于数据库资源，实际上代理进程完成的工作就是通过资源的定义，执行startup spfile=<spfile位置>命令。而对于数据库服务资源，代理进程执行的命令就是alter
system set service_names=<数据库服务名称> sid=<数据库实例名>。可能导致它们无法启动的原因如下：
原因1：数据库资源的某些属性配置错误，如果数据库的启动选项被设置成了nomount，这表示代理进程会使用“startup nomount”的方式启动数据库。如果数据库角色被设置成了STANDBY，则表示代理进程认为这是一个备用数据库，那么数据库在启动时会导致问题。
原因2：数据库的health check文件（$ORACLE_HOME/dbs/hc_<实例名>.dat）无法被访问。
原因3：操作系统验证被禁用。
原因4：$ORACLE_HOME/bin下的Oracle二进制文件的权限或者属主配置错误。
原因5：数据库资源所依赖的磁盘组没有被挂载。
对应的解决方法如下：
方法1：确保数据库资源在OCR中的属性是正确的，以下是一个正常的数据库资源属性的输出
[orasit@ebsdb1 ~]$ srvctl config database
-d sit
Database unique name: SIT
Database name:
Oracle home: /ebsdb/sit/db/tech_st/11.2.0
Oracle user: orasit
Spfile:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: SIT
Database instances: SIT1,SIT2
Disk Groups: DATA_DG
Mount point paths:
Services:
Type: RAC
Database is administrator managed
方法2：确保数据库的health check文件存在而且能够访问，例如
[orasit@ebsdb1 ~]$ ls -l $ORACLE_HOME/dbs
total 31812
……
-rw-rw---- 1 orasit oinstall 1544 Feb 10 18:56 hc_SIT1.dat
……
方法3：启用操作系统验证。在$ORACLE_HOME/network/admin/sqlnet.ora文件中将一下行注释掉或者直接删除。
SQLNET.AUTHENTICATION_SERVICES=(NTS)
方法4：确保$ORACLE_HOME/bin下的Oracle二进制文件的权限或者属主配置正确，例如
[orasit@ebsdb1 ~]$ ls -l
$ORACLE_HOME/bin/oracle
-rwsr-s--x 1 orasit asmadmin 239729642
Feb 8 11:55 /ebsdb/sit/db/tech_st/11.2.0/bin/oracle
方法5：确保数据库所在的磁盘组已经被挂载。如果磁盘组对应的磁盘存在问题，在解决了磁盘组层面的问题后，使用类似于下面的命令挂载磁盘组：
alter diskgroup DATA mount;
如果磁盘组的冗余度是normal或者high，而只是个别的磁盘出现了问题，且没有数据丢失，可以使用类似下面的命令强制挂载磁盘
alter diskgruop DATA mount force;
