Oracle AWR报告的生成和解读

news2025/1/11 8:11:40

Oracle AWR报告的生成和解读

一、AWR报告概念及原理

Oracle10g以后，Oracle提供了一个性能检测的工具：AWR（Automatic Workload Repository 自动工作负载库）这个工具可以自动采集Oracle运行中的负载信息，并生成与性能相关的统计数据。我们可以根据这些统计数据来分析一些潜在的问题。

Oracle启动后，后台会有个进程去每小时采集一次系统的快照信息，信息采集来源为：V$active_Session_History视图。该视图可以展示最近活动会话的历史记录。默认将采集到的信息保存8天。

二、修改AWR采样频率和保存时间

在dba_hist_wr_control表中，保存默认的采样频率和保存时间，执行select * from dba_hist_wr_control，显示下图在这里插入图片描述

SNAP_INTERVAL快照间隔，单位是分钟，+00000 01:00:00.0表示+00000零天，01:00:00.0表示间隔一小时收集一次。

RETENTION 快照保留周期，单位是分钟，默认保留8天。

修改默认收集间隔为2小时，保留2周，执行如下代码：exec

dbms_workload_repository.modify_snapshot_settings(interval=>120,retention=>7*2*24*60);

或

exec dbms_workload_repository.modify_snapshot_settings(interval=>120,retention=>20160);

三、生成AWR报告

在操作系统命令行中输入 sqlplus / as sysdba

进入sqlplus后执行 @?/rdbms/admin/awrrpt.sql

选择生成报告的格式，一般选择html格式。

在这里插入图片描述
选择天数

选择开始和结束的快照编号。
在这里插入图片描述

生成的报告存放在，进入sqlplus前的操作系统路径下。

四、解读AWR报告

AWR报告分为概要部分和详细部分，下面简单介绍一下概要部分。

在这里插入图片描述
上图部分是对数据库和操作系统基本情况的概述，包括快照时间等相关信息。其中，DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间，说明数据库比较空闲。

Per Second和Per Transaction这两部分是数据库资源负载的一个明细列表，分割成每秒钟的资源负载和每个事务的资源负载情况，具体含义如下：

redo size: 每秒/每个事务产生的redo量 (单位字节)

logical reads: 每秒/每个事务产生的逻辑读的块数

block changes: 每秒/每个事务改变的数据块数

physical reads: 每秒/每个事务产生的物理读

physical writes: 每秒/每个事务产生的物理写的块数

user calls: 每秒/每个事务用户的调用次数

parses: 每秒/每个事务分析次数

hard parses: 每秒/每个事务硬分析次数

sorts: 每秒/每个事务排序次数

logons: 每秒/每个事务登录数据库次数

executes: 每秒/每个事务 SQL的执行次数

rollbacks: 每秒/每个事物回滚次数

transactions: 每秒的事务数

在这里插入图片描述
Buffer Nowait：表示在内存获得数据的未等待比例。

buffer hit：表示进程从内存中找到数据块的比率，内存数据块命中率

Redo NoWait：表示在LOG缓冲区获得BUFFER的未等待比例。

library hit：表示共享池中SQL解析的命中率

Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。

Parse CPU to ParseElapsd：解析总时间中消耗总CPU的时间百分比

Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。

Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。

Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。
在这里插入图片描述
Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。