1.Oracle集群日志的文件路径
Oracle集群涉及的日志主要位于“$GRID_HOME/log”和“$ORACLE_HOME/log”目录中。
2.日志目录结构
clusterware 层的日志结构：
grid@rac1:/home/grid>tree -d $ORACLE_HOME/log
/opt/rac/11.2.0/grid/log
|-- crs
|-- diag
| `-- clients
| `-- user_root
| `-- host_1874443374_76
| |-- alert
| |-- cdump
| |-- incident
| |-- incpkg
| |-- lck
| |-- metadata
| |-- stage
| |-- sweep
| `-- trace
`-- rac1
|-- admin
|-- agent
| |-- crsd
| | |-- oraagent_grid
| | |-- oraagent_oracle
| | `-- orarootagent_root
| `-- ohasd
| |-- oraagent_grid
| |-- oracssdagent_root
| |-- oracssdmonitor_root
| `-- orarootagent_root
|-- client
|-- crsd
|-- cssd
|-- ctssd
|-- diskmon
|-- evmd
|-- gipcd
|-- gnsd
|-- gpnpd
|-- mdnsd
|-- ohasd
|-- racg
| |-- racgeut
| |-- racgevtf
| `-- racgmain
`-- srvm
42 directories
RMDBS 层的日志结构：
oracle@rac1:/opt/rac/oracle/diag/rdbms/rac>tree -d rac1
rac1
|-- alert
|-- cdump
|-- hm
|-- incident
|-- incpkg
|-- ir
|-- lck
|-- metadata
|-- stage
|-- sweep
`-- trace
11 directories
其中“rac1”是主机名。
3.日志目录功能说明
1）CRS日志存放在“$GRID_HOME/log/<hostname>/crsd”目录，系统会对该日志每10M进行归档一次；
2）CSS日志存放在“$GRID_HOME/log/<hostname>/cssd”目录，系统会对该日志每20M进行归档一次；
3）EVM日志存放在“$GRID_HOME/log/<hostname>/evmd”目录；
4）“$GRID_HOME/log/<hostname>”和“$ORACLE_HOME/log/<hostname>”目录中的racg目录中记录了RACG可执行文件对应的日志；
5）“$GRID_HOME/log/<hostname>/client”和“$ORACLE_HOME/log/<hostname>/client”目录记录了与srvctl、ocrdump、ocrconfig以及ocrcheck命令对应的日志信息。
4.Oracle集群的alert日志
Oracle RAC环境中的alert日志文件与Oracle单实例的alert日志一样。该文件位于“在 $ORACLE_BASE/rdbms/<hostname>/trace”目录下，命名规则为“alert_<nodename>.log”
该警告日志记录了有关Oracle集群rdbms 层面的重要警告信息。
oracle@rac1:/opt/rac/oracle/diag/rdbms/rac/rac1/trace>more alert_rac1.log
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options.
Using parameter settings in client-side pfile /opt/rac/oracle/admin/rac/pfile/init.ora on machine rac1
System parameters with non-default values:
processes= 150
nls_language = "SIMPLIFIED CHINESE"
nls_territory= "CHINA"
memory_target= 1584M
control_files= "+DATA2/rac/controlfile/current.260.781821965"
db_block_size= 8192
compatible = "11.2.0.0.0"
log_archive_dest_1 = "LOCATION=+DATA2"
log_archive_format = "yangdb_%t_%s_%r.dbf"
db_create_file_dest = "+DATA2"
undo_tablespace = "UNDOTBS1"
instance_number = 1
remote_login_passwordfile= "EXCLUSIVE"
db_domain= ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=racXDB)"
remote_listener = "scan:1521"
audit_file_dest = "/opt/rac/oracle/admin/rac/adump"
audit_trail = "DB"
db_name = "rac"
open_cursors = 300
diagnostic_dest = "/opt/rac/oracle"
Cluster communication is configured to use the following interface(s) for this instance
10.10.10.10
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2
Sat Apr 28 20:50:38 2012
PMON started with pid=2, OS id=16042
Sat Apr 28 20:50:38 2012
VKTM started with pid=3, OS id=16044 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Sat Apr 28 20:50:39 2012
GEN0 started with pid=4, OS id=16048
Sat Apr 28 20:50:39 2012
DIAG started with pid=5, OS id=16050
Sat Apr 28 20:50:39 2012
DBRM started with pid=6, OS id=16052
5.小结
熟悉Oracle集群环境下日志文件的位置和功能有助于快速定位故障的位置，善用之。
ORA-29780: unable to connect GPnP daemon [CLSGPNP_ERR]
安装完成 11GR2 Grid 之后，使用asmca创建磁盘组的时候遇到如下报错：
Started getting following error
ORA-29780: unable to connect to GPnP daemon [CLSGPNP_ERR]
google 一把 和环境变量有关：(CRS/GRID 是运行正常的).
grid@rac1 /oragrid/dbs>env | grep ORA
GRID_HOME=/opt/11.2.0/grid <====== 从老的bash_profle 中继承的！
ORACLE_SID=+ASM1
ORACLE_BASE=/opt/rac/grid
ORACLE_HOME=/opt/rac/11.2.0/grid
$GRID_HOME变量必须和$ORACLE_HOME 保持一致,否则在使用asmca创建磁盘的时候 会认不到asm 磁盘!
OracleRACCSS提供2种后台服务包括群组管理(GroupManagment简称GM)和节点监控(NodeMonitor简称NM)，其中GM管理组(group)和锁(lock)服务。在集群中任意时刻总有一个节点会充当GM主控节点(masternode)。集群中的其他节点串行地将GM请求发送到主控节点(masternode)，而masternode将集群成员变更信息广播给集群中的其他节点。组成员关系(groupmembership)在每次发生集群重置(clusterreconfiguration)时发生同步。每一个节点独立地诠释集群成员变化信息。而节点监控NM服务则负责通过skgxn(skgxn-libskgxn.a，提供节点监控的库)与其他厂商的集群软件保持节点信息的一致性。此外NM还提供对我们熟知的网络心跳(Networkheartbeat)和磁盘心跳(Diskheartbeat)的维护以保证节点始终存活着。当集群成员没有正常Networkheartbeat或Diskheartbeat时NM负责将成员踢出集群，被踢出集群的节点将发生节点重启(reboot)。NM服务通过OCR中的记录(OCR中记录了Interconnect的信息)来了解其所需要监听和交互的端点，将心跳信息通过网络发送到其他集群成员。同时它也监控来自所有其他集群成员的网络心跳Networkheartbeat，每一秒钟都会发生这样的网络心跳，若某个节点的网络心跳在misscount(bytheway:10.2.0.1中Linux上默认misscount为60s，其他平台为30s，若使用了第三方vendorclusterware则为600s，但10.2.0.1中未引入disktimeout；10.2.0.4以后misscount为60s,disktimeout为200s；11.2以后misscount为30s:CRS-4678:Successfulgetmisscount30forClusterSynchronizationServices,CRS-4678:Successfulgetdisktimeout200forClusterSynchronizationServices)指定的秒数中都没有被收到的话，该节点被认为已经”死亡”了。NM还负责当其他节点加入或离开集群时初始化集群的重置(Initiatesclusterreconfiguration)。在解决脑裂的场景中，NM还会监控votingdisk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下，试想我们的环境中存在大量的节点，以Oracle官方构建过的128个节点的环境为我们的想象空间，当网络故障发生时存在多种的可能性，一种可能性是全局的网络失败，即128个节点中每个节点都不能互相发生网络心跳，此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败，128个节点中被分成多个部分，每个部分中包含多于一个的节点，这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(votemesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了，这个时候NMReconfiguration就需要用到votingdisk投票磁盘。因为NM要使用votingdisk来解决因为网络故障造成的通信障碍，所以需要保证votingdisk在任意时刻都可以被正常访问。在正常状态下，每个节点都会进行磁盘心跳活动，具体来说就是会到投票磁盘的某个块上写入disk心跳信息，这种活动每一秒钟都会发生，同时CSS还会每秒读取一种称作”killblock”的”赐死块”，当”killblock”的内容表示本节点被驱逐出集群时，CSS会主动重启节点。为了保证以上的磁盘心跳和读取”killblock”的活动始终正常运作CSS要求保证至少(N/2+1)个投票磁盘要被节点正常访问，这样就保证了每2个节点间总是至少有一个投票磁盘是它们都可以正常访问的，在正常情况下(注意是风平浪静的正常情况)只要节点所能访问的在线votingdisk多于无法访问的votingdisk，该节点都能幸福地活下去，当无法访问的votingdisk多于正常的votingdisk时，ClusterCommunicationService进程将失败并引起节点重启。所以有一种说法认为votingdisk只要有2个足以保证冗余度就可以了，没有必要有3个或以上votingdisk，这种说法是错误的。Oracle推荐集群中至少要有3个votingdisks。补充1：Question:有同学问那么votingdisk必须是奇数个呢？Answer:实际上我们仅仅是推荐使用奇数个votedisk，而非必须是奇数个。10gR2中votedisk的数目上限是32个。Question我们可以使用2或4个votedisk吗？Answer:可以的。但是2、4这样的数目在“至少(N/2+1)个投票磁盘要被节点正常访问”这一diskheartbeat的硬性算法下是不利的：当我们使用2个votedisk时，不能发生任意个votedisk的心跳失败当我们使用3个votedisk时，不能发生大于1个的votedisk心跳失败当我们使用4个votedisk时，不能发生大于1个的votedisk心跳失败，这和3个时的容错率是一样，但是因为我们有的votedisk，这会导致管理成本和引入的风险增长当我们使用5个votedisk时，不能发生大于2个的votedisk心跳失败当我们使用6个votedisk时，仍然不能发生大于2个的votedisk心跳失败，同样的因为比5时多出一个，也会引入不合理的管理成本和风险补充2：Question:若节点间的网络心跳正常，且节点所能正常心跳的votedisk大于不能正常访问的，如3个votedisk时恰巧有1个votedisk的diskheartbeat超时，此时Brainsplit会发生吗？Answer:这种情况即不会触发BrainSplit，也不会引发节点驱逐协议(evictionprotocol)。当单个或小于(N/2+1)个的votingdisk心跳失败(diskheartbeatfailure)时，这种心跳失败可能是由于短期内节点访问votingdisk发生I/Oerror错误而引起的，此时css会立刻将这些失败的votingdisk标记为OFFLINE。虽然有一定数量的votingdiskOFFLINE了，但是我们仍有至少(N/2+1)个投票磁盘可用，这保证了evictionprotocol不会被调用，所以没有节点会被reboot重启。紧接着nodemonitor模块的DiskpingMonitorThread(DPMT-clssnmDiskPMT)会重复尝试访问这些失败的OFFLINEvotingdisk，若这些投票磁盘变得再次可I/O访问且经过验证其上的数据也没有讹误，那么css会再次将此votingdisk标记为ONLINE；但是如果在45s(这里的45s是基于misscount和内部算法获得的)内仍不能正常访问相关的votingdisk，那么DMPT将在cssd.log中生成警告信息，如：（1）alert 日志sqlplus>show parameter background
（2）监听日志
lsnrctl>status
ps：如果想重命名监听日志的话，要执行set log_status off命令，取走过后，执行set log_status on
（3）CRS日志（grid）：
首选查看alertlog：
$CRS_HOME/grid/log/hostname/alertdbserver1.log
Clusterware后台进程日志：
crsd.Log: $ORA_CRS_HOME/grid/log/hostname/crsd/crsd.Log
ocssd.Log: $ORA_CRS_HOME/grid/log/hostname/cssd/ocsd.Log
evmd.Log: $ORA_CRS_HOME/grid/log/hostname/evmd/evmd.Log
