Oracle数据库的优化建议【数据库建设及优化的一般思路】：1.安装过程Oracle官方对于ORACLE的通用最佳实践提供的非常详细，针对不同平台、针对不同版本、针对不同用途等都会有相应一套实施的最佳实践。

例如：1）RAC 和Oracle Clusterware 最佳实践和初学者指南（平台无关部分）Document 810394.1RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent)2）特定平台的详细最佳实践Document 811306.1RAC and Oracle Clusterware Best Practices and Starter Kit (Linux)3）操作系统配置注意事项4）虚拟化注意事项5）存储注意事项6）网络注意事项7）特定硬件注意事项2.测试及系统上线之前这个过程当中，根据特定的应用场合及测试结果以及我们对数据库理解的不同可能会产生一些以行业背景为区分的行业经验及行业实践。

本次活动也在借此机会进行总结和整理形成一些初步的经验点的积累，具体问题及解答聚焦在如下几个方面：1）关于重做日志的配置优化应该做哪些点？应该如何做？首先、接触过数据库的人相信对这个概念都不陌生。

数据库在做SQL更新的时候，首先要将事务执行过程记入重做日志当中，然后才会把日志刷入磁盘，将数据更新持久化。

一条数据提交之后成功的标准时日志落到磁盘，而不是真正的数据落盘。

因此日志的配置（大小、数量）直接决定着数据库读写的性能，如果日志大小非常大，那么会造成归档切换时间非常长，一旦这时候发生了不可恢复的DB灾难，那么通过备份恢复的数据流失量或者说RPO就会较大。

日志大小非常小的话，势必会造成日志频繁切换，AWR里面有大量的日志切换事件，这样对数据库的性能会有较大影响。

因此根据性能测试的AWR报告中日志切换的等待事件、和切换频度来决定其数据量和大小是否需要调整。

一般的OLTP建议（10组、500M）。

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

比如说“_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。

比如说“archive_lag_target”，它决定了我们是否开启日志强制切换功能，为了减少故障时数据损失，可以设置ARCHIVE_LAG_TARGET参数，强制进行日志切换。

这个参数的缺省值是0，即为不启用该参数。

建议设置值为1800。

2）关于ORACLE的内存管理应该关注那些点？应该如何配置？首先、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管理。

手动调整内存参数，具体可以参照以下：//关闭内存自动管理memory_target=0memory_max_target=0//设置SGA为固定值，可以根据性能测试中的AWR报告中的建议sga_max_size=XGsga_target=XG//设置PGA等参数pga_aggregate_target=XGlarge_pool_size=256M另外很重要的一个参数，“_shared_pool_reserved_pct”，如果这个参数设置小了，很可能导致ORA04031，TROUBLESHOOTING ORA-4031 - Simple Guide and Basic Approach to Solve the issue (文档ID 1416817.1)3）关于Linux系统下的大页配置？在Linux 环境中实施HugePage 能够极大地提高内核性能。

对于内存较大的系统，效果尤其明显。

一般而言，系统中的RAM 越大，系统启用Hugepage 后获得的好处也越大。

这是因为内核为映射和维护内存页表所要做的工作量会随着系统内存的增大而增加。

启用Hugepage 能够显著地降低内核要管理的页面数，而且能提高系统的效率。

经验表明，如果未启用Hugepage，内核挤占关键的Oracle Clusterware 或Real Application Clusters 守护进程的情况会很常见，而这会导致实例或节点驱逐出现。

具体配置方法可以参照：HugePages on Linux: What It Is... and What It Is Not... (文档ID 361323.1)4）关于SQL解析相关的参数优化？首先、在Oracle中每条SQL语在执行之前都需要经过解析，这里面又分为软解析和硬解析。

在Oracle 中存在两种类型的SQL语句，一类为DDL语句(数据定义语言)，他们是从来不会共享使用的，也就是每次执行都需要进行硬解析。

还有一类就是DML语句(数据操纵语言)，他们会根据情况选择要么进行硬解析，要么进行软解析。

一般我们希望我们的AWR报告中硬解析偏少，而软解析偏多。

因为硬解析的代价会非常高。

为了减少带绑定变量的sql的解析时间，oracle 9i引入的绑定变量窥测的功能。

也就是在同一个SQL的变量被赋于不同值时采用同一个游标，这样虽然节省了sql的解析时间。

大家有没有通过功能的打开或者关闭实际观察过AWR中的软硬解析数目的实际状况呢？其实对于绑定变量窥测这个特性以及后来的自适应游标等特性，都是oracle为了找到最优执行计划而启用的一些新特性，但是在实际应用过程中，对于不同量级不同特性的业务场景也曾经因此出现了很多bug。

understanding and Diagnosing ORA-00600 [12333] / ORA-3137 [12333] Errors (ID 389713.1)根据自己的业务系统特点，做大量的性能测试和业务测试，根据参数的关闭打开对比awr报告当中显示出的软硬解析比率以及执行计划数据决定是否打开或者关系相应功能特性。

如下参数："_optim_peek_user_binds""_optimizer_adaptive_cursor_sharing""_optimizer_extended_cursor_sharing""_optimizer_extended_cursor_sharing_rel""_optimizer_use_feedback"接着，与之相关的几个参数：open_cursors、session_cached_cursors 这两个参数决定着应用会话可以控制打开以及缓存的游标数量，如果数量不足，就会引起SQL解析的性能问题。

这两个参数要根据v$resource_limit视图中的值的情况进行调整，避免资源设置不合理导致的性能问题。

还有，与执行解析执行计划相关的几个参数，_b_tree_bitmap_plans、有时将B-Tree索引进行BITMAP转换来进行SQL执行，往往会生成极其恶劣的执行计划，导致CPU100%。

Select Fails With ORA-600 [20022] (文档ID 1202646.1)建议可以关掉。

5）如何避免数据库集群节点之间的激烈竞争？数据库节点之间的竞争有很多，包括锁（各种粒度锁）的竞争以及数据的传输等。

完全避免竞争那就失去了RAC的意义了，RAC本身就是希望能在两个节点并行执行任务。

如果特别极致的并行一定引起严重的性能问题，如果完全禁止，既无法做到又失去了集群本来的意义。

所以我们只能在一定程度上去平衡：首先、关于DRM，oracle的DRM特性从理论上来看，它是为了避免节点间的数据量传输，避免节点间的锁等待事件频繁发生。

DRM的极致是做到请求节点和Master节点统一化。

但是实践中，这个特性引起了很多的BUG、反而导致了节点间的竞争出现了性能故障。

Bug 6018125 - Instance crash during dynamic remastering or instance reconfiguration (Doc ID 6018125.8)。

所以建议关闭。

接着、关于参数“parallel_force_local”，ORACLE RAC为了实现多节点并行处理是花费了很大代价的，假设一个集群当中有三个节点，对于某一个数据块儿读写，有一个Master、有一个请求者、有一个拥有者，请求者向Master请求数据块儿的最新版本，Master把请求转发给拥有者，拥有者按照请求信息把数据块儿传送给申请者，然后加锁进行读写。

这一过程是需要有大量的数据传输和竞争存在的，一旦这个事情成为多数，那么势必造成节点间的通讯负载过大，造成大量的锁等待时间，严重影响数据库整体性能。