Oracle RAC 建设过程中必须应知、应做（下）

作者：赵海，某城商行系统架构师，专注并擅长银行数据中心解决方案规划及设计。目前在社区会员关注TOP100排行榜中名列第三位。

个人主页：http://www.aixchina.net/home/space.php?uid=353923

数据库建设过程中缺少可以遵循的实践标准，知识点和经验点散落四处难以快速形成逻辑性强的参照标准，面对项目令人无从下手。本文拟从各个层面进行总结和分析，为日后从事数据库建设的项目提供一个参考思路。

今日发布（下）篇，全文完结

（点击标题可阅读）

1.背景描述
2.存储规划设计的关键点
3.网络规划设计的关键点

（点击标题可阅读）

中

4.操作系统层的关键优化项
5.配置集群层的关键点
6.安装集群时的关键点

下

7.数据库层的关键优化项
8.总结及展望

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 =

(DESCRIPTION_LIST =

(DESCRIPTION =

(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

点击阅读原文到作者个人主页

长按二维码关注“AIX专家俱乐部”公众号