Chinaunix首页 | 论坛 | 博客
  • 博客访问: 17776
  • 博文数量: 6
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 70
  • 用 户 组: 普通用户
  • 注册时间: 2020-07-06 10:35
文章分类

全部博文(6)

文章存档

2020年(6)

我的朋友

分类: Oracle

2020-07-17 17:50:43

这几天在研究AWR报告,参数不仅多,而且不知所云。今天特来整理一下。

首先介绍一下AWR报告,它是是用于系统级别性能诊断和分析的工具是系统级别性能问题的首选工具,提供系统设置和体系结构的整体概况。

AWR涉及的数据可谓非常多,常常让人看得眼花缭乱,不知道哪些是重点。本文主要讲一下AWR的分析方法。
AWR报告分析时采取自顶向下的视角:先专注于主要部分以识别主要问题,然后使用其他部分以获取详细信息。


Oracle有自带的生成awr报告的工具位于$ORACLE_HOME/rdbms/admin下:

Awrrpt.sql:单实例的AWR报告

Awrgrpt.sql: RACAWR报告

Awrrpti.sql:RAC中可以指定节点的AWR报告

Awrddrpt.sql: 单实例的AWR对比报告

Awrgdrpt.sql: RACAWR对比报告

Awrsqrpt.sql: 单个sql的报告


生成AWR报告的注意事项:

1. 对于RAC来说,awrgrpt.sql生成的是rac整体的信息,它是为了对比两个节点而生成的报告,信息比较笼统。如果要看具体的详细信息,可以生成单节点的AWR报告来分析。一般对于RAC,我们生成RACAWR报告+各节点单独的AWR报告

2. awrrpt.sql是单实例的AWR报告,对于RAC来说,可以用这个脚本生成当前节点的报告,如果要生成其他节点的报告,需要分别登录来生成。Awrrpti.sql就解决了这个问题,它可以在生成报告时指定节点。

3. 对于AWR报告来说,它的数据是begin_snapend_snap之间的平均值。因此如果需要分析系统在业务高峰期的性能,最好是生成高峰期每个小时单独的AWR报告。


一般来说,解读AWR报告的步骤顺序

1.报告开头的系统基础信息

2.ADDM的主要发现(好像是12c之后新增)

3.负载概览(Load Profile

4.init.ora参数 (init.ora Parameters )

5.顶级前台等待事件 (Top 10 Foreground Events by Total Wait Time)

6.顶级SQL(SQL Statistics )

7.根据上述步骤里发现的可疑问题,再通过其他部分获取特定的详细信息以进行分析


下面分别介绍:

1.报告开头的系统基础信息

这一部分需要关注数据库的版本,是否是RAC/CDB报告的snap时间范围;同时了解基于coreCPU资源信息,如何将会话数和CPU core结合来检查数据库的连接策略;最后通过DB Time来来获得活动会话的信息。

例如我这个AWR报告是11204 RAC

报告时间是20207.17号的10-11点,这应该是业务高峰期,选取的时间比较合适。

48个逻辑CPU24CPU CoresOracle建议每个Core1-10个会话,也就是说最好有24-240个会话能保证有比较好的性能,这里有700+,比较多了。

Elapsed:快照监控时间,这里取的是1个小时,即60分钟。比较常见的是60分钟,120分钟。

DB Time:不包括Oracle后台进程消耗的时间。即CPU time+ wait time

该例中,DB time576.37分钟,共48个逻辑CPU,平均每个CPU耗时576.37/48=12分钟。

CPU利用率=12/60,约为20%,即CPU空闲。如果超过100%说明出现等待。

对于CPU利用率,也可以直接看下面的Instance CPU

Cursors/Sessions: 这里的beginend值差不多,是正常的。如果该值变大,说明这个期间cursor有泄漏。


2.ADDM的主要发现

对于ADDM部分,我的版本是11204,没有这一部分,需要单独生成addm报告,该报告生成的脚本也在$ORACLE_HOME/rdbms/admin下。参考Oracle 11g:ADDM报告解析


3.负载概览(Load Profile

这一部分,通过DB时间和CPU时间可以对数据库是消耗较多CPU还是在各种等待上有个直观了解。而解析(特别是硬解析)和用户登陆信息logons可以对应用的实现有个初步了解,并提前掌握系统可能存在的问题。

这里首先看DB Time DB CPU

DB time per second是每秒的CPU time(即下面的DB CPU)+ wait time(不包括后台进程消耗的时间),也就是基础信息里面的DB Time/Elapsed(576.37/60).

DB CPUs per second,该示例是9.1个,而共有24core,说明24CPU,每秒钟平均才使用9.1个,说明CPU比较空闲。如果超过了CPU cores,则表示CPU是瓶颈。

也就是说DB time Per Second - DB CPU Per Second,即是每秒的等待时间,如果这个差值比较大,说明系统很忙,CPU等待时间过长,性能需要优化。


Logons:表示每秒/每事务登录的次数。

Har parses(SQL):硬解析。硬解析高说明SQL代码重用率不高。每秒最好低于20

Rollbacks:每秒事务的回滚数。

Transactions:每秒事务数,反映数据库任务繁重与否。参考rollbacks,看出回滚率是不是很高,因为回滚很耗费资源,如果回滚率高,说明数据库有太多无效的操作,需要优化SQL语句。


4.init.ora参数 (init.ora Parameters )


上图中显示了很多开头为下划线的参数(这只是个示例,而不是我真正的报告),注意下划线参数是
oracle隐藏参数,仅在oracle售后建议时临时设置,否则应该使用默认值。因为Oracle每个release版本,所有的测试都是基于默认值。如果擅自修改了默认值,可能会出现意料之外的后果。


对于参数设置,RAC的不同节点的配置要保持一致,否则RAC在不同节点的执行计划会有差异,进而导致其他的问题。

特别要注意以下参数:

?db_block_size

?db_file_multiblock_read_count

?cursor_sharing

?open_cursors

?optimizer_*

?parallel_*

?processes

?sessions

特别注意db_block_size,作为数据库操作的最小单位,oracle的默认值是8192(即8k)。它是在创建数据库的时候指定的,Oracle强烈建议使用默认值,对于部分特殊要求需要大的数据块,可以在表空间级别实现,而不是在数据库级别配置。


5.顶级前台等待事件 (Top 10 Foreground Events by Total Wait Time)

要关注消耗最多DB时间的等待时间(%DB Time),其对应的等待事件(Event)以及平均等待时间(Wait Avg


6.顶级SQL统计资料(SQL Statistics )

这里重点关注SQL ordered by Elapsed Time和SQL ordered by Executions

通过SQL ordered by Elapsed Time,检查最耗时的SQL语句,以及每次执行的平均时间Elapsed Time per Exec以及通过CPU/IO的百分比推断SQL耗时的可能原因,点击SQL ID”查看完整的SQL语句。
譬如在本例中,33m0a3u1xndua这一项 %Total: 35.03,占比超过总DB time的10%,建议优化相关SQL,可大幅度提升数据库性能;
同样的6pfvxmb6b12s5 %Total: 17.3,也同样需要优化。
8vjrcu84stptq per Exec (s): 18.29 平均每次执行时间超过10s,OLTP系统最好控制在10s以内,也需要优化。

对于SQL Ordered by CPU time,占比超过总DB CPU的%10,平均消耗CPU超过5s的都要重点关注。



通过SQL ordered by Executions,检查执行次数最多的语句,频繁执行的SQL的单次执行效率要求非常高,细小的波动都可能对整体性能造成很大影响。

另外要关注一下每次执行处理的行数,对于OLTP应用,正常每条SQL语句只处理少量的行;如果在一个批量处理的负载中看到大量的执行,并且每次执行只处理一行甚至更少,那就预示着使用了逐行数据处理,这是很糟糕的——没法充分利用系统资源。

同样的,也可以点击SQL ID查看完整的SQL语句。


目前维护的系统性能都不错,以后遇到了问题再来补充。

阅读(2166) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~