星期二 三月 25, 2014

如何安装11.2单机Grid Infrastructure(Oracle Restart)?

本文通过图示给出了安装单机的11.2 Grid Infrastructure (也称Oracle Restart)的步骤。


在11.2及之上,如果要使用ASM,必须安装集群件Grid Infrastructure; 在11.2之前,ASM 不属于集群件,可以单独安装ASM。

请下载:How_To_Install_Standalone_GI(OracleRestart).pdf

星期四 八月 01, 2013

11gR2新特性---gipc守护进程


在这篇文章中,我们会对11gR2 新的守护进程gipcd(资源名称ora.gipcd)进行介绍,其中包括gipc的功能,启动顺序和一些基本的测试。


我们知道,对于oracle集群来说,集群私网是非常重要的,无论是集群的网络心跳,节点间通信还是数据库的cache fusion 都需要通过私网来实现。所以,我们会在很多的文档中都看到oracle集群的私网要稳定而且高速,要使用交换机,不能使用直连线(详细的原因可以参考Note 220970.1:RAC: Frequently Asked Questions,本文不作过多的解释)。如果可能的话,对集群私网网卡配置冗余/负载均衡,以确保集群私网的稳定和高效。 但是,在10gR2 11gR1的版本上,这需要借助第三方软件来实现,例如:Linux bonding, AIX EtherChannel, HP-UX APA 等。大部分的网卡聚合软件都会将多个网络接口聚合成为一个逻辑接口(当然,不同的聚合软件会有不同的实现方式,在这里不做讨论)。在安装和配置10g 11.1 版本的集群时,如果您对集群私网的网络接口进行了聚合(冗余或负载均衡),只需要将聚合后的网卡名称和对应的subnet信息告诉集群,换句话说,网卡聚合对oracle集群来说是透明的。但是,这也会给集群带来一些不稳定性,如果网卡聚合配置不正确,当被聚合的网卡之一出现问题时,集群很可能认为私网出现问题而导致很严重的问题,例如:节点重启,实例重启等。


正是由于以上的问题,从11gR2开始(具体点说,从11.2.0.2开始),oracle决定由集群自己来管理私网网卡,集群新特性gipc(Grid
IPC)
被介绍,这个新特性以守护进程gipcd.bin的形式存在于集群中,主要的功能有。


1. 当集群启动时,发现集群的私网网卡。当然,基于之前文章的介绍,集群私网的信息是从gpnp profile中获得的。并对发现的私网接口进行检查。


2. 利用之前发现的私网网卡,发现集群中的其他节点,并和其他节点的私网网卡建立联系。


3. 如果集群配置了多块私网网卡,当某个节点的某一个/几个私网网卡出现问题时,离线有问题的私网,并通知其他节点。


当然,oracle依然支持使用第三方网卡聚合软件对集群私网进行冗余/负载均衡配置,但是,这显然不是个好主意。


另外,在和一些同事和朋友探讨时也发现,很多朋友对gipc
HAIP的概念和功能还不是很清楚,在这里也做一些解释。我们知道,集群私网主要负责两类数据的通信。第一种:集群层面的数据通信,例如:ocssd.bin网络心跳,crsd.bin之间的通信等;第二种:oracle RAC 通信,例如:ASM 实例间的通信,数据库实例间的通信等。而且,第二种数据通信的工作负载要远远大于第一种。gipc,作为管理集群私网的进程,它需要向集群中的其他组件提供集群的私网信息,但是这进程并不负责传递具体的信息,具体的信息,仍然由对应的进程自己传输,当然,这主要针对第一种数据通信。正是由于gipc的出现,oracle 集群具有了管理集群私网的能力,而且第二种信息工作负载又很大,同时集群管理的主要资源就是数据库,HAIP 应运而生,作为实现oracle RAC通信的高可用/负载均衡的实现方法,来完成集群第二种信息的传递。所以,很多时候,如果我们发现只是HAIP出现问题时,受影响的会是数据库实例和ASM实例,而集群层面(也就是NM层面)的一致性仍然能够保证,而且集群的成员也不会发生改变。对于HAIP,本文不作过多介绍,更多信息,请参考之前的文章 “Redundant Interconnect
with Highly Available IP (HAIP)
简介”。


接下来,我们通过集群的一些日志对之前的内容进行一些验证。


1.集群启动时的gipcd.log


2013-07-17
12:28:28.071: [ default][3041003216]gipcd START pid=22337 Oracle Grid IPC
Daemon


2013-07-17
12:28:28.072: [ GIPCD][3041003216]
gipcdMain: gipcd Started
<<<<<< gipcd守护进程被启动了。


……


2013-07-17
12:28:29.046: [ GPNP][3041003216]clsgpnp_getCachedProfileEx: [at clsgpnp.c:613] Result:
(26) CLSGPNP_NO_PROFILE. Can't get offline GPnP service profile: local gpnpd is
up and running. Use getProfile instead.


2013-07-17
12:28:29.046: [ GPNP][3041003216]clsgpnp_getCachedProfileEx: [at clsgpnp.c:623] Result:
(26) CLSGPNP_NO_PROFILE. Failed to get offline GPnP service profile.


2013-07-17
12:28:29.066: [ GPNP][3041003216]clsgpnpm_newWiredMsg: [at clsgpnpm.c:741] Msg-reply has
soap fault 10 (Operation returned Retry (error CLSGPNP_CALL_AGAIN)) [uri
"http://www.grid-pnp.org/2005/12/gpnp-errors#"]
<<<< gipcd 尝试访问gpnp profile但是没有成功。由于log是在GI启动时获取的,这部分信息可以忽略,因为原因是gpnpd还没有成功启动。


……


2013-07-17
12:28:39.342: [ CLSINET][3023027088] # 0 Interface
'eth1',ip='192.168.254.30',mac='00-0c-29-a8-14-65',mask='255.255.255.0',net='192.168.254.0',use='cluster_interconnect'


2013-07-17
12:28:39.342: [ CLSINET][3023027088] # 1 Interface
'eth2',ip='192.168.254.31',mac='00-0c-29-a8-14-6f',mask='255.255.255.0',net='192.168.254.0',use='cluster_interconnect'
<<<<<
gipcd
发现了本地节点用于私网的网卡信息,在这个集群中有2块网卡作为集群的私网。


……


2013-07-17 12:28:39.344:
[GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created local bootstrap
interface for node 'single1', haName 'gipcd_ha_name', inf
'mcast://230.0.1.0:42424/192.168.254.30'


2013-07-17
12:28:39.344: [GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created local
interface for node 'single1', haName 'gipcd_ha_name', inf
'192.168.254.30:46782'


2013-07-17
12:28:39.345: [GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created local
bootstrap interface for node 'single1', haName 'gipcd_ha_name', inf
'mcast://230.0.1.0:42424/192.168.254.31'


2013-07-17
12:28:39.345: [GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created local
interface for node 'single1', haName 'gipcd_ha_name', inf
'192.168.254.31:39332' <<<<<<<
gipcd 用于集群数据通信(就是我们之前提到的第一种数据通信)的endpoint 已经产生。


……


2013-07-17
12:28:56.767: [GIPCHGEN][3023027088] gipchaNodeCreate: adding new node 0x9c107d8 { host 'single2', haName
'gipcd_ha_name', srcLuid 465fb26d-8b46eb95, dstLuid 00000000-00000000 numInf 0,
contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [0 : 0], createTime 797327224,
flags 0x0 } <<<<<
远程节点被发现。


……


2013-07-17
12:28:58.415: [GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created
remote interface for node 'single2', haName 'gipcd_ha_name', inf
'udp://192.168.254.33:16663'


2013-07-17
12:28:58.415: [GIPCHGEN][3025128336] gipchaWorkerAttachInterface: Interface
attached inf 0x9c0bb60
{ host 'single2', haName 'gipcd_ha_name', local 0xb4c4e590, ip '192.168.254.33:16663', subnet
'192.168.254.0', mask '255.255.255.0', numRef 0, numFail 0, flags 0x6 }


2013-07-17
12:28:58.415: [GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created
remote interface for node 'single2', haName 'gipcd_ha_name', inf
'udp://192.168.254.32:17578'


2013-07-17
12:28:58.415: [GIPCHGEN][3025128336] gipchaWorkerAttachInterface: Interface
attached inf 0x9c0a900 { host 'single2', haName
'gipcd_ha_name', local 0xb4cb8eb8, ip '192.168.254.32:17578', subnet
'192.168.254.0', mask '255.255.255.0', numRef 0, numFail 0, flags 0x6 } <<<<<<
gipcd 发现了远程节点私网的网卡信息。


……


2013-07-17
12:29:36.120: [GIPCDMON][3027229584] gipcdMonitorSaveInfMetrics: inf[ 0] eth1 - rank 99, avgms 6.326531 [ 257 / 250 / 245 ]


2013-07-17
12:29:36.120: [GIPCDMON][3027229584] gipcdMonitorSaveInfMetrics: inf[ 1] eth2 - rank 99, avgms 5.182186 [ 259 / 250 / 247 ] <<<<<
gipcd 检查本地私网网卡状态。


……


 2. 当集���中的一个私网down掉时的gipcd.log


2013-07-17
13:23:20.346: [ CLSINET][3027229584] Returning NETDATA: 2 interfaces


2013-07-17
13:23:20.346: [ CLSINET][3027229584] # 0 Interface
'eth1',ip='192.168.254.30',mac='00-0c-29-a8-14-65',mask='255.255.255.0',net='192.168.254.0',use='cluster_interconnect'


2013-07-17
13:23:20.346: [ CLSINET][3027229584] # 1 Interface
'eth2',ip='192.168.254.31',mac='00-0c-29-a8-14-6f',mask='255.255.255.0',net='192.168.254.0',use='cluster_interconnect'


2013-07-17 13:23:20.359:
[GIPCDMON][3027229584] gipcdMonitorSaveInfMetrics: inf[ 0] eth1 - rank 99, avgms 1.560694 [ 171 / 173 / 173 ]


2013-07-17
13:23:20.359: [GIPCDMON][3027229584] gipcdMonitorSaveInfMetrics: inf[ 1] eth2 - rank 99, avgms 1.802326 [ 172 / 172 / 172 ] <<<<<<<<
gipcd 仍然在进行私网检查。


……


+++使用命令“ifconfig eth1 down”禁用集群中的一个私网网卡。


……


2013-07-17
13:23:44.397: [ CLSINET][3027229584] # 0 Interface
'eth2',ip='192.168.254.31',mac='00-0c-29-a8-14-6f',mask='255.255.255.0',net='192.168.254.0',use='cluster_interconnect'


2013-07-17
13:23:44.397: [GIPCDMON][3027229584] gipcdMonitorUpdate: interface went down -
[ ip 192.168.254.30, subnet 192.168.254.0, mask 255.255.255.0 ]


2013-07-17
13:23:44.397: [GIPCDMON][3027229584] gipcdMonitorUpdate: msg sent to client
thread (([update(ip: 192.168.254.30, mask: 255.255.255.0, subnet
192.168.254.0), state(gipcdadapterstateDown)]))
<<<<<<<<
gipcd 发现私网eth1 down掉,同时向它的客户(例如:ocssd.bin)发送消息。


……


2013-07-17
13:23:44.426: [GIPCHGEN][3025128336] gipchaInterfaceDisable: disabling
interface 0xb4c4e590
{ host '', haName 'gipcd_ha_name', local (nil), ip '192.168.254.30', subnet
'192.168.254.0', mask '255.255.255.0', numRef 0, numFail 1, flags 0x1cd }


2013-07-17
13:23:44.428: [GIPCHGEN][3025128336] gipchaInterfaceDisable: disabling
interface 0x9c0bb60
{ host 'single2', haName 'gipcd_ha_name', local 0xb4c4e590, ip '192.168.254.33:16663', subnet
'192.168.254.0', mask '255.255.255.0', numRef 0, numFail 0, flags 0x86 }


2013-07-17
13:23:44.428: [GIPCHALO][3025128336] gipchaLowerCleanInterfaces: performing
cleanup of disabled interface 0x9c0bb60
{ host 'single2', haName 'gipcd_ha_name', local 0xb4c4e590, ip '192.168.254.33:16663', subnet
'192.168.254.0', mask '255.255.255.0', numRef 0, numFail 0, flags 0xa6 } <<<<<<<<
gipcd 开始清理本地私网eth1 的信息,同时也清理掉与之对应的远程节点私网的信息。


……


2013-07-17
13:24:08.747: [GIPCDMON][3027229584] gipcdMonitorSaveInfMetrics: inf[ 0] eth2 - rank 99, avgms 1.955307 [ 204 / 181 / 179 ] <<<<<<<
gipcd 继续检查正常的私网网卡。



注意:在整个过程中,我们还会看到集群的一致性仍然能够保证,不会出现节点离开集群的现象。而且,我们还会看到原来运行在eth1上的HAIP,会failovereth2 上,与此同时,数据库和ASM实例一切正常。



3. 当网卡eht1恢复后。


++ 使用命令”ifconfig eth1 up”恢复网卡eth1


2013-07-17
13:36:31.260: [GIPCDMON][3027229584] gipcdMonitorUpdate: New Interface found -
[ ip 192.168.254.30, subnet 192.168.254.0, mask 255.255.255.0 ]


2013-07-17
13:36:31.260: [GIPCDMON][3027229584] gipcdMonitorUpdate: msg sent to client
thread (([update(ip: 192.168.254.30, mask: 255.255.255.0, subnet
192.168.254.0), state(gipcdadapterstateUp)])) <<<<<
gpicd 发现了新的私网网卡。


……


2013-07-17 13:36:31.471:
[GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created local bootstrap
interface for node 'single1', haName 'gipcd_ha_name', inf
'mcast://230.0.1.0:42424/192.168.254.30'


2013-07-17
13:36:31.471: [GIPCHTHR][3025128336] gipchaWorkerUpdateInterface: created local
interface for node 'single1', haName 'gipcd_ha_name', inf
'192.168.254.30:55548' <<<<<<
本地的通信endpoint被建立。


……


2013-07-17
13:37:11.493: [ CLSINET][3027229584] Returning NETDATA: 2 interfaces


2013-07-17
13:37:11.493: [ CLSINET][3027229584] # 0 Interface
'eth1',ip='192.168.254.30',mac='00-0c-29-a8-14-65',mask='255.255.255.0',net='192.168.254.0',use='cluster_interconnect'


2013-07-17
13:37:11.493: [ CLSINET][3027229584] # 1 Interface
'eth2',ip='192.168.254.31',mac='00-0c-29-a8-14-6f',mask='255.255.255.0',net='192.168.254.0',use='cluster_interconnect'


2013-07-17
13:37:11.510: [GIPCDMON][3027229584] gipcdMonitorSaveInfMetrics: inf[ 0] eth2 - rank 99, avgms 6.141304 [ 307 / 184 / 184 ] <<<<<<<<
<<<<<<<<
gipcd进行私网检查。


注意:在整个过程中,我们还会看到集群的一致性仍然能够保证,不会出现节点离开集群的现象。而且,我们还会看到之前failovereth2上的HAIP,会重新回到eth1 上,与此同时,数据库和ASM实例一切正常。



最后,我们需要强调的是,gipcd 虽然能够管理集群的私网,但是,如果私网网卡本身,或者节点间私网链路(或者性能)存在问题,gipcd仍然无法正常工作。另外,如果您在使用HAIP的同时,仍在使用了第三方的网卡聚合软件(例如:Linux bondingetherchannel等),最好使用最新版本的软件,并且确保配置正确。


希望以上的解释能够对大家了解11gR2 新的守护进程gipcd有些帮助,并且在处理相关问题的时候,能够保持正确的方向。


参与此主题的后续讨论,可以访问我们的中文社区,跟帖“共享:11gR2新特性---gipc守护进程"。

星期四 六月 13, 2013

如何 Relink 11.2 Grid Infrastructure(GI) 和 11.2 RAC?

     对于Oracle Clusterware(CRS) 10g 和11.1, CRS 的binary 不能被 relink。CRS 中的client shared libraries可以被relink, 但是这个relink只有当OS升级或者给OS打补丁出现问题后才需要,大部分时候不需要relink CRS。

     如果想对CRS中的client shared libraries做relink, 请参考MOS文档中的步骤:
     Will an Operating System Upgrade Affect Oracle Clusterware? [ID 743649.1]

     对于Oracle Grid Infrastructure(GI) 11.2 及之后的版本,在GRID HOME中有一些binary需要在OS升级或者打补丁后被relink。
     对于数据库软件(RDBMS binary),在OS升级或者OS打补丁后推荐做relink, RAC 的binary也是一样的,需要relink。

     下面是在11.2 集群环境中执行relink的过程,包括了对GI和RAC做relink的步骤:

1. 首先停止这个节点上的所有数据库实例,这是因为之后停止CRS时虽然会停止数据库实例,但是是以shutdown abort的方式,我们需要以shutdown immediate或者normal来停止数据库实例:
$su - oracle
$srvctl stop instance -d <db_name> -i <instance_name> -o immediate

2. 如果业务需要高可用性,确保这个实例上的service已经切换到了其它节点的实例上。
$ srvctl status service -d <db_name>

3. 用root用户执行<GRID_HOME>/crs/install/rootcrs.pl -unlock来修改相应目录权限并停止GI:
[root@rac1 ~]# cd /u01/app/11.2.0/grid/crs/install
[root@rac1 install]# perl rootcrs.pl -unlock
Using configuration parameter file: ./crsconfig_params


CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'rac1'
CRS-2673: Attempting to stop 'ora.crsd' on 'rac1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'rac1'
CRS-2673: Attempting to stop 'ora.rac2.vip' on 'rac1'
CRS-2673: Attempting to stop 'ora.oc4j' on 'rac1'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'rac1'
CRS-2673: Attempting to stop 'ora.cvu' on 'rac1'
CRS-2677: Stop of 'ora.rac2.vip' on 'rac1' succeeded
CRS-2677: Stop of 'ora.LISTENER_SCAN1.lsnr' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.scan1.vip' on 'rac1'
CRS-2677: Stop of 'ora.scan1.vip' on 'rac1' succeeded
CRS-2677: Stop of 'ora.oc4j' on 'rac1' succeeded
CRS-2677: Stop of 'ora.cvu' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'rac1'
CRS-2673: Attempting to stop 'ora.CRS.dg' on 'rac1'
CRS-2673: Attempting to stop 'ora.racdb.db' on 'rac1'
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.rac1.vip' on 'rac1'
CRS-2677: Stop of 'ora.rac1.vip' on 'rac1' succeeded
CRS-2677: Stop of 'ora.CRS.dg' on 'rac1' succeeded
CRS-2677: Stop of 'ora.racdb.db' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.DATA.dg' on 'rac1'
CRS-2673: Attempting to stop 'ora.RECO.dg' on 'rac1'
CRS-2677: Stop of 'ora.DATA.dg' on 'rac1' succeeded
CRS-2677: Stop of 'ora.RECO.dg' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'rac1'
CRS-2677: Stop of 'ora.asm' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'rac1'
CRS-2677: Stop of 'ora.ons' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'rac1'
CRS-2677: Stop of 'ora.net1.network' on 'rac1' succeeded
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'rac1' has completed
CRS-2677: Stop of 'ora.crsd' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.mdnsd' on 'rac1'
CRS-2673: Attempting to stop 'ora.crf' on 'rac1'
CRS-2673: Attempting to stop 'ora.ctssd' on 'rac1'
CRS-2673: Attempting to stop 'ora.evmd' on 'rac1'
CRS-2673: Attempting to stop 'ora.asm' on 'rac1'
CRS-2677: Stop of 'ora.mdnsd' on 'rac1' succeeded
CRS-2677: Stop of 'ora.crf' on 'rac1' succeeded
CRS-2677: Stop of 'ora.evmd' on 'rac1' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'rac1' succeeded
CRS-2677: Stop of 'ora.asm' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'rac1'
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'rac1'
CRS-2677: Stop of 'ora.cssd' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'rac1'
CRS-2677: Stop of 'ora.gipcd' on 'rac1' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'rac1'
CRS-2677: Stop of 'ora.gpnpd' on 'rac1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'rac1' has completed
CRS-4133: Oracle High Availability Services has been stopped.
Successfully unlock /u01/app/11.2.0/grid

注意,如果在$GRID_HOME/rdbms/audit下面的audit文件很多,会导致rootcrs.pl执行很长时间,这样的话可以将$GRID_HOME/rdbms/audit/*.aud 文件备份到GRID_HOME之外,然后删除。

4. 禁止GI在OS重启后自动启动,这是因为升级OS或者打OS补丁后,可能需要重启主机,这样的话,需要在relink之前禁止GI启动。
用root用户:
[root@rac1 install]# crsctl disable crs
CRS-4621: Oracle High Availability Services autostart is disabled.

5. 备份GI和RDBMS的ORACLE_HOME。

6. 升级OS或者给OS打补丁,包括重启主机等(如果需要)。

7. 用GI的属主用户来对GI binary进行relink:

[root@rac1 audit]# su - grid
[grid@rac1 ~]$ export ORACLE_HOME=/u01/app/11.2.0/grid

确保GI是停止的,然后再执行relink:
[grid@rac1 ~]$ ps -ef|grep d.bin
grid      3408  3360  0 17:09 pts/0    00:00:00 grep d.bin

[grid@rac1 ~]$ crsctl stat res -t
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status failed, or completed with errors.

[grid@rac1 ~]$ $ORACLE_HOME/bin/relink
writing relink log to: /u01/app/11.2.0/grid/install/relink.log

[grid@rac1 ~]$ <===relink结束后,并不会有任何信息提示,只是显示命令提示符。

需要检查/u01/app/11.2.0/grid/install/relink.log, 查看是否有错误。

下面截取了末尾的一些行,如下:
...
 - Linking Oracle
rm -f /u01/app/11.2.0/grid/rdbms/lib/oracle
gcc  -o /u01/app/11.2.0/grid/rdbms/lib/oracle -m64 -L/u01/app/11.2.0/grid/rdbms/lib/ -L/u01/app/11.2.0/grid/lib/ -
...
lsnls11 -lnls11 -lcore11 -lnls11 -lasmclnt11 -lcommon11 -lcore11 -laio    `cat /u01/app/11.2.0/grid/lib/sysliblist` -Wl,-
rpath,/u01/app/11.2.0/grid/lib -lm    `cat /u01/app/11.2.0/grid/lib/sysliblist` -ldl -lm   -L/u01/app/11.2.0/grid/lib
test ! -f /u01/app/11.2.0/grid/bin/oracle ||\
           mv -f /u01/app/11.2.0/grid/bin/oracle /u01/app/11.2.0/grid/bin/oracleO
mv /u01/app/11.2.0/grid/rdbms/lib/oracle /u01/app/11.2.0/grid/bin/oracle
chmod 6751 /u01/app/11.2.0/grid/bin/oracle

8. 用RDBMS的属主对数据库binary做relink:
su - oracle
确保$ORACLE_HOME设置为了数据库的ORACLE_HOME,然后执行:

[oracle@rac1 ~]$ $ORACLE_HOME/bin/relink all
writing relink log to: /u01/app/oracle/product/11.2.0/dbhome_1/install/relink.log
<===relink结束后,并不会有任何信息提示,只是显示命令提示符。

需要检查/u01/app/oracle/product/11.2.0/dbhome_1/install/relink.log, 查看是否有错误。

截取relink.log中部分内容:

Starting Oracle Universal Installer... <<<<<<开头
...
le/product/11.2.0/dbhome_1/lib/sysliblist` -ldl -lm   -L/u01/app/oracle/product/11.2.0/dbhome_1/lib
test ! -f /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle ||\
           mv -f /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle /u01/app/oracle/product/11.2.0/dbhome_1/bin/
oracleO
mv /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/oracle /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle
chmod 6751 /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle <<<<<<结尾

9. 用root用户执行<GRID_HOME>/crs/install/rootcrs.pl -patch来修改相应目录权限并启动GI:

[root@rac1 ~]# cd /u01/app/11.2.0/grid/crs/install
[root@rac1 install]# perl rootcrs.pl -patch
Using configuration parameter file: ./crsconfig_params
CRS-4123: Oracle High Availability Services has been started.

10. Enable CRS来保证主机重启后可以自动启动GI:
[root@rac1 install]# crsctl enable crs
CRS-4622: Oracle High Availability Services autostart is enabled.

11. 确认所有的应启动的资源都已启动:
[root@rac1 install]#  crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS      
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.CRS.dg
               ONLINE  ONLINE       rac1                                        
               ONLINE  ONLINE       rac2                                        
ora.DATA.dg
               ONLINE  ONLINE       rac1                                        
               ONLINE  ONLINE       rac2                                        
ora.LISTENER.lsnr
               ONLINE  ONLINE       rac1                                        
               ONLINE  ONLINE       rac2                                        
ora.RECO.dg
               ONLINE  ONLINE       rac1                                        
               ONLINE  ONLINE       rac2                                        
ora.asm
               ONLINE  ONLINE       rac1                     Started            
               ONLINE  ONLINE       rac2                     Started            
ora.gsd
               OFFLINE OFFLINE      rac1                                        
               OFFLINE OFFLINE      rac2                                        
ora.net1.network
               ONLINE  ONLINE       rac1                                        
               ONLINE  ONLINE       rac2                                        
ora.ons
               ONLINE  ONLINE       rac1                                        
               ONLINE  ONLINE       rac2                                        
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       rac2                                        
ora.cvu
      1        ONLINE  ONLINE       rac2                                        
ora.oc4j
      1        ONLINE  ONLINE       rac2                                        
ora.rac1.vip
      1        ONLINE  ONLINE       rac1                                        
ora.rac2.vip
      1        ONLINE  ONLINE       rac2                                        
ora.racdb.db
      1        ONLINE  ONLINE       rac2                     Open               
      2        OFFLINE OFFLINE                               Instance Shutdown  
ora.scan1.vip
      1        ONLINE  ONLINE       rac2                                        

如果发现实例没有启动,可以手工启动:
$srvctl start instance -d <db_name> -i <instance_name>

12. 可以用下面的MOS文档中的方法来确认oracle 的binary是RAC的:
How to Check Whether Oracle Binary/Instance is RAC Enabled and Relink Oracle Binary in RAC [ID 284785.1]

方法1:如果下面的命令能查出kcsm.o ,说明binary是RAC的:
su - oracle
$ar -t $ORACLE_HOME/rdbms/lib/libknlopt.a|grep kcsm.o
kcsm.o

在AIX上命令是不同的:
 ar -X32_64 -t $ORACLE_HOME/rdbms/lib/libknlopt.a|grep kcsm.o

方法2:查看RAC特有的后台进程是否存在,比如:
[grid@rac1 ~]$ ps -ef|grep lmon
grid      7732     1  0 17:59 ?        00:00:17 asm_lmon_+ASM1
oracle   18605     1  0 20:49 ?        00:00:00 ora_lmon_RACDB1 <===========
grid     20992 10160  0 21:10 pts/2    00:00:00 grep lmon

上面的所有步骤需要在集群的各个节点上依次执行。

上述relink GI的过程来源于下面MOS文档中章节 “Do I need to relink the Oracle Clusterware / Grid Infrastructure home after an OS upgrade?”
 RAC: Frequently Asked Questions [ID 220970.1]


参与此主题的后续讨论,可以访问我们的中文社区,跟帖“分享: 如何 Relink 11.2 Grid Infrastructure(GI) 和 11.2 RAC?"


注意上面的过程适用于集群环境,对于单机版的GI (即Restart),请参考MOS下面的文档来进行relink:
How To Relink The Oracle Grid Infrastructure Standalone (Restart) Installation (Non-RAC). [ID 1536057.1]

星期二 四月 23, 2013

安装Oracle Grid Infrastructure Patch Set Update(GI PSU)的主要步骤

         安装任何补丁时一定要仔细阅读补丁对应的 readme 文件,因为每个补丁的安装步骤可能有所不同。下面以GI PSU 11.2.0.3.6 (补丁号16083653)为例,介绍一下打GI PSU 的主要步骤和注意事项:

      由于在Grid Infrastructure Patch Set Update(以下简称GI PSU)中包括了DB的PSU,所以只要下载并按照GI PSU 的readme安装补丁,并使用opatch auto 就可以把GI和数据库的PSU都安装上,而且使用opatch auto 的好处是完全的自动化,不需要手工停止/启动GI。安装完成后,在GI和DB的ORACLE_HOME会分别安装了GI和DB的PSU,也就是每个ORACLE_HOME下都有两个PSU,一个是GI的,一个是DB的。推荐这种安装方法,因为有的Bug既需要在GI中修复,又需要在DB中修复。


需要注意的是,如果在数据库(RDBMS)的ORACLE_HOME下没有创建任何数据库,也就是在OCR中找不到这个ORACLE_HOME下的数据库,那么opatch auto 并不会把PSU安装在这个ORACLE_HOME下,只会把PSU安装在GI的ORACLE_HOME下。这种情况下,如果要对数据库的ORACLE_HOME安装PSU,需要另外执行: # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <RAC_HOME>,见MOS文档1361802.1和1479651.1。

    安装PSU的过程是滚动的(Rolling),也就是先在一台节点按照readme中的步骤安装这个PSU,当这台执行完毕,所以资源都启动后,依次在其它节点执行。注意,opatch auto不能在多个节点同时执行。


     下面列出GI PSU 的主要步骤和需要注意的事项:

(下面的章节号与readme相对应)

2.1.1. 推荐下载最新的补丁安装工具opatch :
$ <ORACLE_HOME>/OPatch/opatch version
保证opatch的版本高于readme中要求的版本,否则的话,请下载最新的opatch:
https://updates.oracle.com/download/6880880.html

把 GRID_HOME和DB_HOME上的<ORACLE_HOME>/OPatch/进行备份,然后将下载的补丁6880880解压为<ORACLE_HOME>/OPatch。
$ unzip <OPATCH-ZIP> -d <ORACLE_HOME>
$ <ORACLE_HOME>/OPatch/opatch version

2.1.2 如果没有配置OCM,按照下面的步骤执行:
As grid user: $GRID_HOME/OPatch/ocm/bin/emocmrsp
It will be created in /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp

2.1.3 执行下面的命令来确保输出的结果正确:
su - grid
$ <GRID_HOME>/OPatch/opatch lsinventory -detail -oh <GRIG_HOME>
su - oracle
$ <DB_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME>

2.1.4 下载并解压GI PSU  11.2.0.3.6 :
https://updates.oracle.com/download/16083653.html

用grid 用户来上传到服务器并且解压(不要上传到/tmp)。
$ cd <UNZIPPED_PATCH_LOCATION>
$ unzip p16083653_112030_AIX64-5L.zip

比如:
$ cd /u01/oracle/patches
$ unzip p16083653_112030_AIX64-5L.zip

2.1.5 在安装或者回滚PSU前必须用数据库的属主(一般为oracle)把EM agent停止:
su - oracle
$ <DB_HOME>/bin/emctl stop dbconsole

2.2 检查补丁冲突
用grid用户:
$ cd <UNZIPPED_PATCH_LOCATION>
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail  -phBaseDir ./

2.4 补丁安装
Case 1:: 适用于GI和DB的ORACLE_HOME都在本地盘, 不在共享盘,而且没有使用ACFS

必须用root身份安装补丁(不需要停止GI)

# opatch auto <UNZIPPED_PATCH_LOCATION> -ocmrf <ocm response file>

比如:
# opatch auto /u01/oracle/patches -ocmrf  /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp

执行了这个命令后,会自动停止这个节点上的GI和所有资源;
然后在GI和DB的ORACLE_HOME下都安装GI 和DB的PSU;
最后会将这个节点上的GI和资源都启动。

上面的所有步骤在一台节点执行完后,在其他节点依次执行。千万不要同时在两个节点执行opatch auto 命令。

2.5 Patch Post-InstallationInstructions
2.5.2 在任意一台节点用oracle用户连接到数据库上(只需在一台节点执行一次,不需要所有节点都执行):

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT

2.5.3 如果您使用了RMAN,需要将您的RMAN catalog库升级一下,执行:
$ rman catalog username/password@alias
RMAN> UPGRADE CATALOG;

上面是主要的步骤,请参考readme来查看具体的信息。

星期一 十二月 10, 2012

如何升级Oracle Grid Infrastructure 11.2.0.2到11.2.0.3.pdf

下载 Upgrade_Oracle_Grid_Infrastructure_11.2.0.2_to_11.2.0.3.pdf.zip


文中包括截图和具体的步骤来升级Oracle GI 11.2.0.2到11.2.0.3。升级11.2.0.1到11.2.0.3也是类似的。
文中只包括升级GI的过程,升级DB的暂时不包括。

星期六 三月 31, 2012

Redundant Interconnect with Highly Available IP (HAIP) 简介

  从11.2.0.2开始,Oracle 的集群软件Grid Infrastructure(GI)中新增了Redundant Interconnect with Highly Available IP(HAIP),以实现集群私网的高可用性和负载均衡。

  在11.2.0.2之前,私网的冗余一般是通过在OS上做网卡绑(如bonding, EtherChannel等)实现的,有了HAIP之后,无需使用网卡绑定就可以实现私网网卡的冗余。

  在安装GI的过程中,可以定义多个私网网卡来实现私网的冗余,如图:



  安装后,HAIP地址自动设置为169.254.*.*,这个地址不可以手动设置。HAIP 最少为1个,最多为4个(1块网卡,1个HAIP;2块网卡,2个HAIP; 3块及以上,4个HAIP), 均匀的分布在私网的网卡上。


案例:
1. 查看HAIP资源状态
$ crsctl stat res -t -init
NAME                              
TARGET  STATE        SERVER   STATE_DETAILS  Cluster Resources
-------------------------------------------------------------------------------------------------
ora.cluster_interconnect.haip    
ONLINE  ONLINE        node2                      1

2.查看HAIP地址和分布情况。
#ifconfig -a
eth1      Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:66
          inet addr:192.168.254.32  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4b:b766/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
......

eth1:1    Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:66
          inet addr:169.254.31.199  Bcast:169.254.127.255  Mask:255.255.128.0  <=====HAIP address one.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:193 Base address:0x1800

eth2      Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:70
          inet addr:192.168.254.33  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4b:b770/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
......

eth2:1    Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:70
          inet addr:169.254.185.222  Bcast:169.254.255.255  Mask:255.255.128.0  <=====HAIP address two.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:169 Base address:0x1880

haip均匀的分布在两个私网网卡上。

3. 断掉网卡eth1之后。
eth2      Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:70
          inet addr:192.168.254.33  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4b:b770/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3206 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3916 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1474658 (1.4 MiB)  TX bytes:2838774 (2.7 MiB)
          Interrupt:169 Base address:0x1880

eth2:1    Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:70
          inet addr:169.254.185.222  Bcast:169.254.255.255  Mask:255.255.128.0 <=====HAIP address two.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:169 Base address:0x1880

eth2:2    Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:70
          inet addr:169.254.31.199  Bcast:169.254.127.255  Mask:255.255.128.0 <=====HAIP address one.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:169 Base address:0x1880

HAIP one 漂移到了网卡eth2上。

4. 网卡eth1恢复之后。
eth1      Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:66
          inet addr:192.168.254.32  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4b:b766/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
......

eth1:1    Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:66
          inet addr:169.254.31.199  Bcast:169.254.127.255  Mask:255.255.128.0 <=====HAIP address one.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:193 Base address:0x1800

eth2      Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:70
          inet addr:192.168.254.33  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4b:b770/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
......

eth2:1    Link encap:Ethernet  HWaddr 00:0C:29:4B:B7:70
          inet addr:169.254.185.222  Bcast:169.254.255.255  Mask:255.255.128.0 <=====HAIP address two.
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:169 Base address:0x1880

HAIP one 回到了网卡eth1上。

注意:HAIP地址失败不会对ocssd产生影响,也就是说HAIP失败,不会导致节点重启。


HAIP 对数据库和ASM的影响

数据库和ASM实例使用这个HAIP作为cluster interconnect,以下是alert.log的片段。

Cluster communication is configured to use the following interface(s) for this instance
  169.254.31.199
  169.254.185.222
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2

Oracle数据库和ASM实例可以通过HAIP来实现私网通讯的高可用性和负载均衡。私网的流量会在这些私网网卡上实现负载均衡,
如果某个网卡出现了故障,它上面的HAIP会自动切换到别的可用的私网网卡上,从而不影响私网的通讯。

注意:HAIP 是不允许被手动停止或禁用的,除非是由于某些版本或者平台不支持。


关于HAIP的更多介绍,请参考My Oracle Support Note 文档1210883.1.



星期四 一月 19, 2012

11gR2集群件任务角色分离(Job Role Separation)简介

   在这篇文章中,我们将对11gR2 的新特性任务角色分离(Job Role Separation)进行介绍。

   在11gR2,操作系统用户grid成为了集群件(GI)的owner,并且ASM成为了集群件的一部分,所以grid用户也成为了ASM 磁盘的owner。

   通常有3种方式配置ASM磁盘,asmlib, 裸设备和块设备。

1. asmlib

配置asm 磁盘的owner和group。

# /etc/init.d/oracleasm configure

…..

Default user to own the driver interface []: grid

Default group to own the driver interface []: asmadmin

……

查看ASM磁盘的设置:

ls –l /dev/oracleasm/disks

brw-rw---- 1 grid asmadmin 8, 33 Jul 2 18:21 DATA

注意: 从linux 2.6 内核开始,块设备的权限和路径配置在重启之后不再被保留,除非使用udev 创建规则文件固定。例如块设备/dev/sda在重启之后可能变成/dev/sdb。如果使用udev,那么在添加新磁盘时,需要修改规则文件以确保设备名和权限在重启之后不发生改变。

   如果使用asmlib, 只需要确定作为asm 磁盘的范围,asmlib会维护磁盘的标签和权限,以便在操作系统升级后磁盘标签仍然有效。 所以,asmlib 和udev实现的功能基本是相同的。

2. 裸设备。按照以下设置配置磁盘的owner和group:

crw-rw---- 1 grid asmadmin 162, 1 Jul 18 21:40 /dev/raw/raw1

3.块设备。按照以下设置配置磁盘的owner和group:

# chown grid:asmadmin /dev/rhdiskn

# chmod 660 /dev/rhdiskn

  接下来解释任务角色分离中oracle可执行文件的权限和group 设置。

  在上面的例子中,ASM磁盘的group是asmadmin,这意味着组asmadmin中的成员可以对asm磁盘进行读写操作,当然grid用户也可以。而其他用户,例如oracle,则需要通过oracle_home/bin下的oracle可执行文件访问asm 磁盘。

  这意味着oracle可执行文件不仅需要黏着位(stick bit),还需要是设置group 为asmadmin。当使用srvctl(srvctl start database/instance)启动数据库时oracle会自动调用<rdbms_home>/bin/setasmgid设置oracle 可执行文件的group为asmadmin。

   所以,如果问题出现在oracle不能访问asm 磁盘,需要检查以下的内容。当然由于oracle 可以直接访问asm磁盘,而不需要通过asm 实例,所以问题的症状可能很多,甚至ora-600错误都可能是这个原因。

1. Asmlib标识过的磁盘的权限和group设置

brw-rw---- 1 grid asmadmin 8, 49 Dec 31 12:14 DATA

2. 裸设备或者块设备的权限和group设置

crw-rw---- 1 grid asmadmin 162, 1 Jul 18 21:40 /dev/raw/raw1

3. RDBMS和GI 主目录下的oracle可执行文件的权限和group设置

rdbms_home : -rwsr-s--x 1 oracle asmadmin 188832561 Oct 30 21:22 oracle

gi_home: -rwsr-s--x 1 grid oinstall 166530359 Nov 16 14:31 oracle

  注意黏着位(stick bit)的设置

  最后我们对11gR2中安装oracle 集群件和数据库软件中的一些group进行简单的介绍。

    *      oinstall : 这个group是GI 和RDBMS软件的拥有者。
    *      dba : 这个group是数据库的dba group, 对数据库具有最高权限。
    *      asmdba : 这个group是asm实例的dba group, 可以启动/关闭实例,挂载/卸载asm 磁盘组。
    *      asmadmin: 这个group是asm的管理员group,它包含asmdba的全部权限,同时还可以增加/删除 asm 磁盘,磁盘组等。

About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 四月 2014
星期日星期一星期二星期三星期四星期五星期六
  
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今天