ClusterWare笔记

四.  Oracle Real Application Clusters
4.1 什么是Oracle RAC？
(图)
4.1.2 Oracle RAC 并发
RAC 的本质是一个数据库，运行在多台服务器上的数据库，它的主要任务是数据库就是事务处理，它通过 Distributed Lock Management(DLM:分布式

锁管理器) 来解决并发问题。
因为RAC的资源是共享的，为了保证数据的一致性，就需要使用DLM来协调实例间对资源的竞争访问。
RAC 的DLM 就叫作 Cache Fusion。

在DLM 中，根据资源数量，活动密集程度，把资源分成两类：Cache Fusion和Non-Cache Fusion。
Cache Fusion Resource指数据块这种资源，包括普通数据块，索引数据块，段头块(Segment Header),undo 数据块。
Non-Cache Fusion Resource是所有的非数据库块资源, 包括数据文件，控制文件，数据字典，Library Cache，share Pool的Row Cache等。

data dictionary cache: 保存data dictionary. 但是这里要注意，这个区域它里面数据保存是按row来保存的，而不是buffer（即保存这个data

block），所以这个区域也叫row cache。
在Cache Fusion中，每一个数据块都被映射成一个Cache Fusion资源，Cache Fusion 资源实际就是一个数据结构，资源的名称就是数据块地址（DBA）

。每个数据请求动作都是分步完成的。
首先把数据块地址X转换成Cache Fusion 资源名称，然后把这个Cache Fusion 资源请求提交给DLM， DLM 进行Global Lock的申请，释放活动，只有进

程获得了PCM Lock才能继续下一步，即：实例要获得数据块的使用权。
Cache Fusion要解决的首要问题就是：数据块拷贝在集群节点间的状态分布图， 这是通过GRD 实现的。
GRD（Global Resource Directory）

可以把GRD 看作一个内部数据库，这里记录的是每一个数据块在集群间的分布图，它位于每一个实例的SGA中，但是每个实例SGA中都是部分GRD，所有

实例的GRD汇总在一起就是一个完整的GRD
通过GCS 和 GES 进程，在加上GRD 才保证了Cache Fusion运行.
RAC 会根据每个资源的名称从集群中选择一个节点作为它的Master Node，而其他节点叫作Shadow Node。 Master Node 的GRD中记录了该资源在所有节

点上的使用信息，而Shadow Node的GRD中只需要记录资源在该节点上的使用情况，这些信息实际就是PCM Lock信息。

PCM Lock 有3个属性： Mode，Role 和 PI(Past Image)
Oracle RAC Cache Fusion 机制 详解
http://blog.csdn.net/tianlesoftware/article/details/6534239

4.1.3 Oracle RAC 架构
4.1.3.1 SGA 的变化
和传统的单实例相比， RAC Insance的SGA 最显著的变化就是多了一个GRD部分。 Oracle 中的数据操作都是在内存的SGA区完成的，和传统的单实例不

同，RAC 是有多个实例，每个数据块可以在任何一个Instance 的SGA中都有拷贝，RAC必须知道这些拷贝的分布版本，状态，而GRD就是这些信息的内存

区。
GRD 虽然位于SGA中，但是不像Buffer Cache 或者 Log buffer等SGA 组件，有明确的参数来对应，每个节点中都只有部分GRD内容，所有的节点合在一

起才构成完整的GRD.

4.1.3.2 后台进程的变化
4.1.3.2.1  LMSn：Global Cache Service Process
这个进程是Cache Fusion的主要进程，负责数据块在实例间的传递，对应的服务叫作GCS(Global Cache Service), 这个进程的名称来源与Lock

Manager Service。 从Oracle 9开始，Oracle 对这个服务重新命名成Global Cache Service, 但是进程名字确没有调整。
LMS 进程通过GRD的信息来维护数据文件状态和每个cache block的记录。LMS 进程也控制remote instance的message和管理globacl data block，以及

在不同实例之间传输block images。

这个进程的数量是通过参数GCS_SERVER_PROCESSES 来控制。是oracle 实例的参数。
缺省值是1个，取值范围为1-36.(不用改)
For one CPU, there will be one GCS server process.
For 2 - 8 CPUs, there will be 2 GCS server processes.
For more than 8 CPUs, the number of GCS server processes will be equal to the number of CPUs divided by 4. If the result includes a

fraction, the fraction is disregarded. For example, if you had 10 CPUs, then 10/4 would mean 2 GCS processes.

4.1.3.2.2  LMD：Global Enqueue Service Daemon
这个进程负责的是Global Enqueue Service（GES），具体来说，这个进程负责在多个实例之间协调对数据块的访问顺序，保证数据的一致性访问。

4.1.3.2.3  LCK0: Instance Enqueue Process
这个进程负责Non-Cache Fusion 资源的同步访问，

4.1.3.2.4  LMON：Global Enqueue Service Monitor
不同实例的LMON进程会定期通信，进程监控global enqueues和resources的状态，并执行global enquence 的恢复操作，如集群重构，GRD恢复等操作

。
LMON主要借助两种心跳机制来完成健康检查：
1） 节点间的网络心跳（Network Heartbeat）： 可以向节点定时的发送ping包检测节点状态，如果能在规定时间内收到回应，就认为对方状态正常
2） 通过控制文件的磁盘心跳（Controlfile Heartbeat）：每个节点的CKPT进程每隔3秒更新一次控制文件一个数据块，这个数据块叫作Checkpoint

Progress Record，控制文件是共享的，所以实例间可以相互检查对方是否及时更新来判断

4.1.3.2.5  DIAG
DIAG 进程监控实例的健康状态，并在实例出现运行错误时诊断数据记录到alert.log 文件。
4.1.3.2.6  RMSn: Oracle RAC Management Processes (RMSn)
完成对RAC的一些管理任务，比如当一个新的实例加入到集群后，给这个实例创建相关的资源。

4.1.3.2.7  LMHB
LMHB：Global Cache/Enqueue Service Heartbeat Monitor。Monitor the heartbeat of LMON, LMD, and LMSn processes  to ensure they are

running normally without blocking or spinning.
LMHB进程负责监控LMON、LMD、LMSn等RAC关键的后台进程，保证这些background process不被阻塞或spin。
日志目录
cd /u01/oracle/diag/rdbms/dave/dave1/trace
ll dave*lmhb*

按照 100s -> 80s -> 100s -> 80s的间隔监控并输出一次LMSn、LCKn、LMON、LMD等进程的状态及wait chain，
大约每3分钟（5秒）输出一次TOP CPU User，CPU使用率高的session信息: 
如果发现有session的CPU使用率极高，根据内部算法可能会激活 资源计划(resource management plan) ，甚至于kill 进程。

4.1.3.3 RAC下文件存放位置
4.1.3.3.1 spfile （RAC环境下，必须放在ASM上）
4.1.3.3.2 Redo Thread  （RAC环境下，Redo Log必须放在ASM上）

RAC 环境下有多个实例，每个实例都需要有自己的一套Redo log 文件来记录日志。这套Redo Log 就叫作一个Redo Thread，其实单实例下也是Redo

Thread，只是Thread 这个词很少被提及，每个实例一套Redo Thread的设计就是为了避免资源竞争造成性能瓶颈。

Redo Thread有两种：
一种是Private 的，创建语法： alter database add logfile .. Thread n;
另一种是public，创建语法：alter database add logfile...; 
RAC 中每个实例都要设置thread 参数，该参数默认值为0. 如果设置了这个参数，则实例启动时，会使用等于该Thread的Private Redo Thread。如果

没有设置这个参数，则使用缺省值0，启动实例后选择使用Public Redo Thread，并且实例会用独占的方式使用该Redo Thread。

要注意的是，在RAC 环境下，Redo Log Group是在整个数据库级别进行编号的，比如实例1有1，2，3三个日志组，那么实例2的日志组就应该从4开始编

号，不能在使用1，2，3这三个编号。
在RAC 环境下，所有实例的联机日志必须放在共享存储上，
因为如果某个节点异常关闭，剩下的节点要进行Crash Recovery， 执行Crash Recovery的这个节点必须能够访问到故障节点的联机日志，只有把联机

日志放在共享存储上才能满足这个要求。

4.1.3.3.3 Archived Log
1）使用NFS
2）实例间归档（CIA: Cross Instance Archive）
3）使用ASM (建议值)

4.1.3.3.4 Undo Tablespace (可以放在自己节点)

4.1.3.4 SCN(System Change Number)
SCN 是Oracle 用来跟踪数据库内部变化发生的先后顺序的机制，可以把它想象成一个高精度的时钟，每个Redo日志条目，Undo Data Block，Data

Block 都会有SCN 号。 Oracle的Consistent-Read， Current-Read， Multiversion-Block都是依赖SCN 实现。

在RAC中，有GCS 负责全局维护SCN的产生，缺省用的是Broadcast SCN生成算法，该算法大致原理是： 在所有节点间的通信内容中都携带SCN， 每个节

点把接收到的SCN和本机的SCN对比，如果本机的SCN 小，则调整本机的SCN和接收的一致，如果节点间通信不多，还会主动地定期相互通报
还有一个广播算法（Broadcast），这个算法是在每个Commit操作之后，节点要向其他节点广播SCN，虽然这种方式会对系统造成一定的负载，但是确保

每个节点在Commit之后都能立即查看到SCN.

4.1.3.5 Cache Fusion， GCS， GES 关系
Cache Fusion（内存融合）是通过高速的Private Interconnect，在实例间进行数据块传递，它是RAC 最核心的工作机制，它把所有实例的SGA虚拟成

一个大的SGA区。每当不同的实例请求相同的数据块时，这个数据块就通过Private Interconnect 在实例间进行传递。

整个Cache Fusion 有两个服务组成：GCS 和GES。 GCS 负责数据库在实例间的传递，GES 负责锁管理。
LMD：Global Enqueue Service Daemon
LMSn：Global Cache Service Process

4.1.3.6 HAIP（通过多加网卡和私有IP 可以提高 Cache Fusion内存通讯的性能,最多4个）
在没有任何第三方IP故障技术(Bond,IPMP等)的支持下，Grid Infrastructure在11.2.0.2版本开始出现了HAIP特性。
ora.cluster_interconnect.haip资源为Oracle RAC、ORACLE ASM和ORACLE ACFS等通过私网进行内部通信的组件创建1到4个HAIP地址，这些IP地址表现

为169.254.*.*，
安装GI以后，也可以使用oifcfg setif 来添加多个private network interface。
集群中第一个启动的节点上ACTIVE的私有网卡数量决定 HAIP 的地址数量。
就是第一个启动的节点有几个物理网卡，就决定了HAIP的数量了。
如果只有一个激活的private network，那么就只创建一个HAIP.如果有2个，就会创建2个HAIP，如果超过2个激活的私有网卡，那么就会创建4个HAIP。

 

可以通过v$cluster_interconnects 视图查询HAIP的信息：
SQL> select name,ip_address from v$cluster_interconnects;

4.2 管理Oracle RAC的存储
4.2.1 Oracle RAC 对文件存储的要求
Oracle 所有的数据文件（包括每个实例的undo 表空间）和redo log 文件（每个实例至少2个文件），还有SPFILE文件都必须保存在ASM diskgroup上

，因为ASM diskgroup是在共享文件系统上创建的，所以每个节点都可以都必须放在共享设备上的。

4.2.2 OFA 架构概述
Oracle OFA(Optimal Flexible Architecture) 通过设置默认的目录来简化软件的管理工作。 实际上OFA的本质就是一个目录结构。 不同的目录存放

不同的文件，只不过这个目录结构是有它的规则。

4.2.3 Oracle RAC中Redo Log File 的存储 (生产环境必须改)
对于使用administrator-managed 的数据库，每个实例都有自己的online redo log groups。
select thread#,group#,bytes/1024/1024||'M' as sz from v$log order by 1;  --查看

alter database add logfile thread 1 group 5 ('+data') size 50m;
alter database add logfile thread 2 group 6 ('+data') size 50m;
alter database add logfile thread 2 group 8 ('+data', '+data') size 50m;--一次在一个组里加2个文件

4.3 Oracle RAC LoadBalance 说明
LoadBalance 就是把负载平均的分配到集群中的各个节点，从而提高整体的吞吐能力。 Oracle RAC 提供了两种不同的方法来分散负载：
1. 通过Connection Balancing，按照某种算法把用户分配到不同的节点。也可认为是纯技术的分散负载。
2. 通过Service，在应用层上进行分散，也可认为是根据业务的分散负载。

4.3.1 Connection Balancing
Connection Balancing 这种负载均衡是在用户连接这个层次进行的，也就是在用户请求建立连接时，根据每个节点的负载决定把连接分配给哪个实例

，而一旦连接建立之后，会话的所有操作就都在这个实例上完成，而不会再分派给其他节点了。

Connection Balancing 有客户端和服务端两种实现方法。
4.3.2.1 客户端均衡（Client-Side LB）
客户端均衡（Client-Side LB）是Oracle 8i 使用的方法，配置方法是在客户端的tnsnames.ora 文件中加入：LOAD_BALANCE=YES 条目。
RAC =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
    (LOAD_BALANCE = YES)                                       --关键
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = RAC)
      )
    )
  )

4.3.3.2 服务器端均衡（Server-Side LB）  --RAC优化只有2种方法，1增加网卡（最多4个），2业务分离
Server-Side LB 是从Oracle 9i引入的。 它的实现依赖于Listener收集负载信息。
实例启动时PMON进程进行的第一次登记过程叫作Server-register，而后的更新过程叫作service-update。
看lsnrctl status 就可以看见路径，找到trace文件夹可以看到日志
cd /u01/gridbase/diag/tnslsnr/rac1/listener/trace
cat listener.log |grep service_register
cat listener.log |grep service_update

4.3.3.3 两种LB 的配置方法
对于Client-Side LB，需要在客户的tnsnames条目中加入LOAD_BALANCE=YES，
对于Server-side LB，需要配置REMOTE_LISTENER这个参数。
要删除静态注册
SID_LIST_LISTENER_RAC1 =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
      (PROGRAM = extproc)
    )
  )

4.4 Oracle RAC Failover 说明
Oracle RAC 的Failover 可以分为3种：
1. Client-Side Connect time Failover
2. Client-Side TAF
3. Service-Side TAF
注意事项：
不能在listener.ora 文件中设置GLOBAL_NAME， 因为这个参数会禁用Connect-time Failover 和 Transparent Application Failover.

4.4.1 Client-Side Connect Time Failover
RAC =
  (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
     (LOAD_BALANCE=ON)
      (
  CONNECT_DATA=
      (SERVER=DEDICATED)
  (SERVICE_NAME=RAC)
      )
    )

4.4.2 Client-Side TAF(Transparent Application Failover)
所谓TAF，就是连接建立以后，应用系统运行过程中，如果某个实例发生故障，连接到这个实例上的用户会被自动迁移到其他的健康实例上。
对于应用程序而言，这个迁移过程是透明的，不需要用户的介入，当然，这种透明要是有引导的，因为用户的未提交事务会回滚。
TAF 的配置也很简单，只需要在客户端的tnsnames.ora中添加FAILOVER_MODE配置项。这个条目有4个子项目需要定义。

RAC =
  (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
      (LOAD_BALANCE=YES)
      (
 CONNECT_DATA=
     (SERVER=DEDICATED)
 (SERVICE_NAME=RAC)
 (
    FAILOVER_MODE=
(TYPE=session)
(METHOD=basic)
(RETRIES=180)
(DELAY=5)
 )
      )
    )

1. METHOD: 用户定义何时创建到其实例的连接，有BASIC 和 PRECONNECT 两种可选值。
BASIC： 是指在感知到节点故障时才创建到其他实例的连接。
PRECONNECT: 是在最初建立连接时就同时建立到所有实例的连接，当发生故障时，立刻就可以切换到其他链路上。(默认选择)

2. TYPE： 用于定义发生故障时对完成的SQL 语句如何处理，其中有2种类型：session 和select.(默认session)
这2种方式对于未提交的事务都会自动回滚，区别在于对select 语句的处理，对于select，用户正在执行的select语句会被转移到新的实例上，在新的

节点上继续返回后续结果集，而已经返回的记录集则抛弃。
假设用户正在节点1上执行查询，整个结果集共有100条记录，现在已从节点1上返回10条记录，这时节点1宕机，用户连接被转移到节点2上，如果是

session模式，则需要重新执行查询语句；
如果是select方式，会从节点2上继续返回剩下的90条记录，而已经从节点1返回的10条记录不会重复返回给用户，对于用户而言，感受不到这种切换。

3. DELAY 和 RETRIES: 这2个参数分别代表重试间隔时间和重试次数。

4.4.3 Service-Side TAF
4.4.3.1 用srvctl 命令配置Service

#Srvctl add service -d -s -r "preferred-instance-list" -a "available-instance-list" -P
其中TAF-Policy可选：basic 和 preconnect。

-e        Failover type (NONE, SESSION, or SELECT)
-m      Failover method (NONE or BASIC)
-w              Failover delay
-z              Failover retries

例如：(用oracle用户)
srvctl add service -d dave -s dave_taf -r "dave1" -a "dave2" -P basic -e select -m basic -w 5 -z 180
srvctl add service -d dave -s dave_taf -g dave_taf_pool -r "dave1" -a "dave2" -P basic -e select -m basic -w 5 -z 180

4.4.3.1.2 查看配置信息
#srvctl config service -d database-name [-s service-name] [-a]
例如
srvctl config service -d dave

4.4.3.1.3 是否自动运行service
数据库启动时，会自动启动所有的Service。有时为了为了维护需要，需要禁用这个特性，在维护完成后再启动这个特性。
#srvctl enable/disable service -d database-name -s service-name -i instance-name

4.4.3.1.4 启动service
#srvctl start service -d -s -i instance-name -o start-option -c connect-string -q
[oracle@rac1 ~]$ srvctl start service -d dave -s dave_taf

4.4.3.1.5 停止service
#srvctl stop service -d -s -i instance-name -c connect-string -q -f

4.4.3.1.6 查看service 状态
#srvctl status service -d -s  service-name -i instance-name -f -v
[oracle@rac1 ~]$  srvctl config service -d dave -s dave_taf

4.4.3.1.7 删除service
#srvctl remove service -d database-name -s service-name -i instance-name [-f]

4.4.3.1.8 查看service 参数：service_names
--这里配置了多个service：
SQL> show parameter service;
NAME         TYPE  VALUE
------------------------------------ ----------- ------------------------------
service_names        string  dave_taf
SQL>

--检查状态
col name format a15 
col failover_method format a11 heading 'METHOD'
col failover_type format a10 heading 'TYPE'
col failover_retries format 9999999 heading 'RETRIES'
col goal format a10
col clb_goal format a8
col AQ_HA_NOTIFICATIONS format a5 heading 'AQNOT'
select name, failover_method, failover_type, failover_retries,goal, clb_goal,aq_ha_notifications from dba_services where service_id

= 3;

NAME  METHOD     TYPE RETRIES GOAL    CLB_GOAL AQNOT
--------------- ----------- ---------- -------- ---------- -------- -----
dave_taf BASIC     SELECT     180 NONE    LONG     NO

SQL>

在客户端TNS 配置：
orcl=
(DESCRIPTION =
  (ADDRESS_LIST =
    (LOAD_BALANCE = yes)
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.16.201)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.16.203)(PORT = 1521))
  )

  (CONNECT_DATA =
       (SERVER=DEDICATED)
       (SERVICE_NAME = dave_taf)
  )
)

SQL> select sid from v$mystat where rownum=1;
       SID
----------
       146
      
SQL> select failover_type,failover_method,failed_over from v$session where sid=146;
FAILOVER_TYPE FAILOVER_M FAILED_OVE
------------- ---------- ----------      
SELECT        BASIC      YES

4.5 RAC 日志体系说明
(图)
Oracle 11g Clusterware log的目录如下图
[grid@rac1 log]$ pwd
/u01/gridsoft/11.2.0/log
[grid@rac1 log]$ ll
total 12
drwxr-xr-x  2 grid oinstall 4096 May  5 13:54 crs
drwxrwx--T  5 grid asmadmin 4096 May  6 03:36 diag
drwxr-xr-t 25 root oinstall 4096 May  5 14:02 rac1
[grid@rac1 log]$ cd rac1
[grid@rac1 rac1]$ ll
total 172
drwxr-xr-x 3 root root      4096 May  5 14:02 acfs
drwxr-x--- 2 grid oinstall  4096 May  5 14:00 acfslog
drwxr-x--- 2 grid oinstall  4096 May  5 14:00 acfsrepl
drwxr-x--- 2 root oinstall  4096 May  5 14:00 acfsreplroot
drwxr-xr-x 2 root oinstall  4096 May  5 14:00 acfssec
drwxr-x--- 2 grid oinstall  4096 May  5 14:00 admin
drwxrwxr-t 4 root oinstall  4096 May  5 14:00 agent
-rw-rw-r-- 1 grid oinstall 74221 May 10 02:20 alertrac1.log
drwxrwxrwt 2 grid oinstall  4096 May 10 02:22 client
drwxr-x--- 2 root oinstall  4096 May  5 14:05 crflogd
drwxr-x--- 2 root oinstall  4096 May  5 14:05 crfmond
drwxr-x--- 2 root oinstall  4096 May  5 14:03 crsd
drwxr-x--- 2 grid oinstall  4096 May  5 14:02 cssd
drwxr-x--- 2 root oinstall  4096 May  9 17:48 ctssd
drwxr-x--- 4 grid oinstall  4096 May  5 14:00 cvu
drwxr-x--- 2 grid oinstall  4096 May  5 14:00 diskmon
drwxr-x--- 2 grid oinstall  4096 May  5 14:06 evmd
drwxr-x--- 2 grid oinstall  4096 May 10 01:25 gipcd
drwxr-x--- 2 root oinstall  4096 May  5 14:00 gnsd
drwxr-x--- 2 grid oinstall  4096 May  9 12:53 gpnpd
drwxr-x--- 2 grid oinstall  4096 May  5 14:02 mdnsd
drwxr-x--- 2 root oinstall  4096 May  9 12:52 ohasd
drwxrwxr-t 5 grid oinstall  4096 May  5 14:58 racg
drwxr-x--- 2 grid oinstall  4096 May  5 14:00 srvm
[grid@rac1 rac1]$

如果RAC出现问题，其中最优先要看的是alertrac1.log文件。

4.6 RAC 维护工具总结
Oracle Clusterware的命令集可以分4种：
节点层：olsnodes
网络层：oifcfg
集群层：crsctl, ocrcheck,ocrdump,ocrconfig
应用层：srvctl,onsctl,crs_stat

4.6.1 节点层
[grid@rac1 rac1]$ olsnodes
rac1
rac2
[grid@rac1 rac1]$ olsnodes -h
Usage: olsnodes [ [-n] [-i] [-s] [-t] [ | -l [-p]] | [-c] ] [-g] [-v]
 where
  -n print node number with the node name
  -p print private interconnect address for the local node
  -i print virtual IP address with the node name
   print information for the specified node
  -l print information for the local node
  -s print node status - active or inactive
  -t print node type - pinned or unpinned
  -g turn on logging
  -v Run in debug mode; use at direction of Oracle Support only.
  -c print clusterware name

[grid@rac1 rac1]$

4.6.2 网络层(注意，RAC中网卡名称一定要一样，否则不能安装成功)
oifcfg 命令用来定义和修改Oracle 集群需要的网卡属性，这些属性包括网卡的网段地址，子网掩码，接口类型等。
oifcfg 命令的格式如下：interface_name/subnet:interface_type
iflist：显示网口列表
getif: 获得单个网口信息
setif：配置单个网口
delif：删除网口
[grid@rac1 rac1]$ oifcfg -h

Name:
 oifcfg - Oracle Interface Configuration Tool.

Usage:  oifcfg iflist [-p [-n]]
 oifcfg setif {-node | -global} {/:}...
 oifcfg getif [-node | -global] [ -if [/] [-type ] ]
 oifcfg delif {{-node | -global} [[/]] [-force] | -force}
 oifcfg [-help]

  - name of the host, as known to a communications network
   - name by which the interface is configured in the system
    - subnet address of the interface
   - type of the interface { cluster_interconnect | public }

[grid@rac1 rac1]$

--查看网口列表 
[grid@rac1 rac1]$ oifcfg iflist
eth0  192.168.16.0
eth1  192.168.1.0
eth1  169.254.0.0                  (11G的新特性HAIP 169.254.0.0)
[grid@rac1 rac1]$

--查看每个网卡的属性：
[grid@rac1 rac1]$ oifcfg getif
eth0  192.168.16.0  global  public
eth1  192.168.1.0  global  cluster_interconnect
[grid@rac1 rac1]$

--删除接口配置
[root@rac1 ~]# oifcfg delif -global

-- 添加接口配置
[root@rac1 ~]# oifcfg setif -global eth0/192.163.1.0:public
[root@rac1 ~]# oifcfg setif -global eth1/10.82.10.0:cluster_interconnect

4.6.3 集群层
这一层共有4个命令：crsctl, ocrcheck,ocrdump,ocrconfig. 后三个是针对OCR 磁盘的。
4.6.3.1 CRSCTL
[grid@rac1 rac1]$ crsctl -h
Usage: crsctl add       - add a resource, type or other entity
       crsctl check     - check a service, resource or other entity
       crsctl config    - output autostart configuration
       crsctl debug     - obtain or modify debug state
       crsctl delete    - delete a resource, type or other entity
       crsctl disable   - disable autostart
       crsctl discover  - discover DHCP server
       crsctl enable    - enable autostart
       crsctl get       - get an entity value
       crsctl getperm   - get entity permissions
       crsctl lsmodules - list debug modules
       crsctl modify    - modify a resource, type or other entity
       crsctl query     - query service state
       crsctl pin       - pin the nodes in the node list
       crsctl relocate  - relocate a resource, server or other entity
       crsctl replace   - replaces the location of voting files
       crsctl release   - release a DHCP lease
       crsctl request   - request a DHCP lease
       crsctl setperm   - set entity permissions
       crsctl set       - set an entity value
       crsctl start     - start a resource, server or other entity
       crsctl status    - get status of a resource or other entity
       crsctl stop      - stop a resource, server or other entity
       crsctl unpin     - unpin the nodes in the node list
       crsctl unset     - unset an entity value, restoring its default
[grid@rac1 rac1]$

4.6.3.1.1 检查CRS 状态
[grid@rac1 rac1]$ crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
[grid@rac1 rac1]$

4.6.3.1.2 配置CRS是否自启动
CRS 进程栈默认随着操作系统的启动而自启动，有时出于维护目的需要关闭这个特性，可以用root 用户执行下面命令。
[root@rac1 root]# crsctl disable crs
[root@rac1 root]# crsctl enable crs

4.6.3.1.3 启动，停止CRS
-- 启动CRS：
[root@raw1 bin]# ./crsctl start crs

-- 关闭CRS：
[root@raw1 bin]# ./crsctl stop crs

4.6.3.1.4 查看Votedisk 磁盘位置
[root@rac1 root]# crsctl query css votedisk

4.6.3.2 OCR命令系列
4.6.2.3.1 ocrdump
4.6.2.3.2 ocrcheck
4.6.2.3.2 ocrconfig  (备份，还原)

4.6.4 应用层
应用层就是指RAC数据库了，这一层有若干资源组成，每个资源都是一个进程或者一组进程组成的完整服务，这一层的管理和维护都是围绕这些资源进

行的。 有如下命令: srvctl, onsctl, crs_stat 三个命令。

4.6.4.1 crs_stat

4.6.4.2 onsctl
这个命令用于管理配置ONS(Oracle Notification Service). ONS 是Oracle Clusterware 实现FAN Event Push模型的基础。
[root@rac1 conf]# pwd
/u01/gridsoft/11.2.0/opmn/conf
[root@rac1 conf]# cat ons.config
usesharedinstall=true
allowgroup=true
localport=6100  # line added by Agent
remoteport=6200  # line added by Agent
nodes=rac1:6200,rac2:6200  # line added by Agent
[root@rac1 conf]#

Localport: 这个参数代表本地监听端口，
Remoteport：这个参数代表的是远程监听端口，
nodes:决定了本地的ONS daemon要和哪些远程节点上的ONS daemon进行通信。
Nodes 参数值格式如下：Hostname/IP:port[hostname/ip:port]
--在OS级别查看进程状态：
[root@rac1 ~]# ps -aef|grep ons
--确认ONS服务的状态：
[root@rac1 ~]# onsctl ping
ons is running ...
[root@rac1 ~]#
--启动ONS服务：
[root@rac1 ~]#onsctl start

4.6.4.3 srvctl
4.6.4.3.1 使用config查看配置
-- 不带任何参数时，显示OCR中注册的所有数据库
[root@rac1 conf]# srvctl config database
dave
[root@rac1 conf]#
-- 使用-d 选项，查看某个数据库配置：
[root@rac1 conf]# srvctl config database -d dave
Database unique name: dave
Database name: dave
Oracle home: /u01/oracle/11.2.0/db_1
Oracle user: oracle
Spfile: +DATA/dave/spfiledave.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: dave
Database instances: dave1,dave2
Disk Groups: DATA,FRA
Mount point paths:
Services: dave_taf
Type: RAC
Database is administrator managed
[root@rac1 conf]#
--查看Node Application的配置
[root@rac1 conf]# srvctl config nodeapps
Network exists: 1/192.168.16.0/255.255.255.0/eth0, type static
VIP exists: /rac1-vip/192.168.16.201/192.168.16.0/255.255.255.0/eth0, hosting node rac1
VIP exists: /rac2-vip/192.168.16.203/192.168.16.0/255.255.255.0/eth0, hosting node rac2
GSD exists
ONS exists: Local port 6100, remote port 6200, EM port 2016
[root@rac1 conf]#
--查看Listener：
[root@rac1 conf]# srvctl config listener
Name: LISTENER
Network: 1, Owner: grid
Home:
End points: TCP:1521
[root@rac1 conf]#
--查看ASM：
[root@rac1 conf]# srvctl config asm
ASM home: /u01/gridsoft/11.2.0
ASM listener: LISTENER
[root@rac1 conf]#

4.6.4.3.2 使用add 添加对象
1） 添加数据库
[root@raw1 bin]# ./srvctl add database -d dave -o $ORACLE_HOME

2)  添加实例
[root@raw1 bin]# ./srvctl add instance -d dave -n rac1 -i dave1
[root@raw1 bin]# ./srvctl add instance -d dave -n rac2 -i dave2

3) 添加服务，需要使用4个参数
-s : 服务名
-r：首选实例名
-a：备选实例名
-P：TAF策略，可选值为None（缺省值），Basic，preconnect。
[root@rac1 ~]# srvctl add service -d dave -s daveservice -r dave1 -a dave2 -P BASIC

4) 确认添加成功
[root@raw1 bin]# ./srvctl config service -d dmm -s dmmservice -a

4.6.4.3.3 使用enable/disable 启动，禁用对象
-- 启用数据库的自启动：
[root@rac1 ~]# srvctl enable database -d dave

-- 禁止数据库在CRS启动后自启动，这时需要手动启动
[root@rac1 ~]# srvctl disable database -d dave

--使用如下命令查看：
[root@rac1 ~]# srvctl config database -d dave -a -v

4.6.4.3.4 使用remove 删除对象
--删除数据库
[root@rac1 ~]# srvctl remove database -d dave

4.6.4.3.5 启动，停止对象
--启动数据库，默认启动到open状态：
[root@raw1 bin]# ./srvctl start database -d dave

--关闭对象，并指定关闭方式：
[root@rac1 ~]# srvctl stop instance -d dave -i dave1 -o immediate

4.7 如何修改RAC 的 IP 地址？
[root@rac1 conf]# cat /etc/hosts
127.0.0.1   localhost

192.168.16.200 rac1 rac1-public
192.168.1.100 rac1-priv
192.168.16.201 rac1-vip

192.168.16.202 rac2 rac2-public
192.168.1.200 rac2-priv
192.168.16.203 rac2-vip

192.168.16.254 rac-scan
[root@rac1 conf]#

4.7.2.1 备份OCR 和GPNP profile 文件
[root@rac1 rac-cluster]# ocrconfig -manualbackup
GPNP Profile
用grid用户执行：
$ cd $GRID_HOME/gpnp//profiles/peer/
$ cp -p profile.xml profile.xml.bk

4.7.2.2 关闭所有的crs资源，仅保留crs的后台进程
--查看RAC资源当前状态：
[root@rac1 u01]# crs_stat -t

--停止相关资源：
[root@rac1 u01]# srvctl stop database -d dave
[root@rac1 u01]# srvctl stop listener
[root@rac1 u01]# srvctl stop scan_listener
[root@rac1 u01]# srvctl stop scan
[root@rac1 u01]# srvctl stop cvu
[root@rac1 u01]# srvctl stop nodeapps -n rac1
[root@rac1 u01]# srvctl stop nodeapps -n rac2

--检查资源状态：
[root@rac2 ~]# crs_stat -t

4.7.2.3 修改public IP地址
-- 查看当前配置：
[root@rac1 u01]# su - grid
[grid@rac1 ~]$ oifcfg getif -global
eth0  192.162.3.0  global  public
eth1  192.163.1.0  global  cluster_interconnect

--改变public IP信息:
----删除public配置
[grid@rac1 ~]$ oifcfg delif -global eth0
----添加public 配置
[grid@rac1 ~]$ oifcfg setif -global eth0/192.163.3.0:public
注意： 这里IP 地址最一个为0.  代表的是一个网段。
修改的时候要切记。 否在在启动OCR 时 会报如下错误：
 [  CRSOCR][4054413904] OCR context init failure.  Error: PROC-44: 网络地址和网络接口操作中出错 网络地址和网络接口操作错误 [7]

--确认
[grid@rac1 ~]$ oifcfg getif -global
eth0  192.163.3.0  global  public
eth1  192.163.1.0  global  cluster_interconnect

4.7.2.4 用grid用户修改VIP 地址
4.7.2.4.1 查看当前的VIP 信息
[root@rac1 /]# srvctl config nodeapps -a

--验证VIP的状态：
$ crsctl stat res -t
4.7.2.4.2 用root用户修改VIP 信息

# srvctl modify nodeapps -n -A //<[if1[if2...]]>

[root@rac1 /]# srvctl modify nodeapps -n rac1 -A 192.163.3.151/253.253.253.0/eth0
[root@rac1 /]# srvctl modify nodeapps -n rac2 -A 192.163.3.153/253.253.253.0/eth0

4.7.2.4.3 验证
[root@rac1 /]# srvctl config nodeapps -a
Network exists: 1/192.163.3.0/253.253.253.0/eth0, type static
VIP exists: /rac1-vip/192.163.3.151/192.163.3.0/253.253.253.0/eth0, hosting node rac1
VIP exists: /rac2-vip/192.163.3.153/192.163.3.0/253.253.253.0/eth0, hosting node rac2

4.7.2.5 修改private IP地址
--确认网卡配置：
[root@rac1 /]# oifcfg getif -global
eth0  192.163.3.0  global  public
eth1  192.163.1.0  global  cluster_interconnect

----删除Private配置
[grid@rac1 ~]$ oifcfg delif -global eth1
PRIF-31: Failed to delete the specified network interface because it is the last private interface
[grid@rac1 ~]$
在11.2.0.2 以后的版本，我们无法直接删除最后一个private IP，如果要删除，必须先添加一个。 然后重启CRS,在删除旧的信息private 信息即可。

4.7.2.5.1 确认网卡配置
[grid@rac1 ~]$ oifcfg getif -global
eth0  192.163.3.0  global  public
eth1  192.163.1.0  global  cluster_interconnect

4.7.2.5.2 用grid用户添加一个新的private 配置
[grid@rac1 ~]$ oifcfg setif -global eth1/192.162.3.0:cluster_interconnect

这里的网卡名称若相同，则网段必须不同。

--验证：
[grid@rac1 ~]$ oifcfg getif -global
eth1  192.163.1.0  global  cluster_interconnect
eth0  192.163.3.0  global  public
eth1  192.162.3.0  global  cluster_interconnect

4.7.2.6 修改RAC SCAN IP
--查看scan状态：
[root@rac1 ~]# srvctl config scan
SCAN name: rac-scan, Network: 1/192.163.3.0/253.253.253.0/eth0
SCAN VIP name: scan1, IP: /rac-scan/192.162.3.253

--准备修改：
$srvctl stop scan_listener
$srvctl stop scan
$srvctl status scan

--根据我们/etc/hosts中的修改：
192.163.3.253 rac-scan

--用root进行修改：
[root@rac1 ~]# srvctl modify scan -n rac-scan
--检查修改结果：

[root@rac1 ~]# srvctl config scan
SCAN name: rac-scan, Network: 1/192.163.3.0/253.253.253.0/eth0
SCAN VIP name: scan1, IP: /rac-scan/192.163.3.253

注意：
与修改private ip ，vip 不一样，修改scan ip 无需停止数据库实例，asm 或者重启crs，相对比较简单。

4.7.2.7 用root停止所有节点上的clusterware并禁止其自启动
[root@rac1 u01]# crsctl stop crs
[root@rac1 u01]# crsctl disable crs

4.7.2.8 修改操作系统上的网络配置
这里的修改包括/etc/hosts 文件和网卡的相关信息，修改完之后，重启网络服务。
vim /etc/sysconfig/network-scripts/ifcfg-eth1
vim /etc/sysconfig/network-scripts/ifcfg-eth0
[root@rac1 network-scripts]# service network restart

4.7.2.9 在所有节点用root用户enable并启动clusterware

[root@rac1 /]# crsctl enable crs
CRS-4622: Oracle High Availability Services autostart is enabled.
[root@rac1 /]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.
[root@rac1 /]#

4.7.2.10 删除旧的Private 配置信息并确认Private 修改成功
[grid@rac1 ~]$ oifcfg delif -global eth1/192.163.1.0

--确认添加成功：
[root@rac2 ~]# oifcfg getif -global
eth0  192.163.3.0  global  public
eth1  192.162.3.0  global  cluster_interconnect

4.7.2.11 检查所有进程的状态

[root@rac1 /]# srvctl start listener
[root@rac1 /]# srvctl start scan
[root@rac1 /]# srvctl start cvu

4.8 Oracle RAC的备份与恢复
4.8.1 RAC 归档设置说明
archive log list
4.8.1.2.1 设置归档参数
SQL> alter system set log_archive_dest_1 = 'LOCATION=+FRA' scope=both sid='*';
SQL> alter system set cluster_database=false scope=spfile sid='*';
SQL> startup mount
SQL> alter database archivelog;
Database altered.

4.8.2 RAC 的RMAN 备份
4.8.3.1 归档文件的删除问题
--如果归档不在FRA里面，需要配置2个通道连接2个节点
RMAN> configure channel 1 device type disk connect 'sys/oracle@orcl1';
RMAN> configure channel 2 device type disk connect 'sys/oracle@orcl2';
配置完之后，就可以删除归档文件：
RMAN> crosscheck archivelog all;
RMAN> delete archivelog all;

4.8.3 RAC 的RMAN 恢复
4.8.3.1 先停止数据库
 
[oracle@rac1 bin]$ srvctl stop db -d dave
[oracle@rac1 bin]$ crs_stat -t

4.8.3.2 将节点启动到mount 状态
RMAN> startup mount;

4.8.3.3 完全恢复
--如果归档在ASM磁盘组上的话就不需要分配通道
RMAN> RUN {
#allocate channel c1 device type disk connect  'sys/123456@orcl1';
#allocate channel c2 device type disk connect  'sys/123456@orcl2';
restore database;
recover database;
}

4.9 最常见的导致 RAC 实例崩溃的几个问题
4.9.1  ORA-29770 LMHB 终止实例 -- 11gR2
LMON (ospid: 31216) waits for event 'control file sequential read' for 88 secs.
Errors in file /oracle/base/diag/rdbms/prod/prod3/trace/prod3_lmhb_31304.trc (incident=2329):
ORA-29770: global enqueue process LMON (OSID 31216) is hung for more than 70 seconds
LMHB (ospid: 31304) is terminating the instance.
或
LMON (ospid: 8594) waits for event 'control file sequential read' for 118 secs.
ERROR: LMON is not healthy and has no heartbeat.
ERROR: LMHB (ospid: 8614) is terminating the instance.

LMON 等待读取控制文件，导致LMHB 使实例崩溃。
Bug 11890804 LMHB crashes instance with ORA-29770 after long "control file sequential read" waits

4.9.2 ORA-481 导致的实例崩溃 -- 11gR2
1. PMON (ospid: 12585): terminating the instance due to error 481
LMON 进程跟踪文件显示:
Begin DRM(107) (swin 0)
* drm quiesce

LMS 2011-07-05 10:53:44.218905 : Start affinity expansion for pkey 81883.0
2011-07-05 10:53:44.498923 : Expand failed: pkey 81883.0, 229 shadows traversed, 153 replayed 1 retries

2. PMON (ospid: 4915562): terminating the instance due to error 481
Sat Oct 01 19:21:37 2011
System state dump requested by (instance=2, osid=4915562 (PMON)), summary=[abnormal instance termination].

--DRM的全称是Dynamic Resource Mastering

在RAC环境中，Oracle使用GRD（Global Resource Service）来记录各个RAC节点的资源信息，具体通过GCS（Global Cache Service）和GES（Global

Enqueue Service）这两个服务进行管理。

由于在RAC中每个节点都有自己的SGA和buffer cache，为了保证Cache资源的一致性和提高性能，GCS和GES会指定RAC中的一个instance来管理Cache，

这个节点这时就是Resource Master。

在10g以前，Cache资源是不能在各个节点间移动的，除非重启或者某节点因为其他异常被RAC驱逐等情况。而10g的DRM就解决了这个问题，它可以保证

cache能够被remaster到频繁访问这部分数据的节点上，从而提高RAC的性能。

根据metalink确认，该问题确实由DRM机制引起，最终解决方案，使用隐含参数，将DRM特性屏蔽：
_gc_affinity_time=0  
_gc_undo_affinity=FALSE 

这2个参数是静态参数，也就是说必须要重启实例才能生效。
--生产库要关闭DRM

4.9.3 ORA-600[kjbmprlst:shadow]、ORA-600[kjbrref:pkey]、ORA-600[kjbmocvt:rid]、[kjbclose_remaster:!drm]、ORA-600 [kjbrasr:pkey] 导致

的实例崩溃 -- 11gR2
--600错误大多是BUG，去MOS搜索。
这一组 ORA-600 与 DRM（dynamic resource remastering）消息或 read mostly 锁有关。涉及多个 bug，包括：
Document 9458781.8 Missing close message to master leaves closed lock dangling crashing the instance with assorted Internal error
Document 9835264.8 ORA-600 [kjbrasr:pkey] / ORA-600 [kjbmocvt:rid] in RAC with dynamic remastering
Document 10200390.8 ORA-600[kjbclose_remaster:!drm] in RAC with fix for 9979039
Document 10121584.8 ORA-600 [kjbmprlst:shadow] can occur in RAC
Document 11785390.8 Stack corruption / incorrect behaviour possible in RAC
Document 12408350.8 ORA-600 [kjbrasr:pkey] in RAC with read mostly locking
Document 12834022.8 ORA-600 [kjbmprlst:shadow] / ORA-600 [kjbrasr:pkey] with RAC read mostly locking

4.9.4 启用flash cache后产生kcldle/kclfplz/kcbbxsv_l2/kclfprm，导致实例崩溃 -- 11gR2
警报日志中报告了 ORA-7445[kcldle]
ORA-7445[kclfplz]
ORA-7445[kcbbxsv_12]
ORA-744[kclfprm]

它们是由不同的 bug 引起的，而这些bug都归结为 基础bug Bug 12337941 Dumps on kcldle / kclfplz / kcbbxsv_l2 / kclfprm using flash

4.9.5 LMS 报 ORA-600 [kclpdc_21]错误，实例崩溃 -- 11gR2
警报日志中报告了 ORA-600[kclpdc_21]
Document 10040033.8  LMS gets ORA-600 [kclpdc_21] and instance crashes

4.9.6 10.2.0.5 的问题
1. LMS进程 报 ORA-600[kjccgmb:1]错误导致实例崩溃， LMS 2. 由于以下原因导致实例崩溃：
Received an instance abort message from instance 2 (reason 0x0)
Please check instance 2 alert and LMON trace files for detail.
LMD0: terminating instance due to error 481
1. Bug 11893577 - LMD CRASHED WITH ORA-00600 [KJCCGMB:1]
2. Bug 9577274 - 1OFF:UNABLE TO VIEW REQUEST OUTPUT AND LOG AFTER APPLYING FIX TO ISSUE IN BUG 9400041

4.10 导致实例逐出的几个问题
4.10.1 警报日志显示 ora-29740 实例崩溃/驱逐的原因
[oracle@rac1 ~]$ oerr ora 29740
29740, 00000, "evicted by instance number %s, group incarnation %s"
// *Cause: This instance was evicted from the group by another instance of the
//         cluster database group for one of several reasons, which may
//         include a communications error in the cluster and failure to issue
//         a heartbeat to the control file.
// *Action: Check the trace files of other active instances in the cluster
//          group for indications of errors that caused a reconfiguration.

此问题的部分原因是集群中的通信错误、向控制文件发送“心跳”失败以及其它原因
a) 网络问题。
b) 资源耗尽（CPU、I/O 等）
c) 严重的数据库争用。
d) Oracle bug。

4.10.2 警报日志在实例崩溃或驱逐前显示“ipc send timeout”错误
实例驱逐时，警报日志显示许多“IPC send timeout”错误。此消息通常伴随数据库性能问题。
在 RAC 中，数据库进程，例如 lmon、lmd 和 lms 会不断地和其他实例的进程通信。lmd0 进程负责管理 enqueue，而 lms 进程负责管理数据块资源

并传输数据块以支持 Cache Fusion。如果这些进程中的一个或多个受阻、死循环或异常繁忙，则可能导致“IPC send timeout（IPC 发送超时）”错

误。
lmon、lms 和 lmd 进程报告“IPC send timeout”错误的另一个原因是网络问题或服务器资源（CPU 和内存）问题。这些进程可能无法获得 CPU 运行

调度或这些进程发送的网络数据包丢失。
涉及 lmon、lmd 和 lms 进程的通信问题导致实例驱逐。被驱逐实例的警报日志显示的信息类似于如下示例
IPC Send timeout detected.Sender: ospid 1519
Receiver: inst 8 binc 997466802 ospid 23309
如果某实例被驱逐，警报日志中的“IPC Send timeout detected（检测到 IPC 发送超时）”通常伴随着其它问题，如 ora-29740 和“Waiting for

clusterware split-brain resolution（等待集群件“脑裂”解决方案）”
OSW

4.10.3：在实例崩溃或驱逐前，问题实例处于挂起状态
在执行驱逐其他实例动作的实例警报日志中，您可能会看到与以下消息类似的消息：
Remote instance kill is issued [112:1]:8
或者
Evicting instance 2 from cluster

4.10.4：在一个或多个实例崩溃或驱逐前，警报日志显示“Waiting for clusterware split-brain resolution（等待集群“脑裂”解决方案）”
lmon 进程向远程实例发送一个网络 ping，如果远程实例上的 lmon 进程不响应，则出现实例级别的“脑裂”。因此，查找 lmon 不能相互通信的原因

对解决此问题而言非常重要。

常见原因有：
1) 实例级别的“脑裂”通常由网络问题导致，因此检查网络设置和连接非常重要。但是，因为如果网络已关闭，集群件 (CRS) 就会出现故障，所以只

要 CRS 和数据库使用同一网络，则网络不太可能会关闭。  
2) 服务器非常繁忙和/或可用内存量低（频繁的交换和内存扫描），将阻止 lmon 进程被调度。
3) 数据库或实例正处于挂起状态，并且 lmon 进程受阻。
4) Oracle bug
hanganalyze工具分析那个SESSION使得数据库hang住。

4.10.5：另一个实例尝试驱逐问题实例，但由于一些原因未能成功驱逐，最终CRS会终止该问题实例
要求 CRS 终止问题实例的实例警报日志显示
Remote instance kill is issued [112:1]:8

4.11 最常见的导致节点重新启动、驱逐或 CRS 意外重启的几个问题
4.11.1 节点重新启动，但是日志文件未显示任何错误或原因
如果节点重新启动是由于某个 Oracle 进程，但是日志文件没有显示任何错误，则故障位置为 oprocd、cssdmonitor 和 cssdagent 进程。当节点挂起

一段时间或者一个或多个关键 CRS 进程无法被调度获得 CPU 时，会发生这种情况。因为那些进程都以实时优先级运行，所以问题可能是因为内存耗尽

或者可用内存低，而不是因为 CPU 耗尽。也可能是由于内核交换页的工作量繁重或者正忙于扫描内存以标识要释放的页。也可能存在 OS 调度问题。
Hugepage

4.11.2 节点重新启动，该节点是由于丢失网络心跳而被逐出
这是因为丢失网络心跳或 发生了脑裂。在双节点环境中，节点 2 的重复重新启动通常意味着节点 2 由于 脑裂 而被驱逐。在节点重新启动前，

ocssd.log 会显示丢失网络心跳或一条脑裂消息。

4.11.3 在出现存储问题后节点重新启动
ocssd.log 文件显示节点因为无法访问大部分 voting disks 而重新启动。
CRS 必须能够访问大部分 voting disks 。如果 CRS 无法正常访问大部分 voting disks ，则 CRS 无法确保群集的一致性，所以 CRS 重新启动节点

。

4.11.4 asm 或数据库实例被挂起或驱逐后节点重新启动
正常运行节点的 ocssd.log 显示一个 member kill 请求升级到了 node kill 请求。

4.11.5 CRS 自动重启，但是节点没有重新启动
从版本 11.2.0.2 开始，如果 CRS 由于此处列出的任何原因而需要重新启动节点，CRS 会在重新启动节点之前尝试先对自身进行重启。仅当它无法成

功重启自身时，CRS 才重新启动节点来强制对自身进行重启。

--总的方法
1.看log  去MOS搜索，如果匹配打补丁。
2.资源  网络、CPU、I/O等  大内存要配置hugepage
[oracle@ogg2 ~]$ vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  30052  58608 143780 1332228    0    0     3    21   43   13  2  2 96  0  0

3. OSW
4. hanganalyze