ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 10G--进一步探讨ADDM(ZT)

10G--进一步探讨ADDM(ZT)

原创 Linux操作系统 作者:vongates 时间:2019-07-18 17:15:02 0 删除 编辑

Oracle 10g中新的诊断引擎帮助检测和诊断性能问题

在上期的专栏中,我重点讲述了Oracle数据库10g为DBA们提供的快速调优方法之一--使用新的SQL Tuning Advisor(SQL调优顾问)快速调优性能不佳的SQL语句--并初步涉及了新的内置诊断引擎"数据库自动诊断监视程序"(Automatic Database Diagnostic Monitor,ADDM),它有助于轻松确定有问题的SQL语句(参见2004年3/4月号的“建议与赞同”一文,以了解更多有关使用SQL Tuning Advisor和DBMS_SQLTUNE软件包的内容)。 鉴别高负载SQL语句只是ADDM众多功能之一。 构建到Oracle数据库10g内核中的自诊断引擎ADDM自动检测和诊断常见的性能问题,包括:

  • 与过度I/O相关的硬件问题
  • CPU瓶颈
  • 连接管理问题
  • 过度解析
  • 并发问题,如争用锁
  • PGA、高速缓冲区和日志缓冲区大小的问题
  • Oracle真正应用集群(Real Application Clusters,RAC)特定的部署问题,如全局缓存区热数据块和热对象以及互连延时问题

让我们来探讨一下ADDM,从而进一步了解Oracle数据库10g的性能调优新功能。


自动、有效的问题诊断

ADDM定期(默认情况下是每小时一次)自动分析数据库的性能,并鉴别所有的性能问题。 ADDM的诊断引擎被设计成为一个分类系统,它能在自动负荷信息库(Automatic Workload Repository,AWR)中快速高效地筛选统计数据,并根据它们对整个数据库性能的影响来估计问题的领域。AWR是一个新引入的Oracle数据库10g内置信息库,用于存储性能统计数据和工作负荷信息。 ADDM的处理逻辑包括最佳实践和整个行业积累起来的调优专业人士的丰富经验。 最后,ADDM给出一系?quot;发现结果",它们不仅给出出现性能问题的原因,而且还能通知管理员某些数据库子组件(如I/O)运行正常,不需要进行任何进一步的调查。

自动化只是ADDM的几个独特优点之一。 另一个重要优点是ADDM能够确定问题的根源。 就像医生通过治本而不是治标来达到医治病人的满意结果一样,DBA们通过找到性能问题的根源然后调整系统,来获得更好的数据库性能。 但是,有时表面现象会掩盖实质问题,这时寻找根源也许会很困难和费时。

ADDM可以辨别问题的原因和表面现象。 它能够做到这一点,部分原因是能通过使用数据库运行时生成的大量新数据(事件、统计数据)来进行分析和判断。 Oracle数据库的内核代码一直都是为提供原始性能数据而设计的,但是在这一版中,该内核设计得能提供更全面的数据。

例如,等待事件(wait event)更加细粒化,并有众多的锁(lock)和闩(latch)现在被分配到不同的等待事件。 此外,现在等待事件按类别分了组--例如应用、管理、提交、并发、网络、用户I/O、系统I/O和配置,例如,以便更便于通过ADDM进行处理。

除了这些新的等待事件模型外,Oracle数据库10g还包括许多新的统计数据,它们提供从操作系统性能(如,硬盘I/O统计数据、CPU使用情况、网络统计数据)到系统和会话级别的累积统计数据方面的所有性能数据。 新的统计数据中最重的数据之一就是数据库工作时间,或称为DB工作时间--数据库真正用于执行数据库调用的时间总和。

关于时间

ADDM使用DB工作时间来度量吞吐量;它是前台进程(如I/O读操作)花费的时间总和,包括等待数据库资源、在CPU上运行、等待CPU空闲。 ADDM的最高目标就是降低整个系统的DB工作时间值,从而提高整体吞吐量。

关于活动会话(使用CPU的会话)和等待CPU的会话的信息每秒钟要采样一次,并保存在服务器内存的滚动缓冲区--活动会话历史(Active Session History,ASH)中,这是Oracle 数据库10g的一个重要新特性。 ASH (V$ACTIVE_SESSION_HISTORY)维护着历史数据;在以前的Oracle数据库版本中,DBA只有当前的活动会话的信息,而没有历史信息,因此事后找出性能问题的原因就不太容易了。

来自ASH的数据以及其他重要的数据库统计数据以"快照"的形式保存在磁盘上。 默认情况下,每小时拍一次快照并保存7天,但DBA可以修改拍快照的频度和保存时间的设置。 AWR提供原始信息供ADDM进行分析,这一过程在拍完新的AWR快照时便自动开始。

ADDM的启动

由于每次拍完一个新的AWR快照之后ADDM便自动运行,因此不需要手工操作步骤来生成发现结果。 但是通过手工创建新的快照,你可以使用Oracle企业管理器(OEM)或命令行界面按需要运行ADDM。 下面显示通过命令行创建快照的过程:

SQL> exec dbms_workload_repository.create_
snapshot();
PL/SQL procedure successfully completed.

新的快照创建完之后,它的信息(snap_id、begin_interval_ time以及类似的信息)被放到DBA_HIST_SNAPSHOT字典视图中。 快照创建后几秒钟时间,ADDM就根据对该快照的分析提供新的发现结果。 这些发现结果在基于Web的OEM新控制台上的数据库主页上可以看到,如图1所示。

Figure 1

图1: Oracle企业管理器数据库主页提供数据库操作的快速概览。

当你在新的OEM控制台中访问数据库实例时,通常会在控制板风格的主页上一眼就看到数据库是如何操作的。 你可以快速检查服务器是否拥有充足的CPU和内存资源,并从该页面上得到系统的综合概览。 活动会话饼图显示在三个关键方面整个服务器的当前状态: 使用CPU、等待I/O以及等待其他资源。 你可以深入到这些项目中去查看一个过去24小时(可以修改这个值,如31天、7天或只是几分钟)的活动(作业)线条图。

最新运行的ADDM结果显示在主页的性能分析部分,如图2所示,它提供了ADDM最新发现结果的摘要视图: 所诊断出的问题的影响占数据库整体性能的百分比,发现结果的描述以及建议摘要。 每个发现结果的文本都超链接到该一发现结果的更详细信息。 ADDM建议包括如果新的顾问工具--SQL Tuning Advisor(调优顾问)、SQL Access Advisor(访问顾问)、Space Management Advisor(空间管理顾问)等等可以应用,则运行其中之一。 例如,某一发现问题的解决方案可能涉及到使用SQL Tuning Advisor来调优具体的SQL语句,或向该机器添加更多的资源。 单击建议链接会显示详细地发现结果视图,它包括各个建议的全部文本。

Figure 2

图2: 显示在OEM数据库主页上的ADDM发现结果摘要

Figure 3

图3: 详细的性能信息提供快速解决问题的推荐解决方案。

你还可以生成一个ADDM报表,它汇总性能数据并提供所有发现结果及建议的清单,如图3所示。你可以通过基于Web的OEM控制台访问ADDM报表,也可以通过使用新的内置DBMS_ADVISOR包从SQL*Plus命令行访问这些报表。 例如,下面给出如何使用命令行根据最新的快照快速创建ADM报表:

set long 1000000
set pagesize 50000
column get_clob format a80
select dbms_advisor.get_task_report(
task_name, 'TEXT', 'ALL') 
as ADDM_report
from dba_advisor_tasks
	where task_id=(
	select max(t.task_id)
	from dba_advisor_tasks t, 			dba_advisor_log l
	  where t.task_id = l.task_id
	  and t.advisor_name='ADDM'
	  and l.status= 'COMPLETED');

参数ALL生成说明报表中某些元素含义的附加信息。

发现结果报告已发现的问题所产生的用DB工作时间百分比表示的影响,该百分比是基于"如果采取所建议的行动,则发现结果所描述的问题将被解决"这样的假设计算出;它会直接影响预期的改进效果的。 例如,下面的一个发现结果确定有一个配置问题,并建议调整参数文件中sga_target的值:

FINDING 3: 5.2% impact (147 seconds)
---------------------------------------
The buffer cache was undersized causing significant additional read I/O.
RECOMMENDATION 1: DB Configuration, 5.2% benefit (147 seconds)
ACTION: Increase SGA target size by increasing the value of parameter "sga_target" by 24 M.
SYMPTOMS THAT LED TO THE FINDING:
Wait class "User I/O" was consuming significant database time. (5.3% impact [150 seconds])
...

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

请登录后发表评论 登录
全部评论

注册时间:2018-09-11

  • 博文量
    449
  • 访问量
    292694