Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

999

积分

1

好友

942

主题
1#
发表于 2013-11-17 16:54:26 | 查看: 3125| 回复: 1
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) 简介”。

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


下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569     邮箱:service@parnassusdata.com
2#
发表于 2013-11-17 16:54:45
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,会failover到eth2 上,与此同时,数据库和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进行私网检查。

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

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

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

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

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-21 10:35 , Processed in 0.072179 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569