AWR(性能报告)

article/2025/9/24 13:48:27

本文章为网络笔记，看了warehouse老师的视频受益匪浅，更是感觉自己技术太过初级，特写了本笔记，方便以后反复学习！
如有任何不妥，请发邮件至102448567@qq.com删除文章！
关于warehouse：
http://blog.itpub.net/19602/viewspace-1059211/
11gR2视频第四版 7_07_AWR

awr:auto workload repository

v$sysstat
v$system_event

统计信息也好，等待事件也好，这些东西都是在内存中的自实例起来之后就是累积的，一旦机器有问题重启了，那么这些信息都没有了，Oracle从9i开始定期往磁盘中写，在数据库中保留一段时间原来都在内存中，现在定期往磁盘上写，多长时间写一次、保留多长时间都是可以设置的，9i的时候把这种思想叫做statspack他只有text格式，10g叫AWR，awr的repository Oracle提供了表，这些表属于sys但是放在sysaux表空间中
10g有三类表awr表
11g有四类表awr表
命名很有特点，这些都是table

wri（internal）

在这里插入图片描述

wrm（metadata）

在这里插入图片描述

wrh（history）

在这里插入图片描述
11g新增了

wrr$（replay）重演

在这里插入图片描述
引入了一个后台进程默认每隔一小时把统计信息从内存中往磁盘中写（做快照），AWR就是取任何两次快照（只要这个instance没有重启过）时间点之间，然后生成报告来判断有什么变化

SELECT *FROM v$bgprocessWHERE paddr <> '00';

40号进程辅助39号进程，只要是39号进程每隔一小时把统计信息做一个快照然后写到磁盘上
在这里插入图片描述
wri、wrm、wrh、wrr这四类都是基础表，一般从dba_hist开头的视图中查询

dba_hist_wr_control

下面是关于dba_hist_wr_control的定义，来源正是WRM$这类基础表
在这里插入图片描述
DBID就是v$database中的ID，默认是每一个小时（SNAP_INTERVAL）做一个快照，保留8天（RETENTION）

AWR这些功能Oracle都是调用的一个包

通过上图的包中的存储过程modify_snapshot_settings就可以更改多久打一次快照和保留多长时间
在这里插入图片描述

SQL> exec dbms_workload_repository.modify_snapshot_settings(retention=>14400,interval=>30);PL/SQL procedure successfully completed.

已经更改了
在这里插入图片描述
下图记录的就是Oracle打的快照，一次快照记录了一批统计信息，统计信息又包含了一批数据

比如说跟文件相关的统计信息就记录到了下面的这个视图中，当快照id是16222的时候，记录了8个数据文件的信息，物理读了多少次，物理写了多少次，读的耗时，写的耗时等等
在这里插入图片描述
手动创建快照
现在最大是97号快照

SELECT *FROM dba_hist_snapshotORDER BY snap_id DESC

在这里插入图片描述
手动创建

SQL> exec dbms_workload_repository.create_snapshot;PL/SQL procedure successfully completed.

现在变成了98

SELECT *FROM dba_hist_snapshotORDER BY snap_id DESC

在这里插入图片描述
生成AWR脚本的路径$ORACLE_HOME/rdbms/admin/awrrpt.sql，这个目录下有很多AWR开头的脚本，这些都是awrrpt.sql调用的，所以只要记住awrrpt.sql就可以了
9i的statspack和AWR最大的区别就是DB TIME

说明DB TIME的实验：
session1

SQL> select *from tt;ID NAME 		       AGE
---------- -------------------- ----------1 aaa				202 bbb				203 ccc				204 d				205 e				20SQL> update tt set name = 'a' where id = 1;1 row updated.

session2

SQL> conn xiha/xiha
Connected.
SQL> update tt set age = 30 where id = 1;
一直在等待

10号session被阻塞了
在这里插入图片描述
是被138号session阻塞的

SELECT *FROM v$sessionWHERE sid in (10,138)

在这里插入图片描述
v$sql中可以看到执行sql消耗的CPU时间（CPU TIME）和执行时间（elapsed_time ）单位是微秒（一秒的一百万分之一）

SELECT *FROM v$sqlWHERE sql_text like 'update tt set%'

在这里插入图片描述
上面这一条sql就是一直在等待的sql，他的elapsed_time还在不断增加，下面的sql不会增加了，执行完了但是没有提交

Oracle中有一个公式service time或者叫response time=cpu time+wait time
也就是说执行一条sql语句的时间等于cpu时间加上等待的时间
也就是v$sql中的elapsed_time=cpu time+wait time
上图中第一条sql，elapsed_time远远大于cpu time并且还在不断地增加，说明这条sql根本没有执行，一直在等待行级锁，他现在的cpu time是sql语句解析消耗的cpu time；
第二条sql，elapsed_time等于cpu time并且不再增加了，说明这个执行了完了而且几乎没有等待
DB TIME：所有活动session的总的时间（不算后台进程的），上图中的第一条sql也是所有非后台进程session中的一个，他就给db time增加了很多的时间，等待时间很长意味着执行效率很差，优化就是要降低DB TIME，要么降低wait time要么降低cpu time