021.笔记：10G RAC-管理RAC环境中的数据库-CSDN博客

1.RAC的本质
1.1实例命名
数据库名总是相同的，因为它与物理数据库本身相关。另一方面，实例名与每个节点上的内存相关，因此实例名在各节点上必须是唯一的。

1.2RAC环境中的spfile
alter system set db_cache_size=500m scope=spfile sid='ractest1'; --sid='*'

1.3RAC特定参数
instance_number和thread参数是特别用于RAC环境的参数代表，每个实例必须拥用与之相关的唯一值。
CLUSTER_DATABASE：大多数情况下，所有实例都必须将此值设置为TRUE。
当进行升级或打补丁的时候或“修改归档模式或闪回模式”时，除了某个实例外的所有实例都需要被关闭，而只有该单个实例被打开并将CLUSTER_DATABASE设置为FALSE。
CLUSTER_INTERCONNECTS：用于指定集群中IPC通信的网络。
ACTIVE_INSTANCE_COUNT：只应用在两节点集群中。如果在一个两节点集群中将该参数值设为1，那么它会把启动的第一个实例作为主实例，第二个实例作为辅实例。
MAX_COMMIT_PROPAGATION_DELAY:定义了本地实例的SGA中系统变更号(SCN)在被LGWR进程刷新之前保持的最长时间，默认情况下，将参数值设置为700（7秒）通常就足够了。
(propagate:传播；delay[di'lei]延迟)

1.4 RAC实例中附加的后台进程
这些进程的目的是为了以协同方式联合工作，从而维护多个实例同时访问资源所必需的锁定，并及时地确保这些资源对于最需要这些资源的实例是可用的。
select name,description from v$bgprocess where paddr<>'00';
(1).DIAG:诊断守护进程
诊断守护进程负责捕获RAC环境中进程失败的相关信息，并将跟踪信息写出用于失败分析。
(2).LMS：锁管理器服务器进程（高速缓冲区数据块的缓存一致性）
LMS进程（或称为全局缓存服务进程）负责为缓存融合请求在实例间传递块。
(3).LCK:锁进程
锁进程管理那些不是缓存融合(cache-fusion)的请求，例如行缓存请求和库缓存请求。
(4).LMD:锁管理器守护进程
负责管理全局队列和全局资源访问。在实例的内部，LMD进程管理来自集群中其他实例的锁请求。
(5).LMON:锁监控器进程
全局队列服务监控器，在实例加入集群或离开集群时，该进程负责重新配置锁资源，并负责动态锁的重新控制。
(6).缓存融合简介
缓存融全本质上是通过互连网络在集群内各节点的SGA之间进行块传递，这样做避免了必须首先将块推送到磁盘，然后再重新读入到其他实例的缓存中。
当一个块被读入RAC环境中某个实例的缓存时，该块会被赋予一个锁资源（与行级锁不同），以确保其他实例知道该块正在被使用。之后，如果另一实例
请求该块的一个副本，而该块已经处于前一实例的缓存内，那么该块会通过互连网络直接传递到另一实例的SGA。
(7).动态资源控制
请求块的实例可能相同，也可能不同。ORACLE database 10g引入了动态控制的概念，它的主要概念是如果针对特定块的锁被某个实例请求的频率要高于
其他实例的请求频率，那么该锁最终会被移至请求频率高的实例的SGA中，从而使后续的锁请求效率更高。
(8).重新配置
如果某个节点崩溃，那么在剩余实例间重新控制该节点拥有锁的进程称为重新配置。

1.5 RAC环境中的缓存一致性
对于RAC数据库而言，互联网通信事实上可被分为两类--全局缓存服务(GCS)和全局队列服务(GES).
1.全局缓存服务
确保一个实例在任何时刻想修改一个数据库块时，都可获得一个全局锁资源，从而避免另一实例同时修改该块的可能性。
LMS进程是GCS的关键组成部分。
2.全局队列服务
全局队列服务(global enqueue service,GES)主要负责维护字典缓存和库缓存内的一致性。
LMON、LCK和LMD进程联合工作来实现全局队列服务的功能。
3.GV$视图
GV$视图的数据量=V$视图数据量*实例数
4.使用AWR监控RAC度量
RAC环境中由自动工作负载仓库所生成的报表会包括一个名叫“RAC统计数据”的部分，这里可以容易地收集与全局缓存和全局队列相关的操作信息。可以
快速地查看本地缓存和远程缓存的读取频率、需要对磁盘进行读取的频率以及各种操作的平均获取时间。一般而言，这些平均值不应当高于上限30ms，通常
是比较低的。
互连网络的性能：如果发现互连网络的性能变差，那么应当首先查看互连网络的硬件。此外，应当确保将UDP(?)缓冲区设置得尽可能高。在Linux上，可以
使用下列命令对此进行检查：
sysctl net.core.rmem_max net.core.wmem_max net.core.rmem_default
或直接查看/proc/sys/net/core

2.RAC环境中REDO与UNDO的管理
2.1 重做日志与实例恢复
如果由于节点的突然崩溃而需要进行实例恢复，那么剩余的某个实例必须对联机重做日志进行访问，从而执行实例恢复。因此，即便实例已经无法重启，重做
日志中的数据仍是可访问的，而且可以被其他存活的实例前滚，并回滚所有未提交事务。这在RAC环境中可以立即进行，无需等待崩溃的实例恢复联机状态。
实例恢复由集群中剩余的存活节点进行，这说明当崩溃实例被重新启动时，不再需要在该实例上进行实例恢复，因为实例恢复已经完成了。如果多个实例崩溃，那么
只要存在一个存活的实例，联机实例恢复仍然可以进行。如果所有实例都崩溃了，那么将由第一个重新启动的实例执行崩溃恢复。

2.2 重做日志与介质恢复
如果必须在某些或全部数据库文件上进行介质恢复，那么必须在单节点或实例上进行。如果要恢复整个数据库，那么首先必须关闭所有其他实例，然后将数据库安装到
选择进行恢复的节点上。如果要恢复某个不会影响整个数据库的文件（或文件集），那么所有实例可以继续运行，但要求进行恢复的文件必须脱机执行，不允许他人访问。
(1).重做线程
线程号由spfile参数.TREEAD=n定义
select *
from v$log a,v$logfile b
where a.group#=b.group#;

(2)多线程与介质恢复
如果需要恢复一个或多个数据文件，那么不管您在数据库打开时进行恢复还是在将数据库安装到单独实例上时进行恢复，都需要用到来自所有重做日志线程的归档重做日志，
并且这些归档重做日志必须在执行恢复任务的实例的归档目标中是可用的。

集群文件系统环境中的归档
如果在OCFS上的同一个目录上进行归档，目录锁会导致第二个实例上会出现一个短暂的延迟。为每个实例在OCFS驱动器上创建单独的目录是非常明智的。这样做会在某种程
度上丧失方便性，因为当需要进行恢复时，您必须将文件移动或复制到相同的目录中，但是，这样做可以避免在常规操作期间引起性能除低的可能。

ASM环境中的归档
如果使用ASM存储数据文件，那么也可以使用一个ASM磁盘组作为闪回恢复区。默认情况下，LOG_ARCHIVE_DEST_10的值被自动地设置为DB_RECOVERY_FILE_DEST的位置。

*.LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/oradata/grid/archive/'
*.LOG_ARCHIVE_DEST_2='LOCATION=USE_DB_RECOVERY_FILE_DEST'
*.db_recovery_file_dest='+ASM_TEST'
*.db_recovery_file_dest_size=2147483648

RAC环境中进行归档时需注意的其他要点
Oracle会周期性地介入并强制在看起来不那么活跃的实例上进行日志切换。如果发现已经暂时停止的某实例的归档日志仍在生成，那么可以使用下列命令禁止该线程：
alter database disable public thread 3;

2.3 在RAC数据库上启用归档和闪回功能
一个数据库在启用闪回之前必须首先进入归档日志模式。
第一步：mkdir /ocfs/oradata/archive
第二步：alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' scope=spfile sid='*';
alter system set log_archive_dest_2='LOCATION=/ocfs/oradata/archive/' scope=spfile sid='*';
第三步：alter system set log_archive_start=true scope=spfile sid='*';
我们为了向下兼容而采用了该命令，但Oracle Database 10g实际上不提倡使用该参数。
第四步：设备用于本地实例的CLUSTER_DATABASE为FALSE之后，就可以将数据库置为归档日志模式。通过设置CLUSTER_DATABASE=FALSE，接下来的关机和启动安装实际上默认
地做了一次独占式安装（Mount Exclusive），这对于将数据库置于归档日志模式和闪回数据库功能的打开都是必需的：
alter system set cluster_database=false scope=spfile sid='ractest1';
第五步：关闭所有实例。确保所有实例被完全关闭：
shutdown immediate
第六步：安装来自实例ractest1的数据库（其中CLUSTER_DATABASE被置为FALSE），然后将数据库置为归档日志模式。
startup mount
alter database archivelog;
第七步：确认数据库处于归档日志模式并使用了适当的参数：
archive log list
第八步：show parameters recovery_file
第九步：只要数据库处于归档日志模式，就可以在数据库仍然以独占模式（CLUSTER_DATABASE=FALSE）安装时启用闪回技术：
alter database flashback on;
第十步：确保启用了闪回功能，并验证保持目标：
select flashback_on,current_scn from v$database;
show paramters flash
第十一步：alter system set cluster_database=true scope=spfile sid='*';
alter system set cluster_database=true scope=spfile sid='ractest1';--应执行于第四步对应的命令
第十二步：关闭该实例，然后重启所用集群数据库实例。

注意：当归档日志被置于一个ASM磁盘组上时，这些归档日志将不会根据LOG_ARCHIVE_FORMAT进行命名，而是使用由Oracle决定的系统生成名。

2.4.RAC中的UNDO
与重做日志类似，每个实例也需要拥用自己单独的撤销。在这种情况下，每个实例需要拥用其自己的撤销表空间，该表空间也位于共享驱动器上。撤销表空间.UNDO_TABLESPACE
参数定义。如果执行实例恢复，在实例恢复期间是需要撤销操作的。然而，在普通的动作过程中，其他节点也会需要读取撤销表空间。
撤销表空间可以使用ALTER SYSTEM命令，在实例活动的情况下进行动态更改。

3.关于RAC的其他注意事项
3.1管理ASM环境
当使用DBCA创建一个RAC数据库时，DBCA会自动地在每个节点上创建启用RAC的ASM实例。
默认情况下，参数文件是一种常规pfile，不能放在共享磁盘上，其原因是参数文件必须由ASM实例在其启动时进行读取，
但由ASM管理的磁盘组在ASM实例启动后不会立即被安装，是不可访问的。
如果用于任意RAC实例的数据库文件位于ASM磁盘组上，那么每个ASM实例必须定义并安装那些磁盘组。

3.2RAC环境中的补丁
对于某些补丁，Oracle Database 10g允许进行滚动补丁更新，意思是可以将一个补丁应用于某个已关闭的给定节点和实例，而保持集群中的其他实例运行。一旦补丁被应用
于第一个节点，那么第一个实例就可以恢复联机，然后将下一个实例关闭并进行补丁安装。这种功能要依赖于补丁本身，并且对于某些补丁有效，但并不是整个补丁集合。
对于不合乎滚动更新要求的补丁，通过实时应用集群环境和一个逻辑备用数据库，也可以在补丁应用期间保持正常运行。当在RAC环境中为节点和实例打补丁时，通过切换
至逻辑备用数据库，仍然可以令用户群照常运行。在补丁安装完成时，用户能够从逻辑备用环境中切换回主集群环境。

3.3企业管理器网格控制台与RAC
(1)网格控制台
完整安装，不小于5G的安装空间。（不包含安装包占用的空间，压缩包加解压包4G）
“find . -cmin 1”命令辅助获得涉及到的安装日志文件

注意：如果你在其他机器访问这个网址，请先修改host文件，把服务器的ip地址与hostname加入进去，然后使用
http://hostname:4899/em这个网址打开，不要使用http://ip:4899/em，因为这是打不开滴~~~~
emctl start oms

This information is also available at:
/disk2/oracle/OracleHomes/agent10g/sysman/setupinfo.txt
See below for information pertaining to your Enterprise Manager installation:
1. Use the following URL to access the Enterprise Manager Grid Control:
http://nodegrid:4889/em
2. The Enterprise Manager installation includes an Oracle Application Server instance, which is administered using a special "ias_admin" user account. The following information was defaulted for the embedded Application Server instance:
Instance Name: EnterpriseManager0.nodegrid
ias_admin password: This password is the same the SYSMAN account.
3. The connection details for the Enterprise Manager Repository are:
Host: nodegrid
Port: 1521
SID: emrep
4. The Enterprise Manager Release Notes are located at:
/disk2/oracle/OracleHomes/agent10g/relnotes/README_EM.htm

附件：转
(2).应用代理
oem 收集管理数据库信息的方法是在被管理的节点上部署它的代理软件(agent)，通过代理软件来收集本机的所有信息，以xml的信息存储到本地，再通过数据上载的进程，将xml文件上载到oem server机器上，server端的程序再将这些xml信息写入到oem数据库里。这些xml文件也是通过http方式发给Oem服务器的app server，再通过它转给oem service.

弄清楚了Oem架构这后，我们接着往下进行，就是在需要管理的机器上部署10g oem agent.

一）oem10g grid control 应用部署

oracle为agent部署提供了4种方案.

1:直接在需要部署的节点上安装agent软件

2:脚本安装

3:克隆

4:直接在oem界面上进行批量部署。

下面对每一种安装方案作具体的描述，读者可以根据自己的实际情况选择安装。

1:通过agent软件安装

这种方法比较传统和直观，就是在需要部署的节点上直接在本地安装agent软件，安装成功后通过在配置文件中指定一个oms地址来保证agent和oms的正确通讯。

另外一种需要这种安装方式的是当这个节点和oms使用的不是一种OS平台的情况下，必须要使用这种方式，这个需要用户自己到Oracle网站上下载适于本平台的agent软件，但这并不会影响oms的管理。

由于这种安装比较简单，所以在这里不作过多的解释。

2:基于脚本的部署（推荐）

在oem10g的体系中对安全的要求比较高，所以在文件传递上也使用了hhtps的加密协议。在机器的访问上Oracle采用的是ssh方式访问，所以在oem体系中，机器上启用ssh是必须的，至于ssh的启用方法不在本文档的讨论之列。

首先要在oms端运行以下命令，以便于确保数据通过ssh方式在server端和client段进行传递。

OMS_HOME/sysman/prov/resources/scripts/sshUserSetup.sh

具体的命令如下:

sshUserSetup.sh -hosts "host1 host2" -user sjohn

其中-hosts是你要部署agent的机器的名称，如果此处你写hostname，那么你需要把hostname和机器的Ip对应信息写到oms机器的/etc/hosts上，否则可能无法解析hostname。这里可以写很多个需要部署的hosts的名字。

-user是登录到该机器的用户名，密码则在运行过程中输入。

在各个过程中，该脚本首先测试到远程机器的可用性，使用ping的命令，然后使用ssh命令进行登录验证，确保ssh可用。

以上工作完成后就可以进行部署了，oracle文档上还有几个步骤，我觉得可以省略，反正我没用到。

下面拿一台机器举例进行agent部署。

a:用oracle用户登录需要部署agent的机器，在oracle用户默认路径下编辑c shell profile:./bashrc 在最后加入:

set TZ=PRC

设置时区，保存退出。

source ./bashrc 使环境变量生效。

注:这个操作是设置agent host的时区time zone，是agent和oms数据传递时必需的，不能忽略。

b:首先用oracle用户在ORACLE_HOME/下创建一个目录，一般是OracleHomes，

c:使用ftp，或者http，scp等方法，从Oms机器上下载安装脚本，该安装脚本路径如下:

$ORACLE_HOME/OracleHomes/oms10g/sysman/agent_download/linux/agent_download.linux

或者：（$ORACLE_HOME/OracleHomes/oms10g/sysman/agent_download/10.2.0.3.0/linux_x64/agentDownload.linux_x64）--此乃64位系统的路径

d:在需要部署agent的机器上，首先给该脚本可执行的权限。

e:运行安装脚本:

./agent_download.linux -b /opt/oracle/OracleHomes

其中-b参数指定agent安装的路径。

中间不需要交互，Oracle使用的是silent方式的安装。

安装成功或者失败都有日志.

注意：如果以前部署过agent，只删除$AGENT_HOME目录重新部署不会成功，会遇到下面错误而终止：

Initializing Java Virtual Machine from /tmp/OraInstall2010-01-26_03-45-43PM/jre/1.4.2/bin/java. Please wait...
Completed with Status=255

要解决此问题，需要编辑oraInventory目录下的ContentsXML/inventory.xml文件，移除以前安装过的HOME NAME条目。

另外，我用此方法部署好agent，但总是启动失败，检查emagent.log，发现有如下错误信息：

2011-01-27 15:13:25 Thread-4136883904 Invalid TIMEZONE for agent not compatible with OMS timezone, Agent will shutdown. Update agentTZRegion property in /opt/oracle/agent10g/sysman/config/emd.properties file (00900)

原来是时区的问题，比较OMS主机与目标主机上agent的参数配置文件（emd.properties）最后一行，发现目标主机是agentTZRegion=PRC，

而OMS主机是agentTZRegion=Asia/Chungking，

看来设置时区环境变量（set TZ=PRC）没有作用，于是去除时区环境变量，将目标主机改成与OMS主机相同，即：agentTZRegion=Asia/Chungking

之后就启动成功了。

3: clone 方式部署agent。

这个比较简单。

首先需要有一个已经装好的可以正常运行的agent节点，然后将这个节点下agent/目录下所有的文件打一个tar,传到需要部署的节点上，解tar，确定目录正确。

然后运行emca -f 重新配置agent。

检查agent是否运行正常。

4:通过oem进行agent部署。

这个部署是通过oem的web界面进行配置，适合做企业级的大规模的部署。

做这个的前提是oms已经安装，并且可以正常访问，oms的安装和访问前便已经提到了。

步骤如下:

1:登陆oms。

2:选择部署(deplay)签，选择安装(fresh install).

3:进入安装界面，首先和安装路径，输入你agent想要的安装路径。然后选择你的agent的运行平台，这种部署，我发现这中部署agent的平台只能和oms相同的平台，其他的平台需要到

Oracle的官方网站上下载相应平台的agent软件进行安装。

4:Host栏，输入需要部署的host的Ip,或者hostname,如果中间用逗号分隔。如果输入的是hostname，需要保证oms机器可以通过hostname解析出Ip地址，可以通过修改/ect/hosts文件来达到hostname和ip的对应。

5:输入一个操作系统的用户名和密码，基本上就是你的oracle用户和密码。

6:输入Oms的安全口令，随便输一个，自己记住就可以了。

其他的基本上都可以不添，记住最后运行完之后执行一个agent/下的root.sh脚本就可以了。

7:看一下，运行结果，对于运行失败的节点，要看相应的安装日志。

OEM的部署基本上就是这样，上面说到的只是方法，我们在安装过程中出现了很多错误，也察看了很多文档，下面会对这些错误作一些解释和讨论。

　二）oem10g grid control 应用总结

前面已经介绍了Oms和agent的部署方法，这一部分笔者准备把使用10g oem grid control 遇到的问题和使用的心得汇总一下。

一些比较重要的路径和文件

Oms server端和agent端的目录结构基本上相似:区别在于oms端路径的最上层叫oms10g,而agent端的最上层的路径叫agent10g.下面的结构基本上相似，下面说一下几个比较重要的路径和文件。

1: oms10g/bin 和agent10g/bin分别存放了Oms和agent各自的可执行文件，其中emctl文件时用来管理oms或agent的命令，前面说过，由于在 oms server端，也同时安装了agent，所以在oms server上运行emctl命令时要特别主要，需要进入到各自的bin./下面运行，否则可能会出错。

比如想启动oms，可以进入到oms10g/bin 下执行:

./emctl start oms 这个命令会同时启动其他oms需要的服务，比如http server。

具体的所有用法可以通过敲入:./emctl 回车就可以看到。

对于agent的管理，须要进入到agent10g/bin下，以下是一些有用的命令:

./emctl start agent 启动agent service

./emctl stop agent 停止agent service

./emctl status agent 察看agent的运行情况，在出现的信息当中，有一个信息比较重要，last successfully upload time，如果值为null，说明没有数据上传，需要检查一下相关的配置是否正确。或者直接发出:./emctl upload看看信息。

oms 和agent的错误信息都存放在:oms10g(agent10g)/sysman/log

我在安装的过程中出现过很多次agent无法upload的情况，原因大多是本地的TZ变量没有设置正确。TZ就是 time zone时区，是oem10g中比较重要的一个变量，它要求agent节点上必须设置时区变量，并且时区变量的值需要符合oracle要求的时区变量值，这个值了一在agent10g/sysman/admin/emd/supportedtz.lst文件中找到。设置TZ的方法在部署篇里已经讲过了。

oem10g的原理和工作方式

oem10g的agent端的数据收集全部通过perl脚本来完成。扩展名为:*.pl,这些脚本可以在agent10g/sysman/admin/scripts/下找到。

agent 程序首先会把采集到的信息写到本地的xml文件当中，然后再将该文件upload到oms端去，oms service再将xml文件写入到oms自己的repository库里。刚才我们说的./emctl upload其实就是手工上载本地的xml文件。这些生成的文件可以在:agent10g/sysman/admin/upload下找到。

agent程序的发现方式:

当agent 部署到一个节点上时，他首先搜索$ORACLE_HOME/oraInventory下安装的所有oracle产品。以便确定需要收集那些产品的信息，比如他只发现了一个数据库产品，他们它就会只运行收集数据库和主机信息的脚本。对于一个节点来说，agent确定需要收集那些内容的信息写在如下文件中，可以手工修改:agent10g/sysman/emd/targets.xml。

另外一个比较重要的文件是 agent10g/sysman/config/emd.properties 他就是没一个agent的配置文件，agent所有的属性都在里面，比如oms的url,TZ啊什么的，可以手工修改，修改完之后，通过执行. /emctl reload来使之生效。

oem10g的使用心得

oem10g在易用性较8i,9i笨重的java客户端来看，真是有一种脱胎换骨的轻松感觉。你不需要再花很多的时间等待那个图形界面的出现了，只要通过浏览器输入hhtp://oemhost: 4889/em就可以轻松登陆oem.感觉速度比8i和9i都快不少。而且界面有很多图标，看起来很舒服。

oem10g另外一个功能就是加入了告警功能，它会将所有认为有问题的信息以在首页上提示出来，甚至连alert文件中的告警信息也可以弄出来，并且所有的指标都可以自己定义告警阈值，我们单位原原本也有一套数据库监控系统，可是和这个比，简直是小巫见大巫了。

10g oem另外一个令人激动的特点是提供了一个叫adviser的建议功能，它可以帮助你对内存，Undo segent,sql进行相应的优化调整，给出好的建议。但这个功能只能对10g数据库可用。尽管oem10g可以管理从8.1.7.4以后的数据库，但这个功能只对10g的数据库可用。

报表，oem10g提供了很好的报表功能，包括所有该节点上所有监控的信息，而且报表很漂亮。对于那些定期需要向领导作报表的dba来说，这是个不错的工具。