👉 ✈手机屏幕横着看更精彩 *_*. . . . . . 大 江 东 去,浪 淘 尽, 千 古 风 流 人 物。 故 垒 西 边, 人 道 是, 三 国 周 郎 赤 壁。 乱 石 穿 空, 惊 涛 拍 岸, 卷 起 千 堆 雪。 江 山 如 画, 一 时 多 少 豪 杰。 遥 想 公 瑾 当 年, 小 乔 初 嫁 了, 雄 姿 英 发。 羽 扇 纶 巾, 谈 笑 间, 樯 橹 灰 飞 烟 灭。 故 国 神 游, 多 情 应 笑 我, 早 生 华 发。 人 生 如 梦, 一 尊 还 酹 江 月。 (。_°)☆\(- – ) 👈

Oracle数据库性能调优-AWR报告详细分析指南之一

AWR 是Oracle  10g 版本 推出的新特性, 全称叫Automatic Workload Repository-自动负载信息库, AWR 是通过对比两次快,照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分。WORKLOAD REPOSITORY report for

 

DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间,说明数据库比较空闲。

db time= cpu time + wait time(不包含空闲等待)(非后台进程)

说白了就是db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间

DB time = cputime + all of nonidle wait event time

在79分钟里(其间收集了3次快照数据),数据库耗时11分钟,RDA数据中显示系统有8个逻辑CPU(4个物理CPU),平均每个CPU耗时1.4分钟,CPU利用率只有大约2%(1.4/79)。说明系统压力非常小。

 

列出下面这两个来做解释:
Report A:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1
End Snap: 4612 24-Jul-08 23:00:25 17 1.7
Elapsed: 59.51 (mins)
DB Time: 466.37 (mins)

Report B:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6
End Snap: 3102 13-Nov-07 22:00:15 40 16.4
Elapsed: 59.63 (mins)
DB Time: 19.49 (mins)
服务器是AIX的系统,4个双核cpu,共8个核:

/sbin> bindprocessor -q
The available processors are: 0 1 2 3 4 5 6 7

先说ReportA,在snapshot间隔中,总共约60分钟,cpu就共有60*8=480分钟,DBtime为466.37分钟,则:
cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)
也就是说cpu有 466.37/480*100% 花费在处理Oracle的操作上,这还不包括后台进程
看Report B,总共约60分钟,cpu有19.49/480*100% 花费在处理Oracle的操作上
很显然,2中服务器的平均负载很低。
从awr report的Elapsed time和DBTime就能大概了解db的负载。

可是对于批量系统,数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。

posted @ 2020-05-12 17:22  S-Gavin  阅读(675)  评论(0编辑  收藏  举报