大话Oracle Grid:云时代的RAC
上QQ阅读APP看书,第一时间看更新

第2章 安装引发的思考

在第1章中,我们装了Oracle Grid、Oracle Database、创建数据库,搞定了Oracle RAC 11.2的部署。对于有10.2 RAC经验的朋友来说,一定能对11.2的诸多变化有所感触。因此,我们先不急着深入到Grid的内部,我们先把在安装过程中遇到的这些变化梳理一下,对11.2的Grid有个直观的认识。

2.1 怎么有这么多用户和用户组

在Oracle 10.2 RAC的部署中,我们只需要一个用户(oracle)和一个用户组(dba),不管是Clusterware还是Database,都是用oracle安装的,只是在最后执行root.sh脚本时才切换到root用户。

在部署Oracle 11.2的过程中,我们创建了两个用户(oracle、grid)和5个用户组(oinstall、dba、asmadmin、asmdba和asmoper,一共可以用到6个用户组,其中oper和asmoper两个组是可选的)。Grid是用grid用户安装的,Database是oracle用户安装的。

继续阅读之前,考虑下面这几个问题。

Oracle搞出这么多花样目的何在?是别有用心,还是另有隐情?

是谁在管理ASM?

是谁在管理数据库?和ASM是一个人吗?如果不是,这两个人是如何交叉的?

这两个用户的主组都是oinstall,你认为权限和这个有关系吗?

如果读者对这些问题都似是而非,那么就继续阅读下面的内容。先来看一看单实例环境下(不使用ASM存储的单实例)的用户和用户组。

2.1.1 老朋友

单实例(single-instance)环境中常用的3个操作用户组分别是oinstall、dba、oper。

1.oinstall

这个组也叫Oracle产品清单组,代表Oracle软件的“所有者”。怎么会有这么个组呢? Oracle公司现在是个巨无霸,它有好多的软件,光数据库就有Oracle Database、TimesTen、Berkeley DB、MySQL几个不同的产品线,还有中间件(Weblogic、Tuxedo),有BI系统,还有很多我根本不知道干什么的系统。这些软件都可以从 OTN 上免费下载使用,所以我们的机器上很可能会装了一堆的Oracle软件,或者装了一个Oracle软件的好几个版本。

Oracle会记录机器上都装了哪些软件及哪个版本。这份记录就是Oracle的产品清单,Oracle的大部分产品都会支持产品清单,而且是共用一份产品清单。

Oinstall这个组的成员就拥有对“Oracle 产品清单”(oraInventory)的写权限。

在一个系统上首次安装Oracle的软件时(不必是Oracle数据库,可以是任何一款产品),Oracle的安装程序OUI都会创建一个/etc/oraInst.loc文件(AIX或者Linux)。如果是Sun平台,则是/var/opt/oracle/oraInst.loc这个文件。这个文件的内容一般是这样的:

inventory_loc=/u01/app/oracle/oraInventory

inst_group=oinstall

这个文件还不是“Oracle 产品清单”。这个文件只是记录了“Oracle 产品清单组”的组名以及“Oracle产品清单”文件的位置。就这个文件而言,我们可以得到这样的信息:

(1)Oracle产品清单组的组名是oinstall;

(2)Oracle产品清单记录在/u01/app/oracle/oraInventory这个目录中。

真正的清单文件是这个 ContentsXML 目录下的 inventory.xml 文件,这个文件中记录了机器上安装的各种产品,下面就是一个例子。

[oracle@dbp ContentsXML]$ more inventory.xml

<?xml version="1.0" standalone="yes" ?>

<!-- Copyright (c) 2005 Oracle Corporation.All rights Reserved -->

<!-- Do not modify the contents of this file by hand.-->

<INVENTORY>

<VERSION_INFO>

<SAVED_WITH>10.2.0.1.0</SAVED_WITH>

<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>

</VERSION_INFO>

<HOME_LIST>

<HOME NAME="OraDb10g_home1" LOC="/oracle/product/10G" TYPE="O" IDX="2"/>

<HOME NAME="agent10g" LOC="/oracle/product/grid/agent10g" TYPE="O" IDX="5"/>

<HOME NAME="CRS_HOME" LOC="/oracle/product/oem/crs" TYPE="O" IDX="1" CRS="true">

<NODE_LIST>

<NODE NAME="dbs"/>

<NODE NAME="dbp"/>

</NODE_LIST>

</HOME>

<HOME NAME="ORACLE_HOME" LOC="/oracle/product/oem/database" TYPE="O" IDX="6">

<NODE_LIST>

<NODE NAME="dbs"/>

<NODE NAME="dbp"/>

</NODE_LIST>

</HOME>

<HOME NAME="agent10g1" LOC="/oracle/product/agent10g" TYPE="O" IDX="7"/>

<HOME NAME="AgentHome" LOC="/oracle/product/oem10.204/agent10g" TYPE="O" IDX="8"/>

<HOME NAME="10GAGENT" LOC="/oracle/product/10goem/agent10g" TYPE="O" IDX="9"/>

<HOME NAME="ORACLE_HOME_10203" LOC="/oracle/product/10.2.0.3" TYPE="O" IDX="10"/>

<HOME NAME="OraDb10g_home2" LOC="/wxxrdata/oracle10.2.0.3" TYPE="O" IDX="11"/>

<HOME NAME="OraDb10g_home3" LOC="/wxxrdata/temp/tmp" TYPE="O" IDX="12"/>

<HOME NAME="db10g" LOC="/oracle/oem/db10g" TYPE="O" IDX="3" REMOVED="T"/>

<HOME NAME="oms10g" LOC="/oracle/oem/oms10g" TYPE="O" IDX="4" REMOVED="T"/>

</HOME_LIST>

</INVENTORY>

Oracle软件的安装、卸载功能都会依赖并维护这个文件。对一个新环境,我们可以通过这个文件来了解它上面软件的安装情况。有些时候,这个文件还能解决一些怪异的问题。后面的2.2小节就使用这个文件解决了一个实际问题。

在RAC环境下创建oinstall用户组时,要保证各节点上用户组的gid一致,保险的做法是在创建用户组时明确指定组的ID,避免用系统自动生成组ID时可能造成的不一致。

如果没有oinstall组,Oracle也要找个组来充当“Oracle产品清单”的角色。默认情况下,安装程序会把Grid安装者所在的主组当作“Oracle产品清单组”。因此一定要保证所有规划的Oracle软件安装用户都把这个组当作自己的主组。也就是说,我们计划安装Grid、Database这两个软件,而它们各自的安装用户分别是grid和oracle,我们就必须将grid和oracle用户的主组设置为oinstall,这也是为什么在创建用户时会使用-g这个参数。

#/usr/sbin/groupadd -g 505 oinstall

这个组很关键,我们必须要重视这个组。Oracle 11gR2 的 RAC 的安装和 10g 很不一样,在Oracle 10g中,Clusterware和Database两个软件的安装用户都是oracle,所以不会有访问权限的问题。而到了Oracle 11gR2时,原来的Clusterware换成了Grid,又多了一个grid用户。必须保证oracle、grid这两个用户都属于oinstall,这样才能保证在两个软件的安装过程都有权限访问“产品清单”,否则安装过程中会遇到“oraInventory无法访问”的权限错误。

2.dba组(OSDBA用户组)

OSDBA是我们必须要创建的一个系统级的用户组(习惯叫dba),如果没有这个用户组,我们就无法安装数据库软件和进行后续的数据库管理任务。

设置OSDBA组是和Oracle的操作系统身份验证有关的。属于这个组的用户,可以在通过操作系统身份验证后,通过SQL*Plus以SYSDBA身份连接到Oracle数据库实例。这个组的成员有权执行一些关键的、也是危险的管理任务,比如创建数据库、启动和关闭数据库。这个组的默认名称就为dba。SYSDBA系统权限甚至允许在数据库还没打开时访问数据库实例。对此权限的控制完全超出了数据库本身的范围。

不要混淆SYSDBA系统权限与数据库角色DBA。DBA角色不包括SYSDBA或SYSOPER系统权限。也就是说,即使DBA组成员,也要明确指明要以SYSDBA的权限登录,才能得到SYSDBA的权限。像这样:

oracle> sqlplus ‘ / as sysdba’

3.oper组(OSOPER用户组)

OSOPER组是一个可选的组。这个组也是和Oracle操作系统身份认证功能有关的,属于这个组的成员可通过操作系统身份验证使用SQL*Plus以SYSOPER身份连接到Oracle实例。这个可选组的成员拥有一组有限的数据库管理权限,比如可以做备份。这个组的默认组名就是oper。要使用该组,在安装Oracle数据库软件的过程中要选择“Advanced安装类型”进行安装。

既然是可选的,那我们既可以创建也可以不创建这个用户组,创建这个用户组的目的是让一些操作系统的用户也能够行使某些数据库的管理权限(包括 SYSOPER 角色权限)。注意SYSOPER的权限包括startup和shutdown,所以要小心为该用户组添加成员。

创建OSOPER用户组的方法:

# /usr/sbin/groupadd oper

综上所述,在单实例环境(single-instance)中,Oracle Database软件的安装者也是所有者通常都是oracle这个操作系统用户,oracle用户同时也是oinstall、dba、oper用户组的成员。同时oracle用户的主组必须是oinstall。也就是创建oracle用户是这样创建的:

useradd –g oinstall –G dba,oper oracle

在数据库软件的安装过程中,需要指定操作系统用户组,界面如图2-1所示。

图2-1 选择Privileged Operating System用户

这个界面中有两个下拉列表框,这两个列表框就是用来选择之前说的OSDBA和OSOPER两个组对应的操作系统的用户组组名。这里的选择,会影响到$ORACLE_HOME/rdbms/lib/config.c这个文件,这个文件中定义了SS_DBA_GRP和SS_OPER_GRP两个宏:

/* Refer to the Installation and User's Guide for further information.*/

/* IMPORTANT: this file needs to be in sync with

rdbms/src/server/osds/config.c, specifically regarding the

number of elements in the ss_dba_grp array.

*/

#define SS_DBA_GRP "dba"

#define SS_OPER_GRP "oper"

#define SS_ASM_GRP ""

char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};

2.1.2 集群环境的用户组

在Oracle 10g中,Clusterware和Database都是由DBA一个角色进行管理的。在Oracle 11gR2的RAC中,Oracle开始主张把集群环境和数据库的管理拆开。其实这也是Oracle的策略使然,Oracle由原来唱衰“云”变成了积极的“云”推动者,显然它看到了“云”市场的巨大商机。

而Oracle的各条产品线中,也只有Grid(Clusterware)最有可能扛起“Oracle云”的大旗。因此,Oracle非常迫切地要给这个产品去掉数据库的烙印。Oracle现在格外强调它的GI(Grid Infrastructure)是一个基础架构,而RAC数据库只是这个环境中一个普通的资源而已,对它的管理,普通的 DBA稍加培训就可以了。相反,对于架构环境本身的管理,反而需要一个更独立、更专业的角色来进行。这也是它在强调的。

它这种观点不仅仅是想想而已,也已经落实到产品上了。在Oracle的Grid环境中,出现专门管理Grid的用户、用户组以及管理数据库的用户、用户组就是极好的佐证。

于是在Oracle 11.2的Grid中,又多了3个专门管理ASM的用户组。

1.asmadmin(OSASM)用户组

要在 Oracle 11.2 环境中使用 ASM,必须创建 asmadmin(OSASM)用户组,这个用户组也是一个必需的组。这么做也是为了让Oracle ASM管理员和Oracle Database管理员分属不同的管理权限组。

OSASM 组的成员可通过操作系统身份验证使用 SQL*Plus 以 SYSASM 身份连接到一个 Oracle ASM 的实例。SYSASM 是在 Oracle 11G R1 版中出现的权限,到了 Oracle 11gR2,这个权限已经从SYSDBA中完全分离出来了。SYSASM权限不再有对RDBMS实例的访问权限。

用SYSASM取代SYSDBA主要是为了把存储层的系统权限剥离出来,这样对ASM的管理和数据库管理之间有了清晰的责任划分,有助于防止使用相同存储的不同数据库无意间覆盖其他数据库的文件。

OSASM组的成员会被赋予SYSASM权限,SYSASM权限可以执行挂载和卸载磁盘组及其他的存储管理任务。因为对Grid的管理很大程度上就是对ASM的管理,所以这个组的成员可以同时管理Oracle Clusterware和Oracle ASM,因为Clusterware+ASM=Grid。

(1)SYSASM权限。

在Oracle 10.2中,ASM实例的启动和RDBMS数据库一样,都需要管理员以sysdba的身份登录后执行startup命令。

到了Oracle 11.2时,管理员就不能再以sysdba的身份启动ASM数据库了,必须以sysasm角色连接后才能进行操作。

如果以sysdba身份执行启动或者关闭ASM实例的命令,Oracle会提示权限不够。下面就是关闭ASM实例的示例:

[root@searchdb2 ~]# sqlplus "sys/ *** as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Thu Sep 1 10:18:14 2011

Copyright (c) 1982, 2009, Oracle.All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SQL> shutdown immediate;

ORA-01031: insufficient privileges

我们需要退出来后,以sysasm的身份重新连接到实例后,命令才能得以执行:

[grid@indexserver4 ~]$ sqlplus " / as sysasm"

SQL*Plus: Release 11.2.0.2.0 Production on Wed Jun 13 15:56:44 2012

Copyright (c) 1982, 2010, Oracle.All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SQL> shutdown immediate;

ASM diskgroups volume disabled

ASM diskgroups dismounted

ASM instance shutdown

SQL> exit

(2)如何正确关闭ASM实例。

如果你恰好在一个Oracle 11.2 RAC上执行了上面的shutdown命令时,就可能会出现无法关闭的情况,比如:

[grid@indexserver1 ~]$ export ORACLE_SID=+ASM1

[grid@indexserver1 ~]$ sqlplus " / as sysasm"

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jun 14 16:05:08 2012

Copyright (c) 1982, 2010, Oracle.All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SQL> shutdown;

ORA-15097: cannot SHUTDOWN ASM instance with connected client (process 22989)

使用shutdown immediate命令也不行:

SQL> shutdown immediate;

ORA-15097: cannot SHUTDOWN ASM instance with connected client (process 22989)

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options。

即使关闭了数据库后,再执行上面的命令,得到的结果也是一样的。这是因为在Oracle 11.2 RAC环境中,CRS和ASM的关系发生了变化。

在 Oracle 10g 中,ASM 里只能放 Oracle 数据库文件,所有 ASM 只有一种客户端,就是Oracle 数据库。因此,在Oracle 10g 的环境下,我们关闭RAC 的顺序是这样的:关闭数据库Æ关闭ASMÆ关闭CRS。

但是在Oracle 11gR2下,如果是用OUI来安装,除了数据库的数据文件之外,集群自己的OCR和Voting File也是放在ASM里的。

所以这里就遇到了问题。因为集群文件也是放在 ASM 里的,这样 CRSD 也成为了 ASM的客户端。如果像Oracle 10g中那样直接关闭ASM,就会因为还有客户端连接到ASM实例而抛出上面的错误。所以,在Oracle 11gR2下面,要停ASM实例,只能和CRS一起停掉才行。因此正确的关闭方法是关闭CRS。

在root用户下这么做:

[root@indexserver1 ~]# crsctl stop crs

CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on'indexserver1'

CRS-2673: Attempting to stop 'ora.crsd' on 'indexserver1'

CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'indexserver1'

CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'indexserver1'

CRS-2673: Attempting to stop 'ora.registry.acfs' on 'indexserver1'

CRS-2673: Attempting to stop 'ora.DATA.dg' on 'indexserver1'

CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.indexserver1.vip' on 'indexserver1'

CRS-2677: Stop of 'ora.indexserver1.vip' on 'indexserver1' succeeded

CRS-2672: Attempting to start 'ora.indexserver1.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.registry.acfs' on 'indexserver1' succeeded

CRS-2676: Start of 'ora.indexserver1.vip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.DATA.dg' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.asm' on 'indexserver1'

CRS-2677: Stop of 'ora.asm' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.ons' on 'indexserver1'

CRS-2677: Stop of 'ora.ons' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.net1.network' on 'indexserver1'

CRS-2677: Stop of 'ora.net1.network' on 'indexserver1' succeeded

CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'indexserver1' has completed

CRS-2677: Stop of 'ora.crsd' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'indexserver1'

CRS-2673: Attempting to stop 'ora.ctssd' on 'indexserver1'

CRS-2673: Attempting to stop 'ora.evmd' on 'indexserver1'

CRS-2673: Attempting to stop 'ora.asm' on 'indexserver1'

CRS-2673: Attempting to stop 'ora.mdnsd' on 'indexserver1'

CRS-2677: Stop of 'ora.asm' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'indexserver1'

CRS-2677: Stop of 'ora.drivers.acfs' on 'indexserver1' succeeded

CRS-2677: Stop of 'ora.evmd' on 'indexserver1' succeeded

CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'indexserver1' succeeded

CRS-2677: Stop of 'ora.mdnsd' on 'indexserver1' succeeded

CRS-2677: Stop of 'ora.ctssd' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.cssd' on 'indexserver1'

CRS-2677: Stop of 'ora.cssd' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.diskmon' on 'indexserver1'

CRS-2673: Attempting to stop 'ora.crf' on 'indexserver1'

CRS-2677: Stop of 'ora.crf' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.gipcd' on 'indexserver1'

CRS-2677: Stop of 'ora.diskmon' on 'indexserver1' succeeded

CRS-2677: Stop of 'ora.gipcd' on 'indexserver1' succeeded

CRS-2673: Attempting to stop 'ora.gpnpd' on 'indexserver1'

CRS-2677: Stop of 'ora.gpnpd' on 'indexserver1' succeeded

CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'indexserver1' has completed

CRS-4133: Oracle High Availability Services has been stopped.

注意:不要直接kill掉ASM 进程或者用shutdown abort来关闭ASM实例,这样CRS也会挂掉。

2.asmdba(OSDBA for ASM group)用户组

ASM数据库管理员组(OSDBA for ASM)的成员是SYSASM权限的一个子集,这个组被赋予了对Oracle ASM所管理的文件的读写权限。

Grid软件的安装者、所有者(一般都是grid)以及Oracle Database软件的所有者(一般是oracle)必须是该组的成员,而那些需要访问由ASM管理的文件并且属于OSDBA组(dba组)的用户也必须是ASM的OSDBA组的成员。

因此,grid用户和oracle用户都需要属于这个组。

3.asmoper(OSOPER for ASM)用户组

这个组也是个可选组。如果需要单独设置一个对 ASM 实例有部分管理权限( ASM 的SYSOPER权限,包括启动和停止Oracle ASM实例的权限)的操作系统用户,那么我们就可以创建这个组。在默认情况下,OSASM组的成员将拥有ASM的SYSOPER权限所授予的所有权限。

要想使用ASM操作员组,在安装Grid软件时必须选择Advanced安装类型。这时OUI会指定该组的名称。

如果要拥有一个OSOPER for ASM组,则Grid软件所有者(grid)也必须是这个组的一个成员。

在Grid安装过程中,遇到得如图2-2所示的这个界面,就是针对这3个用户组的。

图2-2 Grid安装中遇到的ASM用户组

现在再回顾一下之前看到的表1-2,希望你现在已经对它深入了解了。

2.1.3 GI owner 和 DB owner 是否有必要分开

现在我们再对这个问题做一个深入的探讨。

首先,Oracle Clusterware或者Oracle Grid本身只是Oracle RAC环境中的一个软件,因此自然而然地看起来是应该交给DBA管理的。不过,许多Clusterware的管理任务都需要以root的身份运行,这些又超出了DBA本身的一亩三分地。所以说把Clusterware交给系统管理员来维护也不是没有道理的,而且ASM提供的是存储管理(尽管是用Oracle软件实现的软存储管理),按理也应该是交给系统管理员或者存储管理员(如果有的话)来维护。

在Oracle 10g中,我们可以把CRS和RDBMS分开用两个用户安装(尽管实际上没有人这么做),从而实现一定程度的管理功能分隔。不过,Oracle 10g的ASM还是在RDBMS中的,而且10g 中的ASM 很多任务还是通过SQL 指令完成的,因此,Oracle 10g 中对ASM 的管理还主要是DBA的任务。

Oracle 11g提出了Role-separated Management的思想。把ASM和Clusterware集成为一体,进而可以用不同的操作系统用户组把DBA和ASM管理员隔离开。另外,Oracle 11g提供了新的ASM配置助手(ASMCA)、命令行工具asmcnd,现在都可以完全地分配给存储和系统管理员来完成了。

正是因为ASM和Clusterware的集成,因此,即使你不打算使用Role-separated Management,我也建议你给Grid home和RDBMS home不同的owner。这样如果以后想把任务分离出去,也提前预留出了操作空间。

2.2 DBCA不识别集群环境的解决办法

这个问题是之前所讲的“Oracle产品清单”的一个真实案例。

如果读者按照之前的步骤完成了集群的部署,你不妨在每一个节点上都运行一下DBCA,看看是看到如图2-3所示的这个界面呢?还是看到如图2-4所示的这个界面?通常来说,在一个集群环境中,执行 runInstaller 的那个节点上的 DBCA 都能够识别出集群环境,并给出正确的界面(如图2-3所示),也就是Oracle RAC的欢迎页面。

图2-3 能够识别集群环境的DBCA

图2-4 没有识别出集群环境的DBCA界面

而其他节点上的DBCA界面可能如图2-4所示,这就是因为DBCA不能识别集群环境所引起的问题更多DBCA的问题,可以参看http://docs.oracle.com/cd/E11882_01/install.112/e25666/dbcacrea.htm#BGBGGEAH。如果单击【Next】按钮,就会发现全是单实例的内容。

这是因为什么呢?主要是产品清单的问题,我们分别对比两个节点的内容。

以下是能够出现Oracle RAC Welcome page节点的内容:

<?xml version="1.0" standalone="yes" ?>

<!-- Copyright (c) 1999, 2010, Oracle.All rights reserved.-->

<!-- Do not modify the contents of this file by hand.-->

<INVENTORY>

<VERSION_INFO>

<SAVED_WITH>11.2.0.2.0</SAVED_WITH>

<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>

</VERSION_INFO>

<HOME_LIST>

<HOME NAME="Ora11g_gridinfrahome1" LOC="/u01/app/11.2.0.2/grid" TYPE="O" IDX="1" CRS="true">

<NODE_LIST>

<NODE NAME="indexserver1"/>

<NODE NAME="indexserver2"/>

<NODE NAME="indexserver3"/>

<NODE NAME="indexserver4"/>

</NODE_LIST>

</HOME>

<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/11.2.0.2/database" TYPE="O" IDX="2">

<NODE_LIST>

<NODE NAME="indexserver1"/>

<NODE NAME="indexserver2"/>

<NODE NAME="indexserver3"/>

<NODE NAME="indexserver4"/>

</NODE_LIST>

</HOME>

</HOME_LIST>

</INVENTORY>

而以下是不能识别集群环境的节点的内容:

<?xml version="1.0" standalone="yes" ?>

<!-- Copyright (c) 1999, 2010, Oracle.All rights reserved.-->

<!-- Do not modify the contents of this file by hand.-->

<INVENTORY>

<VERSION_INFO>

<SAVED_WITH>11.2.0.2.0</SAVED_WITH>

<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>

</VERSION_INFO>

<HOME_LIST>

<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/11.2.0.2/database/griddatabase" TYPE="O" IDX="2">

<NODE_LIST>

<NODE NAME="indexserver1"/>

<NODE NAME="indexserver2"/>

<NODE NAME="indexserver3"/>

<NODE NAME="indexserver4"/>

</NODE_LIST>

</HOME>

<HOME NAME="Ora11g_gridinfrahome1" LOC="/u01/app/11.2.0.2/grid" TYPE="O" IDX="1" CRS="true">

<NODE_LIST>

<NODE NAME="indexserver1"/>

<NODE NAME="indexserver2"/>

<NODE NAME="indexserver3"/>

<NODE NAME="indexserver4"/>

</NODE_LIST>

</HOME>

</HOME_LIST>

</INVENTORY>

看出问题了吗?在出现问题的节点上,GRID_HOME,即IDX=1的项目被放在最后了。把顺序调整过来就可以了。

2.3 为什么不配时间服务了

集群环境中对节点时间一致的要求非常严格。Oracle 是用 SCN 来记录数据库的事务操作的,SCN基本上就是时间戳。想象一下,如果两个节点时间有差别,很有可能出现明明节点1上的事务先执行,节点2的事务后执行,而从SCN上反映出来的却是相反的。这会造成数据严重不一致。

因此,在集群环境中,如果出现节点时间上的不一致,就会导致集群的重构,也就是某个节点会被重启。这是由集群判断节点挂起的方式决定的,一个大幅度的时间跳跃会让集群错误的认为发生了严重的节点挂起,从而触发节点隔离(fencing)。使用类似NTP这种时间同步方法,又没有进行精细的配置的话,是很容易造成这种大幅度的时间跳跃的。Oracle 10.2中有几个有名的bug就是因为时间同步而造成节点重启的。

所以,在11.2 RAC 中,时间服务仍然是需要的,也是必需的。但是我们上一章在做前期准备时,并没有做任何时间服务的配置。这是为何呢?因为Oracle 11.2引入了CTSS服务,这个服务会替我们考虑这些问题。

在Oracle 11.2中,Oracle为了简化RAC的部署,做了大量的优化,其中就包括对时间服务的简化。在 Oracle 11.2 中,我们有两个时间同步机制可以选择,可以使用操作系统提供的NTP服务,也可以使用Grid自带的时间同步服务(CTSS,Cluster Time Synchronization Server Daemon)。

2.3.1 使用 NTP 服务

如果要使用操作系统自带的NTP服务,需要修改NTP参数文件,在其中设置-x标志,这样可避免向前调整时间。完成配置的修改后,重启NTP服务即可。

编辑/etc/sysconfig/ntpd文件:

# Drop root to id 'ntp:ntp' by default.

OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

# Set to 'yes' to sync hw clock after successful ntpdate

SYNC_HWCLOCK=no

# Additional options for ntpdate

NTPDATE_OPTIONS=""

重启NTP服务:

[root@indexserver3 grid_data]# service ntpd status

ntpd (pid 4250) is running...

[root@indexserver3 grid_data]# service ntpd stop

Shutting down ntpd: [ OK ]

[root@indexserver3 grid_data]# service ntpd start

ntpd: Synchronizing with time server: [ OK ]

Starting ntpd: [ OK ]

[root@indexserver3 grid_data]# ps -ef|grep ntpd

Ntp  22244  1 0 17:25 ?  00:00:00 ntpd -x -u ntp:ntp -p /var/run/ntpd.pid

Root 22250 15074 0 17:25 pts/0 00:00:00 grep ntpd

2.3.2 使用 CTSS 服务

如果想使用Grid提供的集群时间同步服务,就需要卸载操作系统提供的NTP服务,或者干脆禁用它,后者需要进行如下操作:

要禁用NTP服务,必须停止当前的NTPD服务;

从初始化序列中禁用该服务;

删除ntp.conf文件。

[root@searchdb1 ~]# service ntpd status

ntpd (pid 7447) is running...

[root@searchdb1 ~]# service ntpd stop

Shutting down ntpd: [ OK ]

[root@searchdb1 ~]# chkconfig ntpd

[root@searchdb1 ~]# chkconfig ntpd off

[root@searchdb1 ~]# mv /etc/ntp.conf /etc/ntp.conf.bak

2.3.3 CTSS 和 NTP 的关系

如果CTSS发现集群中所有节点上已经配置或者运行了NTP服务,则CTSS会以一种观察员模式(Observer Mode)运行,这种模式下 CTSS 只会在集群的alert 日志中记录时间不一致的信息,但不会去调整。

如果CTSS发现集群中并不是所有节点都配置或者运行了NTP服务,CTSS就会以一种主动模式(Active Mode)运行,和主节点同步系统时钟。这种同步又分两种方式。

当一个节点加入到集群时,如果这个节点存在时间差异,但是这个差异在某个界限之内,就会用一种步进的方式进行同步,也就是每次调整很小的一个幅度。如果时间差异超过了这个限,就不允许这个节点加入到集群,并在集群的alert日志中记录一个消息。

在运行过程中,如果节点和主节点时间发生了差异,会把系统时钟加快或者减慢已达到重新的同步。这也叫做clock slewing。

说明:CTSS永远不会把系统时钟向前调整。Oracle 10.2 RAC 中就有因为始终向前调整引起节点重启的bug。

要想把 CTSS 从观察者模式转变成主动模式,只需要去掉所有节点上的 NTP 服务即可,CTSS会发现这个变化,并改变模式。反过来也是一样,也就是如果启动所有节点上的NTP服务,会导致CTSS转换成观察者模式。

可以使用以下方式来查看CTSS是运行在什么模式下的:

[grid@indexserver4 ~]$ crsctl check ctss

CRS-4700: The Cluster Time Synchronization Service is in Observer mode.

这说明CTSS是以观察者模式运行的。

2.4 IPMI是什么

IPMI即Integrating Intelligent Platform Management Interface,如何理解呢?

我们在《大话Oracle RAC》中谈到过IO Fencing,或者踢出节点(evict node),也就是当集群中的某个节点失去了响应──没有了磁盘心跳、对ping也没有响应,可能这个节点已经关闭了,也可能负载太高、运行缓慢,也有可能完全挂起了(hung)。这时,集群需要进行重构,也就是要把这个节点踢出集群环境,由剩下的节点重新组建新的集群。这样做是为了解决脑裂风暴。

而踢出一个节点其实就是要让这个节点重启,重启有两种做法,一种是suicide,另一种是STONITH(Shoot The Other Node In The Head)。

Oracle 11.2之前采用的是第一种方法,不过,发现一个节点该重启和这个节点确实能够重启是两回事。这个节点如果已经完全挂起了,它其实是没有办法自己解决这个问题的,这就是IPMI发挥作用的地方了。而IPMI采用的就是后一种办法。

IPMI是一个工业标准。如果集群要使用IPMI,那么这个集群中的每个节点都要有一个BMC (Baseboard Management Controller),这个卡的Firmware要支持IPMI的1.5版,这个版本支持局域网内的 IPMI。换句话说,如果其他健康节点发现这个节点因为某种原因没反应了,必然会通过局域网通知这个BMC卡重启这个节点,最简单的方式就是暂时断电再通电。不过,通过 IPMI 来重启节点,是各种努力都尝试过后的最后一击,当然目的也是为了保护数据的一致性。如果机器配有BMC设备的话,可以配置IPMI。

2.5 ORACLE_BASE和ORACLE_HOME的区别

ORACLE_HOME我们都非常熟悉,ORACLE_BASE是Oracle 11.2部署时一个需要的变量。要理解这两个目录的关系,就需要理解Oracle的Optimal Flexible Architecture(OFA)标准。这是一个保证一致的目录结构和文件命名的标准。我之前并不遵循 OFA 标准,而是采用自己的一套。不过从Oracle 11.2以来,我开始有意识地理解OFA,发现真的不错,所以推荐给读者。

2.5.1 OFA 和软件安装

许多环境和资料都采用了OFA标准,理解这个标准很重要。图2-5就是标准OFA的目录结构和文件名字规范。当然这张图中并没有显示所有的目录和文件,不过关键的常用目录和文件还是显示出来了。

图2-5 OFA标准目录结构

OFA中有几个关键目录需要知道,包括:

Oracle inventory目录;

Oracle Base目录(ORACLE_BASE);

Oracle Home 目录(ORACLE_HOME);

Oracle Network目录(TNS_ADMIN);

Automatic Diagnostic Repository(ADR_HOME)。

1.Oracle Inventory目录

注意这个目录和下一个Oracle Base目录的关系。

当我初次接触到 ORACLE_BASE 这个概念时,有了一个想当然的判断。以为这是一个树根,而所有Oracle有关的东西,都是放在这个树根下的。如果你的想法和我一样,那就要注意了,这个目录不属于ORACLE_BASE。它是和ORACLE_BASE同级的一个目录。

这个目录用来保存本机上所安装的 Oracle 软件的目录清单,本机上安装的所有 Oracle 软件都需要并且共享使用这个目录,当我们第一次安装Oracle软件时,Oracle使用下面的几条规则来寻找这个目录。

(1)是否有OFA-兼容的目录结构,所谓OFA兼容就是指这个目录符合/u[01-09]/app这样的命名规范。如果有,安装程序就会在这个目录下创建,比如/u01/app/oraInventory。

(2)如果oracle用户的环境变量中定义了ORACLE_BASE变量,则安装程序会在下面这个位置创建这个目录:ORACLE_BASE/../oraInventory ,中间的两个原点“..”代表的是ORACLE_BASE的上层目录,也就是说,oraInventory目录是和ORACLE_BASE目录在同一个层次。比如,如果ORACLE_BASE定义为/ora/app/oracle,则这个目录就是/ora/app/oraInventory。

(3)如果安装程序没有找到OFA兼容的目录结构,也没有发现ORACLE_BASE变量,则安装器会在Oracle用户的HOME目录下创建这个目录,也就是/home/oracle/oraInventory目录。

2.Oracle Base目录

Oracle Base目录是Oracle软件安装的最顶层目录。这个目录下可以安装多个版本的Oracle软件,OFA标准里的Oracle Base目录是这样的:

/<mount_point>/app/<software_owner>

挂载点通常是像/u01、/ora01、/oracle这样的名字。用户可以根据自己的环境标准命名这个挂载点。

软件拥有者通常都是oracle,这是你用来安装Oracle软件的操作系统用户。因为,一个完整的Oracle Base目录可能是这样的:

/ora01/app/oracle

3.Oracle Home目录

Oracle Home 目录定义了每个特定软件,比如Oracle Database 11g、Oracle Database 10g的安装目录。每个不同的产品或者同一产品的不同版本必须放在单独目录下。符合 OFA 标准的Oracle Home 目录是这样的:

ORACLE_BASE/product/<version>/<install_name>

在我们的环境中,版本可能是11.2.0.1、11.2.0.2、10.2.0.1,install_name可以是db_1、devdb。比如下面就是一个版本为11.2.0.1的数据库:

/ora01/app/oracle/product/11.2.0.1/db_1

许多DBA,包括我自己都不喜欢ORACLE_HOME下的目录db_1,也看不出它有什么用处。其实 db_1 这种结构是让我们可以有多个单独的二进制:一个开发环境、一个测试环境、一个生产环境,如果确定没有必要使用这么多安装,也可以去掉这个目录。

4.GRID的Oracle Base和Oracle Home

不过Grid的ORACLE_BASE和ORACLE_HOME有所不同,Grid的ORACLE_HOME不能是ORACLE_BASE的子目录,如果这么定义:

ORACLE_BASE=/u01/app/grid

ORACLE_HOME=/u01/app/grid/11.2.0.2

安装会报错,如图2-6和图2-7所示。

图2-6 指定安装位置

图2-7 安装报错

Oracle的官方文档是这样解释的http://docs.oracle.com/cd/E11882_01/install.112/e17212/concepts.htm:Even if you do not use the same software owner to install Grid Infrastructure (Oracle Clusterware and Oracle ASM) and Oracle Database, be aware that running the root.sh script during the Oracle Grid Infrastructure installation changes ownership of the home directory where clusterware binaries are placed toroot, and all ancestor directories to the root level (/) are also changed to root.For this reason, the Oracle Grid Infrastructure for a cluster home cannot be in the same location as other Oracle software.

也就是说,在Grid安装过程的root.sh会把Grid所在目录的属主改成root,而且会一直修改到顶层目录,这样一来就会影响到其他的Oracle软件,所以,不能把Grid的ORACLE_HOME放到ORACLE_BASE的子目录中。

所以,对于Grid用户来说,这两个目录应该是平行的。

5.Oracle Network 目录

一些Oracle工具使用TNS_ADMIN定位网络配置文件,这个目录位于ORACLE_HOME/network/admin,这个目录中会包括sqlnet.ora、tnsnames.ora和listener.ora文件。

6.ADR目录

ADR 目录(Automatic Diagnostic Repository)是从 Oracle 11g 开始出现的,这个目录里的文件对于解决Oracle数据库问题很关键,这个目录定义是ORACLE_BASE/diag/rdbms/<dbname>/<instancename>,其中 dbname 是数据库的名字,instancename 是实例的名字。在单实例数据库环境中,数据库名字和实例名字是相同的,不过数据库名字是小写的,实例名字是大写的。比如,下面这个testdb:

/ora01/app/oracle/diag/rdbms/testdb/TESTDB

7.ORACLE_BASE、ORACLE_HOME环境变量

现在我们已经理解了 OFA 标准了,因此,在安装之前,需要在安装用户的环境中指定ORACLE_BASE、ORACLE_HOME 两个环境变量。Grid、Oracle 两个用户各自的设置是不同的。

Grid用户的环境变量设置:

export ORACLE_BASE=/u01/app/grid

export ORACLE_HOME=/u01/app/11.2.0/grid

PATH=$ORACLE_HOME/bin:$PATH:$HOME/bin

Oracle用户的环境变量设置:

export ORACLE_BASE=/u01/app/database

export ORACLE_HOME=$ORACLE_BASE/11.2.0.2

PATH=$ORACLE_HOME/bin:$PATH:$HOME/bin

2.5.2 ORACLE_HOME 是共享还是本地

在 RAC 集群中,每个节点上的 Oracle 软件都要访问 RAC 数据库。这就会引发一个问题——Oracle 软件本身是放在一个共享存储上(共享 ORACLE_HOME)或者放在每个节点的本地(本地ORACLE_HOME)。

使用共享ORACLE_HOME当然有些好处,比如配置、空间需求、升级。不过,每次升级都必须要有完全的停机才行。而且,因为只有一份 ORACLE_HOME,这很明显是一个单点故障,这个共享空间的任何问题都会导致数据库的挂掉。

因此,对于ORACLE_HOME的建议还是使用本地ORACLE_HOME。千万不要舍不得那一点点空间浪费,也不要害怕准备环境的麻烦。

2.6 SCAN

在安装Grid的过程中,需要填写一个叫做SCAN的项目(如图1-9所示),SCAN即Single Client Access Name的缩写。关于SCAN,我会专门用单独的一章来讨论,本节只是先简单介绍一下。

来看一下Oracle 10.2 RAC的客户端是如何访问数据库的,这些客户端的TNSNAMES.ORA应该是这样的:

Testdb =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = center-rac1-vip)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = center-rac2-vip)(PORT = 1521))

(LOAD_BALANCE = yes)

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME =testdb)

)

)

客户端的这个文件中会记录RAC环境中每个节点的VIP地址,也就是说客户端必须要知道整个集群环境的拓扑结构。一旦集群的拓扑发生了改变,比如加入新的节点或者去掉某个节点,所有客户端的TNSNAMES.ORA文件必须做修改,否则就可能无法继续访问数据库了。

也就是说,Oracle RAC环境不能做到对用户完全透明,这是一个问题。SCAN就是用来解决这个问题的。

SCAN本身是一个QFDN的域名,就像熟悉的网站一样,我们访问谷歌是通过www.google.com访问的,谷歌其实有上百上千台服务器提供WWW服务,我们根本不知道连的是哪一台,也不需要关心,反正只要能打开网页,后面的服务器怎么变化都跟我们无关。也就是说谷歌的服务器对于客户是透明的。

SCAN的效果也是一样的,使用SCAN后,客户端的TNSNAMES.ORA是这样的:

Testdb =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = indexgrid.wxxr.com.cn)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = testdb)——

)

)

现在,客户端所需要知道的就是一个SCAN──indexgrid.wxxr.com.cn,可以叫它域名,你不需要知道任何RAC环境内部的信息,RAC内部再有什么变化,客户端不需要知道。RAC对客户完全透明了。

要实现这个目的,其实后面有一系列的技术支持,包括 DNS、GNS、SCAN VIP、SCANListener、Listener,这些内容都会在后面的章节中展开。

2.7 HAIP(替代双网卡绑定)

众所皆知,RAC环境中有个私有网络,这个网络上跑的是心跳信息和Cache Fusion数据,私有网络对于 RAC 的稳定性、性能有着重要的意义。因此,我们会建议采用多块网卡绑定的方式来搭建这个网络。在不同的操作系统中,网卡绑定的名称也不一样,有的叫 bonding,有的叫 teaming 或 trunking。不管叫什么,其目的都是一样的,都是通过冗余提供分散负载、故障切换的能力。

Oracle Grid从版本11.2.0.2开始内置了一个私有网卡的HA技术,就是HAIP。它和我们熟悉的多网卡绑定有所差异,采用的是一个multiport-listening-endpoint的架构,每个私有网卡都会被分配一个HAIP地址,这个IP地址不需要提前定义,它是自动生成的。最多支持4个私有网卡。

在默认情况下,Oracle RAC会使用所有这些HAIP作为私有网络的通信协议,提供负载均衡。如果一个私有网卡挂了,Oracle会自动地把其HAIP切换到其他的网卡上去。

在 RAC 中,Oracle ASM(ASM 集群)以及其他的集群组件,比如 CSS、CRS、CTSS、EVM等都可以利用HAIP。

当有多个私有网卡时,安装过程如图2-8所示。

图2-8 有多块网卡时的配置界面

说明:HAIP 是Oracle Grid 11.2.0.2之后才有的,11.2.0.1是看不到的。

可以用操作系统的ip命令来查看这个HAIP。

节点1:

[grid@indexserver1 ~]$ /sbin/ip ad sh

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:43:c5:0d brd ff:ff:ff:ff:ff:ff

inet 192.168.1.70/24 brd 192.168.1.255 scope global eth0

inet 192.168.1.80/24 brd 192.168.1.255 scope global secondary eth0:1

inet 192.168.1.86/24 brd 192.168.1.255 scope global secondary eth0:2

inet6 fe80::7a2b:cbff:fe43:c50d/64 scope link

valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:43:c5:0f brd ff:ff:ff:ff:ff:ff

inet 10.0.0.70/8 brd 10.255.255.255 scope global eth1

inet 169.254.177.128/16 brd 169.254.255.255 scope global eth1:1

inet6 fe80::7a2b:cbff:fe43:c50f/64 scope link

valid_lft forever preferred_lft forever

节点2:

[root@indexserver2 11.2.0.2]# ip ad sh

……

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:43:5c:0c brd ff:ff:ff:ff:ff:ff

inet 10.0.0.71/8 brd 10.255.255.255 scope global eth1

inet 169.254.127.239/16 brd 169.254.255.255 scope global eth1:1

inet6 fe80::7a2b:cbff:fe43:5c0c/64 scope link

valid_lft forever preferred_lft forever

……

节点3:

[root@indexserver3 11.2.0.2]# ip ad sh

……

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:43:76:26 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.72/8 brd 10.255.255.255 scope global eth1

inet 169.254.59.18/16 brd 169.254.255.255 scope global eth1:1

inet6 fe80::7a2b:cbff:fe43:7626/64 scope link

valid_lft forever preferred_lft forever

……

节点4:

[root@indexserver4 11.2.0.2]# ip ad sh

……

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:42:79:37 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.73/8 brd 10.255.255.255 scope global eth1

inet 169.254.162.84/16 brd 169.254.255.255 scope global eth1:1

inet6 fe80::7a2b:cbff:fe42:7937/64 scope link

valid_lft forever preferred_lft forever

……

在这个 4 节点的 RAC 中,网卡 eth1 用作私有网卡,这块网卡上除了我们定义的私有 IP10.0.0.*之外,还有一个169.*.*.*的地址,这就是HAIP。

以上是只有一块网卡做私有网卡的情况,下面是在Oracle 11.2.0.3中,有多块网卡做私有网卡的情况。

第一个节点:

[root@promotiondbp ~]# ip ad sh

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:a3:46 brd ff:ff:ff:ff:ff:ff

inet 192.168.1.33/24 brd 192.168.1.255 scope global eth0

inet 192.168.1.40/24 brd 192.168.1.255 scope global secondary eth0:1

inet 192.168.1.39/24 brd 192.168.1.255 scope global secondary eth0:3

inet 192.168.1.37/24 brd 192.168.1.255 scope global secondary eth0:4

inet6 fe80::7a2b:cbff:fe44:a346/64 scope link

valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:a3:48 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.10/8 brd 10.255.255.255 scope global eth1

inet 169.254.8.96/18 brd 169.254.63.255 scope global eth1:1

inet 169.254.242.150/18 brd 169.254.255.255 scope global eth1:2

inet6 fe80::7a2b:cbff:fe44:a348/64 scope link

valid_lft forever preferred_lft forever

4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:a3:4a brd ff:ff:ff:ff:ff:ff

inet 10.0.0.1/8 brd 10.255.255.255 scope global eth2

inet 169.254.111.15/18 brd 169.254.127.255 scope global eth2:1

inet6 fe80::7a2b:cbff:fe44:a34a/64 scope link

valid_lft forever preferred_lft forever

5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:a3:4c brd ff:ff:ff:ff:ff:ff

inet 10.0.0.2/8 brd 10.255.255.255 scope global eth3

inet 169.254.167.173/18 brd 169.254.191.255 scope global eth3:1

inet6 fe80::7a2b:cbff:fe44:a34c/64 scope link

valid_lft forever preferred_lft forever

6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:10:18:9f:6f:c8 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.3/8 brd 10.255.255.255 scope global eth4

7: eth5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:10:18:9f:6f:ca brd ff:ff:ff:ff:ff:ff

inet 10.0.0.4/8 brd 10.255.255.255 scope global eth5

8: sit0: <NOARP> mtu 1480 qdisc noop

link/sit 0.0.0.0 brd 0.0.0.0

第二个节点:

[root@promotiondbs grid]# ip ad sh

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:8d:72 brd ff:ff:ff:ff:ff:ff

inet 192.168.1.34/24 brd 192.168.1.255 scope global eth0

inet 192.168.1.38/24 brd 192.168.1.255 scope global secondary eth0:1

inet 192.168.1.41/24 brd 192.168.1.255 scope global secondary eth0:2

inet6 fe80::7a2b:cbff:fe44:8d72/64 scope link

valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:8d:74 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.5/8 brd 10.255.255.255 scope global eth1

inet 169.254.43.98/18 brd 169.254.63.255 scope global eth1:1

inet 169.254.207.131/18 brd 169.254.255.255 scope global eth1:2

inet6 fe80::7a2b:cbff:fe44:8d74/64 scope link

valid_lft forever preferred_lft forever

4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:8d:76 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.6/8 brd 10.255.255.255 scope global eth2

inet 169.254.126.213/18 brd 169.254.127.255 scope global eth2:1

inet6 fe80::7a2b:cbff:fe44:8d76/64 scope link

valid_lft forever preferred_lft forever

5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 78:2b:cb:44:8d:78 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.7/8 brd 10.255.255.255 scope global eth3

inet 169.254.155.59/18 brd 169.254.191.255 scope global eth3:1

inet6 fe80::7a2b:cbff:fe44:8d78/64 scope link

valid_lft forever preferred_lft forever

6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:10:18:9f:70:48 brd ff:ff:ff:ff:ff:ff

inet 10.0.0.8/8 brd 10.255.255.255 scope global eth4

7: eth5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000

link/ether 00:10:18:9f:70:4a brd ff:ff:ff:ff:ff:ff

inet 10.0.0.9/8 brd 10.255.255.255 scope global eth5

8: sit0: <NOARP> mtu 1480 qdisc noop

link/sit 0.0.0.0 brd 0.0.0.0

[root@promotiondbs grid]#

2.7.1 用 oficfg 无法得到 HAIP 的信息

注意,oficfg 命令虽然可以查看集群环境中各个网卡的用途,但是看不到 HAIP 的信息。比如:

[grid@indexserver1 ~]$ oifcfg getif

eth0 192.168.1.0 global public

eth1 10.0.0.0 global cluster_interconnect

[grid@indexserver1 ~]$ oifcfg iflist -p -n

eth0 192.168.1.0 PRIVATE 255.255.255.0

eth1 10.0.0.0 PRIVATE 255.0.0.0

eth1 169.254.0.0 UNKNOWN 255.255.0.0

2.7.2 确认 ASM 使用了 HAIP

要确认 ASM 使用了 HAIP ,可以从 ASM 的启动日志中看到,以 grid 用户进入$ORACLE_BASE下的目录:

[grid@indexserver1 trace]$ cd /u01/app/grid/diag/asm/+asm/+ASM4/trace

[grid@indexserver1 trace]$ more alert_+ASM4.log

Thu Jul 05 13:07:52 2012

* instance_number obtained from CSS = 4, checking for the existence of node 0...

* node 0 does not exist.instance_number = 4

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Private Interface 'eth1:1' configured from GPnP for use as a private interconnect.

[name='eth1:1', type=1, ip=169.254.177.128, mac=78-2b-cb-43-c5-0f, net=169.254.0.0/16, mask=255.255.0.0, use=haip:cluster_intercon

nect/62]

Public Interface 'eth0' configured from GPnP for use as a public interface.

[name='eth0', type=1, ip=192.168.1.70, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]

Shared memory segment for instance monitoring created

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as /u01/app/11.2.0.2/grid/dbs/arch

Autotune of undo retention is turned on.

LICENSE_MAX_USERS = 0

SYS auditing is disabled

NOTE: Volume support enabled

Starting up:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options.

Usingparametersettingsinserver-sidespfile+DATA/indexgrid/asmparameterfile/registry.253.787835657

System parameters with non-default values:

large_pool_size   = 12M

instance_type   = "asm"

remote_login_passwordfile = "EXCLUSIVE"

asm_diskstring   = "ORCL:*"

asm_power_limit   = 1

diagnostic_dest   = "/u01/app/grid"

Cluster communication is configured to use the following interface(s) for this instance

169.254.177.128

cluster interconnect IPC version:Oracle UDP/IP (generic)

……

也可以通过视图确认:

[grid@indexserver1 trace]$ export ORACLE_SID=+ASM4

[grid@indexserver1 trace]$ sqlplus " / as sysdba"

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jul 5 18:22:30 2012

Copyright (c) 1982, 2010, Oracle.All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SQL> select name,ip_address from v$cluster_interconnects;

NAME   IP_ADDRESS

--------------- ----------------

eth1:1   169.254.177.128

2.7.3 确认 RDBMS 数据库使用 HAIP

同样从数据库的启动日志或者视图中,也可以找到使用HAIP的证据。

来看一下数据库的启动日志:

[oracle@indexserver1 ~]$ cd $ORACLE_BASE/diag /rdbms/wxxrdb/wxxrdb3/trace/

[oracle@indexserver1 trace]$ more alert_wxxrdb3.log

Thu Jul 05 16:50:30 2012

Adjusting the default value of parameter parallel_max_servers

from 640 to 135 due to the value of parameter processes (150)

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Private Interface 'eth1:1' configured from GPnP for use as a private interconnect.

[name='eth1:1', type=1, ip=169.254.177.128, mac=78-2b-cb-43-c5-0f, net=169.254.0.0/16,mask=255.255.0.0, use=haip:cluster_intercon

nect/62]

Public Interface 'eth0' configured from GPnP for use as a public interface.

[name='eth0', type=1, ip=192.168.1.70, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]

Public Interface 'eth0:1' configured from GPnP for use as a public interface.

[name='eth0:1', type=1, ip=192.168.1.80, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]

Public Interface 'eth0:2' configured from GPnP for use as a public interface.

[name='eth0:2', type=1, ip=192.168.1.86, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]

Shared memory segment for instance monitoring created

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as /u01/app/oracle/11.2.0.2/database/dbs/arch

Autotune of undo retention is turned on.

IMODE=BR

ILAT =28

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Oracle Label Security and Real Application Testing options.

Using parameter settings in client-side pfile /u01/app/oracle/cfgtoollogs/dbca/wxxrdb/ initwxxrdbTempOMF.ora on machine indexserver1

System parameters with non-default values:

Processes= 150

memory_target= 4800M

control_files= "/u01/app/oracle/cfgtoollogs/dbca/wxxrdb/tempControl.ctl"

db_block_size= 8192

compatible= "11.2.0.0.0"

db_create_file_dest= "+DATA"

undo_tablespace= "UNDOTBS1"

instance_number= 3

remote_login_passwordfile = "EXCLUSIVE"

db_domain= ""

dispatchers= "(PROTOCOL=TCP) (SERVICE=wxxrdbXDB)"

remote_listener= "indexgrid.wxxr.com.cn:1521"

audit_file_dest= "/u01/app/oracle/admin/wxxrdb/adump"

audit_trail= "DB"

db_name= "seeddata"

db_unique_name= "wxxrdb"

open_cursors= 300

diagnostic_dest= "/u01/app/oracle"

Cluster communication is configured to use the following interface(s) for this instance

169.254.177.128

cluster interconnect IPC version:Oracle UDP/IP (generic)

IPC Vendor 1 proto 2

通过视图:

SQL> select name,ip_address from v$cluster_interconnects;

NAME   IP_ADDRESS

--------------- ----------------

eth1:1  169.254.177.128

2.8 减少机器重启——IO Fencing功能的增强

我们都知道Oracle会通过重启故障节点的方式实现IO Fencing,解决脑裂风暴。不过,每次重启故障节点都会伴随着集群的重构动作,集群重构时会对数据库进行冻结(Freezing),冻结期间数据库是无法接受连接、也无法完成外部请求的,客户端会表现得挂住了。因此,不管是哪种规模的 RAC 环境,都应该尽量减少机器的重启。或者说,应该采用更加优雅的解决方式。

但是,如何区分一个机器确实是因为故障而失去响应,还是因为负载太重暂时无法响应确实比较困难。Oracle具体是什么样的算法我无从得知,但是Oracle 11.2 RAC中对于踢出节点的处理比之前温柔了。

如果某个节点挂起了,对心跳没有了响应,那么Oracle会先尝试着杀掉那些参与IO操作的进程(也就是可能会造成数据破坏的进程),比如DBWR、LGWR,如果Oracle不能干掉这些进程,那么Grid就会重启整个机器。

如果Oracle成功地干掉了这些新进程,那么Oracle就会关闭Grid自己,然后再重启Grid,而这个重启是由ohasd控制的,或者说由Grid的控制文件/etc/oracle/scls_scr/<hostname>/root/ohasdrun控制的。

总之,Oracle 11.2 Grid对于节点的重启不再像以前那么粗暴和绝对了,一定程度上减少了机器重启的数量。

到目前为止,安装过程中所涉及的新概念基本都涵盖了,接下来我们就要开始深入到Grid的内部了。不过,我个人建议,为了加深对这一章内容的把握,你最好把之前装的Oracle Grid全部删掉,靠自己的掌握重新装一遍,这样印象会很深刻。

那我们就看看该如何干净地删除一个Grid。

2.9 Grid的卸载

Oracle 并没有提供一个图形化的卸载工具,或许以后的版本会有。要想干净地卸载,我们也不能简单地把Oracle目录删除了事。在Grid安装目录下有一个deinstall目录,这里的deinstall脚本用于卸载Grid。当我们要对整个集群环境进行重构或者删除掉RAC时,我们会用到它。

删除 Grid 的操作步骤很简单直观,我们下面删除一个 4 节点组成的集群,每个节点都有自己的Grid HOME和Oracle Database HOME。正确的卸载顺序应该是这样的。

2.9.1 关闭数据库和资源

首先,关闭集群各个节点上的所有数据库以及其他资源。这一步需要以root身份在每一个节点上进行:

[root@indexserver1 ~]# crsctl stop crs

CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on'indexserver2'

CRS-2673: Attempting to stop 'ora.crsd' on 'indexserver2'

CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'indexserver2'

CRS-2673: Attempting to stop 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.cvu' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.indexserver3.vip' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.LISTENER_SCAN2.lsnr' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.registry.acfs' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.DATA.dg' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'indexserver2'

CRS-2677: Stop of 'ora.indexserver3.vip' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.indexserver2.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.indexserver2.vip' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.indexserver4.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.indexserver4.vip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.cvu' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.scan3.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.LISTENER_SCAN1.lsnr' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.scan1.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.LISTENER_SCAN2.lsnr' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.scan2.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.scan3.vip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.indexserver1.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.scan1.vip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.scan2.vip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.indexserver1.vip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.registry.acfs' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.DATA.dg' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'

CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.ons' on 'indexserver2'

CRS-2677: Stop of 'ora.ons' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.net1.network' on 'indexserver2'

CRS-2677: Stop of 'ora.net1.network' on 'indexserver2' succeeded

CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'indexserver2' has completed

CRS-2677: Stop of 'ora.crsd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.crf' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.ctssd' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.evmd' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.mdnsd' on 'indexserver2'

CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'indexserver2'

CRS-2677: Stop of 'ora.crf' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.mdnsd' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.evmd' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.drivers.acfs' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.ctssd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.cssd' on 'indexserver2'

CRS-2677: Stop of 'ora.cssd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.gipcd' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.diskmon' on 'indexserver2'

CRS-2677: Stop of 'ora.gipcd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.gpnpd' on 'indexserver2'

CRS-2677: Stop of 'ora.diskmon' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.gpnpd' on 'indexserver2' succeeded

CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'indexserver2' has completed

CRS-4133: Oracle High Availability Services has been stopped.

在每个节点上都要执行这个脚本,然后开始执行deinstall。

2.9.2 用 deinstall 卸载

接下来,在安装Grid的第一个节点上,以grid身份运行这个deinstall脚本,这个脚本会运行一系列的检查,同时会提出一系列问题请你确认,最后才会真正地开始卸载工作。

[grid@indexserver1 ~]$ cd /u01/app/11.2.0/grid/deinstall/

[grid@indexserver1 deinstall]$ ./deinstall

Checking for required files and bootstrapping ...

Please wait ...

Location of logs /u01/app/oraInventory/logs/

############ ORACLE DEINSTALL & DECONFIG TOOL START ############

######################### CHECK OPERATION START #########################

Install check configuration START

Checking for existence of the Oracle home location /u01/app/11.2.0.2/grid

Oracle Home type selected for de-install is: CRS

Oracle Base selected for de-install is: /u01/app/grid

Checking for existence of central inventory location /u01/app/oraInventory

Checking for existence of the Oracle Grid Infrastructure home /u01/app/11.2.0.2/grid

The following nodes are part of this cluster: indexserver1,indexserver2,indexserver3,indexserver4

Install check configuration END

Skipping Windows and .NET products configuration check

Checking Windows and .NET products configuration END

Traces log file: /u01/app/oraInventory/logs//crsdc.log

Enter an address or the name of the virtual IP used on node "indexserver1"[null]

>

indexserver1-vip

The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver1"

继续输入其他节点的VIP名字。

Enter the IP netmask of Virtual IP "192.168.123.210" on node "indexserver1"[255.255.255.0]

>

Enter the network interface name on which the virtual IP address "192.168.123.210" is active

>

eth0

Enter an address or the name of the virtual IP used on node "indexserver2"[192.168.123.210]

>

indexserver2-vip

The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver2"

Enter the IP netmask of Virtual IP "192.168.123.211" on node "indexserver2"[255.255.255.0]

>

Enter the network interface name on which the virtual IP address "192.168.123.211" is active[eth0]

>

Enter an address or the name of the virtual IP used on node "indexserver3"[192.168.123.211]

>

indexserver3-vip

The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver3"

Enter the IP netmask of Virtual IP "192.168.123.212" on node "indexserver3"[255.255.255.0]

>

Enter the network interface name on which the virtual IP address "192.168.123.212" is active[eth0]

>

Enter an address or the name of the virtual IP used on node "indexserver4"[192.168.123.212]

>

indexserver4-vip

The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver4"

Enter the IP netmask of Virtual IP "192.168.123.213" on node "indexserver4"[255.255.255.0]

>

Enter the network interface name on which the virtual IP address "192.168.123.213" is active[eth0]

>

Enter an address or the name of the virtual IP[]

>

Network Configuration check config START

Network de-configuration trace file location: /u01/app/oraInventory/logs/netdc_check2012-06-20_05-50-01-PM.log

Specify all RAC listeners (do not include SCAN listener) that are to be de-configured[LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1]:

Network Configuration check config END

Asm Check Configuration START

ASM de-configuration trace file location: /u01/app/oraInventory/logs/asmcadc_check2012-06-20_05-50-05-PM.log

ASM configuration was not detected in this Oracle home.Was ASM configured in this Oracle home (y|n) [n]: y

Specify the ASM Diagnostic Destination [ ]:

Specify the diskstring []: ORCL:*

Specify the diskgroups that are managed by this ASM instance []: DATA

De-configuring ASM will drop the diskgroups at cleanup time.Do you want deconfig tool to drop the diskgroups y|n [y]:

######################### CHECK OPERATION END #########################

####################### CHECK OPERATION SUMMARY #######################

Oracle Grid Infrastructure Home is: /u01/app/11.2.0.2/grid

The cluster node(s) on which the Oracle home de-installation will be performed are:indexserver1,indexserver2,indexserver3,indexserver4

Oracle Home selected for de-install is: /u01/app/11.2.0.2/grid

Inventory Location where the Oracle home registered is: /u01/app/oraInventory

Skipping Windows and .NET products configuration check

Following RAC listener(s) will be de-configured: LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1

ASM instance will be de-configured from this Oracle home

Do you want to continue (y - yes, n - no)? [n]: y

A log of this session will be written to: '/u01/app/oraInventory/logs/deinstall_deconfig2012-06-20_05-48-53-PM.out'

Any error messages from this session will be written to: '/u01/app/oraInventory/logs/deinstall_deconfig2012-06-20_05-48-53-PM.err'

######################## CLEAN OPERATION START ########################

ASM de-configuration trace file location: /u01/app/oraInventory/logs/asmcadc_clean2012-06-20_05-50-53-PM.log

ASM Clean Configuration START

ASM Clean Configuration END

Network Configuration clean config START

Network de-configuration trace file location: /u01/app/oraInventory/logs/netdc_clean2012-06-20_05-50-55-PM.log

De-configuring RAC listener(s): LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1

De-configuring listener: LISTENER

Stopping listener: LISTENER

Listener stopped successfully.

Listener de-configured successfully.

De-configuring listener: LISTENER_SCAN3

Stopping listener: LISTENER_SCAN3

Listener stopped successfully.

Listener de-configured successfully.

De-configuring listener: LISTENER_SCAN2

Stopping listener: LISTENER_SCAN2

Listener stopped successfully.

Listener de-configured successfully.

De-configuring listener: LISTENER_SCAN1

Stopping listener: LISTENER_SCAN1

Listener stopped successfully.

Listener de-configured successfully.

De-configuring Naming Methods configuration file on all nodes...

Naming Methods configuration file de-configured successfully.

De-configuring Local Net Service Names configuration file on all nodes...

Local Net Service Names configuration file de-configured successfully.

De-configuring Directory Usage configuration file on all nodes...

Directory Usage configuration file de-configured successfully.

De-configuring backup files on all nodes...

Backup files de-configured successfully.

The network configuration has been cleaned up successfully.

Network Configuration clean config END

---------------------------------------->

The deconfig command below can be executed in parallel on all the remote nodes.Execute the command on the local node after the execution completes on all the remote nodes.

Run the following command as the root user or the administrator on node "indexserver3".

/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48-48 PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"

Run the following command as the root user or the administrator on node "indexserver2".

/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48- 48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_ 05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"

Run the following command as the root user or the administrator on node "indexserver4".

/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48- 48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_ 05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"

Run the following command as the root user or the administrator on node "indexserver1".

/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48- 48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_ 05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_ 05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp" -lastnode

Press Enter after you finish running the above commands

<----------------------------------------

这里给出的提示的意思是:在每个节点上运行这些脚本,然后再回到这个界面中按下回车键继续。这几个脚本都是一样的,只是在最后一个节点上多了一个-lastnode参数。

下面就在每个节点上以root身份执行这些脚本,这些脚本的输出比较长,这里就不列出了。在前3个节点上执行这个:

[root@indexserver3 ~]# /tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall 2012-06-20_05-48-48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/ deinstall2012-06-20_05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"

最后一个节点多了一个lastnode,其他都一样:

[root@indexserver1 ~]# /tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinsta ll2012-06-20_05-48-48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/ deinstall2012-06-20_05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/ deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp" –lastnode

4个节点上都执行完之后,再返回到之前执行deinstall的窗口,按下回车键,继续后续的卸载,这次就要开始删除目录了:

Removing Windows and .NET products configuration END

Oracle Universal Installer clean START

Detach Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the local node :Done

Delete directory '/u01/app/11.2.0.2/grid' on the local node : Done

Delete directory '/u01/app/grid' on the local node : Done

Detach Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the remote nodes 'indexserver2,indexserver3,indexserver4' : Done

Delete directory '/u01/app/11.2.0.2/grid' on the remote nodes 'indexserver2,indexserver3, indexserver4' : Done

Delete directory '/u01/app/grid' on the remote nodes 'indexserver2' : Done

Delete directory '/u01/app/grid' on the remote nodes 'indexserver3' : Done

Delete directory '/u01/app/grid' on the remote nodes 'indexserver4' : Done

Oracle Universal Installer cleanup was successful.

Oracle Universal Installer clean END

Oracle install clean START

Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver1'

Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver2'

Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver3'

Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver4'

Oracle install clean END

######################### CLEAN OPERATION END #########################

####################### CLEAN OPERATION SUMMARY #######################

ASM instance was de-configured successfully from the Oracle home

Following RAC listener(s) were de-configured successfully: LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1

Oracle Clusterware is stopped and successfully de-configured on node "indexserver3"

Oracle Clusterware is stopped and successfully de-configured on node "indexserver2"

Oracle Clusterware is stopped and successfully de-configured on node "indexserver1"

Oracle Clusterware is stopped and successfully de-configured on node "indexserver4"

Oracle Clusterware is stopped and de-configured successfully.

Skipping Windows and .NET products configuration clean

Successfully detached Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the local node.

Successfully deleted directory '/u01/app/11.2.0.2/grid' on the local node.

Successfully deleted directory '/u01/app/grid' on the local node.

Successfully detached Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the remote nodes 'indexserver2,indexserver3,indexserver4'.

Successfully deleted directory '/u01/app/11.2.0.2/grid' on the remote nodes 'indexserver2,indexserver3,indexserver4'.

Successfully deleted directory '/u01/app/grid' on the remote nodes 'indexserver2'.

Successfully deleted directory '/u01/app/grid' on the remote nodes 'indexserver3'.

Successfully deleted directory '/u01/app/grid' on the remote nodes 'indexserver4'.

Oracle Universal Installer cleanup was successful.

Oracle deinstall tool successfully cleaned up temporary directories.

#######################################################################

############# ORACLE DEINSTALL & DECONFIG TOOL END #############

2.9.3 卸载后的检查确认

Deinstall脚本执行完后,Grid的卸载就算完成了。接下来要做一些检查,确保卸载没有问题。我们从以下几个方面进行检查。

(1)首先,检查 4 个节点运行上面这些命令时屏幕上输出的日志内容,确保没有重要的错误。

(2)其次,检查集群各节点的/etc/inittab文件,ohasd的内容应该被删除了,也就是不应该有类似下面的内容:

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

(3)每个节点都不应该有ora或者d.bin的进程运行,否则应该用kill -9干掉它。

[root@indexserver3 ~]# ps -edf|grep ora

root 21238 17607 0 10:25 pts/0 00:00:00 grep ora

[root@indexserver3 ~]# ps -edf|grep d.bin

root 21240 17607 0 10:25 pts/0 00:00:00 grep d.bin

(4)看一下/etc/oracle这个目录,这个目录下的那些.loc文件已经被重命名为.orig。

[root@indexserver3 ~]# cd /etc/oracle/

[root@indexserver3 oracle]# ls

ocr.loc.orig olr.loc.orig

2.9.4 删除目录

如果上面的这些检查都没问题,现在就可以删除$GRID_HOME 下的所有内容了。不过这个目录应该已经被清空了。我们也可以继续清空$ORACLE_HOME目录的内容。

2.9.5 删除 ASM 磁盘

现在ASM磁盘还在,那么应该也把它们删除,从而开始一个全新的、干净的安装。这里需要在4个节点上以root身份运行以下命令:

[root@indexserver1 ~]# ls /dev/oracleasm/disks/

WXXRINDEX1

[root@indexserver1 ~]# oracleasm listdisks

WXXRINDEX1

[root@indexserver1 ~]# oracleasm deletedisk wxxrindex1

Clearing disk header: done

Dropping disk: done

[root@indexserver1 ~]# oracleasm listdisks

[root@indexserver1 ~]#

最后,再来个dd:

dd if=/dev/zero of=/dev/emcpowere1 bs=1024 count=1000000

好了,到这里Grid的卸载就全部做完了,接下来重新部署一个Grid吧。

2.10 小结

本章是上一章的内容延续,本来这两章是合并在一起的。但是一章 80 页之巨的安装手册显然会给读者带来太大的压力,用做产品的话说就是“用户体验很差”。所以我把那些外延性的介绍抽了出来,独立成一章。

这一章是围绕着安装中遇到的那些新界面、新名词展开的。Oracle 11gR2的安装界面变化很大,当然最大的变化是配色风格,虽然不太好看,但也不能否定它在我心中“一个伟大产品”的定位。

于是在这一章中,我们谈到了“角色分离”的管理思想,也就不诧异为什么Oracle 11gR2中有那么多用户和用户组。接着我们讨论了SSH用户等价、NTP时间同步、HAIP多网卡绑定,这些都是Oracle为了“降低部署难度”而做出的种种整合措施,很是符合Oracle“开箱见云”的宣传口号。但就个人而言,这些“简化”对于 DBA新人来说并不是好事,因为他们会错过很多长进的机会,也许这就是进步的代价。

安装过程还没有完,还差最后一步——彻底检查,要确保我们之前的努力没有白费,能够放心地把它丢到生产线上去发光散热。这就是下一章的内容。