一 RAC相关以及基础知识…
1.CRS简介…
(1).CRS进程…
(2).Virtual IP Address.
(3).OCR，Voting disk.
2.ASM相关…
3.RAC存储/网络需求…
(1).存储需求…
(2).网络需求…
4.其他概念…
(1).缓存融合…
(2).后台进程..
二 RAC安装…
1.安装规划部署…
2. 安装过程…
3.几点注意问题.
三 RAC管理维护…
1.CRS管理维护…
(1).OCR的管理维护…
(2).Voting disk管理维护…
2.RDBMS管理维护…
(1).spfile以及相关参数说明…
(2)REDO/UNDO管理
(3)Archivelog/flashback配置管理
(4)ASM管理
3.Database备份/恢复…
(1) .Archivelog对各节点可见的备份/恢复…
(2). Archivelog对各节点不可见的备份/恢复…
四.故障切换/负载平衡配置
1.Service 18
2. failover 18
(1).TAF以及实现
(2).FCF以及实现
3.Load Balance
五.其他维护实施相关/案例
1.集群中主机名的更改
2.集群中IP地址的更改
3.集群中节点的删除/添加
4.升级与迁移
5.高可用架构:RAC+DG
六．RAC监控优化
1.思路及等待事件说明
2.性能诊断
一 RAC相关以及基础知识
1.CRS简介
从Oracle 10G开始，oracle引进一套完整的集群管理解决方案—-Cluster-Ready Services，它包括集群连通性.消息和锁.负载管理等框架.从而使得RAC可以脱离第三方集群件，当然，CRS与第三方集群件可以共同使用.
(1).CRS进程
CRS主要由三部分组成，三部分都作为守护进程出现
<1>CRSD：资源可用性维护的主要引擎.它用来执行高可用性恢复及管理操作，诸如维护OCR及管理应用资源，它保存着集群的信息状态和OCR的配置，此进程以root权限运行.
<2>EVMD：事件管理守护进程.此进程还负责启动racgevt进程以管理FAN服务器端调用，此进程以root权限运行
<3>OCSSD：集群同步服务进程.管理集群节点的成员资格，它以fatal方式启动，因此进程发生故障将导致集群重启，以防止数据坏死. 同时，CSS还维护集群内的基本锁功能，以及负责监控voting disk的脑裂故障。它以Oracle权限运行
此外，还有一个进程OPRCD，他是集群中的进程监视程序，仅当平台上的CRS不使用厂商群件时候才出现，且无论运行了多少实例，每个节点只会存在一组后台进程.
来看一下这几个守护进程:
rac1-> cat /etc/inittab
…………………………… .
# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm –nodaemon
h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null
h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null
(2).Virtual IP Address
Oracle 10G RAC下，有3个重要的IP.
① Public IP ② Private IP ③ Vitual IP
Public IP为数据库所在主机的公共网络IP，Private IP被用来私有高速互联，而Oracle较前版本，增加了一个虚拟IP，用来节点发生故障时候更快的故障转移，oracle利用每个节点的lisnter 侦听VIP，一旦发生故障，VIP将进行实际的故障切换，从而在其他的可用的节点上保持联机，从而降低客户应用程序意识到节点故障所需要的时间。
VIP与Public IP必须在同一个网段内。
(3).OCR，Voting disk
OCR(oracle集群注册表)和Voting disk(表决磁盘)是CRS下的两个重要组件，它们必须放在共享磁盘上，以保证每个节点都能对其访问。
OCR包含了针对集群的一些配置信息，诸如:集群数据库中的节点列表.CRS应用程序.资源文件以及事件管理器的授权信息。他负责对集群内的资源追踪，从而获知资源正在哪里运行，应该可以在哪里运行。
Voting disk用来解决split-brain故障:如果节点丢失了与集群中其他节点的网络连接，这些冲突由表决磁盘中的信息来解决
2.ASM相关
ASM (Automated Storage Management) 是Oracle 10G引入的一种文件类型，他提供了直接的I/O读写，是RAC体系下一套不错的对数据文件存储规划的方案. ASM可以自动管理磁盘组，并提供数据冗余和优化.后面章节会就ASM的管理以及ASM下的RAC管理，单独讲解.
3.RAC存储/网络需求
图1.3 RAC体系架构
(1).存储需求
共享存储器是RAC的重要组件之一。它要求集群内的节点可以同时读写物理磁盘。目前，支持共享存储的文件类型也比较多，像Oracle自身提供的ASM，OCFS2以及三方提供的群集文件系统，都是可以选择的类型。
表1.1.1显示了RAC 体系架构下各部分所支持的存储类型 (暂不考虑三方集群文件系统，就ASM/raw device/OCFS2和普通文件系统来说)
表1.1.1 RAC各部分所支持的存储类型
|
类别 |
支持的存储类型 |
存储位置 |
备注 |
|
Cluster 软件 |
OCFS2，普通文件系统 |
共享磁盘/本地磁盘 |
|
|
OCR，Voting disk |
OCFS2，raw device |
共享磁盘 |
|
|
数据库软件 |
OCFS2，普通文件系统 |
共享磁盘/本地磁盘 |
|
|
数据库文件 |
OCFS2，raw device，ASM |
共享磁盘 |
|
|
归档日志文件 |
OCFS2，ASM，普通文件系统 |
共享磁盘/本地磁盘 |
|
|
备份/恢复文件 |
OCFS2，ASM，普通文件系统 |
共享磁盘/本地磁盘 |
|
|
闪回日志文件 |
OCFS2，ASM |
共享磁盘 |
|
(2).网络需求
每个节点主机上至少需要2张物理网卡，以便分配公有IP和私有IP地址。对于私有IP连接，每个集群节点通过专用高速网络连接到所有其他节点，目的在于集群上的节点和实例交换信息状态（锁信息，全局缓存信息等）。通过高速互联，Cache Fusion得以实现。
在实际环境中，高速互联至少需要配置GB级的以太网，而且，最好不要使用交叉直连。
较好的解决方案是节点间配置专用交换机，这样避免因为集群上一个节点宕掉而影响另外节点的正常工作。
4.其他
(1).后台进程
图1.4.1 Backgroud Process in RAC 10g
由于要维护多个实例同时访问资源所必需的锁定，因此，同single instance相比，RAC下增加了额外的一些进程。专门针对RAC的进程有如下几种：
1. LMS(Global Cache Service) 全局缓存服务进程
LMS负责为缓存融合请求在实例间传递块。当一致性请求的时候，LMS首先回滚块，创建块的读一致性映像（CR），然后将该一致性版本通过高速互联传递到处理此请求的远程实例中的前台进程上，LMS进程保证了在同一时刻只允许一个实例去更新数据块。
LMS进程的数量由初始化参数GCS_SERVER_PROCESSES控制。Oracle最大支持36个LMS进程（0–9 and a–z），该初始化参数默认值为2。
2. LMD (Global Enqueue Service Daemon) 全局队列服务守护进程
LMD负责管理全局队列和全局资源访问，并更新相应队列的状态，此外还负责远程节点资源的请求与死锁的检测。LMD与LMS进程互交工作，共同维护GRD。
3. LMON (Global Enqueue Service Monitor) 全局队列服务监控器进程
LMON是全局队列服务的监控器，他负责检查集群内实例的死亡情况并发起重新配置，当实例加入或者离开集群的时候，它负责重新配置锁和资源。
4. LCK(Lock process) 锁进程
LCK管理那些不是缓存融合的请求，例如library cahe, row cache.由于LMS进程提供了主要的锁管理功能，因此每个节点实例上只有一个LCK进程。
DIAG (The Diagnostic Daemon）诊断守护进程
DIAG负责监控实例的健康状况并捕获进程失败的信息，并将失败信息写入用于失败分析，该进程自动启动且不需要人为调整，若失败则自动重新启动。
(2).缓存融合/缓存一致性
Cache Fusion是RAC工作原理的一个中心环节.他的本质就是通过互联网络在集群内各节点的SGA之间进行块传递，从而避免了首先将块推送到磁盘，然后再重新读入其他实例的缓存中，从而最大限度的减少I/O。当一个块被读入RAC环境中某个实例的缓存时，该块会被赋予一个锁资源（与行级锁不同），以确保其他实例知道该块正在被使用。之后，如果另一个实例请求该块的一个拷贝，而该块已经处于前一个实例的缓存内，那么该块会通过互联网络直接被传递到另一个实例的 SGA。如果内存中的块已经被改变，但改变尚未提交，那么将会传递一个CR副本。这就意味着，只要可能，数据块无需写回磁盘即可在各实例缓存之间移动，从而避免了同步多实例的缓存所花费的额外I/O，由此，需要互联网络的速度是高速的，需要快于磁盘访问的速度．
GCS负责维护全局缓冲区内的缓存一致性，LMS进程是其主要组成部分。GCS确保同一时刻某个块上，只能有来自一个实例上的进程能对其修改,同时，并获得该块的当前版本和前映像，以及块所处的状态（NULL,,Shared, Exclusive），模式(local/gobal)。
GES负责维护dictionary cache和library cache缓存一致性（这个与LCK是不同的）。由于存在某个节点上对数据字典的修改(比如ddl和dcl对object属性的修改)，GES负责同步各节点上的字典缓存,消除差异。GES确保请求访问相同对象的多个实例间不会出现死锁。
GRD包含了所有共享资源的当前状态信息，它由GES和GCS共同维护，GRD贮存在内存中，被用来管理全局资源活动。比如：当一个实例第一次读取某块到 SGA的时候，该块的角色为LOCAL，GCS记录此状态到GRD，一旦有另外的实例请求该块，GCS会更新GRD，将此块的角色由LOCAL变为 GLOBAL。
二 RAC安装
不用把安装RAC看成是多么困难的一件事情.足够细心和耐性，充分的准备工作，然后加上一丁点运气，相信你能很快部署好一个RAC测试环境.当然，虚拟环境和实际环境的安装不尽相同，而且，生产系统环境的搭建需要经过缜密的规划和系统的测试.但大同小异，安装过程不该称为我们的绊脚石.
1.安装规划部署
安装之前需重点规划RAC系统各文件的存储类型.可以参见表1.3.1。一个好的存储规划方案，可以省去很多后续的维护成本。
2. 安装过程
安装过程可以参考oracle联机文档install guid。(Vmware安装可以参考Vincent Chan发表在oracle网站上的一文<使用 VMware Server 在 Oracle Enterprise Linux 上安装 Oracle RAC 10g>.文中讲的很详细，在此简单带过.)。简单列一下安装RAC的几个重要步骤
配置系统内核参数以及环境
配置共享存储
安装CRS软件
安装RDBMS软件
创建数据库以及配置其他
3.几点注意问题.
特别提一下vmware下的时间同步问题，在我的环境下，两节点上时间差别很大.一开始采用vmware-toolbox工具同步宿主时间，效果不理想. 可以在每个节点上放置一个小脚本，让他每隔一段时间以另一个节点为基准同步时间.这样，时间同步问题迎刃而解.在我的环境下，我设置每20秒同步一次时间.
rac1>cat date.sh
#!/bin/sh
while true
do
rdate -s rac2>dev/null 2>&1
sleep 10
done
三 RAC管理维护
同Single instance相比，RAC的管理维护要复杂一些。10g给我们提供了一个强大的EM管理工具，将很多管理维护工作简单和界面化。我们也应当习惯使用EM来高效的完成更多的工作。本文以下部分，将暂不讨论EM方面的管理，着重于命令行方式。
1.CRS管理维护
(1).CRS相关的接口命令
CRS在10G RAC体系下有着举足轻重的作用。Oracle也提供了一些命令接口让我们诊断维护它。
<1>CRS_*
10G RAC下，有这么几组crs_命令维护CRS资源。
[root@rac2 bin]# ls $ORA_CRS_HOME/bin|grep "crs_"|grep -v bin
crs_getperm crs_profile crs_register crs_relocate crs_setperm crs_start crs_stat crs_stop crs_unregister
下面分别讲述一下它们。
集群资源查询：CRS_STAT
可以用来查看RAC中各节点上resources的运行状况,Resources的属性等。
例如使用－t选项，检查资源状态：
[root@rac1 ~]# crs_stat –t
Name Type Target State Host
------------------------------------------------------------
ora.demo.db application ONLINE ONLINE rac2
ora....o1.inst application ONLINE ONLINE rac1
ora....o2.inst application ONLINE ONLINE rac2
ora....SM1.asm application ONLINE ONLINE rac1
ora....C1.lsnr application ONLINE ONLINE rac1
ora.rac1.gsd application ONLINE ONLINE rac1
ora.rac1.ons application ONLINE ONLINE rac1
ora.rac1.vip application ONLINE ONLINE rac1
ora....SM2.asm application ONLINE ONLINE rac2
ora....C2.lsnr application ONLINE ONLINE rac2
ora.rac2.gsd application ONLINE ONLINE rac2
ora.rac2.ons application ONLINE ONLINE rac2
ora.rac2.vip application ONLINE ONLINE rac2
利于-p选项，获得资源配置属性。
[root@rac2 bin]# crs_stat -p ora.rac2.vip
NAME=ora.rac2.vip
TYPE=application
ACTION_SCRIPT=/opt/oracle/product/10.2.0/crs_1/bin/racgwrap
ACTIVE_PLACEMENT=1
AUTO_START=1
CHECK_INTERVAL=60
DESCRIPTION=CRS application for VIP on a node
…………………………………………
USR_ORA_STOP_MODE=immediate
USR_ORA_STOP_TIMEOUT=0
USR_ORA_VIP=192.168.18.112
利用-p参数，获得资源权限。
[root@rac2 bin]# crs_stat -ls|grep vip
ora.rac1.vip root oinstall rwxr-xr--
ora.rac2.vip root oinstall rwxr-xr--
主要参数有-t/-v/-p/-ls/-f等。具体可以参见crs_stat –h
集群资源启动/停止CRS_START/CRS_STOP
这组命令主要负责各个节点上resources的启动/停止。可以针对全局资源(例如：crs_stop –all，表示停止所有节点上的resources),也可以针对节点上的某个特定的资源（例如：crs_start ora.rac2.ons,表示启动节点rac2上的ONS）。
集群资源配置CRS_REGISTER/CRS_UNREGISTER/CRS_PROFILE/CRS_SETPERM
这组命令主要负责集群资源的添加删除以及配置。
CRS_PROFILE:用来生成resource的profile文件(当然我们也可以手动编辑或者通过现有生成)，默认存放路径$ORA_CRS_HOME/crs/profile目录下，加参数-dir 手动指定目录。默认名称为resource_name.cap.
crs_profile -create resource_name -t application –a .. –r .. –o..
表3.1为 crs_profile中参数配置说明（比较多，挑一些说吧）：
|
参数名称 |
说明 |
参数指令（以create为例） |
|
NAME |
资源名称 |
crs_profile –create resource_name |
|
TYPE |
资源类型(application, generic) |
crs_profile – create resource_name –t … |
|
ACTION_SCRIPT |
用来管理HA方案脚本 |
crs_profile – create resource_name –a … |
|
ACTIVE_PLACEMENT |
资源贮存的位置/节点 |
crs_profile –create resource_name –o –ap … |
|
AUTO_START |
资源自启动 |
crs_profile –create resource_name –o –as … |
|
CHECK_INTERVAL |
资源监控间隔 |
crs_profile –create resource_name –o –ci … |
|
FAILOVER_DELAY |
资源failover的等待时间 |
crs_profile –create resource_name –o –fd … |
|
FAILURE_INTERVAL |
资源重启尝试间隔 |
crs_profile –create resource_name –o –fi … |
|
FAILURE_THRESHOLD |
资源重启尝试次数(最大20次) |
crs_profile –create resource_name –o –ft … |
|
HOSTING_MEMBERS |
资源启动或者failover的首要节点选择 |
crs_profile –create resource_name –h … |
|
PLACEMENT |
资源启动或者failover的节点选择模式（balanced，balanced，balanced） |
crs_profile – create resource_name -p |
|
REQUIRED_RESOURCES |
当前资源所依赖的资源 |
crs_profile – create resource_name -r |
|
RESTART_ATTEMPTS |
资源重配置之前的尝试启动次数 |
crs_profile –create resource_name –o –ra … |
|
SCRIPT_TIMEOUT |
等待ACTION_SCRIPT的结果返回时间 |
crs_profile –create resource_name –o –st … |
|
USR_ORA_VIP |
Vip地址 |
crs_profile –create vip_name -t application –a $ORA_CRS_HOME/bin/uservip –o oi=…,ov=…,on=… |
crs_profile －update resource_name … 用来更新现有profile(更新的只是profile，而并不是对已经注册到crs里面的资源属性的更改)
crs_register负责将resource的注册到OCR。注册的方法是先生成profile，然后运行
crs_register resource [-dir …]命令，同时，crs_register也具有update resource功能，具体办法可以更新resource对应的profile文件，然后运行crs_register -u resource_name [-dir …] 或者直接发布crs_register –update resource_name …
比如，我将rac节点上的vip改为手动启动。
[root@rac1 crs]# crs_register -update ora.rac1.vip -o as=0
[root@rac1 crs]# crs_stat -p ora.rac1.vip|grep AUTO_START
AUTO_START=0
crs_unregister负责将resource从ocr中移除。必要时候需要加－f参数。
crs_setperm用来设置resource的权限（诸如设置owner，用户的读写权限等），更改owner用-o参数，更改group用-g，更改用户权限用-u，在此不多举例了。
<2>.CRSCTL
用crsctl check crs，检查crs的健康情况。
[root@rac1 ~]# crsctl check crs
CSS appears healthy
CRS appears healthy
EVM appears healthy
用crsctl控制CRS服务
crsctl start|stop|enable|disable crs
用crsctl启动/停止resource
[root@rac1 ~]# crsctl stop resources
Stopping resources.
Successfully stopped CRS resources
[root@rac1 ~]# crsctl start resources
Starting resources.
Successfully started CRS resources
用crsctl检查以及添加、删除voting disk
下面讲述。
更多参见crsctl help。
<3>SRVCTL
SRVCTL是一个强大的CRS和RDBMS的管理配置工具。相关用法参照srvctl -h
（1） srvctl add/delete .. 添加删除资源。譬如我们在进行数据库单实例迁移到rac的时候，可以用这个工具手工注册database或者asm实例到OCR。
（2） srvctl status … 资源的状态监测
（3） srvctl start/stop … 资源的启动/停止，这个可以和crs_start/crs_stop互交使用。
（4） srvctl modify .. 重新定义资源的属性
………………………………………………………..
(2).OCR的管理维护
<1> OCR的状态验证：
可以使用ocrcheck工具来验证OCR的状态以及空间使用情况。在Lunix下，/etc/oracle/ocr.loc文件记录了OCR使用的设备情况。
[root@rac1]# ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 2
Total space (kbytes) : 497896
Used space (kbytes) : 3996
Available space (kbytes) : 493900
ID : 958197763
Device/File Name : /dev/raw/raw5
Device/File integrity check succeeded
Device/File not configured
Cluster registry integrity check succeeded
<2> 在线添加/删除ocrmirror
OCR支持一个镜像，添加/删除镜像可以在线完成，主要在某个online的节点上执行命令即可。
[root@rac1]#ocrconfig -replace ocrmirror /dev/raw/raw5
[root@rac1 oracle]# cat /etc/oracle/ocr.loc
#Device/file getting replaced by device /dev/raw/raw5
ocrconfig_loc=/dev/raw/raw1
ocrmirrorconfig_loc=/dev/raw/raw5
可见，ocr.loc被自动更新。
移除ocr或者镜像的时候，只要不带路径，即可。
当一个crs中存在ocr和镜像的时候，如果移除ocr，镜像会自动转变成ocr的角色。
[root@rac1]# ocrconfig -replace ocr
[root@rac1]# cat /etc/oracle/ocr.loc
#Device/file /dev/raw/raw1 being deleted
ocrconfig_loc=/dev/raw/raw5
可以看到现在的ocrconfig_loc自动变为先前的ocrmirrorconfig_loc设备。
<3> 逻辑备份/恢复
备份命令：
ocrconfig –export [ path ]
还原命令
ocrconfig –import [ path ]
还原OCR的时候，需要停掉各节点crs服务。还原完成后，重新启动CRS。(如果有必要，注意在每个节点分别修改ocr.loc的对应使用设备)
<4> 物理备份/恢复
CRSD负责每4个小时进行一次OCR的备份，默认备份路径在$ORA_CRS_HOME/cdate/crs下，
可以使用ocrConfig –showbackup查看备份情况，如果想更改物理备份路径，可以使用ocrconfig –backuploc [ path ] 来完成
物理恢复命令：
ocrconfig –restore [ path ]
同样,还原OCR的时候，需要停掉各节点crs服务。还原完成后，重新启动CRS。(如果有必要，注意在每个节点分别修改ocr.loc的对应使用设备)
<5> ocrdump
ocrdump可以将ocr信息导出成ascii文本，用于给Oracle Supoort提供检修。
命令如下：
ocrdump
(3).Voting disk管理维护
Voting disk的维护相对简单些。
<1> Votingdisk 状态查询
[root@rac1]# crsctl query css votedisk
0. 0 /dev/raw/raw2
located 1 votedisk(s).
<2>在线添加、删除votingdisk
Oracle建议配置奇数个votingdisk，添加/删除可以在线完成，在某个online的节点上执行命令即可。
添加votingdisk命令：
crsctl add css votedisk [path] -force
删除votingdisk命令：
crsctl add css votedisk [path] -force
<3>votingdisk备份恢复
备份、恢复采用dd命令。恢复的时候，注意停掉各节点上的CRS服务。
2.RDBMS管理维护
(1).spfile以及相关参数说明
最普遍情况，节点共用同一个spfile文件，放置在共享存储上，而每个节点上，相应目录下有一个pfile文件，而这个pfile文件指向共享存储上的spfile。
当我们需要修改某一节点上的paremeter的时候，需要显示的指定sid，例如：
SQL>alter system set sga_target=1024M scope=spfile sid=’rac1’;
System Altered.
这样，节点rac1上的sga_target参数被修改，不会影响其余节点上的参数设置。如果不加sid，默认为sid＝’*’，也就是对所有节点生效。
RAC下，有一些不同与单实例的参数，列举如下：
① cluster_database
一般情况下，该参数在rac各实例下应该设置为true。在一些特别情况下，比如upgrade等，需要将该参数设置成false。
② db_name/db_unique_name/instance_name
各节点db_name需要一致，db_unique_name也需要一致(这与standby是不同的)。而instance_name配置成各个节点的实例名称。
③ instance_number
该参数表示节点上实例的实例号。
④ thread
该参数用来标示实例使用的redo线程。线程号与节点号/实例号没有直接关联。
⑤ local_listener
该参数用来手工注册监听。为解决ORA-12514错误，可以设置该参数。
⑥ remote_listener
该参数用来进行服务器端负载均衡配置。
⑦ cluster_interconnects
该参数用来指定集群中IPC通信的网络。如果集群中有多种网络用于高速互联，需要配置该参数。对于多个IP地址，用冒号将其隔开。对于集群中当前使用的互联地址，可以查询视图gv$cluster_interconnects或着oradebug ipc来查看。
⑧ max_commit_propagation_delay
该参数用于配置SCN的产生机制。在rac下,SCN的同步有2种模式:(1) Lamport Scheme.该模式下，由GES管理SCN的传播同步，max_commit_propagation_delay表示SCN同步所允许的最大时间。在该模式下，全局SCN并非完全同步，这在高并发的OLTP系统中，可能会对应用造成一定的影响。(2) Broadcast on Commit scheme. 该模式下，一旦任何一个实例上事务发布commit，都立即同步SCN到全局。
在10g R1下，该参数默认数值为700，即采用Lamport Scheme模式。而在10g R2下，该参数默认数值为0，采用Broadcast on Commit scheme模式 (设置小于700的某一值，都将采用该模式) 。采用何种方式，可以从alert.log中获知。该参数值需要每个节点保持一致。
(2). Redo/Undo管理
?RAC下的Redo管理
同单实例的系统一样，每个节点实例都需要至少2组logfile。各节点实例有自己独立的重做日志线程(由初始化参数thread定义)，例如：
SQL> select b.THREAD#,a.GROUP#,a.STATUS,a.MEMBER,b.BYTES,b.ARCHIVED,b.STATUS from v$logfile a,v$log b where a.GROUP#=b.GROUP#;
THREAD# GROUP# STATUS MEMBER BYTES ARCHIVED STATUS
------------------- ------- --------------------------------------------------
1 1 STALE +DATA/demo/onlinelog/group_1.257.660614753 52428800 YES INACTIVE
1 2 +DATA/demo/onlinelog/group_2.258.660614755 52428800 NO CURRENT
2 3 +DATA/demo/onlinelog/group_3.265.660615545 52428800 NO CURRENT
2 4 STALE +DATA/demo/onlinelog/group_4.266.660615543 52428800 YES INACTIVE
重做日志需要部署到共享存储中，必须保证可被所有的集群内的节点实例访问。当某个节点实例进行实例/介质恢复的时候，该节点上的实例将可以应用集群下所有节点实例上的重做日志文件(如果需要)，从而保证恢复可以在任意可用节点进行。
?RAC下alter system switch logfile 与alter system archive log current 区别
alter system switch logfile仅对当前发布节点上的对应redo thread进行日志切换并归档。
alter system archive log current对集群内所有节点实例上的redo thread进行切换并归档（在节点实例可用情况下，分别归档到各节点主机的归档目的地，当节点不可用时候，该线程日志归档到命令发布节点的归档目的地）
?RAC下的Undo管理
RAC下的每个节点实例，也需要有自己单独的撤销表空间。由初始化参数 *.Undo_tablespace 指定。同REDO一样，UNDO表空间也需要部署到共享存储，虽然每个节点上UNDO的使用是独立的，但需要保证集群内其他节点实例对其访问，以完成构造读一致性等要求。
SQL>alter system set undo_tablespace=undo1 sid=’demo1’;
SQL>alter system set undo_tablespace=undo2 sid=’demo2’;
(3).Archivelog/flashback配置管理
在RAC下，Archivelog可以放置到本地磁盘，也可以放置到共享存储。需要对Archivelog的放置有合理的部署，如果放置到本地磁盘，会增加备份恢复的复杂程度。
闪回区必须部署到共享存储上，开启前，需要配置db_recovery_file_dest、db_recovery_file_dest_size、db_flashback_retention_target等参数。
下面在一个非归档非闪回的database上，开始归档与闪回。
?更改相关参数
SQL>alter system set log_archive_dest_1='location=/archive/demo1' sid='demo1';
System altered
SQL> alter system set log_archive_dest_1='location=/archive/demo2' sid='demo2';
System altered
SQL> alter system set db_recovery_file_dest_size=512M;
System altered
SQL> alter system set db_recovery_file_dest='+DG1';
System altered
?停掉所有节点实例.开启过程在一个实例上完成。
rac1-> srvctl stop instance -d demo -i demo1
rac1-> srvctl stop instance -d demo -i demo2
rac1-> sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Sun Aug 3 22:06:50 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn /as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 100665588 bytes
Database Buffers 62914560 bytes
Redo Buffers 2973696 bytes
Database mounted.
SQL> alter database archivelog;
Database altered.
SQL> alter database flashback on;
Database altered.
SQL> alter database open;
Database altered.
SQL> select NAME,LOG_MODE,FLASHBACK_ON from v$database;
NAME LOG_MODE FLASHBACK_ON
--------- ------------ ------------------
DEMO ARCHIVELOG YES
10G下，开启归档和闪回并不需要像9i那样，设置初始化参数cluster_database＝false.这无疑简化了操作。
(4).ASM下的RAC管理
?ASM下的参数文件
RAC下，每个节点上有运行有一个ASM实例，而rdbms instance就运行在这个asm实例上。Asm实例是本地的。同rdbms实例一样，他需要有参数文件，参数文件在每个节点的相应目录下。
下面是我的ASM实例下的pfile文件：
cluster_database=true
background_dump_dest=/opt/oracle/admin/+ASM/bdump
core_dump_dest=/opt/oracle/admin/+ASM/cdump
user_dump_dest=/opt/oracle/admin/+ASM/udump
instance_type=asm
large_pool_size=12M
remote_login_passwordfile=exclusive
asm_diskgroups='DG1'
+ASM2.instance_number=2
+ASM1.instance_number=1
简单介绍几个asm实例中比较重要的参数:
instance_type：用来说明实例是ASM 还是RDBMS 类型
asm_diskgroups：ASM磁盘组，asm实例启动的时候会自动mount
asm_diskstring：该参数用来说明能够创建diskgroup的磁盘设备,默认值是NULL
asm_power_limit:该参数用来设置进程 ARBx 的数量，负责控制负载平衡操作的速度。取值 从 0 到 11。默认值为1。
?用于记录ASM实例信息的数据字典。
V$ASM_DISK/ V$ASM_DISK_STAT：记录可以被ASM实例识别的磁盘信息，但这些磁盘并不一定是正在被实例使用的。
V$ASM_DISKGROUP/ V$ASM_DISKGROUP_STAT：记录asm下的diskgroup信息。
V$ASM_ALIAS：记录diskgroup文件的别名信息。
V$ASM_FILE：记录diskgroup中的文件信息。
V$ASM_OPERATION：记录ASM实例中当前运行的一个长时间操作信息。
V$ASM_TEMPLATE：记录diskgroup模板。
V$ASM_CLIENT：记录使用该asm实例下的diskgroup的rdbms实例信息。
?RAC下ASM磁盘组/文件管理操作
<1>.RAC下在线添加、删除磁盘组
在一个节点上添加diskgroup，集群上另外的节点并不会自动mount新添加的diskgroup，需要手动执行。
节点1：
SQL> show parameter asm_diskgroups
NAME TYPE VALUE
------------------------------------ -----------
asm_diskgroups string DATA, DG1
SQL>CREATE DISKGROUP DATA2 NORMAL REDUNDANCY
FAILGROUP DATA2_gp1 DISK '/dev/raw/raw6'
FAILGROUP DATA2_gp2 DISK '/dev/raw/raw7';
Diskgroup created.
SQL> show parameter asm_diskgroups
NAME TYPE VALUE
------------------------------------ -----------
asm_diskgroups string DATA, DG1, DATA2
此时观察节点2，新加的磁盘组没有被mount。
SQL> show parameter asm_diskgroups
NAME TYPE VALUE
-----------------------------------------------
asm_diskgroups string DATA, DG1
SQL>select group_number,type,state,type,total_mb,free_mb from v$asm_diskgroup_stat;
GROUP_NUMBER STATE TYPE TOTAL_MB FREE_MB
--------------- --------------- ------------------------
1 CONNECTED EXTERN 5726 4217
2 CONNECTED EXTERN 415 297
0 DISMOUNTED 0 0
SQL>alter diskgroup DATA2 mount;
删除diskgroup时，保留一个节点diskgroup为mount状态，将其余节点上的diskgroup dismount，然后执行删除命令。
<2>.在线添加、删除磁盘
RAC下在线添加磁盘与删除磁盘与单实例并不差别。需要注意该操作会引起磁盘组的重新平衡，并确保删除磁盘的时候该磁盘组有足够的剩余空间。
节点1：
SQL> alter diskgroup dg6 add disk '/dev/raw/raw7' name dg6_disk7;
Diskgroup altered.
节点2上查询：
SQL>select GROUP_NUMBER,path,NAME,MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,
STATE from v$asm_disk_stat where NAME is not null;
GROUP_NUMBER PATH NAME MOUNT_S HEADER_STATU MODE_ST STATE
------------ ---------------- ---------- ------- ------------ -------
1 /dev/raw/raw3 DATA_0000 CACHED MEMBER ONLINE NORMAL
2 /dev/raw/raw4 DG1_0000 CACHED MEMBER ONLINE NORMAL
3 /dev/raw/raw6 DG6_0001 CACHED MEMBER ONLINE NORMAL
3 /dev/raw/raw7 DG6_DISK7 CACHED MEMBER ONLINE NORMAL
删除磁盘在某一节点操作即可，不做举例验证。
关于ASM的更多管理命令，就不多列举了。
3.Database备份/恢复
RAC下的备份恢复跟单实例的备份恢复实质上没有太大的差别，需要注意的是备份/恢复的时候当前节点对所有数据文件/归档日志的可见。在一个数据文件和归档日志全部放在共享存储上的RAC系统，备份与恢复过程与单实例下的几乎一样。而归档日志如果采用的是本地磁盘，就需要另加注意。下面分别来模拟这个备份恢复过程。
(1).Archivelog对各节点可见的备份/恢复
在这种模式下，备份恢复可以在任意一个可用节点执行即可，跟单实例并不太大区别。
?对database进行备份
RMAN>run
{allocate channel orademo type disk;
backup database format '/backup/database/db_%s_%p_%t' plus archivelog format '/backup/database/arch_%s_%p_%t' delete input;
backup current controlfile format '/backup/database/contr_%s_%p_%t';}
allocated channel: orademo
channel orademo: sid=130 instance=demo2 devtype=DISK
Starting backup at 03-MAY-08
current log archived
channel orademo: starting archive log backupset
channel orademo: specifying archive log(s) in backup set
input archive log thread=1 sequence=5 recid=70 stamp=661823848
input archive log thread=1 sequence=6 recid=72 stamp=661823865
……………………………………..
Finished backup at 03-MAY-08
released channel: orademo
?添加数据，用于测试恢复效果
SQL> create table kevinyuan.test_b as select * from dba_data_files;
Table created
SQL> alter system switch logfile;
System altered
SQL> insert into kevinyuan.test_b select * from dba_data_files;
6 rows inserted
SQL> commit;
Commit complete
SQL> select count(*) from kevinyuan.test_b;
COUNT(*)
----------
12
?模拟故障/恢复
RMAN> run
{restore controlfile from '/backup/database/contr_16_1_661823935';
sql 'alter database mount';
restore database;
recover database;
sql 'alter database open resetlogs'; }
Starting restore at 04-MAY-08
allocated channel: ORA_DISK_1
…………………………………………………………………………..
archive log filename=+DATA/demo/onlinelog/group_4.266.660615543 thread=2 sequence=11
archive log filename=+DATA/demo/onlinelog/group_3.265.660615545 thread=2 sequence=12
media recovery complete, elapsed time: 00:00:00
Finished recover at 04-MAY-08
sql statement: alter database open resetlogs
?恢复完毕，来看一下验证数据：
SQL> select count(*) from kevinyuan.test_b;
COUNT(*)
----------
12
(2). Archivelog对各节点不可见的备份/恢复
如果arhivelog采用本地磁盘,归档日志并不是对任意节点可见。备份archivelog的时候，如果采用和上述类似的备份方案，必然会导致一些归档日志由于无法access而抛出异常。可以采取如下的备份方式，目的就是使得备份通道能够access所有的数据字典中记录的归档日志信息。
恢复的时候,copy所有节点产生的相关备份片/集和归档日志文件到待恢复节点，在一个节点上执行restore/recover操作即可。
模拟一下这个操作。
SQL> alter system set log_archive_dest_1='location=/archive/demo1/' sid='demo1';
System
altered
SQL> alter system set log_archive_dest_1='location=/archive/demo2/' sid='demo2';
System altered
(1)备份数据库
RMAN>run
{allocate channel orademo1 type disk connect
sys/kevinyuan@demo1;
allocate channel orademo2 type disk connect
sys/kevinyuan@demo2;
backup database format '/backup/database/db_%s_%p_%t'
plus archivelog format '/backup/database/arch_%s_%p_%t' delete
input;
backup current controlfile format
'/backup/database/contr_%s_%p_%t;}
allocated channel:
orademo1
channel orademo1: sid=133 instance=demo1 devtype=DISK
allocated
channel: orademo2
channel orademo2: sid=151 instance=demo2
devtype=DISK
Starting backup at 04-MAY-08
current log archived
channel
orademo2: starting archive log backupset
channel orademo2: specifying archive
log(s) in backup set
input archive log thread=2 sequence=4 recid=89
stamp=661826286
………………………………………………………………….
channel orademo1: finished
piece 1 at 04-MAY-08
piece handle=/backup/database/contr_28_1_661826504
tag=TAG20080504T004130 comment=NONE
channel orademo1: backup set complete,
elapsed time: 00:00:09
Finished backup at 04-MAY-08
released channel:
orademo1
released channel:
orademo2
(2)COPY节点2上的备份文件/归档日志文件到节点1相应目录下。
rac2-> scp /backup/database/* rac1:/backup/database/
rac2-> scp /archive/demo2/* rac1:/archive/demo1
(3)恢复database
RMAN>run
{restore controlfile from '/backup/database/contr_28_1_661826504';
sql 'alter database mount';
restore database;
recover database;
sql 'alter database open resetlogs';}
starting restore at 04-MAY-08
using target database
control file instead of recovery catalog
allocated channel:
ORA_DISK_1
channel ORA_DISK_1: sid=147 instance=demo1 devtype=DISK
channel
ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete,
elapsed time: 00:00:20
…………………………………………………………………………………
archive log
filename=+DATA/demo/onlinelog/group_3.265.660615545 thread=2
sequence=7
archive log filename=+DATA/demo/onlinelog/group_4.266.660615543
thread=2 sequence=8
media recovery complete, elapsed time:
00:00:06
Finished recover at 04-MAY-08
sql statement: alter database open
resetlogs
至此，恢复完成。
生产库的备份需要缜密部署与模拟测试，不同的数据库类型也需要制定不同的方案实现。对DATABASE来说，备份重于泰山，不能抱有任何侥幸心理。
1.Service
服务是rac体系中相当重要的概念，它为应用提供高可用和多样化的解决方案。实际中，我们可以创建不同性质的service来满足我们应用的不同需求。
10gR2下，可以通过以下几个方式创建服务。
(1).使用dbca
(2).使用srvctl
node1->srvctl add service -d demo -s srv_1 -r node1 -a node2
node1-> srvctl start service -d demo -s srv_1
node1-> crs_stat -t
Name Type Target State Host
————————————————————
ora.demo.db application ONLINE ONLINE node1
ora….o1.inst application ONLINE ONLINE node1
ora….o2.inst application ONLINE OFFLINE
ora….rv_1.cs application ONLINE ONLINE node1
ora….mo1.srv application ONLINE ONLINE node1
—————————————
SQL> show parameter service
NAME TYPE VALUE
———————————— ———– ———–
service_names string demo,srv_1
(3).使用dbms_service命令创建
10g提供了dbms_service用于管理服务并进行功能扩展.
SQL>EXEC DBMS_SERVICE.CREATE_SERVICE(SERVICE_NAME=>’srv_2′,NETWORK_NAME=>’ srv_2′);
PL/SQL procedure successfully completed
SQL> exec DBMS_SERVICE.START_SERVICE(service_name => ’srv_2′,instance_name => ‘demo1′);
PL/SQL procedure successfully completed
SQL> show parameter service
NAME TYPE VALUE
———————————— ———– ———–
service_names string demo,srv_2
(4).其他等..
不管采用哪种方式，实质都是通过修改service_names而向lisnter动态注册服务.
2. failover and load banance
RAC为应用提供了高性能和高可用的服务，对用户来讲，核心的功能便是failover与load banance.
(1)Failover
在10gR2版本里，Failover的实现方式有两种，一种是TAF(Transparent Application Failover), 一种是FCF(Fast Connection Failover).
TAF以及实现:
TAF是net层透明故障转移,是一种被动的故障转移方式, 依赖于VIP.可以通过客户端和服务器端配置taf的策略.
<1> client端taf配置
以下是一个简单的具有taf功能的tnsnames.ora 内容
demo =
(DESCRIPTION =
(FAILOVER=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.145)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.146)(PORT=1521))
(CONNECT_DATA =
(SERVICE_NAME = demo)
(SERVER=DEDICATED)
(FAILOVER_MODE=(TYPE=SELECT)
(METHOD=BASIC)
(RETRIES=50)
(DELAY=5)
)
)
)
控制TAF策略的参数说明：
|
参数 |
描述 |
|
FAILOVER |
Failover控制开关（on/off），如果为off，不提供故障切换功能，但连接时会对address列表进行依次尝试，直到找到可用为止 |
|
TYPE |
两种类型：session /select Session: 提供session级别的故障切换。 Select：提供select级别的故障切换，切换过程对查询语句透明，但事物类处理需要回滚操作 |
|
METHOD |
两种类型:basic/preconnect Basic:client同时只连接一个节点，故障切换时跳转到另外节点 Preconnect：需要与backup同时使用，client同时连接到主节点和backup节点 |
|
BACKUP |
采用Preconnect模式的备用连接配置 |
|
RETRIES |
故障切换时重试次数 |
|
DELAY |
故障切换时重试间隔时间 |
<2> Server端TAF配置
10gR2提供Server端的TAF配置，需要调用dbms_service包来在实例上进行修改。
SQL> exec dbms_service.modify_service(service_name => ‘DEMO’,failover_method => ‘BASIC’,failover_type => ‘SELECT’,failover_retries => 180,failover_delay => 5);
客户端连接字符串修改成如下即可：
demo =
(DESCRIPTION =
(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.145)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.146)(PORT=1521))
(CONNECT_DATA =
(SERVICE_NAME = demo)
(SERVER=DEDICATED)
)
)
FCF及实现
FCF是10g引进的一种新的failover机制，它依靠各节点的ons进程，通过广播FAN事件来获得各节点的运行情况，是一种前摄性的判断，支持JDBC/OCI/ODP.NET
(1).ons配置
onsctl工具配置各节点的local /remote节点以及端口.配置文件路径:$ORACLE_HOME/opmn/ons.config.
使用 onsctl debug 跟踪ons进程是否正常运行。
(2).配置连接池（以jdbc为例）
需要连接池支持Implicit Connection Cache，设置FastConnectionFailoverEnabled=true.
将ojdbc14.jar / ons.jar等加入CLASSPATH.具体代码可以参见联机文档或metalink相关文档.
(2) Load Balance
10g的 load balance同前版本相比有了很大功能上的改进，依据Load Balancing Advisory，提供了Runtime Connection Load Balancing的策略，但个人认为这也是个相对矛盾所在。越是细化的负载均衡机制，越是有加重cache fusion的可能，这对rac的整体性能是个考验。
load balance主要有两种实现方式:一种是Connection Load Balancing(CLB)，另外一种是Runtime Connection Load Balancing(RCLB)。
CLB分为客户端client-side和服务器端server-side两种。
client-side需要在tnsname.ora添加LOAD_BALANCE=ON来实现，提供基于平衡连接数的负载方案.
server-side需要修改remote_listener参数,让listener能监听到集群中的所有节点,通过PMON来收集节点上的负载信息。
FCF默认支持RCLB功能，RCLB通过load balancing advisory事件来对连接提供更好的服务。RCLB有两种负载平衡方案可供选择—-基于总体service name和基于总体Throughput。可以通过dbms_service来设置具体的goal方案。
SQL> exec dbms_service.modify_service(service_name => ‘TEST’, goal => DBMS_SERVICE.GOAL_SERVICE_TIME);
至于这两种方式的具体差异，在我的测试中，并没有得到明显的体现。
Load Balanc这部分是我存疑最多的地方，查阅了很多文档，说法不一，且没有翔实的案例证明，在此也希望有过研究的朋友们做指正。
本环节侧重一些RAC工程维护相关的实际案例,暂举例以下案例
1.集群中主机名的更改
2.集群中IP地址的更改
3.集群中节点的添加/删除
4.升级:9i rac升级10g rac
5.rac + dg 搭建
6.其他
<一> 集群中主机名的更改
以下为一个实际案例，下表为更改前后的主机名称对比
hostname:node1/node2 —-> td1/td2
private_name:node1_priv/node2_priv —-> td1_priv/td2_priv
vip_name:node1_vip/node2_vip —-> td1_vip/td2_vip
1.生成listener的cap文件
node1->crs_stat –p ora.node1.LISTENER_NODE1.lsnr>/home/oracle/ora.node1.LISTENER_NODE1.lsnr.cap
node1->crs_stat –p ora.node2.LISTENER_NODE2.lsnr>/home/oracle/ora.node2.LISTENER_NODE2.lsnr.cap
2.停掉所有的资源，备份ocr、votingdisk并重新格式化
备份OCR
[root@node1 backup]# ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 2
Total space (kbytes) : 104176
Used space (kbytes) : 4424
Available space (kbytes) : 99752
ID : 2042344313
Device/File Name : /dev/raw/raw1
Device/File integrity check succeeded
Device/File not configured
Cluster registry integrity check succeeded
[root@node1 init.d]# ocrconfig -export /backup/ocr_1.bak
备份votedisk
[root@node1 ~]# crsctl query css votedisk
0. 0 /dev/raw/raw110
located 1 votedisk(s).
[root@node1 ~]# dd if=/dev/raw/raw110 of=/backup/votedisk.bak
重新格式化
[root@td01 ~]# dd if=/dev/zero of=/dev/raw/raw1 bs=1024k count=1
[root@td01 ~]# dd if=/dev/zero of=/dev/raw/raw110 bs=1024k count=1
3.OS上修改hostname并编辑相关文件，重启主机（步骤略）
4.重新配置集群互信。（步骤略）
5.编辑$ORA_CRS_HOME/ install/rootconfig文件，修改以下为你实际的情况。
ORA_CRS_HOME=/opt/oracle/product/10.2.0/crs_1
CRS_ORACLE_OWNER=oracle
CRS_DBA_GROUP=oinstall
CRS_VNDR_CLUSTER=false
CRS_OCR_LOCATIONS=/dev/raw/raw1
CRS_CLUSTER_NAME=crs
CRS_HOST_NAME_LIST=td1,1,td2,2
CRS_NODE_NAME_LIST=td1,1,td2,2
CRS_PRIVATE_NAME_LIST=td1-priv,1,td2-priv,2
CRS_LANGUAGE_ID=’AMERICAN_AMERICA.WE8ISO8859P1′
CRS_VOTING_DISKS=/dev/raw/raw110
CRS_NODELIST=td1,td2
CRS_NODEVIPS=’td1/td1-vip/255.255.255.0/eth0,td2/td2-vip/255.255.255.0/eth0′
在每个节点依次执行：
[root@td2 install]# /opt/oracle/product/10.2.0/crs_1/install/rootconfig
Checking to see if Oracle CRS stack is already configured
Setting the permissions on OCR backup directory
Setting up NS directories
Oracle Cluster Registry configuration upgraded successfully
WARNING: directory ‘/opt/oracle/product/10.2.0′ is not owned by root
WARNING: directory ‘/opt/oracle/product’ is not owned by root
WARNING: directory ‘/opt/oracle’ is not owned by root
WARNING: directory ‘/opt’ is not owned by root
clscfg: EXISTING configuration version 3 detected.
clscfg: version 3 is 10G Release 2.
Successfully accumulated necessary OCR keys.
Using ports: CSS=49895 CRS=49896 EVMC=49898 and EVMR=49897.
node :
node 1: td1 td1-priv td1
node 2: td2 td2-priv td2
clscfg: Arguments check out successfully.
NO KEYS WERE WRITTEN. Supply -force parameter to override.
-force is destructive and will destroy any previous cluster
configuration.
Oracle Cluster Registry for cluster has already been initialized
Startup will be queued to init within 30 seconds.
Adding daemons to inittab
Expecting the CRS daemons to be up within 600 seconds.
CSS is active on these nodes.
td1
td2
CSS is active on all nodes.
Waiting for the Oracle CRSD and EVMD to start
Oracle CRS stack installed and running under init(1M)
Running vipca(silent) for configuring nodeapps
Creating VIP application resource on (2) nodes…
Creating GSD application resource on (2) nodes…
Creating ONS application resource on (2) nodes…
Starting VIP application resource on (2) nodes…
Starting GSD application resource on (2) nodes…
Starting ONS application resource on (2) nodes…
如果是10.2.0.1 版本，在最后一个节点上执行的时候会因为vip的bug抛出异常，在该节点上调用VIPCA图形化界面。
这样gsd、ons和vip已经全部注册到OCR中。
[root@td1 install]# crs_stat -t
Name Type Target State Host
————————————————————
ora.td1.gsd application ONLINE ONLINE td1
ora.td1.ons application ONLINE ONLINE td1
ora.td1.vip application ONLINE ONLINE td1
ora.td2.gsd application ONLINE ONLINE td2
ora.td2.ons application ONLINE ONLINE td2
ora.td2.vip application ONLINE ONLINE td2
6.使用oifcfg配置共有/私连网络
td1-> oifcfg setif -global eth0/10.194.129.0:public
td1-> oifcfg setif -global eth1/10.10.10.0:cluster_interconnect
7.注册其他资源到集群
(1)注册监听到集群
修改监听配置文件lisntener.ora并编辑生成的cap文件（改名），更改其中用到的hostname.
td1-> crs_register ora.td1.LISTENER_TD1.lsnr -dir /home/oracle
td1-> crs_register ora.td2.LISTENER_TD2.lsnr -dir /home/oracle
或者使用netca图形化界面来配置监听.
(2)注册ASM实例到集群(如果使用ASM)
td1->srvctl add asm -n td1 -i ASM1 -o $ORACLE_HOME
td1->srvctl add asm -n td2 -i ASM2 -o $ORACLE_HOME
(3)注册instance/database到集群
td1->srvctl add database -d demo -o $ORACLE_HOME
td1->srvctl add instance -d demo -i demo1 -n td1
td1->srvctl add instance -d demo -i demo2 -n td2
验证：
td1-> crs_stat -t
Name Type Target State Host
————————————————————
ora.demo.db application ONLINE ONLINE td1
ora….o1.inst application ONLINE ONLINE td1
ora….o2.inst application ONLINE ONLINE td2
ora….SM1.asm application ONLINE ONLINE td1
ora….D1.lsnr application ONLINE ONLINE td1
ora.td1.gsd application ONLINE ONLINE td1
ora.td1.ons application ONLINE ONLINE td1
ora.td1.vip application ONLINE ONLINE td1
ora….SM2.asm application ONLINE ONLINE td2
ora….D2.lsnr application ONLINE ONLINE td2
ora.td2.gsd application ONLINE ONLINE td2
ora.td2.ons application ONLINE ONLINE td2
ora.td2.vip application ONLINE ONLINE td2
登陆数据库检查db使用的内连接链路
SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— ——————————-
eth1 10.10.10.145 NO Oracle Cluster Repository
如果使用了OCFS作为共享文件格式，注意在启动数据库前检查相应OCFS的配置并确认ocfs是否能正常挂载使用。
2.集群中IP地址的更改
IP地址的更改比hostname的更改相对容易一些。对于同网段的public/private IP更改，无需进行特别操作。如果是不同网段，需要使用oifcfg处理。因为VIP是作为资源注册到OCR，所以任何VIP的改动都需调用相关命令进行处理。
以上处理都需要在集群资源停掉的基础上操作。
以下是修改前后的public/pricate/vip
Public IP 10.194.129.145/146 –> 10.194.128.145/146
Privite IP 10.10.10.145/146 –> 10.10.1.145/146
Virtual IP 10.194.129.147/148 –> 10.194.128.147/148
1.停掉各资源
数据库正常关库，其余资源使用crs_stop 停止。
2.重新修改网卡ip/gateway/host文件等,重启网络等相关服务
3.利用oifcfg更改public/private ip
查看当前使用
td1-> oifcfg getif
eth1 10.10.10.0 global cluster_interconnect
eth0 10.194.129.0 global public
删除当前
td1-> oifcfg delif -global eth0
td1-> oifcfg delif -global eth1
重新添加
td1-> oifcfg setif -global eth0/10.194.128.0:public
td1-> oifcfg setif -global eth1/10.10.1.0:cluster_interconnect
4.更新注册到OCR中的vip配置(root用户)
[root@td1 ~]# crs_register -update ora.td1.vip -o oi=eth0,ov=10.194.128.147,on=255.255.255.0
[root@td1 ~]# crs_register -update ora.td2.vip -o oi=eth0,ov=10.194.128.148,on=255.255.255.0
或者使用(root用户)
[root@td1 ~]# srvctl modify nodeapps -n td1 -A 10.194.128.147/255.255.255.0/eth0
[root@td1 ~]# srvctl modify nodeapps -n td2 -A 10.194.128.148/255.255.255.0/eth0
5.如果你使用了ocfs，修改ocfs配置文件(/etc/ocfs/cluster.conf),验证修改后是否可用
6.修改监听listener配置文件
7.启动集群各节点资源并验证
td1-> crs_start –all
登陆数据库，检验内连接是否生效。
SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— —————————-
eth1 10.10.1.145 NO Oracle Cluster Repository
<三>.集群中节点的删除/添加
同9i的节点删除/添加相比，10g对节点的添加和删除相对来说略显麻烦，但操作起来更加规范。
因为集群件的存在，需调用一系列接口命令将资源从OCR中添加/删除，本文不再对该案例做详细描述，具体参见oracle官方联机文档RAC部分 –Adding and Deleting Nodes and Instances on UNIX-Based Systems.
<四>.升级与迁移
RAC的迁移与升级并不比单实例复杂多少。对于一个rac新手来说，在思想上也无需觉得这是个很庞杂的事情，当然前提是你有足够的单实例方面的基础知识并对此深刻理解。
比如，利用rman备份，我们可以方便的将一个运行在单节点的实例迁移到rac环境下。需要做的重点，仅仅是迁移数据库(你可以想象成是单实例对单实例)，然后编辑参数文件，添加其他节点启动db所必要的redo和undo，并注册数据库资源到集群中以便管理。
如果你的迁移或升级有停机时间的限制，那大部分情况下重点的问题并不在于被操作对象是RAC架构，而在于如何制定你的MAA策略。比如你需要运用一些表空间传输或者高级复制/流等方面的特性来压缩停机时间，这也许因为是RAC架构而增加了整个施工的难度，但很多时候问题的重点并不在于此。
接下来提供一个9I RAC同机静默升级到 10G RAC的案例,详细可参见我的一篇blog http://www.easyora.net/blog/9i_rac_upgrade_10g_rac.html
<五>.高可用架构:RAC+DG
应该说，rac+dg企业级的架构在高可用和灾备方面来说还是有相当大的市场。
在搭建与管理方面，rac(主)+DG(备)的过程与单实例的主备也无太大异同。需要注意以下方面(但不限于以下方面):
1.log gap的检测问题
注意正确配置fal_server与fal_clicent参数，尤其是对于rac主库归档到各自节点上的情况下,standby端gap server需要将每个主库节点都涵盖进去。
2.switchover/failover注意事项
做任何切换的时候，需要将rac端只保留一个alive的实例，其余实例关闭后，切换步骤跟单节点dg基本一致。
3.standby logfile问题
如果采用LGWR传输日志，需要备库端添加standby logfile日志。需要注意添加的standby logfile的thread要与主库一致。如果你的主库节点有3个实例，那需要添加3大组与rac主库相同thread号的备用日志，每个thread 至少2组日志即可。
1.思路及等待事件说明
鉴于RAC体系的复杂性，RAC的优化比单实例的优化给我们提出了更高的难度和要求。大部分情况下，单实例上的优化方法在RAC结构下同样适用。
RAC优化的2个核心问题:
(1).减少shared pool的压力:减少对数据字典的争用，减少硬解析。
因为row cache/library cache是全局的，频繁的数据字典争用/硬解析在RAC环境下会造成比单实例更严重的性能后果。
(2).减少因Cache fusion带来的全局块传输和争用
频繁的Cache fusion会带来一系列数据块上的全局争用。如何减少逻辑读，减少数据在实例之间共享传输，是RAC体系对应用设计和部署的新要求
Cache fusion性能是影响RAC系统性能的一个极为重要的方面。Avg global cache cr block receive time和avg global cache current block receive time是cache fusion的两个重要指标，以下是oracle给出的这两个指标的阈值情况:
|
Name |
Lower Bound |
Typical |
Upper Bound |
|
Avg global cache cr block receive time(ms) |
0.3 |
4 |
12 |
|
Avg global cache current block receive time(ms) |
0.3 |
8 |
30 |
RAC下的全局等待事件:
SQL>select * from v$event_name where NAME like ‘gc%’ and WAIT_CLASS=’Cluster’;
10G R2下有40多个非空闲的全局等待时间，最常见的值得引起注意的等待事件如下：
gc current/cr request
该等待事件表示资源从远程实例读取到本地实例所花费的时间。出现该事件并不能说明什么问题，如果等待时间过长，可能表示内联网络存在问题或者有严重的块争用。
gc buffer busy
buffer busy waits在全局上的延伸。出现该等待时间一般可能是块的争用问题。
Enquenue类
RAC中，常见的Enquenue有enq: HW – contention/ enq: TX - index contention/enq等，在跨节点高并发的insert环境中很容易出现。
诸如gc current-2way/3way.gc current/cr grant等事件，这些事件只是提供了块传输和消息传输方面的细节或是结果，一般情况下无需太投入关注。
2.性能诊断
性能上的调整很难给出一个定式，但指导思想上可以实现很大方面的统一。
AWR/ASH等报告可以作为RAC系统中一个强有力的性能采集和诊断工具。同单实例的报告相比，AWR中的RAC Statistics部分给我们提供了详细的GES、GCS性能采样，结合全局等待事件，定位集群问题上的症状。
在RAC结构下，Segment Statistics部分是我们更加需要注意的地方。如果你还是习惯使用STATSPACK来进行性能采集，建议至少将收集级别设置为7。该部分为我们提供了详细的Segment级别的活动情况，有助于我们定位全局的HOT table /HOT index，分析全局资源排队争用的根源。
要重视DBA_HIS开头的一系列视图的作用，这将帮我们将问题定位的更加细化，甚至定位到SQL级别。糟糕的SQL效率拖垮系统性能的案例比比皆是，这在RAC中往往更加常见。dba_hist_active_sess_history 可以作为很好的切入点，例如通过关联dba_hist_sqltext获得执行文本，通过关联dba_hist_sql_plan获得执行计划树等，有时候将直接找到造成等待事件的元凶。
① Sequence and index contention
Sequence是RAC中容易引起争用的一个地方,尤其是以sequence作索引，在高并发的多节点insert情况下极易引起索引块的争用以及CR副本的跨实例传输。
需要尽量增大Sequence的cache值并设置序列为noorder。
② undo block considerations
RAC下CR的构造比单实例成本要高，如果一个block中的活动事务分布在几个实例上，需要将几个实例上的undo合并构造所需要的CR，尤其是高并发的有索引键的插入，容易造成undo block的争用。
尽量使用小事务处理。
③HW considerations
跨节点的高并发insert会造成高水位线的争用，采用更大的extent/采用ASSM和分区技术能减缓这一争用。
③ Hot Block
全局热点块问题对RAC系统的影响巨大，尽量减少块跨实例的并发更改,适当采用分区可以缓解该争用。
一个良好的应用设计是RAC发挥功力的重要前提，根据不同的节点部署不同的应用，能有效的减少全局资源的争用，对RAC性能的稳定也相当重要。