自动性能诊断技术
开篇：润墨网以专业的文秘视角，为您筛选了一篇自动性能诊断技术范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘要:企业数据库在大小和数量上的不断增长使得系统管理的复杂性也随之增加。该文介绍的Oracle 数据库 10g新性能诊断技术和监控技术。可以在不受工作负载影响的情况下,简化管理、提高效率以及降低与系统管理相关的成本,该技术大大简化了 Oracle 数据库的诊断和调整过程。
Approach to Flash Memory in Oracle
XIA Yue-ping
( Nanjing College of Information Technology, Nanjing 210016, China)
Abstract: The increase of enterprise database in dimensions and quantity make the management so complexity. The text talk about new diagnose technology and monitoring technology about ORACLEdatabase 10g. The technology can simplify management and raise efficient. It also can reduce the cost about management. The technology simplifies the production of diagnose and adjustment about database.
Key words: automatic performance diagnostics; automatic workload repository; oracle
Oracle 新性能诊断和监控技术技术内置于数据库服务器中,并通过 Oracle Enterprise Manager (EM) 实现外部化。该技术大大简化了 Oracle 数据库的诊断和调整过程。主要组件包括自动工作负载信息库 (AWR)、自动数据库诊断监控程序 (ADDM) 和 Oracle Enterprise Manager (EM)。所有这些组件均建立在 Oracle 数据库代码中代码规范的基础上,该代码规范生成大量来自 Oracle 数据库的诊断统计信息。为了实现这一新功能,已对 Oracle 服务器(尤其是代码方法部分)进行了许多更改。
1 数据库性能统计
每个新数据库版本都增加了更多的性能统计,用于诊断数据库中的问题。10g 增加了几个新的统计,专门用于提高性能问题自动诊断的精确性。在服务器内部生成一个工具的优点之一是,如果问题难以诊断,则我们可以添加更多的规范来简化它!
1) 等待类
Oracle 数据库 10g 中现在可能拥有 700 多个不同的等待事件。事件数目之所以增多,主要是由于为了确保更精确的问题诊断,许多锁和锁栓已经作为单独的等待事件发生。为了实现对等待事件进行更容易的高级分析,等待事件已经划分为基于解决方案空间的等待类,该空间通常用于解决与等待事件有关的问题。例如, TX 互斥锁通常是一个应用程序级别的问题,而 HW 锁定通常是一个配置问题。
2) 时间模型
尝试调整 Oracle 系统时涉及到许多组件,每个组件都具有单独的统计集。要从整体上检查系统,必须使用某种通用度量来实现跨模块比较,例如,如果将内存从缓冲区缓存移动到共享池,总体性能是否会提高?唯一可行的通用度量是时间。如果通过将 8MB 内存移动到共享池而产生的预期性能改进是 x,通过将 8MB 内存移出缓冲区缓存而产生的预期性能下降为y,则如果 x-y 的结果是正值,则表示净收益。在 10g 中,多数顾问程序都会及时的报告它们的结果。此外,还引入了名为“时间模型统计”的新统计,这些统计显示为新的 V$SYS_TIME_MODEL 和 V$SESS_TIME_MODEL 视图。该规范可以帮助我们识别对数据库操作的量化效果。
3) DB 时间
新统计最重要的部分是“数据库时间”。这是数据库调用花费的总时间。调整 Oracle 系统的目标可以陈述为减少用户对数据库执行操作所花的时间,即减少“DB 时间”。如果减少系统对给定工作负载的“DB 时间”,则可以改进性能。“DB 时间”的减少还可以用作调整投入有效性的度量。
例如,通过其它时间模型统计可以从数量方面了解登录操作以及硬分析和软分析的影响。由于该数据无法直接在本产品的早期版本中使用,因此无法实现对这些操作的影响进行量化分析。
4) 活动会话历史记录 (ASH)
从 Oracle7 开始,对 V$SESSION_WAIT 进行取样可以有效地实时检查系统所发生的事件。V$SESSION_WAIT 视图包含的有关当前等待事件的详细信息可以向下扩展到正在读取的单个块以及会话等待的锁栓和等待锁栓的会话数量。但该详细信息无法轻松地用于历史分析。
在 Oracle 数据库 10g 中,V$ACTIVE_SESSION_HISTORY 视图提供了有关数据库中所发生的事件的取样历史记录(记录在内存中的循环缓冲区中)。由于只捕获处于“活动”状态的会话(即数据库调用中的会话),因此它可以表示一个可管理的数据集、直接与执行的工作关联的大小,而非系统允许的会话数量。当会话等待资源(例如 取样时等待 IO)时,等待的完成导致取样数据被修改,这样 V$ACTIVE SESSION_HISTORY 中的条目将包含等待事件实际完成所需的时间。
使用“活动会话历史记录”使我们能够回溯时间,执行详细的分析,并通常不必重播工作负载以收集其它性能跟踪信息作为性能诊断的一部分。
5) 其它 SQL 统计
引入了新列 SQL_id。这是比散列值“更唯一”的值,并显示为字符串。SQL_id 用于 Oracle 数据库 10g 智能基础架构中的 SQL 语句上的所有操作。 以上描述的最常用的等待类已经添加到 V$SQL 中的 SQL 统计中。PLSQL 和 Java 中花费的时间也被量化。 为了使 SQL 调整顾问程序进行更全面的分析,还捕获了 SQL 语句的示例绑定值。
6) 操作系统统计
在数据库中的计时数据方面遇到的问题之一是,许多 CPU 计时器的粒度比已用计时器低数个数量级。由于许多操作将报告零 CPU 使用率,因此这将导致对 CPU 时间的低估。随着 CPU 速度的提高,这一问题变得更加严重。因内存压力导致的分页和交换活动也可以影响数据库的性能,但这无法通过查看任何可用数据库统计信息得到诊断。新视图 V$OSSTAT 可以捕获数据库中的计算机级信息,这样我们便可以轻松地确定是否存在硬件级资源问题。
2 AWR:性能信息库
长期以来,人们已经认识到维护有关 Oracle 系统操作的信息库的重要性。8i 之后的数据库附带的 Statspack 脚本已经得到广泛使用。10g 中采用了自动工作负载信息库,从而使信息库的维护又上了一个台阶。AWR 自动运行以收集有关 Oracle 系统操作的数据并将捕获的数据存储到数据库中。AWR 设计轻便,能够对其使用的存储空间进行自行管理,这样您最终获得的性能数据信息库将不会大于捕获数据的数据库。在完成默认安装后,AWR 将每 30 分钟捕获一次数据,并将清除超过 7 天的旧数据。可以对数据保存的频率和时间长度进行配置。还可以执行手动快照。
AWR 捕获先前由 Statspack 捕获的所有数据以及以上所述的新数据。这些被捕捉到的数据允许进行系统级和用户级分析,又一次减少了为诊断问题所进行的重复工作负载需求。最优化的执行确保了捕捉到的数据被高效执行,以实现企业运营开支的最小化。这些优化的一个示例就是对 SQL 语句的捕捉。在这些数据库中运行时,我们维持 SQL 语句数据在快照之间的增量。这使我们能够高效地只捕获上个快照后对系统负载具有显著影响的语句(通过不同的维度,如 CPU 和已用时间等),而不必捕获自从它们首次出现在系统中之后所有已执行一个阚值级别以上工作的语句(以前则出现这种情况)。这既提高了 SQL 捕获的性能,另一方面又大幅降低了随着时间不断捕获 SQL 语句的数量。
3 自动数据库诊断监控程序:预防性诊断
以 AWR 中捕获的数据为基础,Oracle 数据库 10g 包含自动数据库诊断监控程序 (ADDM),一个内置于数据库中的整体自我诊断引擎。做一个医学上的类比,使用 ADDM 就像到您的全科医生那里看病一样。它查看整个系统,进行诊断,然后提供处理方法建议,或者可能求助于专家程序,即其它 10g 顾问程序组件,如 SQL 调整顾问程序。由于 ADDM 在每次 AWR 统计值捕获后自动运行,因此您可能将其看作是每 30 分钟进行一次定期排定的性能检查。就像医生无论您属于哪个种族都会为您提供治疗一样,ADDM 将以同等方式自如处理任何类型的数据库,OLTP、数据仓库或这些类型的混合。
ADDM [图 1] 检查 AWR 中所捕捉的数据,前瞻性地分析并确定系统面临的主要问题,同时在多数情况下建议解决方案,并量化预期的利益。ADDM 对系统性能采取整体分析,使用时间作为组件间的通用单位。
ADDM 的目标是识别系统中那些消耗“数据库时间”最多的一些领域。ADDM 再深入分析并查明这些问题的根源所在,而不只是提供故障现象和汇报该问题对整个系统影响。如果提出建议后,它将汇报其预期的收益,同样也是时间方面的收益。时间吞吐量的使用允许对一些问题的影响或建议进行比较。先前的许多问题都是基于价值判断和经验,而不是量化影响来识别的。.拥有较高登录量的系统就是一个很好的示例。单凭经验法则可能会得出这样一个结论:每秒登录的数量超过 10 就是个应该修复的问题并需解决。但许多系统都可以大幅度地运行更高的登录率,而不会明显影响系统的性能。在 AWR 中使用新的时间模型数据,ADDM 能够作出量化汇报,如登录系统时间占耗费于数据库全部时间的 20%。该量化值可以使任何需要修复问题或安排它进行修复的任何人更容易相信,而不只是进行“我认为您进行了次数的登录太多了”这样的陈述。在最高级别,ADDM 使用时间模型和等待模型数据检查时间耗费在数据库中的哪些方面,并下钻自上而下树结构规则集。ADDM 内部使用的分类树基于 Oracle HQ 中的 Oracle 服务器技术性能组和其他性能专家的的性能调整经验。这些分类规则的大多数已经在 Oracle 内部工具中得到使用,Oracle Support 组织成功使用这些内部工具用于处理 Statspack 文件已有一年多。
在这些问题中,某些问题先前可以通过执行 Statspack 报表分析来检测,而其它问题(如识别在 Java 中耗费大量时间的 SQL 语句以及识别过量检查点的原因)则必须通过执行附加诊断工作才能确定;ADDM 不仅限于执行等同于 Statspack 分析的工作。
数据库性能页由三个部分组成,并在单个屏幕上显示主机信息、用户活动和吞吐量。通过此信息,数据库管理员先验证计算机是否有足够的 CPU 和内存资源可用,然后对数据库进行分析。然后,可以通过“活动会话”图形(显示用户对 CPU 的使用程度以及是否有用户正在等待资源而非正在运行 CPU)评估数据库的运行状况。最后,该页面显示了一个吞吐量图形,用于判断吞吐量是否受到计算机资源、CPU 消耗或资源争用的影响。
“活动会话”图形包含大量数据。其中的图表在 Y 轴上显示了由等待类和 CPU 分解的活动会话的平均数。该数字表示数据库上的平均负载。Oracle 实例上包含 200 已连接的并正并发工作的会话,但如果只有10 个会话在某个时间点活动,则图形上的活动会话的数目将为 10。该数据每 15 秒钟刷新一次,以便可以实时对问题进行分析。
4 结论
Oracle 数据库性能诊断是数据库管理员职责的重要部分,从以往来看,它消耗了大量的时间和投入,但在确保回报方面却收效甚微。Oracle 数据库 10g 中的 ADDM、AWR 和 ASH 的预防性自动诊断功能为数据库管理员提供了结果和建议,从而可以将精力投入到将为系统吞吐量带来最大好处的方面。用于支持这些的代码规范还增强了企业管理器支持的实时反应式调整方法。
与传统监控系统相比,该诊断所需的成本(无论是资金方面的成本还是已使用的系统资源方面的成本)低很多。最终,客户(您)将从 Oracle 数据库 10g 提供的各种自我管理创新中获得明显的好处。
参考文献:
[1] 赵伯山.Oracle Database 10g 实用培训教程[M].北京:清华大学出版社,2005.
[2] 马树奇译.OCP:Oracle 10g 新特性学习指南[M].北京:电子工业出版社,2005.
[3] Oracle[EB/OL]..