自我管理数据库：自动性能诊断.ppt

1、,Sushil Kumar产品管理主管 数据库可管理性 甲骨文公司,自我管理的数据库： 自动性能诊断,Oracle 数据库 10g 可管理性,可管理性 一个关键的开发关注领域 由 200 多个工程师、主要数据库架构师设计和开发 显著的进步 比 SQL Server 的管理简单 30% 比 DB2 的管理明显要简单得多 比 Oracle9i 的管理简单 50% 比 Oracle8i 的管理简单 70% 好评如潮 分析家给予肯定 客户给予非常肯定,Oracle10g 可管理性解决方案打包,在基本产品中内置了自我管理功能 旨在使核心产品的设置、使用和管理更加简单 单独许可的管理程序包包含非同寻常的功

2、能 使 DBA 的生产力最高 使管理数据库的成本最低 以更低成本提供更高的服务质量 数据库管理程序包 诊断程序包 调整程序包 配置管理程序包 更改管理程序包,Oracle10g 可管理性解决方案打包,在基本产品中内置了自我管理功能 旨在使核心产品的设置、使用和管理更加简单 单独许可的管理程序包包含非同寻常的功能 使 DBA 的生产力最大化 使管理数据库的成本最低 以更低成本提供更高的服务质量 数据库管理程序包 诊断程序包 调整程序包 配置管理程序包 更改管理程序包,数据库程序包许可,与企业版一起提供 包括内置到 Oracle 内核和企业管理器 (EM) 中的功能 程序包可通过下列方式访问 EM

3、 数据库控制 EM 网格控制 数据库 API 利用上述任意接口使用程序包功能时都需要许可,数据库诊断程序包引言,用于管理性能的完整、具有成本效益和易于使用的解决方案 提供了独特的功能 自动识别性能瓶颈 指导的问题解决 全面的系统监视 管理员的时间节省大约 75% 帮助降低 50% 的管理成本,自动性能诊断 自我诊断引擎内置到了核心数据库内核、自动数据库诊断监视器 (ADDM) 自动工作负载捕获和历史性能分析（自动工作负载信息库） 全面的实时系统（数据库和操作系统）性能监视 高级事件管理,数据库诊断程序包主要特性,自动性能诊断 自我诊断引擎内置到了核心数据库内核、自动数据库诊断监视器 (ADDM

4、) 自动工作负载捕获和历史性能分析（自动工作负载信息库） 全面的实时系统（数据库和操作系统）性能监视 高级事件管理,数据库诊断程序包主要特性,传统的性能调整方法,性能和工作负载数据捕获 系统统计、等待信息、SQL 统计等。 分析 数据库在哪些类型的操作上花费时间最长？ 数据库在哪些资源上产生瓶颈？ 什么原因导致了这些瓶颈？ 如何解决这个问题？ 问题解决 如果识别了多个问题，则哪个是最重要的？ 如果实施此解决方案，则我预期可获得多少性能提升？,传统的性能调整方法,性能和工作负载数据捕获 系统统计、等待信息、SQL 统计等。 分析 数据库在哪些类型的操作上花费时间最长？ 数据库在哪些资源上产生瓶颈

5、？ 什么原因导致了这些瓶颈？ 如何解决这个问题？ 问题解决 如果识别了多个问题，则哪个是最重要的？ 如果实施此解决方案，则我预期可获得多少性能提升？,数据库中内置了工作负载和性能统计信息库 Oracle 数据库 10g 智能自我管理基础架构的一部分 自动捕获工作负载数据 默认情况下，每隔 60 分钟保存一次，或者手动保存 7 天的数据 驻留于新引入的 SYSAUX 表空间内 服务器自动管理空间要求 自动清除旧数据 存储不同类别的数据： 基本统计，例如物理读取 SQL 统计，例如磁盘读取（每个 sql 语句） 量度，例如，物理读取数量/秒 活动会话历史,自动负载信息库 (AWR),智能基础架构：

6、新的基本统计 广泛的代码工具,时间模型 (v$sys_time_model) 自动跟踪运行时间 数据库时间 连接管理（登录、登出） 分析（硬、软、失败） SQL、PLSQL 和 Java 执行时间 增强的等待模型 (v$system_event) 等待事件归为代表关键问题领域的等待类别 800 个不同的等待事件，12 个等待类别（应用程序、并发 .） 主要等待事件结束（例如，主要栓锁，入队） 操作系统状态 (v$osstat) CPU + 内存 SQL 语句统计 等待类别、PLSQL、Java 等时间 帮定值取样 (v$sql_bind_capture) 使用内核中的 s，按照维度（CPU、花

7、费时间、分析时间）高效识别 Top SQL,SQL 执行,PLSQL 执行,一般管理,分析,Java 执行,智能基础架构：活动会话历史 (ASH),取样的活动会话历史 (v$session_wait),每秒取一个活动会话样例放入内存 (v$active_session_history) 直接访问内核结构 将选定的样例刷新到 AWR 捕获的数据包括： SID SQL ID 程序、模块、操作 等待事件号 对象、文件、块 实际等待时间（如果是在等待时捕获的）,活动会话历史 (ASH),WAITING,状态,db file sequential read,qa324jffritcf,213,7:38:

8、26,事件,SQL ID,模块,SID,时间,CPU,aferv5desfzs5,Get review id,213,7:42:35,WAITING,log file sync,abngldf95f4de,One click,213,7:52:33,WAITING,buffer busy wait,hk32pekfcbdfr,Add to cart,213,7:50:59,Book by author,活动会话历史 (ASH),细 粒 度 活 动 历 史,自动工作负载信息库优于任何其他数据收集工具,自动、自我管理、效率更高 立即可用的设置 预先计算的量度 例如，事务数量/秒、登录数量/秒等。

9、自我管理的基础 启用历史性能分析 我的用户抱怨昨晚凌晨 3 点钟的性能较差，那时发生了什么情况？ 在过去的某个特定时间，哪些人正使用该系统，他们究竟做了哪些操作？,传统的性能调整方法,性能和工作负载数据捕获 系统统计、等待信息、SQL 统计等。 分析 数据库在哪些类型的操作上花费时间最长？ 数据库在哪些资源上产生瓶颈？ 什么原因导致了这些瓶颈？ 如何解决这个问题？ 问题解决 如果识别了多个问题，则哪个是最重要的？ 如果实施此解决方案，则我预期可获得多少性能提升？,传统的性能调整方法,性能和工作负载数据捕获 系统统计、等待信息、SQL 统计等。 分析 数据库在哪些类型的操作上花费时间最长？ 数据

10、库在哪些资源上产生瓶颈？ 什么原因导致了这些瓶颈？ 如何解决这个问题？ 问题解决 如果识别了多个问题，则哪个是最重要的？ 如果实施此解决方案，则我预期可获得多少性能提升？,自动数据库诊断监视器 (ADDM),数据库中的自我诊断引擎 将所有组件集成在一起 自动提供数据库范围内的性能诊断，包括 RAC 使用时间模型的实时结果 提供影响和优点分析、非问题领域 提供信息与原始数据 立即前摄运行，需要时重新激活运行,SQLAdvisor,高负载 SQL,IO / CPU 问题,RAC 问题,Automatic Diagnostic Engine,自动负载 信息库中的 快照,自我诊断引擎,系统资源建议,网

11、络和数据库 配置建议,使用 AWR 快照进行由上至下的分析 以吞吐量为中心 主要关注缩短“数据库时间” 类别树 基于 Oracle 几十年的性能调整专业技术 实时结果 无需等待几小时的时间才能看到结果 精确查明根本原因 将症状和根本原因分离开来 报告非问题领域 例如，I/O 不是问题,ADDM 运行的方式,最常见的性能问题由 ADDM 自动诊断,不再是尖端科学 Top SQL I/O 问题 经常使用的文件、带宽 分析 硬、软、失败 配置问题 调整日志文件大小 调整日志缓冲区大小 存档 MTTR 设置 应用程序使用情况,无法再用 Statspack 进行诊断 大量的登录/登出 不够大的内存 SG

12、A，PGA 经常使用的块和对象 缓冲区忙碌等待 缓存缓冲区链式栓锁 RAC 服务问题 网络、LMS、远程实例 锁定和 ITL 争用 检测点原因 PL/SQL，Java 时间,性能调整案例研究,诊断和调整硬分析问题,在 Oracle10g 之前，人们必须,检查系统使用情况 查看等待事件 观察栓锁争用 查看共享池和库缓存栓锁上的等待 复查 v$sysstat 查看“已用分析时间” “分析时间 cpu” 以及硬分析多于正常情况的数量 通过下列方法识别 SQL 识别具有很多硬分析的会话，并跟踪这些会话，或者 复查 v$sql 寻找很多带有相同散列计划的语句 检查并复查 SQL 通过观察包含文字的 SQ

13、L 识别“硬分析”问题 启用游标共享,使用 Oracle 10g 和诊断程序包.,由于大多数等待都是并发等待类别，所以系统的 CPU 使用量最大。,ADDM Findings,ADDM 已经自动识别了由于重复硬分析而导致的高 CPU 用量 ,ADDM Findings,并且在解释如何诊断到这个问题的同时推荐解决方案,Good Performance Page,一旦应用了该解决方案，CPU 的用量就会大大降低,同时等待消失,使用 ADDM 之前和之后的情形对比,之前 检查系统使用情况 查看等待事件 观察栓锁争用 查看共享池和库缓存栓锁上的等待 复查 v$sysstat 查看“已用分析时间” “分

14、析时间 cpu” 以及硬分析多于正常情况的数量 通过下列方法识别 SQL 识别具有很多硬分析的会话，并跟踪这些会话，或者 复查 v$sql 寻找很多带有相同散列计划的语句 检查并复查 SQL 通过观察包含文字的 SQL 识别“硬分析”问题 启用游标共享,Oracle10G 复查 ADDM 建议 ADDM 推荐使用 cursor_sharing,情形：硬分析问题,使用 ADDM 之前和之后的情形对比,之前 检查系统使用情况 查看等待事件 观察栓锁争用 查看共享池和库缓存栓锁上的等待 复查 v$sysstat 查看“已用分析时间” “分析时间 cpu” 以及硬分析多于正常情况的数量 通过下列方法识

15、别 SQL 识别具有很多硬分析的会话，并跟踪这些会话，或者 复查 v$sql 寻找很多带有相同散列计划的语句 检查并复查 SQL 通过观察包含文字的 SQL 识别“硬分析”问题 启用游标共享,Oracle10G 复查 ADDM 建议 ADDM 推荐使用 cursor_sharing,情形：硬分析问题,- 听起来不可思议，但是这是真的，根本不需要手动性能诊断 问题解决更快，整体性能更好 减轻了管理员的负担,传统的性能调整方法,性能和工作负载数据捕获 系统统计、等待信息、SQL 统计等。 分析 数据库在哪些类型的操作上花费时间最长？ 数据库在哪些资源上产生瓶颈？ 什么原因导致了这些瓶颈？ 如何解决

16、这个问题？ 问题解决 如果识别了多个问题，则哪个是最重要的？ 如果实施此解决方案，则我预期可获得多少性能提升？,真实的成功案例,Oracle 内部的长回归测试 测试运行了 2 小时 40 分钟 ADDM 建议增加缓冲区缓存 运行时间缩短了 40 分钟 缺陷数据库升级 识别了占用较多数据库时间的语句 使用 SQL Tuning Advisor 调整升级后的较差计划,自动性能诊断 自我诊断引擎内置到了核心数据库内核、自动数据库诊断监视器 (ADDM) 自动工作负载捕获和历史性能分析（自动工作负载信息库） 全面的实时系统（数据库和操作系统）性能监视 高级事件管理,数据库诊断程序包主要特性,全面的系统

17、监视,集成了数据库和操作系统监视 用于所有受支持数据库版本的全面性能监视 性能管理工作流定义良好、直观 详细的等待、会话、SQL 下钻 历史性能数据 事件、量度历史 与新的 Oracle10g 数据源的完整集成 AWR，ASH,数据库主页,主机性能主页,数据库主页,数据库主页,性能主页,性能主页突出显示,等待下钻,等待下钻突出显示,等待下钻,等待下钻,等待下钻突出显示,等待下钻 Top SQL,SQL 详细内容,高级事件通知,种类繁多的通知方法 电子邮件、操作系统命令、PL/SQL 脚本、SNMP 陷阱 服务器生成的警报，使得及时、高效的监视成为可能 灵活的通知规则和计划 使得管理员能够指定希望收到通知的方式和时间 警报管制 在计划维护过程中避免错误警报,“新时代”的性能调整方法,从 EM 性能页面开始 评估问题的性质（短暂还是非短暂） 对于非短暂问题，查看相关的 ADDM 调查结果 对于短暂问题，或者 Oracle10g 之前的数据库 使用 EM 下钻,结论,自动化 Oracle 数据库性能问题的管理 自动问题识别 为诊断程序包所独有 任何