[转帖]十步解析awr报告

十步,解析,awr,报告 · 浏览次数 : 0

小编点评

**数据库细节** * 数据库版本:可以从“DB ID”中查询 * 数据库实例名称:可以从“DBID”中查询 * 数据库最近一次启动时间:可以从“最近一次启动时间”字段中查询 * 数据库版本:可以从“数据库版本”字段中查询 * 数据库是否为 rac2:可以从“数据库类型”字段中查询 **主机配置信息** * 数据库主机名:可以从“主机名”字段中查询 * 数据库主机平台:可以从“主机平台”字段中查询 * 服务器CPU及核数:可以从“CPU”和“核数”字段中查询 * 服务器内存大小:可以从“服务器内存大小”字段中查询 **SnapShot信息** * awr报告的起止时间:可以从“start_time”字段中查询 * session数量:可以从“session_count”字段中查询 **Shared Pool Statistics** * Shared pool 状态:% SQL with executions>1指的是执行次数大于1的SQL比例,越大越好 * 执行次数:可以从“执行次数”字段中查询 **Load Profile** * DB CPU(s) per second:每秒钟同时工作的CPU数量 * HARD 解析率:硬解析率 * 性能问题:需要查看cursor_sharing参数和应用程序的绑定变量问题 **Instance Efficiency Percentages** * % Non-Parse CPU:数据的CPU资源有94.9%用在非解析上 * % Parse CPU:数据的CPU资源有94.9%用在解析上 **Top 10 Foreground Events by Total Wait Time** * wait class:等待类 * wait avg:平均等待时间 * waits:等待次数 **Time Model Statistics** * 各过程所占的资源比例 * % of DB Time:数据库CPU占用率 * DB CPU相关进程:需要关注一些异常的高占用情况 **SQL Statistics** * SQL语句持续时间:按执行次数排序的SQL语句 * 执行次数:语句的执行次数 * elapsed time:语句的执行时间 **Operating System Statistics** * %iowait:CPU在等待io操作完成的比例 * 其他:其他等待比例

正文

http://www.zhaibibei.cn/awr/1.1/

 

从这期开始讲解awr报告的部分,首先讲解awr整体的部分

后续会针对不同的点进行讲解

1. 数据库细节

Alt text

这部分可以看到

  • 数据库的版本
  • 数据库 DBID
  • 数据库实例名称及实例号
  • 数据库最近一次启动时间
  • 数据库版本
  • 数据库是否为rac

2. 主机配置信息

Alt text

这部分可以看到

  • 数据库主机名
  • 数据库主机平台
  • 服务器CPU及核数
  • 服务器CPU个数
  • 服务器内存大小

3. SnapShot信息

Alt text

这部分可以看到

  • awr报告的起止时间以及当时的session数量等
  • awr报告持续时间
  • DB 时间

DB Time= session time spent in database.

DB Time= CPU Time + Non IDLE wait time.

可以看到DB Time比 Elapsed大,如果大很多并且有性能问题,需再进一步分析,后面章节再说

4. Shared Pool Statistics

该视图显示的是Shared pool的状态

Alt text

% SQL with executions>1指的是执行次数大于1的SQL比例,越大越好,如过小则可能是为使用绑定变量导致

5. Load Profile

这里我们可以了解系统负载的情况

Alt text

首先是 DB CPU(s) per second,它说明的是每秒钟同时工作的CPU数量

从主机配置可以看到共24个虚拟cpu,而DB CPU(s) per second只有0.4 则说明cpu没有瓶颈

其次我们关注hard parses和 parses的比例,如硬解析率非常高则需要查看cursor_sharing参数和应用程序的绑定变量问题,一般都是由于绑定变量引起的

6. Instance Efficiency Percentages

Alt text

上面的百分比越高越好,后面会针对每个做介绍

“% Non-Parse CPU” 指的是数据的CPU资源有94.9%用在非解析上,这样是好的

7. Top 10 Foreground Events by Total Wait Time

这里是排名前十的前台等待事件

Alt text

  1. 首先看wait class栏位,如果是 User I/O , System I/O, Others这种的可以不用太担心,如发现Concurrency这类等待需要特别关心

  2. 其次看等待时间,wait avg=total wait time(总等待时间)/waits(等待次数),最主要看平均等待时间是否正常

后面章节会详细说明每个等待时间

8. Time Model Statistics

该视图说明的是各过程所占的资源比例

Alt text

我们注意到所有 % of DB Time总和大于100%,因为这是一个累计的比例,下面DB CPU相关的过程包含在DB CPU中

我们需要注意的是一些异常的高占用情况,如hard parse elapsed time (硬解析时间)占用时间过长等

9. Operating System Statistics

该视图是操作系统层面的性能指标

Alt text

这里需要注意%iowait,他代表CPU在等待io操作完成,这个可能是io过慢或者io操作过多导致。

10. SQL Statistics

Alt text

接下来是最重要的一块,他能帮助我们定位占用相关资源的TOP SQL语句

SQL ordered by Elapsed Time

Alt text

上图为根据持续时间排序的SQL语句

所有栏位可根据字面上意思得出意义

  • 如executions过多可能会引起CPU占用率高
  • 如executions低,而elapsed time很高,则需要优化该SQL,降低执行时间

需要注意的是execution如果为0不代表未执行,代表在awr报告的持续范围内该语句未执行完成

这里只举持续时间这个例子,其他后面章节详细说明

通过上面的十点应该会对数据库的性能及负载有了大体的了解,接下来会针对内部细节做解释,谢谢。

与[转帖]十步解析awr报告相似的内容:

[转帖]十步解析awr报告

http://www.zhaibibei.cn/awr/1.1/ 从这期开始讲解awr报告的部分,首先讲解awr整体的部分 后续会针对不同的点进行讲解 1. 数据库细节 这部分可以看到 数据库的版本 数据库 DBID 数据库实例名称及实例号 数据库最近一次启动时间 数据库版本 数据库是否为rac 2

[转帖]《Linux性能优化实战》笔记(十九)—— DNS 解析原理与故障案例分析

一、 域名与 DNS 解析 域名主要是为了方便让人记住,而 IP 地址是机器间的通信的真正机制。以 time.geekbang.org 为例,最后面的 org 是顶级域名,中间的 geekbang 是二级域名,而最左边的 time 则是三级域名。点(.)是所有域名的根,所有域名都以点作为后缀。 把域

[转帖]网络基本功(十六):细说网络性能监测与实例(下)

https://zhuanlan.zhihu.com/p/37898572 转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese 介绍 网络问题中,性能问题是最复杂的问题之一,解决这样的问题能够透彻的了解整个网络的结构。但通过合适的吞吐

[转帖]Redis系列(十五)、Redis6新特性之集群代理(Cluster Proxy)

在之前的文章中介绍了Redis6的集群搭建和原理,我们可以使用dummy和smart客户端连接集群,本篇介绍Redis6新增的一个功能:集群代理。客户端不需要知道集群中的具体节点个数和主从身份,可以直接通过代理访问集群,对于客户端来说通过集群代理访问的集群就和单机的Redis一样,因此也能解决很多集

[转帖]Redis系列(十五)、Redis6新特性之集群代理(Cluster Proxy)

在之前的文章中介绍了Redis6的集群搭建和原理,我们可以使用dummy和smart客户端连接集群,本篇介绍Redis6新增的一个功能:集群代理。客户端不需要知道集群中的具体节点个数和主从身份,可以直接通过代理访问集群,对于客户端来说通过集群代理访问的集群就和单机的Redis一样,因此也能解决很多集

[转帖]Nginx报错404,由于请求处理时间过长

问题复现 近期部门内部有一个应用由于数据量过于庞大,或者说sql优化性能问题,导致查询全量数据时老报错nginx404,后来查看浏览器timing信息,发现其竟然时常达到可怕的2分钟十秒,抛去解决sql优化问题,这里从Nginx端的配置来说如何解决这类问题! 存在的问题 服务器处理请求时间过长,导致

【转帖】Linux性能优化(十四)——CPU Cache

一、CPU Cache 1、CPU Cache简介 CPU Cache是位于CPU与内存之间的临时存储器,容量比内存小但交换速度却比内存要快得多。Cache的出现主要是为了解决CPU运算速度与内存读写速度不匹配的矛盾,因为CPU运算速度要比内存读写速度快很多,会使CPU花费很长时间等待数据到来或把数

[转帖]《Linux性能优化实战》笔记(十七)—— Linux网络基础与性能指标

一、 网络模型 1. OSI 网络模型(七层) 为了解决网络互联中异构设备的兼容性问题,并解耦复杂的网络包处理流程,OSI 模型把网络互联的框架分为七层,每个层负责不同的功能。其中, 应用层,负责为应用程序提供统一的接口。表示层,负责把数据转换成兼容接收系统的格式。会话层,负责维护计算机之间的通信连

[转帖]十个漂亮的数学定理赏析

https://www.bilibili.com/read/cv10762342?spm_id_from=333.999.0.0 原地址 十个漂亮的数学定理赏析 Beauty is the first test: there is no permanent place in the world fo

[转帖]十二、G1垃圾收集器

G1收集器是一款面向服务器的垃圾收集器,也是HotSpot在JVM上力推的垃圾收集器,并赋予取代CMS的使命。为什么对G1收集器给予如此高的期望呢?既然对G1收集器寄予了如此高的期望,那么他一定是有特别之处。他和其他的垃圾收集器有何不同呢?下面我们将从以下几个方面研究G1收集器。 一、为什么会诞生G