第3章 自动数据库性能监视器
数据库性能监控与调优方法
数据库性能监控与调优方法数据库作为企业信息系统的重要组成部分，承担着数据存储与管理的任务，因此数据库的性能对于企业的正常运行至关重要。
本文将介绍数据库性能监控与调优的方法，旨在帮助企业保障数据库的稳定高效运行。
首先，数据库性能监控是保障数据库正常运行的基础。
具体而言，数据库管理员需要对数据库进行持续监控，并及时发现和解决可能存在的性能问题。
以下是一些常用的数据库性能监控方法：1. 监控关键指标：数据库管理员可以通过监控关键指标来评估和监测数据库的性能。
这些指标包括数据库连接数、查询响应时间、磁盘使用率、CPU利用率等。
通过实时监控这些指标，可以及时发现性能问题，并采取相应措施进行调优。
2. 使用性能监控工具：市场上有许多性能监控工具可供选择，如Oracle的Enterprise Manager、MySQL的Percona Monitoring and Management等。
这些工具能够提供可视化的监控界面，帮助管理员实时了解数据库的运行状态，并提供详细的性能分析和建议。
3. 设置告警机制：在性能监控过程中，管理员可以设置告警机制，当数据库出现性能问题时，及时发送警报，以便能够尽早发现和解决问题。
告警机制可以通过邮件、短信等方式进行通知，确保管理员能够第一时间采取措施。
其次，数据库调优是提升数据库性能的有效方法。
通过对数据库的调优，可以优化查询性能、提高数据库的并发处理能力、减少资源消耗等。
以下是一些常用的数据库调优方法：1. 设计优化的数据库结构：合理的数据库结构设计是数据库性能调优的基础。
数据库管理员需要根据应用需求和数据特点，考虑表的索引、关系模式设计、数据类型等因素，以降低查询复杂度，提高查询效率。
2. 优化查询语句：查询语句的优化对于提升数据库性能非常重要。
管理员可以通过修改查询语句、优化查询条件、使用合适的索引等方式，减少查询的时间和资源消耗。
此外，也可以考虑使用数据库的查询优化器，对查询语句进行自动优化。
性能监视器-PerformanceMonitor
性能监视器-PerformanceMonitor性能监视器是Windows⾃带的系统资源和性能监视⼯具. 性能监视器能够量化地提供CPU使⽤率, 内存分配状况, 异常派发情况, 线程调度频率等信息. 能够提供每秒钟的请求数⽬, 请求响应时间等等. 性能监视器能够监视⼀段时间内上述资源的利⽤情况, 提供平均值和峰值.性能监视器有助于获取关于性能的具体指标, 监视问题出现时系统资源的变化情况. 通过检查性能监视器中⼀些重要计数器的变化情况, 往往能够找到⼀些⽐较有⽤的线索. ⽐如⽐较每秒请求数⽬, 请求响应时间和CPU利⽤率是否有相同的变化曲线就能看出性能是否跟负载相关.解决性能问题的时候, 往往会让客户添加下⾯⼀些计数器进⾏性能收集.Process object下的所有计数器Processor object下的所有计数器System object下的所有计数器Memory object下的所有计数器如果客户的程序时.NET程序, 还会添加以.NET开头的object下的所有计数器.如果客户使⽤, 还会添加以开头的object下的所有计数器.分析性能⽇志的时候, 重点观察下⾯这些计数器.Process object=============Process object中的计数器可以根据⽬标进程分析内存, CPU, 线程数⽬和handle数⽬. 选出问题的⽬标进程, 然后分析⽬标进程的下⾯⼀些计数器.%Processor Time-------------------该计数器是该进程占⽤CPU资源的指标. 即便进程繁忙的时候, CPU平均占⽤率应该在80%以内. 如果超过该数值, 可以认为程序发⽣了⾼CPU的问题. 另外⼀种问题是CPU波动幅度⼤. 虽然平均占⽤率不⾼, 但是上下跳动频繁. 在某⼀个短时间段⾥⾯, 会有连续⾼CPU的情况出现.Handle Count------------------该计数器记录了当前进程使⽤的kernel object handle数量. Kernel object是重要的系统资源. 当程序进⼊稳定运⾏状态的时候, Handle Count 数量也应该维持在⼀个稳定的区间. 如果发现Handle Count在整个程序周期内总体趋势连续向上, 应该考虑程序是否有Handle Leak.ID Process------------------该计数器记录了⽬标进程的进程ID. 你可能觉得奇怪, ID有什么好观察的? 进程ID是⽤来观察程序是否有重启发⽣. ⽐如⼯作进程可能会⾃动回收. 由于进程名都相同, 所以只有通过进程ID来判断是否有重新启动现象. 如果ID有变化, 那么⽽看看程序是否发⽣崩溃或者Recycle.Private Bytes------------------该计数器记录了当前通过VirtualAlloc API进⾏的, Commit了的Memory数量. ⽆论是直接调⽤API申请的内存, Heap Manager申请的内存, 还是CLR的managed heap, 都算在⾥⾯. 跟Handle Count⼀样, 如果在整个程序周期内总体趋势连续向上, 说明有Memory Leak.Virtual Bytes------------------该计数器记录了当前进程申请成功的⽤户态总内存地址, 包括DLL/EXE占⽤的地址和通过VirtualAlloc API进⾏的, Reserve了的内存地址数量,所以该计数器应该总⼤于Private Bytes. ⼀般说来, Virtual Bytes与Private Bytes的变化⼤致⼀致. 由于内存分⽚的存在, Virtual Bytes与Private Bytes⼀般保持⼀个相对稳定的⽐例关系. 当Virtual Bytes与Private Bytes的⽐例⼤于2的时候, 程序往往有⽐较严重的内存地址分⽚. Processor object==============Processor object记录系统中芯⽚的负载情况. 由于普通程序并不可以绑定到某个具体的CPU上执⾏, 所以在多CPU机器上观察Total Instance 也就⾜够了.%Processor Time----------------------该计数器跟Process下的%Processor Time的意义⼀样, 不过这⾥记录的不是针对具体的某⼀个进程, ⽽是整个系统. 通过把该计数器跟Process下的同名计数器⼀起⽐较, 就能看出系统的⾼CPU问题是否是由于单⼀的某个进程导致的.System object==============System object记录系统中⼀个整体的统计信息. 所以不区分instance. 通过⽐较System object下的counter和其他counter的变化趋势, 往往能看出⼀些线索.Context Switch/ sec--------------------Context Switch标⽰了系统中整体线程的调度, 切换频率. 线程切换是开销⽐较⼤的操作. 频繁的线程切换回导致⼤量CPU周期被浪费. 所以当看到⾼CPU的时候, ⼀定要与Context Switch⼀起⽐较. 如果两者有相同的变化趋势, ⾼CPU往往是由于contention(线路争夺)导致的, ⽽不是死循环.Exception Dispatches/ sec-------------------Exception Dispatches表⽰了系统中异常派发, 处理的频繁程度. 跟线程切换⼀样, 异常处理也需要⼤量的CPU开销. 分析⽅法跟Context Swith 雷同.File Data Operations/ sec-------------------File Data Operations记录了当前系统中磁盘⽂件读写的频繁程度. 通过观察该计数器跟其他性能指针的变化趋势, 能够判断磁盘⽂件操作是否是性能瓶颈. 类似的计数器还有Network Interface, Bytes Total/ secMemory Object=============Memory object记录了当前系统中整体内存的统计信息.Avaiable Mbytes 和 Committed Bytes---------------------Available Mbytes记录了当前剩余的物理内存数量. Committed Bytes记录了所有进程commit的内存数量. 结合两个计数器可以观察到:1. 两者相加可以粗略估计系统总体可⽤内存的多少, 便于估计物理配置.2. 当Available Mbytes少于100MB的时候, 说明系统总体内存紧张, 会影响到系统所有进程的性能. 应该考虑增加物理内存或检查内存泄露.3. 通过⽐较Process object中的Private Bytes和Virtual Bytes, 便于进⼀步确认是否有内存泄露, 判断内存泄露是否是由某⼀单个进程导致的.Free System Page Table Entries, Pool Paged Bytes 和 Pool Nonpaged Bytes--------------------这三个计数器可以衡量核⼼态空闲内存的数量. 特别是当使⽤/3GB开关后, 核⼼态内存地址被压缩, 容易导致核⼼态内存不⾜, 继⽽引发⼀些⾮常奇怪的问题..NET CLR Memory object=============.NET CLR Memory object记录了CLR进程中跟CLR相关的内存信息. 该类别下的所有计数器都很有趣, 意思也⾮常直接. 建议⽤⼀个例⼦程序进⾏测试和研究. 下⾯是两个最常⽤的计数器.Bytes in all heaps----------------------Bytes in all heaps 记录了上次GC发⽣时所统计到的, 进程中不能被回收的所有CLR object占⽤的内存空间. 该计数器不是实时的, 每次GC发⽣的时候, 该计数器才更新. 与同⼀进程的Process下的Private Bytes⽐较, 可以区分出managed heap和native memory的变化情况. 对于memory leak, 便于区分是managed heap的leak, 还是native memory 的leak.%Time in GC%Time in GC记录了GC发⽣的频繁程度. ⼀般来说15%以内算⽐较正常. 当超过20%时, 说明GC发⽣过于频繁. 由于GC不仅带来很⾼的CPU 开销, ⽽且还需要挂起⽬标进程的CLR线程, 所以⾼频率GC是⾮常危险的. 通过跟CPU利⽤率和其他性能指标的⽐较, 往往能够看出GC对性能的影响. ⾼频率的GC往往因为:1. 负载过⾼.2. 不合理的架构, 对内存使⽤率不⾼.3. 内存泄露, 内存碎⽚导致内存压⼒.的性能监视============如果⽬标程序时, 在开头的object中, 下⾯这些计数器对于测量的性能⾮常有⽤. 由于不少计数器存在于多个object 类别中, 下⾯只列出具体的计数器名字, ⽽不去对应到具体的object.Application Restarts-------------------Application Restarts记录了 Application Domain重启的次数. 导致 appDomain重启的原因往往是虚拟⽬录被修改. ⽐如修改了web.config⽂件, 或者防毒程序对母你⽬录进⾏了扫描. 通过该计数器可以观察是否有异常的重启现象.Request Execution Time-------------------Request Execution Time记录了请求的执⾏时间, 它是衡量性能的最直接参数. 通过该计数器的平均值来衡量性能是否合乎预期. 需要注意的地⽅是: 由于Windows并⾮实时系统, 所以不能⽤峰值来衡量整体性能. ⽐如当GC发⽣的时候, 请求执⾏时间肯定要超过GC的时间.所以, 平均值才是有效的标准.Request Current-------------------Request Current记录了当前正在处理的和等待处理的请求. 最理想的情况是Request Current等于CPU的数量, 这说明请求与硬件资源能并发处理的能⼒恰好吻合, 硬件投资正运⾏在最优状态. 但是⼀般说来, 当负荷⽐较⼤的时候, Request Current也随着增⾼. 如果Request Current在⼀段时间内有超过10的情况, 说明性能有问题. 注意观察此时对应的CPU情况和其他的资源. 如果CPU不⾼, 很可能是是程序中有Blocking发⽣, ⽐如等待数据库请求, 导致请求⽆法及时完成.Request/ second------------------Request/ second计数器记录了每秒钟到达的请求数. 这是衡量负载的直接参数. 注意观察Request/ second是否超过程序预期的吞吐量. 如果Request/ second 有突发的波动, 注意看是否有拒绝服务攻击. 通过把Request/second, Request Current, Request Execution Time和系统资源⼀起⽐较, 往往能够看出整体性能的变化和各个因素之间的影响.Request in Application Queue------------------当没有空余的⼯作线程来处理新进⼊的请求的时候, 新的请求会被放到Application Queue中. 当Application Queue堆积的请求也超过设定数值的时候, 直接返回503 Server Too Busy错误, 同时丢弃该请求. 所以正常情况下, Request Application Queue应该总为0,否则说明已经有请求堆积, 性能问题严重.摘⾃<Windows⽤户态程序⾼效排错>。
数据库监控与性能分析工具推荐
数据库监控与性能分析工具推荐目前，随着数据库技术的发展，数据库监控和性能分析工具也得到了越来越广泛的应用。
在众多的数据库监控和性能分析工具中，本文为大家推荐一些性能优良、功能全面的数据库监控和性能分析工具。
1. SolarWinds Database Performance Analyzer（DPA）这是一款专门为云端、物理和虚拟化的环境设计的数据库性能监控和分析工具。
DPA可以对多个数据库实例的性能、等待事件和存储性能进行实时监控和分析。
此外，它还提供了一个自适应基准库，在运行足够的跟踪之后，可以自动为你选择合适的基准值。
DPA还有一个非常强大的功能 - 对于具有低性能的SQL语句自动创建索引，这可以大幅提升整体性能。
2. Paessler PRTG Network MonitorPRTG Network Monitor可以监控网络系统和应用程序的可用性，并提供丰富的自定义报告。
它支持多种设备，包括Microsoft SQL、MySQL和Oracle数据库。
PRTG可以监控数据库的性能指标，如响应时间、查询次数和传输速率。
此外，还可以使用PRTG进行自定义警报和通知，以便快速解决潜在的问题。
3. Idera SQL Diagnostic ManagerSQL Diagnostic Manager是一款监控SQL Server性能的全面解决方案，提供实时性能、存储和服务器监控。
它可以自动诊断性能问题，并提供实时警报和建议来改善性能。
SQL Diagnostic Manager还提供了许多内置报告和仪表板，以及用户可以创建自定义报告和仪表板的选项。
4. dbForge Studio for SQL ServerdbForge Studio是一款功能强大的集成开发环境（IDE），专门为SQL Server设计。
它提供了一个广泛的工具箱，以实现SQL Server的性能监控和分析，包括查询性能分析、查询优化器、语法检查、单元测试等功能。
MySQL数据库性能监控与优化的工具推荐
MySQL数据库性能监控与优化的工具推荐近年来，随着互联网的快速发展和信息技术的不断创新，各类网站和应用程序的数据库需求越来越大。
而数据库作为应用系统中最关键的组成部分之一，其性能直接关系到整个系统的运行效率和用户体验。
为了及时发现和解决数据库性能问题，提高系统的稳定性和性能，数据库性能监控与优化工具应运而生。
本文将介绍几种常用的MySQL数据库性能监控与优化工具，为用户提供参考。
一、MySQL性能监控工具1. MySQL Enterprise MonitorMySQL Enterprise Monitor是由MySQL AB开发的一款强大的性能监控工具。
该工具提供了丰富的监控指标和图表，可以实时监测MySQL服务器的性能参数，包括CPU利用率、内存使用、磁盘IO、查询响应时间等。
同时，它还支持报警功能，可以在数据库性能出现异常时发送警报通知管理员及时处理。
2. Percona Monitoring and Management (PMM)PMM是由Percona开发的一套开源的MySQL性能监控工具。
它基于Prometheus和Grafana构建，提供了丰富的监控指标和仪表盘展示，用户可以通过图表直观地了解数据库的性能状况。
PMM还提供了Query Analytics功能，可以对SQL查询进行分析，帮助用户优化查询性能。
3. Navicat MonitorNavicat Monitor是一款功能强大的MySQL性能监控工具，为用户提供实时的性能监控和优化建议。
它可以监测MySQL服务器的关键指标，如查询执行时间、连接数、线程状态等，并生成相应的报表和图表展示。
此外，Navicat Monitor还支持远程监控，用户可以通过网络访问监控数据，方便远程管理。
二、MySQL性能优化工具1. MySQLTunerMySQLTuner是一款Perl脚本工具，用于分析MySQL服务器的配置和性能瓶颈，并给出相应的优化建议。
性能监视器的使用
性能监视器【实验目的】1)1)性能监视器的运用。
2)3)理解网络层次结构中各层数据的包装关系。
3)4)捕捉ping命令相关协议的数据包，并分析结构。
【实验环境】具备IIS的Windows 2003 Server计算机、局域网、Windows 20003Server安装光盘。
【实验重点及难点】重点：掌握网络监视器使用方法，深刻体会网络层次结构中各层数据的包装关系，学会分析常用数据包的结构。
【实验内容】一、监视事件IIS中的网站是靠IIS服务来实现的，例如Web站点依赖于WWW服务，故服务启动失败这样的事件往往暗示着站点不能正常工作的原因。
此外，象TCP/IP错误，网络硬件设备错误这样的事件往往也是导致服务器不能正常工作的罪魁祸首。
当系统提示出错或者IIS 出现某种异常情况时，有经验的管理员通常先检查事件查看器所记录的事件。
单击【开始】、【程序】、【管理工具】、【事件查看器】打开如右图所示的事件查看器。
全部事件分别保存在三个事件日志中：应用程序日志、安全日志和系统日志，其包含的事件种类如下：对于IIS服务器而言，系统日志中记录的事件显得更加重要。
如图，在事件查看器控制树中选择系统日志，则右侧窗格列出已经被记录的全部事件，事件分为：错误、警告、信息等不同类型。
事件列表中仅显示有关事件发生的时间、来源、分类和用户等有限信息，为了详细查看某一事件的描述或信息代码，应双击列表中的事件，查阅事件属性对话框。
如右图所示，在事件属性对话框中详细描述事件发生的情况和可能的原因，典型的事件还给出了数据代码供程序员调试使用。
单击事件属性对话框中的上下箭头可以继续查看上一个或下一个事件的详细信息。
二、性能监视器通过日志文件的方式对服务器进行长期监视，得到系统对象的平均特性。
利用日志文件进行及监视的方法如下：1、在性能监视器中展开【系统日志和警报】节点，右击【计数器日志】，选择【新建日志设置】。
2、在【新建日志设置】对话框中输入新日志名称，单击【确定】。
如何打开计算机上的性能监视器
如何打开计算机上的性能监视器计算机的性能监视器是一项非常有用的功能，可以帮助我们了解计算机的运行情况，包括CPU、内存、磁盘、网络等方面的信息。
在日常使用计算机的过程中，经常会遇到计算机运行缓慢的情况，通过性能监视器可以快速定位问题并进行相应的调整。
本文将介绍如何打开计算机上的性能监视器。
一、通过快捷键打开性能监视器方法一：按下键盘上的Ctrl+Shift+Esc快捷键，可以直接打开任务管理器；方法二：按下Ctrl+Alt+Del键，进入蓝色的选项页面，选择“任务管理器”，即可打开任务管理器。
二、通过“开始”菜单打开性能监视器步骤一：点击计算机桌面左下角的“开始”按钮；步骤二：在弹出的菜单中选择“Windows 系统”文件夹；步骤三：在“Windows 系统”文件夹中，可以看到“性能监视器”选项，点击即可打开性能监视器。
三、通过运行窗口打开性能监视器步骤一：按下键盘上的Win+R组合键，打开运行窗口；步骤二：在运行窗口中输入“perfmon.msc”，然后点击“确定”按钮；步骤三：即可打开性能监视器。
四、通过控制面板打开性能监视器步骤一：点击计算机桌面左下角的“开始”按钮；步骤二：在弹出的菜单中选择“控制面板”；步骤三：在控制面板中，可以按照不同版本的Windows操作系统，选择不同的选项路径，如“系统和安全”、“系统和维护”等；步骤四：在相应的选项中，找到“管理工具”选项，点击进入；步骤五：可以看到“性能监视器”的选项，点击即可打开性能监视器。
通过以上四种方法，您可以轻松地打开计算机上的性能监视器，随时了解计算机的运行情况。
性能监视器除了提供实时的性能数据外，还可以查看历史记录、创建报表等功能，帮助用户更好地管理和优化计算机的性能。
在实际使用过程中，我们可以根据自己的需求设置不同的监视器参数，比如监视特定的进程、查看某个硬件设备的使用情况等。
通过观察性能监视器的数据，我们可以找到造成计算机性能下降的原因，及时进行相应的优化操作，提升计算机运行的效率。
数据库性能监控工具的性能指标定义与告警策略配置
数据库性能监控工具的性能指标定义与告警策略配置随着现代软件系统复杂性的增加和用户对系统性能的要求不断提高，数据库性能监控工具的重要性也日益凸显。
数据库是许多应用程序的核心，其性能直接影响整个应用系统的运行效果。
因此，准确地定义数据库性能指标，并配置适当的告警策略非常重要，以及时发现并解决性能问题，保证系统的安全性以及高可用性。
1.性能指标的定义性能指标是用于衡量数据库系统性能的重要工具。
定义合适的性能指标有助于监测和评估数据库的运行状况，从而及时发现潜在的性能问题。
主要的性能指标如下：1.1. 响应时间：衡量数据库对于用户提交的请求所需的时间。
这是用户体验的关键指标，反映了数据库系统对查询、插入和更新请求的处理能力。
1.2. 吞吐量(Throughput)：表示数据库系统在单位时间内能够处理的事务数量。
较高的吞吐量意味着系统处理能力较强，用户请求得到及时响应。
1.3. 并发性：指数据库系统能够同时处理的事务数量。
并发性高表示数据库系统能同时处理多个逻辑上相互独立的事务，提高系统的运行效率。
1.4. 缓存使用率：用于衡量数据库系统内存缓存效果。
高的缓存使用率可以减少磁盘IO操作，提高访问性能。
1.5. 磁盘空间利用率：表示数据库占用的磁盘空间与总可用磁盘空间之间的比例。
合理利用磁盘空间可以提高数据库系统的存储效率。
1.6. 锁争用：用于衡量数据库锁资源的争用程度。
高的锁争用意味着并发事务之间需要等待锁资源的释放，降低了系统的性能。
2. 告警策略的配置为了及时发现和解决数据库性能问题，配置适当的告警策略是必要的。
告警策略的配置应基于数据库的性能指标，并且具有一定的灵活性以应对特定情况。
以下是一些常用的告警策略配置需求：2.1. 设置阈值：根据数据库的性能指标，设置相应的阈值，当指标超过阈值时触发告警。
例如，可以设置响应时间阈值为200毫秒，当响应时间超过该阈值时触发告警。
2.2. 配置告警通知方式：根据实际情况选择适当的告警通知方式，包括邮件、短信、应用程序通知等。
MySQL技术中的数据追踪和性能分析工具介绍
MySQL技术中的数据追踪和性能分析工具介绍引言：MySQL作为一种广泛使用的开源数据库管理系统，被广泛应用于各种规模和类型的应用程序中。
在开发和管理MySQL数据库时，数据追踪和性能分析工具起着至关重要的作用。
本文将介绍一些常用的MySQL数据追踪和性能分析工具，帮助读者更好地掌握MySQL技术。
一、数据追踪工具1. General Query LogMySQL的General Query Log是一项常用的数据追踪工具，可以记录所有与数据库交互的查询语句，包括用户、时间戳和查询内容等信息。
通过开启General Query Log，开发人员可以轻松地追踪和分析数据库的查询活动，以便于排查问题或进行性能调优。
2. Slow Query LogSlow Query Log是一种MySQL提供的重要数据追踪工具，可以记录执行时间超过设定阈值的查询语句。
开启Slow Query Log可以帮助开发人员发现性能瓶颈和潜在问题，并进行相应的优化操作。
通过分析Slow Query Log，我们可以找出哪些查询需要被优化，以提高数据库的性能。
3. Performance SchemaPerformance Schema是MySQL 5.5版本及以上的一个特性，它提供了一种更加灵活和全面的数据追踪工具。
通过Performance Schema，我们可以了解到更多底层MySQL服务器的性能指标和统计信息，如线程、锁、IO、内存、查询计划等。
借助Performance Schema，我们可以更加深入地了解数据库的运行状态，并对其进行优化和监控。
二、性能分析工具1. EXPLAINEXPLAIN是MySQL的一种重要的性能分析工具，它可以用来分析查询语句的执行计划。
通过EXPLAIN，我们可以了解MySQL是如何执行查询语句的，包括表的访问顺序、索引的使用情况、是否使用临时表等。
通过分析EXPLAIN的结果，我们可以找到查询语句的优化方向，从而提高查询的效率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第3章自动数据库性能监视器
自动数据库性能监视器（ADDM）自动检查和报告数据库的性能问题。
结果作为ADDM调查报告显示在Oracle企业管理器的数据库主页中，审查ADDM调查结果让你可以快速找出性能问题。
每个ADDM调查结果都提供了一串有关减少性能问题影响的建议，审查ADDM调查结果并执行建议是你每天正常维护数据库应该要做的事情，即使数据库处于未最佳的性能状态，你也应该继续使用ADDM监视数据库性能。
3.1 自动数据库诊断监视器概述
ADDM是构建在Oracle数据库内部的自我诊断软件，ADDM检查并分析自动工作量仓库（AWR）捕获到的数据，确定Oracle数据库可能存在的性能问题，然后它定位性能问题的根本原因，为纠正这些性能问题提供建议，并量化预计的性能收益，ADDM也可以识别不需要行动的区域。
3.1.1 ADDM分析
每次AWR快照（默认每小时一次）后就会执行ADDM分析，分析报告保存在数据库中，你可以通过Oracle企业管理器来查看这些报告，在使用本指南描述的另一个性能调整方法之前，先审查一下ADDM分析报告。
ADDM分析是从上到下执行的，首先确定症状，然后完善分析报告，指出导致性能问题的根本原因，ADDM使用DB time统计信息确定性能问题，DB time是数据库除了用户请求花去的递增式时间，包括等待时间和所有非空闲会话的CPU时间。
数据库性能调整的目标是减少给定工作量的DB time，通过减少DB time，数据库使用相同数量的资源可以支持更多用户请求，ADDM报告使用了大量DB time的系统资源，将其显示在问题区域，并按消耗的DB time数量进行倒序排序，关于DB time统计信息的更多信息请参考"时间模型统计"小节的内容。
3.1.2 ADDM建议
除了诊断性能问题外，ADDM还会给出建议解决方案，并且有时会建议多个可选的解决方案让你选择，ADDM建议包括：
硬件改造
添加CPU或修改I/O子系统配置
数据库配置
修改初始化参数配置
方案修改
对表或索引进行哈希分区，或使用自动段空间管理（ASSM）
修改应用程序
为序列使用缓存选项或使用绑定变量
使用其它顾问
在高负载SQL语句上运行SQL调整顾问或在热点对象上运行分段顾问。
ADDM应用在生产系统上受益良多，即使在开发和测试系统上，ADDM也可以提前提供潜在的性能问题警报。
性能调整是一个反复的过程，修复一个问题可能会导致瓶颈转移到系统的其它部分，即使使用ADDM分析报告，也要经过多次反复的调整才能使性能达到理想的水平。
3.1.3 Oracle真正应用集群中的ADDM
在Oracle真正引用集群（Oracle RAC）环境中，你可以使用ADDM分析整个数据库集群的性能，Oracle RAC中的ADDM会认为DB time是所有数据库实例数据库时间的总和，它只会报告集群级别的重要分析结果，例如，考虑局部各个集群节点的I/O水平就没什么意义，但所有节点的I/O水平的总和对于判定集群问题就显得很重要了。
3.2 配置自动数据库诊断监视器
3.2.1 设置初始化参数启用ADDM
默认情况下自动数据库诊断监视功能是被启用的，由初始化参数CONTROL_MANAGEMENT_PACK_ACCESS和STATISTICS_LEVEL控制。
CONTROL_MANAGEMENT_PACK_ACCESS初始化参数应该被设置为DIAGNOSTIC+TUNING（默认）或DIAGNOSTIC以确保启用自动数据库诊断监视器，如果将CONTROL_MANAGEMENT_PACK_ACCESS设置为NONE，就会禁用掉许多Oracle数据库特性，包括ADDM，强烈建议不要这么做。
STATISTICS_LEVEL初始化参数应该被设置为TYPICAL（默认）或ALL以确保启用自动数据库诊断监视器，如果将STATISTICS_LEVEL 设置为BASIC将会禁用掉许多Oracle数据库特性，包括ADDM，强烈建议也不要这么做。
确定ADDM是否启用的步骤：
1.在数据库主页，点击"服务器"，显示"服务器"子页面。
2.在数据库配置小节，点击"初始化参数"，显示"初始化参数"页面。
3.在"名称"字段处，输入STATISTICS_LEVEL，然后点击"开始"按钮，会显示一个初始化参数设置的表格。
4.完成下面两件事情：
如果"值"列显示"ALL"或"TYPICAL"，那什么都不做。
如果"值"列显示"BASIC"，就选择"ALL"或"TYPICAL"，然后点击"应用"按钮。
5.在"名称"字段处，输入CONTROL_MANAGEMENT_PACK_ACCESS，然后点击"开始"按钮，会显示一个初始化参数设置的表格。
6.完成下面两件事情：
如果"值"列显示"DIAGNOSTIC"或"DIAGNOSTIC+TUNING"，那什么都不用做。
如果"值"列显示"NONE"，就选择"DIAGNOSTIC"或"DIAGNOSTIC+TUNING"，然后点击"应用"按钮。
3.2.2 设置DBIO_EXPECTED参数
ADDM分析报告中的I/O性能某种程度上依赖于一个参数：DBIO_EXPECTED。
它描述了I/O子系统期望的性能，DBIO_EXPECTED的值是读取一个数据库块的平均时间，单位是微妙（一百万分之一秒），Oracle数据库默认值使用10微妙，对于大部分硬盘驱动器这是一个合适的数值，如果你的硬件非常特殊，可以考虑使用一个不同的值。
确定DBIO_EXPECTED初始化参数是否正确设置的步骤如下：
1.测量在你的硬件上读取一个数据库块的平均时间
这个测量必须采取随机I/O方式，如果你使用的是标准硬盘驱动器，包括寻道时间，大部分硬盘驱动器的测量值都在5000到20000微妙之间。
2.为后面的ADDM分析设置一次性值
例如，如果测量值是8000微妙，那就以SYS用户登陆，然后执行下面的PL/SQL代码：
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER('ADDM', 'DBIO_EXPECTED', 8000);
3.2.3 AWR快照
默认情况下，自动工作量仓库（AWR）每小时会产生一个性能数据的快照，统计信息会在工作量仓库中保留8天，你可以修改产生快照的间隔时间，也可以修改统计信息的保留时间。
Oracle建议你调整AWR保留时间到至少1个月，你也可以扩展到一个业务周期，便于你对比，如一个会计季度，你也可以创建一个AWR
基线保留快照识别重要的时间期限。
位于快照间隔之间的数据由ADDM进行分析，ADDM比较快照之间的差异确定捕获了哪个SQL语句，久而久之，ADDM分析报告显示捕获到的大量SQL语句。
3.2.3.1 创建快照
通常不需要手动创建快照，因为AWR默认每小时都会产生一个性能数据的快照，但在某些情况下，需要手动创建快照以捕获活动持续期间的差异，如当你想比较比快照间隔时间短的时间范围的性能数据。
创建快照的步骤如下：
1.在数据库主页，点击"性能"，显示"性能"页面。
2.在"附加监视链接"下，点击"快照"，显示"快照"页面，列出了大部分最近的快照。
3.点击"创建"按钮，显示"确认"页面。
4.点击"确定"按钮，显示"正在处理：显示创建快照页面"，当快照创建完毕后，"快照"页面显示一条确认消息。
在这个例子中，快照ID是249。
执行ADDM建议的步骤：
1.在数据库主页的诊断摘要下，点击ADDM调查结果后的连接，显示自动数据库诊断监视器（ADDM）页面。
2.在ADDM性能分析部分，点击影响最严重的ADDM调查结果。
在这个例子中，最严重的调查结果是消耗数据库时间最多的SQL（Top SQL by DB Time），显示性能调查结果详细页面。
5.为了显示调查结果的历史记录，点击调查结果历史（Finding History），显示调查结果历史页面。
在这个例子中，显示了从前一个快照（快照161）到所选择的快照（快照162）收集的统计信息。
4.如果想查看统计信息的工作量仓库报告，点击报告（Report），显示工作量仓库报告页面。
5.例外，点击保存到文件可以将报告保存下列，以便以后访问。