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帐号的朋友在这里下载脚本。