五大报告关注点

最新推荐文章于 2024-06-18 02:32:04 发布

weixin_33709609

最新推荐文章于 2024-06-18 02:32:04 发布

阅读量281

点赞数

文章标签：数据库 python

原文链接：https://my.oschina.net/liubaizi/blog/3015574

版权

2019独角兽企业重金招聘Python工程师标准>>>

一、AWR报告关注点主要从6个指标入手：

DB Time;
load_profile;
efficiency percentages;
top 5 events
SQL Statistic
Segment_statistic

1）DB Time 主要用来判断当前系统有没有遇到相关瓶颈。一般Elapsed时间乘以CPU个数的时间如果结果大于DB time，我们认为系统压力不大，反之则压力较大。

2）load_profile 这个指标主要用来展现当前系统的一些指示性能的总体参数，比如

redo size就是用来显示平均每秒的日志尺寸和平均每个事物的日志尺寸，结合Transactions 这个每秒实务数的指标，就可以分析出当前实务的繁忙程度。

下图1每秒有2,563.9个事物数，这在现实中几乎不可能，现实中的运营商系统一般在200上下比较正常，超过1000就属于非常繁忙了。

图1 单次提交awr

图2 批量提交awr

图2每秒有0.7个事务，平均每个事务产生的日志尺寸是6位数，说明系统是一个提交不频繁的处理大任务时间的系统。

根据而图1的每个事务的日志尺寸，说明系统是一个提交非常频繁且每个事务都非常小的密集提交系统。

3）efficiency percentages是一些命中率指标，其中Buffer Hit、Library Hit等都表示SGA的命中率。在Soft Parse指标表示共享池的软解析率，在OLTP系统中如果该指标低于90%应当引起注意。表示存在未使用绑定变量的情况。

4）top 5 events 等待事件是衡量数据库整体优化情况的重要指标，通过观察Top 5 Timed Foreground Events 模块的Event 和% DB time 可以非常直观

地看出当前数据库面临的主要等待事件是什么。

A）log file sync（日志文件同步）

当一个用户提交或回滚数据时， LGWR 将会话期的重做由 Log Buffer 写入到重做日志中，LGWR 完成任务以后会通知用户进程。日志文件同步等待（ Log File Sync）就是指进程等待LGWR 写完成这个过程，对于回滚操作，该事件记录从用户发出 rollback 命令到回滚完成的时间。

如果该等待过多，可能说明 LGWR 的写出效率低下，或者系统提交过于频繁。

针对该问题，可以关注:
log file parallel write等待事件
user commits,user rollback等统计信息可以用于观察提交或回滚次数

解决方案:
1.提高LGWR性能
尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上
2.使用批量提交
3.适当使用NOLOGGING/UNRECOVERABLE等选项

可以通过如下公式计算平均redo写大小：

avg.redo write size = (Redo block written/redo writes)*512 bytes

如果系统产生redo很多，而每次写的较少，一般说明LGWR被过于频繁的激活了.

B)control file sequential read

Reading from the control file. This happens in many cases. For example, while:

1、Making a backup of the control files

2、Sharing information (between instances) from the control file

3、Reading other blocks from the control files

4、Reading the header block

该等待事件并不表明数据库有问题。一个健康的系统，物理读事件应是除空闲等待事件外的最大等待事件。而该事件在RAC中尤其明显，依照经验来看，在一个正常的RAC集群中，该事件应该排在top10中，因为实例间共享同一份控制文件，对控制文件读取是很频繁的，如果被其他等待事件挤出前10了，那就得看看是哪些等待事件了。

其次，可以查看AWR报告该事件的等待次数，平均等待时间，最大等待时间等信息进行进一步确认。看看这些信息比起日常AWR报告信息是否有明显的异常。