系统投产前，Oracle数据库优化思路和9个典型问题

Posted 2021-05-01 twt企业IT社区

系统上线前，对于基础架构的技术审核可能需要伴随一系列整改和优化，其中数据库层面的整改和优化是最重要的一项。以下来自社区会员的经验和心得可供参考（以Oracle为例）。由社区专家赵海整理总结。

1.安装时（文档 ID 1525820.1）

其实Oracle官方对于Oracle的通用最佳实践提供的非常详细，针对不同平台、针对不同版本、针对不同用途等都会有相应一套实施的最佳实践。

例如：

1）RAC 和 Oracle Clusterware 最佳实践和初学者指南（平台无关部分）
Document 810394.1 

RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent)

2）特定平台的详细最佳实践

Document 811306.1 

RAC 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=0

memory_max_target=0

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

sga_max_size=XG

sga_target=XG

//设置PGA等参数

pga_aggregate_target=XG

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

6）关于数据库的自动任务？

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

Automatic Optimizer Statistics Collection（自动优化器统计信息收集）：

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

Automatic Segment Advisor（自动段指导）：

识别有可用回收空间的段，并提出如何消除这些段中的碎片的建议。您也可以手动运行 Segment Advisor 获取更多最新建议，或获取 Automatic Segment Advisor 没有检查到的那些有可能做空间回收的段的建议。

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

关于统计信息收集，数据库是有其自己的默认启动时间，11g是在22:00-2:00之间，假设这个时间跟我们的跑批时间有冲突的话，我们可以修改器具体执行时间。但是这个任务必须保留。

关于其他的两个优化指导，其实要看我们实际工作中用到的几率是否很高，是否有价值留着给我们提供一些优化的理论指导。一般感觉用不好的话意义不大，还不如不用。

7）关于安全方面的几个配置优化？

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

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

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

最后，所有这些重定给OS或者本来就依靠OS的日志文件也好、审计文件也好。一定得注意其对OS的i节点资源使用情况的一个把握，不要出现df -h正常但是df -i 不正常的情况。这个往往是非常容易忽视的一点。无论是从监控上还是从OS对用户资源参数的限定上都要有一个明确的把握。

8）关于ADG的关注点？

ADG本身作为容灾的一个手段，那么其本身会有很多点需要我们监控。比如说主备库的状态、日志的切换状况、数据之间有没有GAP等等。但是我想说的是我们非常容易忽略的地方。

首先，关于备库的RMAN参数设置，

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

这个参数设置是保护没有被应用的日志不被删除，在11g的高版本实际上已经不需要再设置了，但是低版本的就需要注意了。具体可以参照文档 ID 1577382.1

9）其他在管理数据库时应该注意的点？

例如：

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

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

ASM的冗余方式是否一致？

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

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

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

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

更多相关内容，请点击阅读原文