Oracle Policy-Managed Cluster – Growing for DBaaS

Policy-Managed Cluster在Oracle 11gR2中被引进,在Oracle 12c中使用dbca创建RAC数据库的时候,Policy-Managed选项已然成为默认值。 Policy-Managed RAC

那么到底什么是Policy-Managed方式的集群和数据库呢?与以前的Admin-Managed方式有何区别?何种环境适合使用这种新的方式进行管理?本文尝试回答这些问题,并且做出简单的测试。

什么是Policy-Managed方式?

基于策略的管理方式,是以服务器池(Server Pools)为基础的,简单地说,就是先定义一些服务器池,池中包含一定量的服务器,然后再定义一些策略,根据这些策略Oracle会自动决定让多少数据库实例运行在池中的几台机器上。数据库实例名后缀、数据库实例个数、所运行的主机,这些都是通过策略决定的,而不是数据库管理员事先定好的。

与Admin-Managed方式有何区别?

实际上上面的表述已经明确说明了,Policy-Managed和Admin-Managed方式的差别。让我们再回顾一下,在以往我们创建一个RAC数据库大概是怎样的方法,我们在dbca的界面中会选择要将数据库实例运行在整个集群中的几台机器上,或者是2台或者是3台,甚或是更多,但是只要在安装的时候选定几台机器,那么以后如果不做增减节点的操作,就始终会在这几台机器上运行。而且,通常会根据主机名称的排序自动将每台主机上的数据库实例依次命名为dbname1到dbnameN。这些在管理员安装完毕以后,都不会再自动变化,这就是Admin-Managed方式。

何种环境适合使用这种新的方式进行管理?

当管理大量的服务器集群,并且在这些集群中运行着多种不同重要程度,不同策略的RAC数据库时,为了简化管理,建议使用Policy-Managed方式,实际上Oracle也建议只有在超过3台的服务器的时候才使用Policy-Managed来管理整个数据库集群。想象一下使用Policy-Managed方式可以达到的效果:如果我们有10台服务器组成,根据不同的应用的重要性定义服务器池的关键程度,然后在其中某些机器意外停机的情况下,仍然可以自动地保持足够多的机器给重要的系统提供数据库服务,而将不关键的系统数据库服务器个数降低到最低限度。

那么Policy-Managed方式到底长什么样?

在默认安装完Oracle 12c的RAC数据库之后,发现数据库实例始终只会启动在一个节点中。检查服务器池配置。

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 0, Min: 0, Max: 1
Category: hub
Candidate server names:

Free池和Generic池是默认存在的,orcl_pool池则是在dbca创建数据库的时候由我们自己定义的。其中Min: 0, Max: 1表示在这个池中最少允许有0台机器,最多允许有1台机器被使用。所以这也造成了使用这个服务器池的数据库实例始终只会启动在一个节点中,即使这在我们最初的定义中是一个RAC数据库。

当前的数据库实例启动在节点2中,比较一下节点1和节点2服务器使用情况的输出。

[grid@dbserver2 ~]$ crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=Free --此处显示未Free,表示节点1中不属于任何正在运行的服务器池资源。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

[grid@dbserver2 ~]$ crsctl status server dbserver2 -f
NAME=dbserver2
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool --此处显示节点2正运行在orcl_pool服务器池资源中。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

接下来需要修改一下配置,让RAC数据库以我们熟知的方式启动在多个节点上。 –修改orcl_pool池中最少运行一台机器,最多运行2台机器,还记得我们前面说的关键程度吗?importance表示该池的关键程度,数字越大表示关键程度越高,越优先被考虑满足Min条件。

[oracle@dbserver2 ~]$ srvctl modify srvpool -serverpool orcl_pool -importance 5 -min 1 -max 2

–重新检查服务器池信息,可以看到已经修改成功,Min: 1, Max: 2

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 5, Min: 1, Max: 2
Category: hub
Candidate server names:

–查看当前服务器池的状态,可以看到orcl_pool池中激活的服务器包括了节点1和节点2两台机器。

[grid@dbserver1 ~]$ crsctl status serverpool
NAME=Free
ACTIVE_SERVERS=

NAME=Generic
ACTIVE_SERVERS=

NAME=ora.orcl_pool
ACTIVE_SERVERS=dbserver1 dbserver2

在修改完毕以后,节点1中的数据库实例就会自动启动,我们可以通过crsctl命令查看服务器的状态,其中STATE_DETAILS字段显示了正在启动资源,在正常启动完毕以后该字段会显示为空。

[grid@dbserver2 ~]$ crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool
STATE_DETAILS=STARTING RESOURCES
ACTIVE_CSS_ROLE=hub

现在就出现了一个比较尴尬的情况(对于我们以前管理RAC的常识来说),由于dbserver1中的实例是后启动的,因此实例名后缀为2,而dbserver2中的实例名后缀是1,实际上,在Policy-Managed管理的RAC环境中,无需关注到底哪个实例启动在哪台机器上,我们需要的就是通过SCAN IP,通过Service名去访问数据库就好,而不需要通过实例名访问数据库。但是这里为了测试一下功能,还是决定1归1,2归2,我有说过我是完美主义者吗?

--先将dbserver1上的数据库服务资源reolocate到dbserver2中,这样实例2就运行回到了dbserver2中。
[grid@dbserver1 ~]$ crsctl relocate resource ora.orcl12c.db -s dbserver1 -n dbserver2
--再将dbserver1中的实例启动,因为实例2已经启动在dbserver2中,因此即使此时该实例是后启动的,但是仍然还是会命名为实例1。
[oracle@dbserver1 ~]$ srvctl start instance -db orcl12c -node dbserver1

最后将这个RAC数据库再改回到只会启动一个实例的默认状态。

[oracle@dbserver2 ~] srvctl modify srvpool -serverpool orcl_pool -min 0 -max 1

以后,无论是启动在哪台机器上,数据库的实例名永远会是dbname_1(注意,这里有一个下划线,这是Policy-Managed数据库实例的命名规则)。而我们访问数据库,则不应该指定实例名。比如:

sqlplus sys/passwd@db-cluster-scan:1521/orcl12c as sysdba

因为现在你已经无需关心到底实例是启动在哪台机器上了,后面是一个资源池,是不是有些熟悉这样的表述,是的,没错,Cloud! 我们也贴上了Cloud这个红到发紫的词,这就是Oracle私有云解决方案的构成组件之一。

Install 11.2.0.2 RAC on OEL5.5 x86-64 (root.sh issue on second node)

在安装11.2.0.2 RAC的时候,第一步安装Grid,在第二个节点上运行root.sh的时候,报错如下:

Start of resource "ora.ctssd" failed
CRS-2672: Attempting to start 'ora.ctssd' on 'xsh-server2'
CRS-2674: Start of 'ora.ctssd' on 'xsh-server2' failed
CRS-4000: Command Start failed, or completed with errors.
Cluster Time Synchronisation Service  start in exclusive mode failed at /u01/app/11.2.0/grid/crs/install/crsconfig_lib.pm line 6455.
/u01/app/11.2.0/grid/perl/bin/perl -I/u01/app/11.2.0/grid/perl/lib -I/u01/app/11.2.0/grid/crs/install /u01/app/11.2.0/grid/crs/install/rootcrs.pl execution failed

从报错信息上看是ctssd进程启动失败(在这之前会显示cssd进程启动成功,这与MOS上的其它一些第二节点运行root.sh失败的情形是不一样的,那些场景在cssd进程启动的时候就失败了),查看ctssd进程的启动log(位于$GRID_HOME/log/ctssd目录下),发现如下错误信息。

2010-11-12 18:55:46.132: [    GIPC][2424495392] gipcCheckInitialization: possible incompatible non-threaded init from [prom.c : 687], original from [clsss.c : 5325]
[ default][2424495392]Failure 4 in trying to open SV key SYSTEM.version.localhost

[ default][2424495392]procr_open_key error 4 errorbuf : PROCL-4: The local registry key to be operated on does not exist.

2010-11-12 18:55:46.135: [    CTSS][2424495392]clsctss_r_av2: Error [3] retrieving Active Version from OLR. Returns [19].
2010-11-12 18:55:46.138: [    CTSS][2424495392](:ctss_init16:): Error [19] retrieving active version. Returns [19].
2010-11-12 18:55:46.138: [    CTSS][2424495392]ctss_main: CTSS init failed [19]
2010-11-12 18:55:46.138: [    CTSS][2424495392]ctss_main: CTSS daemon aborting [19].
2010-11-12 18:55:46.138: [    CTSS][2424495392]CTSS daemon aborting

从crsctl命令中也可以看出ora.cssd启动成功,但是ora.ctssd是OFFLINE状态。

 $ crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        OFFLINE OFFLINE                                                   
ora.cluster_interconnect.haip
      1        OFFLINE OFFLINE                                                   
ora.crf
      1        OFFLINE OFFLINE                                                   
ora.crsd
      1        OFFLINE OFFLINE                                                   
ora.cssd
      1        ONLINE  ONLINE       xsh-server2                                  
ora.cssdmonitor
      1        ONLINE  ONLINE       xsh-server2                                  
ora.ctssd
      1        ONLINE  OFFLINE                                                   
ora.diskmon
      1        ONLINE  ONLINE       xsh-server2                                  
ora.drivers.acfs
      1        OFFLINE OFFLINE                                                   
ora.evmd
      1        OFFLINE OFFLINE                                                   
ora.gipcd
      1        ONLINE  ONLINE       xsh-server2                                  
ora.gpnpd
      1        ONLINE  ONLINE       xsh-server2                                  
ora.mdnsd
      1        ONLINE  ONLINE       xsh-server2   

此时如果用此命令查看第一个节点的状况会发现所有资源都是正常ONLINE的。继续检查cssd.log(位于$GRID_HOME/log/cssd目录中),显示在发现ASM磁盘的时候报错。

2010-11-12 13:44:30.505: [   SKGFD][1087203648]UFS discovery with :ORCL:VOL*:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]OSS discovery with :ORCL:VOL*:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Discovery with asmlib :ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so: str :ORCL:VOL*:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Fetching asmlib disk :ORCL:VOL1:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Fetching asmlib disk :ORCL:VOL2:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Fetching asmlib disk :ORCL:VOL3:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]ERROR: -15(asmlib ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so op asm_open error Operation not permitted
)
2010-11-12 13:44:30.505: [   SKGFD][1087203648]ERROR: -15(asmlib ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so op asm_open error Operation not permitted
)
2010-11-12 13:44:30.505: [   SKGFD][1087203648]ERROR: -15(asmlib ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so op asm_open error Operation not permitted

值得注意的是,这样的报错在第一个节点上也同样存在,但是第一个节点上所有的资源包括ASM磁盘组却都是正常运行的。

对于以上cssd.log中的错误,按照MOS Note [1050164.1]处理,修改/etc/sysconfig/oracleasm-_dev_oracleasm文件,指定ASMLib在发现磁盘的时候需要忽略的盘和需要检查的盘。在我们的环境中是使用了Multipath来对多块磁盘做多路径处理,因此需要包括dm开头的磁盘,而忽略sd开头的磁盘。这样的问题也应该只会发生在使用了Multipath的磁盘上。

# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"

可以通过以下方法来确认是否遭遇了此问题。

# ls -l /dev/oracleasm/disks
brw-rw---- 1 oracle dba 3, 65 May 14 12:08 CRSVOL
# cat /proc/partitions
  3 65 4974448 sda
253  1 4974448 dm-1

在上面可以看到CRSVOL这个用oracleasm创建的ASM磁盘的major和minor号分别是3,65,而这正是/dev/sda的号,并不是/dev/dm-1的号,所以表示在创建ASM磁盘组的时候并没有使用到Multipath设备。通常情况下,在节点1上是正确的,而在节点2上不正确的,因此出现了问题。

在处理完以上问题以后,必须要对grid环境做deconfig再reconfig,而不能只是在失败节点上重新运行root.sh(我在这里耗费了大量时间),重新配置grid的步骤可以参考MOS Note [942166.1] – How to Proceed from Failed 11gR2 Grid Infrastructure (CRS) Installation。之后root.sh顺利在第二节点上运行成功。

在错误解决以后,回顾之前的安装信息,可以发现虽然第一个节点显示所有资源都正常,但是和正常的root.sh运行信息相比则缺少了几行显示。

正常的信息如下:

# $GRID_HOME/root.sh
Running Oracle 11g root script...

The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /u01/app/11.2.0/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
LOCAL ADD MODE 
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
OLR initialization - successful
Adding daemon to inittab
ACFS-9200: Supported
ACFS-9300: ADVM/ACFS distribution files found.
ACFS-9307: Installing requested ADVM/ACFS software.
ACFS-9308: Loading installed ADVM/ACFS drivers.
ACFS-9321: Creating udev for ADVM/ACFS.
ACFS-9323: Creating module dependencies - this may take some time.
ACFS-9327: Verifying ADVM/ACFS devices.
ACFS-9309: ADVM/ACFS installation correctness verified.
CRS-2672: Attempting to start 'ora.mdnsd' on 'xsh-server1'
CRS-2676: Start of 'ora.mdnsd' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.gpnpd' on 'xsh-server1'
CRS-2676: Start of 'ora.gpnpd' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'xsh-server1'
CRS-2672: Attempting to start 'ora.gipcd' on 'xsh-server1'
CRS-2676: Start of 'ora.cssdmonitor' on 'xsh-server1' succeeded
CRS-2676: Start of 'ora.gipcd' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'xsh-server1'
CRS-2672: Attempting to start 'ora.diskmon' on 'xsh-server1'
CRS-2676: Start of 'ora.diskmon' on 'xsh-server1' succeeded
CRS-2676: Start of 'ora.cssd' on 'xsh-server1' succeeded

ASM created and started successfully.

Disk Group CRSDG created successfully.

clscfg: -install mode specified
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Successful addition of voting disk 67463e71af084f76bf98b3ee55081e40.
Successfully replaced voting disk group with +CRSDG.
CRS-4266: Voting file(s) successfully replaced
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   67463e71af084f76bf98b3ee55081e40 (ORCL:VOL1) [CRSDG]
Located 1 voting disk(s).

CRS-2672: Attempting to start 'ora.asm' on 'xsh-server1'
CRS-2676: Start of 'ora.asm' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.CRSDG.dg' on 'xsh-server1'
CRS-2676: Start of 'ora.CRSDG.dg' on 'xsh-server1' succeeded
ACFS-9200: Supported
ACFS-9200: Supported
CRS-2672: Attempting to start 'ora.registry.acfs' on 'xsh-server1'
CRS-2676: Start of 'ora.registry.acfs' on 'xsh-server1' succeeded
Preparing packages for installation...
cvuqdisk-1.0.9-1
Configure Oracle Grid Infrastructure for a Cluster ... succeeded

而之前的信息则缺少了以下4行。

LOCAL ADD MODE 
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
OLR initialization - successful

Oracle显然不会承认这是bug,好吧,解决问题就好。

Procwatcher: Useful Script to Monitor Oracle Processes

也许总在某个时候,作为Oracle DBA的你心里会想,这进程到底在干什么呢?为什么占用这么高的CPU?为什么写这么多数据到磁盘上产生这么大的IO?

当然,我们有各种各样的诊断方法来确认这些进程在做什么,不过,也很有可能在初步的诊断之后,还是一无所获,这时候也许类似于oradebug short_stack这样的命令或者是操作系统级别的debug命令能够让我们在重重迷雾中找到一些指路的明灯。不能否认,在某些时候,只是灵光一闪,从某些特征上忽然醒悟了该从哪个方向入手,就能帮助我们最终解决问题。

这里介绍的Procwatcher是一个shell脚本,运行在UNIX/LINUX操作系统级别,帮助我们给指定的Oracle Clusterware后台进程(比如crsd.bin, evmd.bin等)以及Oracle RDBMS后台进程(比如dbwr, smon, pmon等)进行定期的debug跟踪,将收集的stack traces按照进程和日期存储在磁盘上。

不要期望能够完全看明白stack trace的内容,那些是给专业的Oracle Support人员看的,但是我们至少可以知道在一个进程非常缓慢或者非常忙碌的时候,它被hang在了什么地方,也许是一个类似于kslwait这样的函数,这些就是蛛丝马迹,可以通过这些关键字去Metalink中找寻更有价值的信息。或者把这些trace内容上传给Oracle Support人员,也对解决疑难问题有很大帮助。

此脚本的内部注释非常完整,基本上所有的帮助信息都可以从脚本注释中找到。

启动和关闭脚本的命令分别是:

./prw.sh start 
./prw.sh stop

注意点:
1. 获取stack trace通常会对被debug的进程有短暂的suspend操作,比如ocssd.bin如果被suspend过长(超过css misscount时间),则会导致节点被重启。可以修改脚本中的CRSPROCS参数,将不需要trace的进程去除。

2. 在AIX平台上慎用EXAMINE_CRS=true,也就是在AIX平台上最好不要用这个脚本去获取Oracle Clusterware后台进程的stack trace,可能造成程序被hang住。

3. 默认保留2天的trace记录,可以通过下面的语法修改为3天或者更多。

./prw.sh start 3

可以登录Metalink的朋友可以在Note:459694.1中下载该脚本。
没有Metalink帐号的朋友在这里下载脚本。

Oracle Clusterware consolidated logging

使用过Oracle Clusterware 10gR1的朋友应该还记得各个后台进程的log都被散乱地放在各自的目录中,可惜的是,也许你刚刚熟悉了每个log的位置,然后当你将10gR1升级到10gR2,你就发现所有的log你都找不到了,它们不再在原来的位置,Oracle重新整理放在了统一的目录下。

这里记录一下10gR2和11gR1中Oracle Clusterware的log位置。以下$ORACLE_HOME指Oracle RDBMS软件的安装目录,$ORA_CRS_HOME指Oracle Clusterware软件的安装目录。

CRS logs $ORA_CRS_HOME/log/[hostname]/crsd/
CSS logs $ORA_CRS_HOME/log/[hostname]/cssd/
EVM logs $ORA_CRS_HOME/log/[hostname]/evmd
$ORA_CRS_HOME/evm/log/
Resource logs $ORA_CRS_HOME/log/[hostname]/racg
$ORACLE_HOME/log/[hostname]/racg
SRVM logs $ORA_CRS_HOME/log/[hostname]/client
$ORACLE_HOME/log/[hostname]/client
Cluster Network Communication logs $ORA_CRS_HOME/log
OPMN logs $ORA_CRS_HOME/opmn/logs
alert logs $ORA_CRS_HOME/log/[hostname]/alert[hostname].log
OPROCD logs /var/opt/oracle/[hostname]
CLSOMON files $CRS_HOME/log/[hostname]/cssd/oclsomon

当Oracle Clusterware发生问题的时候,需要寻求Oracle Support的帮助,那么这些位置的log都是可能会需要的。

我们也可以使用在10gR2之后Oracle提供的perl脚本来获取诊断信息。
在10gR2版本中,执行:

$ORA_CRS_HOME/bin/diagcollection.pl -collect

在11gR1版本中,执行:

$ORA_CRS_HOME/bin/diagcollection.pl -crshome=$ORA_CRS_HOME -collect

该脚本执行结束以后,将会产生几个tar.gz文件,包括crsData_[hostname].tar.gz,ocrData_[hostname].tar.gz,oraData_[hostname].tar.gz和basData_[hostname].tar.gz 。

另外如果Oracle Support需要你提供Oracle Clusterware的安装情况,那么可以使用cluvfy实用程序来获得输出。

su - oracle 
cluvfy stage -post crsinst -n all -verbose

Using Diagwait during Oracle Clusterware Node evictions

什么情况下Oracle Clusterware会重启(Evict,驱逐)节点机器?

1. 节点机器在interconnect network上无法ping通,没有了network heartbeat,比如网络问题。
2. 节点机器无法存取Voting Disk,没有了disk heartbeat,比如磁盘问题。
3. 由于节点机器过于繁忙,导致没有空闲资源来完成上述的两种动作之一,比如CPU问题,内存问题。

具体的Timeout算法参看Metalink Note:294430.1

通常,在某个节点被驱逐之后,cssd.log或者crsd.log或者操作系统自身的log中会有具体的信息记载,通过这些log可以知道到底是什么原因导致了节点被驱逐。但是,可能在某些情况下,由于操作系统在被强行reboot之前过于繁忙,根本没有任何空余的CPU时间片来将内存中的log内容写入到磁盘log文件中,这时候,我们在log中看到的就是忽然的一段时间空白之后就是Cluster重新启动的信息了。

在10.2.0.3之后,我们可以设置diagwait,来延迟eviction,让系统在重启之前等待几秒,尽量让log可以写入到磁盘上。该功能目前已经backport到10.1.0.5中,因此在 10.1.0.5 (or higher), 10.2.0.3 (or higher) 和11.1.0.6 (or higher)这些版本中都可以设置diagwait。

注:set diagwait不仅仅会延迟eviction,同时会将oprocd进程的检查margin从默认的500ms(10205中是1500ms)提升到10000ms(也就是10秒),opocd如果发现两次检查的时间间隔超过margin值,就会强制重启服务器,所以实际上set diagwait同样提高了RAC环境的稳定性。

在不支持的版本中设置diagwait将会得到”unrecognized parameter diagwait specified” 错误提示。

设置diagwait的方法,使用root用户执行以下命令:
1. 停止Clusterware

#crsctl stop crs 
#/bin/oprocd stop

2. 确认Clusterware stack已经完全关闭

#ps -ef |egrep "crsd.bin|ocssd.bin|evmd.bin|oprocd"

3. 在集群的任意节点上设置diagwait等待时间13秒

#crsctl set css diagwait 13 -force

4. 检查diagwait设置是否成功

#crsctl get css diagwait

如果设置成功,则返回13,否则返回”Configuration parameter diagwait is not defined”。

5. 重新启动Oracle Clusterware

#crsctl start crs

在解决完导致节点被驱逐的问题之后,可以将diagwait参数取消。

取消的方法仍然按照上面的命令步骤,只是将第3步中的命令改为:

#crsctl unset css diagwait

在Oracle 10gR2 + AIX5L的系统中,可能由于各种原因(比如操作系统的bug或者数据库的bug),导致OPROCD进程驱逐节点,检查以及解决的方法可以参看Metalink Note:419312.1

RAC10gR2 on HP-UX IA64

这几天经历了有史以来最痛苦的Oracle 10gR2 RAC的安装体验。

操作系统是HP-UX IA64,原本是两台已经安装过Oracle10gR2 CRS+RAC的系统,在安装完之后做了安全控制,取消了很多服务,然后机器从北京搬到上海,存储换了(意味着OCR和Voting Disk没有了),主机名称换了,网卡ID换了,IP地址换了(意味着重新构建OCR Disk很麻烦),在这样的一台机器上要重新安装RAC。

多次的失败之后,要求HP工程师重新安装了操作系统,从上周五白天一直到今天晚上才完全搞定,在今天晚上22:00才最后发现原来一切一切不可思议的问题都是源自于一个小小的环节,以往几天甚至对CRS在HP-UX上的稳定性都产生了极大的怀疑。

现象是,css/crs/evm这些后台进程用ps看全部都是正常的,但是crs_stat命令始终报无法连接CRS Daemon;重新启动机器之后有时候一个节点正常了,但是另外一个节点不正常,再次重启,不正常的节点可能又正常了;好不容易两个节点都正常了,数据库软件也安装完毕了,数据库也创建了,最后再重启一下两台机器,CRS又不正常了。。。几乎抓狂!

最后,焦点聚集到网卡的全双工和半双工设置上,网络集成商在屡次确认网络配置确实没有问题之后,在客户的强烈要求下,最后又再次检查了一下交换机,发现交换机上有两个端口设置成了半双工+自适应,而主机上的网卡全部都是全双工+非自适应,而这两个端口恰恰是连接某台数据库服务器上的Public网卡。就是这个网络设置上全双工和半双工的不匹配,让CRS发生了各种古怪的现象。

一切问题都在把交换机端口也设置为全双工+非自适应之后荡然无存。

这篇文章的意思是:CRS不是想象中那么不稳定,如果在安装过程中或者安装完毕有奇怪的现象,那么第一个要找的不是CRS软件本身,而是操作系统以及网络设置。

How to change VIP interface in 10g cluster

凌晨2点出发到客户处加班,加班的目的是由于改动网卡而重新配置VIP资源。

IBM AIX5L的系统,安装的是10gR2 RAC,在最开始安装的时候,客户配置了HACMP,并且设置了Primary网卡和Standby网卡,同时HACMP还会管理这两块网卡,当Public网卡出现问题的时候IP会切换到Standby网卡,但是10g Cluster的VIP却无法应对这种情况,当发生IP切换,VIP就down了。本来客户如此考虑是为了避免网卡的单点故障,但是通过HACMP这样管理的方法却仍然无法避免VIP的单点故障,因此客户决定今天晚上重新设置网卡,将原本的Primary和Standby网卡bunddle成一块Public网卡,这样网卡的Interface Name就会发生改变,所以VIP资源就需要重新配置。

修改VIP资源的步骤大体如下。

1. 停止数据库,CRS

$ srvctl stop database -d grid 
$ srvctl stop nodeapps -n node1
$ srvctl stop nodeapps -n node2

2. 修改OCR中的信息
删除原先的信息

$ORA_CRS_HOME/bin/oifcfg delif -global eth1

添加新的信息

$ORA_CRS_HOME/bin/oifcfg setif –global eth0/192.168.2.0:public

检查是否添加成功

$ORA_CRS_HOME/bin/oifcfg getif

3. 用root用户修改nodeapps
因为修改必须在 Oracle Clusterware stack启动状态下进行,因此上面一步要用srvctl stop nodeapps来停止资源而不要使用crsctl stop crs来停掉整个Clusterware。

# srvctl modify nodeapps -n node1 -A 192.168.2.125/255.255.255.0/eth0
# srvctl modify nodeapps -n node2 -A 192.168.2.126/255.255.255.0/eth0

检查是否修改成功

# srvctl config nodeapps -n  -a

4. 重新启动nodeapps和数据库

$ srvctl start nodeapps -n node1
$ srvctl start nodeapps -n node2
$ srvctl start database -d grid 

Oracle10gR2 RAC OCR & Voting Disk backup

在Oracle10gR2的RAC环境中,数据库自然是使用RMAN来备份,那么CRS和ASM实例如何备份呢?

Oracle会自动对CRS的配置信息OCR盘进行备份,Oracle会自动选择将备份文件存储在哪个节点上,通过ocrconfig命令我们可以知道最近的ocr备份信息的存储情况,然后定期使用操作系统的tar或者带库的文件系统备份功能将相应目录备份进磁带,就完成了ocr的备份。

$ /oracle/crs/cdata>ocrconfig -showbackup

server1 2007/04/17 12:23:56 /oracle/crs/cdata/crs
server1 2007/04/17 08:23:55 /oracle/crs/cdata/crs
server1 2007/04/17 04:23:54 /oracle/crs/cdata/crs
server1 2007/04/16 08:23:50 /oracle/crs/cdata/crs
server2 2007/04/04 02:14:51 /oracle/crs/cdata/crs

对于仲裁盘votingdisk,可以使用dd命令将其copy到文件系统,然后同样使用带库的文件系统备份功能备份到磁带上。crsctl query命令可以得到当前使用的votingdisk的设备名称。

$ /oracle/crs/cdata>crsctl query css votedisk
0. 0 /dev/vote_disk

$ /oracle/crs/cdata>dd if=/dev/vote_disk of=/orabackup/vote_disk
501760+0 records in.
501760+0 records out.

最后是ASM实例的备份,因为ASM没有任何数据文件,所以只需要在文件系统级别备份ASM的$ORACLE_HOME目录即可。

Powered by ScribeFire.

Oracle 10.2.0.3 RAC Reboot due to system time change

在Oracle10.2.0.3 RAC的测试中,发现如果修改某个节点的系统时间超过1.5秒,那么这个节点会被自动重新启动。

好狠的处理方式 ……

详细机制参见Internal Only的Metalink Note 308051.1

The OPROCD executable sets a signal handler for the SIGALRM handler and sets the interval timer based on the to-millisec parameter provided. The alarm handler gets the current time and checks it against the time that the alarm handler was last entered. If the difference exceeds (to-millisec + margin-millisec), it will fail; the production version will cause a node reboot.

尝试修改/etc/init.cssd中关于OPROCD的配置,将DISABLE_OPROCD设置为TRUE,然后重新启动系统,在系统进程中已经不存在oprocd进程,但是居然修改完系统时间以后,机器仍然被重新启动了。

文档中另外的描述提到,如果OPROCD是在non fatal mode状态下启动的,那么将只会写一段log而不去重新启动机器,并且在Note:265769.1中也描述了如何修改为non fatal mode,但是我没有去尝试。

In fatal mode, OPROCD will reboot the node if it detects excessive wait. In Non Fatal mode, it will write an error message out to the file .oprocd.log in one of the following directories.

最后尝试的结果是将整个cssd进程disable掉,这样可以避免因为修改系统时间而引起机器重启。

Oracle10g的CRS确实有些霸道,上次的测试中拔掉Private IP网卡上的网线,操作系统会重新启动,这次居然修改系统时间也会导致系统重启,真当这些机器是Windows了?UNIX Server中重启一次机器多大的事儿啊,CRS搞的跟吃饭一样随意,时不常reboot。

下面的这段资料描述了Oracle CRS的三个进程会在哪些状态下重新启动机器。

Oracle clusterware has the following three daemons which may be responsible for panicing the node. It is possible that some other external entity may have rebooted the node. In the context of this discussion, we will assume that the reboot/panic was done by an Oracle clusterware daemon.

* Oprocd – Cluster fencing module
* Cssd – Cluster sychronization module which manages node membership
* Oclsomon – Cssd monitor which will monitor for cssd hangs

OPROCD This is a daemon that only gets activated when there is no vendor clusterware present on the OS. This daemon is also not activated to run on Windows/Linux. This daemon runs a tight loop and if it is not scheduled for 1.5 seconds, will reboot the node.
CSSD This daemon pings the other members of the cluster over the private network and Voting disk. If this does not get a response for Misscount seconds and Disktimeout seconds respectively, it will reboot the node.
Oclsomon This daemon monitors the CSSD to ensure that CSSD is scheduled by the OS, if it detects any problems it will reboot the node.

更多讨论参见itpub note 747833

关于为何要reboot,Wing Hong在上面的帖子里对fencing有一段深入浅出的解释,摘录如下。

fencing is a very important concept in cluster. not sure I can explain clearly in a few words. any how , forget about RAC first, just look at generic share-disk cluster issue.

let’s say the cluster only has two nodes. both share the disk. ie. they both have the right to write to the same disk.

so this share access must be coordinated.

however , if for some reason , this coordination lost, it can be any reason, communication process hanging, you unplug the network cable between them, etc etc

at this moment both nodes are functioning normally except the lost coordination between them.

then the cluster has two problems to solve:
1. who will be the new member of the new incarnation of cluster , in this case, this is split brain issue.

2. once we decide who will remain in the cluster and who will go , how can we prevent the going node NOT to do something harmful to the cluster ? this is fencing issue. Bear in mind , the going node is working perfectly normal except the coordination part, so it still can write to the shared-disk.

There are a couple of approaches in fencing:

1.server fencing , in cluster terms, Shoot The Other Node In The Head (STONITH) , i.e the good node kill the going node.

( the way Oracle do is : reboot itself, once go through the reboot process, it just do the rejoin cluster again, then the cluster can decide whether accept it or not )

2. I/O fencing. rather than trying to kill the node, it is working on the disks side to block the going node’s access to disk, Sun , Veritas has solution on this way.

HTH. also try to do a google on terms like “fencing” , “split brain”, “amnesia”.