oraclerac日记

篇一：oracle rac日记

RAC的主要性能指标

经常有人问老白，一套RAc系统，如何评价CACHE FUSION方面有没有问题呢?这个问题 确实有点麻烦，任何一套系统的健康性分析都是很复杂的，因为每个系统都是不一样的，都有独立的特性。不过作为技术分析手段，还是有很多指标可以反映出系统的状况。本节将介绍主要的GCS/GES相关性能指标的情况。这些性能指标可以从AWR报告或者STATSPACK报告中获取，也可以从VSGES STATISTICS中读取。

总体负载与命中率指标

本节里的部分指标是Oracle l0g才有的，0racle 10g AwR报告在指标分析方面有了较大的改DBA遥过这些指标可以更容易地进行性能分析。以下是0racle l09的一个例子：

第一部分是LOAD PROFILE(负载情况)，从负载情况我们可以判断这个系统中GES／GCS的总体负载，由于每个系统都是个性化的，因此我们不能简单地通过这些指标来判断这个系统是否存在问题。不过我们可以进行横向的比较，在系统中采集性能基线，通过性能基线的分析确定这些指标的正常范围和平均值，通过这些基线指标来判断当前的指标是否处于正常范围。

第二部分Global Cached Efficiency Percentages是一个我们了解RAC中CACHE共享情况的重要指标。如上面数据，这个系统中99．54％的数据是从本地CACHE中获取，0．14％是从远程CACHE中获取，0．32％是从本地磁盘获取。这是一个做了应用分区的系统，两个实例的应用之间互相共享的数据十分少。而一个具有较为严重冲突的系统可能是这详的：

其中有差不多6％是从远程CACHE中获取的，这种情况下，CACHE FUSION可能带来较为严

重的冲突。从以下指标也可以看出流控的比例十分高：

在Oracle 9i中，可以从Statspack报告中看到类似的指标，彳i过没有109AWR报告那么清晰：

其中的Global cache hit rati0是通过CACHE FUSION来访问的CACHE的百分比。％ of remote buffer gets是通过远程BUFFER获取的BUFFER的百分比。Ratio of fusion VS physical writes表明脏块中全局脏块的比例，如果这个比例比较高，那么会对RAC的DBWR刷新脏块造成较大的性能影响。

1．6．2消息传输相关的指标

与消息传输相关的指标有以下几项，供读者参考。

- ％ of direct sent messages：进程直接发送消息成功的比例，没有通过代理，也没有进行流控。如果这个值比较高，说明消息发送不存在性能问题。

- ％ of flow controlled messages：进程无法直接发送消息的比例，这说明在发送消息的时候tickets不足，需要进行流控。如果这个比例比较高，说明发送传递存在性能问题。 - ％ of indirect sent messages：由于消息无法直接发送到远端而申请流控的比例，这说明发送消息的时候出现了远端接收失败，但是这种情况一般来说还未出现tickets不足。如果这个比例比较高，说明消息发送存在性能问题。

- Avg message sent queue time(ms)：一个非直接传输的逻辑消息在队列中的平均等待时间，也就是被发送的时间和进入队列的时间之间的时间差。一般来说这个时间越长说明队列中等待的消急太多或者消息传输太慢，正常情况下，这个值应该在0．1毫秒左右，并且不会超过1毫秒。

- Avg message sent queue time on ksxp(ms)：在IPC层面上发送一个消息到收到ACK回应的时间差，这个指标可以看出IPC的性能。正常情况下这个指标也应该小于l毫秒。 - Avg message received queue time(ms)：消息收到进入队列到开始处理的时间，一般来说这人时间越长说明等待处理的消息越多，一般来说这个值应该在0．1毫秒左右，甚至更低。

- Avg GCS message process time(ms)：平均处理一个BUFFER相关的GCS请求的时间，一般这个指标小于0．5毫秒。

- Ave GES message process time(ms)：平均处理一个锁操作消息的时间，一般来说这个指标小于0．5毫秒。

1.6．3 GLOBAL CACHE SERVICE的相关指标

与GLOBAL CACHE SERVICE相关的指标有以下几项，供读者参考。

- Ave global cache get time(ms)：一个GLOBAL CACHE的获取时间，计算公式为10* Global cache get time／global cache gets，一般来说这个指标应该小于5毫秒，如果大于5毫秒，说明系统负载较大，CPU处理能力不足或者RAC INTERCONNECT的负载过高，导致RAC INTERCONNECT的性能下降。如果这个指标超过20毫秒，对系统的性能影响将十分大。 - Ave global cache convert time (ms)：这个指标是对一个DATA BUFFER的访问权限

转换所需要的平均时间，计算公式是10*Global cache convert time／global cache converts。这个指标一般来说是针对从S向X转换的，从X向S转换是开销十分小的操作，并不在在统计范围内。这个指标一般来说应该在4毫秒左右，超过20毫秒说明RAC的性能可能存在问题。

- Ave time to process CR block request(ms)：这个指标统计一个CR BLOCK请求的时间，包含生成CR BLOCK、刷新CR BLOCK和发送CR BLOCK的时间，兰0racle 10g的AWR报告里，这个指标被分解为3个部分(Avg global cache cr block build time、avg global cache cr block flush time、Avg global cache cr block sendtime)，这个值正常范围是在0．1毫秒到l毫秒，在负载较高的系统，这个指标可能会更高一些，不过如果这个指标超过10毫秒，可能会对系统的性能有较大的影响。在10g中，这个指标被分解为3个指标，从这3个指标我们更容易判断问题出在哪个环节上。

- Ave receive time for CR block(ms)：一个CR BLOCK从发起请求到收到的时间，一般来说，这个指标在0．3--4毫秒，在负载较高的系统中，这个指标可能会略高，如果这个指标超过12毫秒，我们就需要关注，因为可能会对系统的性能造成较大的影响。

- Ave time to process current block request(ms)：处理一个CURRENT状态的BLOCK请求的处理时间，这个指标也包含3个部分PIN BUFFER的时间、FLASH的时间和发送的时间。一般情况下这个指标在3毫秒左右，负载较高的系统，该指标可能较高，不过大于20毫秒的时候就需要关注了，因为这种情况系统的性能可能受到了较为严重的影响。

- Ave receive time for current bl

1.7如何阅读SYSTEMSTATE DUMP

阅读SYSTEMSTATE DUMP是处理Oracle故障的时候经常要面对的任务，在这本书里，很多地方老白都是通过TRACE文件来进行分析的：因此本节就专门讨论一下如何阅读DUMP文件。

首先我们看一份DUMP文件，需要知道一份DUMP文件里有哪些内容，一般来说，一份 SYSTEMSTATE DUMP中包含了以下内容。

- DUMP文件头。

- PROCESS DUMP：DUMP时所有的PROCESS的DUMP信息，每个PROCESS一个专门的章节。 - CALL DUMP：在PROCESS DUMP中，包含了CALL DUMP。

- SESSION DUMP：在每个PROCESS DUMP中，都会有1个或多个SESSION DUMP(如果是MTS，可能一个PROCESS DUMP中包含多个SESSION DUMP)。

- ENQUEUE DUMP。

- BUFFER DUMP：在SESSION DUMP中可能会包含BUFFER DUMP。

在阅读SYSTEMSTATE DUMP的时候，我们一般来说首先会使用ASS工具来进行分析，ASS 工具是Oracle的工程师编写的一个AWK脚本，用于分析SYSTEMSTATE DUMP文件，找出DUMP 中可能存在问题的地方，1．7．8小节中有详细介绍，并且列出了ass.awk vl.0.9的脚本。通过ASS的输

篇二：5.5 Oracle 11g RAC 的安装日志

Oracle 11g RAC 在 CentOS 5.5 的安装日志 (2011-12-27 13:16)

标签: 服务器 光纤 Oracle 存储器 Linux 分类： oracle 集群

Oracle 11g RAC 在 CentOS 5.5 的安装日志

[日期：2011-08-07] 来源：Linux社区 作者：miyatang

服务器

DELL R410 2台

CPU INTER E5620 .4GHz 12M4C

MEM 64G

DISK 300G

存储器

DS3512

DISK 600G*12 RAID5

（因为JS以次充好，在服务器光纤卡上，搞了一个月，才把问题解决掉。

出现问题：

1.服务器时不时找不到存储器；

2.在存储器设置端，找不到光纤卡接口。

3.服务器重启后，找不到存储器，要存储器重启后才可找到

最后还是用一块4GB的当了8GB给了我们。速度肯定是打折了。

那个气呀。使用不同的硬件产品，就是麻烦）

软件环境：

CentOS 5.5 64bit

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0（64位）

1、服务器本地磁盘分区：

Disk /dev/sda: 300.0 GB, 300000000000 bytes

255 heads, 63 sectors/track, 36472 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Device BootStartEndBlocksId System

/dev/sda1* 1 2520078183 Linux

/dev/sda2 26 36472292760527+ 8e Linux LVM

使用了LVM 分区，后使用卷。

关于LVM 资料如下：

http://hi.baidu.com/dongfangmn/blog/item/23f7ccd813c9213831fa1c67.html

2、IP规划

[root@rac2 app]# cat /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 localhost.localdomain localhost

#::1 localhost6.localdomain6 localhost6

#public ip

192.168.18.101 rac1

192.168.18.103 rac2

#priv ip

192.168.0.101 rac1-private

192.168.0.103 rac2-private

#vip ip

192.168.18.121rac1-vip

192.168.18.123rac2-vip

#scan ip

192.168.18.100rac-scan

(注意：All host names must conform to the RFC 952 standard,

which permits alphanumeric characters, Host name using underscores（“_”）

are not allowed.HOSTS 文件中不支持“_” 字符)

3、用户/组

/usr/sbin/groupadd -g 501 oinstall

/usr/sbin/groupadd -g 502 dba

/usr/sbin/groupadd -g 503 oper

/usr/sbin/groupadd -g 504 asmadmin

/usr/sbin/groupadd -g 505 asmoper

/usr/sbin/groupadd -g 506 asmdba

/usr/sbin/useradd -g oinstall -G dba,asmdba,oper oracle

/usr/sbin/useradd -g oinstall -G asmadmin,asmdba,asmoper,oper,dba grid

[root@ora1 ~]# id oracle

uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(oper),506(asmdba)

[root@ora1 ~]# id grid

uid=502(grid) gid=501(oinstall)

groups=501(oinstall),502(dba),503(oper),504(asmadmin),505(asmoper),506(asmdba)

mkdir -p /opt/app/oraInventory

chown -R grid:oinstall /opt/app/oraInventory

chmod -R 775 /opt/app/oraInventory

mkdir -p /opt/app/grid

mkdir -p /opt/app/oracle

chown -R grid:oinstall /opt/app/grid

chown -R oracle:oinstall /opt/app/oracle

chmod -R 775 /opt/app/oracle

chmod -R 775 /opt/app/grid

passwd grid

passwd oracle

4、修改系统参数：

vi /etc/security/limits.conf

#ORACLE SETTING

grid soft nproc2047

grid hard nproc16384

grid soft nofile 1024

grid hard nofile 65536

oraclesoft nproc2047

oraclehard nproc16384

oraclesoft nofile 1024

oraclehard nofile 65536

vi /etc/pam.d/login

#ORACLE SETTING

session required pam_limits.so

# vi /etc/sysctl.conf

#ORACLE SETTING

fs.aio-max- = 1048576

fs.file-max = 6815744

kernel.shmall = 2097152

kernel.shmmax = 536870912

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

net.ipv4.ip_local_port_range = 9000 65500

net.core.rmem_default = 262144

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 1048586

5、gird时间同步所需要的设置(11gR2新增检查项)

#Network Time Protocol Setting

/sbin/service ntpd stop

chkconfig ntpd off

#rm /etc/ntp.conf

mv /etc/ntp.conf /etc/ntp.conf.org

选择是开启还是关闭SELINUX的工作模式（修改这一项后最好重启一下操作系统）

[root@oracle ~]# vi /etc/selinux/config

# 设置SELINUX为disabled

SELINUX=disabled

6、操作系统版本：

[root@rac1 ~]# lsb_release -a

LSB

Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch

Distributor ID: CentOS

Description: CentOS release 5.5 (Final)

Release: 5.5

Codename: Final

[root@rac1 ~]# uname -a

Linux solr03 2.6.18-194.11.4.el5 #1 SMP Tue Sep 21 05:04:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

[root@rac1 ~]#

7、修改系统的发行版本

[root@oracle ~]# vi /etc/RedHat-release

将CentOS release 5 (Final) 修改成

#CentOS release 5 (Final)

Red Hat Enterprise Linux AS release 5 (Nahant Update 5)

（因为oracle公司没推出CentOS版本的oracle）

8、修改gird、oracle用户的.bash_profile文件：

#grid 用户配置文件 ORACLE_HOSTNAME请自行设置

TMP=/tmp; export TMP

TMPDIR=$TMP; export TMPDIR

ORACLE_SID=+ASM1; export ORACLE_SID

ORACLE_BASE=/opt/oracle; export ORACLE_BASE

ORACLE_HOME=/opt/oracle/product/11.2.0; export ORACLE_HOME

NLS_DATE_FORMAT="yyyy-mm-dd HH24:MI:SS"; export NLS_DATE_FORMAT

THREADS_FLAG=native; export THREADS_FLAG

PATH=$ORACLE_HOME/bin:$PATH; export PATH

THREADS_FLAG=native; export THREADS_FLAG

PATH=$ORACLE_HOME/bin:$PATH; export PATH

if [ $USER = "oracle" ] || [ $USER = "grid" ]; then

if [ $SHELL = "/bin/ksh" ]; then

ulimit -p 16384

ulimit -n 65536

else

ulimit -u 16384 -n 65536

fi

umask 022

fi

stty erase ^h #删除键可用处理

篇三：Oracle RAC的五大优势及其劣势

详述Oracle RAC的五大优势及其劣势

2012年08月15日00:05 it168网站原创 作者：刘炳林 编辑：王玉圆 评论：0条

【IT168 技术】不同的集群产品都有自己的特点，RAC的特点包括如下几点：·双机并行。RAC是一种并行模式，并不是传统的主备模式。也就是说，RAC集群的所有成员都可以同时接收客户端的请求。

·高可用性。RAC是Oracle数据库产品高可用性的解决方案，能够保证在集群中只要有一个节点存活，就能正常对外提供服务。

·易伸缩性。RAC可以非常容易地添加、删除节点，以满足系统自身的调整。·低成本。能使用较低廉的服务器来实现高可用性、高吞吐量的集群环境，这要比通过对某台高端服务器增加硬件实现高可用性、高吞吐量花费的成本低很多。·高吞吐量。随着节点数的增加，整个RAC的吞吐量也在不断增长。下面详细讨论这五大特点。

一、双机并行

RAC是一种充分利用服务器资源的高可用性实现方案，RAC的并行模式实现方式与传统的双机热备实现方式截然不同，图1-4是两者的比较。

如图1-4所示，两个节点在传统的双机热备环境中，始终有一台机器作为备用机，只有当主节点出现问题的时候才会切换到备用机上;如果主机一直没有出现问题，那么备用机始终处于空闲状态，这在资源的利用上以及成本方面都是巨大的浪费。但RAC是一种并行模式的架构，也就是说，两个节点的集群节点间是一种并行运行的关系，当一台机器出现问题，请求会自动转发到另一台机器，没有任何一台机器作为备用机一直不被使用，这样就充分利用了服务器资源。同时，传统的双机热备构架在出现问题时，常常需要数分钟的切换时间，而RAC在出现问题时，针对存在的会话只需要数十秒的时间就可以完成失败切换过程，对新会话的创建不会产生影响，在切换时间上也有比较大的优势。

▲图1-4 双机热备与RAC并行模式对比

二、高可用性

RAC是Oracle数据库高可用性解决方案。高可用性包含两部分的内容：首先是在这种解决方案下要确保数据不丢失，这是最基础的也是必须要保证的;其次是确保不停机，使Oracle数据库一直维持在正常的运行状态，避免停机给客户带来的损失，这是讨论最多的内容。

停机一般分为两类，计划停机和非计划停机。所谓计划停机是有计划地安排节点或者系统的停机，一般在Oracle升级、系统维护或者硬件维护的情况下会出现。非计划停机就是在非人为计划的情况下突然停机，这种情况一般是在Oracle bug、系统故障、硬件故障或人为操作失败的时候出现。

在没有较高花费的情况下，想实现系统100%的不停机几乎是不可能的。表1-1列出了特定百分比高可用性比率运行停机的时间，详细记录了每种高可用性比率每年、每月、每周可以出现最大的停机时间。

通常情况下，以每月停机时间来计算对应的可用性比率。根据系统的重要性情况，应该为系统设定合理的可用性比率。

集群最大的优势在于它的高可用性，通过使用RAC可以在一定程度上避免因为硬件或软件故障引起的数据丢失和非计划停机，并在一定程度上减少或排除计划停机时间。这是很多客户选择RAC的最直接原因。

RAC中包含了非常多的高可用特性，主要包含如下几点：

·实现节点间的负载均衡。

·实现失败切换的功能。

·通过Service组件来控制客户端的访问路径。

·集群软件能够自动化管理各个资源，并且有定时的节点状态检测机制，能自动对一些失败的进程以及心跳检测失败的节点进行重启，使其重新恢复到正常的运行状态。

在Oracle 11gR2版本中，Clusterware得到了改善，提供了更高的可用性。例如，大量新的基于代理的监控系统用于监控所有的资源。这些代理使用更少的资源执行更频繁的检查，即更快速的失败扫描和更短的恢复时间。在Oracle监听的例子中，平均失败扫描时间从5分钟减少到30秒，同时，检查间隔从每10分钟减少到1分钟。另外，Clusterware的“Out-of-Place Upgrade”等特性也减少了软件维护需要的停机时间。

三、易伸缩性

RAC为需要重新规划的应用提供了易扩展性。为了在系统初始阶段保持较低的成本，避免造成不必要的浪费，集群可以按照标准硬件配置，选择适当的服务器资源、存储资源来搭建数据库环境。当系统需要更多的处理能力或者需要增加存储时，通过添加另一台服务器或存储设备到集群中，能够在不停机的情况下获得水平的扩展。在一个集群中， Clusterware和RAC支持多达100个集群节点。

当某个集群的处理能力过剩，另一个集群的处理能力不够时，可以从处理能力过剩的集群移动一个节点到处理能力不够的集群中。这样能够充分利用服务器资源，节约成本。11gR2版本中推出了网格即插即用(Grid Plug and Play，GPnP)，可以实现节点的快速添加。

四、低成本

通过多台普通的PC服务器组成一个集群，可以提高集群的处理能力，这样要比采用一台高性能的服务器的成本低很多。如果想提高系统的处理能力，给集群添加节点比为高性能服务器添加硬件要容易得多。另外，使用集群还能动态地移除节点，更加充分地利用管理者掌握的所有服务器资源，从服务器整体使用上降低了服务器的采购成本。越来越多的企业愿意将集群解决方案应用到他们的系统中，以降低成本，提高系统的可用性。

五、高吞吐量

RAC是由多台服务器构成的逻辑主体，比单台数据库服务器能接收更多的客户端请求。这在要求高吞吐量的系统中，能够得到非常明显的体现。在RAC的架构中，多个实例分布在多个服务器上，能同时打开同一个数据库，而每个实例能够接收相等数量的客户端请求，这样，随着服务器的增加，吞吐量也在不断地增加。

在以上讨论的特点中，高可用性是RAC最大的特点。

RAC存在的问题

虽然RAC有非常多的优点，但由于部署一套RAC会涉及服务器、存储设备、HBA卡、操作系统等多方面的技术，且从实现上要比单实例数据库更复杂，对硬件设备的稳定性、设备之间以及设备与操作系统的兼容性上要求也更高，Oracle的bug也会造成RAC运行出现问题。所以，从实际的运行情况来看，RAC要比单实例的数据库存在更多的问题，问题的原因也各不相同。RAC存在的问题主要体现在稳定性和高性能方面，下面讨论这两个问题。

一、稳定性

数据库的稳定运行是系统稳定运行的基础和前提，数据库的运行依赖于操作系统、服务器、存储设备等软硬件设备的运行情况。

由于各种硬件设备、操作系统的厂商不同，有时候在兼容性上会存在问题，即使同一个厂商的服务器，由于驱动、固件版本的不同也可能导致硬件出现问题以及与其他设备的兼容性问题。同时，由于RAC本身也存在不少bug，很多部署的RAC环境缺乏在上线前对环境的检查和测试，导致在运行过程中出现一系列不稳定的情况，这样高可用性并没有得到充分的体现。

由此来看，稳定的硬件环境加上稳定的RAC版本，决定着RAC运行的稳定性。数据库工程师与硬件工程师在安装配置前大量的环境检查、验证，以及部署后的大量测试工作都是非常重要的。

二、高性能

高性能也是大部分从单机环境迁移到RAC环境比较头疼的问题，RAC并不是高性能的解决方案。在目前普遍使用千兆网络的硬件环境中，很多时候系统的数据库从原来的单机迁移至RAC环境，系统的性能反而下降。在这种情况下，数据库管理员应该根据RAC的特点对系统调整提出合理的建议，经过合理的设计、开发，使用RAC是能够提高系统的处理性能的。以上两个问题是需要特别注意的。另外，与硬件工程师、系统开发人员进行良好的沟通，以及对系统合理的设计是保证RAC稳定运行和高性能运行的前提。