clusterware启动顺序—

CRSD层面

1.启动过程

）导致">CRSD无法启动集群的应用程序资源的可能原因有：">

原因：/etc/oracle/ocr.loc指向了错误的OCR文件

[grid@ebsdb1 11.2.0]$ cat
/etc/oracle/ocr.loc

ocrconfig_loc=+VOTE_DG

local_only=FALSE

原因：：代理进程对应的二进制文件丢失或者损坏。

原因：集群的私网出现问题，从而导致crsd.bin无法和远程节点通信。

原因：：：修改：从正常的OCR备份中恢复OCR。：从正常的节点上复制代理进程的二进制文件到有问题的节点。

方法：确认私网能够正常工作。

方法：确认$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

方法：删除有问题的$GRID_HOME/crs/init/*.pid文件，之后重新启动）导致">VIP或">SCAN VIP无法正常启动的可能原因：">

原因：由于网络问题导致集群公网资源无法启动。

原因：由于：：：确认集群公网能够正常工作，而且公网资源ora.net1.network正常工作。

方法：确认：使用：使用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无法正常启动的可能原因">

由于）">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=<数据库实例名>。可能导致它们无法启动的原因如下：

原因：数据库资源的某些属性配置错误，如果数据库的启动选项被设置成了nomount，这表示代理进程会使用“startup nomount”的方式启动数据库。如果数据库角色被设置成了STANDBY，则表示代理进程认为这是一个备用数据库，那么数据库在启动时会导致问题。

原因：数据库的health check文件（$ORACLE_HOME/dbs/hc_<实例名：操作系统验证被禁用。

原因：：数据库资源所依赖的磁盘组没有被挂载。

对应的解决方法如下：

方法：确保数据库资源在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

方法：确保数据库的health check文件存在而且能够访问，例如

[orasit@ebsdb1 ~]$ ls -l $ORACLE_HOME/dbs

total 31812

……

-rw-rw---- 1 orasit oinstall 1544 Feb 10 18:56 hc_SIT1.dat

……

方法：启用操作系统验证。在$ORACLE_HOME/network/admin/sqlnet.ora文件中将一下行注释掉或者直接删除。：确保$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

方法：确保数据库所在的磁盘组已经被挂载。如果磁盘组对应的磁盘存在问题，在解决了磁盘组层面的问题后，使用类似于下面的命令挂载磁盘组：

alter diskgroup DATA mount;

如果磁盘组的冗余度是">normal或者">high，而只是个别的磁盘出现了问题，且没有数据丢失，可以使用类似下面的命令强制挂载磁盘">

alter diskgruop DATA mount force;

来自为知笔记(Wiz)