Oracle的任何一个新版本，总是会带来大量引人瞩目的新特性，但是往往在这些新特性引入之初，首先引起的是一些麻烦，因为对于新技术的不了解、因为对于旧环境的不适应，从Oracle产品到技术服务运维，总是要走过一个磨合的长期过程。
请注意：我们并不是推荐大家盲目的关闭和摒弃Oracle的新特性，我们建议大家在遇到问题时，做出适合自己的调整。
就此盘点一下Oracle 11g中，那些新特性带来的新烦恼，如果有用户准备或者刚刚踏入这个新版本，则可以作为借鉴。
1. Adaptive direct path read-自适应的直接路径读
在Oracle Database 11g中有一个新特性，全表扫描可以通过直接路径读的方式来执行，这是一个合理的变化，如果全表扫描的大量数据读取是偶发性的，则直接路径可以避免大量数据对于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在这个报告中处于最占用DBTime的部分：
在这类情况下，时间模型-Time Model中会显示如下指标，其中connection management call elapsed time 占据了主要的DB Time ,
这个等待直接表明是在建立数据库连接时产生的：
这类问题，在Oracle的11g中是常见和确定的，在MOS上可以找到相对应的记录：High libraty 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-文件写错误终止实例
从Oracle11.2.0.2版本开始，一个新的隐含参数-datafile-write-errors-ceash-instance被阴柔到数据库中，通过这个参数名就可以了解到其含义：当发生数据库文件写错误时，Crash数据库实例。 |
么要引入这个参数呢？这个参数后台解决的是什么问题呢？
我在《数据安全警示录》一书上曾经写过多个案例，在归档模式下当发生文件（非SYSTEM文件）写错误时，Oracle会自动将数据文件离线，这造成了很多灾难，类似的错误日志可能是这样的：
Fri Jan 13 19:32:21 2013
KFC:write/open error block=0xf1fa6 online=1file=73/dev/rods-gm05
error=27063 txt:IBM AIX RISC
System/6000Error:22:Invalid argument
Additional information:-1
Additional information:557056
Automatic datafile due to write error on file73:/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实例以替代Office。注意：在非归档模式下或者SYSTEM遭受错误时，数据库会直接崩溃。
好了，现在答案清楚了：为了解决数据文件损失，离线控制存在的不确定性风险，Oracle引入的-datafile-write-errors-crash-instance控制数据库实例直接崩溃。
如果你不能接受这一选择，那么设置参数-datafile-write-errors-crash-instance为False.