概述

Oracle的任何新版本总会带来许多新特性。今天主要介绍oracle11g中的十个特性，有助于加深对oracle11g的理解。

1.Adaptivedirectpathread-自适应的直接路径读

在OracleDatabase11g中有一个新特性。DirectPathRead可以执行全表扫描，这是一个合理的改变。如果全表扫描中的大量数据读取是零星的，直接pathread可以避免大量数据对BufferCache的影响。

然而现实往往是残酷的：在很多业务系统中，全表扫描是无处不在的常态，将大表的全表扫描全部转换成直接路径读取，效率还不如BufferCache中的Cache，DirectPathRead已经成为一个严重的负担。

当然，对于小表，Oracle允许通过BufferCache进行全表扫描，因为这样可能速度更快，对性能影响也不大。小表受隐式参数影响：_small_table_threshold。如果表格大于小表格限制的5倍，将自动使用DPR而不是FTS。

如果遇到该特性的负面影响，可以设置初始化参数：_serial_direct_read禁用串行直接路径读取，默认值为AUTO。如果设置为NEVER，11g的自动directpathread功能将被禁用。此参数可以在实例或会话级别动态修改，而无需重新启动实例(可以与Event10949一起设置)。

SQLaltersystemset ' _ serial _ direct _ read '=auto；

SQLaltersystemset ' _ serial _ direct _ read '=never；

以下AWR信息是典型的DPR症状，可以看出DirectPathRead在此报告中是DBTime中占用最多的部分：

如果结合ASH报告，更明显的是显示全表扫描的SQL是以DirectPathRead的方式执行TableAccessFull:

2.AdaptiveLogFileSync-自适应的LogFileSync

日志文件同步等待的优化一直是Oracle数据库常见的问题。一旦日志文件的写入性能出现波动，等待可能会非常突出。

在Oracle版本Oracle11.2.0.3中，Oracle将隐式参数_use_adaptive_log_file_sync的初始值设置为TRUE，这带来了很多LogFileSync等待异常的情况。虽然这个问题由来已久，但很多Oracle用户还是不知道。

前台进程提交事务后，LGWR需要执行日志写操作，前台进程因此进入LogFileSync等待期。

在之前的版本中，LGWR会在写操作完成后通知前台进程，这是Post/Wait模式；在11gR2中，为了优化这个进程，前台进程通知LGWR写后，可以通过定时采集的方式查询写进度，这就是所谓的轮询模式。在11.2.0.3，默认情况下此功能是打开的。该参数的含义是数据库可以自适应地选择post/wait和polling模式并在它们之间切换。

参数_use_adaptive_log_file_sync的解释是：post/wait和polling之间的自适应切换。正是这个原因带来了大量的bug，但是LogFileSync的等待却异常的高。如果你在11.2.0.3版本中观察到这样的表现，它很可能与此相关。

遇到问题时，一般会将_use_adaptive_log_file_sync参数设置为False，回到之前的模式有助于解决问题。

3.AdaptiveCursorSharing-自适应游标共享

Oracle数据库的SQL使用共享机制。通过绑定变量，OracleDB可以为多个SQL语句共享一个游标，从而减少分析SQL语句时使用的共享内存和CPU资源。

然而，一个执行计划并不总是适用于所有的绑定值。为了生成尽可能准确的执行计划，OracleDatabase11g引入了自适应游标共享的新特性，在执行共享SQL时考虑了更多的因素。如果使用多个执行计划的好处比资源开销更重要，那么将使用绑定变量为每个SQL语句生成多个执行计划。

AdaptiveCursorSharing使您能够通过自适应游标共享，仅对使用绑定变量的语句智能地共享游标。但是有时候这个特性会使得确定的执行计划变得不稳定,如果确信没有必要对系统中的执行计划进行额外的适应性分析和改变，否则它可能会受到不稳定的执行计划的影响。您可能需要调整此功能的使用。

通过关闭此功能，您可以设置隐式参数：

SQLaltersessionset ' _ optimizer _ exte

nded_cursor_sharing_rel"=none;

SQL>altersessionset"_optimizer_extended_cursor_sharing"=none;

SQL>altersessionset"_optimizer_adaptive_cursor_sharing"=false;

4.Oracle11g密码延迟认证

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

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

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

ALTERSYSTEMSETEVENT='28401TRACENAMECONTEXTFOREVER,LEVEL1'SCOPE=SPFILE;

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

在这类情况下，时间模型-TimeModel中会显示如下指标，其中connectionmanagementcallelapsedtime占据了主要的DBTime，这个等待直接表明是在建立数据库连接时产生的：

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

5._datafile_write_errors_crash_instance-文件写错误终止实例

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

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

在归档模式下当发生文件（非SYSTEM文件）写错误时，Oracle会自动将数据文件离线，这造成了很多灾难，类似的错误日志可能是这样的：

FriJan1319:32:212018KCF:write/openerrorblock=0xf1fa6online=1file=73/dev/rods_gm05error=27063txt:'IBMAIXRISCSystem/6000Error:22:InvalidargumentAdditionalinformation:-1Additionalinformation:557056'Automaticdatafileofflineduetowriteerroronfile73:/dev/rods_gm05

鉴于很多用户遇到的困境，Oracle做出了修正，这一修正在MOS上以BUG形式被提交，其内容为：Bug7691270CrashtheDBincaseofwriteerrors(ratherthanjustofflinefiles)。

在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-优化器的基数反馈

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

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

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

altersystemset"_optimizer_use_feedback"=false;

7.deferred_segment_creation-延迟段创建

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

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

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

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

altersystemsetdeferred_segment_creation=flasesscope=spfile;

8._resource_manager_always_on-资源管理器

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

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

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

SQL>altersystemset"_resource_manager_always_off"=truescope=spfile;SQL>altersystemset"_resource_manager_always_on"=falsescope=spfile;

9._gc_policy_time-RAC集群中的DRM管理

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

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

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

altersystemset"_gc_policy_time"=0scope=spfile;altersystemset"_gc_undo_affinity"=falsescope=spfile;

10._cleanup_rollback_entries、_undo_autotune-UNDO的清理和调整

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

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

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

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

altersystemset"_undo_autotune"=falsescope=spfile;

altersystemset"_cleanup_rollback_entries"=1000scope=spfile;

---

篇幅有限，今天主要讲一下oracle11g的这些新特性，帮助大家更好的理解oracle为什么要这样设计。

后面会分享更多关于DBA内容，感兴趣的朋友可以关注下~