oracle性能诊断

oracle性能诊断


刀是最大众化的武器,小到刮刀、折刀、剃刀、西瓜刀、切菜刀、剔骨刀,大到柳叶刀、圆月弯刀、武士刀、青龙偃月刀。。。不论大小长短、不论古今中外,刀是最常见的武器。不过再普通的刀,到了高手的手中,也会成为神兵利器,刀如此,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,或者更高一些,作为一个架构管理员,能够理解整个业务系统,对数据库、存储、网络、系统、应用软件、业务流程都非常清楚,甚至于对使用者的使用习惯都非常清楚,优化就不再是什么高难度了。天地之大皆装于我胸中,万物皆为我之神兵。如果真有那么一天一切都在你的掌握之中,优化也许会比吃饭更容易一些咯

    最后,他总结道:优化的工具有千千万,找到适合的最关键;精通一、两个工具,比什么工具都“会”使更有用;工具就是工具,最终优化人来定;工具是可以换的,人“才”是换不来的;优化应该在系统中整体贯穿,需要我们用优化工具的时候似乎已经有点晚。

你可能感兴趣的:(性能,AWR,statspack,addm,v$XXX)