Oracle RAC 建设过程中各个层面关键点和优化项总结

原题：Oracle RAC建设过程中必须要知和要做的事情   作者：赵海，某城商行系统架构师，专注并擅长银行数据中心解决方案规划及设计。

数据库建设过程中缺少可以遵循的实践标准，知识点和经验点散落四处难以快速形成逻辑性强的参照标准，面对项目令人无从下手。本文是基于数据建设的规划、实施以及配置优化等阶段对大量文献的总结提炼，以及从项目的实践出发，对数据库建设过程中各个层面应该注意的事项进行的总结。优质长文，建议先收藏后看。

1.背景描述

数据库建设是每一个企业数据中心建设过程中非常重要的一个环节，直接关系到业务连续性和稳定性。但是我们在数据库建设过程当中却很少有可以遵循的实践标准。当我们面对整个建设项目的规划设计和配置优化的时候，又觉得无从下手。散落在官方网站上的一些知识点和经验点无法让我们快速形成一个具有很强逻辑性的参照标准。本文希望通过以下篇幅的总结和分析，从各个层面给予实践标准，为日后从事数据库建设的项目提供一个参考思路。

2.存储规划设计的关键点 2.1 OCR/VOTE磁盘的合理规划事项

什么是OCR/VOTE磁盘，它在集群中是什么样的角色呢？

ORACLE RAC ASM管理模式下，磁盘组通常有三个（+DATA，+FRA，+OCR），在OCR磁盘组当中所有的磁盘中存储的数据包括两部分，一部分是Vote File，另外一部分就是OCR（Oracle Cluster Registry）。Vote File是用来记录集群节点的磁盘心跳信息，而OCR是保存集群配置信息的数据。Vote File，以整个文件的方式存储在OCR磁盘上，不做任何条带。下图是其信息记录的一个说明：

以上是一个三节点的ORACLE RAC集群的Vote FIle的一个示意矩阵，每一行是一个节点的写入的信息，例如第一行，Instance1分别把其对集群中的三个成员（1、2、3）进行私网检测的结果写入到仲裁文件当中，Instance2、Instance3同样把其检测结果写入仲裁文件，最终组成了三个节点的仲裁矩阵。当私网发生故障而从网络上导致集群分割为几个孤岛子集的时候，集群是通过这个文件的信息来判断最后存活的节点。具体算法有两个非常重要的规则：

1. 保障隔离后的集群子集中节点数目最多的子集存活。

2. 当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。

对于Vote File本身的数目来讲，Oracle又有一个非常重要的规则：集群节点获得的Vote File数目小于N/2+1时，节点就会被集群驱逐出集群，N是Vote File的总数目。也就是说集群中所有节点获得的Vote File数目必须要大于等于N/2+1。

根据以上结果来看，对于VOTE磁盘组的规划，首先偶数个仲裁磁盘必然会造成一个浪费。那么我们就没有必要选择偶数仲裁磁盘。然后我们再考虑磁盘组磁盘的容错能力，为了保障我们至少有1份磁盘容错能力，我们的仲裁磁盘至少是3块儿。也就是说对于OCR磁盘组的规划来讲，至少保障其内有三个容错组，每一个容错组里面一块儿仲裁磁盘。

对于OCR来讲，它属于集群的资源注册信息，是集群运行的前提条件。所以一定要保障它的高可用性。由于它属于配置数据，那么一定会遵循ORACLE ASM的磁盘冗余策略（External、Normal、High）。也就是说OCR在OCR磁盘组里面可以拥有1份、2份、3份镜像。每份镜像的数据条带会落在一个独立的容错组里。

综上所述，对于OCR磁盘组的规划，为了保障仲裁盘的至少一份的容错能力以及OCR数据的高冗余策略，我们应该至少将磁盘组内规划为3个磁盘，每一个磁盘落在一个独立的容错组。磁盘大小建议为1GB以上（虽然OCR Device = 300M左右）。

2.2 存储外部冗余架构设计

首先一定要用多路径软件对Lun进行路径管理，并且保障链路切换策略为负载均衡模式。对于链路的数目来讲最佳为8条链路。而且需要保证这8条链路在光纤口、光纤卡、接入交换机、核心交换机、存储控制器5个层面上的冗余。例如2张双口光纤卡，每个光纤卡通过各自接入交换机连接到不同的两个核心交换机上，核心交换机又分别与两个存储控制器的前端口相连接。在光纤交换机的zone配置里，每一个主机光纤口wwn和存储的一个前端口wwn配置在一个zone里面，端口比例为1:2，总共有8个zone。用示意图的方式表示如下：

2.3 NFS架构的存储配置参数

Orace RAC的ASM磁盘可以是网络存储架构实现的Lun，当然我们也可以利用文件系统或者裸盘作为数据库的存储资源。但是在挂载NFS卷的时候，有若干参数是值得我们注意的。

1）Hard/soft：当应用进程发送一个请求，Hard情况下，客户端遇到错误不会立即通知应用，而是在后台进行重试直到正常，这会导致应用进程的阻塞；Soft情况下，客户端会立刻通知应用导致应用挂起。从这个意义上来讲，Soft对应用的响应速度会比Hard好，但是如果网络不稳，那么Soft有可能导致应用数据被损坏。这也是Oracle建议将这个参数设置为Hard的理由。

2）Rsize/Wsize:客户端从服务器端读写文件的最大数目（byte）/每次请求。如果该参数不做设置的话，那么它是通过客户端和服务器端的协商完成的。一般建议设置为固定的32768。

3）Timeo: 建议为600（60秒）。

4）Intr/nointr: 是否允许接受文件操作的中断信号，一般而言设置为nointr。

5）Noac/ac: ac情况下，客户端会缓存文件属性信息，从而提高客户端的读性能。Noac情况下，客户端不会缓存文件属性信息，任何情况下的读都是NFS文件系统上文件的实时版本信息。Ac情况下，客户端会定期扫描Server端的文件实时信息，其他时候都是读取自己缓存的信息。NFS卷作为数据库的存储磁盘，只需要实时反映文件的真实版本信息即可，不需要客户端再去做缓存，数据库有自己的缓存机制。因此一般情况下Oracle建议将这个参数设置为Noac。

当然这些参数，根据不同的操作系统特点是会有一些差异。表2.3是摘自Oracle官方发布的NFS存储最佳实践参数表当中的一部分，可以提供通用参考。

2.4 ASM磁盘组规划

（1）磁盘组相关

除了OCR磁盘组之外，一般建议建立磁盘组不超过2个，一个是存放数据的数据磁盘组（+DATA），另外一个是存放日志的闪回区磁盘组(+FRA)。假设我们选择磁盘组的冗余策略为Normal，那么建议磁盘数目为偶数个并且至少为4个相同大小相同性能配置，一方面考虑到冗余为2份，另外一方面保障Failure Group里面数目的条带化分布，可以保障磁盘组的读写性能。如果是其他冗余策略，那么按照同样的思路去选择磁盘组的数目。另外Lun的大小不能超过2T（容易引起ORA-15196、ORA-15099问题）。

（2）磁盘分配单元及文件条带

AU是ASM Disk Group磁盘空间分配单元。Strip实际上是文件层面的条带，准确说法应该是文件的扩展块儿。对于文件的扩展块儿来讲就是文件切割的单元。它有两种模式（coarse & fine）。对于coarse模式来讲，扩展块儿大小等于AU大小，对应的参数固定不变（_asm_stripesize=AU，_asm_stripewidth=1）。对于fine模式来讲，扩展块儿大小是可以进行调整，根据我们的业务需求进行适当调整。例如设置为256K，那么原来1M的文件写在一个磁盘中的AU中，那么现在可以并行写入到赐个磁盘的4个AU当中。充分发挥了小IO的并行读写性能。但是对于某些大IO的数据库业务，那么AU可以适当调整到4M，同时启用操作系统的大页读写参数。文件扩展块儿可以保持corse模式。对于一般的OLTP业务来讲，数据文件、归档文件一般设置为corse；而redo日志、控制文件、flashback日志设置为fine。对于11g之后的oracle，这些参数基本不需要我们去主动调整，除非确实有性能问题与之相关。

2.5 ASM内存管理参数

（1）内存参数相关

 db_cache_size: 缓冲区，存放metadata块儿的buffer cache，建议值为64M。

 shared_pool: 管理ASM实例所需要的内存池，建议值为128M。

 Large_pool: 用来存储 extent maps，建议值为64M。

（2）其他参数相关

在11g当中，如果多个数据库共享ASM实例的话，那么建议按照以下规则计算process的数目设置。

ASM processes = 25 + （10 + max（可能的并发数据文件变化））* 数据库的数目。当然这个数目需要一个经验的评估，需要根据集群环境数据库的情况以及业务IO的判断来估算。

2.6 异步IO配置

一般来讲数据库应用都是要启用异步IO来提高数据库的IO性能。同时需要打开操作系统的异步IO参数和数据库的异步IO参数。以Linux为例，在操作系统层面需要设置参数 aio-max-nr=1048576（11g 中设置为 4194304），表示同时可以拥有的异步IO请求数目。然后在Oracle数据库层面设置以下两个参数：filesystemio_option=setall；disk_asynch_io=true。对于AIX来说，需要设置以下三个参数（aix_maxservers, aix_minservers,aio_maxreqs）对于OLTP业务来讲，IBM官方的建议值为（800,200，16384）。

以上的参数值只是一个通用的参考，但是以上所述的参数具体配置的值还是需要根据自己环境的数据来评估。比如我们需要关注iostat中的io等待情况和aio的一系列指标来判断设置值的科学与否。

2.7 ASMLib & Udev

对于Linux平台而言，Oracle RAC的ASM磁盘管理有三种方式（ASMlib、DM、udev），我们首选的方式是ASMlib，对于 RHEL6（从6.4开始），内核驱动软件包'kmod-oracleasm'已经在 Redhat 平台上启动，并且可以通过RedHat Network (RHN)上的"RHEL Server Supplementary (v. 6 64-bit x86_64)" 渠道进行安装。这个模块的更新将会由 RedHat 提供。

对于ASMlib的方式，它是通过以下命令方式创建ASM磁盘：

# /usr/sbin/oracleasm createdisk disk_name device_partition_name

通过这种方式创建的ASM磁盘组名称（disk_name）,唯一绑定的是后面的device_partition_name，因此我们必须保障操作系统在日后的Lun变更过程中，这个命名是不能够变更的。假设我们用的是第三方多路径软件管理方式实现，那么需要通过多路径管理软件的方式来讲磁盘的device_partition_name和磁盘的唯一ID关联。例如emcpowerpath可以用emcadm export/import方式来保障Rac节点上的Lun名称一致。

对于udev的方式，同样道理我们需要将磁盘的scsi-id和最终形成的asm磁盘名称进行关联，而不是用磁盘在操作系统显示的设备名来关联。例如：

KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="36000c29a972d7d5fe0bf683b21046b34", NAME="asmgrid_disk1", OWNER="grid", GROUP="asmadmin", MODE="0660"

其中的PROGRAM字段非常重要，它表示我们是用什么方式来关联磁盘在操作系统和ASM之间的对应关系。如果在日后的运维过程中，随着磁盘的增减变化或者服务器的重启变更等导致了磁盘设备名发生变化，那么就会导致ASM磁盘符号紊乱，最终数据库集群无法启动。当然这个问题在11g之后就不存在了，因为11g之后ASM自动会去根据磁盘的唯一ID匹配ASM识别的磁盘ID，节点的读写是根据磁盘的ASM标示来执行的。但是从管理科学角度还是应该按照最佳实践来做从而保障没有任何风险。

2.8 AIX平台关注的存储参数

对于AIX平台而言，存储卷的系统参数必须遵循以下规则。

(1) reserve_lock、reserve_policy

该两个参数其实都是表示操作系统是否持有存储卷的共享锁方式。存储阵列类型为SSA, FAStT, 或者其他 non-MPIO-capable disks，参数设置参照A。存储阵列类型为SS, EMC, HDS, CLARiiON, 或者其他 MPIO-capable disks，参数设置方式参照B。

A. # chdev -l hdiskn -a reserve_lock=no

B. # chdev -l hdiskn -a reserve_policy=no_reserve

(2) 磁盘在加入ASM磁盘组之前，必须清除其盘头PVID信息。否则就会导致ORA-15063、ORA-15040、ORA-15042等磁盘错误。

(3) fc_err_recov。

该参数表示因为AIX平台下光纤断掉场合下，读写错误切换的时间。正常情况下，这个切换会导致数据库IO挂起10分钟。如果是Vote disk，就会导致集群重启。为了避免此类情况发生需要把该参数的值设置为fast_fail，实现快速切换。

(4) max_transfer。

该参数建议设置最少为Oracle最大请求的IO大小，一般超过1M。

(5) queue_depth。

该参数表示Lun的最大IO队列深度，这个参数的设置必须足以支撑数据库并发读写的负载。

(6) max_xfer_size。

该参数表示光纤卡的最大传输大小，这个参数的设置必须与磁盘的吞吐参数保持倍数关系，并且必须大于磁盘设置的参数。

(7) num_cmd_elems。

该参数表示光纤卡接受的最大IO请求数目，这个参数同样与磁盘的queue_depth有着倍数关系，具体值的设定需要看环境当中光纤卡和其所容纳Lun的数目。

3.网络规划设计的关键点 3.1 硬件及参数

从Oracle官方的推荐来看，他们首先推荐使用万兆以太网，至少使用千兆以太网，负载如果很高那么私网可以采用infiniband。当然这个完全取决于客户生产环境的具体业务量及负载情况。这个仅仅是个参考，有条件的情况下可以按照推荐进行配置。私网的连接需要使用交换机，Oracle集群安装并不支持私网的直连架构。网卡及交换机的双攻击速率参数保持正确一致。

3.2 网卡绑定

各种平台都有自己的网卡绑定工具，而且提供负载均衡和主备模式的绑定。首先为了提高公网和私网的网络高可用，网卡需要绑定。对于Linux平台我们需要在配置文件 “/etc/modprobe.d/dist.conf” 中将数mode来控制网卡绑定的具体策略：

 mod=0，即：(balance-rr)Round-robin policy（平衡抡循环策略）。

 mod=1，即： (active-backup)Active-backup policy（主-备份策略）。

 mod=2，即：(balance-xor)XOR policy（平衡策略）。

 mod=3，即：broadcast（广播策略）。

 mod=4，即：IEEE 802.3ad Dynamic link aggregation（IEEE802.3ad 动态链接聚合）。

 mod=5，即：(balance-tlb)Adaptive transmit load balancing（适配器传输负载均衡）。

 mod=6，即：(balance-alb)Adaptive load balancing（适配器适应性负载均衡）。

对于私网网卡绑定方式mode=3&6会导致ORA-600，公网网卡绑定方式mode=6会导致BUG9081436。对于具体的绑定模式，对于平台版本低而且网络架构非常复杂的场合，还是建议主备模式，因为主备模式更稳定，不容易产生数据包路径不一致的问题。如果是负载均衡模式的场合，如果网络参数设置不是很科学的情况下，很容易出现从一个物理网卡发送报文，但是回报文却回到另外一个物理网卡上，网络链路再加入防火墙的规则之后，非常容易导致丢包问题发生。

而对于AIX平台来讲，将参数mode修改为NIB或者Standard值。Standard是根据目标IP地址来决定用哪个物理网卡来发送报文，是基于IP地址的负载均衡，也不易产生上述的丢包问题。

3.3 SCAN

Oracle RAC，从11gr2之后增加了SCAN（Single ClientAccess Name）的特性。

SCAN是一个域名，可以解析至少1个IP，最多解析3个SCAN IP，客户端可以通过这个SCAN 名字来访问数据库，另外SCAN ip必须与public ip和VIP在一个子网。启用SCAN 之后，会在数据库与客户端之间，添加了一层虚拟的服务层，就是SCAN IP和SCAN IP Listener，在客户端仅需要配置SCAN IP的tns信息，通过SCANIP Listener，连接后台集群数据库。这样，不论集群数据库是否有添加或者删除节点的操作，均不会对客户端产生影响，也就不需要修改配置。对于SCAN相关的配置，有以下一些配置注意事项：

（1）主机的默认网关必须与SCAN以及VIP在同一个子网上。

（2）建议通过 DNS，按round-robin方式将 SCAN 名称（11gR2 和更高版本）至少解析为 3 个 IP 地址，无论集群大小如何。

（3）为避免名称解析出现问题，假设我们设置了三个SCAN地址，那么HOSTs文件当中不能出现SAN的记录，因为HOSTs文件当中的记录是静态解析，与DNS动态解析相悖。

3.4 网络参数

操作系统平台上关于网络的内核参数非常重要，直接决定私网公网数据传输的稳定性和性能。不过针对不同的操作系统，相关的参数设置也各有差异。

1．Linux

对于Linux平台的内核参数，有两个非常重要（net.core.rmem_default、net.core.rmem_max）。具体功能解释如下：

 net.ipv4.conf.eth#.rp_filter：数据包反向过滤技术。

 net.ipv4.ip_local_port_range：表示应用程序可使用的IPv4端口范围。

 net.core.rmem_default：表示套接字接收缓冲区大小的缺省值。

 net.core.rmem_max：表示套接字接收缓冲区大小的最大值。

 net.core.wmem_default：表示套接字发送缓冲区大小的缺省值。

 net.core.wmem_max：表示套接字发送缓冲区大小的最大值。

为了获得更好的网络性能，我们需要根据具体情况把以上两个参数从其默认值适当调整为原来的2-3倍甚至更高，关闭或者设置反向过滤功能为禁用0或者宽松模式2。

2.AIX

对于AIX平台的内核参数，以下设置是从Oracle官方文档摘出的最佳配置：

tcp_recvspace = 65536；tcp_sendspace = 65536；

udp_sendspace = ((db_block_size *db_multiblock_read_count) + 4096) ；

udp_recvspace = 655360；

rfc1323 = 1；

sb_max = 4194304；

ipqmaxlen = 512；

第1、2个参数表示TCP窗口大小，第3、4个参数表示UDP窗口大小。rfc1323启用由 RFC 1323（TCP 扩展以得到高性能）指定的窗口定标和时间图标。窗口定标允许 TCP 窗口大小（tcp_recvspace 和 tcp_sendspace）大于 64KB（65536）并且通常用于大的 MTU 网络。默认为0(关)，如果试图将 tcp_sendspace 和 tcp_recvspace 设为大于 64 KB则需要先修改此值为1。ipqmaxlen 表示指定接收包的数目，这些包可以列在 IP 协议输入队列中。sb_max指定一个 TCP 和 UDP 套接字允许的最大缓冲区大小。

3.5 安全配置事项

1．Linux平台下的防火墙需要关闭，否则会引起公网或者私网的通讯问题。

# chkconfig iptables stop

2．Linux平台下的selinux安全配置项需要关闭，配置文件为/etc/security/config。

SELINUX=disabled

3．如果是Power System主机的PowerVM虚拟化架构下的AIX平台，如果发现Oracle RAC的两个节点之间有大量丢包现象或者是以下几种事件：

 Cache Fusion "block lost"

 IPC Send timeout

 Instance Eviction

 SKGXPSEGRCV: MESSAGE TRUNCATED user data nnnn bytes payload nnnn bytes

那么我们需要检查VIOS分区操作系统的补丁信息，如果没有APAR IZ97457，那么我们需要将这个补丁打上，详细需到IBM官网找到相应的补丁及其详细解释。

3.6 通用注意事项

1.系统主机名、域名等配置不允许有下划线。

2.网卡名称在两个节点上保持一致（例：public->eth2ð1，private->eth3ð2）。

3.网卡设备名称当中不能包含“.”等特殊字符。

4.私网地址需遵守RFC1918标准，采用其所规定的ABC三类企业内部私网地址。否则会引起BUG4437727发生。A类：10.0.0.0 -10.255.255.255 (10/8比特前缀)； B类：172.16.0.0 -172.31.255.255 (172.16/12比特前缀)； C类：192.168.0.0 -192.168.255.255 (192.168/16比特前缀)。而且私网VLAN需要与上述no-routeable子网之间需要是1:1的映射关系，以免引起BUG9761210。

5.从11gr2起，私网网段配置需要支持组播功能，因为私网需要通过组播模式实现通讯。

3.7 send (tx) / receive (rx)

UDP包传输的过程中，接受进程会读取数据包头的校验值。任何校验值损坏都会使这个包被丢弃，并导致重发，这会增加CPU的使用率并且延缓数据包处理。

由于网卡上开启了Checksum offloading 导致了checksum 错误，如果出现这样的问题请检查checksum offloading的功能是否被禁用，测试后考虑关闭网卡上的该项功能。在Linux系统上执行ethtool -K <IF> rx off tx off可以关闭该功能。

3.8 MTU

不匹配的MTU大小设置会导致传输过程中出现 "packet too big" 错误并丢失数据包，导致global cache block丢失和大量的重传（retransmission）申请。而且私网中不一致的MTU值会导致节点无法加入集群的问题。

对于以太网（Ethernet），大多数UNIX平台的默认值是1500字节。私网链路中所有设备都应该定义相同的MTU。请确认并监控私网链路中的所有的设备。为ping ,tracepath,traceroute命令指定大的，非默认尺寸，ICMP probe 包来检查MTU设置是否存在不一致。使用ifconfig或者厂商推荐的工具为服务器网卡（NIC）的MTU设置合适的值。

Jumbo Frames 并不是IEEE 标准配置。单个Jumb Frame的大小是9000 bytes左右。Frame 的大小取决于网络设备供应商，在不同的通信设备上的大小可能是不一致的。如果默认的MTU 尺寸不是9000bytes，请保证通信路径中的所有设备（例如：交换机/网络设备/网卡）都能够支持一个统一的MTU值，在操作的过程中必须把Frame Size（MTU Size）配置成这个值。不合适的MTU设置，例如：交换机上配置MTU=1500,但是服务器上的私网网卡配置成MTU=9000，这样会造成丢包，包的碎片和重组的错误，这些都会导致严重的性能问题和节点异常宕机。大部分的平台上我们都可以通过netstat –s命令的‘IP stats’输出发现包的碎片和重组的错误。大部分的平台上我们可以通过ifconfig –a命令找到frame size的设置。关于交换机上的配置查询，需要查看交换机提供商的文档来确定。

4.操作系统层的关键优化项

4.1 兼容性检查

在Oracle建设实施之前，根据操作系统平台对即将采用的相关数据库技术进行兼容性检查。下面的link是官方的Matrix，分别针对Linux平台和Unix平台：

http://www.oracle.com/technetwork/database/clustering/tech-generic-linux-new-086754.html

http://www.oracle.com/technetwork/database/clustering/tech-generic-unix-new-166583.html

4.2 平台版本及补丁

当我们选择了具体的操作系统平台以及具体的数据库版本之后，接下需要做的事情就是要根据官方提供的文档来检查我们的系统补丁以及相关软件包是否齐全准确：

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=184026698780346&parent=DOCUMENT&sourceId=1526555.1&id=169706.1&_afrWindowMode=0&_adf.ctrl-state=bjsizj5t_240

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=184190072886338&parent=DOCUMENT&sourceId=1526555.1&id=1393041.1&_afrWindowMode=0&_adf.ctrl-state=bjsizj5t_338

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=184287678146090&parent=DOCUMENT&sourceId=1526555.1&id=282036.1&_afrWindowMode=0&_adf.ctrl-state=bjsizj5t_436

Oracle官方对所有数据库集群及RDBMS等建议的最新补丁列表：

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=202212137729856&parent=DOCUMENT&sourceId=1526083.1&id=756671.1&_afrWindowMode=0&_adf.ctrl-state=yi6z8ecqc_839#r11204

另外在AIX平台上有一个不容忽视的地方，那就是必须保障Hacmp没有安装或者没有任何残留痕迹。

4.3 时间同步设置项

NTP是11gr2之前必须的选项，用来同步节点之间的时间。而到了11gr2之后，不仅仅可以采用NTP也可以采用CTSSD（Cluster Time Synchronization Daemon）代替NTP。如果NTP启用的话，Oracle会采用NTP，CTSSD自动处于观察模式。但是在NTP的启用模式上，我们需要采用渐进式模式（需要利用启动参数-x）。可以参照下面的配置：

1. /etc/sysconfig/ntpd

# Drop root to id 'ntp:ntp' by default.

OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

# Set to 'yes' to sync hw clock after successful ntpdate

SYNC_HWCLOCK=no

# Additional options for ntpdate

NTPDATE_OPTIONS=""

4.4 ASLR (Address Space Layout Randomization)

ASLR是REL5 Linux以上版本中默认开启的一个特性，是参与保护缓冲区溢出问题的一个计算机安全技术。是为了防止攻击者在内存中能够可靠地对跳转到特定利用函数。ASLR包括随机排列程序的关键数据区域的位置，包括可执行的部分、堆、栈及共享库的位置。ASLR通过制造更多让攻击者预测目标地址的困难以阻碍一些类型的安装攻击。而在ORACLE的进程管理当中，多个进程共享相同地址的共享内存，开启ASLR特性之后，Oracle就无法保障共享内存可用。从而导致ORA-00445错误发生。要在Linux上关闭这个特性需要添加或修改以下两个参数到/etc/sysctl.conf文件：

kernel.randomize_va_space=0

kernel.exec-shield=0

4.5 HugePage

大多数操作系统采用了分段或分页的方式进行管理。分段是粗粒度的管理方式，而分页则是细粒度管理方式，分页方式可以避免内存空间的浪费。相应地，也就存在内存的物理地址与虚拟地址的概念。通过前面这两种方式，CPU必须把虚拟地址转换程物理内存地址才能真正访问内存。为了提高这个转换效率，CPU会缓存最近的虚拟内存地址和物理内存地址的映射关系，并保存在一个由CPU维护的映射表中。为了尽量提高内存的访问速度，需要在映射表中保存尽量多的映射关系。

Linux的内存管理采取的是分页存取机制，为了保证物理内存能得到充分的利用，内核会按照LRU算法在适当的时候将物理内存中不经常使用的内存页自动交换到虚拟内存中，而将经常使用的信息保留到物理内存。

通常情况下，Linux默认情况下每页是4K，这就意味着如果物理内存很大，则映射表的条目将会非常多，会影响CPU的检索效率。因为内存大小是固定的，为了减少映射表的条目，可采取的办法只有增加页的尺寸。因此Hugepage便因此而来。也就是打破传统的小页面的内存管理方式，使用大页面2m,4m等。如此一来映射条目则明显减少。如果系统有大量的物理内存（大于8G），则物理32位的操作系统还是64位的，都应该使用Hugepage。

那么如何控制Oracle数据库对HugePage的利用呢？主要分为以下几个步骤：

1．需要在/etc/security/limits.conf 中设置memlock值(单位KB)，该值小于内存大小。

2． 如果你使用11G及以后的版本，AMM已经默认开启，但是AMM与Hugepages是不兼容的，必须先关闭AMM。

3．编辑/etc/sysctl.conf 设置 vm.nr_hugepages参数的具体值。

4．停止实例并重启OS系统，并通过以下命令检查设置是否生效：

# grep HugePages /proc/meminfo

HugePages_Total: 1496

HugePages_Free: 485

HugePages_Rsvd: 446

HugePages_Surp: 0

5．通过以下参数控制数据库对HugePage的使用方式(11gr2之后)：

use_large_pages = {true/only/false/auto}

默认值是true，如果系统设置Hugepages的话，SGA会优先使用hugepages，有多少用多少。如果设置为false， SGA就不会使用hugepages。如果设置为only 如果hugepages大小不够的话，数据库实例是无法启动的。设置为auto，这个选项会触发oradism进程重新配置linux内核，以增加hugepages的数量。一般设置为true。

SQL> alter system set use_large_pages=true scope=spfile sid='*';

4.6 Transparent HugePage

透明大页管理和前面所述的标准大页管理都是操作系统为了减少页表转换消耗的资源而发布的新特性，虽然Oracle建议利用大页机制来提高数据库的性能，但是Oracle却同时建议关闭透明大页管理。这二者的区别在于大页的分配机制，标准大页管理是预分配的方式，而透明大页管理则是动态分配的方式。

对于数据库来讲这种动态的分配方式在系统负载很高的情况下非常有可能导致数据库出现严重的性能问题。这在Oracle官方文档1557478.1当中有详细的记载。

那么如何来关闭系统的透明大页管理呢？只要修改如下参数即可：

# echo never > /sys/kernel/mm/transparent_hugepage/enabled

4.7 vm.min_free_kbytes

该参数是Linux内核当中用来控制保留最小空闲内存的数量，Oracle建议调大该值为512M。这样的设置有利于相对加快内存的回收速度，从而降低内存吃紧的压力。

4.8 AIX虚拟内存参数

这一项主要是针对AIX的内存管理。AIX内存管理和Linux的内存管理机制不一样，它采用计算内存和非计算内存方式来管理内存。IBM对Oracle的建议值为以下方案：

minperm%=3

maxperm%=90

maxclient%=90

lru_file_repage=0

lru_poll_interval=10

strict_maxperm=0

strict_maxclient=1

page_steal_method=1

minperm和maxperm控制非计算内存中的文件页的下限和上限；maxclient控制非计算内存中的客户页面；lru_file_repage表示分页替换守护进程将根据其内部重新分页表来确定选择何种类型的分页进行操作。strict_maxperm&strict_maxclient表示无论是否有空闲内存，都会严格限制文件页以及客户页的最大占有比率不得超越限制。page_steal_method表示换页时的策略，0为全部页面，1为非计算持久页面。以上参数放方案表示费计算持久页面的上限为90%，下限为3%；客户机页面上限为90%；采用非严格持久页面上限控制策略；严格客户机页面上限控制策略。lru_file_repage & page_steal_method配合使用表示LRUD在寻找空闲页时，只寻找费计算内存当中的持久内存页面。

vmm_klock_mode=2

这个参数是是否对内核页进行加锁的控制。0则表示不进行加锁，那么内核页有可能被错误换出从而导致Page Fault发生；1则表示部分内核页面加锁；2则表示对所有内核页面进行加锁。在Oracle RAC环境下或者EMC的存储作为系统的Swap Device的时候，IBM强烈建议将该参数设置为2。

4.9 PowerVM环境下的参数调整

PowerVM环境下，由于其利用Hypervisor实现了很多虚拟化的功能，这些功能大多从灵活性及扩展型来考虑，但是如果我们运行的是Oracle Rac的话，那么还是有很多关键点需要注意。

1. cpu folding

虚拟处理器折叠功能，当系统负载比较低的时候，AIX系统自动休眠一些虚拟处理器，以减少Hypervisor的开销，提升PowerVM平台整体性能。但是在某些情况下，当数据库的负载变化非常快的时候，CPU折叠或者打开的速度反而会影响数据库甚至系统的性能，严重导致系统挂起。下面是IBM针对该BUG的一个补丁，主要针对AIX5.3 & 6.1。

https://www-01.ibm.com/support/docview.wss?uid=isg1fixinfo105201

4.10 Linux内核参数

以下是Oracle官方针对Linux平台内核参数设置的一个通用方案：

fs.aio-max-nr = 1048576

fs.file-max = 6815744

kernel.shmall = 2097152

kernel.shmmax = 4294967295

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

net.ipv4.ip_local_port_range = 9000 65500

net.core.rmem_default = 4194304

net.core.rmem_max = 4194304

net.core.wmem_default = 4194304

net.core.wmem_max = 4194304

kernel.shmmax： 是核心参数中最重要的参数之一，用于定义单个共享内存段的最大值。设置应该足够大，能在一个共享内存段下容纳下整个的SGA ,设置的过低可能会导致需要创建多个共享内存段，这样可能导致系统性能的下降。

至于导致系统下降的主要原因为在实例启动以及ServerProcess创建的时候，多个小的共享内存段可能会导致当时轻微的系统性能的降低(在启动的时候需要去创建多个虚拟地址段，在进程创建的时候要让进程对多个段进行“识别”，会有一些影响)，但是其他时候都不会有影响。

64位linux系统：可取的最大值为物理内存值-1byte，建议值为多于物理内存的一半，一般取值大于SGA_MAX_SIZE即可，可以取物理内存-1byte。例如，如果为12G物理内存，可取210241024*1024-1=12884901887，SGA肯定会包含在单个共享内存段中。

kernel.shmall：  该参数控制可以使用的共享内存的总页数。Linux共享内存页大小为4KB,共享内存段的大小都是共享内存页大小的整数倍。一个共享内存段的最大大小是16G，那么需要共享内存页数是16GB/4KB=16777216KB /4KB=4194304（页），也就是64Bit系统下16GB物理内存，设置kernel.shmall = 4194304才符合要求(几乎是原来设置2097152的两倍)。这时可以将shmmax参数调整到16G了，同时可以修改SGA_MAX_SIZE和SGA_TARGET为12G（您想设置的SGA最大大小，当然也可以是2G~14G等，还要协调PGA参数及OS等其他内存使用，不能设置太满，比如16G）。

kernel.shmmni： 该参数是共享内存段的最大数量。shmmni缺省值4096，一般肯定是够用了。

fs.file-max： 该参数决定了系统中所允许的文件句柄最大数目，文件句柄设置代表linux系统中可以打开的文件的数量。

fs.aio-max-nr： 此参数限制并发未完成的请求，应该设置避免I/O子系统故障。

kernel.sem： 以kernel.sem = 250 32000 100 128为例：250是参数semmsl的值，表示一个信号量集合中能够包含的信号量最大数目。32000是参数semmns的值，表示系统内可允许的信号量最大数目。100是参数semopm的值，表示单个semopm()调用在一个信号量集合上可以执行的操作数量。128是参数semmni的值，表示系统信号量集合总数。

net.ipv4.ip_local_port_range： 表示应用程序可使用的IPv4端口范围。

net.core.rmem_default： 表示套接字接收缓冲区大小的缺省值。

net.core.rmem_max： 表示套接字接收缓冲区大小的最大值。

net.core.wmem_default： 表示套接字发送缓冲区大小的缺省值。

net.core.wmem_max： 表示套接字发送缓冲区大小的最大值。

5.配置集群层的关键点

5.1 diagwait

在集群进行驱逐节点时，节点发生重新启动的场合下，操作系统需要转储CrashDump，这个参数就是集群需要等待操作系统转储的时间参数。对于版本 10gR2 和 11gR1，所有平台上的最佳实践都是将 CSS diagwait 参数设置为小于等于13。对于11gR2已经不要求对该参数进行设置。

5.2 ORA_CRS_HOME

对于这个变量，Oracle官方给出的建议是：不要设置 ORA_CRS_HOME 环境变量（在所有平台上）。设置此变量将使各个 Oracle 组件出现问题，而且 CRS 程序完全不需要此变量，因为它们都有包装脚本。

5.3 关于组播和多播

Oracle11gR2私网采用的是组播方式通讯，组播地址段为230.0.1.0 或 224.0.0.251网段，为了保障集群私网通讯的正常及稳定，一方面这个网段的网络配置需要支持组播，另外一方面不要让主机的任何其他网络配置和这两个网段冲突。曾经遇到过浪潮的X86服务器的带外管理的某个地址也正好利用了这个网段，结果导致了Oracle Rac节点的异常重启。这种问题一般会显示为私网通讯报错，但是正常状况下只要带外管理收集日志工具不启动的话，那么是不会发现这个问题的，属于偶发性问题。所以我们需要特别小心此类问题，不要等到发生时候再去花费大量实践调查。

6.安装集群时的关键点

6.1 cluvfy

如果安装过10g以后的RAC环境，应该对这个工具并不陌生。在安装Cluster和Database之前通常会执行runcluvfy.sh脚本来检查当前系统是否满足安装条件。runcluvfy.sh将cluvfy工具的功能在shell中实现，使得用户在数据库和CLUSTER安装之前就可以利用这个工具的功能。这个工具的主要作用就是验证系统是否满足安装的条件，尤其是检查网络和域名解析，如果网络和域名解析在安装之前没有正常的配置，通常直接导致安装的失败。主要用法如下所列两个功能：

# runcluvfy.sh stage -list

# runcluvfy.sh comp -list

6.2 升级顺序问题

安装完集群软件也好，RDBMS也好，打补丁是必然要做的事情。但是究竟是等安装完所有的组件之后再统一打补丁呢还是说将每一个组件都按照安装&补丁升级的顺序依次做完呢？Oracle给的建议是：在执行 11gR2 之前的安装时，建议在执行任何 RDBMS 或 ASM 主目录安装前应用补丁程序将 Clusterware 主目录升级到所需的级别。

6.3 root.sh & rootupgrade.sh

安装或者升级期间，最后的步骤就是要执行以上的脚本。当然按照安装文档的要求必须是用超级用户root来执行。但是可能有些人认为只要利用root的权限去执行就可以了，很想当然的用了su root -c或者是sudo等去执行，结果导致执行失败，日志报错crsd.bin crashes。因为脚本的执行不仅仅是要用超级用户root的权限，还要利用root用户的环境配置等。

6.4 /etc/init.cssd

11.2 之前再AIX系统上，OPROCD 默认不在 AIX 全局运行队列运行 ，这可能会导致 OPROCD 错误地重启节点。(Bug 13623902)。此问题的更正操作是修改 /etc/init.cssd 文件，加入如下参数：

RT_GRQ=ON

export RT_GRQ

但是AIX6.1 TL4以上的版本就自带了对该问题的修正程序。所以当我们采用低版本的AIX操作系统时，需要特别注意这个配置文 件。

7.数据库层的关键优化项

7.1 pre_page_sga & lock_sga

这两个参数都是对数据库SGA的保护参数。lock_sga是控制SGA不被换出到交换空间上，会保障数据库内存页一致留在物理内存上，从而提高性能。而pre_page_sga是保障数据库实例启动时就把所有SGA读到物理内存上，虽然启动会慢，但是后续性能会好。

但是pre_page_sga同时还有一个作用。pre_page_sga 为true时, 每个进程创建的时候都会去touch一遍sga里的page, 当sga越大的时候,这个touch所消耗的时间就越长，特别是在断开式连接,短连接的Application上, 将会消耗很多资源。当客户端连接感觉到慢的时候，这个参数就一定要设置成false了。Oracle的建议也是false。

SQL> alter system set pre_page_sga=false scope=spfile sid='';

SQL> alter system set lock_sag=true scope=spfile sid='';

7.2 关于重做日志

首先、接触过数据库的人相信对这个概念都不陌生。数据库在做SQL更新的时候，首先要将事务执行过程记入重做日志当中，然后才会把日志刷入磁盘，将数据更新持久化。一条数据提交之后成功的标准时日志落到磁盘，而不是真正的数据落盘。因此日志的配置（大小、数量）直接决定着数据库读写的性能，如果日志大小非常大，那么会造成归档切换时间非常长，一旦这时候发生了不可恢复的DB灾难，那么通过备份恢复的数据流失量或者说RPO就会较大。日志大小非常小的话，势必会造成日志频繁切换，AWR里面有大量的日志切换事件，这样对数据库的性能会有较大影响。因此根据性能测试的AWR报告中日志切换的等待事件、和切换频度来决定其数据量和大小是否需要调整。一般的OLTP建议（10组、500M）。

接着、我们还需要考虑与其相关的参数设置。

1. _use_adaptive_log_file_sync

它直接决定了日志落盘的方式，对于日志缓冲区的数据落盘的方式，11g增加一种新的方式就是polling的方式，传统方式是post/wait方式。oracle底层自动判断何时用何种方法来完成lgwr进程的写任务。对于post/wait方式来讲，客户端做了commit之后，需要等待事件完成。oracle一旦完成会通知用户进程，用户进程立刻感知。但是这一通知post，会耗费大量CPU资源。polling是oracle前台进程启动检查任务，自动检查后台lgwr写入情况，耗费CPU资源比较少，但是用户进程并不一定能立刻感知。

所以两种方法各有千秋。但是关键是后台实现两种方法切换的时候要耗费系统性能，尤其在繁忙的时候频繁切换的话反而会导致数据库性能下降。awr出现大量log file sync，Bug 13707904。

SQL> alter system set "_use_adaptive_log_file_sync"=false scope=spfile sid='*';

2. archive_lag_target 它决定了我们是否开启日志强制切换功能，为了减少故障时数据损失，可以设置archive_lag_target参数，强制进行日志切换。这个参数的缺省值是0，即为不启用该参数。建议设置值为1800。 SQL> alter system set archive_lag_target=1800 scope=spfile sid='*';

7.3 AMM

首先、ORACLE通用的两种内存管理方式AMM&ASMM，从Oracle 11g开始，ORACLE默认使用AMM(自动内存管理)，即让数据库完全管理SGA、PGA的大小，而对于管理员只需要设置一个总的大小（memory_target），数据库会动态的调整SGA、PGA的大小以及其中包含的各个组件大小，如Database buffer cache、Shared pool等。这个特性设计的初衷是好的，它希望避免不正确的SGA和PGA设置导致的内存使用不平衡的性能问题。

但是在实际应用过程中，这个特性是不是一定非常出色呢？AMM中在数据库启动是会有一个固定比例来分配SGA/PGA 大小：

sga_target =memory_target 60%

pga_aggregate_target=memory_target *40%。

但是在并发较高，数据库非常繁忙的场合下，自动内存调整的速度很可能赶不上大量会话对内存的请求的速度。另外当PGA随着会话不断增加而需求量猛增的情况下，它会首先抢占SGA，导致数据库性能故障。在高并发的数据库场景中并不建议使用AMM。采用10g更为成熟的自动共享内存管理(ASMM)和自动PGA管理。手动调整内存参数，具体可以参照以下：

1. 关闭内存自动管理

SQL> alter system set memory_target=0 scope=spfile sid='';

SQL> alter system set memory_max_target=0 scope=spfile sid='*';

2. 设置SGA为固定值，可以根据性能测试中的AWR报告中的建议

SQL> alter system set sga_max_size=XG scope=spfile sid='';

SQL> alter system set sga_target=XG scope=spfile sid='';

3. 设置PGA等参数

SQL> alter system set pga_aggregate_target=XG scope=spfile sid='';

SQL> alter system set large_pool_size=256M scope=spfile sid='';

pga_aggregate_target=XG

large_pool_size=256M

另外很重要的一个参数，“_shared_pool_reserved_pct”，如果这个参数设置小了，很可能导致ORA04031，所以需要一个合理的设置。

SQL> alter system set“_shared_pool_reserved_pct”=10 scope=spfile sid='*';

7.4 SQL解析

1. 绑定变量窥测

在Oracle中每条SQL语在执行之前都需要经过解析，这里面又分为软解析和硬解析。在Oracle中存在两种类型的SQL语句，一类为 DDL语句(数据定义语言)，他们是从来不会共享使用的，也就是每次执行都需要进行硬解析。还有一类就是DML语句(数据操纵语言)，他们会根据情况选择要么进行硬解析，要么进行软解析。一般我们希望我们的AWR报告中硬解析偏少，而软解析偏多。因为硬解析的代价会非常高。为了减少带绑定变量的sql的解析时间，oracle 9i引入的绑定变量窥测的功能。也就是在同一个SQL的变量被赋于不同值时采用同一个游标，这样虽然节省了sql的解析时间。大家有没有通过功能的打开或者关闭实际观察过AWR中的软硬解析数目的实际状况呢？其实对于绑定变量窥测这个特性以及后来的自适应游标等特性，都是oracle为了找到最优执行计划而启用的一些新特性，但是在实际应用过程中，对于不同量级不同特性的业务场景也曾经因此出现了很多bug( Bug 20370037，Bug 13456573，Bug 20082921）等。

根据自己的业务系统特点，做大量的性能测试和业务测试，根据参数的关闭打开对比awr报告当中显示出的软硬解析比率以及执行计划数据决定是否打开或者关系相应功能特性。如下参数：

"_optim_peek_user_binds"

"_optimizer_adaptive_cursor_sharing"

"_optimizer_extended_cursor_sharing"

"_optimizer_extended_cursor_sharing_rel"

"_optimizer_use_feedback"

2. open_cursors & session_cached_cursors

与之相关的几个参数：open_cursors、session_cached_cursors 这两个参数决定着应用会话可以控制打开以及缓存的游标数量，如果数量不足，就会引起SQL解析的性能问题。这两个参数要根据v$resource_limit视图中的值的情况进行调整，避免资源设置不合理导致的性能问题。

SQL> alter system set open_cusors=N scope=spfile sid='';

SQL> alter system set session_cached_cursors=M scope=spfile sid='';

3. _b_tree_bitmap_plans

与执行解析执行计划相关的几个参数，_b_tree_bitmap_plans、有时将B-Tree索引进行BITMAP转换来进行SQL执行，往往会生成极其恶劣的执行计划，导致CPU100%。Select Fails With ORA-600 [20022] (文档 ID 1202646.1) 建议可以关掉。

SQL> alter system set "_b_tree_bitmap_plans"=false scope=spfile sid='*';

7.5 process & sessions

process 限制了能够连接到SGA的操作系统进程数，这个总数必须足够大，从而能够适用于后台进程与所有的专用服务器进程，此外共享服务器进程与调度进程的数目也被计算在内。session 是通信双方从开始通信到通信结束期间的一个上下文(context)。这个上下文是一段位于服务器端的内存：记录了本次连接的客户端机器、通过哪个应用程序、哪个用户在登录等信息。

Oracle的连接数sessions与其参数文件中的进程数process相关，它们的关系如下： sessions=(1.1process+5)

这两个参数的设置是需要根据应用的具体并发需求来决定具体的设置方案。

SQL> alter system set process=N scope=spfile sid='';

SQL> alter system set sessions=1.1N+5 scope=spfile sid='';

7.6 DRM

数据库节点之间的竞争有很多，包括锁（各种粒度锁）的竞争以及数据的传输等。完全避免竞争那就失去了RAC的意义了，RAC本身就是希望能在两个节点并行执行任务。如果特别极致的并行一定引起严重的性能问题，如果完全禁止，既无法做到又失去了集群本来的意义。所以我们只能在一定程度上去平衡：

首先、关于DRM，oracle的DRM特性从理论上来看，它是为了避免节点间的数据量传输，避免节点间的锁等待事件频繁发生。DRM的极致是做到请求节点和Master节点统一化。但是实践中，这个特性引起了很多的BUG、反而导致了节点间的竞争出现了性能故障。Bug 6018125 - Instance crash during dynamic remastering or instance reconfiguration (Doc ID 6018125.8)。所以建议关闭。

SQL> alter system set "_gc_policy_time"=0 scope=spfile sid='*';

SQL> alter system set "_gc_undo_affinity"=false scope=spfile sid='*';

7.7 parallel_force_local

关于参数“parallel_force_local”，ORACLE RAC为了实现多节点并行处理是花费了很大代价的，假设一个集群当中有三个节点，对于某一个数据块儿读写，有一个Master、有一个请求者、有一个拥有者，请求者向Master请求数据块儿的最新版本，Master把请求转发给拥有者，拥有者按照请求信息把数据块儿传送给申请者，然后加锁进行读写。这一过程是需要有大量的数据传输和竞争存在的，一旦这个事情成为多数，那么势必造成节点间的通讯负载过大，造成大量的锁等待时间，严重影响数据库整体性能。尤其是在做跨数据中心高可用的场合下。因此我们只要做到业务级别的并发处理，而不要追求一个SQL级别的绝对并发。物极必反的道理就在于此。因此把参数打开，使得进程级别并发实现本地化处理，不要跨节点处理。在官方文档 ID 1536272.1当中，必须优化的参数就包括这个。

SQL> alter system set parallel_force_local=true scope=spfile sid='*';

7.8 关于自动任务

Oracle 11g 数据库有三个预定义自动维护任务：

1. Automatic Optimizer Statistics Collection（自动优化器统计信息收集）： 收集数据库中所有无统计信息或仅有过时统计信息的 Schema 对象的 Optimizer（优化器）统计信息。QL query optimizer（SQL 查询优化器）使用此任务收集的统计信息提高 SQL 执行的性能。

2. Automatic Segment Advisor（自动段指导）： 识别有可用回收空间的段，并提出如何消除这些段中的碎片的建议。也可以手动运行 Segment Advisor 获取更多最新建议。

3. Automatic SQL Tuning Advisor（自动 SQL 优化指导）：检查高负载 SQL 语句的性能，并提出如何优化这些语句的建议。您可以配置此指导，自动应用建议的SQL profile。

关于统计信息收集，数据库是有其自己的默认启动时间，11g是在22:00-2:00之间，假设这个时间跟我们的跑批时间有冲突的话，我们可以修改器具体执行时间。但是这个任务必须保留。关于其他的两个优化指导，其实要看我们实际工作中用到的几率是否很高，是否有价值留着给我们提供一些优化的理论指导。如果感觉意义不大，可以不用。

7.9 安全方面的配置优化

首先、是数据库要不要保留审计？如何保留？

假设不打开审计，那么将来出来安全问题，我们无法寻找线索；假设打开，那么很可能因为使得审计日志占用大量的存储空间，甚至影响数据库IO性能。一般情况下还是需要对一些基本登录行为的审计，但是我们可以把日志位置修改制定到操作系统层面减少数据库层因此的性能压力，而且应该定期转储，减少碎文件太多而把文件系统i节点用光的极端情况。可以通过对参数"audit_trail"以及adump参数的调整来实现此项优化。

接着、alert日志和trace文件的控制参数。

max_dump_file_size，它决定了这些文件的大小限制，默认情况下是unlimited，如果生成了很大的文件，就会达到OS对文件上限的要求，导致写入失败。

SQL> alter system set max_dump_file_size='100m' scope=spfile sid='*';

7.10 parallel_min_servers

这个参数决定了实例可以并行执行的进程的最大数目。设置太小查询进程没有并行执行能力。如果设置太大，那么可能会导致内存资源紧张，从而影响系统整体性能。确保监控活动并行服务器进程的数量并计算要应用于 parallel_min_servers 的平均值。可通过以下操作完成：

SQL> select * from v$pq_syssstat;

查看列值 "Servers Highwater"；

根据硬件情况优化 parallel_max_servers的值。最开始可以使用 (2 * ( 2 个线程 ) (CPU_COUNT)) = 4 x CPU 计算，然后使用测试数据对更高的值重复测试。一般OLTP系统需限制其不超过128（ORACLE的默认算法有BUG，在cpu核数超过128，默认并行参数设置过高时，容易被触发，会导数oracle无法启动。另外，如果这个参数太高，并行的进程开的太大了，会导数数据库无法承受并发压力）。

SQL> alter system set parallel_max_servers=128 scope=spfile sid='';

7.11 fast_start_mttr_target & fast_start_parallel_rollback

fast_start_mttr_target={0-3600} 一旦设置具体值，那么崩溃恢复将在此要求的时间范围内完成。fast_start_parallel_rollback={high/low/false}，high启动4倍于CPU数目的并行恢复进程，low启动2倍于CPU数目的并行恢复进程，false关闭并行恢复进程。这两个参数都是用来加速在故障场合下的奔溃恢复，其根本的机制就是要通过主动触发checkpoint来缩短最近依次checkpoint和联机重做日志之间的距离。但是这个无疑会带来一定的性能风险。所以这两个值的设置需要根据具体业务情况来设置，同时要进行压力测试，不要因为激进的策略带来性能问题。

与此相关还有一个参数log_checkpoints_to_alert，默认是关闭状态。打开这个参数会在trace文件当中记录详细的检查点发生信息，对于数据库诊断来讲是一个必不可少的功能。因此建议打开。

SQL> alter system set fast_start_mttr_target=120 scope=spfile sid='';

SQL> alter system set fast_start_parallel_rollback=low scope=spfile sid='';

SQL> alter system set log_checkpoints_to_alert=true scope=spfile sid='*';

7.12 listener.ora

对于11.2之前的 listener， 首先得保证IPC项存在，且此项列在所有RAC listener的地址列表的第一个。否则，可能会对 VIP 在公网接口出现故障时进行故障转移所用的时长产生不利影响。

LISTENER_n1 =

(DEION_LIST =

(DEION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)))

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = n1vip)(PORT = 1521)(IP = FIRST)))

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.8.21.121)(PORT = 1521)(IP = FIRST)))

)

)

假设把TCP列到第一项，那么监听需要等待TCP timeout，而TCP timeout是受操作系统相关参数控制，并且timeout时间较长，那么就有可能引起故障转移并不能非常及时的问题。

7.13 sqlnet.ora

数据库连接的客户端异常断开后，其占有的相应并没有被释放，如从v$session视图中依旧可以看到对应的session处于inactive，且对应的服务器进程也没有释放，导致资源长时间地被占用，对于这种情形开该如何处理呢？sqlnet.expire_time对于这个问题我们提供了解决方案，专门用于清理那些异常断开的情形，如网络异常中断，客户端异常掉电，异常重启等。可以在sqlnet.ora文件当中设置参数sqlnet.expire_time=5。

7.14 回收站

从ORACLE 10g开始，引入了一个叫回收站(Recycle Bin)的概念。它的全称叫Tablespace Recycle Bin。回收站实际是一个逻辑容器。它以表空间中现有已经分配的空间为基础，而不是从表空间上物理划出一个固定区域用作回收站。这意味着回收站和表空间中的对象共用存储区域、系统没有给回收站预留空间。因此，当表被DROP后，如果可用空间充足，并且没有对回收站进行清理，那么被DROP掉的对象会一直存在回收站中，但是如果可用空间紧张的情况下，数据库会根据先进先出的顺序覆盖Recycle Bin中的对象。回收站这个特性主要的好处就是在误删除一个表时有一个恢复机制，不必通过数据库还原来实现，避免大量的人工误操作。

但是对于业务场景存在大量的drop对象但是没有purge操作的场合下，那么回收站的开启势必会带来数据库系统表空间大量占用以及数据库性能降低的风险，尤其是在金融业务批量的业务环境。所以就实际的生产环境而言，这个功能的用途并非像理论上想象的那么有意义。基于风险的考虑，还是建议把该功能关闭掉。

SQL> show parameter recyclebin

SQL> salter system set recyclebin=off cope=spfile sid='*';

SQL> spurge recyclebin

SQL> spurge dba_recyclebin

7.15 结果缓存

结果缓存是11g之后增加的特性。分为server和client两种类型，server是指在SGA的Share Pool当中保留一块儿内存空间用来存储SQL或者PLSQL的查询结果，供其他进程来共享使用。Client是指在OCI连接进程当中的内存当中保存SQL查询结果，供进程内所有session来使用。本意都是要提高查询效率。但是在实际使用的过程当中，它曾导致了很多问题，例如RC Latch、reliable message等资源等待问题（ID 1951729.1 - Bug 19557279，12c已经修复了这个问题）。

因此，为了避免系统遇到以上情况下发生更严重的性能问题，建议将结果缓存关闭掉。

SQL> alter system set "_optimizer_ads_use_result_cache"=false scope=spfile sid='*';

SQL> alter system set "_result_cache_max_size"=900 scope=spfile sid='*';

7.16 undo

在事务提交或回滚之后，因为flashback或一致读的需求，还需要将对应的undo数据保存在undo表空间中一段时间，这个时间就是由undo_retention来设置的。根据undo_retention可以继续将undo的inactive状态划分为EXPIRED，UNEXPIRED两类，undo中超过undo_retention时间之外的inactive undo回滚区称为expired, 还处于unod_retention时间之内的inactive undo回滚区称为unexpired。undo_retention不是说必须达到这个时间后才能被覆盖，而只是一个期望值，比如undo表空间文件设置为非自动扩展，当一个大事务需要将undo中未使用的区域及过期的undo区域都使用完了，而undo空间不能自动扩展，这时保证事务顺利运行优先级比较高，undo中没有过期的回滚区也会被覆盖使用(从其中使用时间越早的开始)，也就是说retention设置的时间段内的undo非过期数据是没有保证的。

10g之后引入一个新的参数“_undo_autotune”，这个参数表示Oracle对undo自动优化，就是在undo表空间非自动增长的情况下，Oracle会根据undo表空间的大小来调整undo RETENTION的大小，自动调整retention就是最大限度的利用当前undo表空间的可用空间，尽可能的保留最多的undo数据，以最大化的减少类似ORA-01555 等错误发生。

_undo_autotune此参数默认开启，有利于时间长的查询，但是对于典型的OLTP系统来说不太适用。尤其在系统繁忙的时候，经常会出现undo不够用的情况。回收undo，简单resize会报错。因此建议关闭次参数并设置合理的retetion时间。

SQL> alter system set "_undo_autotune"=false scope=spfile sid='*';

SQL> alter system set undo_retention=900 scope=spfile sid='*';

（1.OLTP系统:15分钟 / 2.混合:1小时 / 3.DSS系统:3小时）

7.17 执行计划中的排序

正常情况下，我们认为SQL查询计划如果利用index排序索引的话，从性能上看会是比较优的选择。但是往往在实际生产过程中，很多中情况如果走排序的话不一定会获得最优的查询计划，有的时候反而会更糟糕。因此Oracle用一个参数“_sort_elimination_cost_ratio”来控制是否一定走排序寻找最优执行计划。

当“不排序的成本/排序的成本”这个比值小于“_sort_elimination_cost_ratio”参数值时，Oracle会选择不走排序去获取执行计划。“_sort_elimination_cost_ratio”的默认值为0，也就是说Oracle默认任何情况下都选择排序获取执行计划，即使排序的成本是无穷大。

实践证明默认的选择往往是不对的，会将查询引入到错误的执行计划。因此建议将参数值设置为5。 SQL> alter system set "_sort_elimination_cost_ratio"=5 scope=spfile sid='*';

7.18 控制文件

关于控制文件的记录保存时间控制参数control_file_record_keep_time，默认值为7，也就是说控制文件只保留7天记录，超过7天的备份记录会被认为是无效的。这个值的设置需要跟两个地方关联起来：

1. 集中备份软件设置的备份策略中关于过期时间的定义。

2. Rman的参数retention policy。

例如我们的备份策略对某系统备份集过期的时间定义为30天，那么我们就分别对控制文件和RMAN两个地方的参数做如下设置（RMAN保留时间设置太长会导致list backup命令执行多几分钟时间）：

SQL> alter system set control_file_record_keep_time=30 scope=spfile sid='*';

RMAN> configure retention policy to recovery window of 30 days;

7.19 job_queue_processes

如果同一时间内运行的Job数很多，过小的参数值导致job不得不进行等待。而过大的参数值则消耗更多的系统资源。应该设置一个比较合理的数值，以避免此类事情发生。

Oracle默认值为1000，这个值对于一般的OLTP系统来讲比较大，所以需要进行合理的修改。

7.20 rman

1. 为了提高rman备份的效率，假设磁带备份设备支持异步I/O，建议将这个参数设置为true，以启动该设置。创建一个large pool，使得RMAN中获得良好的性能。 SQL> alter system set backup_tape_io_slaves=true scope=spfile sid='*';

2. 关于ADG备库的RMAN参数设置， RMAN> configure archivelog deletion policy to applied on standby; 这个参数设置是保护没有被应用的日志不被删除，在11g的高版本实际上已经不需要再设置了，但是低版本的就需要注意了。

7.21 其他

1．表空间的数据文件是否采用了自动扩展的方式？

2．表空间的数据文件是否都用了ASM的方式？

3．ASM的冗余方式是否一致？

4．应用用户的默认密码策略是不是已经取消了180天的限制等等。

5．数据库的监控指标是否覆盖了（集群、服务、监听、ASM、表空间、性能等所有应该涵盖的方面）？

6．OS层面的监控是否已经启用？尤其是私网之间的通讯、CPU、内存的监控等？是Nmon还是osw，他们的日志是定期循环还是持续不断增长等等？

7．数据库巡检的体系是否完善？日巡检月度巡检的内容是否经过精心设计？是否已经实现了自动化等等？强烈建议日巡检工作实现脚本自动化，任务定时执行，日志统一整合到共享文件系统上，有条件的可以进行整合入库，按照自己的巡检机制和体系实现按需调入调出。

8.总结及展望

本文是基于数据建设的规划、实施以及配置优化等阶段对大量文献的总结提炼以及项目的实践出发，对数据库建设过程中各个层面应该注意的事项进行了一个总结。希望对正在从事此项工作的同业以及将来要从事这类项目的同业给予参考，也希望更多人在此基础之上能够将其完善和优化分享给大家。

【主要参考文献】

[1]. RAC 和 Oracle Clusterware 最佳实践和初学者指南（平台无关部分） (文档 ID 1526083.1)

[2]. RAC and Oracle Clusterware Best Practices and Starter Kit (Linux) (文档 ID 811306.1)

[3]. RAC and Oracle Clusterware Best Practices and Starter Kit (AIX) (文档 ID 811293.1)

[4]. Top 11 Things to do NOW to Stabilize your RAC Cluster Environment (文档 ID 1344678.1)

[5]. IBM System p Advanced POWER Virtualization Best Practices

[6]. 最佳实践：主动避免数据库和查询相关的性能问题 (文档 ID 1549184.1)

[7]. 11gR2 Clusterware and Grid Home - What You Need to Know (文档 ID 1053147.1)

[8]. Oracle Databases on VMware Best Practices Guide

[9]. Deploying Oracle Database 11g R2 on Red Hat Enterprise Linux 6 Best Practices

[10].10g 和 11gR1 ASM 技术最佳实践 (文档 ID 1602417.1)

[11]. Oracle® Database High Availability Best Practices 11g Release 1 (11.1)

[12]. Oracle® Database High Availability Best Practices 11g Release 2 (11.2)

[13]. Oracle on AIX – Configuration & Tuning. R Ballough (ppt)

[14]. Oracle Database 11g R2 Oracle Database 11g R2 RAC on IBM AIX Tips and Considerations

[15]. Grid Infrastructure Redundant Interconnect and ora.cluster_interconnect.haip

此文章是转载于搜狐的文章