星期三 九月 04, 2013

如何升级Oracle Grid Infrastructure和RAC从11.2.0.3到11.2.0.4?

把GI 和 RAC从 11.2.0.3升级到11.2.0.4的主要步骤:

1. 升级GI


1) 下载11.2.0.4 GI软件:
11.2.0.4的下载链接:
https://updates.oracle.com/download/13390677.html
p13390677_112040_platform_3of7.zip是 Oracle Grid Infrastructure (includes Oracle ASM, Oracle Clusterware, and Oracle Restart)。
2) 安装11.2.0.4 GI到一个新的ORACLE_HOME(不要停止旧的GI,所有节点GI都启动)。
3) 安装的时候选择“Upgrade Oracle Grid Infrastructure or Oracle Automatic Storage Management”。
4) 安装结束时,根据提示用root用户在各个节点依次执行rootupgrade.sh 。
5) 修改grid用户的环境变量ORACLE_HOME 和 PATH 等到新的路径
6) 参考 11.2 GI 升级的官方文档:
Oracle® Grid Infrastructure Installation Guide
11g Release 2 (11.2) for Linux
E41961-02
F How to Upgrade to Oracle Grid Infrastructure 11g Release 2
http://docs.oracle.com/cd/E11882_01/install.112/e41961/procstop.htm#BABEHGJG

2. 升级RAC数据库软件
1) 下载 11.2.0.4数据库软件:
https://updates.oracle.com/download/13390677.html
p13390677_112040_platform_1of7.zip
p13390677_112040_platform_2of7.zip
上面的两个补丁包是Oracle Database (includes Oracle Database and Oracle RAC)。
2) 在安装前一定要取消oracle用户的ORACLE_BASE, ORACLE_HOME, ORACLE_SID等的设置。
3) 安装 11.2.0.4 RAC 到一个新的ORACLE_HOME,选择只安装软件不建库(Install database software only)
4) 在安装11.2.0.4的过程中设置正确的ORACLE_BASE and ORACLE_HOME.
5) 安装的要求请参考11.2官方文档:
Oracle® Real Application Clusters Installation Guide
11g Release 2 (11.2) for Linux and UNIX
E41962-03
http://docs.oracle.com/cd/E11882_01/install.112/e41962/chklist.htm

3. 升级已有的数据库
1) 升级前一定要备份数据库。
2) 运行utlu112i.sql 来进行升级前的检查(数据库是启动的):
su - oracle
export ORACLE_HOME=旧的ORACLE_HOME
export ORACLE_SID=实例名
$ORACLE_HOME/bin/sqlplus / as sysdba
SQL> @/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/utlu112i.sql <==这是新的ORACLE_HOME下面的脚本,修正这个脚本所发现的所有问题。
3) 运行11.2.0.4的DBUA来升级数据库:
<新的ORACLE_HOME>/bin/dbua
DBUA 将会执行的工作:
-DBUA会从/etc/oratab获得数据库的信息
- 停止数据库和DBConsole
- 在新的ORACLE_HOME创建密码文件
- 拷贝spfile到新的ORACLE_HOME 并且去除obsolete的参数
- 在DBUA中可以选择备份数据库
- 在DBUA中可以把数据文件从file system/raw devices 迁移到ASM (需要保证diskgroup是mount的)
4) 修改oracle用户的环境变量ORACLE_HOME 和 PATH 等到新的路径
5) 请参考 数据库升级到11.2的官方文档:
Oracle® Database Upgrade Guide
11g Release 2 (11.2)
E23633-09
http://docs.oracle.com/cd/E11882_01/server.112/e23633/upgrade.htm

请下载具体的步骤和截图文档:


How_To_Upgrade_11.2.0.3_To_11.2.0.4.zip.001,


How_To_Upgrade_11.2.0.3_To_11.2.0.4.zip.002


右键点击“保存”下载,下载两个文件后解压。


关于这个问题的讨论,请参与中文数据库社区帖子: 把GI 和 RAC从 11.2.0.3升级到11.2.0.4的步骤(带截屏)

星期三 八月 14, 2013

如何在11.2集群中添加/删除资源?

     在11.2,数据库、监听、VIP、ASM、磁盘组等都属于GI所管理的资源,有的时候需要添加、删除、修改资源属性等,都是使用crsctl命令来操作的。
     注意在集群中添加和删除资源只是将它从OCR中注册或者移除,并不是真正的将这个资源删掉。比如diskgroup这个资源,用crsctl add/delete并不会把这个磁盘组删除。


     下面列出了GI所管理的资源:
-bash-3.00$ crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
               ONLINE  ONLINE       rac1                                     
               ONLINE  ONLINE       rac2                                     
ora.LISTENER.lsnr
               ONLINE  ONLINE       rac1                                     
               ONLINE  OFFLINE      rac2                                     
ora.OCR_VOTE.dg
               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
               ONLINE  OFFLINE      rac1                                     
               ONLINE  OFFLINE      rac2                                     
ora.net1.network
               ONLINE  ONLINE       rac1                                     
               ONLINE  OFFLINE      rac2                                     
ora.ons
               ONLINE  ONLINE       rac1                                     
               ONLINE  OFFLINE      rac2                                     
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       rac1                                     
ora.cvu
      1        ONLINE  ONLINE       rac1                                     
ora.rac1.vip
      1        ONLINE  ONLINE       rac1                                     
ora.rac2.vip
      1        ONLINE  INTERMEDIATE rac1                 FAILED OVER         
ora.oc4j
      1        ONLINE  ONLINE       rac1                                     
ora.rac11g2.db
      1        ONLINE  ONLINE       rac1                 Open                
      2        ONLINE  ONLINE       rac2                 Open                
ora.scan1.vip
      1        ONLINE  ONLINE       rac1                          

官方文档中有添加、删除、修改资源的详细命令和解释:
http://docs.oracle.com/cd/E11882_01/rac.112/e16794/crsref.htm#CHDFEFBJ
Oracle Clusterware Administration and Deployment Guide
11g Release 2 (11.2)
E16794-17

添加资源:
crsctl add resource resource_name -type resource_type [-file file_path |
-attr "attribute_name=attribute_value,attribute_name=attribute_value,..."]
[-i] [-f]

resource_name A short, descriptive name for the resource. (
resource_name: 资源名)
-type resource_type The type of resource that you are adding preceded by the -type flag.(-type 资源类型)
-file file_path Path name (either absolute or relative) for a text file containing line-separated attribute name-value pairs that define the resource.
-attr "attribute_name= attribute_value (-attr: 资源属性以及对应的值,不同类型的资源对应的属性不同)
-i If you specify -i, then the command returns an error if processing this command requires waiting for Oracle Clusterware to unlock the resource or its dependents. Sometimes, Oracle Clusterware locks resources or other objects to prevent commands from interfering with each other.
-f Use the force option:(-f : 强制添加,忽略依赖性)
    To add a resource that has dependencies on other resources that do not yet exist. The force option overrides checks that would prevent a command from being completed.
    To add a resource if the resource has hard dependencies on other resources and the owner of the resources does not execute permissions on one or more of the dependencies. If you do not specify the force option in this case, an error displays.
    To add resources of application type because you may need to move servers into the Generic server pool. If the servers currently host resources that must be stopped, then the force option is required

删除资源:
crsctl delete resource resource_name [-i] [-f]

resource_name Specify the name of the resource you want to remove.
-i If you specify -i, then the command returns an error if processing this command requires waiting for Oracle Clusterware to unlock the resource or its dependents. Sometimes, Oracle Clusterware locks resources or other objects to prevent commands from interfering with each other.
-f Use the force option to remove either running resources, or remove this resource even though other resources have a hard dependency on it.(-f 强制删除,即使这个资源在运行或者有其他资源依赖于它)

修改资源:
crsctl modify resource resource_name -attr "attribute_name=attribute_value"
[-i] [-f] [-delete]

resource_name The name of the resource you want to modify.
-attr "attribute_name=attribute_value"
-i If you specify -i, then the command returns an error if processing this command requires waiting for Oracle Clusterware to unlock the resource or its dependents. Sometimes, Oracle Clusterware locks resources or other objects to prevent commands from interfering with each other.
-f Use the -f option when:
    The resource has a hard dependency on a non-existing resource
    The owner of the resource does not have execute permissions on one or more hard dependencies
    The modification results in servers being moved into the Generic pool and resources being stopped or relocated to accomplish the server move
-delete If you specify the -delete option, then Oracle Clusterware deletes the named attribute.

下面是在11.2.0.3上删除和添加diskgroup ora.RECO.dg的例子:

主要用到的命令:
su - grid

1. 停止依赖于磁盘组ora.RECO.dg的所有数据库:
$ srvctl stop database -d <db_name>

2. 查看ora.RECO.dg的配置信息:
-bash-3.00$ crsctl stat  res ora.RECO.dg -p   
NAME=ora.RECO.dg                                                          
TYPE=ora.diskgroup.type                                                    
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r-- <===这个信息在添加资源的使用需要                           
...
VERSION=11.2.0.3.0    

3. 停止ora.RECO.dg:
-bash-3.00$ crsctl stop  res ora.RECO.dg -f                            

4. 从集群中移除ora.RECO.dg:
-bash-3.00$ crsctl delete  res ora.RECO.dg -f  

5. 将ora.RECO.dg添加到集群中:
-bash-3.00$ crsctl add  res ora.RECO.dg -type ora.diskgroup.type -attr "ACL='owner:grid:rwx,pgrp:oinstall:rwx,other::r-
-',AUTO_START=always,VERSION=11.2.0.3.0" -i


6. 检查资源的配置信息是正确的:
-bash-3.00$ crsctl stat  res ora.RECO.dg -p

7. 将这个资源启动:
-bash-3.00$ crsctl start  res ora.RECO.dg        
-bash-3.00$ crsctl stat  res -t

8. 启动所有依赖于这个磁盘组的数据库:
$ srvctl start database -d <db_name>

具体的测试过程及输出:

su - grid

1. 停止依赖于磁盘组ora.RECO.dg的所有数据库:
$ srvctl stop database -d RAC11G2

2. 查看ora.RECO.dg的配置信息:

-bash-3.00$ crsctl stat  res ora.RECO.dg -p                                
NAME=ora.RECO.dg                                                          
TYPE=ora.diskgroup.type                                                    
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r--                            
ACTION_FAILURE_TEMPLATE=                                                  
ACTION_SCRIPT=                                                            
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%                    
ALIAS_NAME=                                                                
AUTO_START=always                                                          
CHECK_INTERVAL=300                                                        
CHECK_TIMEOUT=30                                                          
DEFAULT_TEMPLATE=                                                          
DEGREE=1                                                                  
DESCRIPTION=CRS resource type definition for ASM disk group resource      
ENABLED=1                                                                  
LOAD=1                                                                    
LOGGING_LEVEL=1                                                            
NLS_LANG=                                                                  
NOT_RESTARTING_TEMPLATE=                                                  
OFFLINE_CHECK_INTERVAL=0                                                  
PROFILE_CHANGE_TEMPLATE=                                                  
RESTART_ATTEMPTS=5                                                        
SCRIPT_TIMEOUT=60                                                          
START_DEPENDENCIES=hard(ora.asm) pullup(ora.asm)                          
START_TIMEOUT=900                                                          
STATE_CHANGE_TEMPLATE=                                                    
STOP_DEPENDENCIES=hard(intermediate:ora.asm)                              
STOP_TIMEOUT=180                                                          
TYPE_VERSION=1.2                                                          
UPTIME_THRESHOLD=1d                                                        
USR_ORA_ENV=                                                              
USR_ORA_OPI=false                                                          
USR_ORA_STOP_MODE=                                                        
VERSION=11.2.0.3.0                                                        

3. 停止ora.RECO.dg:
-bash-3.00$ crsctl stop  res ora.RECO.dg -f                            
CRS-2673: Attempting to stop 'ora.RECO.dg' on 'rac2'              
CRS-2673: Attempting to stop 'ora.RECO.dg' on 'rac1'              
CRS-2677: Stop of 'ora.RECO.dg' on 'rac2' succeeded                
CRS-2677: Stop of 'ora.RECO.dg' on 'rac1' succeeded                

4. 从集群中移除ora.RECO.dg:
-bash-3.00$ crsctl delete  res ora.RECO.dg   <==如果有不加-f, 当有资源依赖于这个磁盘组时会报错                          
CRS-2730: Resource 'ora.rac11g2.db' depends on resource 'ora.RECO.dg'   
CRS-4000: Command Delete failed, or completed with errors.            

-bash-3.00$ crsctl delete  res ora.RECO.dg -f      <=====需要使用-f来强制删除

5. 将ora.RECO.dg添加到集群中:
-bash-3.00$ crsctl add  res ora.RECO.dg -type ora.diskgroup.type -attr "ACL='owner:grid:rwx,pgrp:oinstall:rwx,other::r-

-',AUTO_START=always,VERSION=11.2.0.3.0" -i

6. 检查资源的配置信息是正确的:

-bash-3.00$ crsctl stat  res ora.RECO.dg -p
NAME=ora.RECO.dg
TYPE=ora.diskgroup.type
ACL=owner:grid:rwx,pgrp:oinstall:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
ALIAS_NAME=
AUTO_START=always
CHECK_INTERVAL=300
CHECK_TIMEOUT=30
DEFAULT_TEMPLATE=
DEGREE=1
DESCRIPTION=CRS resource type definition for ASM disk group resource
ENABLED=1
LOAD=1
LOGGING_LEVEL=1
NLS_LANG=
NOT_RESTARTING_TEMPLATE=
OFFLINE_CHECK_INTERVAL=0
PROFILE_CHANGE_TEMPLATE=
RESTART_ATTEMPTS=5
SCRIPT_TIMEOUT=60
START_DEPENDENCIES=hard(ora.asm) pullup(ora.asm)
START_TIMEOUT=900
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=hard(intermediate:ora.asm)
STOP_TIMEOUT=180
TYPE_VERSION=1.2
UPTIME_THRESHOLD=1d
USR_ORA_ENV=
USR_ORA_OPI=false
USR_ORA_STOP_MODE=
VERSION=11.2.0.3.0

7. 将这个资源启动:
-bash-3.00$ crsctl start  res ora.RECO.dg        
CRS-2672: Attempting to start 'ora.RECO.dg' on 'rac1'
CRS-2672: Attempting to start 'ora.RECO.dg' on 'rac2'
CRS-2676: Start of 'ora.RECO.dg' on 'rac1' succeeded
CRS-2676: Start of 'ora.RECO.dg' on 'rac2' succeeded

-bash-3.00$ crsctl stat  res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       Local Resources
--------------------------------------------------------------------------------
ora.RECO.dg
              ONLINE  ONLINE       rac1                                    
              ONLINE  ONLINE       rac2                                    

8.启动所有依赖于这个磁盘组的数据库:
$ srvctl start database -d RAC11G2 


 参与此主题的后续讨论,可以访问我们的中文社区,跟帖“如何在11.2集群中添加/删除资源?"。

星期四 八月 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守护进程"。

星期一 七月 29, 2013

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


在这篇文章中,我们会对11gR2 新的守护进程(资源名称ora.gpnpd)进行介绍,其中包含的gpnp的功能,启动顺序和基本的诊断方法。


我们知道,在10gR211gR1的版本中,当启动集群的时候,所有的配置信息都要从OCR进行读取,而OCR有存放在共享内存中,这样做实际上并不是很好,因为我们相当于把集群所有的配置信息都存放到了共享存储上,而一旦某个节点对共享存储的访问出现了问题,这个节点就不能加入集群,对集群的影响是很大的,所以,从11gR2开始,GI(Grid Infrastructure) 开始把集群的配置信息进行本地化,例如:
OLR
gpnp profile 被引入。随着我们将集群中重要的信息分别存放到了各个节点,我们也会发现,从11gR2开始,如果OCR出现了问题,仅仅是某些集群的资源(由CRSD管理的资源)会出现问题,而集群(cssd层面)仍然可以正常运行。


接下来,我们对gpnp profile gpnpd守护进程进行一些介绍。首先,gpnp profile(这是个xml文件,而对于gpnp wallet文件,我们并不做过多的介绍)用于存放构建集群的bootstrap 信息,或者可以称为构建集群的最基本的信息,其中包括,集群名称,集群GUID, ASM discovery string, 公网和私网信息等等。所以,当我们在启动集群的某一个节点时,需要读取这个文件(默认文件名为<gi_home>/gpnp/<node_name>/profiles/peer/profile.xml,从而获得构建集群的基本信息。另外,由于这个文件中保存的是整个集群的基本信息,所以这个文件在所有节点之间都应该是相同的。同时,我们还需要一个守护进程,也就是gpnpd.bin(资源名为 ora.gpnpd) 来对gpnp profile 进行维护。举个例子,一个3节点的集群,其中节点3由于一些问题暂时没有启动,而在此期间,集群的私网配置发生了改变,之后,节点3启动,在启动的过程中,节点3gpnpd进程需要和其他节点的gpnpd进程通信,获得最新版本的gpnp profile


下面,我们对 gpnpd守护进程的功能进行一些介绍。


1. 这个进程是由ohasd oraagent 负责管理的。


2. 通过gpnp wallet文件进行验证并负责读取gpnp prfofile。当然,如果gpnpd发现本地的gpnp profile 无法读取,会尝试从OLR的信息中重建gpnp profile


3. gpnp profile的客户(例如ocssd.bin)发布信息。


4. 发现集群中其他节点的gpnpd 守护进程,如果有需要,通过mdns 同步在节点间同步gpnp profile


5. 如果集群的配置发生改变,有必要的话,修改gpnp profile.


接下来,我们通过启动集群过程中的一段gpnpd.log来对以上的内容进行进一步的了解。


2013-07-26 21:31:44.208: [ default][4143449792]gpnpd
START pid=<xxxx> Oracle Grid Plug-and-Play Daemon <<<<<< gpnpd.bin
守护进程被启动。


……


2013-07-26 21:31:45.234: [ GPNP][4143449792]clsgpnpkwf_initwfloc: [at
clsgpnpkwf.c:399] Using FS Wallet Location : <gi_home>/gpnp/<node_name>/wallets/peer/
<<<<<<<<<< gpnp
wallet 文件被访问


……


2013-07-26 21:31:45.349: [ default][4143449792]GPNPD
started on node XXXXX.


2013-07-26 21:31:45.350: [ GPNP][4143449792]clsgpnpd_MainWork: [at
clsgpnpd.c:4836] --- Local best profile:


2013-07-26 21:31:45.350: [ GPNP][4143449792]clsgpnpd_MainWork:
<?xml version="1.0"
encoding="UTF-8"?><gpnp:GPnP-Profile Version[cont]


……


2013-07-26 21:31:45.350: [ GPNP][4143449792]clsgpnpd_MainWork:
usterName="XXXXXX"
PALocation=""><gpnp:Network-Profile><[cont]


2013-07-26 21:31:45.351: [ GPNP][4143449792]clsgpnpd_MainWork:
gpnp:HostNetwork id="gen" HostName="*"><gpnp:Network
id="net1" I[cont]


2013-07-26 21:31:45.351: [ GPNP][4143449792]clsgpnpd_MainWork:
P="XXX.XXX.XXX.XXX" Adapter="eth1"
Use="cluster_interconnect"/><gpn[cont]


2013-07-26 21:31:45.351: [ GPNP][4143449792]clsgpnpd_MainWork:
p:Network id="net2" IP="XXX.XXX.XXX.XXX "
Adapter="eth0" Use="public[cont]
<<<<<<<<<< gpnp pofile
被读取。


……


2013-07-26 21:31:46.162: [ GPNP][4143449792]clsgpnpdRCB: [at
clsgpnpd.c:3933] GPnPD endpoint url "mdns:gpnp._tcp://XXXXX:27230/agent=gpnpd,cname=xxxxx,host=xxxxx,pid=xxxx/gpnpd
h:****** c:*******" successfully advertised with RD <<<<<< gpnpd
通过mdns发布了本地节点的endpoint.


2013-07-26 21:31:51.375: [ GPNP][120384416]clsgpnp_profileCallUrlInt:
[at clsgpnp.c:2104] put-profile call to url "tcp://xxxxx:56182" disco
"mdns:service:gpnp._tcp.local.://xxxxxx:56182/agent=gpnpd,cname=xxxxxxxxx,guid=6de9b87c2edadf6fbf4bb1fcf61e2fa0,host=xxxxxxx,pid=xxxxxx/gpnpd
h:****c:****u:6de9b87c2edadf6fbf4bb1fcf61" [f=0 claimed- host:****
cname:****** seq:4 auth:CN=GPnP_peer] <<<<<<<<
同时,gpnpd也通过mdns,在网络中搜索其他的节点。如果,网络中有多个集群(版本为11gR2 或者12c,那么其他集群的节点也会被发现,但是,gpnpd会通过集群的GUID进行区分。


……


2013-07-26 21:32:00.954: [ GPNP][120384416]clsgpnp_profileCallUrlInt:
[at clsgpnp.c:2104] put-profile call to url "tcp://xxxxx:32774" disco
"mdns:service:gpnp._tcp.local.://xxxxxx:32774/agent=gpnpd,cname=xxxxxxxxx,host=xxxxxx,pid=8023/gpnpd
h:*** c:****" [f=0 claimed- host:**** cname:***** seq:4
auth:CN=GPnP_peer] <<<<<<<<<
集群的另外一个节点XXXXX被发现,gpnpd 确认是否有必要在两个节点间同步gpnp profile.


……


2013-07-26 21:32:06.625: [ GPNP][120384416]clsgpnpd_pushThread: [at
clsgpnpd.c:4770] START gpnpd start serving clients after profile updates <<<<<<<<<< push
thread
被启动。如果需要,这个线程负责把本地的gpnp profile发送给其他节点。


……


2013-07-26 21:32:55.562: [ GPNP][79473568]clsgpnp_ocrDetectThread: [at
clsgpnp0.c:4508] OCR client init SUCCEEDED. OCR shared cache is now available
<<<<< gpnpd
开始监控OCR cache以便在集群的配置信息发生改变,而且有必要更新gpnp profile时进行修改。


最后,我们对和gpnpd相关的问题的诊断进行简单的描述。


1. 如果问题是本地的gpnp无法启动,那么根据gpnp的启动过程,需要察看。


1.1 Gpnpd pid 文件是否存在而且可以被访问


1.2 mdnsd 是否启动


1.3 gpnp wallet 文件是否存在,gpnp profile是否能够被grid 用户访问。


1.4 两个节点之间的网络连接是否正常。


1.5 其他节点的gpnpd.bin 是否正常。因为,在启动本地gpnpd.bin之后,它需要和集群其他节点的gpnpd.bin进行通信,以便确认集群中最新的gpnp profile


2. gpnpd的问题也会导致其他依赖于gpnpd的资源无法启动,例如ocssd.bin,这个进程需要访问gpnp profile获取集群的基本信息,例如 VF的位置,集群私网信息等。


3. 如果我们发现问题是gpnp profile中的信息出现了错误,可以使用工具gpnptool 进行修正。


4.对于诊断gpnpd问题所需要的信息,一般是


4.1 gpnpd.log 这个日志能够告诉我们gpnpd 是否被启动,以及,启动过程已经到达了哪一步,问题是在哪里出现的。


4.2 命令”crsctl stat res –t -init”的输出,它可以告诉我们ora.gpnpd资源的状态,以及集群中其他init资源的状态。


4.3 mdnsd.log, 如果我们发���问题出现在mdns无法发现集群中的其他节点,那么,这个文件很有帮助。


4.4 OSW 报告,它能够告诉我们OS当时的负载状况,集群网络统计信息等等。



希望通过以上的介绍能够让大家了解11gR2 GI 中新的守护进程gpnpd的一些认识,并在工作中遇到相关的问题时,有所帮助。

星期五 五月 17, 2013

Oracle 11gr2 软件安装和数据库创建步骤详解


本文是一篇step-by-step 文档,演示了如何安装oracle 数据库软件以及使用DBCA创建数据库。 同时,我们对每一步的功能,注意事项和容易犯的错误都进行了描述。希望对大家了解数据库安装过程有所帮助。


请在此链接下载全文: Oracle 11gr2 软件安装和数据库创建步骤详解


参与此主题的后续讨论,可以访问我们的中文社区,跟帖 共享 : Oracle 11gr2 软件安装和数据库创建步骤详解



星期一 九月 03, 2012

11gR2 如何诊断节点重启问题

本文对如何诊断11gR2 GI环境下的节点重启问题进行了一些介绍。

首先,像10g版本一样,我们首先介绍在GI中能够导致节点重启的进程。
1.Ocssd.bin:这个进程的功能和10g版本的功能基本差不多,主要是节点监控(Node Monitoring)和组管理(Group Management)。详细的信息请参考之前文章“如何诊断节点重启问题”了解详细的内容。
2.Cssdagent.bin/Cssdmonitor.bin:这2个进程是11gR2新增加的。他们的工作主要是同ocssd.bin进行本地心跳(Local HeartBeat),默认情况下每1秒钟一次。本地心跳的作用是监控本地的ocssd.bin进程是否正常运行。同时,他们也监控自己到ocssd.bin之间的连接。所以,我们可以认为,这两个进程的出现代替了10g中的oclsomon/oclsvmon(如果第三方集群管理软件存在)和oprocd。

接下来,介绍一个11gR2的重要的新特性—rebootless restart,这个新特性是在版本11.2.0.2被介绍的。从这个版本开始,当集群中的某个节点被驱逐(例如丢失网络心跳)或者该节点的ocssd.bin出现问题时,集群将不会直接重新启动该节点,而是首先尝试重新启动GI stack来解决问题,如果GI stack不能够在指定的时间内(short disk I/O timeout)完成graceful shutdown,才会重新启动节点,之后,存活的节点对集群进行重新配置。

下面我们列出在诊断11gR2 节点重启问题时经常搜集的信息
1.Ocssd.log
2.Cssdagent 和 cssdmonitor logs
<GI_home>/log/<node_name>/agent/ohasd/oracssdagent_root/oracssdagent_root.log
<GI_home>/log/<node_name>/agent/ohasd/oracssdmonitor_root_root/oracssdmonitor_root.log
3.Cluster alert log
<GI_home>/log/<node_name>/alert<node_name>.log
4.OS log
5.OSW 或者 CHM 报告

最后,我们对常见的节点重启的问题进行介绍。
1.由于丢失网络心跳导致的节点重启问题。对于这种原因导致的节点重启,诊断的方式和10g基本没有什么区别。但是有一个误区需要指出来。下面是一段GI alert log 信息,他们来自于node2。
2012-08-15 16:30:06.554 [cssd(11011) ]CRS-1612:Network communication with node node1 (1) missing for 50% of timeout interval.  Removal of this node from cluster in 14.510 seconds
2012-08-15 16:30:13.586 [cssd(11011) ]CRS-1611:Network communication with node node1 (1) missing for 75% of timeout interval.  Removal of this node from cluster in 7.470 seconds
2012-08-15 16:30:18.606 [cssd(11011) ]CRS-1610:Network communication with node node1 (1) missing for 90% of timeout interval.  Removal of this node from cluster in 2.450 seconds
2012-08-15 16:30:21.073 [cssd(11011) ]CRS-1632:Node node1 is being removed from the cluster in cluster incarnation 236379832
2012-08-15 16:30:21.086 [cssd(11011) ]CRS-1601:CSSD Reconfiguration complete. Active nodes are node2 .

以上的信息并不一定说明节点node1是由于丢失网络心跳而被驱逐出集群的,首先我们要验证, node2在报 node1 丢失网络心跳的时候node1 的状态,如果说node1 已经重启或者存在严重的性能问题(可以通过os log 或者OSW 报告验证),那么node1 重启并不是由于node2发现node1丢失网络心跳造成的,而是由于node1出现问题后产生的结果,这里的reconfiguration,仅仅是集群成员信息的更新,并不会导致节点重启。而且,从11.2.0.2开始,由于rebootless restart的介入,node eviction 首先导致的结果是GI stack重启,而不是直接节点重启。但是,如果在node2报node1丢失节点心跳的时候,node1的ocssd.bin仍然正常运行(可以通过ocssd.log验证)或者node1也报丢失了和其他节点的网络心跳,那么node1的重启是由于GI node eviction导致的。

2.由于丢失磁盘心跳导致的节点重启,这种情况和10g的情况基本相同,在这里不作详细的描述。

3.由于ocssd.bin 丢失了和Cssdagent/Cssdmonitor.bin的本地心跳导致的节点重启,对于这种情况,一般来说,我们会在oracssdagent_root.log 或oracssdmonitor_root.log 看到以下的信息。
2012-07-23 14:09:58.506: [ USRTHRD][1095805248] (:CLSN00111: )clsnproc_needreboot: Impending reboot at 75% of limit 28030; disk timeout 28030, network timeout 26380, last heartbeat from CSSD at epoch seconds 1343023777.410, 21091 milliseconds ago based on invariant clock 269251595; now polling at 100 ms
……
2012-07-23 14:10:02.704: [ USRTHRD][1095805248] (:CLSN00111: )clsnproc_needreboot: Impending reboot at 90% of limit 28030; disk timeout 28030, network timeout 26380, last heartbeat from CSSD at epoch seconds 1343023777.410, 25291 milliseconds ago based on invariant clock 269251595; now polling at 100 ms
……
从上面的信息我们看到本地心跳的timeout时间为28 秒左右(misscount – reboot time)。

4.由于操作系统资源竞争导致的节点重启。 如果说操作系统的资源被耗尽或者存在严重的竞争,也会导致ocssd.bin不能正常工作,造成节点重启。对于这种情况,虽然重启操作系统的命令会由ocssd.bin发出,但是真正的原因是os资源竞争。以下是一小段OSW输出,它显示了 在节点重启之前 cpu 耗尽。
Linux OSWbb v5.0 node1
SNAP_INTERVAL 30
CPU_COUNT 8
OSWBB_ARCHIVE_DEST /osw/archive
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
……
zzz ***Mon Aug 30 17:55:21 CST 2012
158  6 4200956 923940   7664 19088464    0    0  1296  3574 11153 231579  0 100  0  0  0
zzz ***Mon Aug 30 17:55:53 CST 2012
135  4 4200956 923760   7812 19089344    0    0     4    45  570 14563  0 100  0  0  0
zzz ***Mon Aug 30 17:56:53 CST 2012
126  2 4200956 923784   8396 19083620    0    0   196  1121  651 15941  2 98  0  0  0

对于这种原因导致的重启问题,也适用于10g。

本文只是对11gR2诊断节点重启问题进行了简单的介绍,更详细的内容,请参考以下的内容
Note 1050693.1 : Troubleshooting 11.2 Clusterware Node Evictions (Reboots)

星期五 六月 15, 2012

11gR2 新特性:Oracle Cluster Health Monitor(CHM)简介

   Cluster Health Monitor(以下简称CHM)是一个Oracle提供的工具,用来自动收集操作系统的资源(CPU、内存、SWAP、进程、I/O以及网络等)的使用情况。相对于OSWatcher,CHM直接调用OS的API来降低开销,而OSWatcher则是直接调用UNIX命令。另外,CHM的实时性更强,每秒收集一次数据(在11.2.0.3,改为了5秒一次)。 OSWatcher 的优点是可以用traceroute命令检测私网间的连通性,而且生成的数据的保留时间可以设置得很长。如果可以的话,最好是两个工具都使用。

   这些系统资源数据对于诊断集群系统的节点重启、Hang、实例驱逐(Eviction)、性能问题等是非常有帮助的。另外,用户可以使用CHM来及早发现一些系统负载高、内存异常等问题,从而避免产生更严重的问题。

CHM会自动安装在下面的软件:
    11.2.0.2 及更高版本的 Oracle Grid Infrastructure for Linux (不包括Linux Itanium) 、Solaris (Sparc 64 和 x86-64)
    11.2.0.3 及更高版本 Oracle Grid Infrastructure for AIX 、 Windows (不包括Windows Itanium)。

    在11.2.0.2之前的集群(10.2到11.2.0.1),可以安装独立版的CHM。目前支持的平台有Linux x86 和Linux x86-64,还有32位的Windows Server 2003 SP 2。独立版的CHM并不一定要安装在集群环境,单机环境也可以使用。关于如何安装独立版的CHM,请参考另一篇博客:
如何安装独立版的CHM(Oracle Cluster Health Monitor)


    在集群中,可以通过下面的命令查看CHM对应的资源(ora.crf)的状态:
    $ crsctl stat res -t -init
    --------------------------------------------------------------------------------
    NAME           TARGET  STATE        SERVER                   STATE_DETAILS       Cluster Resources
ora.crf        ONLINE  ONLINE       rac1

CHM主要包括两个服务:
    1). System Monitor Service(osysmond):这个服务在所有节点都会运行,osysmond会将每个节点的资源使用情况发送给cluster logger service,后者将会把所有节点的信息都接收并保存到CHM的资料库。
      $ ps -ef|grep osysmond
       root      7984     1  0 Jun05 ?        01:16:14 /u01/app/11.2.0/grid/bin/osysmond.bin

    2). Cluster Logger Service(ologgerd):在一个集群中的,ologgerd 会有一个主机点(master),还有一个备节点(standby)。当ologgerd在当前的节点遇到问题无法启动后,它会在备用节点启用。

     主节点:
     $ ps -ef|grep ologgerd
       root      8257     1  0 Jun05 ?        00:38:26 /u01/app/11.2.0/grid/bin/ologgerd -M -d       /u01/app/11.2.0/grid/crf/db/rac2

     备节点:
      $ ps -ef|grep ologgerd
       root      8353     1  0 Jun05 ?        00:18:47 /u01/app/11.2.0/grid/bin/ologgerd -m rac2 -r -d
/u01/app/11.2.0/grid/crf/db/rac1


CHM诊断日志:如果CHM的运行异常,可以查看下面的日志:
$GRID_HOME/log/<nodename>/crflogd/crflogd.log
$GRID_HOME/log/<nodename>/crfmond/crfmond.log

GI 中的服务ora.crf 是CHM对应的资源,可以使用下面的命令来启停CHM(不推荐停止该服务):
用root用户:
$GRID_HOME/bin/crsctl stop res ora.crf -init
$GRID_HOME/bin/crsctl start res ora.crf -init

CHM Repository:用于存放收集到数据,默认情况下,会存在于Grid Infrastructure home 下 ,需要1 GB 的磁盘空间,每个节点大约每天会占用0.5GB的空间,您可以使用OCLUMON来调整它的存放路径以及允许的空间大小(最多只能保存3天的数据)。

下面的命令用来查看它当前设置:
     $ oclumon manage -get reppath
       CHM Repository Path = /u01/app/11.2.0/grid/crf/db/rac2
       Done

     $ oclumon manage -get repsize
       CHM Repository Size = 68082 <====单位为秒
       Done

     修改路径:
     $ oclumon manage -repos reploc /shared/oracle/chm

     修改大小:
     $ oclumon manage -repos resize 68083 <==在3600(小时) 到 259200(3天)
之间
      rac1 --> retention check successful
      New retention is 68083 and will use 1073750609 bytes of disk space
      CRS-9115-Cluster Health Monitor repository size change completed on all nodes.
      Done

获得CHM生成的数据的方法有两种:
     1. 一种是使用Grid_home/bin/diagcollection.pl:
        1). 首先,确定cluster logger service的主节点:
         $ oclumon manage -get master
         Master = rac2


        2).用root身份在主节点rac2执行下面的命令:
         # <Grid_home>/bin/diagcollection.pl -collect -chmos -incidenttime inc_time -incidentduration duration
         inc_time是指从什么时间开始获得数据,格式为MM/DD/YYYY24HH:MM:SS, duration指的是获得开始时间后多长时间的数据。

         比如:# diagcollection.pl -collect -crshome /u01/app/11.2.0/grid -chmoshome  /u01/app/11.2.0/grid -chmos -incidenttime 06/15/201215:30:00 -incidentduration 00:05

       3).运行这个命令之后,CHM的数据会生成在文件chmosData_rac2_20120615_1537.tar.gz。

    2. 另外一种获得CHM生成的数据的方法为oclumon:
        $oclumon dumpnodeview [[-allnodes] | [-n node1 node2] [-last "duration"] | [-s "time_stamp" -e "time_stamp"] [-v] [-warning]] [-h]

        -s表示开始时间,-e表示结束时间
       $ oclumon dumpnodeview -allnodes -v -s "2012-06-15 07:40:00" -e "2012-06-15 07:57:00" > /tmp/chm1.txt

       $ oclumon dumpnodeview -n node1 node2 node3 -last "12:00:00" >/tmp/chm1.txt
       $ oclumon dumpnodeview -allnodes -last "00:15:00" >/tmp/chm1.txt


下面是/tmp/chm1.txt中的部分内容:
----------------------------------------
Node: rac1 Clock: '06-15-12 07.40.01' SerialNo:168880
----------------------------------------

SYSTEM:
#cpus: 1 cpu: 17.96 cpuq: 5 physmemfree: 32240 physmemtotal: 2065856 mcache: 1064024 swapfree: 3988376 swaptotal: 4192956 ior: 57 io
w: 59 ios: 10 swpin: 0 swpout: 0 pgin: 57 pgout: 59 netr: 65.767 netw: 34.871 procs: 183 rtprocs: 10 #fds: 4902 #sysfdlimit: 6815744
 #disks: 4 #nics: 3  nicErrors: 0

TOP CONSUMERS:
topcpu: 'mrtg(32385) 64.70' topprivmem: 'ologgerd(8353) 84068' topshm: 'oracle(8760) 329452' topfd: 'ohasd.bin(6627) 720' topthread:
 'crsd.bin(8235) 44'

PROCESSES:

name: 'mrtg' pid: 32385 #procfdlimit: 65536 cpuusage: 64.70 privmem: 1160 shm: 1584 #fd: 5 #threads: 1 priority: 20 nice: 0
name: 'oracle' pid: 32381 #procfdlimit: 65536 cpuusage: 0.29 privmem: 1456 shm: 12444 #fd: 32 #threads: 1 priority: 15 nice: 0
...
name: 'oracle' pid: 8756 #procfdlimit: 65536 cpuusage: 0.0 privmem: 2892 shm: 24356 #fd: 47 #threads: 1 priority: 16 nice: 0

----------------------------------------
Node: rac2 Clock: '06-15-12 07.40.02' SerialNo:168878
----------------------------------------

SYSTEM:
#cpus: 1 cpu: 40.72 cpuq: 8 physmemfree: 34072 physmemtotal: 2065856 mcache: 1005636 swapfree: 3991808 swaptotal: 4192956 ior: 54 io
w: 104 ios: 11 swpin: 0 swpout: 0 pgin: 54 pgout: 104 netr: 77.817 netw: 33.008 procs: 178 rtprocs: 10 #fds: 4948 #sysfdlimit: 68157
44 #disks: 4 #nics: 4  nicErrors: 0

TOP CONSUMERS:
topcpu: 'orarootagent.bi(8490) 1.59' topprivmem: 'ologgerd(8257) 83108' topshm: 'oracle(8873) 324868' topfd: 'ohasd.bin(6744) 720' t
opthread: 'crsd.bin(8362) 47'

PROCESSES:

name: 'oracle' pid: 9040 #procfdlimit: 65536 cpuusage: 0.19 privmem: 6040 shm: 121712 #fd: 33 #threads: 1 priority: 16 nice: 0
...


  关于CHM的更多解释,请参考Oracle官方文档:
  http://docs.oracle.com/cd/E11882_01/rac.112/e16794/troubleshoot.htm#CWADD92242
  Oracle® Clusterware Administration and Deployment Guide
  11g Release 2 (11.2)
  Part Number E16794-17

  或者 My Oracle Support文档:
  Cluster Health Monitor (CHM) FAQ (Doc ID 1328466.1)

11gR2 Agent 简介

目的:本文会对oracle 11gR2 集群件(Grid Infrastructure,以下简称GI) 新特性 agent进行介绍,包括 agent的功能,常见的agent介绍,以及基本的诊断方法。

适用范围:11.2.0.1及以上版本。

    首先我们对10gR2 crs 管理资源的方法进行简单的介绍。在10gR2 当中,crsd 负责对集群中的资源进行管理。具体说来,crsd 调用相关的racg脚本,产生racg进程对资源进行管理,例如racgvip 脚本用来管理vip资源。这种管理办法,由于是racg进程进行对资源的操作,有时候会存在一些问题。从11gR2 GI开始, agent 作为一个全新的架构对GI中所有的资源进行管理,这种全新的agent 架构使资源管理更加强壮,性能更好。

    接下来我们对agent的特点进行一些介绍。
1.几乎所有的资源和daemon都是由agent 管理的。例如gipc, gpnp等 由ohasd 产生的orarootagent管理。
2.Agent守护进程是多线程的,而且是HA(High Available)进程.
3.Ohasd 会产生下面的agent
        cssdagent(这个agent代表命令“crsctl stat res –t –init” 中的资源ora.cssd )
        orarootagent
        oraagent
        cssdmonitor
    Crsd 会产生下面的agent
        orarootagent
        Oraagent
        用户自定义的agent.
注意:用户oracle和grid都会产生各自对应的oraagent来管理各自的资源。例如 oraagent_grid管理资源ora.asm, oraagent_oracle管理ora.<database_name>.db资源。

    下面我们对agent如何管理资源进行介绍。首先,agent 拥有一些EP(Entry Point),类似于可以对资源执行的动作。
       Start:启动资源
       Stop:停止资源
       Check:检查资源的状态,如果发现了资源状态改变,则agent会通知GI,资源状态发生了改变。
       Clean:清理资源,一般来说清理资源会在资源存在问题,需要重新启动或failover之前发生。
       Abort:中止资源。

    当以上的任意EP结束之后,会返回以下返回值中的一个,而这些返回值也对应着资源的状态。
       ONLINE:在线。对应资源的online状态
       OFFLINE:离线。对应资源的offline状态。对于offline状态,可以细分为planed offline 和unplaned offline。Planed offline是指GI倾向于这个资源处在offline状态,例如我们使用GI相关的工具(srvctl, crsctl)停止了一个资源,这种情况,GI就认为资源应该处于offline状态,因为停止资源的操作是通过GI来实现的。同时,对于planed offline的资源,它的target状态也会被修改为offline状态,这意味着,如果在资源的target状态为offline时重启GI stacks,除非资源的auto_start属性设置为always,否则,该资源不会被自动启动(关于target状态,和属性auto_start的更多信息,请参考oracle联机文档Oracle Clusterware Administration and Deployment Guide 11g Release 2)。对于unplaned offline,是指资源被GI以外的工具停止,例如使用sqlplus手动关闭数据库,在这种情况下,GI并不认为该资源应该处于offline状态,资源的target状态仍然为online,所以,资源在重新启动GI时仍然会被启动,当然除非资源的auto_start属性设置为never。
       UNKNOWN:未知,对应资源的unknown状态。在这种状态下,agent会继续对该资源进行check。
       PARTIAL:资源部分在线,对应资源的intermediate状态。 在这种情况下agent会继续对该资源进行check,并及时更新资源状态。
       FAILED:失败。该返回值说明资源存在问题,不能正常工作,agent会首先执行clean EP,之后根据资源的相关属性进行failover或restart操作。

    之后,我们可以通过下面这张表格了解agent与负责管理的资源的对应关系。




    最后,我们对agent相关的trace文件进行简单的介绍。首先,agent的trace 文件位于路径GRID_HOME/log/<host>/agent下,以下是比较详细的信息。

            GRID_HOME/log/<host>/agent /ohasd/orarootagent_root  <– ohasd产生的orarootagent日志

            GRID_HOME/log/<host>/agent/ohasd/oraagent_grid  <– ohasd产生的oraagent日志

            GRID_HOME/log/<host>/agent/ohasd/oracssdagent_root  <– ohasd产生的cssdagent日志

            GRID_HOME/log/<host>/agent/ohasd/oracssdmonitor_root  <– ohasd产生的cssdmonitor日志

            GRID_HOME/log/<host>/agent/crsd/oraagent_grid  <– crsd产生的oraagent日志,owner为grid

            GRID_HOME/log/<host>/agent/crsd/oraagent_oracle  <– crsd产生的oraagent日志,owner为oracle

            GRID_HOME/log/<host>/agent/crsd/orarootagent_root  <–crsd产生的orarootagent日志

    另外,以下的文件对诊断agent相关的问题也很有帮助。

            集群alert log(Grid_home/log/<hostname>/alert<hostname>.log)

            Grid_home/log/<hostname>/ohasd/ohasd.log

            Grid_home/log/<hostname>/crsd/crsd.log


    由于每个agent需要管理多个资源,所以,如果只是某一个资源存在问题,可以使用有问题的资源名称过滤agent日志会更有效率,当然Agent日志的可读性很好,在这里不进行详细的介绍。Agent如果crash,一般情况下,会产程一个core文件(Grid_home/log/<hostname>/agent/{ohasd|crsd}/<agent名>_<用户名>)和对应的堆栈文件(Grid_home/log/<hostname>/agent/{ohasd|crsd}/<agent名>_<用户名>/<agent名>_<用户名>OUT.log)。


星期六 三月 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.



星期三 三月 07, 2012

11gR2 集群(CRS/GRID)新功能—— SCAN(Single Client Access Name)

回顾
-------------------
本文简单的介绍一下11gR2集群(CRS/GRID)新功能SCAN(Single Client Access Name),希望对于刚刚接触11gR2的朋友有一些帮助。


在介绍SCAN之前,先简单的回顾一下oracle关于IP地址的使用,在9i RAC时,oracle没有自己的clusterware,主要依靠第三方的集群软件(如IBM HACMP等等),客户端主要是通过public IP来访问数据库(如果第三方集群软件提供服动IP的话,也可以通过这个服动IP来访问数据库),当某一个节点已经出现故障无法对外提供服务时,如果客户端继续请求连接这个节点的public IP,那么连接请求会长时间没有返回,最后要等到TCP-IP timeout (TCP-IP超时时间一般为10分钟,不同OS这个值不同)才会返回一个超时信息,这对于实时性要求较高的应用来说是致命的问题,很多DBA都经历过这样的问题,从技术层面上来说,这是一个网络层的问题,任何应用都要等待网络层返回超时信息。为了解决这个问题,从oracle 10g
RAC开始,引入了一个新的功能叫VIP,这个功能类似于第三方集群软件的浮动IP,简单的说就是当public 网卡或者节点出现问题,VIP可以快速的failover到另外的节点,如果客户端的连接请求被分配到这个VIP时,客户端连接请求马上就会遇到错误,因此会快速的跳过这个‘有问题的’VIP,而重新分配另一个VIP(这个功能是客户端连接时的failover),最终连接到数据库,这些对于应用来说是透明的,基本感觉不到连接的延时。


SCAN简介
-------------------
从11gR2 Grid Infrastructure (CRS/clusterware)开始,引入了一个新功能叫SCAN (Single Client Access Name),SCAN是一个域名,可以解析至少1个IP,最多解析3个SCAN IP,客户端可以通过这个SCAN 名字来访问数据库,SCAN的好处就是当集群中新增加了节点或者删除了节点,不需要额外维护客户端。在11gR2上,客户端仍然可以继续使用原有的 VIP,但是oracle推荐使用SCAN。


SCAN ip必须与public ip和VIP在一个子网,同时oracle推荐使用DNS或者GNS(11gR2
新功能)来解析SCAN,如果没有使用DNS或者GNS的话,可以使用hosts文件,但是这个办法不是oracle推荐的,因为这个方法只能定义一个 SCAN IP。


GRID集群中有2类资源是与SCAN有关的,一类是SCAN IP,另一类是SCAN Listener,SCAN IP和SCAN Listener是成对出现的,也就是说如果有3个SCAN IP,就会同时有3个SCAN Listene。SCAN IP就是DNS解析的IP地址,SCAN Listener的作用是接受客户端的连接请求。查看SCAN IP信息和SCAN Listener信息的方法在下文介绍。


数据库的初始化参数remote_listener默认被设置为SCAN Listener,目的是为了让SCAN Listener可以监听所有的实例,记录所有实例的压力,以便于按照负载均衡的方式来转发客户端的请求。


客户端如何通过SCAN访问数据库
------------------------------------------------------
客户端发出连接数据库的请求,DNS将SCAN解析出对应的3个SCAN IP并返回给客户端,
客户端随机的选择其中一个SCAN IP地址,然后客户端通过这个SCAN IP访问对应的节点,当对应节点的SCAN Listener接受到请求后,SCAN Listener会选择压力最小的数据库实例,然后压力最小的数据库实例对应的local listener的地址将会返回给客户端,最终这个local listener为客户端请求建立与数据库的连接。


客户端tnsnames.ora的配置
-------------------------------------------
RAC =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac-cluster-scan)(PORT = 1521))
  (CONNECT_DATA =
     (SERVER = DEDICATED)
     (SERVICE_NAME = rac)
  ) )

客户端的连接方式:
$ sqlplsu <username>/<password>@RAC


EZconnet的连接仍然适用于SCAN
$ sqlplus <username>/<password>@rac-cluster-scan:1521/rac

常用命令
-----------------------
1. 查看SCAN配置信息
$ srvctl config scan
SCAN name: rac-cluster-scan, Network: 1/192.168.1.0/255.255.255.0/
SCAN VIP name: scan1, IP: /rac-cluster-scan/192.168.1.12
SCAN VIP name: scan2, IP: /rac-cluster-scan/192.168.1.13
SCAN VIP name: scan3, IP: /rac-cluster-scan/192.168.1.14


2. 查看SCAN Listener配置信息
$ srvctl config scan_listener
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521
SCAN Listener LISTENER_SCAN2 exists. Port: TCP:1521
SCAN Listener LISTENER_SCAN3 exists. Port: TCP:1521


3. 查看SCAN的状态
$ srvctl status scan


4. 查看SCAN listener的状态
$ srvctl status scan_listener


常用文档
------------------
SCAN介绍
www.oracle.com/technetwork/testcontent/scan-098460.html

ORACLE SUPPORT网站上查看下面2篇文章,都是关于SCAN的介绍,希望能够帮助您解决关于SCAN的问题。
11gR2 Grid Infrastructure Single Client Access Name (SCAN) Explained (Doc ID 887522.1)
How to Setup SCAN Listener and Client for TAF and Load Balancing [Video] (Doc ID 1188736.1)


同时推荐您学习oracle的在线文档,里面有很详细的介绍,包括新功能,CRS/RAC 安装过程和常用的管理命令,基本上可以解决我们平时遇到的大部分疑问。


集群(GRID/CRS)的安装和管理文档:
http://docs.oracle.com/cd/E11882_01/install.112/e22489/toc.htm
http://docs.oracle.com/cd/E11882_01/rac.112/e16794/toc.htm


RAC的安装和管理文档:
http://docs.oracle.com/cd/E11882_01/install.112/e24660/toc.htm
http://docs.oracle.com/cd/E11882_01/rac.112/e16795/toc.htm

星期四 一月 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
   
       
今天