盘点 Oracle 11g 中新特性带来的10大性能影响

转自 https://mp.weixin.qq.com/s?__biz=MjM5MDAxOTk2MQ==&mid=2650275500&idx=1&sn=84bc12fea2b88a92162117ab95a52954&chksm=be4866ba893fefac19fd7abb984057be31f506b7f4ad524c9715da6ca067b0df4a6304c38048&scene=21#wechat_redirect

Oracle的任何一个新版本，总是会带来大量引人瞩目的新特性，但是往往在这些新特性引入之初，首先引起的是一些麻烦，因为对于新技术的不了解、因为对于旧环境的不适应，从Oracle产品到技术服务运维，总是要走过一个磨合的长期过程。

请注意：我们并不推荐大家盲目的关闭和摒弃Oracle的新特性，我们建议大家在遇到问题时，做出适合自己的调整。

就此盘点一下 Oracle 11g 中，那些新特性带来的新烦恼，如果有用户准备或者刚刚踏入这个新版本，则可以作为借鉴。

1 Adaptive direct path read - 自适应的直接路径读

在Oracle Database 11g中有一个新特性，全表扫描可以通过直接路径读的方式来执行（Direct Path Read），这是一个合理的变化，如果全表扫描的大量数据读取是偶发性的，则直接路径读可以避免大量数据对于Buffer Cache的冲击。

可是现实往往是残酷的：在很多业务系统中，全表扫描是普遍存在的常态，将大表的全表扫描全部转化为直接路径读，反而不如Cache在Buffer Cache中效率高，Direct Path Read反而成为了一个严重的负担。

当然对于小表来说，Oracle允许通过Buffer Cache来进行全表扫描，因为这可能更快，也对性能影响不大。小表受到隐含参数：_small_table_threshold 影响。如果表大于 5 倍的小表限制，则自动会使用DPR替代FTS。

如果遇到这个特性的负面影响，可以设置初始化参数： _serial_direct_read 来禁用串行直接路径读，其默认值为AUTO，设置为NEVER时禁用 11g 的自动direct path read的特性。该参数可以动态在实例或会话级别修改，而无需重启实例（可以结合Event 10949设置）。

SQL> alter system set "_serial_direct_read"=auto;

SQL> alter system set "_serial_direct_read"=never;

以下的AWR信息是典型的DPR症状，我们看到Direct Path Read在这个报告中处于最占用DB Time的部分：

如果结合ASH报告更加一目了然，显示全表扫描的SQL，都在以Direct Path Read的方式执行 Table Access Full：

2 Adaptive Log File Sync - 自适应的Log File Sync

关于 Log File Sync 等待的优化，在Oracle数据库中一直是常见问题，LOG FILE的写出性能一旦出现波动，该等待就可能十分突出。

在Oracle 11.2.0.3 版本中，Oracle 将隐含参数 _use_adaptive_log_file_sync 的初始值设置为 TRUE，由此带来了很多 Log File Sync 等待异常的情况，这个问题虽然由来已久，但是仍然有很多Oracle的用户并不知情。

当前台进程提交事务（commit）后，LGWR需要执行日志写出操作，而前台进程因此进入 Log File Sync 等待周期。

在以前版本中，LGWR 执行写入操作完成后，会通知前台进程，这也就是 Post/Wait 模式；在11gR2 中，为了优化这个过程，前台进程通知LGWR写之后，可以通过定时获取的方式来查询写出进度，这被称为 Poll 的模式，在11.2.0.3中，这个特性被默认开启。这个参数的含义是：数据库可以在自适应的在 post/wait 和 polling 模式间选择和切换。

 _use_adaptive_log_file_sync 参数的解释就是： Adaptively switch between post/wait and polling ，正是由于这个原因，带来了很多Bug，反而使得 Log File Sync 的等待异常的高，如果你在 11.2.0.3 版本中观察到这样的表征，那就极有可能与此有关。

在遇到问题是，通常将 _use_adaptive_log_file_sync 参数设置为 False，回归以前的模式，将会有助于问题的解决。

3 Adaptive Cursor Sharing - 自适应游标共享

Oracle数据库的SQL使用的是共享机制，通过绑定变量可以使Oracle DB 可以为多条SQL 语句共享单个游标，以减少分析SQL 语句所使用的共享内存和CPU资源等。

然而一个执行计划并不总是适用于所有绑定值，为了尽可能生成准确的执行计划，Oracle Database 11g 引入了自适应游标共享的新特性，在执行共享SQL时考虑更多的因素，如果与资源开销相比，使用多个执行计划所带来的收益更重要，则会为使用绑定变量的每条SQL 语句生成多个执行计划。

Adaptive Cursor Sharing 通过自适应游标共享，可以仅针对使用绑定变量的语句智能地共享游标。但是有时候这个特性会使得确定的执行计划变得不稳定，如果你确定系统中无需额外自适应的分析和变更执行计划，或者可能被不稳定的执行计划影响。那么可能需要调整这个特性的使用。

关闭这个特性，可以设置隐含参数：

SQL> alter session set"_optimizer_extended_cursor_sharing_rel"=none; 

SQL> alter session set"_optimizer_extended_cursor_sharing"=none; 

SQL> alter session set"_optimizer_adaptive_cursor_sharing"=false;

4 Oracle 11g 密码延迟认证

在 Oracle 11g 中，为了提升安全性，Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是，如果用户输入了错误的密码尝试登录，那么随着登录错误次数的增加，每次登录前验证的时间也会增加，以此减缓可能对于数据库重复的口令尝试攻击。

但是对于正常的系统，由于口令的更改，可能存在某些被遗漏的客户端，不断重复尝试，从而引起数据库内部长时间的 Library Cache Lock的等待，这种情形非常常见。

如果遇到这一类问题，可以通过Event 28401关闭这个特性，从而消除此类影响，以下命令将修改设置在参数文件中：

ALTER SYSTEM SET EVENT =
 '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

出现这类问题非常典型的AWR报告呈现如下，首先在 TOP 5 中，你可能看到显著的 Library Cache Lock 的等待，以下范例来自11.2.0.3.0版本的真实情况：

在这类情况下，时间模型 - Time Model 中会显示如下指标，其中 connection management call elapsed time 占据了主要的DB Time，这个等待直接表明是在建立数据库连接时产生的：

这类问题，在Oracle的11g中是常见和确定的，在MOS上可以找到相应的记录：High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1）此外Oracle 11g开启了密码大小写验证，如果从Oracle 10g升级过来，需要特别的当心这个变化，通过初始化参数SEC_CASE_SENSITIVE_LOGON 可以来控制这个特性。

5_datafile_write_errors_crash_instance - 文件写错

从Oracle 11.2.0.2版本开始，一个新的隐含参数 - _datafile_write_errors_crash_instance 被引入到数据库中，通过这个参数名就可以了解到其含义：当发生数据文件写错误时，Crash数据库实例。

为什么要引入这个参数呢？这个参数后台解决的是什么问题呢？

我在《数据安全警示录》一书上曾经写过多个案例，在归档模式下当发生文件（非SYSTEM文件）写错误时，Oracle会自动将数据文件离线，这造成了很多灾难，类似的错误日志可能是这样的：

Fri Jan 13 19:32:21 2013
KCF: write/open error block=0xf1fa6 online=1
     file=73 /dev/rods_gm05
     error=27063 txt: 'IBM AIX RISC System/6000 Error: 22: Invalid argument
Additional information: -1
Additional information: 557056'
Automatic datafile offline due to write error on
file 73: /dev/rods_gm05

鉴于很多用户遇到的困境，Oracle做出了修正，这一修正在MOS上以BUG形式被提交，其内容为：Bug 7691270  Crash the DB in case of write errors (rather than just offline files) 。

在11.2.0.2之前，如果数据库运行在归档模式下，并且写错误发生在非SYSTEM表空间文件，则数据库会将发生错误的文件离线，在从11.2.0.2开始，数据库会Crash实例以替代Offline。注意：在非归档模式下或者SYSTEM遭受错误时，数据库会直接崩溃。

好了，现在答案清楚了：为了解决数据文件损失，离线控制存在的不确定性风险，Oracle引入的 _datafile_write_errors_crash_instance 控制数据库实例直接崩溃。

如果你不能接受这一选择，那么设置参数 _datafile_write_errors_crash_instance 为False。

6 _optimizer_use_feedback - 优化器的基数反馈

Cardinality Feedback - 基数反馈，是Oracle 11.2中引入的新特性，这个新特性利用SQL执行过程中的信息采集，动态的调整执行计划，以解决统计信息陈旧、无直方图或基于直方图基数计算不准确等情况。

Oracle希望由此提升执行计划的准确性，但是在某些情况下，我们可能遇到SQL 第一次执行性能最好，之后再运行其性能变差的情况。

初始化参数 _optimizer_use_feedback 可以控制这个特性的启用，设置为False关闭了这个特性：

alter system set “_optimizer_use_feedback”=false;

7 deferred_segment_creation - 延迟段创建

在Oracle 11.2中， 当我们创建一个空表或者空分区时，为了加快创建速度，Oracle并不会立即分配初始段和空间，实际的表段Table Segement被延迟到第一行数据插入时创建。

该功能通过DEFERRED_SEGMENT_CREATION参数启用，默认为TRUE。延迟段创建可以节省空间，加快初始化过程，是面向性能和资源的一个优化。

这个新特性带来的一个问题是，在使用 exp / imp 进行导出导入时，不会包含这些空表，可能导致遗漏对象。

如果觉得这个特性是困扰，可以通过修改参数关闭这个特性：

alter system set deferred_segment_creation=flase sscope=spfile;

8 resource_manager_always_on - 资源管理器

在11g中，Oracle的资源管理器缺省被启用，并且时常发挥作用，并可能引发竞争。

你可能在TOP 5事件中看到类似的情景：

有两个参数配合设置，可以在你不需要资源管理器时彻底关闭这个隐含的控制：

SQL> alter system set "_resource_manager_always_off"=true scope=spfile; 

SQL> alter system set "_resource_manager_always_on"=false scope=spfile;

9 _gc_policy_time - RAC集群中的DRM管理

DRM是 Dynamic Resource Management 的简称，意思就是动态资源管理。在Oracle RAC中，所有的数据块（Data block）都有一个实例作为主实例进行管理，叫做Master，Master 负责照看好自己所管辖的data block的状态，包括锁定等，并对跨实例访问进行授权。

如果能随着数据块的访问频繁动态的修改数据块的master节点，那么对应GC的grant message则会大量的减少。基于以上考虑，DRM特性应运而生。但是早期的DRM在进行 re-master的过程中长长带来短时的性能影响，在很多重要环境中，这是不能忍受的。

如果希望关闭DRM这个特性，可以结合设置 _gc_policy_time 和  _gc_undo_affinity :

alter system set "_gc_policy_time" = 0 scope=spfile;

alter system set "_gc_undo_affinity" = false scope=spfile;

在白求恩智能诊断平台上（https://bethune.enmotech.com），对于DRM特性的检测结果如下：

很多的新特性，由于DBA对其原理不够了解，使用不当往往会带来很多的性能影响。在白求恩平台上，针对新特性的部分会详细检查。帮助DBA快速找出系统中存在的一些隐患。

白求恩，从架构到细节，全方位诊断系统安全与健康，比你更了解你的数据库。现在登录立即体验：https://bethune.enmotech.com

10 cleanup_rollback_entries 、_undo_autotune UNDO的清理和调整

在UNDO的管理中，如何设置保留时间，清理回滚段条目，释放UNDO空间，在高事务率的数据库中非常重要。

_cleanup_rollback_entries - 指定回滚时每次回滚的ENTRIES个数，默认为100，可以设置更高提升回滚速度；

_undo_autotune - 用于自动调整undo retention时间，设置 _undo_autotune=true，则undo_retention不再适用，Oracle会自行决定tuned_undo_retention；

以下设置在需要时对这些特性做出调整：

alter system set "_undo_autotune" = false scope=spfile;

alter system set "_cleanup_rollback_entries" = 1000 scope=spfile;

---

系统的性能永远是DBA最关注的问题，Bethune能够帮助你快速检测出数据库当前的或者潜在的性能隐患，更好地防范。然而，在真正遇到问题的时候，面对庞大负责的性能体系，该如何找到正确的方法优化系统性能呢？

恩墨学院推出性能优化案例视频课程，由侯院长亲自教授，以数据库常用性能优化技术进行讲解，包括锁等待、索引优化和列计算等技术；通过本课程的学习，你将初步具备性能优化诊断与处理的能力，在后续实战中也会对数据库的性能优化更加专业和熟练。