3.1.3 oracle系统中的十大顶级错误
这部分列举出了在oracle系统中发现的最普遍的错误。通过实施oracle性能改善的方法，你需要避免这
些错误。如果你在系统中发现这些错误，那么重新设计应用对于性能的改善效果是值得的。。可以参考
自动性能优化功能来查看关于帮助诊断和调整系统的功能。查看第十章 使用动态性能视图进行实例调优
来讨论等待事件如何影响性能。

1坏的链接管理
对于每个数据库的交互，应用都会链接和中断链接。对于应用服务器使用无状态的中间件的情况下，这
个问题是普遍的

2 对于游标和共享池的坏的使用
不使用游标导致了重复的解析，如果绑定变量未使用，那么就会对所有的sql进行硬解析。这就会产生对
性能的重要影响，也并不是完全不能扩展的。使用绑定变量的游标能打开和执行很多次。但是对于应用
产生的动态游标还是有疑问的。

3 坏的sql
坏的游标是使用了多于应用需求的资源的sql。那会是运行24小时的决策型系统的请求或者从花费多于一
分钟的来源于在线应用的请求。消耗很多系统资源的sql应该被调查是否可以做潜在的改善。ADDM找出了
高负载的sql，并且可以用sql调优advisor为优化提供建议。可以参考第六章 自动性能诊断和第十二章
自动sql优化

4 使用非标准的初始化参数
这个参数可能基于坏的建议和错误的假设基础上进行的设置。大多数的系统仅仅使用基础的参数给出可
接受的性能。尤其是和latch 上的spin_count相关的参数和不能证实的优化特征能够引起大量的问题需
要进行大量的调查。

同样的，优化初始化参数文件中的参数集优先于执行计划的调优。由于这些原因，模式，模式统计数据
以及优化集合应该作为一个组曲保证性能的持续性。

1 获得数据库的IO错误
 在可用的磁盘上有一些拙劣的设置，另外一些错误的标明了磁盘的数量，因为他们通过磁盘空间来配置
磁盘而不是IO带宽。可以查询第八章 IO配置和设计。

2redo日志的设计问题
一些站点使用了数量少，比较小的redo log。小的redo引起系统检查点不断发生，产生了buffer cache
和IO系统的高负载。如果redo log太少，那么归档就不能持续，并且数据库将会等待归档进程的完成。
可以查看第四章 哦诶之数据库的性能 关于redo log的信息。

3 buffer cache中连续数据块的寻找导致缺乏freelist列表，freelist 组，事务槽，或者缺乏回滚段。
这尤其体现在插入比较频繁的应用中，在已经设置块大小为8K的应用中，或者大量的活跃用户但是仅仅
有少量的回退段的应用中。使用自动段空间管理和自动回退段空间管理来解决这个问题。

4 长期的全表扫描
长期进行大容量的全表扫描或者交互型的在线操作能标示出坏的事务设计，缺乏索引，或者sql优化。长
期的表扫描，本质上是IO密集型和不可扩展的。

5 大量的递归sql
sys执行的大容量的递归sql能够标识空间管理活动，比如区间分配。这个是非扩展的并且影响用户响应
时间。用户本地管理表空间来管理区间分配回降低递归sql。递归sql在另外的用户id下执行可能是sql或
者plsql，这并不是问题。

6 部署和迁移问题
在一些案例中，一个应用使用太多的资源是因为模式拥有的表没有正确的从开发环境或者旧的开发中迁
移过来。比如缺少索引或者正确的统计数据。这个错误会导致不好的执行计划和坏的用户交互性能。当
从已知性能的环境中迁移应用，要使用DBMS_STATS包导出模式的统计数据来维护计划的稳定性。

尽管这些错误不被ADDM直接检测，ADDM高亮显示了导致高负载的SQL。