Clusterware启动顺序
Clusterware启动顺序
[root@ebsdb1 etc]# 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
根据以上输出,集群大概可分为4个层次:
层次1:OHAS层面,负责集群的初始化资源和进程。
层次2:CSS层面,负责构建集群并保证集群的一致性。
层次3:CRS层面,负责管理集群的各种应用程序资源。
层次4:EVM层面,负责在集群节点间传递集群事件。
接下来详细地介绍每一个层面的启动过程:
OHASD层面
该层面主要负责启动集群的初始化资源和进程,具体的过程如下:
1./etc/inittab中的以下行被调用
$cat /etc/inittab|grep init.d | grep –v grep
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2.操作系统进程init.ohasd run被启动,该进程负责启动ohasd.bin守护进程
[root@ebsdb1 etc]# ps -ef | grep ohasd | grep -v grep
root3813 1 0 Feb03 ? 00:00:00 /bin/sh /etc/init.d/init.ohasd run
root56333 1 0 Feb03 ? 01:03:52 /ebsdb/grid/11.2.0/bin/ohasd.bin reboot
而init.ohasd在启动ohasd.bin守护进程之前需要执行以下的操作。
1)集群自动启动是否被禁用
2)GI home所在文件系统是否被正常挂载
3)管道文件(npohasd)是否能够被访问
[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle
total 4
srwxr-xr-x 1 grid oinstall 0 Feb 3 10:41 mdnsd
-rwxrwxrwx 1 grid oinstall 6 Feb 3 10:41 mdnsd.pid
prwxrwxrwx 1 root root0 Oct 26 15:43 npohasd
对于ohasd.bin进程,他需要经过以下过程才能够正常运行。
1)确认OLR存在,而且能够被正常访问
[grid@ebsdb1 ~]$ ls -l $GRID_HOME/cdata/
total 2928
drwxr-xr-x 2 grid oinstall 4096 Feb 14 10:21 ebsdb1
-rw------- 1 root oinstall 272756736 Feb 14 15:02 ebsdb1.olr
drwxrwxr-x 2 grid oinstall 4096 Jan 25 13:11 ebsdb-cluster
drwxr-xr-x 2 grid oinstall 4096 Oct 26 15:38 localhost
2)ohasd所使用的套接字文件(socket file)存在
[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle/*HAS*
srwxrwxrwx 1 root root 0 Feb 3 10:41 /var/tmp/.oracle/sebsdb1DBG_OHASD
srwxrwxrwx 1 root root 0 Feb 3 10:41 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11
-rwxrwxrwx 1 root root 0 Oct 26 15:43 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11_lock
srwxrwxrwx 1 root root 0 Feb 3 10:41 /var/tmp/.oracle/sOHASD_UI_SOCKET
3)ohasd对应的日志文件能够被正常访问
[grid@ebsdb1 11.2.0]$ ls -l $GRID_HOME/log/ebsdb1/ohasd
total 106192
-rw-r--r-- 1 root root 10579981 Feb 12 16:01 ohasd.l01
-rw-r--r-- 1 root root 10520765 Feb 5 20:22 ohasd.l02
-rw-r--r-- 1 root root 10547596 Jan 24 14:24 ohasd.l03
-rw-r--r-- 1 root root 10544559 Jan 22 18:01 ohasd.l04
-rw-r--r-- 1 root root 10546879 Jan 20 21:42 ohasd.l05
-rw-r--r-- 1 root root 10551400 Jan 19 01:21 ohasd.l06
-rw-r--r-- 1 root root 10552985 Jan 17 04:50 ohasd.l07
-rw-r--r-- 1 root root 10550884 Jan 15 08:21 ohasd.l08
-rw-r--r-- 1 root root 10548055 Jan 13 11:52 ohasd.l09
-rw-r--r-- 1 root root 10548999 Jan 11 15:09 ohasd.l10
-rw-r--r-- 1 root root 3171780 Feb 14 17:03 ohasd.log
-rw-r--r-- 1 root root 1260 Feb3 10:41 ohasdOUT.log
如果发现init.ohasd进程没有出现,那么说明操作系统进程没有成功地调用/etc/init.d/init.ohasd run命令,比较常见的原因可能如下:
原因1:操作系统运行在了错误的runlevel(可使用who –r查看当前的运行级别)
原因2:/etc/rc<n>.d当中有些脚本被挂起,导致了S<nn>ohasd没有被调用
原因3:GI的自动启动功能被关闭(crsctl disable crs)
而对应的解决办法如下:
办法1:重新启动操作系统到正确的运行级别
办法2:手工运行init.ohasd脚本(例如: nohup /etc/init.d/ohasd run &)
办法3:启动GI自动启动功能(crsctl enable crs)
如果发现init.ohasd已经启动,但是ohasd.bin没有被正常启动,比较常见的原因如下:
原因1:OLR不能被访问或者已经丢失。
原因2:ohasd对应的套接字文件无法访问或者已经丢失
原因3:ohasd对应的日志文件无法被访问
而对应的解决办法如下:
办法1:从OLR备份中恢复OLR(默认情况下,在集群安装结束后,OLR会备份<$GRID_HOME/cdata/<节点名>/backup_<时间>.olr>)
ocrconfig –local –restore <OLR备份文件>
办法2:重新启动GI,以便重建套接字文件
crsctl stop crs
crsctl start crs
办法3:修改ohasd日志文件的属性,确认它能够被访问到
-rw-r--r-- 1 root root3171780 Feb 14 17:03 ohasd.log
当然,如果遇到了其他问题,那就需要查看ohasd.log来进行问题分析了
3.ohasd.bin开始启动集群的初始化资源和进程
根据前面的介绍,ohasd.bin会启动4个代理进程来启动所有的集群初始化资源。
oraagnet:启动ora.asm、ora.evmd、ora.gipcd、ora.gpnpd、ora.mdnsd等
orarootagent:启动ora.crsd、ora.ctssd、ora.cluster_interconnect.haip、ora.crf、ora.diskmon等
cssdagnet:启动ora.cssd
cssdmonitor:启动ora.cssdmonitor
如果对应的代理进程无法启动的话,那么以上的集群初始化资源也就无法启动,而代理进程无法启动的主要原因有以下两种:
原因1:代理进程对应的二进制文件损坏
原因2:代理进程的日志文件无法访问
[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oraagent_grid
total 109976
……
-rw-r--r-- 1 grid oinstall 6895201 Feb 14 19:28 oraagent_grid.log
……
[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/orarootagent_root
total 112468
……
-rw-r--r-- 1 root root 9467315 Feb 14 19:30 orarootagent_root.log
……
[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdagent_root
total 852
-rw-r--r-- 1 root root 865091 Feb 14 16:04 oracssdagent_root.log
[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdmonitor_root
total 844
-rw-r--r-- 1 root root 856526 Feb 14 19:25 oracssdmonitor_root.log
对应的解决办法如下:
办法1:将有问题节点的代理进程二进制文件和健康节点的文件进行比较,发现不同后,把健康节点的文件复制到问题节点的对应位置。
办法2:确认代理进程的日志文件能够被对应的用户访问。
4.集群的初始化资源开始启动
虽然ohasd的代理进程会同时启动所有的集群初始化资源,但是它们之间还是有依赖关系的,集群初始化资源的启动依赖关系如下:
有些对集群不重要的初始化资源,在上图中并没有显示
从上面的途中大家可以看到gipcd、gpnpd、mdnsd负责完成集群的bootstrap过程;cssdagent和cssdmonitor负责启动和监控cssd守护进程;而集群的其他初始化资源都要依赖于cssd。
下面对集群的bootstrap过程进行简单的介绍(详细的过程在css管理中)
1)mdnsd守护进程被启动,并启动mdns服务,以便gpnpd能够通过mdns在节点之间传输gpnp profile文件。
2)gpnpd守护进程被启动,gpnpd开始读取本地节点的gpnp profile,之后和远程节点的gpnpd守护进程通信,以便获得集群中最新的gpnp profile信息。
3)gpnpd启动完毕,向本地节点的其他集群初始化资源提供gpnp profile服务。
4)gipcd守护进程被启动,从gpnpd守护进程获得集群的私网信息,并和远程节点的gpipcd守护进程通信,最后开监控本地节点的私网。
5)cssdagent代理进程启动ocssd.bin守护进程。
6)cssdmonitor守护进程启动,并开始监控ocssd.bin守护进程的状态。
在整个过程中,可能导致集群的bootstrap过程无法成功的主要原因如下。
原因1:集群中有其他的mdns软件运行,这会导致GI的mdnsd服务无法正常工作。
原因2:gpnp profile文件中的信息出现错误,这会导致集群的bootstrap过程无法完成。
[grid@ebsdb1 peer]$ gpnptool get
或
[grid@ebsdb1 peer]$ cat $GRID_HOME/gpnp/<hostname>/profiles/peer/profile.xml
原因3:节点之间的网络通信存在问题,这会导致gpnp profile无法正常传输。
原因4:gpnp的一些线程被挂起,这会导致gpnpd守护进程无法成功完成启动任务。
原因5:集群的私网网卡出现问题,这会导致gipcd无法和其他节点的gipcd进行通信或者集群没有可用的私网进行通信。
原因6:gipcd存在问题,这会导致它错误地认为集群私网网卡存在问题。
原因7:以上守护进程的套接字文件丢失。
对应的解决方法如下。
方法1:停止并禁用其他的mdns软件。
方法2:如果gpnp profile只是在集群的某一个节点上出现了错误,可以从集群的其他节点将其复制过来。如果集群所有几点的gpnp pfile都出现了问题,那么就需要使用gpnp工具来进行修正。
下面的例子演示了如何使用gpnp tool修改gpnp profile中集群的私网信息。
1) 检查当前的gpnp profile,确认gpnpd能够通过mdns找到集群的其他节点。
[grid@ebsdb1 peer]$ gpnptool get
[grid@ebsdb1 peer]$ gpnptool find
2) 创建一个工作路径以用于编辑gpnp profile
mkdir /home/grid/gpnp
export GPNPDIR=/home/grid/gpnp
$GRID_HOME/bing/gpnptool get -o=$GPNPDIR/profile.original
3) 创建一个用于修改的gpnp profile副本
cp $GPNPDIR/profile.original $GPNPDIR/p.xml
4) 查看gpnp profile的序列号和私网信息
$gpnptool getpval -p=$GPNPDIR/p.xml -prf_sq -o-
$gpnptool getpval -p=$GPNPDIR/p.xml -net -o-
5) 修改集群私网的网卡信息
gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=<当前序列号+1> -net<私网编号>:net_ada=<私网网卡名>
例如:
gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=9 -net2:net_ada=eth1
6) 确认之前的修改
gpnptool sign -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -w=cw-fs:peer
7) 将修改后的gpnp profile应用到gpnpd守护进程中。
gpnptool put -p=$GPNPDIR/p.xml
8) 将改变后的gpnp profile推送到集群的其他节点
gpnptool find -c=<集群名>
gpnptool rget -c=<集群名>
方法3:确认件私网通信正常(例如:使用ping、traceroute等命令确认集群私网的连通性)
方法4:在操作系统层面重新启动gpnp守护进程,例如:kill -9 <gpnp进程ID>
当gpnpd守护进程被总之之后,对应的ohasd代理进程oraagent会及时发现这一情况,并启动新的gpnpd守护进程。
方法5:确认集群私网通信正常(例如:使用ping、traceroute等命令确认集群私网的连通性)
方法6:在操作系统层面重新启动gipcd守护进程,例如:kill -9 <gipcd进程ID>
当gipcd守护进程被总之之后,对应的ohasd代理进程oraagent会及时发现这一情况,并启动新的gipcd守护进程。
方法7:重新启动GI,以便重建套接字文件。
crsctl stop crs
crsctl start crs
<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">
Clusterware启动顺序
[root@ebsdb1 etc]# 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
根据以上输出,集群大概可分为4个层次:
层次1:OHAS层面,负责集群的初始化资源和进程。
层次2:CSS层面,负责构建集群并保证集群的一致性。
层次3:CRS层面,负责管理集群的各种应用程序资源。
层次4:EVM层面,负责在集群节点间传递集群事件。
接下来详细地介绍每一个层面的启动过程:
OHASD层面
该层面主要负责启动集群的初始化资源和进程,具体的过程如下:
1./etc/inittab中的以下行被调用
$cat /etc/inittab|grep init.d | grep –v grep
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2.操作系统进程init.ohasd run被启动,该进程负责启动ohasd.bin守护进程
[root@ebsdb1 etc]# ps -ef | grep ohasd | grep -v grep
root3813 1 0 Feb03 ? 00:00:00 /bin/sh /etc/init.d/init.ohasd run
root56333 1 0 Feb03 ? 01:03:52 /ebsdb/grid/11.2.0/bin/ohasd.bin reboot
而init.ohasd在启动ohasd.bin守护进程之前需要执行以下的操作。
1)集群自动启动是否被禁用
2)GI home所在文件系统是否被正常挂载
3)管道文件(npohasd)是否能够被访问
[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle
total 4
srwxr-xr-x 1 grid oinstall 0 Feb 3 10:41 mdnsd
-rwxrwxrwx 1 grid oinstall 6 Feb 3 10:41 mdnsd.pid
prwxrwxrwx 1 root root0 Oct 26 15:43 npohasd
对于ohasd.bin进程,他需要经过以下过程才能够正常运行。
1)确认OLR存在,而且能够被正常访问
[grid@ebsdb1 ~]$ ls -l $GRID_HOME/cdata/
total 2928
drwxr-xr-x 2 grid oinstall 4096 Feb 14 10:21 ebsdb1
-rw------- 1 root oinstall 272756736 Feb 14 15:02 ebsdb1.olr
drwxrwxr-x 2 grid oinstall 4096 Jan 25 13:11 ebsdb-cluster
drwxr-xr-x 2 grid oinstall 4096 Oct 26 15:38 localhost
2)ohasd所使用的套接字文件(socket file)存在
[grid@ebsdb1 ~]$ ls -l /var/tmp/.oracle/*HAS*
srwxrwxrwx 1 root root 0 Feb 3 10:41 /var/tmp/.oracle/sebsdb1DBG_OHASD
srwxrwxrwx 1 root root 0 Feb 3 10:41 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11
-rwxrwxrwx 1 root root 0 Oct 26 15:43 /var/tmp/.oracle/sOHASD_IPC_SOCKET_11_lock
srwxrwxrwx 1 root root 0 Feb 3 10:41 /var/tmp/.oracle/sOHASD_UI_SOCKET
3)ohasd对应的日志文件能够被正常访问
[grid@ebsdb1 11.2.0]$ ls -l $GRID_HOME/log/ebsdb1/ohasd
total 106192
-rw-r--r-- 1 root root 10579981 Feb 12 16:01 ohasd.l01
-rw-r--r-- 1 root root 10520765 Feb 5 20:22 ohasd.l02
-rw-r--r-- 1 root root 10547596 Jan 24 14:24 ohasd.l03
-rw-r--r-- 1 root root 10544559 Jan 22 18:01 ohasd.l04
-rw-r--r-- 1 root root 10546879 Jan 20 21:42 ohasd.l05
-rw-r--r-- 1 root root 10551400 Jan 19 01:21 ohasd.l06
-rw-r--r-- 1 root root 10552985 Jan 17 04:50 ohasd.l07
-rw-r--r-- 1 root root 10550884 Jan 15 08:21 ohasd.l08
-rw-r--r-- 1 root root 10548055 Jan 13 11:52 ohasd.l09
-rw-r--r-- 1 root root 10548999 Jan 11 15:09 ohasd.l10
-rw-r--r-- 1 root root 3171780 Feb 14 17:03 ohasd.log
-rw-r--r-- 1 root root 1260 Feb3 10:41 ohasdOUT.log
如果发现init.ohasd进程没有出现,那么说明操作系统进程没有成功地调用/etc/init.d/init.ohasd run命令,比较常见的原因可能如下:
原因1:操作系统运行在了错误的runlevel(可使用who –r查看当前的运行级别)
原因2:/etc/rc<n>.d当中有些脚本被挂起,导致了S<nn>ohasd没有被调用
原因3:GI的自动启动功能被关闭(crsctl disable crs)
而对应的解决办法如下:
办法1:重新启动操作系统到正确的运行级别
办法2:手工运行init.ohasd脚本(例如: nohup /etc/init.d/ohasd run &)
办法3:启动GI自动启动功能(crsctl enable crs)
如果发现init.ohasd已经启动,但是ohasd.bin没有被正常启动,比较常见的原因如下:
原因1:OLR不能被访问或者已经丢失。
原因2:ohasd对应的套接字文件无法访问或者已经丢失
原因3:ohasd对应的日志文件无法被访问
而对应的解决办法如下:
办法1:从OLR备份中恢复OLR(默认情况下,在集群安装结束后,OLR会备份<$GRID_HOME/cdata/<节点名>/backup_<时间>.olr>)
ocrconfig –local –restore <OLR备份文件>
办法2:重新启动GI,以便重建套接字文件
crsctl stop crs
crsctl start crs
办法3:修改ohasd日志文件的属性,确认它能够被访问到
-rw-r--r-- 1 root root3171780 Feb 14 17:03 ohasd.log
当然,如果遇到了其他问题,那就需要查看ohasd.log来进行问题分析了
3.ohasd.bin开始启动集群的初始化资源和进程
根据前面的介绍,ohasd.bin会启动4个代理进程来启动所有的集群初始化资源。
oraagnet:启动ora.asm、ora.evmd、ora.gipcd、ora.gpnpd、ora.mdnsd等
orarootagent:启动ora.crsd、ora.ctssd、ora.cluster_interconnect.haip、ora.crf、ora.diskmon等
cssdagnet:启动ora.cssd
cssdmonitor:启动ora.cssdmonitor
如果对应的代理进程无法启动的话,那么以上的集群初始化资源也就无法启动,而代理进程无法启动的主要原因有以下两种:
原因1:代理进程对应的二进制文件损坏
原因2:代理进程的日志文件无法访问
[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oraagent_grid
total 109976
……
-rw-r--r-- 1 grid oinstall 6895201 Feb 14 19:28 oraagent_grid.log
……
[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/orarootagent_root
total 112468
……
-rw-r--r-- 1 root root 9467315 Feb 14 19:30 orarootagent_root.log
……
[grid@ebsdb1 oraagent_grid]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdagent_root
total 852
-rw-r--r-- 1 root root 865091 Feb 14 16:04 oracssdagent_root.log
[grid@ebsdb1 oracssdagent_root]$ ls -l $GRID_HOME/log/ebsdb1/agent/ohasd/oracssdmonitor_root
total 844
-rw-r--r-- 1 root root 856526 Feb 14 19:25 oracssdmonitor_root.log
对应的解决办法如下:
办法1:将有问题节点的代理进程二进制文件和健康节点的文件进行比较,发现不同后,把健康节点的文件复制到问题节点的对应位置。
办法2:确认代理进程的日志文件能够被对应的用户访问。
4.集群的初始化资源开始启动
虽然ohasd的代理进程会同时启动所有的集群初始化资源,但是它们之间还是有依赖关系的,集群初始化资源的启动依赖关系如下:
有些对集群不重要的初始化资源,在上图中并没有显示
从上面的途中大家可以看到gipcd、gpnpd、mdnsd负责完成集群的bootstrap过程;cssdagent和cssdmonitor负责启动和监控cssd守护进程;而集群的其他初始化资源都要依赖于cssd。
下面对集群的bootstrap过程进行简单的介绍(详细的过程在css管理中)
1)mdnsd守护进程被启动,并启动mdns服务,以便gpnpd能够通过mdns在节点之间传输gpnp profile文件。
2)gpnpd守护进程被启动,gpnpd开始读取本地节点的gpnp profile,之后和远程节点的gpnpd守护进程通信,以便获得集群中最新的gpnp profile信息。
3)gpnpd启动完毕,向本地节点的其他集群初始化资源提供gpnp profile服务。
4)gipcd守护进程被启动,从gpnpd守护进程获得集群的私网信息,并和远程节点的gpipcd守护进程通信,最后开监控本地节点的私网。
5)cssdagent代理进程启动ocssd.bin守护进程。
6)cssdmonitor守护进程启动,并开始监控ocssd.bin守护进程的状态。
在整个过程中,可能导致集群的bootstrap过程无法成功的主要原因如下。
原因1:集群中有其他的mdns软件运行,这会导致GI的mdnsd服务无法正常工作。
原因2:gpnp profile文件中的信息出现错误,这会导致集群的bootstrap过程无法完成。
[grid@ebsdb1 peer]$ gpnptool get
或
[grid@ebsdb1 peer]$ cat $GRID_HOME/gpnp/<hostname>/profiles/peer/profile.xml
原因3:节点之间的网络通信存在问题,这会导致gpnp profile无法正常传输。
原因4:gpnp的一些线程被挂起,这会导致gpnpd守护进程无法成功完成启动任务。
原因5:集群的私网网卡出现问题,这会导致gipcd无法和其他节点的gipcd进行通信或者集群没有可用的私网进行通信。
原因6:gipcd存在问题,这会导致它错误地认为集群私网网卡存在问题。
原因7:以上守护进程的套接字文件丢失。
对应的解决方法如下。
方法1:停止并禁用其他的mdns软件。
方法2:如果gpnp profile只是在集群的某一个节点上出现了错误,可以从集群的其他节点将其复制过来。如果集群所有几点的gpnp pfile都出现了问题,那么就需要使用gpnp工具来进行修正。
下面的例子演示了如何使用gpnp tool修改gpnp profile中集群的私网信息。
1) 检查当前的gpnp profile,确认gpnpd能够通过mdns找到集群的其他节点。
[grid@ebsdb1 peer]$ gpnptool get
[grid@ebsdb1 peer]$ gpnptool find
2) 创建一个工作路径以用于编辑gpnp profile
mkdir /home/grid/gpnp
export GPNPDIR=/home/grid/gpnp
$GRID_HOME/bing/gpnptool get -o=$GPNPDIR/profile.original
3) 创建一个用于修改的gpnp profile副本
cp $GPNPDIR/profile.original $GPNPDIR/p.xml
4) 查看gpnp profile的序列号和私网信息
$gpnptool getpval -p=$GPNPDIR/p.xml -prf_sq -o-
$gpnptool getpval -p=$GPNPDIR/p.xml -net -o-
5) 修改集群私网的网卡信息
gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=<当前序列号+1> -net<私网编号>:net_ada=<私网网卡名>
例如:
gpnptool edit -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -prf_sq=9 -net2:net_ada=eth1
6) 确认之前的修改
gpnptool sign -p=$GPNPDIR/p.xml -o=$GPNPDIR/p.xml -ovr -w=cw-fs:peer
7) 将修改后的gpnp profile应用到gpnpd守护进程中。
gpnptool put -p=$GPNPDIR/p.xml
8) 将改变后的gpnp profile推送到集群的其他节点
gpnptool find -c=<集群名>
gpnptool rget -c=<集群名>
方法3:确认件私网通信正常(例如:使用ping、traceroute等命令确认集群私网的连通性)
方法4:在操作系统层面重新启动gpnp守护进程,例如:kill -9 <gpnp进程ID>
当gpnpd守护进程被总之之后,对应的ohasd代理进程oraagent会及时发现这一情况,并启动新的gpnpd守护进程。
方法5:确认集群私网通信正常(例如:使用ping、traceroute等命令确认集群私网的连通性)
方法6:在操作系统层面重新启动gipcd守护进程,例如:kill -9 <gipcd进程ID>
当gipcd守护进程被总之之后,对应的ohasd代理进程oraagent会及时发现这一情况,并启动新的gipcd守护进程。
方法7:重新启动GI,以便重建套接字文件。
crsctl stop crs
crsctl start crs
<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">
Clusterware启动顺序相关推荐
- clusterware启动顺序——CRSD
clusterware启动顺序--CRSD CRSD层面 1.启动过程 CRSD层面的主要工作是启动crsd.bin守护进程,然后由crsd.bin读取OCR中的信息并和PE master节点通信,之 ...
- oracle clusterware 11g,Oracle 11gR2 clusterware启动顺序
从1gR2起Oracle引入init.ohasd,将其配置在/etc/inittab中,用以启动和管理clusterware相关资源 Pre 11R2 /etc/inittab h1:2:respaw ...
- 11g oracle cluster 自动启动,Oracle 11gR2 clusterware启动顺序
从1gR2起Oracle引入init.ohasd,将其配置在/etc/inittab中,用以启动和管理clusterware相关资源 Pre 11R2 /etc/inittab h1:2:res 从1 ...
- oracle clusterware 11g,Oracle11gR2clusterware启动顺序
从1gR2起Oracle引入init.ohasd,将其配置在/etc/inittab中,用以启动和管理clusterware相关资源 Pre 11R2 /etc/inittab h1:2:res 从1 ...
- 【Oracle】RAC11gR2Grid启动顺序及启动故障诊断思路
转自:https://www.2cto.com/database/201605/507269.html 图片来自:https://blog.csdn.net/zwjzqqb/article/detai ...
- 【Oracle】RAC11gR2 Grid启动顺序及启动故障诊断思路
从11gR2开始,Oracle RAC的架构有了比较大的变化,集群层面相交于之前的版本有了比较大的变动,原来的rac架构基本上属于cssd.crsd.evmd三大光秃秃的主干进程,日志数量较少,对于r ...
- 转-linux系统脚本 环境变量 的启动顺序
linux系统脚本的常见启动顺序 由于相关变量定义不同, 所以以下启动顺序仅供参考 在Redhat Redflag centos fc linux系统里面脚本的启动 先后: 第一步:通过/boot/v ...
- Hadoop的启动顺序和停止顺序
2019独角兽企业重金招聘Python工程师标准>>> 启动顺序:NameNode.DataNode.SecondaryNameNode.JobTracker.TaskTracker ...
- linux 更改服务的启动顺序
打开/etc/init.d/下该服务的脚本 找到类似如下一句 # chkconfig: 2345 64 36 这里的64就是启动顺序 这里的36就是关闭顺序 你把smb的这个64所在位置的数字改的小于 ...
最新文章
- 滑动窗口——TCP可靠传输的实现[转]
- Synchronize对象属性改变
- 互联网亿级日志实时分析平台,一个码农半小时就可以搞定,只因ELK
- emacs中安装markdown-mode
- 楼市反弹难以持续 年末房价稳中趋降
- 人工智能目标检测模型总结(一)——R-CNN、Fast R-CNN、Faster R-CNN
- java类 uuid_Java常用类——UUID类
- git 某个文件回退到指定版本
- 电信光猫F652破解经验谈
- ft232电路ttl_FT232AM的设计电路及中文资料
- 饿百零售开放平台,测试账号饿了么显示该商家还没有上传商品
- App Inventor自定义插件Extension
- 方正中间件创业大赛南京赛区圆满落幕
- 投影幕布尺寸计算器_投影距离和屏幕尺寸计算器
- 【沃顿商学院学习笔记】商业分析——Customer Analytics:04 规范性分析 Prescriptive Analytics
- Windows11网速慢解决方案
- 虚幻引擎图文笔记:使用物理模拟(Physical Simulation)给角色添加一个马尾辫
- crawler:AJAX动态网页数据抓取、Selenium使用
- 秋招面试问题总结-视觉算法
- iOS 带下划线文字
热门文章
- (附源码)计算机毕业设计SSM教师业绩考核和职称评审系统
- 微软 Build 2019:IE 重生,Azure 成主角;华为拟在英剑桥新建半导体研发基地,与ARM做邻居……...
- Springloaded使用方法
- Spring Boot定时发送短信
- mavros操作飞机时方向位置改为机体坐标系下指令(转载)
- 路由器的登陆界面登陆过慢的原因
- 修改Mysql57的root密码
- IDEA 代码背景(护眼绿)
- Invivoscribe任命Loui Madakamutil为首席科学官,领导公司治疗学部门
- 使用border-radius出现缺角的问题