刀是最大众化的武器，小到刮刀、折刀、剃刀、西瓜刀、切菜刀、剔骨刀，大到柳叶刀、圆月弯刀、武士刀、青龙偃月刀。。。不论大小长短、不论古今中外，刀是最常见的武器。不过再普通的刀，到了高手的手中，也会成为神兵利器，刀如此，Oracle的动态性能视图也如此，无论各种性能问题，根源皆可寻究于此。
这些试图包括：V$SYSSTAT V$SESSION V$SESSTAT V$SGASTAT
V$FILESTAT V$UNDOSTAT V$ROLLSTAT V$WAITSTAT ；V$LOCK V$LATCH V$SQL V$SQLAREA V$SQLTEXT；V$PROCESS ；V$LIBRARYCACHE； V$ROWCACHE等等。
李轶楠谈到，不是每个问题，都那么清楚的摆在我们面前，细致的察看，仔细的分析，利器才是利器
===================================
剑，轻灵、快速、灵敏，甚至于诡异。谈笑间，轻松快意时寻出敌人弱点，以闪电般的速度刺入敌人最虚弱的部位，一击破敌。
性能优化的核心是什么，快速准确的定位，不需要华丽的显示，不需要冗长的信息，需要的仅仅是一个准确的定位，等待事件就是此中利器。
竞争即等待，关注等待事件：v$system_event / v$session_event / v$session_wait 有助于我们发现系统的性能瓶颈。比如：
从v$system_event中，我们能发现系统问题；从v$session_event中发现会话问题； 从v$session_wait的参数中可以找到竞争对象。
熟悉各种主要的等待事件,快速定位问题所在 ，如图
常用等待事件：
? buffer busy waits(数据高速缓存忙等待)
? db file scattered read(数据文件离散读取)
? db file sequential read(数据文件顺序读)
? direct path read(直接路径读取)
? direct path write(直接路径写出)
? enqueue(队列)
? free buffer waits(空闲缓冲区等待)
? latch free(锁存器空闲)
? log buffer space(日志缓冲区空间分配)
? log file switch(archiving needed)
? log file switch(checkpoint incomplete)
? log file sync(日志文件同步)
=================================================
枪中之霸王，胆气之结晶。枪具有剑的轻灵，又有棍的霸道，不论是快速定位，还是全面分析，都是statspack所能胜任的。有了全面的信息收集，分析问题变得简单了。
Statspack输出包含丰富的信息，如数据库和实例名称；获取快照的时间；当前高速缓存的大小；负载概览；实例效率百分比；前五个等待事件；等待事件的完整列表；共享池中SQL语句的信息；实例活动统计；表空间和文件I/O；缓冲区统计信息；回退段或还原段统计信息；字典高速缓存统计信息；库高速缓存统计；SGA统计；Init.ora参数的启动值等。
====================================================
是一种暗器，但又不是暗器。悄然，自动，不动声色间，一切皆在握。Oracle在10g开始，推出了一系列自动化、智能化的工具，虽然这些工具在以前或多或少都有相似的影子，但功能的增强、理念的增强，造就了这些以前所不具备的新工具。
Active Session History（ASH）-活动会话历史，每秒钟自动从内存中抓取样例的活动会话信息，比如，通过以下语句：
select a.sql_text from v$sql a
where sql_id in (select sql_id from v$active_session_history where session_id=157);
? 信息直接从内存结构中获取，并不保存，仅在系统运行中有效
? 可以得到
? SID
? SQL ID
? Program
? Wait event#
? Object, File, Block
? actual wait time (if captured while waiting)
通过ashrpt.sql可以产生ash分析报告，发现某个时段的TOP (Top Events/ Top SQL/ Top Sessions/ Top Objects/Files/Latches)
通过活动会话历史信息，可以追溯到性能问题的根源，找出什么资源在竞争？向下追溯到哪个程序带来了竞争？以及哪个SQL带来了竞争？
用户可以找出活动会话信息中的TOP，如通过TOP SQL可以进一步发现问题。
Automatic Workload Repository-自动负载信息库 (AWR)
? 10g的数据库中内置了工作负载信息库
? AWR是Oracle10g数据库自动化管理的基础架构
? 自动捕获工作负载数据
? 默认情况下，每隔 60 分钟保存一次，或者手动保存 7 天的数据
? 存储在新SYSAUX 表空间内
? 服务器自动管理空间要求
? 自动清除旧数据
? 存储不同类别的数据：
? 基本统计，例如物理读取
? SQL 统计，例如磁盘读取（每个 sql 语句）
? 量度，例如，物理读取数量/秒
? 通过awrrpt.sql可以产生与statspack类似的性能差异报告
Automatic Database Diagnostic Monitor -自动数据库诊断监控(ADDM) ：
? AWR收集完信息后自动调用，为数据库提供性能诊断分析报告
? 分析依赖于AWR收集的性能信息快照，对比两次收集快照的性能差异，提供分析建议
? 由Oracle自动调用，也可以手动调用
? 可以分析当前的，最近一次收集的，也可以分析之前还存在的AWR快照
? 对RAC 架构同样适用
? 分析结果在数据库的相应字典表中存储，可以通过dbms_advisor包的get_task_report过程来获取已经分析的结果，也可以通过addmrpt.sql脚本对特定的快照进行分析。
Automatic Database difference Report - AWR数据对比报告(ADDR)：
? 对AWR报告的一种补充
? 基于基线的理念，对比比单纯的报告更能够说明问题
? 比基线更灵活，产生报告时随意选择对比基线
? 通过awrddrpt.sql可以获取性能异常时间与正常时间段AWR报告的对比值，能够快速发现性能差异，从而定位问题
============================================================
多情环似乎是一个情种，谁拥有它似乎都会产生感情，从而对许多江湖中的事看的很淡。在Oracle应用中，谁对性能影响最大，不言而喻，是SQL，准确地说是SQL语句的算法，可以说，80%以上的性能问题都可以通过调整SQL来解决或者缓解，拥有调优SQL性能的能力，基本上可以算作一个DBA高手咯。
SQL 调整以前的手段包括：检查系统使用情况；查看等待事件；查看数据库分散读取上的等待事件；通过以下方法识别 SQL（难以操作）；识别具有大量数据库分散读取等待事件的会话并跟踪它们，或者在 OEM 中查看最突出的会话；获得解释计划；检查被访问的对象（大小/基数）；查看 SQL 统计信息和/或与对象统计信息相比较 (v$sql) （难以操作）；识别问题；联系打包应用程序的供应商；为供应商提供测试方案；供应商提供补丁/升级；安装在客户的下一个维护周期中的补丁/升级；
在Oracle 10g以后，我们可以：
通过查看 ADDM 建议；或者根据链接来运行自动 SQL 调整；还可以接受来自 SQL 调整的 SQL 描述文件建议。
SQL Tuning & Access Advisors能够对系统中的SQL语句提供优化指导 ，从多个不同的方向为SQL提供优化建议，建议包括了：统计信息的重新收集，创建/删除索引，创建/删除物化视图，是否需要物化视图日志，SQL语句的书写以及固化执行计划的SQL Profiling；通过存储在Oracle内部的SQL Profiling 能够在不改变SQL代码的基础上强制执行计划。
=====================================================
Oracle很强大的工具，优化SQL的利器，能够强制SQL的执行算法，确保SQL执行按照我们希望的执行计划。钩，用的好伤人，用不好伤己，hints也如此。非高手者，非思路清晰者，且忌乱用，用不好的话，你会很受伤的。。。
一些典型的hints：首选用于测试执行计划；其次可用于在需求确定时，固化执行计划
常用的hints：
? FIRST_ROWS, ALL_ROWS ,RULE
? FULL(tab)
? INDEX( tab index )
? NO_INDEX ( tab index )
? USE_NL(tab)
? USE_MERGE(tab..)
? USE_HASH(tab1 tab2)
? PARALLEL ( table, <degree> [, <instances>] )
===========================================================
没有武器就是有武器，有武器就是没有武器。最后一种武器-拳头，就是对整个体系的全面理解，无形的武器胜于有形的武器，就像太极，没有招数就是最好的招数。
作为一个DBA，或者更高一些，作为一个架构管理员，能够理解整个业务系统，对数据库、存储、网络、系统、应用软件、业务流程都非常清楚，甚至于对使用者的使用习惯都非常清楚，优化就不再是什么高难度了。天地之大皆装于我胸中，万物皆为我之神兵。如果真有那么一天一切都在你的掌握之中，优化也许会比吃饭更容易一些咯
最后，他总结道：优化的工具有千千万，找到适合的最关键；精通一、两个工具，比什么工具都“会”使更有用；工具就是工具，最终优化人来定；工具是可以换的，人“才”是换不来的；优化应该在系统中整体贯穿，需要我们用优化工具的时候似乎已经有点晚。
本文转自 vfast_chenxy 51CTO博客，原文链接：http://blog.51cto.com/chenxy/738258，如需转载请自行联系原作者
