11g,awr报告详细分析.doc

11g,awr报告详细分析 ORACLE AWR报告详细分析 Elapsed时间，说明数据库比较空闲。 db time= cpu time + wait time（不包含空闲等待） （非后台进程） 说白了就是db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间 DB time = cpu time + 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 先说Report A,在snapshot间隔中，总共约60分钟，cpu就共有60*8=480分钟，DB time为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和DB Time就能大概了解db的负载。 可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。 Cache Sizes 值比较。 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 事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。 Redo size：每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。Logical reads：每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的block数。Logical Reads= Consistent Gets + DB Block Gets Block changes：每秒/每事务修改的块数 Physical reads：每秒/每事务物理读的块数 Physical writes：每秒/每事务物理写的块数 User calls：每秒/每事务用户call次数 Parses：SQL解析的次数.每秒解析次数，包括fast parse，soft parse和hard parse三种数量的综合。 软解析每秒超过300次意味着你的应用程序效率不高，调整session_cursor_cach