Oracle RAC

IT界数据库架构师的漂泊人生 2020-12-14

2319

GI 组成

11G 的GI部分跟10G的GI 进步复杂化,单词都不一样了。11G的RAC有一整套进程，代理进程以及配置文件组成。

由高可用服务堆栈和集群就绪服务堆栈两部分组成

高可用性堆栈：由 OHASD进程负责其组成 appagent ,ologgerd,GPNPD,GIPC,mDNS,oraagent,scriptagent,osymond,orarootagent.

集群就绪服务堆栈 CRSD进程负责组成 CRS,CSS,CSSDAGENT,ASM,EVM

,CTSS,ONS,ORAAGENT,ORAROOTAGETN

高可用性堆栈进程介绍:

1 OHASD: 负责本地的OLR

2 GPNPD:提供启动集群必要信息

3 GIPC: 网格进程通讯

4 GNS: 域名服务

5 MDNS: 域名多播服务

6 OSYSMOND:系统监控

7 OLOGGERD: 日志记录服务

CRS堆栈进程

1 CRSD:管理资源启动,停止.维护OCR. CRSD.BIN

2 CSS: 节点成员信息,并维护表决磁盘. OCSSD.BIN

3 CSS代理:CSSDAGENT 启停CSS服务

4 CSS监视:CSSDMONITOR 当OS挂起,CPU饥饿时提供IO保护

5 CTSS:集群时间同步

6 EVM: 集群事件发布

7 ONS: 通知订阅服务

8 ASM: 共享磁盘服务

这两个堆栈有几个重要的进程,其他进程没大意思的. 1 OHASD,2 GPNPD 3GIPC, 4 CRSD,5 CSS 6 CSSAGENT 7 CTSS 8 ASM 9 CSSDMONITOR

启动顺序并非按照上面两个部分,先启动高可用后启动CRS.而是.....

启动顺序分5个层次

第1 层 INIT ==> OHASD 系统启动的时候,调用脚本

/etc/init.d/init.ohasd run >/dev/null......

oracle linux6.x 后 etc/init/oracle-ohasd.conf

启动后进程

ps -ef|grep ohasd|grep -v grep

init.ohasd run

ohasd.bin reboot

这样看出由脚本启动了OHASD 高可用主进程

第2层由OHASD进程启动4个代理进程

2.1 CSSDMONITOR : CSS监视器

2.2 ORAAGENT : ORACLE代理进程

2.3 ORAROOTAGENT :ROOT代理进程

2.4 CSSDAGENT : CSS代理进程

第3层由 2.2 ORAAGETN 代理进程派生5个进程

3.1 MDNSD: MDNS守护进程

3.2GIPCD : 网格进程间通信进程

3.3GPNPD: GPNP配置守护进程

3.4 EVMD: 事件监视器守护进程

3.5 ASM: 监测ASM实例的资源

由2.3 ORAROOTAGENT 进程

3.6 CRSD: CRS守护进程

3.7 CTSSD: CTSS守护进程

3.8 diskmon: 磁盘监视器守护进程

3.9 ACFS: ASM集群文件系统

第4层由2.4 CSSDAGENT 启动CSSD

4.1 CRSD ORAROOTAGENT

4.2 CRSD ORACLEAGENT

第5层启动集群资源了

由 4.1 CRSD ORAROOTAGENT

5.1网络资源

5.2 SCAN IP

5.3 NODE VIP

5.4 ACFS 注册表

5.5 GNS VIP

4.2 CRSD ORAAGENT

5.6 ASM 实例

5.7 磁盘组

5.8 数据库实例

5.9 SCAN监听

5.10 扫描VIP

5.11 数据库服务

5.12 ONS

5.13 EONS

5.14 GSD

5.15 GNS

这样大家可以简单清楚明白了一些进程.如果集群启动后发生了问题,就能大概定位到是什么位置.

另外集群是通过本地的OLR和GPNP完成启动不需要ASM实例上的OCR.

集群管理工具 crsctl -help

crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4638:Cluster Ready Services is online

CRS-4638:Cluster synchronization Services is online

CRS-4638: Event Manager is online

这个集群检查工具一看下就知道三个主要进程是否完成了启动 1 OHAS 2 CRS 3 CSS

mdns 主要为小型私有网络提供域名解析服务,不存在DNS情况下。使用多播技术发布消息。使用UDP协议进行数据传输。对应主机名会以.LOCAL结尾。利用公网和私网进行资源发现活动.

gpnp 会使用mdns提供的节点信息向网络发布自己的信息,同时收索其他节点信息。发现了个节点并把本地的gpnp profile推送过去，成功表示是同一个集群。

gpnp 全称是grid plug and play 进程名为gpnpd.bin 目的于将集群基本信息保存在本地，通过MDNSD进行通信识别集群其他的节点。由gpnp wallet和gpnp profile组成。

这样说来这个进程还是很重要的哦！ gpnpd.bin从gpnp profile配置文件读取集群信息，然后访问MDNS 没有的话访问DNS，再没有的话访问/etc/hosts。

gpnp profile 保存路径在GI_HOME/gpnp/profiles/peer

gpnp主线程完成对gpnp profile的读取；

push 线程当本地profile改变时向远程节点推送;

dispatch线程：消息分发

OCR线程：当OCR发生改变后通知DISPATCH线程。

逻辑链条：OCR->DISPATCH->远程节点（dispatch) ;push->推送到远程节点。

GIPC grid interprocess communaication 以gipcd.bin 该守护进程主要功能是：

1 当集群启动时发现集群的私有网卡并对其检查

2 通过网卡发现其他节点，并建立联系

3 当多个私网的网卡时，如果一块或多块发生故障离线时通知其他节点。

4 负责集群层面的数据通信，比如occsd.bin,网络心跳，crsd.bin。

HAIP 是架构在两个网卡上的负载均衡和高可用。

这个是针对私有网卡进行绑定操作的，目的代替linux bonding ,aix etherchannel.需要11.2.0.2版本。

HAIP 会自己产生特殊的IP地址，绑定在私网网卡上。1个就1个两个网卡就两个。网卡挂了后上面的HAIP 就漂移到其他网卡上。

HAIP 负责数据库实列的通信高负荷的。

CSS 全称 Cluster Synchronization Service 集群同步服务。

构建集群，维护集群一致性。进行节点管理和群组管理。

启动: ohasd.bin ->oracssdagent_root->ocssd.bin

ocssd.bin访问gpnpd.bin获得集群基本信息，集群名称，集群GID，集群私网信息，VF（表决磁盘）位置。从gipcd.bin获得远程节点联系信息，访问VF租借块（Lease Block)获得本地节点编号，加入集群。

OCSSD.BIN GIPCD,GPNPD都是有OHASD的代理进程同时启动的。OCSSD会一直等待其他两个进程启动OK后继续工作，为此不存在前后顺序问题。

ocssd.bin 从gpnp profile (discovery string) 获得VF的路径，直接读取上面的信息，因此不需要ASM。同时读取misscount 30,reboot latency 3,long i/o timeout 200,short io timeout 27。等超时参数。

通过gipcd进程获得本地私网的网卡和远程私网网卡。节点间私网建立，集群重配，成员列表得到更新。

集群一致性

心跳机制：

1 确定节点之间的连通性，以便节点之间能够了解彼此的状态。

2 用1到多个共享位置保存节点之间连通信息，以便在重配时能够做出正确的决定并记录集群最新状态。

3 本地节点自我监控机制，以便本地出现问题时能够主动离职，避免不一致性产生。

网络心跳：Network HearBeat (NHB) 每个节点ocssd.bin线程每秒都向其他节点发生网络心跳信息。发生线程每秒发送；派遣线程负责接收信息并派遣给相关的进程；分析线程如果某个节点连续丢失网络心跳超过misscount值就通知集群重配。重配线程负责集群重配。

重配：

1 当一个节点连续丢失了网络心跳后分析线程发起集群重配

2 集群重配节点（Reconfiguration Master) RM 向其他节点发生重配消息，收到节点回复此消息，并通知RM自己的状态。

3 RM基于每个节点状态进行投票并检查是否发生了脑裂。

4 对于脑裂，RM会查看网络心跳无法访问的节点的磁盘心跳信息，以便确认节点状态。

5 RM向表决磁盘的KILL BLOCK中写入有毒信息，需要重启的节点当访问VF时读到有毒信息，完成本节点的重启。

6 RM节点修改集群成员列表（主要是在表决磁盘）完成重配。

磁盘心跳：

Disk HearBeat（DHB) 当集群发生了脑裂后帮助制定脑裂的解决方案。同样集群中每个节点每秒向所有表决磁盘注册本节点的磁盘心跳信息。同时把自己联系到的成员列表写入表决磁盘。

磁盘心跳线程负责向集群表决磁盘发送信息，并且读取VF中的KILL BLOCK中的信息。

磁盘心跳监控线程负责监控磁盘心跳线程是否能正常工作；

kill block线程负责监控VF的kill block 信息；

当某个节点在规定时间内（short io time out）一直无法访问某个VF，那么对应的VF会被离线。当达到一定数后，该节点会被重启。这个VF数公式= VF总数/2+1。比如说 VF有3个，3/2+1=2.5 =2 。如果说该节点已经有2个VF不能访问，那么它就该重启。

这样说来RM 依旧网络心跳谁丢失了，然后该节点无法访问几个VF，来决定它是否离线重配，也就是写入有毒信息。如果节点正常只是网络问题，那么它自己主动重启。

节点无法访问VF 会等待200s后对应VF离线，最后剩下的VF 低于某个数，那么重启，优先重启是集群，而不是节点整个系统。

总结下仲裁机制：

当发生问题时候，节点都活得好好的，都认为自己是正常的对方是神经病。

1 先看那个子集群拥有节点多，多的存活。

2 如果节点数一样，则通过谁拥有最多的VF 存活

本地心跳：

Local HearBeat (LHB) 监控ocssd.bin进程和本地节点状态，在发生网络心跳的同时也向cssdagent,cssdmonitor发生occsd.bin状态。如果有问题重启自己节点。

术语：

VF 表决磁盘其中有租借块（LEASE BLOCK) 每个节点编号不再是固定的，是租用的。

KILL BLOCK 保存posion package 有毒信息要求节点重启信息。

OCR 集群注册信息。

misscount 30秒网络和本地心跳。

LIOT(long io time out) 磁盘心跳 200秒连续200秒无法访问VF。

SIOT(short io time out) 节点重配时对VF IO 超时 27秒

REBOOT TIME 集群要求OS重启时间 3秒

Incarnation 每次重配后参数加一便于集群标识最新状态。

CSS组管理

组管理主要完成资源的共享和资源的隔离。资源的管理工作由后面的CRS负责，资源会作为一个个组注册到CSS中，每个组有N个成员构成，成员需要向组内和组外共享信息。比如说集群中每个数据库作为一个组，其中该组主要成员就是LMON进程，当LMON进程启动时需要把自己注册到CSS上，它才能知道数据库同时又几个实列在运行，每个实列在哪个节点上运行。另外ASM启动的时候，也要把自己注册到CSS上，以便于数据库实列知道它启动了。

组：由成员和资源组成的整体。组分为全局组各个成员需要通过RPC来通信，分布在不同节点上。本地组，成员在同一个节点上。

成员：能够独立运行的实体，例如 OS进程。成员由主成员和共享成员，主成员负责监控集群并在其发生变化时进行相应地操作。

GM master ：组管理主节点完成组成员的重配工作。

隔离：当组成员离开的时候，GM保证该成员在OS层上离开，正在执行的IO操作被清理掉。

举个栗子说明下：

磁盘全局组（Disk Group Group Global,DGGG) 每个磁盘组都会哟对应的DGGG，ASM的GMON进程会作为主成员注册进来。如果ASM管理多个磁盘组，GMON会注册到每个DGGG中。

磁盘本地组：（DGGL）每个磁盘组都会有对应的DGGL，数据库实列RBAL进程作为主成员注册进来。同时该组会和DGGG的DMON成员进行信息共享。

数据库全局组（DGG）每个数据库都会有个全局组,LMON进程会注册进来。

核心前段进程组（UFG）：这是个本地组，数据库实例的RBAL和ASMB注册进来。

ASM 实例关闭

sqlplus as sysasm

> shutdown abort

ASM ALTER.LOG

shutting down instance (abort)

License high water mark = 10

USER(ospid:12637): terminating the instance

......

OCSSD.LOG

[CSSD][3027381136]clssgmFenceClient:fencing client(),member(0) in group (UFG_+ASM1),death fence(1),SAGE fence(0)

.....

[CSSD][...]clssgmFenceProcessDeath:client(0x98f7160) pid 13340 undead

clssgmDestroyProc:

clssgmFenceCompletion:

clssgmTermMember:

clssgmUnreferenceMember:

clssgmRemoveMember:

DG组由于这是个全局组，该组成员来自多个节点，当一个节点的主成员离开时GM要进行重配，因此需要看下另外个节点发生了什么。OCSSD.LOG

clssgmBroadcastGrockRcfgCmpl:RPC of grock(DG_DATA1) received all acks,grock update sequence

clssgmRemoveMember:

clssgmQueueGrockEvent:.......

clssgmBroadcastGrockRcfgCmpl:.....

成员终止升级：

过去实例要驱逐另外个实例的话，就在控制文件写入些话。等对应实例LMON访问时候，就知道自己该被驱逐。可是，可是LMON进程死了话? 岂不是搞不定啊！现在可以GM层 KILL掉LMON，进而达到实例驱逐目的。假如这个办法也失败的话，或者规定时间内没完成呢？

那么在规定时间内（20秒）实例无法完成，则在CSS层产生新进程KILL DAEMON以终止目标实例的LMON。如果KD进程在30秒内无法终止LMON进程，那么CSS将升级为节点终止。先重启GI，无法时候再重启节点！

简单地说: 成员自觉离职 -> CSS强行成员离职 ->CSS (GI)离职 ->节点离职（分公司经理离职）

集群重启（Rebootless Restart)

1 当某个节点连续丢失网络心跳超过misscount时

2 当某个节点无法访问多个VF时

3 当成员终止升级为节点终止时

crsctl stop crs

crsctl start crs

CRS （Cluster Ready Service) 集群就绪服务进程crsd.bin。

在11G R2集群中除了OHASD外其他的一切守护进程和资源都承为资源。

CRSD.BIN 以ora.crsd资源形式存在。

代理进程	资源拥有者	资源名称
oraagent	grid	ora.gsd
oraagent	grid	ora.<监听>.lsnr
oraagent	grid	ora.asm
oraagent	grid	ora.ons
oraagent	grid	ora.oc4j
oraagent	grid	ora.<scan>.lsnr
oraagent	grid	ora.<磁盘组>.dg
scriptagent	grid	ora.cvu
oraagent	oracle	ora.<dbname>.db
oraagent	oracle	ora.<dbser>.srv
orarootagent	root	ora.registry.acfs
orarootagent	root	ora.scan<x>.vip
orarootagent	root	ora.<node>.vip
orarootagent	root	ora.gns
orarootagent	root	ora.gns.vip
orarootagent	root	ora.net1.network

资源有六种状态，五种方法。好比C++类有方法和属性样。

五种方法分别是

1 Start

2 Stop

3 Check

4 Clean

5 Abort

状态

1 Online

2 Offline

3 Unknown

4 Partial: 部分在线

5 Failed

6 Intermediat: 中间状态

CRSD的一个组件 PE(Policy Engine) 采用主从模式，一般最先启动成为PE主节点，集群中所有资源操作被发生给PE主节点的CRSD守护进程，由它向各个节点的资源发送相关的操作。因此有些模块负责协调工作，PE模块，AGENT模块，UI模块，OCR模块，通告模块，通信模块。

资源类型：把资源分成很多类型。比如有

1 ora.diskgroup.type

2 ora.listenner.type

3 ora.asm.type

4 ora.database.type

资源属性：只读，可修改，特定。

资源依赖关系：以资源属性start_dependencies 和 stop_dependencies

./crsctl stat res ora.ora11g.db -p

可以看到关系类型：

1 hard

2 weak

3 pull-up

4 attraction

5 dispersion

CRS运行方式：

请求节点A ：客户端 ==>UI模块==>PE模块 ==>PE主节点（PE模块）==>目标节点（agent模块）==>agent进程==>操作资源 OK==>agent模块==>PE主节点==>......照原路返回。

资源分本地资源和集群资源

本地资源只能在本节点上运行，不能转移到其他节点上运行。

集群资源可以在一个和多个节点上运行。

内存融合

就是另外个实列需要的数据库块，另外个数据库实例有的话，就通过网络从那个实列要过来用。内存融合技术，相当于把每个实例的内存看成一个整体内存，这样就减少了IO读取量。

实际情况会比较复杂些，涉及到多种情况，

第一种块不在内存中，

第二种块在别的内存中，

第三种修改块，

第四种读取修改前的块，

第五种修改正在修改的块。

共享池中保存内存融合相关资源的管理信息列如：GCS GES资源定义，以及相关锁信息。

GCS 是全局缓存服务（Global Cache Service),GES 全局队列服务（Global Enqueue Service)

select * from v$sgastat where like 'gcs%';

这里可以看到有关SGA里关于GCS GES的情况

在数据库缓存中保留RAC相关特殊的数据块，以及数据块管理信息。

v$gc_element;

因此在RAC系统中分配给共享池和数据库缓存池，应该比以往单实例要更多的内存。比如说共享池要多分配25%，数据库缓存池要多分配10%

后台进程命名比较难以记忆，因此单独说说它们

LMON（GES Monitor) 全局队列服务监控进程：负责数据库层面的集群关系，并与其它节点上的LMON定期心跳通信。当出问题时完成数据库实例层面的重新配置和GES层面的实列恢复。

LMS （GCS Process) 全局缓存服务处理进程：完成GCS工作，并维护GRD全局资源目录中数据块资源信息，参与DRM工作。可以配置多个进程！

LMD(GES Daemon) 全局队列守护进程：负责GES资源管理工作，也参与DRM工作。

LCK ：实列锁管理，LCK是LMD的补充，锁包括：library cache lock,row cache lock. 当一个进程申请实列锁时，LCK进行广播，对方实列收到消息并反馈。如果对方有进程持有不兼容的锁，那么通知进程释放对应的锁。当shared pool 出现压力要释放cursor，LCK进程释放rowcache内存。

DIAG 诊断捕获进程。

LMHB（GES,GCS Heartbeat Monitor) GES GCS 心跳监控进程：监控 LMS,LMD,LMON,LCK。

后台进程说明完毕！

其中DRM 是动态资源主节点。就是调整数据块应该存放在那个实例内存中的功能。

1 控制文件：除了承担单实列所有功能外，还要承担类似于表决磁盘的角色，检查点进场CKPT会定期向控制文件写入本地实例状态信息，以便在数据库层面需要重配的时候进行投票。

2 UNDO表空间：RAC要求每个实例创建自己的UNDO表空间，事务不能跨UNDO表空间。

3 临时表空间：RAC没有要求每个实例拥有自己的TEMP空间，会在一个表空间里分配临时段，同一个临时段不能被多个实列同时使用。当不够用时会要求其他实列释放占用的临时段。一般建议建个表空间组降低临时段的争用。

4 重做日志：REDO 要求每个实例两个REDO日志组，每个日志组必须包含1个有效的日志。日志线程号在单实例中这个基本不存在的东西，在RAC就非常重要了。

ora11gr2.thread=1

ora11gr2.thread=2

5 初始化参数文件 SPFILE和PFILE 一般都存在ASM 磁盘组上，当为了万一，必须把SPFILE和PFILE备份在本地磁盘ORACLE_HOME/dbs 下。一当ASM盘无法访问时，SPFILE就无法获得。

前面我们谈到它的两种服务，多个后台进程，已经我们假设的场景。今天我们了解下GRD

1 全局资源目录(GRD)

GRD是一种数据结构：一张表，数组，链表等。它GRD能使多个实例并发访问进程所有情况都在内存实现，从而摆脱对磁盘的依赖。

GRD作为内存融合的基础，在此基础上内存融合被分为GES,GCS两个部分，已经对它们管理的LMS和LMD。

GRD实际上是保存和组织内存融合相关所有资源的一种方式，而且每个数据实例都包含GRD的信息，所有实列的内存融合信息构成整个的GRD.共享池和数据缓存池都保存了不同种类的GRD信息

从上图看虚线就是GRD。数据库缓存池存有GCS资源的定义（数据块）共享池存有PCM锁，PCM锁通过LE方式实现，LE通过HASH CHAIN方式组织。

GCS->LE->PCM

共享池还保存了GES资源的定义和NON-PCM锁信息。

LMD LMS 是GRD的接口，服务进程必须通过接口才能访问GRD。

资源就是数据库提供的，可以被客户访问的对象。可以是一个数据块，索引，表，排队等。

锁：就是保护这些资源在并发的时候。

因此RAC 只有两种锁 PCM锁和NON-PCM锁。而本地锁：latch mutex,row cache lock,library cache lock等是不能跨实例的。

同时每个实列会有些LATCH MUTEX 保护 RAC 在数据库缓存池和共享池里面的东西。

PCM资源名称是【数据块】【文件号】【BL】。比如说5号文件207号块上是【0x10e】【0x5】【BL】,数字都是16进制。可以从X$KJBR 表查看资源的属性。

SELECT * FROM X$KJBR WHERE KJBRNAME LIKE '%10e%5%BL%';

需要在主节点上查

NON-PCM资源名称为【id1】【id2】【类型】其中ID1，ID2从V$LOCK中的ID1，ID2;

假如说 UPDATE TABALE SET NAME='XXX' WHERE ID=3;

那么从V$LOCK 获得 SELECT * FROM v$LOCK WEHRE SID=45；

以TM排队为列【0X587C】【0X0】【TM】

从V$GES_RESOURCE WHERE RESOURCE_NAME LIKE '%587C%TM%'

PCM锁通过LE来进行描述，可以从V$GC_ELEMENT获得信息。它有三个属性：模式，角色，旧镜像。

模式有三种：N空，S 共享，X独占。同时锁有持有和申请。因此这里就举不兼容的。X->S,S->X,X->X

角色：本地(L)和全局(G) 本地表示只在本地修改过，全局是在远程1个或多个实例修改过。

旧镜像（PAST IMAGE) PI 取值 1和0 1表示存在 0 表示不存在。一般角色L 就不存PI。PI 只针对G角色的资源。也就是说块在多个实例多次修改在DBWR未写入前的中间状态。如果DBWR写入后PI块就变成了CR块（consistent Read),当PI产生时，对应改变信息被写入重做日志，PI的存在主要是避免RAC过多的访问回滚段。

NON-PCM锁跟单实例排队机制一样！

GRD中的资源需要能过被多个实列同时访问，这就需要一个协调者记录对应资源上的锁信息，并负责协调资源的申请！它就是主节点。

集群中的每个节点，都可能是主节点，这种分布式主节点好处在于，高可用型和工作负载。唯独是主节点消息通讯比较大。

当一个GRD资源被第一次访问的时候，会对它做个HASH计算得到主节点的实列编号。然后把该资源的定义信息和对应锁信息保存在主节点上。

同时本地实列也就是非主节点，资源使用节点会保存一份资源的副本和锁信息。避免频繁的实列通讯被称为shadow lock。

Oracle以资源（数据块）为单位计算主节点，而不是以对象，数据文件等。

集群中无论几多个实列，最多有三个节点完成资源操作，它们是

1 资源申请节点

2 主节点

3 资源持有节点

消息机制：RAC实列之间通讯实现方式，上面三个实列之间通讯就是消息，同时数据块传递是一种特殊的消息

消费分类：一种REGULAR，需要马上传递而且及时反馈。

另外一种是BATH 异步发送。

消息池：也就是说上面的消息，先要放进消息池当中，然后由队列进行管理

V$SGASTAT.NAME LIKE 'mess%'

这个视图查询消息池情况

流量控制，指消息流量控制。很多消息需要立即处理，当实列之间消息处理能力雨露不均，就可能出现过多的消息发送请求，从而导致消息死锁。

Oracle 在系统里定义一定数量的TICKET，如果进程需要发送消息必须持有TICKET。接受到消息节点会反馈信息过去，同时夹带接受端的TICKET数，消息发送进程收到TICKET数会对比本节点的TICKET数。然后做出是否再次发送消息的决定。

V$DLM_MISC . NAME LIKE 'mess%'

非PCM资源：

我们新建个表来测试：create table test(id number,name varchar2(20));

insert into test values(1,'hello');

insert into test values(2,'good day');

commit;

实例1

会话1 ：update test set name='hello world' where id=1;

获得SID：select distinct sid from v$mystat;

不提交继续下面测试。

从v$lock 可以看到锁信息

select * from v$lock where sid=xxx;

看类型TM的ID1和ID2

ID1=22652

ID2=0

转换成16进制【0x587c】【0x0】【TM】

会话3：

SELECT RESOURCE_NAME,ON_CONVERT_Q,ON_GRANT_Q,MASTER_NODE,NEXT_CVT_LEVEL

FROM V$GES_RESOURCE

on_conver_q =0

on_grant_q =1

master_node=0

next_cvt_level=KJUSERNL

说明目前转换队列没有进程，持有队列有个进程，主节点在实例1上，锁级别为kjusernl

再看 V$GES_ENQUEUE 中的信息

GRANT_LEV = KJUSERCW

REQUEST_L=KJUSERCW

PID =XXX

OWNER_NODE=0

会话2 更新下一行：update test set name='goodbye my love' where id =2;

V$GES_RESOURCE 的信息没有发生变化，说明两个会话以兼容方式申请的资源。

而v$GES_ENQUEUE 多了两行数据，唯独不同就是PID值不同了。

会话2 ROLLBACK后会话1 LOCK TABLE TEST IN EXCLUSIVE MODE；

会话2以更高级方式申请TM锁

这样 v$GES_RESOURCE 信息没有发生变化，而V$GES_ENQUEUE 锁级别变成了KJUSEREX

实列2 会话1 来个更新 update test set name ='goodbye my love' where id =2;

这个时候V$GES_RESOURCE 数据发生了变化，ON_CONVERT_Q 从0变成了1

V$GES_ENQUEUE上多了一行数据

GRANT_LEV REQUEST_L PID OWNER_NODE

kjuserex kuserex 333 0

kjusernl kjusercw 444 1

看到实例2 申请KJUSERCW锁，当被实列1的会话1阻塞了。

在实例2 会话2 查看V$GES_RESOURCE 信息跟实例上的信息不一样

ON_CONVERT_Q ON_GREANT_Q MASTER_NODE NEXT_CVT

1 0 0 KJUSERNL

总结下 NON-PCM资源是通过队列来进行锁的兼容性获得，要么就等待。

PCM资源

目前RAC 有4个节点分别叫 A B C D

场景1 ：

C节点要读取个块 SELECT * FROM TEST WHERE ID=1；

1 此时SCN=100 该数据块经过HASH计算被安排它的主节点是D，

2 主节点登记锁属性为SL0

3 C节点从数据文件读取该块

4 读取完后获得对应锁属性 SL0，并异步通知主节点

场景2 ：

B节点也要读取该块 SCN 102 SELECT * FROM TEST WHERE ID=1；

1 节点B 向主节点D发送请求

2 主节点D发现最新版本在节点C上，要求节点C发送；

3 节点C 把数据块发送给节点B

4 节点B收到数据后通知主节点D更新锁信息

场景3 ：

B节点要更新块： UPDATE TEST SET NAME='XX' WHERE ID=1;

1 节点B向主节点D申请该块的高级锁(EXCLUSIVE)

2 主节点D发现节点C持有该块的S锁，要求它释放并把该块传给B

3 节点C收到消息后，释放锁并把块传给B 同时节点C的块变成CR块。

4 节点B 收到块后，通知主节点D更新锁锁信息XL0 SCN=103

场景4

B节点修改了块，A节点也要修改。

UPDATE TEST SET NAME='X信息X' WHERE ID=1;

1 节点A向主节点D申请高级锁

2 主节点要求B释放X锁

3 节点B 写入日志，并释放X锁，把锁信息变成 NG1，当前块变成了PI块（次新块）

4 节点A收到了后通知主节点修改锁信息为 XG0

场景5

A节点修改后 C节点要求SELECT

1 节点C向主节点申请共享锁S

2 主节点D 要求节点A 释放锁并传给C

3 节点A 写入日志释放X锁节点A对应锁信息是SG1

4 节点C收到块后更新本地锁信息，也通知主节点更新SG0

场景6

节点B 要求SELECT该块

1 节点B向主节点申请共享锁S

2 主节点发现C和A都存在S锁，选择C传送

3 节点C把最新版本传给B

4 节点C更新本地锁信息 SG1

CHECK POINT

节点A 要求写入文件

1 节点A向主节点要求将数据写入文件

2 主节点发现A节点存在最新版本，并通知它写入

3 节点A进行IO

4 节点A写完后本地锁XL0

5 主节点通知所有持有PI的节点取消PI。

总结来说要么更新，要么查询，要么写入。其实总体来说很简单

如果PCM资源也就是数据库被第一次查询就注册下主节点并从数据文件读入

第二次查询就从其他节点拿过来

第一次更新从其他节点拿过数据，并该节点释放锁，同时更新本地锁信息。

拿到后通知主节点更新锁信息，包括版本和持有的节点。

如果第二次更新原来持有更新的节点就变成了PI块类似于UNDO块。

CR块是读一致性块，发生在SELECT 过去的，修改前的数据块。

在RAC中这情况发生了些改变

1 如果本地节点有的话，就从UNDO构造出来

2 从远程节点拿CR

3 远程节点要么从PI块，要么从手中现有的查询块给。

4 在构建CR通知LGRW进程将CLEAN OUT信息记录到日志上。

select cr_requests,data_requests,undo_requests,disk_read_results,flushes,errors

from v$cr_block_server;

SCN

SCN 是数据库内部时钟，不重复，单向增长。ORACLE在分布事务系统中选择SCN最大的为标准，将所有的实例同步成最大的。

既然RAC多实列都要用到SCN，而且每个实例都会有事务提交，那么就需要一种方式来确保每个实例在进行事务操作时能够拿到正确的当前数据库的SCN号。

也就是说需要一种方式在实例之间传播SCN。为此ORACLE采用两种方式：Lamport和BOC.从10.2版本开始BOC成了默认方式。

BOC 只有当某个节点的SCN号发生改变才进行传播，传播进程主要是LGWR。

RAC多实例通信通过LMS,LMD进程。LGWR负责将REDO写入日志，并且把SCN号传给LMS,LMD。

BOC 间接方式：

1 用户提交事务，并通知LGWR。进入LOG FILE SYNC等待。

2 LGWR 将事务提交SCN发送给本地LMS，每个节点都有自己的SCN发生器.

3 LGWR写入日志

4 本地LMS把包含SCN消息发生给远程节点的LMS

5 所有远程LMS收到并反馈给本地LMS

5.5 每个节点把接收到的SCN和本机的SCN对比，如果本机的SCN 小，则调整本机的SCN和接收的一致

6 日志IO完成写完

7 本地LMS通知LGWR 所有节点已经收到我们的SCN了

8 本地LGWR通知用户进程。

直接方式：就是LGWR直接把SCN号发给远程所有节点LMS。其他与间接方式一样。

DRM是Dynamic Remastering 中文意思说动态调整主节点。

它是从10G开始的,以前9i第一次后就一定终身。这样代理多次远程节点访问，增加了2路和3路的通信成本。

那么DRM 是通过对资源的访问频率来修改资源的主节点属性。有三个隐含参数。

1 _gc_policy_time 每次收集的间隔时间默认10分钟

2 _gc_policy_minimum 每分钟至少访问多少次才修改主节点，默认1500。

3 _gc_affinity_ratio 当一个节点超过其他节点访问次数倍数时，默认为50倍。

DRM迁移的是数据块的主节点信息，而不是将最新的块迁移到访问次数最多的节点。

DRM 是收集粒度是对象级别，比如说索引，表，分区。

因此迁移的话，是把整个对象的数据块主节点信息进行迁移。

DRM会给符合条件的数据块加个标识affinity lock。

DRM会使用WIDNOWS 来批量迁移数据块主信息，默认值64.

DRM 过程

1 LCK0统计对象在每个实列的访问情况，把符合条件放入DRM队列中。

2 当DRM时间点到达后，LMD进程检查队列，把符合条件的以WIDNOWS单位迁移。

最后LMON和LMS协作完成迁移工作。

1 静默阶段 LMON准备DRM时通知所有实例的LMS结束相应的操作，并停接受请求。

2 冻结阶段 LMS接受请求后冻结这些资源，（gcs drm freeze in enter server mode)

3 清除阶段将对应块在所有节点上的旧的主节点信息清除

4 重建阶段所有LMS把本地持有锁发个新的主节点。

5 解冻阶段。。。。。。。。。。。。。。。。

很显然DRM虽好，可也带来性能问题。。慎用！

read mostly 是DRM的优化。很多应用当中数据库对象大部分操作都是查询，很少修改。对于这样的对象的数据块，每个实例都保留副本就可以了。在访问过程中不需查看主节点信息，也不需要在实例中传递数据块。

LCK0 在统计访问次数的时候，也统计访问方式，体现是S锁的PCM，并且访问该数据块经常产生实例之间通信，那么就会将这个数据库对象加上个read mostly标识。并且对所有实例都预先赋予读取权限。

同样预读取要消耗大量的物理IO。同时修改时候也很消耗资源的。

以下特性对象适合read mostly

1 该对象大部分读取操作多，极少修改

2 访问该对象是出现大量的gc cr grant 2-way,gc current block 2-way,3-way等待事件。

通过下面视图看是否降低了远程通信。

select name ,value from v$systat where name in ('gc local grants','gc remote grants');

read mostly 特性开启参数是 _gc_read_mostly_locking. 默认值是开启状态。

很显然新特性，也带来新性能问题。ORACLE老是这样搞，把我们当小白鼠玩。 read mostly 目的是解决性能问题，当这个特性目前是自动的，非手动来设定哪个对象成为read mostly。必然带来不必要的修改！

实列管理

1 实列启动时候，会和集群软件进行通讯，获得数据库已经启动实列的列表，并将自己注册到CSS组当中

2 集群管理软件通知其他实列有新的实列加入

3 已经存在的实列当中选一个出来当重配主实列，完成数据库实列重配工作。

关闭与上面一样。

CGS（Cluster group service）功能更CSS差不多

1 实列之间的心跳

2 当实列加入和离开时完成重配工作

3 解决数据库层脑裂

心跳

1 网络心跳由LMON进程完成，间隔300秒之间没有发生相应就视为挂了 ORA-29740

2 磁盘心跳：由CKPT每3秒向控制文件写入本地实列能够访问其他实列的信息 ORA-494

如果某个实列在900秒内不能完成控制文件IO，选择重启实列方式，维护数据一致性。

3 本地心跳： LMHB 新加入监控进程来监控LMON,LMS,LMD,LCK0

有三个隐含参数

1 _lm_rcvr_hang_check_frequency =20s 定期检查的间隔时间

2 _lm_rcvr_hang_allow_time =30 s =实列死机时间

3 _lm_rcvr_hang_kill = true 当实列超过hang时间后是否容许重启实列

4 _lm_rcvr_hang_check_system_load = true 分析把系统的负载考虑进来

在高负载的集群系统上这几个时间会造成系统的负担，建议延长时间 60和200秒

数据库层脑裂

1 两个实列之间私有网络出现了问题，在一定时间300秒后，两个实列无法之间通讯

2 每个实列都尝试获得控制文件的RR锁，获得RR锁的实列访问控制文件实列表状态决定驱逐谁了。

实列恢复

当某个实列离开集群后，重配主节点会将对应实列的重做日志应用到数据库。

1 执行恢复实列的SMON进程获得IR锁，并通知其他实列开始实列恢复，之后进行第一次redo.log分析

主要目的构建恢复集

2 获取恢复所需要的内存融合锁，根据恢复集中的数据块向其他实列申请对应的锁和块。

3 开始恢复redo中数据库改变，恢复后释放IR锁。

恢复集是个通过块地址的双向链表，其中记录了每个重做日志中被修改的块的第一个脏SCN号，块地址，最后脏SCN。

阶段1 扫描异常关闭的REDO把需要恢复块加入恢复集，如果块最后出现了BWR标志，则从恢复集删除；对多次修改的块

每次的修改只更新恢复集的最后脏的SCN号

应用修改，一种是从数据文件中读取，然后应用更改。另外一种是从数据文件读取的块，跟其他实列的同样的块的PI

做比较，哪个PI的SCN最大，就从这个块的PI开始恢复操作。

MASTER信息，实列上的修改过的块的MASTER信息在其他节点上还好吗，

在自己节点上的话，那新的MASTER信息将移交给做恢复的实列上。

那些没有修改的块，就等下次读取的时候再HASH到新MASTER上。

RAC 统计信息

一类是 PCM资源的

二类是 NON-PCM

三类是消息

第一类 GCS

gc current blocks received 向远程申请当前块数

gc current blocks served 向远程块发送当前块数

gc current block receive time 从发送申请到接收到块的时间，0.01秒

gc current block send time 向远程节点发送当前块的时间，

gc cr blocks received 向远程节点申请CR块

gc cr blocks receive time 从申请到接收到CR块时间

gc cr blocks served 向远程节点发送CR块数

gc cr blocks send time 向远程节点发送CR块时间

gc current block flush time PI块FLUSH到REDO.LOG时间

gc current block pin time 当前块获取PIN锁的时间

gc cr blocks fulsh time CR块FLUSH到REDO.LOG时间

gc cr block build time CR块构造时间

申请时间（gc current block receive time）=服务端

（gc current block flush time+gc current block pin time+gc current block send time）+网络传送时间

第二类 GES 统计

global enqueue gets 实列申请锁的次数

global enqueue get time 所有成功申请的时间

第三类消息统计

messages sent directly 没有经过流量控制和阻塞，直接到达远程节点的消息数量

messages flow controlled 经过流量控制的消息数，没有得到有效的TICKET。

messages sent indirectly 没有直接到达远程节点的消息数

messages received actual 接收到远程消息数

messages received logical 统计接收到所有的消息数

AWR的统计信息

DBWR Fusion writes 数据库写入有关CACHE FUSION相关数据块数

Estd Interconnect traffic (KB) 每秒私网流量

Buffer access-local cache % 本地缓存访问比

Buffer access-remote cache 从远程缓存访问比

Buffer access-disk 从磁盘访问比

avg global enqueue get time ms

avg global cache cr block receive time

avg global cache current block receive time

avg global cache cr block build time

avg global cache cr block send time

global cache log flushes for cr blocks served %

avg global cache cr block flush time (ms)

avg global cache current block pin time

avg global cache current block send time

Global cache log flushes for current blocks served

avg global cache current blocks flush time

消息统计

avg message sent queue time (ms)

avg message sent queue time on ksxp

avg message received queue time

avg GCS message process time

avg GES message process time

V$GES_STATISTICS

ack for commit broadcst (actual)

acks for commit broadcst(logical)

CR块统计

v$cr_block_server

cr block requests 远程实列向本地申请次数

current block requests 本地实列通过当前块满足远程CR块要求

data block requests 普通数据块请求数量

undo block requests 回滚段数据块请求

tx block requests 回滚段段头块请求

当前块统计 V$CURRENT_BLOCK_SERVER

GC数据传输统计：V$INSTANCE_CACHE_TRANSFER

先来个死锁，死锁由LMD进程处理

1 每个实例的LMD进程定期申请DI资源，获得申请DI资源的LMD进程会搜索各个实例没有被满足的锁请求，并绘制锁的等待链路。

2 如果LMD发现了有闭合环路的存在，那么就将导致这个环路的进程的DML语句回滚，然后释放DI资源。

LMD检查死锁时间间隔有隐含参数 _lm_dd_interval (10秒）。

2 enqueue等待事件：有些enqueue等待情况在RAC系统中可能比较严重

2.1 tx enqueue: 排队代表进程

2.1.1 enq: TX- row lock contention :等待其他事务提交或回滚

2.1.2 enq:TX-index contention :对单向增长的主键索引的表进行大量的并发插入

2.1.3 enq:TX-allocate ITL entry: 等待分配新事务槽，由于数据块大，包含太多数据

2.1.4 SQ enqueue: 与序列相关，每当产生一组新的CACHE值时，要更新序列的定义。

解决方法1 加大序列CACHE值

解决方法2 修改序列属性NOORDER

解决方法3 为不同的序列创建不同的序列

3 GC 等待事件

3.1 gc current cr block request :主节点LMS进程还没响应

3.2 gc current cr block 2 way:

3.3 gc current cr block 3 way:

这两个事件，如果出现比较多，时间比较长可能存在以下情况

1 私有网络带宽问题

2 UDP层面出现了问题

3 资源系统出现了问题

3.4 gc current cr block busy: 远程的块正在被进程使用中，redo flush也算在其中。

原因 1 热点块，2 对相同的表大并发的DML，3 对带有主键索引的表大量的并发INSERT

3.5 gc current cr grant 2-way 该块不在内存中，在文件中。

3.6 gc current grant busy: 申请实列以X独占方式，等待其他先到达的S模式释放锁

原因是一个实列不断修改块，其他实例不断访问块

3.7 gc current cr block congested: 远程节点已经收到，可是LMS进程没有及时响应和发生

3.8 gc current cr grant congested：同3.7 LMS没有发生反馈信息

3.9 gc cr failure/gc curent retry: 申请实例没有收到数据块

3.10 gc current/cr multi block request: 申请多个块，没有收到或者没有完整收到

原因网络带宽，UDP参数设置。内部限制每次最多只能发生16个数据块。

1 序列 SEQ

1.1 尽量使用大的CACHE值来减少对数据字典的访问次数

1.2 尽量避免ORDER

2 HW序列

HW 是进程在升高数据对象高水位值时需要持有的资源，防止多个进程同时修改高水位。

2.1 表空间存储参数设置有问题，导致数据库对象频繁地申请空间。

2.2 大量的并发的PARALLEL DML或者BULK INSERT语句

每个实列在尝试分配新空间的时候都会申请HW排队就产生比较多的HW-CONTENTION

create tablespace .... extent management local uniform size 10m;

3 索引块争用导致的性能问题

如果表上存在主键索引，并且键值单向增长。有大量的Insert并发语句。如果是多实例同时的话，将又大量的索引块和数据块在实列之间转移。

建议

1 使用HASH或者RANGE方式对表分区，这样将数据分布到更多的块。

2 如果索引列值是被顺序插入，可以使用反向索引。

3 调整应用避免将连续的键值插入到表当中

4 网络缓存大小导致性能问题

UPD 发生缓冲区=DB_BLOCK_SIZE*DB_FILE_MULTIBLOCK_READ_COUNT+4KB

UDP 接收缓存区=10*UDP发送缓存区

HANG （挂起）是指某个进程由于无法获得资源而进入等待状态，只有获得资源才解除。一般有两种状态，死锁和等待连。关于等待链是有阻塞进程和等待进程构成的，阻塞进程存在一个或多个根阻塞进程，如果根阻塞进程处于空闲状态，那么就存在问题！如果阻塞进程忙而且时间比较长，那么对数据库影响比较大。

HANG MANAGE 工作方式

HM 通过后台DIA0进程来收集HM需要的信息，而节点号最小的实例DIA0作为主进程来分析其他实例收集到的信息。

1 定期收集信息

2 找到HANG的会话发生给主进程

3 主进程绘制等待链

4 分析是否出现了HANG，只有当某一个等待链上的会话信息和相应的等待事件没有发生改变时，才可以认为HANG有可能出现。

5 验证：主进程再等待一个阶段 1-4的过程，之后与上个结果对比下

6 定位：主进程根据验证结果定位到根阻塞进程

7 解决：主进程根据参数是否要求解决参数是_hang_resolution_scope 默认是Off 不解决继续监控。如果设置成process 表示终止根阻塞进程来解决，当这个根阻塞不能是后台数据库进程。如果设置成了instance 表示可以终止实例方式。

不解决情况

1 由于TX ENQUEUE TM ENQUEUE 应用程序设计相关的

2 由于无法归档引起来的，log file switch

3 由于 CF enqueue

4 由于备份操作

参数介绍

_hang_detection_enabled 是否启用默认TRUE

_hang_detection_interval 收集信息频率默认32秒

_hang_resolution_scope 解决方式 OFF;PROCESS;INSTANCE

_hang_verification_interval 验证时间间隔 46秒

_hang_ignored_hangs_interval 被忽悠的HANG重新验证时间 300秒

_hm_analysis_oradebug_sys_dump_level 产生转储级别 0

日志

DIA0 进程主跟踪文件（<sid>_DIA0_<pid>.trc) 记录工作的详细信息，包括发现，分析，处理HANG的过程。

DIA0 历史跟踪文件(<sid>_DIA0_<pid>_n.trc)

incident 如果DIA0通过终止进程方式解决HANG的话，会在ALERT.LOG记录一个ORA-32701。同时会在ADR产生一个INCIDENT日志文件记录本次详细信息。

如果发生了HANG 可以从V$HANG_INFO 看看。

V$HANG_SESSION_INFO;

V$HANG_STATISTICS;

在集群上监听又是怎么回事呢？

这就可以说道说道下了，不过集群上的监听还是比较容易理解，从原来的9I 发展到如今的11GR2 可以说监听这块越来越容易配置了。

到了11G 后我们把以前学得清理掉，请清空脑袋。从头开始！

1 应用程序如何连接？

它主要通过 TNSNAME.ORA文件或者是JDBC配置来的，下面不是很规范，仅仅举例说明下而已。

JDBC ：oracle:thin:@test-scan:1521/sharkdb

tnsname.ora : (address = (protocol=tcp) (host=test-scan)(prot=1521)(servername=sharkdb)

2 IP 地址呢？

这就要通过DNS来进行域名解析，当然每个应用程序都要配域名解析地址，也就是

[oracle@svr3 ~]cat etc/resolv.conf

# Generated by NetworkManager

nameserver 8.8.8.8

nameserver 202.96.134.133

3 DNS 会返回随机3个不同的IP地址也就是SCAN IP

3 SCAN 监听器

如下面图所示，如果是4个节点三个SCAN-IP 对应3个SCAN 监听器，这3分布在三个不同的实例上。当然如果是两个实例的集群，比如有个节点上有2个SCAN-IP监听器。

4 关于SCAN-IP监听需要我们DBA去设置吗？

自然不要，它本身就是集群中的资源而已，当要配置下IP地址啦！不过都很简单EASY啦！！

SRVCTL CONFIG SCAN

scan naem :test-scan,network:1/192.168.100.0/255.255.255.0/eth0

scan vip name :scan 1,ip:/test-scan/192.168.100.100

scan vip name :scan 2,ip:/test-scan/192.168.100.100

scan vip name :scan 3,ip:/test-scan/192.168.100.100

5 SCAN -IP 漂移

当 SCAN监听器所在的实例上机器不可用了，集群不行了，或者重启了。它就漂移到其他节点上。

6 SCAN监听消息转发

当一个请求被接受到了，它被所有的实例都注册了服务。也就是说它这个监听器拥有所有的服务名的注册。如果它运行的实例上没有该服务，它就转发到其他实例上的本地监听。

引入了scan以后，就方便了客户端连接的一个接口，顾名思义 single client access name ，简单客户端连接名，这是一个唯一的名称，在整个公司网络内部唯一，并且在DNS中可以解析为三个ip地址，客户端连接的时候只需要知道这个名称，并连接即可，每个SCAN VIP对应一个scan listener，cluster内部的service在每个scan listener上都有注册，scan listener接受客户端的请求，并foward到不同的Local listener中去，还是由local 的listener提供服务给客户端。

7 负载均衡

PMON 会把参数中设置的remote_listener 的服务注册到SCAN监听器上，同时还注册负载信息。因此SCAN监听每次会把当前的请求转发到负载比较低的实例上。

8 TAF 叫灾备。

这里只谈服务端的TAF， TAF主要通过服务名来搞定的。

srvctl add service -d ora11g -s test -r ora11g1 -a ora11g2 -p basic -e session -m basic -w 5 -z 3

-d 表示数据库唯一名称

-s 添加的服务名

-r 默认运行的实例

-a 故障切换的实列

-e TAF类型有SESSION,SELECT,NONE

-w 重试切换间隔时间

-z 重试次数

-p TAF策略用户定义何时创建到其实例的连接，有BASIC 和 PRECONNECT

TAF 类型解释

用于定义发生故障时对完成的SQL 语句如何处理，其中有2种类型：session 和select.这2种方式对于未提交的事务都会自动回滚，区别在于对select 语句的处理，对于select，用户正在执行的select语句会被转移到新的实例上，在新的节点上继续返回后续结果集，而已经返回的记录集则抛弃。

BASIC：是指在感知到节点故障时才创建到其他实例的连接。

PRECONNECT: 是在最初建立连接时就同时建立到所有实例的连接，当发生故障时，立刻就可以切换到其他链路上。

两种方法比较： BASIC方式在Failover时会有时间延迟，PRECONNECT方式虽然没有时间延迟，但是建立多个冗余连接会消耗更多资源，两者就是是用时间换资源和用资源换时间的区别。

9. 启动server_taf服务

[oracle@db1 bin]$ ./srvctl start service -d orcl -s server_taf

10. 检查service运行情况

[oracle@db1 bin]$ ./srvctl config service -d orcl

11 远程监听地址

remote_listener

这个值一般设置为 test-scan:1521

也就是把本地服务注册到SCAN监听器上，如果是在/etc/hosts设置1个scan-ip的话，一般写的是SCAN-IP地址。如果采用DNS的话，那只能写域名方式。这样来实例也要知道DNS的地址在哪？

oracle RAC cluster 日志信息：
日志对于系统或是数据库问题的诊断尤为重要，在cluster中除了scan监听日志和用于存储ocr和表决磁盘的asm实例日志符合adr结构，其他日志不符合adr特性。
默认clusterware日志存储在$ORACLE_HOME/log/hostname中

了解RAC日志目录对于RAC 安装和运行过程出的问题能比较快速地进行定位