电脑桌面
添加小米粒文库到电脑桌面
安装后可以在桌面快捷访问

Oracle_AWR_报告分析实例讲解VIP免费

Oracle_AWR_报告分析实例讲解_第1页
1/47
Oracle_AWR_报告分析实例讲解_第2页
2/47
Oracle_AWR_报告分析实例讲解_第3页
3/47
WORKLOAD REPOSITORY report for DB Name DB Id Instance Inst num Release RAC Host ICCI 1314098396 ICCI1 1 10.2.0.3.0 YES HPGICCI1 Snap Id Snap Time Sessions Cursors/Session Begin Snap: 2678 25-Dec-08 14:04:50 24 1.5 End Snap: 2680 25-Dec-08 15:23:37 26 1.5 Elapsed: 78.79 (mins) DB Time: 11.05 (mins) Elapsed 表示整个 AWR 报表统计的时间长度 DB Time 是记录在服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间 DB Time=cpu time+wait time(不包含空闲等待)(非后台进程) DB Time 不包括 Oracle 后台进程消耗的时间。如果 DB Time 远远小于 Elapsed时间,说明数据库比较空闲。 上述报表中 Snapshot 时间间隔约为 79 分钟,cpu 就公有 8*79=632 分钟。DB Time 为 11.05分钟,则:cpu 花费了 11.05 分钟在处理 oracle 非空闲等待和运算上(比如逻辑读),也就是说 cpu 有 11.05/632=0.017%花费在处理 oracle 的操作上。 从 awr report 的 Elapsed time 和 DB Time 就能大概了解 db 的负载,计算公式可参考为:cpu 负载=DB Time/(cpu 数*Elapsed)*100% 在 79 分钟里(其间收集了 3 次快照数据),数据库耗时 11 分钟,RDA 数据中显示系统有 8 个逻辑 CPU(4 个物理 CPU),平均每个 CPU 耗时 1.4 分钟,CPU 利用率只有大约 2%(1.4/79)。说明系统压力非常小。 可是对于批量系统,数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。 Report Summary Cache Sizes Begin End Buffer Cache: 3,344M 3,344M Std Block Size: 8K Shared Pool Size: 704M 704M Log Buffer: 14,352K 显示 SGA 中每个区域的大小(在 AMM 改变它们之后),可用来与初始参数值比较。 shared pool 主要包括 library cache 和 dictionary cache。library cache 用来存储最近解析(或编译)后 SQL、PL/SQL 和 Java classes 等。library cache 用来存储最近引用的数据字典。发生在 library cache 或 dictionary cache 的 cache miss 代价要比发生在buffer cache 的代价高得多...

1、当您付费下载文档后,您只拥有了使用权限,并不意味着购买了版权,文档只能用于自身使用,不得用于其他商业用途(如 [转卖]进行直接盈利或[编辑后售卖]进行间接盈利)。
2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。
3、如文档内容存在违规,或者侵犯商业秘密、侵犯著作权等,请点击“违规举报”。

碎片内容

Oracle_AWR_报告分析实例讲解

确认删除?
VIP
微信客服
  • 扫码咨询
会员Q群
  • 会员专属群点击这里加入QQ群
客服邮箱
回到顶部