Oracle_AWR_报告分析实例讲解(1).docxVIP

WORKLOAD REPOSITORY report for DB Time是记录在服务器花在数据库运算（非后台进程）和等待（非空闲等待） 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 BeEnd Be Buffer Cache: 3,344M 3,344M Std Block Size: 8K Shared Pool Size: 704M I 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的代价高得多。因此shared pool的设置要确保最近使用的 数据都能被cache。 Load Profile DB Time (s) 2.4 0.0 Redo size: 918,805.72 775,912.72 Logical reads: 3,521.77 2,974.06 Block changes: 1,817.95 1,535.22 Physical reads: 68.26 57.64 Physical writes: 362.59 306.20 User calls: 326.69 275.88 Parses: 38.66 32.65 Hard parses: 0.03 0.03 Sorts: 0.61 0.51 Logons: 0.01 0.01 Executes: 354.34 299.23 Transactions: 1.18 % Blocks changed per Read: 51.62 Recursive Call %: 51.72 Rollback per transaction %: 85.49 Rows per Sort: ######## 显示数据库负载概况，将之与基线数据比较才具有更多的意义，假如每秒或每 事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负 载状况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2 个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。 DB Time （s）:每秒内用于DB处理的时间，其他时间为等待时间 Redo size:每秒/每事务产生的redo大小（单位字节），可标志数据库任务的 繁重程序。其中Per Second表示每秒中产生的redo的字节数，Per Transaction表 示每个事务产生的redo的字节数，可以通过后者可以看到事务的大小，帮忙判 断是否commit次数太多。例如per second很大，而per transaction很小，说明 commit次数太多。通常在很繁忙的系统中日志生成量可能达到上百k，甚至几百 k。 Logical reads：每秒/每事务规律读的块数（我们可以这样认为，bl