Oracle 白皮书
2003 年 11月
引言
企业数据库在大小和数量上的不断增长使得系统管理的复杂性也随之增加.Oracle 数据库 10g(以下称 Oracle 数据库 10g)提供了一组集成的自我管理功能,可以在不受工作负载影响的情况下,简化管理,提高效率以及降低与系统管理相关的成本. 本白皮书论述了 Oracle 新性能诊断和监控技术的基础架构和部件,该技术内置于数据库服务器中,并通过 Oracle Enterprise Manager (EM) 实现外部化.该技术大大简化了 Oracle 数据库的诊断和调整过程.本白皮书介绍的主要组件包括自动工作负载信息库 (AWR),自动数据库诊断监控程序 (ADDM) 和 Oracle Enterprise Manager (EM).所有这些组件均建立在Oracle 数据库代码中代码规范的基础上,该代码规范生成大量来自 Oracle数据库的诊断统计信息.

问题概述
数据库性能优化已被人看作是一种集半科学,半艺术和半巫术于一身的技术.人们普遍认为,它是一项复杂而耗时的任务,并需要高额的专家咨询技术.它需要相关人员进行不断的摸索和实践,并且只有少数人才有资格执行它.您必须成为该"核心集团"中的一分子才能在性能优化上取得成功.
调整数据库真的那么难吗 它需要深入了解如何使用 Oracle 中的 200 个参数以及几十个特性吗 是否调整地频率越大越好 对于这些问题,答案肯定是"否".
您每隔多久搜索一次那个神奇的下划线参数,来提高每个 Oracle 数据库的性能 我们有好消息要告诉您.在 Oracle 数据库 10g中,我们将使您梦想成真.您只需在 Oracle 初始化文件中设置 _MAKE_SQL_RUN_FASTER = TRUE,这样便会提高企业中每个数据库的运行速度,并且绝对不会有任何不良影响.这是肯定的.还有,我们是否告诉过您我们可以为您架起一座桥梁,并积极工作来帮助您提高薪水 好吧,还是让我们进入正题吧!性能诊断和调整主要是指遵循一种逻辑方法.幸运的是,这正好是计算机的看家本领!

与精确的问题诊断相关的问题
在更改系统之前,重要的是对所遇到的问题进行精确,及时的诊断.许多数据库管理员 (DBA) 通常会研究故障现象,并立即着手更改系统以修复这些故障现象.凡是曾亲身执行过性能优化工作的人都会建议您:对实际问题进行精确诊断将大大提高成功解决问题的可能性. 但我们发现,DBA 通常将大量的时间和精力花费在修复性能故障现象上,而不是确定烦扰系统的性能问题上.许多情况下,故障现象修复在性能改进方面见效甚少.之所以经常处理故障现象,是因为 DBA 知道如何解决故障现象.他或她曾经修复过该故障现象,并参与这新一轮的故障现象修复.管理员在进行新一轮故障现象修复时相信:上一轮应用的性能修复方法肯定同样适用于此次故障现象修复.这一切使他们认为该故障现象至少已经在首次出现时得到了正确地诊断,不幸的是,情况并非始终这样!
尽管显得多余,但不得不说的是,调整是一个迭代过程,解决一个问题可能导致瓶颈移动(或转移)到系统的另一部分.通常情况下,要诊断性能问题,必须先识别导致问题的工作负载部分,然后在进行更详细诊断后重复此工作负载.我们将此称作工作负载重放.由于以下原因可能无法实现工作负载重播:
1. 识别引起问题的工作负载是项重要的工作.
2. 大量应用程序在不设置生产数据库副本的情况下无法重新运行.
单单这两个问题通常就会使诊断过程增加几周甚至几个月的时间.

Oracle 数据库 10g 诊断优点概述
内置于 Oracle 数据库 10g 中的自动数据库诊断监控程序 (ADDM) 具有以下优点:
1. 每 60 分钟生成一份自动性能诊断报告
2. 问题诊断基于几十年的调整经验
3. 对问题影响进行基于时间的量化并提出建议
4. 识别根本原因,而非故障现象
5. 由于全部数据保存在自动工作负载信息库 (AWR) 中,因此显著降低了重放工作负载进行详细分析的需要.

对 Oracle 性能问题的反应
为了演示 Oracle 数据库 10g 中的新性能功能的有效性,我们将对 Oracle数据库 10g 发布之前解决性能问题所需的步骤进行评估,并将其与 Oracle 数据库 10g 中的方法进行对比.相同的问题方案将产生完全不同的诊断投入.此时您可能已经猜到,10g 中的诊断方法要比先前版本中的诊断方法简单很多.
降低诊断投入将使 DBA 将时间花在如何解决问题上,在我们看来这正是DBA 的用武之地.

Oracle 数据库 10g 之前的版本
1. 在本部分中,我们将研究一个示例,该示例演示了在 Oracle 数据库 10g 之前的版本中诊断性能所涉及的操作:
2. DBA 收到用户(或警报)抱怨系统速度慢的电话.
3. DBA 检查服务器计算机并检查是否有大量资源可用,很显然,速度慢并非因计算机资源耗尽而引起.
4. 然后,(他或她)查看数据库并看到许多会话正在等待"锁栓释放".
5. 通过下钻锁栓,他了解到大多数锁栓释放等待都在"库缓存"和"共享池"锁栓上.
6. 根据以往的经验并参考大量相关书籍,数据库管理员了解到这些锁栓通常与硬分析问题相关.为了进一步核实,他将查看统计"已用分析时间"和"分析时间 cpu"的增长率.还将发现已用时间的增长速度远远超过 CPU 时间的增长速度,因此怀疑得到证实.
7. 此时,数据库管理员采用多种方法识别出现偏差的数据分布.方法之一是查看所有会话的"分析计数(硬)"统计信息,以便了解是否有一个或多个会话负责硬分析的主要部分.另一个方法是检查共享池以确定是否有许多具有 SQL 计划相同,但 SQL 文本不同的语句.在我们的示例中,DBA 将采用第二种方法,并发现有很少数量的计划,其中的每个计划都有许多不同的与之关联的 SQL 文本.
8. 检查其中的几个 SQL 语句后发现,SQL 语句的 WHERE 子句中包含文字字符串,因此必须对每个语句单独进行分析.
9. 由于以往曾遇到过此类情况,因此 DBA 现在可以断定,此问题的根本原因是由于未使用绑定变量而导致的硬分析,可以继续修复此问题.
10. 在执行这些步骤时,DBA 必须凭借他的经验诊断问题的原因,并可能会很有可能在其中的任何步骤中做出错误的决定,从而浪费时间和精力.

Oracle 数据库 10g
采用相同的示例,我们可以会看到在 Oracle 数据库 10g 中存在明显的差异:
1. DBA 收到用户抱怨速度太慢的电话.
2. DBA 检查最新的 ADDM 报告(下面的附录A 提供了完整示例),第一个建议显示:
FINDING 3: 31% impact (7798 seconds)

------------------------------------

SQL statements were not shared due to the usage of

literals. This resulted in additional hard parses which

were consuming significant database time.

RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)

ACTION: Investigate application logic for possible use of

bind variables instead of literals. Alternatively, you may

set the parameter "cursor_sharing" to "force".

RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033

were found to be using literals. Look in V$SQL for examples

of such SQL statements.

DBA 随即了解到数据库中 30% 以上的时间用于分析,并获得如何解决这种情况的建议.注意,该报告还包含一个可疑计划散列值,使数据库管理员能够快速检查几个示例语句.此外,数据库管理员未使用该诊断过程增加系统开销.
该示例着重说明了使用 Oracle 数据库 10g 的自动诊断功能能够节省大量的时间和投入.

智能化的基础架构
诊断 Oracle 系统中问题的能力不是偶然发生的.调整专家需要了解数据库的工作方式以及影响数据库的方法. Oracle 数据库 10g 的自动诊断功能也不是偶然发生的.为了实现这一新功能,已对 Oracle 服务器(尤其是代码方法部分)进行了许多更改.

数据库统计
每个新数据库版本都增加了更多的性能统计,用于诊断数据库中的问题.10g 增加了几个新统计,专门用于提高性能问题自动诊断的精确性.在服务器内部生成一个工具的优点之一是,如果问题难以诊断,则我们可以添加更多的规范来简化它!

等待类
Oracle 数据库 10g 中现在可能拥有 700 多个不同的等待事件.事件数目之所以增多,主要是由于为了确保更精确的问题诊断,许多锁和锁栓已经作为单独的等待事件发生.为了实现对等待事件进行更容易的高级分析,等待事件已经划分为基于解决方案空间的等待类,该空间通常用于解决与等待事件有关的问题.例如, TX 互斥锁通常是一个应用程序级别的问题,而 HW 锁定通常是一个配置问题.下面列出了最经常发生的等待类和一些示例:
1. 应用程序 - 由行级别锁定或显式锁定命令导致的锁定等待

2. 管理 - 导致其他用户等待类似索引重建的数据库管理员命令
3. 提交 - 在提交后等待重做日志写入确认
4. 并发性 - 并行分析和缓冲区缓存锁栓和锁争用
5. 配置 - 过小的日志缓冲区空间,日志文件大小,缓冲区缓存大小,共享池大小,ITL 分配,HW 入队争用,ST 入队争用
6. 用户 I/O - 等待从磁盘读取块
7. 网络通讯 - 等待数据通过网络发送
8. 空闲 - 表示会话处于非活动状态(如 'SQL*Net message from client')的等待事件

时间模型

来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/51862/viewspace-180614/ ，如需转载，请注明出处，否则将追究法律责任。