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,好吧,解决问题就好。

Tips for Installing Oracle11gR2 RAC on AIX 6.1

不准备写一篇完整的Installation Guide,安装光盘中自带的pdf文档已经足够。本文只是总结一些在安装过程中碰到的问题或者说应该要注意的要点。

1. 如下命令的软件包需要配全,通常在安装完操作系统以后就应该已经都有了。

lslpp -l bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat \
 bos.perf.perfstat bos.perf.proctools rsct.basic.rte rsct.compat.clients.rte xlC.aix61.rte

2. 安装文档中提到的fix即使不存在也不影响安装。

# instfix -i -k "IZ41855 IZ51456 IZ52319"
    There was no data for IZ41855 in the fix database.
    All filesets for IZ51456 were found.
    There was no data for IZ52319 in the fix database.

3. 11gR2 RAC自带CTSS时间同步服务,因此安装文档中要求禁用NTP,但是在安装过程中最后检查的时候,仍然会报NTP服务无法使用,可以直接忽略。

4. 11gR2 RAC安装中对于用户和用户组的建议可以说比以前复杂很多,不再仅仅是oinstall和dba这两个用户组。为了方便我们仍然可以只创建oinstall和dba这两个用户组,但是建议按照安装文档中描述的那样创建grid和oracle这两个用户,用grid用户安装Grid Infrastructure,用oracle用户安装RAC。

5. 11gR2中OCR和Voting是可以放置在ASM磁盘组中,因此实际上在整个数据库环境中,应该会存在至少三个ASM Disk Group,也就是crsdg(用于GRID使用)、datadg(数据库数据文件)、fradg(闪回区)。这里需要特别注意,所有磁盘组都是用grid用户执行asmca来创建的(当然你可以用create diskgroup命令创建),而最后数据库实例是以oracle用户启动的,也就是oracle用户也必须有读写磁盘组中disk的权限。

假设我们的环境中有rhdisk2、rhdisk3、rhdisk4三个LUN分别对应crsdg、datadg和fradg,那么建议做如下的权限设置:

chown grid:oinstall /dev/rhdisk2
chown grid:oinstall /dev/rhdisk3
chown grid:oinstall /dev/rhdisk4
chmod 660 /dev/rhdisk3
chmod 660 /dev/rhdisk4

# ls -l /dev/rhdisk*
crw-------    1 grid     oinstall     23,  3 Jun 01 16:23 /dev/rhdisk2
crw-rw----    1 grid     oinstall     23,  4 Jun 01 16:13 /dev/rhdisk3
crw-rw----    1 grid     oinstall     23,  2 Jun 01 16:13 /dev/rhdisk4

6. 新增的SCAN VIP其实可有可无,特别对于不会频繁增删数据库节点的环境,个人觉得几乎无用。而且实际上,SCAN VIP和SCAN VIP LISTENER的切换操作十分缓慢,在我的测试中relocate scan的操作大概需要花费2分钟才能完成,不确认是不是我个人的配置问题。

SCAN VIP也同样是绑定在RAC环境中的某个节点上。如下SCAN VIP则是绑定在dbserver2中的public网卡上,可以看到public网卡上总共有3个IP,一个是实IP,一个是VIP,一个是SCAN VIP。

# crs_stat -t|grep scan
ora....N1.lsnr ora....er.type ONLINE    ONLINE    dbserver2 
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    dbserver2 

# srvctl config scan_listener
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521

# srvctl config scan
SCAN name: crs-scan.cnrmall.com, Network: 1/192.168.255.0/255.255.255.0/en0
SCAN VIP name: scan1, IP: /crs-scan.cnrmall.com/192.168.255.250

# netstat -in
Name  Mtu   Network     Address           ZoneID    Ipkts Ierrs    Opkts Oerrs  Coll
en0   1500  link#2      0.21.5e.48.e4.60       -    96331     0    47140     0     0
en0   1500  192.168.255 192.168.255.225        -    96331     0    47140     0     0
en0   1500  192.168.255 192.168.255.235        -    96331     0    47140     0     0
en0   1500  192.168.255 192.168.255.250        -    96331     0    47140     0     0
en1   1500  link#3      0.21.5e.48.e4.61       -   342409     0   293503     0     0
en1   1500  172.16      172.16.0.2             -   342409     0   293503     0     0
lo0   16896 link#1                             -   103667     0   103678     0     0
lo0   16896 127         127.0.0.1              -   103667     0   103678     0     0
lo0   16896 ::1                                0   103667     0   103678     0     0

7. SCAN VIP在Oracle安装文档的建议中是需要配置在DNS服务器中,实际上也可以使用/etc/hosts文件,并且除却SCAN VIP之外的public ip、vip、private ip也仍然都是可以跟以前一样,配置在/etc/hosts文件中。

8. 安装11gR2 RAC要求必须配置ssh用户对等性,以前配置rsh的方式现在已经无法通过安装检查。OUI中提供了自动配置ssh用户对等性的按钮,因此无需再事先手动配置。

需要注意的是:该功能完全针对Linux环境进行的开发,因此在AIX环境中,需要事先作如下操作:

ln -s /usr/bin/ksh /bin/bash
mkdir -p /usr/local/bin
ln -s /usr/bin/ssh-keygen /usr/local/bin/ssh-keygen

在配置对等性时,OUI会使用/bin/bash,而AIX默认是没有bash的,因此需要将ksh软链接到bash(当然你也可以安装bash包)。
同样,OUI会使用/usr/local/bin/ssh-keygen产生对等性密钥,而AIX中在安装了OpenSSH以后,ssh-keygen命令默认是存储在/usr/bin中,因此也需要做link。

9. 在成功安装完Grid Infrastructure之后,运行cluvf命令可能会报错。

# cluvfy comp nodeapp -verbose

ERROR: 
CRS is not installed on any of the nodes
Verification cannot proceed

并且,在碰到这样的错误之后,也无法安装RAC,会碰到如下错误:

[INS-35354] The system on which you are attempting to install Oracle RAC is not part of a valid cluster.

也就是无论是cluvf命令还是OUI,都认为这个机器上没有安装CRS,并不是在一个集群环境中。但是实际上运行crsctl check crs命令是完全正常的。

这个错误的解决方法可以参看Metalink Note [ID 798203.1],大体上来说就是在安装Grid Infrastructure的时候,inventory.xml文件中丢掉了CRS=”true”字样,这无疑是安装程序的bug。需要手工detachHome再attachHome。

10. 11gR2 RAC在CRS资源部分做了很多改动,创建完RAC数据库以后的默认资源比以前多了不少。

# crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.CRSDG.dg   ora....up.type ONLINE    ONLINE    dbserver1   
ora.DATADG.dg  ora....up.type ONLINE    ONLINE    dbserver1   
ora.FRADG.dg   ora....up.type ONLINE    ONLINE    dbserver1   
ora....ER.lsnr ora....er.type ONLINE    ONLINE    dbserver1   
ora....N1.lsnr ora....er.type ONLINE    ONLINE    dbserver2   
ora.asm        ora.asm.type   ONLINE    ONLINE    dbserver1   
ora.dbcnr.db   ora....se.type ONLINE    ONLINE    dbserver2   
ora....SM1.asm application    ONLINE    ONLINE    dbserver1   
ora....R1.lsnr application    ONLINE    ONLINE    dbserver1   
ora....er1.gsd application    OFFLINE   OFFLINE               
ora....er1.ons application    ONLINE    ONLINE    dbserver1   
ora....er1.vip ora....t1.type ONLINE    ONLINE    dbserver1   
ora....SM2.asm application    ONLINE    ONLINE    dbserver2   
ora....R2.lsnr application    ONLINE    ONLINE    dbserver2   
ora....er2.gsd application    OFFLINE   OFFLINE               
ora....er2.ons application    ONLINE    ONLINE    dbserver2   
ora....er2.vip ora....t1.type ONLINE    ONLINE    dbserver2   
ora.eons       ora.eons.type  ONLINE    ONLINE    dbserver1   
ora.gsd        ora.gsd.type   OFFLINE   OFFLINE               
ora....network ora....rk.type ONLINE    ONLINE    dbserver1   
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    dbserver2   
ora.ons        ora.ons.type   ONLINE    ONLINE    dbserver1   
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    dbserver2 

启动数据库实例以后,可以看到11gR2的后台进程已经增加到了43个,说实话,我很怀念简单的Oracle8i。

# ps -ef|grep ora_ | grep -v grep
  oracle  364656       1   0 17:01:17      -  0:00 ora_mark_dbcnr1 
  oracle  540722       1   0 17:01:17      -  0:03 ora_mmnl_dbcnr1 
  oracle  561184       1   0 18:07:34      -  0:00 ora_q003_dbcnr1 
  oracle  643244       1   0 17:01:17      -  0:01 ora_mmon_dbcnr1 
  oracle  651360       1   0 17:01:16      -  0:00 ora_asmb_dbcnr1 
  oracle  655494       1   0 17:01:16      -  0:00 ora_rbal_dbcnr1 
  oracle  663680       1   1 17:01:13      -  0:06 ora_lmd0_dbcnr1 
  oracle  667794       1   0 17:01:12      -  0:00 ora_pmon_dbcnr1 
  oracle  671832       1   0 17:01:12      -  0:01 ora_diag_dbcnr1 
  oracle  675932       1   0 17:01:16      -  0:00 ora_smon_dbcnr1 
  oracle  679962       1   0 17:01:12      -  0:00 ora_gen0_dbcnr1 
  oracle  696414       1   0 17:01:16      -  0:00 ora_dbw0_dbcnr1 
  oracle  708790       1   0 17:02:33      -  0:00 ora_qmnc_dbcnr1 
  oracle  716930       1   0 17:01:17      -  0:04 ora_lck0_dbcnr1 
  oracle  721124       1   0 17:01:16      -  0:00 ora_mman_dbcnr1 
  oracle  725186       1   0 17:02:32      -  0:00 ora_gtx0_dbcnr1 
  oracle  729102       1   0 17:01:15      -  0:00 ora_lmhb_dbcnr1 
  oracle  737358       1   0 17:01:16      -  0:00 ora_reco_dbcnr1 
  oracle  745554       1   0 17:02:34      -  0:00 ora_q001_dbcnr1 
  oracle  749762       1   0 17:01:16      -  0:00 ora_lgwr_dbcnr1 
  oracle  753716       1   0 17:01:12      -  0:00 ora_ping_dbcnr1 
  oracle  766014       1   0 17:01:13      -  0:00 ora_psp0_dbcnr1 
  oracle  790688       1   0 17:01:13      -  0:00 ora_acms_dbcnr1 
  oracle  794780       1   0 17:01:12      -  0:02 ora_vktm_dbcnr1 
  oracle  815252       1   0 17:01:12      -  0:00 ora_dbrm_dbcnr1 
  oracle  819350       1   1 17:01:15      -  0:16 ora_lms1_dbcnr1 
  oracle  827642       1   0 17:02:36      -  0:01 ora_cjq0_dbcnr1 
  oracle  848054       1   0 17:02:30      -  0:00 ora_arc0_dbcnr1 
  oracle  856270       1   0 17:01:15      -  0:00 ora_rms0_dbcnr1 
  oracle  868590       1   0 17:25:42      -  0:00 ora_q002_dbcnr1 
  oracle  872622       1   0 17:01:15      -  0:16 ora_lms0_dbcnr1 
  oracle  901314       1   0 17:02:32      -  0:00 ora_arc3_dbcnr1 
  oracle  921600       1   0 18:07:17      -  0:00 ora_pz98_dbcnr1 
  oracle  925926       1   0 17:01:18      -  0:00 ora_rsmn_dbcnr1 
  oracle  929980       1   0 17:07:35      -  0:00 ora_smco_dbcnr1 
  oracle  942286       1   0 18:07:17      -  0:00 ora_pz99_dbcnr1 
  oracle  950274       1   0 17:02:32      -  0:00 ora_rcbg_dbcnr1 
  oracle  958498       1   0 17:02:31      -  0:00 ora_arc2_dbcnr1 
  oracle  974876       1   0 18:07:38      -  0:00 ora_w000_dbcnr1 
  oracle 1011914       1   0 17:01:16      -  0:01 ora_ckpt_dbcnr1 
  oracle 1052884       1   1 17:01:13      -  0:06 ora_lmon_dbcnr1 
  oracle 1069246       1   1 17:01:13      -  0:33 ora_dia0_dbcnr1 
  oracle 1110056       1   0 17:02:31      -  0:00 ora_arc1_dbcnr1 
# ps -ef|grep ora_ | grep -v grep | wc -l
      43
#