rac 学习日记

最新推荐文章于 2024-07-16 10:28:31 发布

cuichenkai7892

最新推荐文章于 2024-07-16 10:28:31 发布

阅读量92

点赞数

文章标签：数据库嵌入式操作系统

一些内容主要是从《大话 rac》里面摘抄的，便于以后记忆！
Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 1 、ocr

首先，先来看下 ocr 的官方说明：

the OCR is a file that manages cluster and Oracle Real

Application Clusters (Oracle RAC) database configuration information.

The OCR contains information about the cluster node list, instance-to-node mapping information, and information

OCR的备份：

Oracle 每4个小时对其做一次备份，并且保留最后的3个备份。

可以通过 ocrconfig –showbackup 来查看备份所在的文件和目录。

“健忘“问题是由于每个节点都有配置信息的拷贝，修改节点的配置信息不同步引起的。要想解决“健忘”问题，最简单的办法就是整个集群只有一份配置，各节点共用这份配置，无论在哪个节点修改配置，都是修改相同的配置文件，这样就保证修改不会丢失。Oracle采用的方法就是把这个配置文件放在共享存储上，这个文件就是OCR Disk。

Ocr 维护方面的文档：

Metalink：ID 428681.1

OCR、Vote disk Maintenance Operations(ADD、REMOVE、REPLACE、MOVE), including moving from RAW Devices to Block Devices

Metalink：ID 399482.1

How to Recreate OCR、Voting Disk Accidentally Deleted

2、Voting Disk

Voting Disk这个文件主要用于记录节点中成员状态，在出现“脑裂”时，仲裁哪个Partition获得集群的控制权，而其他Partition必须从集群中剔除。

在Clusterware安装以后，就可以通过下面命令来查看Voting Disk的位置。

[oracle@rac1 ~]$ crsctl query css votedisk

0. 0 /dev/raw/raw2

1. 0 /dev/raw/raw8

3、Clusterware 后台进程

Clusterware由若干个进程组成，其中最重要的3个是CRSD. CSSD和EVMD。在安装Clusterware的最后阶段，会要求在每个节点执行root.sh脚本，这个脚本会在//etc/inittab文件的最后添加如下3行。这样以后每次系统启动时，Clusterwaxe也会自动启动，其中EVMD和CRSD两个进程如果出现异常，则系统会自动重启这两个进程，但是如果CSSD进程异常，系统会立即重启。

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

h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1

h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1

3.1、OCSSD

OCSSD这个进程是Clusterware最关键的进程，如果这个进程出现异常，会导致系统重启。这个进程提供CSS (Cluster Synchronization Serviee)服务。CSS服务通过多种心跳机制，实时监控集群健康状态，提供脑裂保护等基础集群服务功能。

css服务有两种心跳机制：一种是通过私有网络的Network Heartbeat，另一种是通过Voting Disk的Disk Heartbeat。

这两个心跳都有最大时延，对于Disk Heartbeat，这个时延叫作IOT (I/O Timeout)；对于Network Heartbeat，这个时延叫作MC (Miscount)。两个参数都是以秒为单位，缺省时IOT大于MC。在缺省情况下，这两个参数是Oracle自动判定的，并且不建议调整。

可以通过下面命令查看这两个参数设置：

[oracle@rac1 ~]$ crsctl get css disktimeout

200

[oracle@rac1 ~]$ crsctl get css misscount

3.2、CRSD

CRSD是实现“高可用性(HA)”的主要进程，它所提供的服务叫作CRS (Cluster Ready Service)服务。

上文己经提到，Oracle Clusterware是位于集群层的组件，它要为应用层资源(CRS Resource)提供“高可用性服务”。因此，Oracle Clusterwaxe必须要监控这些资源，并在这些资源运行异常时进行干预，包括关闭、重启进程或者转移服务。而CRSD进程提供的就是这些服务。

所有需要“高可用性”的组件，都会在安装配置的时候，以CRS Resource的形式登记到OCR中，而CRSD进程就根据OCR中的内容，决定监控那些进程、如何监控、出现问题时如何解决。也就是说CRSD进程负责监控CRS Resource的运行状态，并要启动、停止、监控、Failover这些资源。默认情况下，CRS会自动尝试重启资源5次，如果还是失败，则放弃尝试。

CRS Resource包括GSD (Global Service Daemon ), ONS (Oracle Nofitication Service Daemon ) 、 VIP、 Database. Instance和Service。这些资源被分成两类：GSD, ONS, VIP和Listener属于Noteapps类；而Database, Instance和Service属于Database-Related Resource类。这种分类方式也很好理解，Nodeapps就是说每个节点只需要一个就够了，比如每个节点只有一个Listener而Database-Related是说这些资源是和数据库相关的，不受节点的限制，比如一个节点可以有多个实例、每个实例可以有多个Service。

GSD, ONS. VIP这3种服务是在安装Oracle Clusterware的最后，执行VIPCA时创建并登记到OCR中的(参见第1章的图1-56到图1-61)；而Database、 Listener、 Instance和Service是在各自的配置过程中自动或手动登记到OCR中的。

3.2.1、GSD

Oracle 9i 的官方文档上是这么介绍这个服务的：（10g 的官方文档上没有这个的描述，真恶心）

Global Services Daemon (GSD)

The Global Services Daemon (GSD) records information such as connection requests from SRVCTL and stores these records the gsdaemon_node_name.log file in the $ORACLE_HOME/srvm/log directory. Clients of the GSD, such as SRVCTL, the DBCA, and Oracle Enterprise Manager, interact with the GSD to perform. various manageability operations on the nodes in your cluster.

Clients of the Global Services Daemon (GSD), such as SRVCTL, the DBCA, and Oracle Enterprise Manager, interact with the GSD to perform. various manageability operations on the nodes in your cluster database. You must start the GSD on all the nodes in your Real Applications Clusters database so that the manageability features and tools operate properly.

For example, if you start an instance using Oracle Enterprise Manager, then the Intelligent Agent launches a script. that contains SRVCTL commands. The GSD executes these commands which correspond to the requested operation.

GSD与rac的管理工具dbca srvctl oem进行交互，用来完成实例的启动关闭等管理任务。为了保证这些管理工具运行正常必须在所有的节点上先start gsd,并且一个GSD进程支持在一个节点的多个rac.gsd进程位于$ORACLE_HOME/bin目录下，其log文件为$ORACLE_HOME/srvm/log/gsdaemon.log

例如：假设使用oem工具来启动一个实例，oem把该任务传递给相应的智能引擎，该智能引擎生成一个包含SRVCTL命令的脚本文件，GSD进程读取该脚本文件并且执行该脚本，最后GSD把执行结果返回给智能引擎,近而智能引擎返回给OEM.

又例如，假设使用srvctl工具关闭所有的实例，GSD进程接受来自SRVCTL工具发出的请求，并在本地节点上执行该请求，然后把执行结果返回给SRVCTL会话。

You can use gsdctl commands to start, stop, and obtain the status of the GSD service on any platform. The options for gsdctl are:

* gsdctl start -- To start the GSD service

* gsdctl stop -- To stop the GSD service

* gsdctl stat -- To obtain the status of the GSD service

Gsd 是从 oracle 9i延续过来的，从我目前的测试来看，gsd 关掉对 srvctl 没有影响，但对 OEM 的影响未知，而且，就算开着也不见得有写日志到 $ORACLE_HOME/srvm/log/gsdaemon.log 中，还有，gsdctl 的命令似乎过时了，不管用。

Metalink：ID 156561.1

What is the Global Services Daemon (GSD) for Oracle9i Real Application Clusters?

3.2.2、ONS

官方文档上是这样描述的：

A publish and subscribe service for communicating information about all FAN events.

对于负责所有的 fan events 之间的通信。

这是我从 metalink 上摘抄下来的：

The purpose of the ons daemon

The Oracle Notification Service daemon is an daemon started by the Oracle Clusterware as part of the nodeapps. There is one ons daemon started per clustered node.

The Oracle Notification Service daemon is receiving a subset of published clusterware events via the local evmd and racgimon clusterware daemons and forward those events to application subscribers and to the local listeners, this in order to facilitate:

a. the FAN or Fast Application Notification feature or allowing applications to respond to database state changes. Fast Connection Failover (FCF) is the client mechanism which uses the FAN feature to achieve it. FCF clients/subscribers are JDBC, OCI, and ODP.NET in 10gR2.

b. the 10gR2 Load Balancing Advisory (the RLB feature) or the feature that permit load balancing accross different rac nodes dependent of the load on the different nodes. The rdbms MMON is creating an advisory for distribution of work every 30 seconds and forward it via racgimon and ONS to listeners and applications.

通过上面的黑体字，似乎 ons 另外一个重要的作用是 application failover。

ons 相关的应用切换是要应用开发时考虑到用ons的包才有用的，国内的话 99.9999% 没有用

metalink：ID 759895.1

The ONS Daemon Explained In Oracle RAC / Oracle Clusterware Environment

从这篇文章中，还是能学习到一些知识的：

下面的命令能看到 ons（包括 gsd 和 vip）的执行脚本

crs_stat -p ora..ons | grep ACTION_SCRIPT

ACTION_SCRIPT=/u01/app/oracle/product/crs/bin/racgwrap

下面的命令能看到 ons 的执行权限

crs_getperm ora.hostname.ons

Name: ora.hostname.ons

owner:oracle:rwx,pgrp:dba:r-x,other::r--,

ons 的配置文件位于

$ORA_CRS_HOME/opmn/conf/ons.config

3.3、EVMD

EVMD这个进程负责发布CRS产生的各种事件(Event )。这些Event可以通过两种方式发布给客户—ONS和Callout Script。用户可以自定义回调脚本，放在特定的目录下，这样当有某些事件发生时，EVMD会自动扫描该目录，并调用用户的脚本，这种调用是通过racgevt进程来完成的。

3.4、RACGIMON

RACGIMON这个进程负责检查数据库健康状态，负责Service的启动、停止、故障转移(Failover)。这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON进程定时更新。

3.5、OPROCD

OPROCD这个进程也叫作Process Monitor Daemon。如果在非Lines平台上，并且没有使用第三方的集群软件时，会看到这个进程，这个进程用来检测节点的Processor Hang (CPU挂起)，如果调度时间超过1.5秒，就会认为CPU工作异常，会重启节点，也就是说这个进程提供的是“I/O隔离”功能，从其在Windows平台上的服务名“OraFenceService”也能体会到它的功能。而在Linux平台上，是利用的hangcheck-timer模块来实现“IO隔离”功能的。

CRS一些官方的文档：

Metalink：ID 259301.1

CRS and 10g/11.1 Real Application Clusters --也介绍了 crs 底下的各个进程

Metalink：ID 259301.1

Troubleshooting 10g and 11.1 Clusterware Reboots

3.6、和单实例相比，后台进程的变化

3.6.1、LMSn

这个进程是Cache Fusion的主要进程，负责数据块在实例间的传递，对应的服务叫作GCS (Global Cache Service)，这个进程的名称来源于Lock Manager Service。从Oracle 9开始，Oracle对这个服务重新命名成Global Cache Service服务(GCS )，但是进程名字却没有调整。

这种进程的数量通过参数GCS_SERVER_PROCESSES来控制，缺省值是2个，取值范围为0-9。

the number of lms process to start depends on CPU, the default value is Max(CPU_COUNT/4,2),there is hidden parameter to change it . _lm _lms . This is FYI only , :-) , since I don't know how successful it would be if you test with these parameters change.

sys> select ksppinm, ksppdesc from x$ksppi where ksppinm like '%lms%';

KSPPINM KSPPDESC

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

_lm_lms number of background global cache server processes to start

_lm_dynamic_lms dynamic lms invocation

_lm_max_lms max. number of background global cache server processes

_lm_min_lms min. number of background global cache server processes

_lm_activate_lms_threshold threshold value to activate an additional lms

_lm_lms_waittime default wait time for lms

Metalink：ID 181489.1

Tuning Inter-Instance Performance in RAC and OPS --it so good!

3.6.2、LMD

这个进程提供负责的是Global Enqueue Service (GES )。具体来说，这个进程负责在多个实例之间协调对数据块的访问顺序，保证数据的一致性访问。它和前面的LMSn进程的GCS服务还有GRD共同构成RAC最核心的功能Cache Fusion。

3.6.3、LCK

这个进程负责Non-Cache Fusion资源的同步访问，每个实例有一个LCK进程。

3.6.4、LMON

各个实例的LMON进程进行会定期通信，以检查集群中各节点的健康状态，当某个节点出现故障时，负责集群重构、GRD恢复等操作，它提供的服务叫作Cluster Group Services(CGS)，这个进程的更多细节参见4.5.2小节。

前面的章节已经介绍了集群环境中“脑裂”的危害和解决办法。但是，在关键应用中只靠集群软件的健康监测是不够的。比如某个节点的Instance异常挂起，导致其不能对外提供服务。如果单从 Network, OS, ClusterWare几个层面看，可能检测不到这种异常的。因此，脱离了应用程序的集群状态检测是没有意义的，数据库必须有自我监控的机制。

Oracle RAC的LMON进程，被赋予了自检功能，这个功能就是LMON提供的CGS服务，总的来说，这个服务以下几个要点。

(1) LMON提供了节点监控(Node Montor)功能:这个功能是用来记录应用层各个节点的健康状态，节点的健康状态是通过一个保存在 GRD中的位图< Bitmap)来记录的，每个节点一位，0代表着节点关闭，1代表节点正常运行。各个节点间的LMON会相互通信，确认这个位图的一致性。

(2)节点上的LMON进程间会定期进行通信，这个通信可以通过CM层完成，也可以不通过CM层，直接通过网络层完成。

(3) LMON可以和下层的ClusterWare合作也可以单独工作。当LMON检测到实例级别的“.脑裂”时，LMON会先通知下层的Clusterware，期待借助于Clusterware解决“脑裂”问题。但是RAC并不假设Clusterware肯定能够解决问题，因此，LMON进程不会无尽等待Clusxerware层的处理结果。如果发生等待超时，LMON进程会自动触发IMR (Instance Membership Recovery也叫Instance Membership Reconfiguration ) 。LMQN进程提供的IMR功能可以看作是Oracle在数据库层提供的“脑裂”、”I0隔离”机制。