如何使用AWR报告来诊断数据库性能问题 (Doc ID 1523048.1)

0    151    1

👉 本文共约159855个字,系统预计阅读时间或需601分钟。

本页目录 隐藏
Main Report

目标

本文旨在提供如何解释跟数据库性能问题息息相关的AWR信息。

需要注意的是生成 AWR Report 或访问 AWR 相关的视图,以及使用任何 AWR 相关的诊断信息,都需要额外的 Diagnostic Pack License。这包括生成 AWR/ADDM/ASH report,也包括当技术支持要求的生成上述报表时。

注意: Oracle Diagnostics Pack (以及 Oracle Tuning Pack) 只在企业版中提供。
详见:

Oracle® Database Licensing Information
12c Release 1 (12.1)
Part number E17614-08
Chapter 1 1 Oracle Database Editions
Feature Availability by Edition
http://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC139

最佳实践

如何主动避免问题发生及做好诊断信息的收集

有些问题是无法预见的,但大部分其它的问题如果及早发现一些征兆其实是可以避免的。同时,如果问题确实发生了,那么收集问题发生时的信息就非常重要。有关于如何主动避免问题及诊断信息的收集,请参见:

Document 1482811.1 Best Practices: Proactively Avoiding Database and Query Performance Issues
Document 1477599.1 Best Practices Around Data Collection For Performance Issues

提出问题、获取帮助并分享您的经验

您想要与其他 Oracle 客户、Oracle 员工及业内专家深入探讨吗?

Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article.
点击这里访问 My Oracle Support Community 数据库性能优化页,在这里您可以提出问题、获取他人的帮助并分享您的经验。

解决方案

对于数据库整体的性能问题,AWR的报告是一个非常有用的诊断工具。

一般来说,当检测到性能问题时,我们会收集覆盖了发生问题的时间段的AWR报告-但是最好只收集覆盖1个小时时间段的AWR报告-如果时间过长,那么AWR报告就不能很好的反映出问题所在。

还应该收集一份没有性能问题的时间段的AWR报告,作为一个参照物来对比有问题的时间段的AWR报告。这两个AWR报告的时间段应该是一致的,比如都是半个小时的,或者都是一个小时的。

关于如何收集AWR报告,请参照如下文档:

Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point

注:最好一开始我们从ADDM报告入手,因为对应时间段的ADDM报告往往已经指出了问题所在。
参见:

Interpretation

在处理性能问题时,我们最关注的是数据库正在等待什么。
当进程因为某些原因不能进行操作时,它需要等待。花费时间最多的等待事件是我们最需要关注的,因为降低它,我们能够获得最大的好处。
AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息,可以让我们只关注主要的问题。

  • Top 5 Timed Events

    正如前面提到的,"Top 5 Timed Events"是AWR报告中最重要的部分。它指出了数据库的sessions花费时间最多的等待事件,如下:

    在这个例子里,Top 5 Events部分显示问题可能跟SQL的执行有关,那么我们接下来检查load profile部分。

    如果您检查AWR report是为了一般性的性能调优,那么可以看到有比较多的redo activity和比较高的physical writes. Physical writes比physical read要高,并且有42%的块被更改了.

    此外,hard parse的次数要少于soft parse.

    如果mutex等待事件比较严重,如"library cache: mutex X",那么查看所有parse的比率会更有用。

    当然,如果把Load Profile部分跟正常时候的AWR报告做比较会更有用,比如,比较redo size, users calls, 和 parsing这些性能指标。

  • Instance Efficiency

    Instance Efficiency部分更适用于一般性的调优,而不是解决某个具体问题(除非等待事件直接指向这些指标)。

    从我们的这个例子来看,最有用的信息是%Non-Parse CPU,它表明几乎所有的CPU都消耗在了Execution而不是Parse上,所以调优SQL会对性能有改善。

    94.48% 的soft parse比率显示hard parse的比例很小,这是可取的。Execute to Parse %很高,说明cursor被很好的重用了。我们总是期望这里的值都是接近100%,但是因为应用的不同,如果这个部分的参数的某些值很小,也是可以认为没 有问题的;如在数据仓库环境,hard parse因为使用了物化视图或histogram而变得很高。所以,重要的是,我们需要把这部分信息和正常时候的AWR报告做比较来判断是否有问题。

  • Latch Activity

    在我们这个例子里,我们并没有看到很高的latch相关的等待,所以这部分的信息可以忽略。

    但是如果latch相关的等待很严重,我们需要查看Latch Sleep Breakdown 部分sleeps很高的latch

    这 里top latch是cache buffers chains. Cache Buffers Chains latches是用来保护buffer caches中的buffers。在我们读取数据时,这个latch是正常需要获得的。Sleep的数字上升代表session在读取buffers时开 始等待这个latch。争用通常来自于不良的SQL要读取相同的buffers。

    在我们这个例子里,虽然读取buffer的操作发生了 28亿次,但是只sleep了41,336次,可以认为是比较低的。Avg Slps/Miss(Sleeps/ Misses)也比较低。这表明当前Server有能力处理这样多的数据,所以没有发生Cache Buffers Chains latch的争用。

    关于其他的latch free等待,请参照以下文档:

    Document 413942.1 How to Identify Which Latch is Associated with a "latch free" wait

值得注意的wait events

  • CPU time events

    CPU变为top wait event并不总是代表出现了问题。但是如果同时数据库性能比较慢,那么就需要进一步分析了。首先,检查AWR报告的“ SQL ordered by CPU Time ”部分,看是否某个特定的SQL使用了大量的CPU。

    Analysis:

    • -> Total CPU Time (s): 56,207
      它代表了15分钟的CPU time。但是这个数字是否有问题取决于整个报告的时间。
    • Top SQL使用的CPU是 20,349秒(大概5分钟)
    • 整个CPU时间占DB Time的9.1%
    • 执行了168次,这个执行次数跟之前提到的几个SQL是一样的,说明这些SQL可能都是被同一个JOB调用的。

​ Actions:
​ 一旦确定了使用最高 CPU 的 SQL 语句,请调查这种使用的原因。

  • 查看执行次数,看看这是否适合该语句。 过多的执行可能表明该语句被过于频繁地调用,并且可能为一组行而不是逐行执行它(比如批量执行它)。
  • 每次执行的 CPU 量是否过多 - 这可能表明语句本身效率低下。
  • 此外,请查看 AWR 报告中的其他 SQL 统计信息,以查看所讨论的 SQLID 是否显示任何这些值的过多值,然后适当地处理该语句。

​ 其他潜在的CPU相关的问题:

    检查是否有其他等待事件与高CPU 事件同时出现

    如cursor: pin S问题可能引起高CPU使用:

    Document 6904068.8 Bug 6904068 - High CPU usage when there are "cursor: pin S" waits

    数据库以外的CPU使用率过高

    如果一个数据库以外的进程使用了过多CPU,那么数据库进程能够获得的CPU就会减少,数据库性能就会受到影响。在这种情况下,运行OSWather或者其他的OS工具去发现是哪个进程使用了过多CPU

    Document 433472.1 OS Watcher For Windows (OSWFW) User Guide

    诊断CPU使用率

    下面的文档进一步描述了如何进一步分析CPU问题:

    Document 164768.1 Troubleshooting: High CPU Utilization

  • 'Log file sync' waits

    当 一个user session commit或rollback时,log writer进程会把redo从log buffer中写入redo logfile文件。AWR报告会帮助我们来确定是否存在这方面的问题,并且确认是否是由物理IO引起。如果”log file sync”事件比较严重,下面的文档详细描述了如何来处理:

    Document 1376916.1 Troubleshooting: "Log File Sync" Waits
    Document 34592.1WAITEVENT: "log file sync"

  • Buffer busy waits

    当 一个session从buffer cache读取一个buffer时,如果这个buffer处于busy的状态(由于其它session正在向其中读取数据,或者是由于这个buffer被 其它的session以不兼容模式持有),那么这个session就会等待这个事件。参照下面文档来找出哪个block处于busy状态和为什么:

    Document 155971.1 Resolving Intense and "Random" Buffer Busy Wait Performance Problems
    Document 34405.1 WAITEVENT: "buffer busy waits"

Waits for 'Cursor: mutex/pin'

如 果发现了一些像"Cursor: pin S wait on X" 或"Cursor: mutex X" 类的mutex等待,那么可能是由于parsing引起的问题。检查"SQL ordered by Parse Calls" 和"SQL ordered by Version Count"部分的Top SQL,这些SQL可能引起这类的问题。以下文档可以帮助我们分析这类问题:

Document 1356828.1 FAQ: 'cursor: mutex ..' / 'cursor: pin ..' / 'library cache: mutex ..' Type Wait Events
Document 1349387.1 Troubleshooting 'cursor: pin S wait on X' waits.

诊断其他问题

关于其他性能问题,请参照文档:

Document 1377446.1 Troubleshooting Performance Issues

使用ADDM的报告

当分析性能问题时,除了AWR报告,我们还可以同时参照ADDM报告,对于潜在的性能问题,它同时提供了具体的解决方案建议。下面是从如下文档拿到的一个ADDM报告示例:

Document 250655.1How to use the Automatic Database Diagnostic Monitor:

Example Output:

DETAILED ADDM REPORT FOR TASK 'SCOTT_ADDM' WITH ID 5
----------------------------------------------------

Analysis Period: 17-NOV-2003 from 09:50:21 to 10:35:47
Database ID/Instance: 494687018/1
Snapshot Range: from 1 to 3
Database Time: 4215 seconds
Average Database Load: 1.5 active sessions

\~~~~~~~~~~~~~~~~

FINDING 1: 65% impact (2734 seconds)
------------------------------------
PL/SQL execution consumed significant database time.

RECOMMENDATION 1: SQL Tuning, 65% benefit (2734 seconds)
ACTION: Tune the PL/SQL block with SQL_ID fjxa1vp3yhtmr. Refer to
the "Tuning PL/SQL Applications" chapter of Oracle's "PL/SQL
User's Guide and Reference"
RELEVANT OBJECT: SQL statement with SQL_ID fjxa1vp3yhtmr
BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;

FINDING 2: 35% impact (1456 seconds)
------------------------------------
SQL statements consuming significant database time were found.

RECOMMENDATION 1: SQL Tuning, 35% benefit (1456 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
gt9ahqgd5fmm2.
RELEVANT OBJECT: SQL statement with SQL_ID gt9ahqgd5fmm2 and
PLAN_HASH 547793521
UPDATE bigemp SET empno = ROWNUM

FINDING 3: 20% impact (836 seconds)
-----------------------------------
The throughput of the I/O subsystem was significantly lower than expected.

RECOMMENDATION 1: Host Configuration, 20% benefit (836 seconds)
ACTION: Consider increasing the throughput of the I/O subsystem.
Oracle's recommended solution is to stripe all data file using
the SAME methodology. You might also need to increase the
number of disks for better performance.

RECOMMENDATION 2: Host Configuration, 14% benefit (584 seconds)
ACTION: The performance of file
D:\ORACLE\ORADATA\V1010\UNDOTBS01.DBF was significantly worse
than other files. If striping all files using the SAME
methodology is not possible, consider striping this file over
multiple disks.
RELEVANT OBJECT: database file
"D:\ORACLE\ORADATA\V1010\UNDOTBS01.DBF"

SYMPTOMS THAT LED TO THE FINDING:
Wait class "User I/O" was consuming significant database time.
(34% impact [1450 seconds])

FINDING 4: 11% impact (447 seconds)
-----------------------------------
Undo I/O was a significant portion (33%) of the total database I/O.

NO RECOMMENDATIONS AVAILABLE

SYMPTOMS THAT LED TO THE FINDING:
The throughput of the I/O subsystem was significantly lower than
expected. (20% impact [836 seconds])
Wait class "User I/O" was consuming significant database time.
(34% impact [1450 seconds])

FINDING 5: 9.9% impact (416 seconds)
------------------------------------
Buffer cache writes due to small log files were consuming significant
database time.

RECOMMENDATION 1: DB Configuration, 9.9% benefit (416 seconds)
ACTION: Increase the size of the log files to 796 M to hold at
least 20 minutes of redo information.

ADDM报告相比AWR报告来说,它提供了可读性更好的建议;当然应该同时参照ADDM报告和AWR报告来得到更准确地诊断。

其他的AWR参考文章

当阅读AWR报告的其他部分时,可以参照下面的一些文档:

Document 786554.1 How to Read PGA Memory Advisory Section in AWR and Statspack Reports
Document 754639.1 How to Read Buffer Cache Advisory Section in AWR and Statspack Reports

Document 1301503.1 Troubleshooting: AWR Snapshot Collection issues
Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point

Statspack

AWR报告取代了旧有的staspack及bstat/estat报告,下面的这些文档概述了如何阅读statspack报告:

http://www.oracle.com/technetwork/database/focus-areas/performance/statspack-opm4-134117.pdf

Additional information can be found in the following articles:

Document 94224.1 FAQ- Statspack Complete Reference
Document 394937.1 Statistics Package (STATSPACK) Guide

Document 149113.1 Installing and Configuring StatsPack Package
Document 149121.1 Gathering a StatsPack snapshot
Document 228913.1 Systemwide Tuning using STATSPACK Reports

参考

NOTE:228913.1 - Systemwide Tuning Using STATSPACK Reports
NOTE:754639.1 - How to Read Buffer Cache Advisory Section in AWR and Statspack Reports.
NOTE:786554.1 - How to Read PGA Memory Advisory Section in AWR and Statspack Reports to Tune PGA_AGGREGATE_TARGET
NOTE:1349387.1 - Troubleshooting 'cursor: pin S wait on X' waits.
BUG:6904068 - HIGH CPU UTILIZATION DURING MUTEX WAIT EVENTS
NOTE:1301503.1 - Troubleshooting: Missing Automatic Workload Repository (AWR) Snapshots and Other Collection Issues
NOTE:1356828.1 - FAQ: 'cursor: mutex ..' / 'cursor: pin ..' / 'library cache: mutex ..' Type Wait Events
NOTE:1363422.1 - Automatic Workload Repository (AWR) Reports - Main Information Sources
NOTE:1377446.1 - * Troubleshooting Performance Issues
NOTE:1376916.1 - Troubleshooting: 'Log file sync' Waits
NOTE:155971.1 - Resolving Intense and "Random" Buffer Busy Wait Performance Problems
NOTE:164768.1 - Troubleshooting: High CPU Utilization
NOTE:413942.1 - How to Identify Which Latch is Associated with a "latch free" wait
NOTE:433472.1 - OS Watcher For Windows (OSWFW) User Guide
NOTE:271196.1 - Automatic SQL Tuning and SQL Profiles
NOTE:276103.1 - Performance Tuning Using Advisors and Manageability Features: AWR, ASH, ADDM and SQL Tuning Advisor
NOTE:34405.1 - WAITEVENT: "buffer busy waits" Reference Note
NOTE:250655.1 - How to Use the Automatic Database Diagnostic Monitor
NOTE:223117.1 - Troubleshooting I/O Related Waits
NOTE:1482811.1 - Best Practices: Proactively Avoiding Database and Query Performance Issues
NOTE:1477599.1 - Best Practices: Proactive Data Collection for Performance Issues
NOTE:34592.1 - WAITEVENT: "log file sync" Reference Note
NOTE:6904068.8 - Bug 6904068 - High CPU usage when there are "cursor: pin S" waits
NOTE:262687.1 - Using the DBMS_SQLTUNE Package to Run the SQL Tuning Advisor

Oracle中的AWR,全称为Automatic Workload Repository,自动负载信息库。它收集关于特定数据库的操作统计信息和其他统计信息,Oracle以固定的时间间隔(默认为1个小时)为其所有重要的统计信息和负载信息执行一次快照,并将快照存放入AWR中。这些信息在AWR中保留指定的时间(默认为1周),然后执行删除。执行快照的频率和保持时间都是可以自定义的。
AWR的引入,为我们分析数据库提供了非常好的便利条件(这方面MySQL就相差了太多)。曾经有这样的一个比喻——“一个系统,就像是一个黑暗的大房间,系统收集的统计信息,就如同放置在房间不同位置的蜡烛,用于照亮这个黑暗大房间。Oracle,恰到好处地放置了足够的蜡烛(AWR),房间中只有极少的烛光未覆盖之处,性能瓶颈就容易定位。而对于蜡烛较少或是没有蜡烛的系统,性能优化就如同黑暗中的舞者。”
那如何解读AWR的数据呢?Oracle本身提供了一些报告,方便进行查看、分析。下面就针对最为常见的一种报告——《AWR数据库报告》进行说明。希望通过这篇文章,能方便大家更好地利用AWR,方便进行分析工作。

一、MAIN

1
Database Information
img
2
Snapshot Information
img
(1)Sessions
表示采集实例连接的会话数。这个数可以帮助我们了解数据库的并发用户数大概的情况。这个数值对于我们判断数据库的类型有帮助。
(2)Cursors/session
每个会话平均打开的游标数。
(3)Elapsed
通过Elapsed/DB Time比较,反映出数据库的繁忙程度。如果DB Time>>Elapsed,则说明数据库很忙。
(4)DB Time
表示用户操作花费的时间,包括CPU时间和等待事件。通常同时这个数值判读数据库的负载情况。
具体含义
db time = cpu time + wait time(不包含空闲等待)(非后台进程)
db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间。对应于V$SESSION的elapsed_time字段累积。
"合集数据"
需要注意的是AWR是一个数据合集。比如在1分钟之内,1个用户等待了30秒钟,那么10个用户等待事件就是300秒。CPU时间也是一样,在1分钟之内,1个CPU处理30秒钟,那么4个CPU就是120秒。这些时间都是以累积的方式记录在AWR当中的。
示例
DB CPU——这是一个用于衡量CPU的使用率的重要指标。假设系统有N个CPU,那么如果CPU全忙的话,一秒钟内的DB CPU就是N秒。除了利用CPU进行计算外,数据库还会利用其它计算资源,如网络、硬盘、内存等等,这些对资源的利用同样可以利用时间进行度量。假设系统有M个session在运行,同一时刻有的session可能在利用CPU,有的session可能在访问硬盘,那么在一秒钟内,所有session的时间加起来就可以表征系统在这一秒内的繁忙程度。一般的,这个和的最大值应该为M。这其实就是Oracle提供的另一个重要指标:DB time,它用以衡量前端进程所消耗的总时间。
对除CPU以后的计算资源的访问,Oracle用等待事件进行描述。同样地,和CPU可分为前台消耗CPU和后台消耗CPU一样,等待事件也可以分为前台等待事件和后台等待事件。DB Time一般的应该等于"DB CPU + 前台等待事件所消耗时间"的总和。等待时间通过v$system_event视图进行统计,DB Time和DB CPU则是通过同一个视图,即v$sys_time_model进行统计。
--"Load Profile"中关于DB Time的描述
img
这个系统的CPU个数是8,因此我们可以知道前台进程用了系统CPU的7.1/8=88.75%。DB Time/s为11.7,可以看出这个系统是CPU非常繁忙的。里面CPU占了7.1,则其它前台等待事件占了11.7 – 7.1 = 4.6 Wait Time/s。DB Time 占 DB CPU的比重: 7.1/11.7= 60.68%
--"Top 5 Timed Events"中关于DB CPU的描述
按照CPU/等待事件占DB Time的比例大小,这里列出了Top 5。如果一个工作负载是CPU繁忙型的话,那么在这里应该可以看到 DB CPU的影子。
img
注意到,我们刚刚已经算出了DB CPU 的%DB time,60%。其它的external table read、direct path write、PX Deq: read credit、PX Deq: Slave Session Stats这些就是占比重40的等待事件里的Top 4了。
--"Top 5 Timed Foreground Events"的局限性
再研究下这个Top 5 Timed Foreground Events,如果先不看Load Profile,是不能计算出一个CPU-Bound的工作负载。要知道系统CPU的繁忙程序,还要知道这个AWR所基于两个snapshot的时间间隔,还要知道系统CPU的个数。要不系统可以是一个很IDLE的系统呢。记住CPU利用率 = DB CPU/(CPU_COUNT
Elapsed TIME)。这个Top 5 给我们的信息只是这个工作负载应该是并行查询,从外部表读取数据,并用insert append的方式写入磁盘,同时,主要时间耗费在CPU的运算上。
--解读"DB Time" > "DB CPU" + "前台等待事件所消耗时间" ——进程排队时间
上面提到,DB Time一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。在下面有对这三个值的统计:
img
DB CPU = 6474.65
DB TIME = 10711.2
FG Wait Time = 1182.63
明显的,DB CPU + FG Wait Time < DB Time,只占了71.5%
*其它的28.5%被消耗到哪里去了呢?这里其实又隐含着一个Oracle如何计算DB CPU和DB Time的问题。当CPU很忙时,如果系统里存在着很多进程,就会发生进程排队等待CPU的现象。在这样,DB TIME是把进程排队等待CPU的时间算在内的,而DB CPU是不包括这一部分时间。这是造成 DB CPU + FG Wait Time < DB Time的一个重要原因。如果一个系统CPU不忙,这这两者应该就比较接近了。不要忘了在这个例子中,这是一个CPU非常繁忙的系统,而71.5%就是一个信号,它提示着这个系统可能是一个CPU-Bound的系统。

二、Report Summary

1
Cache Sizes
img
这部分列出AWR在性能采集开始和结束的时候,数据缓冲池(buffer cache)和共享池(shared pool)的大小。通过对比前后的变化,可以了解系统内存消耗的变化。
2
Load Profile
img
这两部分是数据库资源负载的一个明细列表,分隔成每秒钟的资源负载和每个事务的资源负载。

  • Redo size
    每秒(每个事务)产生的日志大小(单位字节)

  • Logical reads
    每秒(每个事务)产生的逻辑读(单位是block)。在很多系统里select执行次数要远远大于transaction次数。这种情况下,可以参考Logical reads/Executes。在良好的oltp环境下,这个应该不会超过50,一般只有10左右。如果这个值很大,说明有些语句需要优化。

  • Block Changes
    每秒(每个事务)改变的数据块数。

  • Physical reads
    每秒(每个事务)产生的物理读(单位是block)。一般物理读都会伴随逻辑读,除非直接读取这种方式,不经过cache。

  • Physical writes
    每秒(每个事务)产生的物理写(单位是block)。

  • User calls
    每秒(每个事务)用户调用次数。User calls/Executes基本上代表了每个语句的请求次数,Executes越接近User calls越好。

  • Parses
    每秒(每个事务)产生的解析(或分析)的次数,包括软解析和硬解析,但是不包括快速软解析。软解析每秒超过300次意味着你的"应用程序"效率不高,没有使用soft soft parse,调整session_cursor_cache。

  • Hard parses
    每秒(每个事务)产生的硬解析次数。每秒超过100次,就可能说明你绑定使用的不好。

  • Sorts
    每秒(每个事务)排序次数。

  • Logons
    每秒(每个事务)登录数据库次数。

  • Executes
    每秒(每个事务)SQL语句执行次数。包括了用户执行的SQL语句与系统执行的SQL语句,表示一个系统SQL语句的繁忙程度。

  • Transactions
    每秒的事务数。表示一个系统的事务繁忙程度。目前已知的最繁忙的系统为淘宝的在线交易系统,这个值达到了1000。

  • % Blocks changed per Read
    表示逻辑读用于只读而不是修改的块的比例。如果有很多PLSQL,那么就会比较高。

  • Rollback per transaction %
    看回滚率是不是很高,因为回滚很耗资源。

  • Recursive Call %
    递归调用SQL的比例,在PL/SQL上执行的SQL称为递归的SQL。
    3
    Instance Efficiency Percentages (Target 100%)
    img
    这个部分是内存效率的统计信息。对于OLTP系统而言,这些值都应该尽可能地接近100%。对于OLAP系统而言,意义不太大。因为在OLAP系统中,大查询的速度才是对性能影响的最大因素。

  • Buffer Nowait %
    非等待方式获取数据块的百分比。
    这个值偏小,说明发生SQL访问数据块时数据块正在被别的会话读入内存,需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。
    Buffer Nowait<99%说明,有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)。

  • Redo NoWait %
    非等待方式获取redo数据百分比。

  • Buffer Hit %
    数据缓冲命中率,表示了数据块在数据缓冲区中的命中率。
    Buffer Hit<95%,可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高(大量的db file sequential read)。

  • In-memory Sort %
    数据块在内存中排序的百分比。总排序中包括内存排序和磁盘排序。当内存中排序空间不足时,使用临时表空间进行排序,这个是内存排序对总排序的百分比。
    过低说明有大量排序在临时表空间进行。在oltp环境下,最好是100%。如果太小,可以调整PGA参数。

  • Library Hit %
    共享池中SQL解析的命中率。
    Library Hit<95%,要考虑加大共享池,绑定变量,修改cursor_sharing等。

  • Soft Parse %
    软解析占总解析数的百分比。可以近似当作sql在共享区的命中率。
    这个数值偏低,说明系统中有些SQL没有重用,最优可能的原因就是没有使用绑定变量。
    <95%:需要考虑到绑定
    <80%:那么就可能sql基本没有被重用

  • Execute to Parse %
    执行次数对分析次数的百分比。
    如果该值偏小,说明解析(硬解析和软解析)的比例过大,快速软解析比例小。根据实际情况,可以适当调整参数session_cursor_cache,以提高会话中sql执行的命中率。
    round(100*(1-:prse/:exe),2) 即(Execute次数 - Parse次数)/Execute次数 x 100%
    prse = select value from v$sysstat where name = 'parse count (total)';
    exe = select value from v$sysstat where name = 'execute count';
    没绑定的话导致不能重用也是一个原因,当然sharedpool太小也有可能,单纯的加session_cached_cursors也不是根治的办法,不同的sql还是不能重用,还要解析。即使是soft parse 也会被统计入 parse count,所以这个指标并不能反应出fast soft(pga 中)/soft (shared pool中)/hard (shared pool 中新解析) 几种解析的比例。只有在pl/sql的类似循环这种程序中使用使用变量才能避免大量parse,所以这个指标跟是否使用bind并没有必然联系增加session_cached_cursors 是为了在大量parse的情况下把soft转化为fast soft而节约资源。

  • Latch Hit %
    latch的命中率。
    其值低是因为shared_pool_size过大或没有使用绑定变量导致硬解析过多。要确保>99%,否则存在严重的性能问题,比如绑定等会影响该参数。

  • Parse CPU to Parse Elapsd %
    解析总时间中消耗CPU的时间百分比。即:100*(parse time cpu / parse time elapsed)
    解析实际运行事件/(解析实际运行时间+解析中等待资源时间),越高越好。

  • % Non-Parse CPU
    CPU非分析时间在整个CPU时间的百分比。
    100*(parse time cpu / parse time elapsed)= Parse CPU to Parse Elapsd %
    查询实际运行时间/(查询实际运行时间+sql解析时间),太低表示解析消耗时间过多。
    4
    Shared Pool Statistics
    img

  • Memory Usage %
    共享池内存使用率。
    应该稳定在70%-90%间,太小浪费内存,太大则内存不足。

  • % SQL with executions>1
    执行次数大于1的SQL比率。
    若太小可能是没有使用绑定变量。

  • % Memory for SQL w/exec>1
    执行次数大于1的SQL消耗内存/所有SQL消耗的内存(即memory for sql with execution > 1)。
    5
    *Top 5 Timed Events*
    img

三、RAC Statistics

这一部分只在有RAC环境下才会出现,是一些全局内存中数据发送、接收方面的性能指标,还有一些全局锁的信息。除非这个数据库在运行正常是设定了一个基线作为参照,否则很难从这部分数据中直接看出性能问题。
经验
Oracle公司经验,下面GCS和GES各项指标中,凡是与时间相关的指标,只要GCS指标低于10ms,GES指标低于15ms,则一般表示节点间通讯效率正常。但是,即便时间指标正常,也不表示应用本身或应用在RAC部署中没有问题。
1
Global Cache Load Profile
img
2
Global Cache Efficiency Percentages (Target local+remote 100%)
img
3
Global Cache and Enqueue Services - Workload Characteristics
img
4
Global Cache and Enqueue Services - Messaging Statistics
img
5
Global Cache Transfer Stats
img
如果CR的%Busy很大,说明节点间存在大量的块争用。

四、Wait Events Statistics

1
Time Model Statistics
img
这部分信息列出了各种操作占用的数据库时间比例。

  • parse time elapsed/hard parse elapsed time
    通过这两个指标的对比,可以看出硬解析占整个的比例。如果很高,就说明存在大量硬解析。

  • % Not-Parse CPU
    花费在非解析上CPU消耗占整个CPU消耗的比例。反之,则可以看出解析占用情况。如果很高,也可以反映出解析过多(进一步可以看看是否是硬解析过多)。
    示例 - 计算CPU消耗
    img
    Total DB CPU = DB CPU + background cpu time = 1305.89 + 35.91 = 1341.8 seconds
    再除以总的 BUSY_TIME + IDLE_TIME
    % Total CPU = 1341.8/1941.76 = 69.1%,这刚好与上面Report的值相吻合。
    其实,在Load Profile部分,我们也可以看出DB对系统CPU的资源利用情况。
    img
    用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。
    这里 5.3/8 = 66.25 %
    比69.1%稍小,说明DB在后台也消耗了大约3%的CPU。
    2
    Wait Class
    img
    这一部分是等待的类型。可以看出那类等待占用的时间最长。
    3
    Wait Events
    img
    这一部分是整个实例等待事件的明细,它包含了TOP 5等待事件的信息。
    %Time-outs: 超时百分比(超时依据不太清楚?)
    4
    Background Wait Events
    img
    这一部分是实例后台进程的等待事件。如果我们怀疑那个后台进程(比如DBWR)无法及时响应,可以在这里确认一下是否有后台进程等待时间过长的事件存在。
    5
    Operating System Statistics
    (1)背景知识
    如果关注数据库的性能,那么当拿到一份AWR报告的时候,最想知道的第一件事情可能就是系统资源的利用情况了,而首当其冲的,就是CPU。而细分起来,CPU可能指的是:

  • OS级的User%, Sys%, Idle%

  • DB所占OS CPU资源的Busy%

  • DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU


    (2)11g
    如果数据库的版本是11g,那么很幸运的,这些信息在AWR报告中一目了然:
    img
    OS级的%User为75.4,%Sys为2.8,%Idle为21.2,所以%Busy应该是78.8。
    DB占了OS CPU资源的69.1,%Busy CPU则可以通过上面的数据得到:%Busy CPU = %Total CPU/(%Busy) 100 = 69.1/78.8 100 = 87.69,和报告的87.7相吻合。
    (3)10g
    如果是10g,则需要手工对Report里的一些数据进行计算了。Host CPU的结果来源于DBA_HIST_OSSTAT,AWR报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是厘秒-也就是1/100秒)。
    img
    解读输出
    %User = USER_TIME/(BUSY_TIME+IDLE_TIME)100 = 146355/(152946+41230)100 = 75.37
    %Sys = SYS_TIME/(BUSY_TIME+IDLE_TIME)100
    %Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)
    100
    ELAPSED_TIME
    这里已经隐含着这个AWR报告所捕捉的两个snapshot之间的时间长短了。有下面的公式。正确的理解这个公式可以对系统CPU资源的使用及其度量的方式有更深一步的理解。
    BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
    推算出:ELAPSED_TIME = (152946+41230)/8/100 = 242.72 seconds //这是正确的。
    时间统计视图v$sys_time_model
    至于DB对CPU的利用情况,这就涉及到10g新引入的一个关于时间统计的视图 - v$sys_time_model。简单而言,Oracle采用了一个统一的时间模型对一些重要的时间指标进行了记录,具体而言,这些指标包括:
    \1) background elapsed time
    \2) background cpu time
    \3) RMAN cpu time (backup/restore)
    \1) DB time
    \2) DB CPU
    \2) connection management call elapsed time
    \2) sequence load elapsed time
    \2) sql execute elapsed time
    \2) parse time elapsed
    \3) hard parse elapsed time
    \4) hard parse (sharing criteria) elapsed time
    \5) hard parse (bind mismatch) elapsed time
    \3) failed parse elapsed time
    \4) failed parse (out of shared memory) elapsed time
    \2) PL/SQL execution elapsed time
    \2) inbound PL/SQL rpc elapsed time
    \2) PL/SQL compilation elapsed time
    \2) Java execution elapsed time
    \2) repeated bind elapsed time
    我们这里关注的只有和CPU相关的两个: background cpu time 和 DB CPU。这两个值在AWR里面也有记录。

五、SQL Statistics

1
SQL ordered by Elapsed Time
img
这一部分是按照SQL执行时间从长到短的排序。

  • Elapsed Time(S)
    SQL语句执行用总时长,此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间,而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time

  • CPU Time(s)
    为SQL语句执行时CPU占用时间总时长,此时间会小于等于Elapsed Time时间。单位时间为秒。

  • Executions
    SQL语句在监控范围内的执行次数总计。如果Executions=0,则说明语句没有正常完成,被中间停止,需要关注。

  • Elap per Exec(s)
    执行一次SQL的平均时间。单位时间为秒。

  • % Total DB Time
    为SQL的Elapsed Time时间占数据库总时间的百分比。

  • SQL ID
    SQL语句的ID编号,点击之后就能导航到下边的SQL详细列表中,点击IE的返回可以回到当前SQL ID的地方。

  • SQL Module
    显示该SQL是用什么方式连接到数据库执行的,如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。

  • SQL Text
    简单的SQL提示,详细的需要点击SQL ID。


    分析说明
    如果看到SQL语句执行时间很长,而CPU时间很少,则说明SQL在I/O操作时(包括逻辑I/O和物理I/O)消耗较多。可以结合前面I/O方面的报告以及相关等待事件,进一步分析是否是I/O存在问题。当然SQL的等待时间主要发生在I/O操作方面,不能说明系统就存在I/O瓶颈,只能说SQL有大量的I/O操作。
    如果SQL语句执行次数很多,需要关注一些对应表的记录变化。如果变化不大,需要从前面考虑是否大多数操作都进行了Rollback,导致大量的无用功。
    2
    SQL ordered by CPU Time
    img
    记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和,而不是单次SQL执行时间)。这部分是SQL消耗的CPU时间从高到底的排序。

  • CPU Time (s)
    SQL消耗的CPU时间。

  • Elapsed Time (s)
    SQL执行时间。

  • Executions
    SQL执行次数。

  • CPU per Exec (s)
    每次执行消耗CPU时间。

  • % Total DB Time
    SQL执行时间占总共DB time的百分比。
    3
    SQL ordered by Gets
    img
    这部分列出SQL获取的内存数据块的数量,按照由大到小的顺序排序。buffer get其实就是逻辑读或一致性读。在sql 10046里面,也叫query read。表示一个语句在执行期间的逻辑IO,单位是块。在报告中,该数值是一个累计值。Buffer Get=执行次数 * 每次的buffer get。记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和,而不是单次SQL执行所占的Gets)。

  • Buffer Gets
    SQL执行获得的内存数据块数量。

  • Executions
    SQL执行次数。

  • Gets per Exec
    每次执行获得的内存数据块数量。

  • %Total
    占总数的百分比。

  • CPU Time (s)
    消耗的CPU时间。

  • Elapsed Time (s)
    SQL执行时间。


    筛选SQL的标准
    因为statspack/awr列出的是总体的top buffer,它们关心的是总体的性能指标,而不是把重心放在只执行一次的语句上。为了防止过大,采用了以下原则。如果有sql没有使用绑定变量,执行非常差但是由于没有绑定,因此系统人为是不同的sql。有可能不会被列入到这个列表中。

  • 大于阀值buffer_gets_th的数值,这是sql执行缓冲区获取的数量(默认10000)。

  • 小于define top_n_sql=65的数值。
    4
    SQL ordered by Reads
    img
    这部分列出了SQL执行物理读的信息,按照从高到低的顺序排序。记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和,而不是单次SQL执行所占的磁盘物理读)。

  • Physical Reads
    SQL物理读的次数。

  • Executions
    SQL执行次数。

  • Reads per Exec
    SQL每次执行产生的物理读。

  • %Total
    占整个物理读的百分比。

  • CPU Time (s)
    SQL执行消耗的CPU时间。

  • Elapsed Time (s)
    SQL的执行时间。
    5
    SQL ordered by Executions
    img
    这部分列出了SQL执行次数的信息,按照从大到小的顺序排列。如果是OLTP系统的话,这部分比较有用。因此SQL执行频率非常大,SQL的执行次数会对性能有比较大的影响。OLAP系统因为SQL重复执行的频率很低,因此意义不大。

  • Executions
    SQL的执行次数。

  • Rows Processed
    SQL处理的记录数。

  • Rows per Exec
    SQL每次执行处理的记录数。

  • CPU per Exec (s)
    每次执行消耗的CPU时间。

  • Elap per Exec (s)
    每次执行的时长。
    6
    SQL ordered by Parse Calls
    img
    这部分列出了SQL按分析次(软解析)数的信息,按照从高到底的顺序排列。这部分对OLTP系统比较重要,这里列出的总分析次数并没有区分是硬分析还是软分析。但是即使是软分析,次数多了,也是需要关注的。这样会消耗很多内存资源,引起latch的等待,降低系统的性能。软分析过多需要检查应用上是否有频繁的游标打开、关闭操作。

  • Parse Calls
    SQL分析的次数。

  • Executions
    SQL执行的次数。

  • % Total Parses
    占整个分析次数的百分比。
    7
    SQL ordered by Sharable Memory
    记录了SQL占用library cache的大小的TOP SQL。

  • Sharable Mem (b)
    占用library cache的大小。单位是byte。
    8
    SQL ordered by Version Count
    img
    这部分列出了SQL多版本的信息。记录了SQL的打开子游标的TOP SQL。一个SQL产生多版本的原因有很多,可以查询视图v$sql_sahred_cursor视图了解具体原因。对于OLTP系统,这部分值得关注,了解SQL被重用的情况。

  • Version Count
    SQL的版本数。

  • Executions
    SQL的执行次数。
    9
    SQL ordered by Cluster Wait Time
    img
    记录了集群的等待时间的TOP SQL。这部分只在RAC环境中存在,列出了实例之间共享内存数据时发生的等待。在RAC环境下,几个实例之间需要有一种锁的机制来保证数据块版本的一致性,这就出现了一类新的等待事件,发生在RAC实例之间的数据访问等待。对于RAC结构,还是采用业务分隔方式较好。这样某个业务固定使用某个实例,它访问的内存块就会固定地存在某个实例的内存中,这样降低了实例之间的GC等待事件。此外,如果RAC结构采用负载均衡模式,这样每个实例都会被各种应用的会话连接,大量的数据块需要在各个实例的内存中被拷贝和锁定,会加剧GC等待事件。

  • Cluster Wait Time (s)
    集群等待时长。

  • CWT % of Elapsd Time
    集群操作等待时长占总时长的百分比。

  • Elapsed Time(s)
    SQL执行总时长。
    10
    Complete List of SQL Text
    img
    这部分是上面各部分涉及的SQL的完整文本。

六、Instance Activity Statistics

1
Instance Activity Stats
img
这部分是实例的信息统计,项目非常多。对于RAC架构的数据库,需要分析每个实例的AWR报告,才能对整体性能做出客观的评价。
CPU used by this session
这个指标用来上面在当前的性能采集区间里面,Oracle消耗的CPU单位。一个CPU单位是1/100秒。从这个指标可以看出CPU的负载情况。
案例 - 分析系统CPU繁忙程度
img
在TOP5等待事件里,找到"CPU time",可以看到系统消耗CPU的时间为26469秒。
img
在实例统计部分,可以看到整个过程消耗了1813626个CPU单位。每秒钟消耗21个CPU单位,对应实际的时间就是0.21秒。也就是每秒钟CPU的处理时间为0.21秒。
img
系统内CPU个数为8。每秒钟每个CPU消耗是21/8=2.6(个CPU单位)。在一秒钟内,每个CPU处理时间就是2.6/100=0.026秒。
总体来看,当前数据库每秒钟每个CPU处理时间才0.026秒,远远算不上高负荷。数据库CPU资源很丰富,远没有出现瓶颈。

七、IO Stats

1
Tablespace IO Stats
img
表空间的I/O性能统计。

  • Reads
    发生了多少次物理读。

  • Av Reads/s
    每秒钟物理读的次数。

  • Av Rd(ms)
    平均一次物理读的时间(毫秒)。一个高相应的磁盘的响应时间应当在10ms以内,最好不要超过20ms;如果达到了100ms,应用基本就开始出现严重问题甚至不能正常运行。

  • Av Blks/Rd
    每次读多少个数据块。

  • Writes
    发生了多少次写。

  • Av Writes/s
    每秒钟写的次数。

  • Buffer Waits
    获取内存数据块等待的次数。

  • Av Buf Wt(ms)
    获取内存数据块平均等待时间。
    2
    File IO Stats
    img
    文件级别的I/O统计。

八、Advisory Statistics

顾问信息。这块提供了多种顾问程序,提出在不同情况下的模拟情况。包括databuffer、pga、shared pool、sga、stream pool、java pool等的情况。
1
Buffer Pool Advisory
img
Buffer pool的大小建议。

  • Size for Est (M)
    Oracle估算Buffer pool的大小。

  • Size Factor
    估算值与实际值的比例。如果0.9就表示估算值是实际值的0.9倍。1.0表示buffer pool的实际大小。

  • Buffers for Estimate
    估算的Buffer的大小(数量)。

  • Est Phys Read Factor
    估算的物理读的影响因子,是估算物理读和实际物理读的一个比例。1.0表示实际的物理读。

  • Estimated Physical Reads
    估计的物理读次数。
    2
    PGA Memory Advisory
    img
    PGA的大小建议。

  • PGA Target Est (MB)
    PGA的估算大小。

  • Size Factr
    影响因子,作用和buffer pool advisory中相同。

  • W/A MB Processed
    Oracle为了产生影响估算处理的数据量。

  • Estd Extra W/A MB Read/ Written to Disk
    处理数据中需要物理读写的数据量。

  • Estd PGA Cache Hit %
    估算的PGA命中率。

  • Estd PGA Overalloc Count
    需要在估算的PGA大小下额外分配内存的个数。
    3
    Shared Pool Advisory
    img
    建议器通过设置不同的共享池大小,来获取相应的性能指标值。

  • Shared Pool Size(M)
    估算的共享池大小。

  • SP Size Factr
    共享池大小的影响因子。

  • Est LC Size (M)
    估算的库高速缓存占用的大小。

  • Est LC Mem Obj
    高速缓存中的对象数。

  • Est LC Time Saved (s)
    需要额外将对象读入共享池的时间。

  • Est LC Time Saved Factr
    对象读入共享池时间的影响因子。
    表示每一个模拟的shared pool大小对重新将对象读入共享池的影响情况。当这个值的变化很小或不变的时候,增加shared pool的大小就意义不大。

  • Est LC Load Time (s)
    分析所花费的时间。

  • Est LC Load Time Factr
    分析花费时间的影响因子。

  • Est LC Mem Obj Hits
    内存中对象被发现的次数。
    4
    SGA Target Advisory
    img
    建议器对SGA整体的性能的一个建议。

  • SGA Target Size (M)
    估算的SGA大小。

  • SGA Size Factor
    SGA大小的影响因子。

  • Est DB Time (s)
    估算的SGA大小计算出的DB Time。

  • Est Physical Reads
    物理读的次数。

九、Latch Statistics

1
Latch Activity
img

  • Get Requests/Pct Get Miss/Avg Slps /Miss
    表示愿意等待类型的latch的统计信息。

  • NoWait Requests/Pct NoWait Miss
    表示不愿意等待类型的latch的统计信息。

  • Pct Misses
    比例最好接近0。

十、Segment Statistics

1
Segments by Logical Reads
img
段的逻辑读情况。
2
Segments by Physical Reads
img
段的物理读情况。
3
Segments by Buffer Busy Waits
img
从这部分可以发现那些对象访问频繁。Buffer Busy Waits事件通常由于某些数据块太过频繁的访问,导致热点块的产生。
4
Segments by Row Lock Waits
AWR报告Segment Statistics部分的Segments by Row Lock Waits,非常容易引起误解,它包含的不仅仅是事务的行级锁等待,还包括了索引分裂的等待。之前我一直抱怨为什么v$segment_statistics中没有统计段级别的索引分裂计数,原来ORACLE已经实现了。但是统计进这个指标中,你觉得合适吗?

十一、其他问题

SQL运行周期对报告的影响
对SQL语句来讲,只有当它执行完毕之后,它的相关信息才会被Oracle所记录(比如:CPU时间、SQL执行时长等)。当时当某个SQL终止于做AWR报告选取的2个快照间隔时间之后,那么它的信息就不能被这个AWR报告反映出来。尽管它在采样周期里面的运行,也消耗了很多资源。
也就是说某个区间的性能报告并不能精确地反映出在这个采样周期中资源的消耗情况。因为有些在这个区间运行的SQL可能结束于这个时间周期之后,也可能有一些SQL在这个周期开始之前就已经运行了很久,恰好结束于这个采样周期。这些因素都导致了采样周期里面的数据并不绝对是这个时间段发生的所有数据库操作的资源使用的数据。

其它

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

WORKLOAD REPOSITORY report for

DB NameDB IdInstanceInst numReleaseRACHost
ICCI1314098396ICCI1110.2.0.3.0YESHPGICCI1


Snap IdSnap TimeSessionsCursors/Session
Begin Snap:267825-Dec-08 14:04:50241.5
End Snap:268025-Dec-08 15:23:37261.5
Elapsed:78.79 (mins)
DB Time:11.05 (mins)

DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于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就共有608=480分钟,DB time为466.37分钟
则:cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)
也就是说cpu有 466.37/480
100% 花费在处理Oracle的操作上,这还不包括后台进程
看Report B,总共约60分钟,cpu有 19.49/480*100% 花费在处理Oracle的操作上
很显然,Report B中服务器的平均负载很低。
从awr report的Elapsed time和DB Time就能大概了解db的负载。

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

Report Summary

Cache Sizes

BeginEnd
Buffer Cache:3,344M3,344MStd Block Size:8K
Shared Pool Size:704M704MLog Buffer:14,352K

显示SGA中每个区域的大小(在AMM改变它们之后),可用来与初始参数值比较。

shared pool主要包括library cache和dictionary cache。
library cache用来存储最近解析(或编译)后SQL、PL/SQL和Java classes等。
dictionary cache用来存储最近引用的数据字典。
发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。
因此shared pool的设置要确保最近使用的数据都能被cache。

Load Profile

Per SecondPer Transaction
Redo size:918,805.72775,912.72
Logical reads:3,521.772,974.06
Block changes:1,817.951,535.22
Physical reads:68.2657.64
Physical writes:362.59306.20
User calls:326.69275.88
Parses:38.6632.65
Hard parses:0.030.03
Sorts:0.610.51
Logons:0.010.01
Executes:354.34299.23
Transactions:1.18
% Blocks changed per Read:51.62Recursive Call %:51.72
Rollback per transaction %:85.49Rows per Sort:########

显示数据库负载概况,将之与基线数据比较才具有更多的意义,如果每秒或每事务的负载变化不大,说明应用运行比较稳定。
单个的报告数据只说明应用的负载情况,绝大多数据并没有一个所谓“正确”的值,然而
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_cache。
在这里,fast parse指的是直接在PGA中命中的情况(设置了session_cached_cursors=n);
soft parse是指在shared pool中命中的情形;hard parse则是指都不命中的情况。

Hard parses:其中硬解析的次数,硬解析太多,说明SQL重用率不高。
每秒产生的硬解析次数, 每秒超过100次,就可能说明你绑定使用的不好,也可能是共享池设置不合理。
这时候可以启用参数cursor_sharing=similar|force,该参数默认值为exact。但该参数设置为similar时,存在bug,可能导致执行计划的不优。

Sorts:每秒/每事务的排序次数

Logons:每秒/每事务登录的次数

Executes:每秒/每事务SQL执行次数

Transactions:每秒事务数.每秒产生的事务数,反映数据库任务繁重与否。

Blocks changed per Read:表示逻辑读用于修改数据块的比例.在每一次逻辑读中更改的块的百分比。

Recursive Call:递归调用占所有操作的比率.递归调用的百分比,如果有很多PL/SQL,那么这个值就会比较高。

Rollback per transaction:每事务的回滚率.看回滚率是不是很高,因为回滚很耗资源 ,如果回滚率过高,
可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争
该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。

Rows per Sort:每次排序的行数

注:

Oracle的硬解析和软解析

  提到软解析(soft prase)和硬解析(hard prase),就不能不说一下Oracle对sql的处理过程。
当你发出一条sql语句交付Oracle,在执行和获取结果前,Oracle对此sql将进行几个步骤的处理过程:

  1、语法检查(syntax check)

  检查此sql的拼写是否语法。

  2、语义检查(semantic check)

  诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。

  3、对sql语句进行解析(prase)

  利用内部算法对sql进行解析,生成解析树(parse tree)及执行计划(execution plan)。

  4、执行sql,返回结果(execute and return)

  其中,软、硬解析就发生在第三个过程里。

  Oracle利用内部的hash算法来取得该sql的hash值,然后在library cache里查找是否存在该hash值;

  假设存在,则将此sql与cache中的进行比较;

  假设“相同”,就将利用已有的解析树与执行计划,而省略了优化器的相关工作。这也就是软解析的过程。

  诚然,如果上面的2个假设中任有一个不成立,那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。

创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作,所以,应当极力避免硬解析,尽量使用软解析。

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:100.00Redo NoWait %:100.00
Buffer Hit %:98.72In-memory Sort %:99.86
Library Hit %:99.97Soft Parse %:99.92
Execute to Parse %:89.09Latch Hit %:99.99
Parse CPU to Parse Elapsd %:7.99% Non-Parse CPU:99.95

本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio,
Library Hit ratio也称Library Cache Hit ratio。
同Load Profile一节相同,这一节也没有所谓“正确”的值,而只能根据应用的特点判断是否合适。
在一个使用直接读执行大型并行查询的DSS环境,20%的Buffer Hit Ratio是可以接受的,而这个值对于一个OLTP系统是完全不能接受的。
根据Oracle的经验,对于系统,Buffer Hit Ratio理想应该在90%以上。

Buffer Nowait表示在内存获得数据的未等待比例。在缓冲区中获取Buffer的未等待比率
Buffer Nowait的这个值一般需要大于99%。否则可能存在争用,可以在后面的等待事件中进一步确认。

buffer hit表示进程从内存中找到数据块的比率,监视这个值是否发生重大变化比这个值本身更重要。
对于一般的OLTP系统,如果此值低于80%,应该给数据库分配更多的内存。
数据块在数据缓冲区中的命中率,通常应在95%以上。否则,小于95%,需要调整重要的参数,小于90%可能是要加db_cache_size。
一个高的命中率,不一定代表这个系统的性能是最优的,比如大量的非选择性的索引被频繁访问,就会造成命中率很高的假相(大量的db file sequential read)
但是一个比较低的命中率,一般就会对这个系统的性能产生影响,需要调整。命中率的突变,往往是一个不好的信息。
如果命中率突然增大,可以检查top buffer get SQL,查看导致大量逻辑读的语句和索引,
如果命中率突然减小,可以检查top physical reads SQL,检查产生大量物理读的语句,主要是那些没有使用索引或者索引被删除的。


Redo NoWait
表示在LOG缓冲区获得BUFFER的未等待比例。如果太低(可参考90%阀值),考虑增加LOG BUFFER。
当redo buffer达到1M时,就需要写到redo log文件,所以一般当redo buffer设置超过1M,不太可能存在等待buffer空间分配的情况。
当前,一般设置为2M的redo buffer,对于内存总量来说,应该不是一个太大的值。


library hit
表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率,当应用程序调用SQL或存储过程时,
Oracle检查Library Cache确定是否存在解析过的版本,如果存在,Oracle立即执行语句;如果不存在,Oracle解析此语句,并在Library Cache中为它分配共享SQL区。
低的library hit ratio会导致过多的解析,增加CPU消耗,降低性能。
如果library hit ratio低于90%,可能需要调大shared pool区。
STATEMENT在共享区的命中率,通常应该保持在95%以上,否则需要要考虑:加大共享池;使用绑定变量;修改cursor_sharing等参数。


Latch Hit**
:**Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。
要确保Latch Hit>99%,否则意味着Shared Pool latch争用,可能由于未共享的SQL,或者Library Cache太小,可使用绑定变更或调大Shared Pool解决。
要确保>99%,否则存在严重的性能问题。当该值出现问题的时候,我们可以借助后面的等待时间和latch分析来查找解决问题。


Parse CPU to Parse Elapsd**
:*解析实际运行时间/(解析实际运行时间+解析中等待资源时间),越高越好。
计算公式为:Parse CPU to Parse Elapsd %= 100
(parse time cpu / parse time elapsed)。
即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%,意味着CPU等待时间为0,没有任何等待。


Non-Parse CPU
SQL实际运行时间/(SQL实际运行时间+SQL解析时间),太低表示解析消耗时间过多。
计算公式为:% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小,表示解析消耗的CPU时间过多。
与PARSE_CPU相比,如果TOT_CPU很高,这个比值将接近100%,这是很好的,说明计算机执行的大部分工作是执行查询的工作,而不是分析查询的工作。


Execute to Parse**
:*是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
计算公式为:Execute to Parse =100
(1 - Parses/Executions)。
本例中,差不多每execution 5次需要一次parse。所以如果系统Parses > Executions,就可能出现该比率小于0的情况。
该值<0通常说明shared pool设置或者语句效率存在问题,造成反复解析,reparse可能较严重,或者是可能同snapshot有关,通常说明数据库性能存在问题。


In-memory Sort**
:**在内存中排序的比率,如果过低说明有大量的排序在临时表空间中进行。
考虑调大PGA(10g)。如果低于95%,可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决,
注意这两个参数设置作用的范围时不同的,SORT_AREA_SIZE是针对每个session设置的,PGA_AGGREGATE_TARGET则时针对所有的sesion的。


Soft Parse**
:**软解析的百分比(softs/softs+hards),近似当作sql在共享区的命中率,太低则需要调整应用使用绑定变量。
sql在共享区的命中率,小于<95%,需要考虑绑定,如果低于80%,那么就可以认为sql基本没有被重用。

Shared Pool Statistics

BeginEnd
Memory Usage %:47.1947.50
% SQL with executions>1:88.4879.81
% Memory for SQL w/exec>1:79.9973.52

Memory Usage %:对于一个已经运行一段时间的数据库来说,共享池内存使用率,应该稳定在75%-90%间,
如果太小,说明Shared Pool有浪费,而如果高于90,说明共享池中有争用,内存不足。
这个数字应该长时间稳定在75%~90%。如果这个百分比太低,表明共享池设置过大,带来额外的管理上的负担,从而在某些条件下会导致性能的下降。
如果这个百分率太高,会使共享池外部的组件老化,如果SQL语句被再次执行,这将使得SQL语句被硬解析。
在一个大小合适的系统中,共享池的使用率将处于75%到略低于90%的范围内.

SQL with executions>1:执行次数大于1的sql比率,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多SQL解析。
在一个趋向于循环运行的系统中,必须认真考虑这个数字。在这个循环系统中,在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。
在共享池中,在观察期间将有一组未被执行过的SQL语句,这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组,这个数字才会接近100%。

Memory for SQL w/exec>1:执行次数大于1的SQL消耗内存的占比。
这是与不频繁使用的SQL语句相比,频繁使用的SQL语句消耗内存多少的一个度量。
这个数字将在总体上与% SQL with executions>1非常接近,除非有某些查询任务消耗的内存没有规律。
在稳定状态下,总体上会看见随着时间的推移大约有75%~85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期,
执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。

小结:通过ORACLE的实例有效性统计数据,我们可以获得大概的一个整体印象,然而我们并不能由此来确定数据运行的性能。当前性能问题的确定,
我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容,hit统计帮助我们发现和预测一些系统将要产生的性能问题,由此我们
可以做到未雨绸缪。而wait事件,就是表明当前数据库已经出现了性能问题需要解决,所以是亡羊补牢的性质。

Top 5 Timed Events

EventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait Class
CPU time51577.6
SQL*Net more data from client27,3196429.7Network
log file parallel write5,4974797.1System I/O
db file sequential read7,9003545.3User I/O
db file parallel write4,8063475.1System I/O

这是报告概要的最后一节,显示了系统中最严重的5个等待,按所占等待时间的比例倒序列示。当我们调优时,总希望观察到最显著的效果,
因此应当从这里入手确定我们下一步做什么。
例如如果‘**buffer busy wait’是较严重的等待事件,我们应当继续研究报告中Buffer Wait和File/Tablespace IO区的内容,
识别哪些文件导致了问题。如果最严重的等待事件是I/O
事件,我们应当研究按物理读排序的SQL语句区以识别哪些语句在
执行大量I/O
,并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待,就需要察看详细的LATCH
统计识别哪些LATCH**产生的问题。

一个性能良好的系统,cpu time应该在top 5的前面,否则说明你的系统大部分时间都用在等待上。

在这里,log file parallel write是相对比较多的等待,占用了7%的CPU时间。

通常,在没有问题的数据库中,CPU time总是列在第一个。

更多的等待事件,参见本报告 的Wait Events一节。

RAC Statistics

BeginEnd
Number of Instances:22

Global Cache Load Profile

Per SecondPer Transaction
Global Cache blocks received:4.163.51
Global Cache blocks served:5.975.04
GCS/GES messages received:408.47344.95
GCS/GES messages sent:258.03217.90
DBWR Fusion writes:0.050.05
Estd Interconnect traffic (KB)211.16

Global Cache Efficiency Percentages (Target local+remote 100%)

Buffer access - local cache %:98.60
Buffer access - remote cache %:0.12
Buffer access - disk %:1.28

Global Cache and Enqueue Services - Workload Characteristics

Avg global enqueue get time (ms):0.1
Avg global cache cr block receive time (ms):1.1
Avg global cache current block receive time (ms):0.8
Avg global cache cr block build time (ms):0.0
Avg global cache cr block send time (ms):0.0
Global cache log flushes for cr blocks served %:3.5
Avg global cache cr block flush time (ms):3.9
Avg global cache current block pin time (ms):0.0
Avg global cache current block send time (ms):0.0
Global cache log flushes for current blocks served %:0.4
Avg global cache current block flush time (ms):3.0

Global Cache and Enqueue Services - Messaging Statistics

Avg message sent queue time (ms):0.0
Avg message sent queue time on ksxp (ms):0.3
Avg message received queue time (ms):0.5
Avg GCS message process time (ms):0.0
Avg GES message process time (ms):0.0
% of direct sent messages:14.40
% of indirect sent messages:77.04
% of flow controlled messages:8.56

Main Report

Wait Events Statistics

Back to Top

/* oracle等待事件是衡量oracle运行状况的重要依据及指示,等待事件分为两类:
空闲等待事件和非空闲等待事件, TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序,= FALSE那么事件按等待的数量排序。
运行statspack期间必须session上设置TIMED_STATISTICS = TRUE,否则统计的数据将失真。
空闲等待事件是oracle正等待某种工作,在诊断和优化数据库时候,不用过多注意这部分事件,
非空闲等待事件专门针对oracle的活动,指数据库任务或应用程序运行过程中发生的等待,
这些等待事件是我们在调整数据库应该关注的

对于常见的等待事件,说明如下:

\1) db file scattered read 文件分散读取
该事件通常与全表扫描或者fast full index scan有关。因为全表扫描是被放入内存中进行的进行的,通常情况下基于性能的考虑,有时候也可能是分配不到足够长的连续内存空间,所以会将数据块分散(scattered)读入Buffer Cache中。该等待过大可能是缺少索引或者没有合适的索引(可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的,因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时,需要通过检查来确定全表扫描是否必需的来调整。因为全表扫描被置于LRU(Least Recently Used,最近最少适用)列表的冷端(cold end),对于频繁访问的较小的数据表,可以选择把他们Cache 到内存中,以避免反复读取。当这个等待事件比较显著时,可以结合v$session_longops 动态性能视图来进行诊断,该视图中记录了长时间(运行时间超过6 秒的)运行的事物,可能很多是全表扫描操作(不管怎样,这部分信息都是值得我们注意的)。
关于参数OPTIMIZER_INDEX_COST_ADJ=n:该参数是一个百分比值,缺省值为100,可以理解为FULL SCAN COST/INDEX SCAN COST。当n%* INDEX SCAN COST<FULL SCAN COST时,oracle会选择使用索引。在具体设置的时候,我们可以根据具体的语句来调整该值。如果我们希望某个statement使用索引,而实际它确走全表扫描,可以对比这两种情况的执行计划不同的COST,从而设置一个更合适的值。

\2) db file sequential read 文件顺序读取整代码,特别是表连接:该事件说明在单个数据块上大量等待,该值过高通常是由于表间连接顺序很糟糕(没有正确选择驱动行源),或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的,并确保多表连接的连接顺序来调整。

\3) buffer busy wait 缓冲区忙 增大DB_CACHE_SIZE,加速检查点,调整代码:

当进程需要存取SGA中的buffer的时候,它会依次执行如下步骤的操作:

当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待。该值不应该大于1%。当出 现等待问题时,可以检查缓冲等待统计部分(或V$WAITSTAT),确定该等待发生在什么位置:

a) 如果等待是否位于段头(Segment Header)。这种情况表明段中的空闲列表(freelist)的块比较少。可以考虑增加空闲列表(freelist,对于Oracle8i DMT)或者增加freelist groups(在很多时候这个调整是立竿见影的(alter table tablename strorage(freelists 2)),在8.1.6之前,这个freelists参数不能动态修改;在8.1.6及以后版本,动态修改feelists需要设置COMPATIBLE至少为8.1.6)。也可以增加PCTUSED与PCTFREE之间距离(PCTUSED-to-pctfree gap),其实就是说降低PCTUSED的值,尽快使块返回freelist列表被重用。如果支持自动段空间管理(ASSM),也可以使用ASSM模式,这是在ORALCE 920以后的版本中新增的特性。

b) 如果这一等待位于undo header,可以通过增加回滚段(rollback segment)来解决缓冲区的问题。

c) 如果等待位于undo block上,我们需要增加提交的频率,使block可以尽快被重用;使用更大的回滚段;降低一致读所选择的表中数据的密度;增大DB_CACHE_SIZE。

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

d) 如果等待处于data block,表明出现了hot block,可以考虑如下方法解决: ①将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布(可以增大pctfree值 ,扩大数据分布,减少竞争),以避开这个"热点"数据块。②也可以减小数据块的大小,从而减少一个数据块中的数据行数,降低数据块的热度,减小竞争;③检查对这些热块操作的SQL语句,优化语句。④增加hot block上的initrans值。但注意不要把initrans值设置的过于高了,通常设置为5就足够了。因为增加事务意味着要增加ITL事务槽,而每个ITL事务槽将占用数据块中24个字节长度。默认情况下,每个数据块或者索引块中是ITL槽是2个,在增加initrans的时候,可以考虑增大数据块所在的表的PCTFREE值,这样Oracle会利用PCTFREE部分的空间增加ITL slot数量,最大达到maxtrans指定。

e) 如果等待处于index block,应该考虑重建索引、分割索引或使用反向键索引。为了防止与数据块相关的缓冲忙等待,也可以使用较小的块,在这种情况下,单个块中的记录就较少,所以这个块就不是那么"繁忙"。或者可以设置更大的PCTFREE,使数据扩大物理分布,减少记录间的热点竞争。在执行DML (insert/update/ delete)时,Oracle向数据块中写入信息,对于多事务并发访问的数据表,关于ITL的竞争和等待可能出现,为了减少这个等待,可以增加initrans,使用多个ITL槽。在Oracle9i 中,可以使用ASSM这个新特性Oracle 使用位图来管理空间使用,减小争用。

当进程需要存取SGA中的buffer的时候,它会依次执行如下步骤的操作:
1.获得cache buffers chains latch,遍历那条buffer chain直到找到需要的buffer header
2.根据需要进行的操作类型(读或写),它需要在buffer header上获得一个共享或独占模式的buffer pin或者buffer lock
3.若进程获得buffer header pin,它会释放获得的cache buffers chains latch,然后执行对buffer block的操作
4.若进程无法获得buffer header pin,它就会在buffer busy waits事件上等待

进程之所以无法获得buffer header pin,是因为为了保证数据的一致性,同一时刻一个block只能被一个进程pin住进行存取,
因此当一个进程需要存取buffer cache中一个被其他进程使用的block的时候,这个进程就会产生对该block的buffer busy waits事件。

截至 9i,buffer busy waits事件的p1,p2,p3三个参数分别是file#,block#和id,分别表示等待的buffer block所在的文件编号,
块编号和具体的等待原因编号,到了Oracle ,前两个参数没变,第3个参数变成了块类型编号,这一点可以通过查询v$event_name视图来进行验证:

Oracle 9i
> select parameter1,parameter2,parameter3 from v$event_name where name='buffer busy waits'
PARAMETER1 PARAMETER2 PARAMETER3


file# block# id
Oracle 10g
PARAMETER1 PARAMETER2 PARAMETER3


file# block# class#

在诊断buffer busy waits事件的过程中,获取如下信息会很有用:
1.获取产生buffer busy waits事件的等待原因编号,这可以通过查询该事件的p3参数值获得
2.获取产生此事件的SQL语句,可以通过如下的查询获得:
select sql_text from v$sql t1,v$session t2,v$session_wait t3
where t1.address=t2.sql_address and t1.hash_value=t2.sql_hash_value
and t2.sid=t3.sid and t3.event='buffer busy waits';
3.获取等待的块的类型以及所在的segment,可以通过如下查询获得:

select 'Segment Header' class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait b
where a.header_file=b.p1 and a.header_block=b.p2 and b.event='buffer busy waits'
union
select 'Freelist Groups' class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait b
where a.header_file=b.p1 and b.p2 between a.header_block+1 and (a.header_block+a.freelist_groups) and a.freelist_groups>1 and b.event='buffer busy waits'
union
select a.segment_type||' block' class,a.segment_type,a.segment_name,a.partition_name from dba_extents a,v$session_wait b
where a.file_id=b.p1 and b.p2 between a.block_id and a.block_id+a.blocks-1 and b.event='buffer busy waits' and not exists(select 1 from dba_segments where
header_file=b.p1 and header_block= b.p2);

查询的第一部分:如果等待的块类型是segment header,那么可以直接拿buffer busy waits事件的p1和p2参数去dba_segments视图中匹配header_file和header_block字段即可找到等待的segment名称和segment类型,进行相应调整
查询的第二部分:如果等待的块类型是freelist groups,也可以在dba_segments视图中找出对应的segment名称和segment类型,注意这里的参数p2表示的freelist groups的位置是在segment的header_block+1到header_block+freelist groups组数之间,并且freelist groups组数大于1
查询的第三部分:如果等待的块类型是普通的数据块,那么可以用p1、p2参数和dba_extents进行联合查询得到block所在的segment名称和segment类型

对于不同的等待块类型,我们采取不同的处理办法:
1.data segment header:
进程经常性的访问 segment header通常有两个原因:获取或修改process freelists信息、扩展高水位标记,针对第一种情况,进程频繁访问process freelists信息导致freelist争用,我们可以增大相应的segment对象的存储参数freelist或者freelist groups;若由于数据块频繁进出freelist而导致进程经常要修改freelist,则可以将pctfree值和pctused值设置较大的差距,从而避免数据块频繁进出freelist;对于第二种情况,由于该segment空间消耗很快,而设置的next extent过小,导致频繁扩展高水位标记,解决的办法是增大segment对象的存储参数next extent或者直接在创建表空间的时候设置extent size uniform
2.data block:
某一或某些数据块被多个进程同时读写,成为热点块,可以通过如下这些办法来解决这个问题:
(1)降低程序的并发度,如果程序中使用了parallel查询,降低parallel degree,以免多个parallel slave同时访问同样的数据对象而形成等待降低性能
(2)调整应用程序使之能读取较少的数据块就能获取所需的数据,减少buffer gets和physical reads
(3)减少同一个block中的记录数,使记录分布于更多的数据块中,这可以通过若干途径实现:可以调整segment对象的pctfree值,可以将segment重建到block size较小的表空间中,还可以用alter table minimize records_per_block语句减少每块中的记录数
(4)若热点块对象是类似自增id字段的索引,则可以将索引转换为反转索引,打散数据分布,分散热点块
3.undo segment header:
undo segment header争用是因为系统中undo segment不够,需要增加足够的undo segment,根据undo segment的方法,若是手工管理模式,需要修改rollback_segments初始化参数来增加rollback segment,若是自动管理模式,可以减小transactions_per_rollback_segment初始化参数的值来使oracle自动增多rollback segment的数量
4.undo block:
undo block争用是由于应用程序中存在对数据的读和写同时进行,读进程需要到undo segment中去获得一致性数据,解决办法是错开应用程序修改数据和大量查询数据的时间

小结:buffer busy waits事件是oracle中比较复杂的一个,其形成原因很多,需要根据p3参数对照Oracle提供的原因代码表进行相应的诊断,10g以后则需要根据等待的block类型结合引起等待时间的具体SQL进行分析,采取相应的调整措施

\4) latch free:当闩锁丢失率高于0.5%时,需要调整这个问题。详细的我们在后面的Latch Activity for DB部分说明。

latch是一种低级排队机制,用于保护SGA中共享内存结构。latch就像是一种快速地被获取和释放的内存锁。用于防止共享内存结构被多个用户同时访问。如果latch不可用,就会记录latch释放失败(latch free miss )。有两种与闩有关的类型:

  ■ 立刻。

  ■ 可以等待。

  假如一个进程试图在立刻模式下获得闩,而该闩已经被另外一个进程所持有,如果该闩不能立可用的话,那么该进程就不会为获得该闩而等待。它将继续执行另一个操作。

  大多数latch问题都与以下操作相关:

  没有很好的是用绑定变量(library cache latch)、重作生成问题(redo allocation latch)、缓冲存储竞争问题(cache buffers LRU chain),以及buffer cache中的存在"热点"块(cache buffers chain)。

  通常我们说,如果想设计一个失败的系统,不考虑绑定变量,这一个条件就够了,对于异构性强的系统,不使用绑定变量的后果是极其严重的。

  另外也有一些latch等待与bug有关,应当关注Metalink相关bug的公布及补丁的发布。当latch miss ratios大于0.5%时,就应当研究这一问题。

  Oracle的latch机制是竞争,其处理类似于网络里的CSMA/CD,所有用户进程争夺latch, 对于愿意等待类型(willing-to-wait)的latch,如果一个进程在第一次尝试中没有获得latch,那么它会等待并且再尝试一次,如果经过_spin_count次争夺不能获得latch, 然后该进程转入睡眠状态,持续一段指定长度的时间,然后再次醒来,按顺序重复以前的步骤.在8i/9i中默认值是_spin_count=2000。

  如果SQL语句不能调整,在8.1.6版本以上,Oracle提供了一个新的初始化参数: CURSOR_SHARING可以通过设置CURSOR_SHARING = force 在服务器端强制绑定变量。设置该参数可能会带来一定的副作用,对于Java的程序,有相关的bug,具体应用应该关注Metalink的bug公告。

**Latch 问题及可能解决办法
------------------------------
* Library Cache and Shared Pool (未绑定变量---绑定变量,调整shared_pool_size)
每当执行SQL或PL/SQL存储过程,包,函数和触发器时,这个Latch即被用到.Parse操作中此Latch也会被频繁使用.
* Redo Copy (增大_LOG_SIMULTANEOUS_COPIES参数)
重做拷贝Latch用来从PGA向重做日志缓冲区拷贝重做记录.
* Redo Allocation (最小化REDO生成,避免不必要提交)
此Latch用来分配重做日志缓冲区中的空间,可以用NOLOGGING来减缓竞争.
* Row Cache Objects (增大共享池)
数据字典竞争.过度parsing.
* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS应增大或设为质数)
"过热"数据块造成了内存缓冲链Latch竞争.
\
Cache Buffers Lru Chain (调整SQL,设置DB_BLOCK_LRU_LATCHES,或使用多个缓冲区池)
扫描全部内存缓冲区块的LRU(最近最少使用)链时要用到内存缓冲区LRU链Latch.太小内存缓冲区、过大的内存缓冲区吞吐量、过多的内存中进行的排序操作、DBWR速度跟不上工作负载等会引起此Latch竞争。

\5) Enqueue 队列是一种锁,保护一些共享资源,防止并发的DML操作。队列采用FIFO策略,注意latch并不是采用的FIFO机制。比较常见的有3种类型的队列:ST队列,HW队列,TX4队列。
ST Enqueue的等待主要是在字典管理的表空间中进行空间管理和分配时产生的。解决方法:1)将字典管理的表空间改为本地管理模式 2)预先分配分区或者将有问题的字典管理的表空间的next extent设置大一些。
HW Enqueue是用于segment的HWM的。当出现这种等待的时候,可以通过手工分配extents来解决。
TX4 Enqueue等待是最常见的等待情况。通常有3种情况会造成这种类型的等待:1)唯一索引中的重复索引。解决方法:commit或者rollback以释放队列。 2)对同一个位图索引段(bitmap index fragment)有多个update,因为一个bitmap index fragment可能包含了多个rowid,所以当多个用户更新时,可能一个用户会锁定该段,从而造成等待。解决方法同上。3)有多个用户同时对一个数据块作update,当然这些DML操作可能是针对这个数据块的不同的行,如果此时没有空闲的ITL槽,就会产生一个block-level锁。解决方法:增大表的initrans值使创建更多的ITL槽;或者增大表的pctfree值,这样oracle可以根据需要在pctfree的空间创建更多的ITL槽;使用smaller block size,这样每个块中包含行就比较少,可以减小冲突发生的机会。

AWR**报告分析--等待事件-队列.doc**

\6) Free Buffer 释放缓冲区:这个等待事件表明系统正在等待内存中的可用空间,这说明当前Buffer 中已经没有Free 的内存空间。如果应用设计良好,SQL 书写规范,充分绑定变量,那这种等待可能说明Buffer Cache 设置的偏小,你可能需要增大DB_CACHE_SIZE。该等待也可能说明DBWR的写出速度不够,或者磁盘存在严重的竞争,可以需要考虑增加检查点、使用更多的DBWR 进程,或者增加物理磁盘的数量,分散负载,平衡IO。

\7) Log file single write:该事件仅与写日志文件头块相关,通常发生在增加新的组成员和增进序列号时。头块写单个进行,因为头块的部分信息是文件号,每个文件不同。更新日志文件头这个操作在后台完成,一般很少出现等待,无需太多关注。

\8) log file parallel write:从log buffer 写redo 记录到redo log 文件,主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员,当flush log buffer 时,写操作是并行的,这时候此等待事件可能出现。尽管这个写操作并行处理,直到所有I/O 操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE,那么即使只有一个redo log file member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率。改善这个等待的方法是将redo logs放到I/O快的盘中,尽量不使用raid5,确保表空间不是处在热备模式下,确保redo log和data的数据文件位于不同的磁盘中。

\9) log file sync:当一个用户提交或回滚数据时,LGWR将会话的redo记录从日志缓冲区填充到日志文件中,用户的进程必须等待这个填充工作完成。在每次提交时都出现,如果这个等待事件影响到数据库性能,那么就需要修改应用程序的提交频率, 为减少这个等待事件,须一次提交更多记录,或者将重做日志REDO LOG 文件访在不同的物理磁盘上,提高I/O的性能。

当一个用户提交或回滚数据时,LGWR 将会话期的重做由日志缓冲器写入到重做日志中。日志文件同步过程必须等待这一过程成功完成。为了减少这种等待事件,可以尝试一次提交更多的记录(频繁的提交会带来更多的系统开销)。将重做日志置于较快的磁盘上,或者交替使用不同物理磁盘上的重做日志,以降低归档对LGWR的影响。

  对于软RAID,一般来说不要使用RAID 5,RAID5 对于频繁写入得系统会带来较大的性能损失,可以考虑使用文件系统直接输入/输出,或者使用裸设备(raw device),这样可以获得写入的性能提高。

\10) log buffer space:日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小,增加日志缓冲区的大小,或者使用更快的磁盘来写数据。

当你将日志缓冲(log buffer)产生重做日志的速度比LGWR 的写出速度快,或者是当日志切换(log switch)太慢时,就会发生这种等待。这个等待出现时,通常表明redo log buffer 过小,为解决这个问题,可以考虑增大日志文件的大小,或者增加日志缓冲器的大小。

  另外一个可能的原因是磁盘I/O 存在瓶颈,可以考虑使用写入速度更快的磁盘。在允许的条件下设置可以考虑使用裸设备来存放日志文件,提高写入效率。在一般的系统中,最低的标准是,不要把日志文件和数据文件存放在一起,因为通常日志文件只写不读,分离存放可以获得性能提升。

\11) logfile switch:通常是因为归档速度不够快。表示所有的提交(commit)的请求都需要等待"日志文件切换"的完成。Log file Switch 主要包含两个子事件:
log file switch (archiving needed) 这个等待事件出现时通常是因为日志组循环写满以后,第一个日志归档尚未完成,出现该等待。出现该等待,可能表示io 存在问题。解决办法:①可以考虑增大日志文件和增加日志组;②移动归档文件到快速磁盘;③调整log_archive_max_processes。
log file switch (checkpoint incomplete) 当日志组都写完以后,LGWR 试图写第一个log file,如果这时数据库没有完成写出记录在第一个log file 中的dirty 块时(例如第一个检查点未完成),该等待事件出现。该等待事件通常表示你的DBWR 写出速度太慢或者IO 存在问题。为解决该问题,你可能需要考虑增加额外的DBWR 或者增加你的日志组或日志文件大小,或者也可以考虑增加checkpoint的频率。

\12) DB File Parallel Write:文件被DBWR并行写时发生。解决办法:改善IO性能。

处理此事件时,需要注意

1)db file parallel write事件只属于DBWR进程。

2)缓慢的DBWR可能影响前台进程。

3)大量的db file parallel write等待时间很可能是I/O问题引起的。(在确认os支持异步io的前提下,你可以在系统中检查disk_asynch_io参数,保证为TRUE。可以通过设置db_writer_processes来提高DBWR进程数量,当然前提是不要超过cpu的数量。)
DBWR进程执行经过SGA的所有写入,当开始写入时,DBWR进程编译一组脏块(dirty block),并且将系统写入调用发布到操作系统。DBWR进程查找在各个时间内写入的块,包括每隔3秒的一次查找,当前台进程提交以清除缓冲区中的内容时:在检查点处查找,当满足_DB_LARGE_DIRTY_QUEUE、_DB_BLOCK_MAX_DIRTY_TARGET和FAST_START_MTTR_TARGET阀值时,等等。
虽然用户会话从来没有经历过db file parallel write等待事件,但这并不意味着它们不会受到这种事件的影响。缓慢的DBWR写入性能可以造成前台会话在write complete waits或free buffer waits事件上等待。DBWR写入性能可能受到如下方面的影响:I/O操作的类型(同步或异步)、存储设备(裸设备或成熟的文件系统)、数据库布局和I/O子系统配置。需要查看的关键数据库统计是当db file parallel write、free buffer waits和write complete waits等待事件互相关联时,系统范围内的TIME_WAITED和AVERAGE_WAIT。
如果db file parallel write平均等待时间大于10cs(或者100ms),则通常表明缓慢的I/O吞吐量。可以通过很多方法来改善平均等待时间。主要的方法是使用正确类型的I/O操作。如果数据文件位于裸设备(raw device)上,并且平台支持异步I/O,就应该使用异步写入。但是,如果数据库位于文件系统上,则应该使用同步写入和直接I/O(这是操作系统直接I/O)。除了确保正在使用正确类型的I/O操作,还应该检查你的数据库布局并使用常见的命令监控来自操作系统的I/O吞吐量。例如sar -d或iostat -dxnC。
当db file parallel write平均等待时间高并且系统繁忙时,用户会话可能开始在free buffer waits事件上等待。这是因为DBWR进程不能满足释放缓冲区的需求。如果free buffer waits事件的TIME_WAITED高,则应该在高速缓存中增加缓冲区数量之前说明DBWR I/O吞吐量的问题。
高db file parallel write平均等待时间的另一个反响是在write complete waits等待事件上的高TIME_WAITED。前台进程不允许修改正在传输到磁盘的块。换句话说,也就是位于DBWR批量写入中的块。前台的会话在write complete waits等待事件上等待。因此,write complete waits事件的出现,一定标志着缓慢的DBWR进程,可以通过改进DBWR I/O吞吐量修正这种延迟。

\13) DB File Single Write:当文件头或别的单独块被写入时发生,这一等待直到所有的I/O调用完成。解决办法:改善IO性能。

\14) DB FILE Scattered Read:当扫描整个段来根据初始化参数db_file_multiblock_read_count读取多个块时发生,因为数据可能分散在不同的部分,这与分条或分段)相关,因此通常需要多个分散的读来读取所有的数据。等待时间是完成所有I/O调用的时间。解决办法:改善IO性能。

这种情况通常显示与全表扫描相关的等待。
当数据库进行全表扫时,基于性能的考虑,数据会分散(scattered)读入Buffer Cache。如果这个等待事件比较显著,可能说明对于某些全表扫描的表,没有创建索引或者没有创建合适的索引,我们可能需要检查这些数据表已确定是否进行了正确的设置。

然而这个等待事件不一定意味着性能低下,在某些条件下Oracle会主动使用全表扫描来替换索引扫描以提高性能,这和访问的数据量有关,在CBO下Oracle会进行更为智能的选择,在RBO下Oracle更倾向于使用索引。

因为全表扫描被置于LRU(Least Recently Used,最近最少适用)列表的冷端(cold end),对于频繁访问的较小的数据表,可以选择把他们Cache到内存中,以避免反复读取。

当这个等待事件比较显著时,可以结合v$session_longops动态性能视图来进行诊断,该视图中记录了长时间(运行时间超过6秒的)运行的事物,可能很多是全表扫描操作(不管怎样,这部分信息都是值得我们注意的)。

\15) DB FILE Sequential Read:当前台进程对数据文件进行常规读时发生,包括索引查找和别的非整段扫描以及数据文件块丢弃等待。等待时间是完成所有I/O调用的时间。解决办法:改善IO性能。

如果这个等待事件比较显著,可能表示在多表连接中,表的连接顺序存在问题,没有正确地使用驱动表;或者可能索引的使用存在问题,并非索引总是最好的选择。在大多数情况下,通过索引可以更为快速地获取记录,所以对于编码规范、调整良好的数据库,这个等待事件很大通常是正常的。有时候这个等待过高和存储分布不连续、连续数据块中部分被缓存有关,特别对于DML频繁的数据表,数据以及存储空间的不连续可能导致过量的单块读,定期的数据整理和空间回收有时候是必须的。

需要注意在很多情况下,使用索引并不是最佳的选择,比如读取较大表中大量的数据,全表扫描可能会明显快于索引扫描,所以在开发中就应该注意,对于这样的查询应该进行避免使用索引扫描。

\16) Direct Path Read:一般直接路径读取是指将数据块直接读入PGA中。一般用于排序、并行查询和read ahead操作。这个等待可能是由于I/O造成的。使用异步I/O模式或者限制排序在磁盘上,可能会降低这里的等待时间。

与直接读取相关联的等待事件。当ORACLE将数据块直接读入会话的PGA(进程全局区)中,同时绕过SGA(系统全局区)。PGA中的数据并不和其他的会话共享。即表明,读入的这部分数据该会话独自使用,不放于共享的SGA中。

在排序操作(order by/group by/union/distinct/rollup/合并连接)时,由于PGA中的SORT_AREA_SIZE空间不足,造成需要使用临时表空间来保存中间结果,当从临时表空间读入排序结果时,产生direct path read等待事件。

使用HASH连接的SQL语句,将不适合位于内存中的散列分区刷新到临时表空间中。为了查明匹配SQL谓词的行,临时表空间中的散列分区被读回到内存中(目的是为了查明匹配SQL谓词的行),ORALCE会话在direct path read等待事件上等待。

使用并行扫描的SQL语句也会影响系统范围的direct path read等待事件。在并行执行过程中,direct path read等待事件与从属查询有关,而与父查询无关,运行父查询的会话基本上会在PX Deq:Execute Reply上等待,从属查询会产生direct path read等待事件。

直接读取可能按照同步或异步的方式执行,取决于平台和初始化参数disk_asynch_io参数的值。使用异步I/O时,系统范围的等待的事件的统计可能不准确,会造成误导作用。

\17) direct path write:直接路径写该等待发生在,系统等待确认所有未完成的异步I/O 都已写入磁盘。对于这一写入等待,我们应该找到I/O 操作最为频繁的数据文件(如果有过多的排序操作,很有可能就是临时文件),分散负载,加快其写入操作。如果系统存在过多的磁盘排序,会导致临时表空间操作频繁,对于这种情况,可以考虑使用Local管理表空间,分成多个小文件,写入不同磁盘或者裸设备。

在DSS系统中,存在大量的direct path read是很正常的,但是在OLTP系统中,通常显著的直接路径读(direct path read)都意味着系统应用存在问题,从而导致大量的磁盘排序读取操作。

直接路径写(direct paht write)通常发生在Oracle直接从PGA写数据到数据文件或临时文件,这个写操作可以绕过SGA。

这类写入操作通常在以下情况被使用:
·直接路径加载;
·并行DML操作;
·磁盘排序;
·对未缓存的“LOB”段的写入,随后会记录为direct path write(lob)等待。

最为常见的直接路径写,多数因为磁盘排序导致。对于这一写入等待,我们应该找到I/O操作最为频繁的数据文件(如果有过多的排序操作,很有可能就是临时文件),分散负载,加快其写入操作。

\18) control file parallel write:当server 进程更新所有控制文件时,这个事件可能出现。如果等待很短,可以不用考虑。如果等待时间较长,检查存放控制文件的物理磁盘I/O 是否存在瓶颈。
多个控制文件是完全相同的拷贝,用于镜像以提高安全性。对于业务系统,多个控制文件应该存放在不同的磁盘上,一般来说三个是足够的,如果只有两个物理硬盘,那么两个控制文件也是可以接受的。在同一个磁盘上保存多个控制文件是不具备实际意义的。减少这个等待,可以考虑如下方法:①减少控制文件的个数(在确保安全的前提下)。②如果系统支持,使用异步IO。③转移控制文件到IO 负担轻的物理磁盘。

\19) control file sequential read
control file single write :控制文件连续读/控制文件单个写对单个控制文件I/O 存在问题时,这两个事件会出现。如果等待比较明显,检查单个控制文件,看存放位置是否存在I/O 瓶颈。

\20) library cache pin

该事件通常是发生在先有会话在运行PL/SQL,VIEW,TYPES等object时,又有另外的会话执行重新编译这些object,即先给对象加上了一个共享锁,然后又给它加排它锁,这样在加排它锁的会话上就会出现这个等待。P1,P2可与x$kglpn和x$kglob表相关
X$KGLOB (Kernel Generic Library Cache Manager Object)
X$KGLPN (Kernel Generic Library Cache Manager Object Pins)
-- 查询X$KGLOB,可找到相关的object,其SQL语句如下
(即把V$SESSION_WAIT中的P1raw与X$KGLOB中的KGLHDADR相关连)
select kglnaown,kglnaobj from X$KGLOB
where KGLHDADR =(select p1raw from v$session_wait
where event='library cache pin')
-- 查出引起该等待事件的阻塞者的sid
select sid from x$kglpn , v$session
where KGLPNHDL in
(select p1raw from v$session_wait
where wait_time=0 and event like 'library cache pin%')
and KGLPNMOD <> 0
and v$session.saddr=x$kglpn.kglpnuse
-- 查出阻塞者正执行的SQL语句
select sid,sql_text
from v$session, v$sqlarea
where v$session.sql_address=v$sqlarea.address
and sid=<阻塞者的sid>
这样,就可找到"library cache pin"等待的根源,从而解决由此引起的性能问题。

\21) library cache lock
该事件通常是由于执行多个DDL操作导致的,即在library cache object上添加一个排它锁后,又从另一个会话给它添加一个排它锁,这样在第二个会话就会生成等待。可通过到基表x$kgllk中查找其对应的对象。
-- 查询引起该等待事件的阻塞者的sid、会话用户、锁住的对象
select b.sid,a.user_name,a.kglnaobj
from x$kgllk a , v$session b
where a.kgllkhdl in
(select p1raw from v$session_wait
where wait_time=0 and event = 'library cache lock')
and a.kgllkmod <> 0
and b.saddr=a.kgllkuse
当然也可以直接从v$locked_objects中查看,但没有上面语句直观根据sid可以到v$process中查出pid,然后将其kill或者其它处理。

\22)

对于常见的一些IDLE wait事件举例:

dispatcher timer

lock element cleanup

Null event

parallel query dequeue wait

parallel query idle wait - Slaves

pipe get

PL/SQL lock timer

pmon timer- pmon

rdbms ipc message

slave wait

smon timer

SQL*Net break/reset to client

SQL*Net message from client

SQL*Net message to client

SQL*Net more data to client

virtual circuit status

client message

SQL*Net message from client

下面是关于这里的常见的等待事件和解决方法的一个快速预览

等待事件一般解决方法
Sequential Read调整相关的索引和选择合适的驱动行源
Scattered Read表明出现很多全表扫描。优化code,cache小表到内存中。
Free Buffer增大DB_CACHE_SIZE,增大checkpoint的频率,优化代码
Buffer Busy Segment header增加freelist或者freelistgroups
Buffer Busy Data block隔离热块;使用反转索引;使用更小的块;增大表的initrans
Buffer Busy Undo header增加回滚段的数量或者大小
Buffer Busy Undo blockCommit more;增加回滚段的数量或者大小
Latch Free检查具体的等待latch类型,解决方法参考后面介绍
Enqueue–ST使用本地管理的表空间或者增加预分配的盘区大小
Enqueue–HW在HWM之上预先分配盘区
Enqueue–TX4在表或者索引上增大initrans的值或者使用更小的块
Log Buffer Space增大LOG_BUFFER,改善I/O
Log File Switch增加或者增大日志文件
Log file sync减小提交的频率;使用更快的I/O;或者使用裸设备
Write complete waits增加DBWR;提高CKPT的频率;

Time Model Statistics

  • Total time in database user-calls (DB Time): 663s
  • Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic
  • Ordered by % or DB time desc, Statistic name
Statistic NameTime (s)% of DB Time
DB CPU514.5077.61
sql execute elapsed time482.2772.74
parse time elapsed3.760.57
PL/SQL execution elapsed time0.500.08
hard parse elapsed time0.340.05
connection management call elapsed time0.080.01
hard parse (sharing criteria) elapsed time0.000.00
repeated bind elapsed time0.000.00
PL/SQL compilation elapsed time0.000.00
failed parse elapsed time0.000.00
DB time662.97
background elapsed time185.19
background cpu time67.48

此节显示了各种类型的数据库处理任务所占用的CPU时间。

DB time=报表头部显示的db time=cpu time + all of nonidle wait event time

Back to Wait Events Statistics
Back to Top

Wait Class 等待事件的类型

  • s - second
  • cs - centisecond - 100th of a second
  • ms - millisecond - 1000th of a second
  • us - microsecond - 1000000th of a second
  • ordered by wait time desc, waits desc

查询Oracle 10gR1提供的12个等待事件类:

select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;

Wait ClassWaits%Time -outsTotal Wait Time (s)Avg wait (ms)Waits /txn
User I/O66,8370.00120211.94
System I/O28,2950.009335.05
Network1,571,4500.00660280.72
Cluster210,5480.0029037.61
Other81,78371.8228014.61
Application333,1550.0016059.51
Concurrency5,1820.04510.93
Commit9190.00440.16
Configuration25,42799.46104.54

Back to Wait Events Statistics
Back to Top

Wait Events 现实非空闲等待事件 后面是空闲等待事件

  • s - second
  • cs - centisecond - 100th of a second
  • ms - millisecond - 1000th of a second
  • us - microsecond - 1000000th of a second
  • ordered by wait time desc, waits desc (idle events last)

(1)查询所有等待事件及其属性:

select event#, name, parameter1, parameter2, parameter3 from v$event_name order by name;

(2)查询Oracle 10gR1提供的12个等待事件类:

select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;

wait_event.doc

下面显示的内容可能来自下面几个视图)

V$EVENT_NAME视图包含所有为数据库实例定义的等待事件。

V$SYSTEM_EVENT视图显示自从实例启动后,所有Oracle会话遇到的所有等待事件的总计统计。

V$SESSION_EVENT视图包含当前连接到实例的所有会话的总计等待事件统计。该视图包含了V$SYSTEM_EVENT视图中出现的所有列。它记录会话中每一个等待事件的总等待次数、已等待时间和最大等待时间。SID列标识出独立的会话。每个会话中每个事件的最大等待时间在MAX_WAIT列中追踪。通过用SID列将V$SESSION_EVENT视图和V$SESSION视图结合起来,可得到有关会话和用户的更多信息。

V$SESSION_WAIT视图提供关于每个会话正在等待的事件或资源的详细信息。该视图在任何给定时间,只包含每个会话的一行活动的或不活动的信息。

自从OWI在Oracle 7.0.12中引入后,就具有下来4个V$视图:

· V$EVENT_NAME

· V$SESSION_WAIT

· V$SESSION_EVENT

· V$SYSTEM_EVENT

除了这些等待事件视图之外,Oracle 10gR1中引入了下列新视图以从多个角度显示等待信息:

· V$SYSTEM_WAIT_CLASS

· V$SESSION_WAIT_CLASS

· V$SESSION_WAIT_HISTORY

· V$EVENT_HISTOGRAM

· V$ACTIVE_SESSION_HISTORY

然而,V$SESSION_WAIT、V$SESSION_WAIT和V$SESSION_WAIT仍然是3个重要的视图,它们提供了不同粒度级的等待事件统计和计时信息。三者的关系如下:

V$SESSION_WAIT ? V$SESSION_EVENT ? V$SYSTEM_EVENT

EventWaits%Time -outsTotal Wait Time (s)Avg wait (ms)Waits /txn
SQL*Net more data from client27,3190.006424.88
log file parallel write5,4970.004790.98
db file sequential read7,9000.003541.41
db file parallel write4,8060.003470.86
db file scattered read10,3100.003131.84
direct path write42,7240.003017.63
reliable message3552.8218490.06
SQL*Net break/reset to client333,0840.0016059.50
db file parallel read3,7320.001340.67
gc current multi block request175,7100.0010031.39
control file sequential read15,9740.001012.85
direct path read temp1,8730.00950.33
gc cr multi block request20,8770.00803.73
log file sync9190.00440.16
gc cr block busy5260.00360.09
enq: FB - contention10,3840.00301.85
DFS lock handle3,5170.00310.63
control file parallel write1,9460.00310.35
gc current block 2-way4,1650.00200.74
library cache lock4320.00240.08
name-service call wait220.002760.00
row cache lock3,8940.00200.70
gcs log flush sync1,25942.02210.22
os thread startup185.562890.00
gc cr block 2-way3,6710.00200.66
gc current block busy1130.001120.02
SQL*Net message to client1,544,1150.0010275.83
gc buffer busy156.671700.00
gc cr disk read3,2720.00100.58
direct path write temp1590.00150.03
gc current grant busy8980.00110.16
log file switch completion290.001170.01
CGS wait for IPC msg48,73999.87008.71
gc current grant 2-way1,1420.00000.20
kjbdrmcvtq lmon drm quiesce: ping completion90.000190.00
enq: US - contention5670.00000.10
direct path read1380.00010.02
enq: WF - contention140.00090.00
ksxr poll remote instances13,29158.45002.37
library cache pin2110.00010.04
ges global resource directory to be frozen9100.000100.00
wait for scn ack5830.00000.10
log file sequential read360.00020.01
undo segment extension25,34299.79004.53
rdbms ipc reply2790.00000.05
ktfbtgex6100.000100.00
enq: HW - contention440.00010.01
gc cr grant 2-way1580.00000.03
enq: TX - index contention10.000340.00
enq: CF - contention640.00010.01
PX Deq: Signal ACK3721.62010.01
latch free30.000100.00
buffer busy waits6250.16000.11
KJC: Wait for msg sends to complete1540.00000.03
log buffer space110.00020.00
enq: PS - contention460.00010.01
enq: TM - contention700.00000.01
IPC send completion sync40100.00000.01
PX Deq: reap credit1,54499.81000.28
log file single write360.00000.01
enq: TT - contention460.00000.01
enq: TD - KTF dump entries120.00010.00
read by other session10.000120.00
LGWR wait for redo copy5400.00000.10
PX Deq Credit: send blkd175.88000.00
enq: TA - contention140.00000.00
latch: ges resource hash list440.00000.01
enq: PI - contention80.00000.00
write complete waits10.00020.00
enq: DR - contention30.00000.00
enq: MW - contention30.00000.00
enq: TS - contention30.00000.00
PX qref latch150100.00000.03
PX qref latch在并行执行的情况下偶然会发现PX qref latch等待事件,当系统高峰期同时采用了高并发的情况下最容易出现。看来要进行特殊照顾了。概念和原理** 在并行执行环境中,query slaves 和query coordinator之间是通过队列交换数据和信息的。PX qref latch 是用来保护这些队列的。 PX qref latch 等待事件的出现一般表明信息的发送比接受快,这时需要调整buffer size(可以通过parallel_execution_message_size参数调整)。 但是有些情况下也是难以避免发生这种情况的,比如consumer需要长时间的等待数据的处理,原因在于需要返回大批量的数据包,这种情况下很正常。调整和措施* 当系统的负载比较高时,需要把并行度降低;如果使用的是默认并行度,可以通过减小parallel_thread_per_cpu参数的值来达到效果。 DEFAULT degree = PARALLEL_THREADS_PER_CPU #CPU's优化**parallel_execution_message_size**参数 Tuning parallel_execution_message_size is a tradeoff between performance and memory. For parallel query, the connection topology between slaves and QC requires (n^2 + 2n) connections (where n is the DOP not the actual number of slaves) at maximum. If each connection has 3 buffers associated with it then you can very quickly get into high memory consumption on large machines doing high DOP queries
enq: MD - contention20.00000.00
latch: KCL gc element parent latch110.00000.00
enq: JS - job run lock - synchronize10.00010.00
SQL*Net more data to client160.00000.00
latch: cache buffers lru chain10.00000.00
enq: UL - contention10.00000.00
gc current split10.00000.00
enq: AF - task serialization10.00000.00
latch: object queue header operation30.00000.00
latch: cache buffers chains10.00000.00
latch: enqueue hash chains20.00000.00
SQL*Net message from client1,544,1130.0012,6268275.83
gcs remote message634,88498.649,20314113.41
DIAG idle wait23,6280.004,6161954.22
ges remote message149,59193.454,6123126.72
Streams AQ: qmn slave idle wait1670.004,611276110.03
Streams AQ: qmn coordinator idle wait35147.864,611131370.06
Streams AQ: waiting for messages in the queue488100.004,60594360.09
virtual circuit status157100.004,596292720.03
PX Idle Wait1,07297.112,58124070.19
jobq slave wait14597.9342028960.03
Streams AQ: waiting for time management or cleanup tasks1100.002702697470.00
PX Deq: Parse Reply4040.00030.01
PX Deq: Execution Msg12126.45000.02
PX Deq: Join ACK3842.11010.01
PX Deq: Execute Reply3432.35000.01
PX Deq: Msg Fragment160.00000.00
Streams AQ: RAC qmn coordinator idle wait351100.00000.06
class slave wait20.00000.00

db file scattered read等待事件是当SESSION等待multi-block I/O时发生的,通过是由于full table scans或 index fast full scans。发生过多读操作的Segments可以在“Segments by Physical Reads”和 “SQL ordered by Reads”节中识别(在其它版本的报告中,可能是别的名称)。如果在OLTP应用中,不应该有过多的全扫描操作,而应使用选择性好的索引操作。

DB file sequential read等待意味着发生顺序I/O读等待(通常是单块读取到连续的内存区域中),如果这个等待非常严重,应该使用上一段的方法确定执行读操作的热点SEGMENT,然后通过对大表进行分区以减少I/O量,或者优化执行计划(通过使用存储大纲或执行数据分析)以避免单块读操作引起的sequential read等待。通过在批量应用中,DB file sequential read是很影响性能的事件,总是应当设法避免。

Log File Parallel Write 事件是在等待LGWR进程将REDO记录从LOG 缓冲区写到联机日志文件时发生的。虽然写操作可能是并发的,但LGWR需要等待最后的I/O写到磁盘上才能认为并行写的完成,因此等待时间依赖于OS完成所有请求的时间。如果这个等待比较严重,可以通过将LOG文件移到更快的磁盘上或者条带化磁盘(减少争用)而降低这个等待。

Buffer Busy Waits事件是在一个SESSION需要访问BUFFER CACHE中的一个数据库块而又不能访问时发生的。缓冲区“busy”的两个原因是:1)另一个SESSION正在将数据块读进BUFFER。2)另一个SESSION正在以排它模式占用着这块被请求的BUFFER。可以在“Segments by Buffer Busy Waits”一节中找出发生这种等待的SEGMENT,然后通过使用reverse-key indexes并对热表进行分区而减少这种等待事件。

Log File Sync事件,当用户SESSION执行事务操作(COMMIT或ROLLBACK等)后,会通知 LGWR进程将所需要的所有REDO信息从LOG BUFFER写到LOG文件,在用户SESSION等待LGWR返回安全写入磁盘的通知时发生此等待。减少此等待的方法写Log File Parallel Write事件的处理。

Enqueue Waits是串行访问本地资源的本锁,表明正在等待一个被其它SESSION(一个或多个)以排它模式锁住的资源。减少这种等待的方法依赖于生产等待的锁类型。导致Enqueue等待的主要锁类型有三种:TX(事务锁), TM D(ML锁)和ST(空间管理锁)。

Back to Wait Events Statistics
Back to Top

Background Wait Events

  • ordered by wait time desc, waits desc (idle events last)
EventWaits%Time -outsTotal Wait Time (s)Avg wait (ms)Waits /txn
log file parallel write5,4970.004790.98
db file parallel write4,8060.003470.86
events in waitclass Other69,00283.2522012.33
control file sequential read9,3230.00711.67
control file parallel write1,9460.00310.35
os thread startup185.562890.00
direct path read1380.00010.02
db file sequential read210.00050.00
direct path write1380.00000.02
log file sequential read360.00020.01
gc cr block 2-way960.00000.02
gc current block 2-way780.00000.01
log buffer space110.00020.00
row cache lock590.00000.01
log file single write360.00000.01
buffer busy waits1510.66000.03
gc current grant busy290.00000.01
library cache lock40.00010.00
enq: TM - contention100.00000.00
gc current grant 2-way80.00000.00
gc cr multi block request70.00000.00
gc cr grant 2-way50.00000.00
rdbms ipc message97,28873.7750,19451617.38
gcs remote message634,88698.649,20314113.41
DIAG idle wait23,6280.004,6161954.22
pmon timer1,621100.004,61528470.29
ges remote message149,59193.454,6123126.72
Streams AQ: qmn slave idle wait1670.004,611276110.03
Streams AQ: qmn coordinator idle wait35147.864,611131370.06
smon timer2776.504,531163560.05
Streams AQ: waiting for time management or cleanup tasks1100.002702697470.00
PX Deq: Parse Reply4040.00030.01
PX Deq: Join ACK3842.11010.01
PX Deq: Execute Reply3432.35000.01
Streams AQ: RAC qmn coordinator idle wait351100.00000.06

Back to Wait Events Statistics
Back to Top

Operating System Statistics

StatisticTotal
NUM_LCPUS0
NUM_VCPUS0
AVG_BUSY_TIME101,442
AVG_IDLE_TIME371,241
AVG_IOWAIT_TIME5,460
AVG_SYS_TIME25,795
AVG_USER_TIME75,510
BUSY_TIME812,644
IDLE_TIME2,971,077
IOWAIT_TIME44,794
SYS_TIME207,429
USER_TIME605,215
LOAD0
OS_CPU_WAIT_TIME854,100
RSRC_MGR_CPU_WAIT_TIME0
PHYSICAL_MEMORY_BYTES8,589,934,592
NUM_CPUS8
NUM_CPU_CORES4

NUM_LCPUS: 如果显示0,是因为没有设置LPARS

NUM_VCPUS: 同上。

AVG_BUSY_TIME: BUSY_TIME / NUM_CPUS

AVG_IDLE_TIME: IDLE_TIME / NUM_CPUS

AVG_IOWAIT_TIME: IOWAIT_TIME / NUM_CPUS

AVG_SYS_TIME: SYS_TIME / NUM_CPUS

AVG_USER_TIME: USER_TIME / NUM_CPUSar o

BUSY_TIME: time equiv of %usr+%sys in sar output

IDLE_TIME: time equiv of %idle in sar

IOWAIT_TIME: time equiv of %wio in sar

SYS_TIME: time equiv of %sys in sar

USER_TIME: time equiv of %usr in sar

LOAD: 未知

OS_CPU_WAIT_TIME: supposedly time waiting on run queues

RSRC_MGR_CPU_WAIT_TIME: time waited coz of resource manager

PHYSICAL_MEMORY_BYTES: total memory in use supposedly

NUM_CPUS: number of CPUs reported by OS 操作系统CPU数

NUM_CPU_CORES: number of CPU sockets on motherboard 主板上CPU插槽数

总的elapsed time也可以用以公式计算:

BUSY_TIME + IDLE_TIME + IOWAIT TIME

或:SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME

(因为BUSY_TIME = SYS_TIME+USER_TIME)

Back to Wait Events Statistics
Back to Top

Service Statistics

  • ordered by DB Time
Service NameDB Time (s)DB CPU (s)Physical ReadsLogical Reads
ICCI608.10496.60315,84916,550,972
SYS$USERS54.7017.806,53958,929
ICCIXDB0.000.0000
SYS$BACKGROUND0.000.0028238,990

Back to Wait Events Statistics
Back to Top

Service Wait Class Stats

  • Wait Class info for services in the Service Statistics section.
  • Total Waits and Time Waited displayed for the following wait classes: User I/O, Concurrency, Administrative, Network
  • Time Waited (Wt Time) in centisecond (100th of a second)
Service NameUser I/O Total WtsUser I/O Wt TimeConcurcy Total WtsConcurcy Wt TimeAdmin Total WtsAdmin Wt TimeNetwork Total WtsNetwork Wt Time
ICCI59826864046213380015640596552
SYS$USERS65673238231110073233
SYS$BACKGROUND4431153301680000

Back to Wait Events Statistics
Back to Top

SQL Statistics v$sqlarea

本节按各种资源分别列出对资源消耗最严重的SQL语句,并显示它们所占统计期内全部资源的比例,这给出我们调优指南。例如在一个系统中,CPU资源是系统性能瓶颈所在,那么优化buffer gets最多的SQL语句将获得最大效果。在一个I/O等待是最严重事件的系统中,调优的目标应该是physical IOs最多的SQL语句。

在STATSPACK报告中,没有完整的SQL语句,可使用报告中的Hash Value通过下面语句从数据库中查到:

select sql_text

from stats$sqltext

where hash_value = &hash_value

order by piece;

Back to Top

SQL ordered by Elapsed Time

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
Elapsed Time (s)CPU Time (s)ExecutionsElap per Exec (s)% Total DB TimeSQL IdSQL ModuleSQL Text
9357193.5014.10d8z0u8hgj8xdycuidmain@HPGICCI1 (TNS V1-V3)insert into CUID select CUID_...
7675172,3290.0011.524vja2k2gdtyupload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
5842158.048.75569r5k05drsj7cumimain@HPGICCI1 (TNS V1-V3)insert into CUMI select CUSV_...
5142150.937.68ackxqhnktxnbccusmmain@HPGICCI1 (TNS V1-V3)insert into CUSM select CUSM_...
3836166,0690.005.677gtztzv329wg0select c.name, u.name from co...
353135.005.286z06gcfw39pkdSQL*PlusSELECT F.TABLESPACENAME, TO...
2323172,3290.003.461dm3bq36vu3g8load_fnsact@HPGICCI1 (TNS V1-V3)insert into iccifnsact values...
151152.982.25djs2w2f17nw2zDECLARE job BINARY_INTEGER := ...
1414172,9830.002.167wwv1ybs9zguzload_fnsact@HPGICCI1 (TNS V1-V3)update ICCIFNSACT set BORM_AD...
1313172,3370.002.00gmn2w09rdxn14load_oldnewact@HPGICCI1 (TNS V1-V3)insert into OLDNEWACT values ...
1313166,0510.001.89chjmy0dxf9mbjicci_migact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
10419.701.460yv9t4qb1zb2bcuidmain@HPGICCI1 (TNS V1-V3)select CUID_CUST_NO , CUIDID...
10851.911.441crajpb7j5tyzINSERT INTO STATS$SGA_TARGET_A...
88172,3290.001.2538apjgr0p55nsload_fnsact@HPGICCI1 (TNS V1-V3)update ICCICCS set CCSMAXOVER...
88172,9830.001.165c4qu2zmj3guxload_fnsact@HPGICCI1 (TNS V1-V3)select * from ICCIPRODCODE wh...

Back to SQL Statistics
Back to Top

SQL ordered by CPU Time

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
CPU Time (s)Elapsed Time (s)ExecutionsCPU per Exec (s)% Total DB TimeSQL IdSQL ModuleSQL Text
7576172,3290.0011.524vja2k2gdtyupload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
5793157.3114.10d8z0u8hgj8xdycuidmain@HPGICCI1 (TNS V1-V3)insert into CUID select CUID_...
4251142.437.68ackxqhnktxnbccusmmain@HPGICCI1 (TNS V1-V3)insert into CUSM select CUSM_...
4258142.018.75569r5k05drsj7cumimain@HPGICCI1 (TNS V1-V3)insert into CUMI select CUSV_...
3638166,0690.005.677gtztzv329wg0select c.name, u.name from co...
2323172,3290.003.461dm3bq36vu3g8load_fnsact@HPGICCI1 (TNS V1-V3)insert into iccifnsact values...
1414172,9830.002.167wwv1ybs9zguzload_fnsact@HPGICCI1 (TNS V1-V3)update ICCIFNSACT set BORM_AD...
1313172,3370.002.00gmn2w09rdxn14load_oldnewact@HPGICCI1 (TNS V1-V3)insert into OLDNEWACT values ...
1313166,0510.001.89chjmy0dxf9mbjicci_migact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
111552.232.25djs2w2f17nw2zDECLARE job BINARY_INTEGER := ...
88172,3290.001.2538apjgr0p55nsload_fnsact@HPGICCI1 (TNS V1-V3)update ICCICCS set CCSMAXOVER...
81051.601.441crajpb7j5tyzINSERT INTO STATS$SGA_TARGET_A...
88172,9830.001.165c4qu2zmj3guxload_fnsact@HPGICCI1 (TNS V1-V3)select * from ICCIPRODCODE wh...
41013.541.460yv9t4qb1zb2bcuidmain@HPGICCI1 (TNS V1-V3)select CUID_CUST_NO , CUIDID...
33513.135.286z06gcfw39pkdSQL*PlusSELECT F.TABLESPACENAME, TO...

Back to SQL Statistics
Back to Top

SQL ordered by Gets

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • Total Buffer Gets: 16,648,792
  • Captured SQL account for 97.9% of Total

这一部分,通过Buffer Gets对SQL语句进行排序,即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程,因为存储过程执行的单独的语句的数目被总计出来。在这里的Buffer Gets是一个累积值,所以这个值大并不一定意味着这条语句的性能存在问题。通常我们可以通过对比该条语句的Buffer Gets和physical reads值,如果这两个比较接近,肯定这条语句是存在问题的,我们可以通过执行计划来分析,为什么physical reads的值如此之高。另外,我们在这里也可以关注gets per exec的值,这个值如果太大,表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。

另外说明一点:大量的逻辑读往往伴随着较高的CPU消耗。所以很多时候我们看到的系统CPU将近100%的时候,很多时候就是SQL语句造成的,这时候我们可以分析一下这里逻辑读大的SQL。

select * from

executions, buffer_gets/executions "Gets/Exec",

Buffer GetsExecutionsGets per Exec%TotalCPU Time (s)Elapsed Time (s)SQL IdSQL ModuleSQL Text
3,305,363172,32919.1819.8574.5776.414vja2k2gdtyupload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
2,064,41412,064,414.0012.4057.3193.50d8z0u8hgj8xdycuidmain@HPGICCI1 (TNS V1-V3)insert into CUID select CUID_...
1,826,869166,06911.0010.9735.8437.607gtztzv329wg0select c.name, u.name from co...
1,427,648172,3378.288.5812.9713.29gmn2w09rdxn14load_oldnewact@HPGICCI1 (TNS V1-V3)insert into OLDNEWACT values ...
1,278,667172,3297.427.6822.8522.941dm3bq36vu3g8load_fnsact@HPGICCI1 (TNS V1-V3)insert into iccifnsact values...
1,216,36711,216,367.007.3142.4350.93ackxqhnktxnbccusmmain@HPGICCI1 (TNS V1-V3)insert into CUSM select CUSM_...
1,107,30511,107,305.006.6542.0158.04569r5k05drsj7cumimain@HPGICCI1 (TNS V1-V3)insert into CUMI select CUSV_...
898,868172,9835.205.4014.2814.347wwv1ybs9zguzload_fnsact@HPGICCI1 (TNS V1-V3)update ICCIFNSACT set BORM_AD...
711,450166,0514.284.2712.5212.55chjmy0dxf9mbjicci_migact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
692,996172,3294.024.168.318.3138apjgr0p55nsload_fnsact@HPGICCI1 (TNS V1-V3)update ICCICCS set CCSMAXOVER...
666,748166,0524.024.006.366.367v9dyf5r424yhicci_migact@HPGICCI1 (TNS V1-V3)select NEWACTNO into :b0 from...
345,357172,9832.002.077.707.715c4qu2zmj3guxload_fnsact@HPGICCI1 (TNS V1-V3)select * from ICCIPRODCODE wh...
231,75651,6334.491.395.755.8349ms69srnaxzjload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCIRPYV values (...

Back to SQL Statistics
Back to Top

SQL ordered by Reads

  • Total Disk Reads: 322,678
  • Captured SQL account for 66.1% of Total

这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL,即物理I/O。当我们的系统如果存在I/O瓶颈时,需要关注这里I/O操作比较多的语句。

select * from

executions, disk_reads/executions "Reads/Exec",

Physical ReadsExecutionsReads per Exec%TotalCPU Time (s)Elapsed Time (s)SQL IdSQL ModuleSQL Text
66,286166,286.0020.5457.3193.50d8z0u8hgj8xdycuidmain@HPGICCI1 (TNS V1-V3)insert into CUID select CUID_...
50,646150,646.0015.703.549.700yv9t4qb1zb2bcuidmain@HPGICCI1 (TNS V1-V3)select CUID_CUST_NO , CUIDID...
24,507124,507.007.5942.0158.04569r5k05drsj7cumimain@HPGICCI1 (TNS V1-V3)insert into CUMI select CUSV_...
21,893121,893.006.7842.4350.93ackxqhnktxnbccusmmain@HPGICCI1 (TNS V1-V3)insert into CUSM select CUSM_...
19,761119,761.006.122.146.04a7nh7j8zmfrzwcumimain@HPGICCI1 (TNS V1-V3)select CUSV_CUST_NO from CUMI...
19,554119,554.006.061.273.8338gak8u2qm11wSQL*Plusselect count(*) from CUSVAA_T...
6,34216,342.001.973.1335.006z06gcfw39pkdSQL*PlusSELECT F.TABLESPACENAME, TO...
4,38514,385.001.361.592.43cp5duhcsj72q0cusmmain@HPGICCI1 (TNS V1-V3)select CUSM_CUST_ACCT_NO from...
63512.600.0211.1714.91djs2w2f17nw2zDECLARE job BINARY_INTEGER := ...
35135.000.010.080.671uk5m5qbzj1vtSQL*PlusBEGIN dbms_workload_repository...

Back to SQL Statistics
Back to Top

SQL ordered by Executions

  • Total Executions: 1,675,112
  • Captured SQL account for 99.8% of Total

这部分告诉我们在这段时间中执行次数最多的SQL语句。为了隔离某些频繁执行的查询,以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询,这可能是很有用的。或许一个查询正在一个循环的内部执行,而且它可能在循环的外部执行一次,可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的飞快,任何被执行几百万次的操作都将开始耗尽大量的时间。

select * from

rows_processed, rows_processed/executions "Rows/Exec",

ExecutionsRows ProcessedRows per ExecCPU per Exec (s)Elap per Exec (s)SQL IdSQL ModuleSQL Text
172,983172,3291.000.000.005c4qu2zmj3guxload_fnsact@HPGICCI1 (TNS V1-V3)select * from ICCIPRODCODE wh...
172,983172,3291.000.000.007wwv1ybs9zguzload_fnsact@HPGICCI1 (TNS V1-V3)update ICCIFNSACT set BORM_AD...
172,337172,3371.000.000.00gmn2w09rdxn14load_oldnewact@HPGICCI1 (TNS V1-V3)insert into OLDNEWACT values ...
172,329172,3291.000.000.001dm3bq36vu3g8load_fnsact@HPGICCI1 (TNS V1-V3)insert into iccifnsact values...
172,329172,3291.000.000.0038apjgr0p55nsload_fnsact@HPGICCI1 (TNS V1-V3)update ICCICCS set CCSMAXOVER...
172,3296,2860.040.000.004vja2k2gdtyupload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
166,069166,0691.000.000.007gtztzv329wg0select c.name, u.name from co...
166,052166,0521.000.000.007v9dyf5r424yhicci_migact@HPGICCI1 (TNS V1-V3)select NEWACTNO into :b0 from...
166,051166,0511.000.000.00chjmy0dxf9mbjicci_migact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
51,74051,7401.000.000.00bu8tnqr3xv25qload_fnsact@HPGICCI1 (TNS V1-V3)select count(*) into :b0 fro...
51,63351,6331.000.000.0049ms69srnaxzjload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCIRPYV values (...

Back to SQL Statistics
Back to Top

SQL ordered by Parse Calls

  • Total Parse Calls: 182,780
  • Captured SQL account for 99.0% of Total

在这一部分,主要显示PARSE与EXECUTIONS的对比情况。如果PARSE/EXECUTIONS>1,往往说明这个语句可能存在问题:没有使用绑定变量,共享池设置太小,cursor_sharing被设置为exact,没有设置session_cached_cursors等等问题。

select * from

executions, hash_value,address

Parse CallsExecutions% Total ParsesSQL IdSQL ModuleSQL Text
166,069166,06990.867gtztzv329wg0select c.name, u.name from co...
6,3046,3043.452ym6hhaq30r73select type#, blocks, extents,...
2,4372,4381.33bsa0wjtftg3uwselect file# from file$ where ...
1,5681,5680.869qgtwh66xg6nzupdate seg$ set type#=:4, bloc...
1,5541,5540.85aq4js2gkfjru8update tsq$ set blocks=:3, max...
4444440.24104pd9mm3fh9pselect blocks, maxblocks, gran...
4214210.23350f5yrnnmshslock table sys.mon_mods$ in ex...
4214210.23g00cj285jmgswupdate sys.mon_mods$ set inser...
86860.053m8smr0v7v1m6INSERT INTO sys.wri$_adv_messa...
81810.04f80h0xb1qvbskSELECT sys.wri$_adv_seq_msggro...

Back to SQL Statistics
Back to Top

SQL ordered by Sharable Memory

No data exists for this section of the report.

在这一部分,主要是针对shared memory占用的情况进行排序。

select * from

executions, hash_value,address

Back to SQL Statistics
Back to Top

Running Time top 10 sql

select * from

SQL ordered by Version Count

No data exists for this section of the report.

在这一部分,主要是针对SQL语句的多版本进行排序。相同的SQL文本,但是不同属性,比如对象owner不同,会话优化模式不同、类型不同、长度不同和绑定变量不同等等的语句,他们是不能共享的,所以再缓存中会存在多个不同的版本。这当然就造成了资源上的更多的消耗。

Back to SQL Statistics
Back to Top

SQL ordered by Cluster Wait Time

Cluster Wait Time (s)CWT % of Elapsd TimeElapsed Time(s)CPU Time(s)ExecutionsSQL IdSQL ModuleSQL Text
10.9611.7293.5057.311d8z0u8hgj8xdycuidmain@HPGICCI1 (TNS V1-V3)insert into CUID select CUID_...
4.217.2558.0442.011569r5k05drsj7cumimain@HPGICCI1 (TNS V1-V3)insert into CUMI select CUSV_...
3.627.1250.9342.431ackxqhnktxnbccusmmain@HPGICCI1 (TNS V1-V3)insert into CUSM select CUSM_...
2.396.3537.6035.84166,0697gtztzv329wg0select c.name, u.name from co...
2.383.1276.4174.57172,3294vja2k2gdtyupload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
1.6416.919.703.5410yv9t4qb1zb2bcuidmain@HPGICCI1 (TNS V1-V3)select CUID_CUST_NO , CUIDID...
1.063.0235.003.1316z06gcfw39pkdSQL*PlusSELECT F.TABLESPACENAME, TO...
0.8313.766.042.141a7nh7j8zmfrzwcumimain@HPGICCI1 (TNS V1-V3)select CUSV_CUST_NO from CUMI...
0.6687.900.750.42444104pd9mm3fh9pselect blocks, maxblocks, gran...
0.5013.013.831.27138gak8u2qm11wSQL*Plusselect count(*) from CUSVAA_T...
0.5051.750.960.791,554aq4js2gkfjru8update tsq$ set blocks=:3, max...
0.3391.110.360.3318704xtrk7uyhknhselect obj#, type#, ctime, mti...
0.332.4713.2912.97172,337gmn2w09rdxn14load_oldnewact@HPGICCI1 (TNS V1-V3)insert into OLDNEWACT values ...
0.291.2622.9422.85172,3291dm3bq36vu3g8load_fnsact@HPGICCI1 (TNS V1-V3)insert into iccifnsact values...
0.2510.142.431.591cp5duhcsj72q0cusmmain@HPGICCI1 (TNS V1-V3)select CUSM_CUST_ACCT_NO from...
0.2127.920.740.741,5689qgtwh66xg6nzupdate seg$ set type#=:4, bloc...
0.203.495.835.7551,63349ms69srnaxzjload_fnsact@HPGICCI1 (TNS V1-V3)insert into ICCIRPYV values (...
0.171.3912.5512.52166,051chjmy0dxf9mbjicci_migact@HPGICCI1 (TNS V1-V3)insert into ICCICCS values (:...
0.1657.640.280.2439cn1gtsav2d5jhcusvaamain@HPGICCI1 (TNS V1-V3)BEGIN BEGIN IF (xdb.DBMS...
0.1474.580.190.141215ngzsfstg8tmyselect o.owner#, o.name, o.nam...
0.1164.720.180.158078m9ryygp65v5cusvaamain@HPGICCI1 (TNS V1-V3)SELECT /+ ALL_ROWS / COUNT(*...
0.1194.540.120.0117bwt0pmxhv7qk7delete from con$ where owner#=...
0.1180.260.140.1432753saa2zkr6wc3select intcol#, nvl(pos#, 0), ...
0.0819.200.420.241d92h3rjp0y217begin prvt_hdm.auto_execute( :...
0.0754.970.130.13837ng34ruy5awxqselect i.obj#, i.ts#, i.file#,...
0.065.221.130.72770hhmdwwgxbw0rselect obj#, type#, flags, ...
0.0686.500.060.0645a2any035u1qz1select owner#, name from con$...
0.068.190.670.0811uk5m5qbzj1vtSQL*PlusBEGIN dbms_workload_repository...
0.0475.690.060.06876769wyy3yf66fselect pos#, intcol#, col#, sp...
0.0448.050.090.0770pvtkmrrq8usgselect file#, block# from seg...
0.048.840.400.406,3042ym6hhaq30r73select type#, blocks, extents,...
0.0328.150.120.1249b52m6vduutr8jdelete from RecycleBin$ ...
0.0366.230.050.05851gu8t96d0bdmuselect t.ts#, t.file#, t.block...
0.0367.030.050.0538btzq46kta67dzDBMS_SCHEDULERupdate obj$ set obj#=:6, type#...
0.0266.730.040.04863m8smr0v7v1m6INSERT INTO sys.wri$_adv_messa...
0.0226.940.090.09380k8h617b8guhfdelete from RecycleBin$ ...
0.0276.760.030.03519vtm7gy4fr2nyselect con# from con$ where ow...
0.0251.910.050.058483taa7kaw59c1select name, intcol#, segcol#,...
0.020.1514.9111.175djs2w2f17nw2zDECLARE job BINARY_INTEGER := ...
0.022.121.000.998,784501v412s13r4mload_fnsact@HPGICCI1 (TNS V1-V3)update ICCIFNSACT set BORM_FA...
0.0253.820.030.0339bdv0rkkssq2jmcusvaamain@HPGICCI1 (TNS V1-V3)SELECT count(*) FROM user_poli...
0.010.1014.3414.28172,9837wwv1ybs9zguzload_fnsact@HPGICCI1 (TNS V1-V3)update ICCIFNSACT set BORM_AD...
0.018.290.160.13421g00cj285jmgswupdate sys.mon_mods$ set inser...
0.011.650.560.54284qubbrsr0kfninsert into wrh$_latch (snap...
0.0122.330.040.022644au3v5mzpc1cload_curmmast@HPGICCI1 (TNS V1-V3)insert into ICCICURMMAST valu...
0.010.087.717.70172,9835c4qu2zmj3guxload_fnsact@HPGICCI1 (TNS V1-V3)select * from ICCIPRODCODE wh...

Back to SQL Statistics
Back to Top

对于出现在上面的可疑的sql语句,我们可以查看语句相关的执行计划,然后分析相关索引等是否合理。

通过语句查看执行计划的方法:

SELECT id,parent_id,LPAD(' ',4*(LEVEL-1))||operation||' '||options||' '||object_name "Execution plan" ,cost,cardinality,bytes

FROM (

SELECT p.* FROM v$sql_plan p,v$sql s WHERE p.address = s.ADDRESS

AND p.hash_value = s.HASH_VALUE

and p.hash_value = '&hash_value'

)

CONNECT BY PRIOR id = parent_id

START WITH id = 0;

查看,分析,优化索引等在这里就不再一一描述了。

Complete List of SQL Text

SQL IdSQL Text
04xtrk7uyhknhselect obj#, type#, ctime, mtime, stime, status, dataobj#, flags, oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
0hhmdwwgxbw0rselect obj#, type#, flags, related, bo, purgeobj, con# from RecycleBin$ where ts#=:1 and to_number(bitand(flags, 16)) = 16 order by dropscn
0k8h617b8guhfdelete from RecycleBin$ where purgeobj=:1
0pvtkmrrq8usgselect file#, block# from seg$ where type# = 3 and ts# = :1
0v9t4qb1zb2bselect CUID_CUST_NO , CUID_ID_TYPE , CUID_ID_RECNO from CUID_TMP where CHGFLAG='D'
104pd9mm3fh9pselect blocks, maxblocks, grantor#, priv1, priv2, priv3 from tsq$ where ts#=:1 and user#=:2
1crajpb7j5tyzINSERT INTO STATS$SGA_TARGET_ADVICE ( SNAP_ID , DBID , INSTANCE_NUMBER , SGA_SIZE , SGA_SIZE_FACTOR , ESTD_DB_TIME , ESTD_DB_TIME_FACTOR , ESTD_PHYSICAL_READS ) SELECT :B3 , :B2 , :B1 , SGA_SIZE , SGA_SIZE_FACTOR , ESTD_DB_TIME , ESTD_DB_TIME_FACTOR , ESTD_PHYSICAL_READS FROM V$SGA_TARGET_ADVICE
1dm3bq36vu3g8insert into iccifnsact values (:b0, :b1, :b2, null , null , :b3, :b4, GREATEST(:b5, :b6), null , :b7, :b8, null , :b9, :b10, :b6, null , null , null , null , null , :b12, null , null , null , :b13, :b14, null , null , :b15, :b16, :b17)
1gu8t96d0bdmuselect t.ts#, t.file#, t.block#, nvl(t.bobj#, 0), nvl(t.tab#, 0), t.intcols, nvl(t.clucols, 0), t.audit$, t.flags, t.pctfree$, t.pctused$, t.initrans, t.maxtrans, t.rowcnt, t.blkcnt, t.empcnt, t.avgspc, t.chncnt, t.avgrln, t.analyzetime, t.samplesize, t.cols, t.property, nvl(t.degree, 1), nvl(t.instances, 1), t.avgspc_flb, t.flbcnt, t.kernelcols, nvl(t.trigflag, 0), nvl(t.spare1, 0), nvl(t.spare2, 0), t.spare4, t.spare6, ts.cachedblk, ts.cachehit, ts.logicalread from tab$ t, tab_stats$ ts where t.obj#= :1 and t.obj# = ts.obj# (+)
1uk5m5qbzj1vtBEGIN dbms_workload_repository.create_snapshot; END;
2ym6hhaq30r73select type#, blocks, extents, minexts, maxexts, extsize, extpct, user#, iniexts, NVL(lists, 65535), NVL(groups, 65535), cachehint, hwmincr, NVL(spare1, 0), NVL(scanhint, 0) from seg$ where ts#=:1 and file#=:2 and block#=:3
350f5yrnnmshslock table sys.mon_mods$ in exclusive mode nowait
38apjgr0p55nsupdate ICCICCS set CCSMAXOVERDUE=GREATEST(:b0, CCSMAXOVERDUE) where FNSACTNO=:b1
38gak8u2qm11wselect count(*) from CUSVAA_TMP
3m8smr0v7v1m6INSERT INTO sys.wri$_adv_message_groups (task_id, id, seq, message#, fac, hdr, lm, nl, p1, p2, p3, p4, p5) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13)
44au3v5mzpc1cinsert into ICCICURMMAST values (:b0, :b1, :b2)
49ms69srnaxzjinsert into ICCIRPYV values (:b0, :b1, :b2, :b3, :b4, :b5, :b6, :b7, :b8, :b9, :b10, :b11, :b12, :b13, :b14, :b15, :b16, :b17, :b18, :b19, :b20, :b21, :b22, :b23, :b24, :b25, :b26, :b27, :b28, :b29, :b30, :b31, :b32, :b33, :b34, :b35, :b36, :b37, :b38, :b39, :b40, :b41, :b42, :b43, :b44, :b45, :b46, :b47, :b48, :b49, :b50, :b51)
4vja2k2gdtyupinsert into ICCICCS values (:b0, '////////////////////////', 0, 0, 0, 0, 0, ' ', 0, 0, 0, ' ', '0', null )
501v412s13r4mupdate ICCIFNSACT set BORM_FACILITY_NO=:b0 where BORM_MEMB_CUST_AC=:b1
53saa2zkr6wc3select intcol#, nvl(pos#, 0), col#, nvl(spare1, 0) from ccol$ where con#=:1
569r5k05drsj7insert into CUMI select CUSV_CUST_NO , CUSV_EDUCATION_CODE , CHGDATE from CUMI_TMP where CHGFLAG<>'D'
5c4qu2zmj3guxselect * from ICCIPRODCODE where PRODCODE=to_char(:b0)
5ngzsfstg8tmyselect o.owner#, o.name, o.namespace, o.remoteowner, o.linkname, o.subname, o.dataobj#, o.flags from obj$ o where o.obj#=:1
6769wyy3yf66fselect pos#, intcol#, col#, spare1, bo#, spare2 from icol$ where obj#=:1
6z06gcfw39pkdSELECT F.TABLESPACE_NAME, TO_CHAR ((T.TOTAL_SPACE - F.FREE_SPACE), '999, 999') "USED (MB)", TO_CHAR (F.FREE_SPACE, '999, 999') "FREE (MB)", TO_CHAR (T.TOTAL_SPACE, '999, 999') "TOTAL (MB)", TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)100)), '999')||' %' PER_FREE FROM ( SELECT TABLESPACE_NAME, ROUND (SUM (BLOCKS(SELECT VALUE/1024 FROM V$PARAMETER WHERE NAME = 'db_block_size')/1024) ) FREE_SPACE FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME ) F, ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES/1048576)) TOTAL_SPACE FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME ) T WHERE F.TABLESPACE_NAME = T.TABLESPACE_NAME
78m9ryygp65v5SELECT /+ ALL_ROWS / COUNT(*) FROM ALL_POLICIES V WHERE V.OBJECT_OWNER = :B3 AND V.OBJECT_NAME = :B2 AND (POLICY_NAME LIKE '%xdbrls%' OR POLICYNAME LIKE '%$xd%') AND V.FUNCTION = :B1
7gtztzv329wg0select c.name, u.name from con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled = :1 and c.owner# = u.user#
7ng34ruy5awxqselect i.obj#, i.ts#, i.file#, i.block#, i.intcols, i.type#, i.flags, i.property, i.pctfree$, i.initrans, i.maxtrans, i.blevel, i.leafcnt, i.distkey, i.lblkkey, i.dblkkey, i.clufac, i.cols, i.analyzetime, i.samplesize, i.dataobj#, nvl(i.degree, 1), nvl(i.instances, 1), i.rowcnt, mod(i.pctthres$, 256), i.indmethod#, i.trunccnt, nvl(c.unicols, 0), nvl(c.deferrable#+c.valid#, 0), nvl(i.spare1, i.intcols), i.spare4, i.spare2, i.spare6, decode(i.pctthres$, null, null, mod(trunc(i.pctthres$/256), 256)), ist.cachedblk, ist.cachehit, ist.logicalread from ind$ i, ind_stats$ ist, (select enabled, min(cols) unicols, min(to_number(bitand(defer, 1))) deferrable#, min(to_number(bitand(defer, 4))) valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1 order by i.obj#
7v9dyf5r424yhselect NEWACTNO into :b0 from OLDNEWACT where OLDACTNO=:b1
7wwv1ybs9zguzupdate ICCIFNSACT set BORM_ADV_DATE=:b0, BOIS_MATURITY_DATE=:b1, BOIS_UNPD_BAL=:b2, BOIS_UNPD_INT=:b3, BOIS_BAL_FINE=:b4, BOIS_INT_FINE=:b5, BOIS_FINE_FINE=:b6, BORM_LOAN_TRM=:b7, BORM_FIVE_STAT=:b8, BOIS_ARREARS_CTR=:b9, BOIS_ARREARS_SUM=:b10 where BORM_MEMB_CUST_AC=:b11
83taa7kaw59c1select name, intcol#, segcol#, type#, length, nvl(precision#, 0), decode(type#, 2, nvl(scale, -127/MAXSB1MINAL/), 178, scale, 179, scale, 180, scale, 181, scale, 182, scale, 183, scale, 231, scale, 0), null$, fixedstorage, nvl(deflength, 0), default$, rowid, col#, property, nvl(charsetid, 0), nvl(charsetform, 0), spare1, spare2, nvl(spare3, 0) from col$ where obj#=:1 order by intcol#
4qubbrsr0kfninsert into wrh$_latch (snap_id, dbid, instance_number, latch_hash, level#, gets, misses, sleeps, immediate_gets, immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time) select :snap_id, :dbid, :instance_number, hash, level#, gets, misses, sleeps, immediate_gets, immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time from v$latch order by hash
9qgtwh66xg6nzupdate seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7, maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13, 65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18 where ts#=:1 and file#=:2 and block#=:3
9vtm7gy4fr2nyselect con# from con$ where owner#=:1 and name=:2
a2any035u1qz1select owner#, name from con$ where con#=:1
a7nh7j8zmfrzwselect CUSV_CUST_NO from CUMI_TMP where CHGFLAG='D'

Back to SQL Statistics
Back to Top

Instance Activity Statistics

Back to Top

Instance Activity Stats

StatisticTotalper Secondper Trans
CPU used by this session23,3884.954.18
CPU used when call started21,8164.613.90
CR blocks created2,7940.590.50
Cached Commit SCN referenced237,93650.3342.50
Commit SCN cached30.000.00
DB time583,424123.41104.22
DBWR checkpoint buffers written402,78185.2071.95
DBWR checkpoints90.000.00
DBWR fusion writes2550.050.05
DBWR object drop buffers written00.000.00
DBWR thread checkpoint buffers written221,34146.8239.54
DBWR transaction table writes1300.030.02
DBWR undo block writes219,27246.3839.17
DFO trees parallelized160.000.00
PX local messages recv'd400.010.01
PX local messages sent400.010.01
PX remote messages recv'd800.020.01
PX remote messages sent800.020.01
Parallel operations not downgraded160.000.00
RowCR - row contention90.000.00
RowCR attempts140.000.00
RowCR hits50.000.00
SMON posted for undo segment recovery00.000.00
SMON posted for undo segment shrink90.000.00
SQL*Net roundtrips to/from client1,544,063326.62275.82
active txn count during cleanout276,65258.5249.42
application wait time1,6200.340.29
auto extends on undo tablespace00.000.00
background checkpoints completed70.000.00
background checkpoints started90.000.00
background timeouts21,7034.593.88
branch node splits3370.070.06
buffer is not pinned count1,377,184291.32246.01
buffer is pinned count20,996,1394,441.373,750.65
bytes received via SQL*Net from client7,381,397,1831,561,408.361,318,577.56
bytes sent via SQL*Net to client149,122,03531,544.2226,638.45
calls to get snapshot scn: kcmgss1,696,712358.91303.09
calls to kcmgas433,43591.6977.43
calls to kcmgcs142,48230.1425.45
change write time4,7071.000.84
cleanout - number of ktugct calls282,04559.6650.38
cleanouts and rollbacks - consistent read gets550.010.01
cleanouts only - consistent read gets2,4060.510.43
cluster key scan block gets21,8864.633.91
cluster key scans10,5402.231.88
cluster wait time2,8550.600.51
commit batch/immediate performed2940.060.05
commit batch/immediate requested2940.060.05
commit cleanout failures: block lost2,2270.470.40
commit cleanout failures: callback failure7500.160.13
commit cleanout failures: cannot pin40.000.00
commit cleanouts427,61090.4576.39
commit cleanouts successfully completed424,62989.8275.85
commit immediate performed2940.060.05
commit immediate requested2940.060.05
commit txn count during cleanout111,55723.6019.93
concurrency wait time5150.110.09
consistent changes1,7160.360.31
consistent gets5,037,4711,065.59899.87
由consistent gets,db block gets和physical reads这三个值,我们也可以计算得到buffer hit ratio,计算的公式如下: buffer hit ratio = 100(1-physical reads /(consistent gets+ db block gets)),例如在这里,我们可以计算得到:buffer hit ratio =100(1-26524/(16616758+2941398))= 99.86
consistent gets - examination2,902,016613.87518.40
consistent gets direct00.000.00
consistent gets from cache5,037,4711,065.59899.87
current blocks converted for CR00.000.00
cursor authentications4340.090.08
data blocks consistent reads - undo records applied1,5190.320.27
db block changes8,594,1581,817.951,535.22
db block gets11,611,3212,456.182,074.19
db block gets direct1,167,830247.03208.62
db block gets from cache10,443,4912,209.141,865.58
deferred (CURRENT) block cleanout applications20,7864.403.71
dirty buffers inspected25,0075.294.47
脏数据从LRU列表中老化,A value here indicates that the DBWR is not keeping up。如果这个值大于0,就需要考虑增加DBWRs。dirty buffers inspected: This is the number of dirty (modified) data buffers that were aged out on the LRU list. You may benefit by adding more DBWRs.If it is greater than 0, consider increasing the database writes.
drop segment calls in space pressure00.000.00
enqueue conversions6,7341.421.20
enqueue releases595,149125.89106.31
enqueue requests595,158125.90106.32
enqueue timeouts90.000.00
enqueue waits7,9011.671.41
exchange deadlocks10.000.00
execute count1,675,112354.34299.23
free buffer inspected536,832113.5695.90
这个值包含dirty,pinned,busy的buffer区域,如果free buffer inspected - dirty buffers inspected - buffer is pinned count的值还是比较大,表明不能被重用的内存块比较多,这将导致latch争用,需要增大buffer cache
free buffer requested746,999158.01133.44
gc CPU used by this session9,0991.921.63
gc cr block build time130.000.00
gc cr block flush time1430.030.03
gc cr block receive time4740.100.08
gc cr block send time360.010.01
gc cr blocks received4,1420.880.74
gc cr blocks served10,6752.261.91
gc current block flush time230.000.00
gc current block pin time340.010.01
gc current block receive time1,2120.260.22
gc current block send time520.010.01
gc current blocks received15,5023.282.77
gc current blocks served17,5343.713.13
gc local grants405,32985.7472.41
gc remote grants318,63067.4056.92
gcs messages sent1,129,094238.84201.70
ges messages sent90,69519.1816.20
global enqueue get time1,7070.360.30
global enqueue gets async12,7312.692.27
global enqueue gets sync190,49240.3034.03
global enqueue releases190,32840.2634.00
global undo segment hints helped00.000.00
global undo segment hints were stale00.000.00
heap block compress108,75823.0119.43
hot buffers moved to head of LRU18,6523.953.33
immediate (CR) block cleanout applications2,4620.520.44
immediate (CURRENT) block cleanout applications325,18468.7958.09
index crx upgrade (positioned)4,6630.990.83
index fast full scans (full)130.000.00
index fetch by key852,181180.26152.23
index scans kdiixs1339,58371.8360.66
leaf node 90-10 splits340.010.01
leaf node splits106,55222.5419.03
lob reads110.000.00
lob writes830.020.01
lob writes unaligned830.020.01
local undo segment hints helped00.000.00
local undo segment hints were stale00.000.00
logons cumulative610.010.01
messages received20,0404.243.58
messages sent19,8804.213.55
no buffer to keep pinned count00.000.00
no work - consistent read gets1,513,070320.06270.29
opened cursors cumulative183,37538.7932.76
parse count (failures)10.000.00
parse count (hard)1430.030.03
parse count (total)182,78038.6632.65
通过parse count (hard)和parse count (total),可以计算soft parse率为:100-100(parse count (hard)/parse count (total)) =100-100(1-6090/191531)=96.82
parse time cpu270.010.00
parse time elapsed3380.070.06
physical read IO requests82,81517.5214.79
physical read bytes2,643,378,176559,161.45472,200.46
physical read total IO requests98,87120.9117.66
physical read total bytes2,905,491,456614,607.04519,023.13
physical read total multi block requests24,0895.104.30
physical reads322,67868.2657.64
physical reads cache213,72845.2138.18
physical reads cache prefetch191,83040.5834.27
physical reads direct108,95023.0519.46
physical reads direct temporary tablespace108,81223.0219.44
physical reads prefetch warmup00.000.00
physical write IO requests223,45647.2739.92
physical write bytes14,042,071,0402,970,360.022,508,408.55
physical write total IO requests133,83528.3123.91
physical write total bytes23,114,268,6724,889,428.304,129,022.63
physical write total multi block requests116,13524.5720.75
physical writes1,714,120362.59306.20
physical writes direct1,276,780270.08228.08
physical writes direct (lob)00.000.00
physical writes direct temporary tablespace108,81223.0219.44
physical writes from cache437,34092.5178.12
physical writes non checkpoint1,673,703354.04298.98
pinned buffers inspected100.000.00
prefetch clients - default00.000.00
prefetch warmup blocks aged out before use00.000.00
prefetch warmup blocks flushed out before use00.000.00
prefetched blocks aged out before use00.000.00
process last non-idle time4,7301.000.84
queries parallelized160.000.00
recursive calls1,654,650350.01295.58
recursive cpu usage2,6410.560.47
redo blocks written8,766,0941,854.321,565.93
redo buffer allocation retries240.010.00
redo entries4,707,068995.70840.85
redo log space requests340.010.01
redo log space wait time500.010.01
redo ordering marks277,04258.6049.49
redo size4,343,559,400918,805.72775,912.72
redo subscn max counts2,6930.570.48
redo synch time4080.090.07
redo synch writes6,9841.481.25
redo wastage1,969,620416.64351.84
redo write time5,0901.080.91
redo writer latching time10.000.00
redo writes5,4941.160.98
rollback changes - undo records applied166,60935.2429.76
rollbacks only - consistent read gets1,4630.310.26
rows fetched via callback342,15972.3861.12
session connect time1,4610.310.26
session cursor cache hits180,47238.1832.24
session logical reads16,648,7923,521.772,974.06
session pga memory37,393,4487,909.946,679.79
session pga memory max45,192,2329,559.648,072.92
session uga memory30,067,312,2406,360,225.775,371,081.14
session uga memory max61,930,44813,100.3311,062.96
shared hash latch upgrades - no wait6,3641.351.14
shared hash latch upgrades - wait00.000.00
sorts (disk)40.000.00
磁盘排序一般不能超过5%。如果超过5%,需要设置参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE,注意,这里SORT_AREA_SIZE是分配给每个用户的,PGA_AGGREGATE_TARGET则是针对所有的session的一个总数设置。
sorts (memory)2,8570.600.51
内存中的排序数量
sorts (rows)42,379,5058,964.667,570.47
space was found by tune down00.000.00
space was not found by tune down00.000.00
sql area evicted70.000.00
sql area purged440.010.01
steps of tune down ret. in space pressure00.000.00
summed dirty queue length35,0677.426.26
switch current to new buffer170.000.00
table fetch by rowid680,469143.94121.56
这是通过索引或者where rowid=语句来取得的行数,当然这个值越大越好。
table fetch continued row00.000.00
这是发生行迁移的行。当行迁移的情况比较严重时,需要对这部分进行优化。检查行迁移的方法:1) 运行$ORACLE_HOME/rdbms/admin/utlchain.sql2) analyze table table_name list chained rows into CHAINED_ROWS3) select from CHAINED_ROWS where table_name='table_name';清除的方法:方法1:create table table_name_tmp as select from table_name where rowed in (select head_rowid from chained_rows); Delete from table_name where rowed in (select head_rowid from chained_rows); Insert into table_name select from table_name_tmp;方法2:create table table_name_tmp select from table_name ;truncate table table_nameinsert into table_name select * from table_name_tmp方法3:用exp工具导出表,然后删除这个表,最后用imp工具导入这表方法4:alter table table_name move tablespace tablespace_name,然后再重新表的索引上面的4种方法可以用以消除已经存在的行迁移现象,但是行迁移的产生很多情况下时由于PCT_FREE参数设置的太小所导致,所以需要调整PCT_FREE参数的值。
table scan blocks gotten790,986167.32141.30
table scan rows gotten52,989,36311,208.999,465.77
table scans (long tables)40.000.00
longtables就是表的大小超过buffer buffer* _SMALL_TABLE_THRESHOLD的表。如果一个数据库的大表扫描过多,那么db file scattered read等待事件可能同样非常显著。如果table scans (long tables)的per Trans值大于0,你可能需要增加适当的索引来优化你的SQL语句
table scans (short tables)169,20135.7930.23
short tables是指表的长度低于buffer chache 2%(2%是有隐含参数_SMALL_TABLE_THRESHOLD定义的,这个参数在oracle不同的版本中,有不同的含义。在9i和10g中,该参数值定义为2%,在8i中,该参数值为20个blocks,在v7中,该参数为5个blocks)的表。这些表将优先使用全表扫描。一般不使用索引。_SMALL_TABLE_THRESHOLD值的计算方法如下(9i,8K): (db_cache_size/8192)*2%。注意:_SMALL_TABLE_THRESHOLD参数修改是相当危险的操作
total number of times SMON posted2590.050.05
transaction lock background get time00.000.00
transaction lock background gets00.000.00
transaction lock foreground requests00.000.00
transaction lock foreground wait time00.000.00
transaction rollbacks2940.060.05
tune down retentions in space pressure00.000.00
undo change vector size1,451,085,596306,952.35259,215.00
user I/O wait time11,9922.542.14
user calls1,544,383326.69275.88
user commits8120.170.15
user rollbacks4,7861.010.85
workarea executions - onepass10.000.00
workarea executions - optimal1,6160.340.29
write clones created in background00.000.00
write clones created in foreground110.000.00

Back to Instance Activity Statistics
Back to Top

Instance Activity Stats - Absolute Values

  • Statistics with absolute values (should not be diffed)
StatisticBegin ValueEnd Value
session cursor cache count3,0243,592
opened cursors current3739
logons current2426

Back to Instance Activity Statistics
Back to Top

Instance Activity Stats - Thread Activity

  • Statistics identified by '(derived)' come from sources other than SYSSTAT
StatisticTotalper Hour
log switches (derived)96.85

Back to Instance Activity Statistics
Back to Top

IO Stats

Back to Top

通常,在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦DBA了解了如何读取和写入这些数据,他们也许能够通过磁盘间更均匀的分配I/O而得到某些性能提升。

在这里主要关注Av Rd(ms)列 (reads per millisecond)的值,一般来说,大部分的磁盘系统的这个值都能调整到14ms以下,oracle认为该值超过20ms都是不必要的。如果该值超过1000ms,基本可以肯定存在I/O的性能瓶颈。如果在这一列上出现######,可能是你的系统存在严重的I/O问题,也可能是格式的显示问题。

Tablespace IO Stats

  • ordered by IOs (Reads + Writes) desc
TablespaceReadsAv Reads/sAv Rd(ms)Av Blks/RdWritesAv Writes/sBuffer WaitsAv Buf Wt(ms)
ICCIDAT0167,408143.763.17160,2613460.00
UNDOTBS110012.001.0057,771126250.02
TEMP15,02238.747.243,831100.00
USERS6805.441.00971000.00
SYSAUX26305.481.00458000.00
SYSTEM3205.941.001580323.33
UNDOTBS26016.671.006000.00

显示每个表空间的I/O统计。根据Oracle经验,Av Rd(ms) [Average Reads in milliseconds]不应该超过30,否则认为有I/O争用。

Back to IO Stats
Back to Top

File IO Stats

  • ordered by Tablespace, File
TablespaceFilenameReadsAv Reads/sAv Rd(ms)Av Blks/RdWritesAv Writes/sBuffer WaitsAv Buf Wt(ms)
ICCIDAT01/dev/rora_icci015,91914.303.7315,161310.00
ICCIDAT01/dev/rora_icci027,69224.123.1816,555400.00
ICCIDAT01/dev/rora_icci036,56312.593.8015,746300.00
ICCIDAT01/dev/rora_icci048,07622.933.1116,164300.00
ICCIDAT01/dev/rora_icci056,55512.613.3121,958500.00
ICCIDAT01/dev/rora_icci066,94314.033.4120,574400.00
ICCIDAT01/dev/rora_icci077,92924.122.8718,263400.00
ICCIDAT01/dev/rora_icci087,71923.832.9917,361400.00
ICCIDAT01/dev/rora_icci096,79414.793.2918,425400.00
ICCIDAT01/dev/rora_icci1021105.311.006000.00
ICCIDAT01/dev/rora_icci111,16804.451.006000.00
ICCIDAT01/dev/rora_icci1247804.231.006000.00
ICCIDAT01/dev/rora_icci1335505.131.006000.00
ICCIDAT01/dev/rora_icci1441104.911.006010.00
ICCIDAT01/dev/rora_icci1517205.291.006010.00
ICCIDAT01/dev/rora_icci1611907.231.006010.00
ICCIDAT01/dev/rora_icci1722706.261.006010.00
ICCIDAT01/dev/rora_icci187708.441.006010.00
SYSAUX/dev/rora_SYSAUX26305.481.00458000.00
SYSTEM/dev/rora_SYSTEM3205.941.001580323.33
TEMP/dev/rora_TEMP3,65315.676.6182700
TEMP/dev/rora_TEMP22,56914.426.7055600
TEMP/dev/rora_TEMP31,02202.5016.8655700
TEMP/dev/rora_TEMP57,778212.436.461,89100
UNDOTBS1/dev/rora_UNDO010110012.001.0057,771126250.02
UNDOTBS2/dev/rora_UNDO02016016.671.006000.00
USERS/dev/rora_USERS6805.441.00971000.00

Back to IO Stats
Back to Top

Buffer Pool Statistics

  • Standard block size Pools D: default, K: keep, R: recycle
  • Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
PNumber of BuffersPool Hit%Buffer GetsPhysical ReadsPhysical WritesFree Buff WaitWrit Comp WaitBuffer Busy Waits
D401,0719915,480,754213,729437,34000634

这里将buffer poll细分,列举default、keep、recycle三种类型的buffer的详细情况。在这份报告中,我们的系统中只使用Default size的buffer pool。这里的3个waits统计,其实在前面的等待时间中已经包含,所以可以参考前面的描述。关于命中率也已经在前面讨论。所以,其实这段信息不需要怎么关注。
Back to Top

Advisory Statistics

Back to Top

Instance Recovery Stats

  • B: Begin snapshot, E: End snapshot
Targt MTTR (s)Estd MTTR (s)Recovery Estd IOsActual Redo BlksTarget Redo BlksLog File Size Redo BlksLog Ckpt Timeout Redo BlksLog Ckpt Interval Redo Blks
B0113692316580718837005807
E0981162001828613188370018837005033355

Back to Advisory Statistics
Back to Top

Buffer Pool Advisory

  • Only rows with estimated physical reads >0 are displayed
  • ordered by Block Size, Buffers For Estimate

这是oracle的对buffer pool的大小的调整建议。从advisory的数据看,当然buffer是越大,物理读更小,随着buffer的增大,对物理读的性能改进越来越小。当前buffer 设置为5,120M,物理读因子=1。我们可以看到,buffer pool在3G之前的扩大,对物理读的改善非常明显,之后,这种改善的程度越来越低。

PSize for Est (M)Size FactorBuffers for EstimateEst Phys Read FactorEstimated Physical Reads
D3200.1038,3801.3410,351,726
D6400.1976,7601.259,657,000
D9600.29115,1401.088,365,242
D1,2800.38153,5201.048,059,415
D1,6000.48191,9001.027,878,202
D1,9200.57230,2801.017,841,140
D2,2400.67268,6601.017,829,141
D2,5600.77307,0401.017,817,370
D2,8800.86345,4201.017,804,884
D3,2000.96383,8001.007,784,014
D3,3441.00401,0711.007,748,403
D3,5201.05422,1800.997,702,243
D3,8401.15460,5600.997,680,429
D4,1601.24498,9400.997,663,046
D4,4801.34537,3200.997,653,232
D4,8001.44575,7000.997,645,544
D5,1201.53614,0800.987,630,008
D5,4401.63652,4600.987,616,886
D5,7601.72690,8400.987,614,591
D6,0801.82729,2200.987,613,191
D6,4001.91767,6000.987,599,930

Back to Advisory Statistics
Back to Top

PGA Aggr Summary

  • PGA cache hit % - percentage of W/A (WorkArea) data processed only in-memory
PGA Cache Hit %W/A MB ProcessedExtra W/A MB Read/Written
87.911,100151

Back to Advisory Statistics
Back to Top

PGA Aggr Target Stats

  • B: Begin snap E: End snap (rows dentified with B or E contain data which is absolute i.e. not diffed over the interval)
  • Auto PGA Target - actual workarea memory target
  • W/A PGA Used - amount of memory used for all Workareas (manual + auto)
  • %PGA W/A Mem - percentage of PGA memory allocated to workareas
  • %Auto W/A Mem - percentage of workarea memory controlled by Auto Mem Mgmt
  • %Man W/A Mem - percentage of workarea memory under manual control
PGA Aggr Target(M)Auto PGA Target(M)PGA Mem Alloc(M)W/A PGA Used(M)%PGA W/A Mem%Auto W/A Mem%Man W/A MemGlobal Mem Bound(K)
B1,024862150.360.000.000.000.00104,850
E1,024860154.140.000.000.000.00104,850

Back to Advisory Statistics
Back to Top

PGA Aggr Target Histogram

  • Optimal Executions are purely in-memory operations
Low OptimalHigh OptimalTotal ExecsOptimal Execs1-Pass ExecsM-Pass Execs
2K4K1,3851,38500
64K128K282800
128K256K5500
256K512K797900
512K1024K10810800
1M2M7700
8M16M1100
128M256M3210
256M512M1100

Back to Advisory Statistics
Back to Top

PGA Memory Advisory

  • When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0
PGA Target Est (MB)Size FactrW/A MB ProcessedEstd Extra W/A MB Read/ Written to DiskEstd PGA Cache Hit %Estd PGA Overalloc Count
1280.134,652.122,895.9962.000
2560.254,652.122,857.1362.000
5120.504,652.122,857.1362.000
7680.754,652.122,857.1362.000
1,0241.004,652.12717.8287.000
1,2291.204,652.12717.8287.000
1,4341.404,652.12717.8287.000
1,6381.604,652.12717.8287.000
1,8431.804,652.12717.8287.000
2,0482.004,652.12717.8287.000
3,0723.004,652.12717.8287.000
4,0964.004,652.12717.8287.000
6,1446.004,652.12717.8287.000
8,1928.004,652.12717.8287.000

Back to Advisory Statistics
Back to Top

Shared Pool Advisory

  • SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor
  • Note there is often a 1:Many correlation between a single logical object in the Library Cache, and the physical number of memory objects associated with it. Therefore comparing the number of Lib Cache objects (e.g. in v$librarycache), with the number of Lib Cache Memory Objects is invalid.
Shared Pool Size(M)SP Size FactrEst LC Size (M)Est LC Mem ObjEst LC Time Saved (s)Est LC Time Saved FactrEst LC Load Time (s)Est LC Load Time FactrEst LC Mem Obj Hits
3040.43787,62664,8421.00311.003,206,955
3840.55787,62664,8421.00311.003,206,955
4640.66787,62664,8421.00311.003,206,955
5440.77787,62664,8421.00311.003,206,955
6240.89787,62664,8421.00311.003,206,955
7041.00787,62664,8421.00311.003,206,955
7841.11787,62664,8421.00311.003,206,955
8641.23787,62664,8421.00311.003,206,955
9441.34787,62664,8421.00311.003,206,955
1,0241.45787,62664,8421.00311.003,206,955
1,1041.57787,62664,8421.00311.003,206,955
1,1841.68787,62664,8421.00311.003,206,955
1,2641.80787,62664,8421.00311.003,206,955
1,3441.91787,62664,8421.00311.003,206,955
1,4242.02787,62664,8421.00311.003,206,955

Back to Advisory Statistics
Back to Top

SGA Target Advisory

SGA Target Size (M)SGA Size FactorEst DB Time (s)Est Physical Reads
1,0240.259,0609,742,760
2,0480.507,6127,948,245
3,0720.757,5637,886,258
4,0961.007,4517,748,338
5,1201.257,4237,713,470
6,1441.507,3977,680,927
7,1681.757,3857,666,980
8,1922.007,3857,666,980

Back to Advisory Statistics
Back to Top

Streams Pool Advisory

No data exists for this section of the report.

Back to Advisory Statistics
Back to Top

Java Pool Advisory

No data exists for this section of the report.

Back to Advisory Statistics
Back to Top

Wait Statistics

Back to Top

Buffer Wait Statistics

  • ordered by wait time desc, waits desc
ClassWaitsTotal Wait Time (s)Avg Time (ms)
data block3023
undo header61600
file header block800
undo block700

Back to Wait Statistics
Back to Top

Enqueue Activity

  • only enqueues with waits are shown
  • Enqueue stats gathered prior to 10g should not be compared with 10g data
  • ordered by Wait Time desc, Waits desc
Enqueue Type (Request Reason)RequestsSucc GetsFailed GetsWaitsWt Time (s)Av Wt Time(ms)
FB-Format Block14,07514,07507,03330.43
US-Undo Segment964964055600.32
WF-AWR Flush242401409.00
HW-Segment High Water Mark4,2234,22303701.22
CF-Controlfile Transaction10,54810,54805800.67
TX-Transaction (index contention)1101035.00
TM-DML121,768121,76167000.43
PS-PX Process Reservation10310304600.65
TT-Tablespace9,9339,93303900.54
TD-KTF map table enqueue (KTF dump entries)121201201.42
TA-Instance Undo181801300.38
PI-Remote PX Process Spawn Status16160800.50
MW-MWIN Schedule330300.67
DR-Distributed Recovery330300.33
TS-Temporary Segment14113300.33
AF-Advisor Framework (task serialization)14140101.00
JS-Job Scheduler (job run lock - synchronize)220101.00
UL-User-defined220101.00
MD-Materialized View Log DDL660200.00

Back to Wait Statistics
Back to Top

Undo Statistics

Back to Top

Undo从9i开始,回滚段一般都是自动管理的,一般情况下,这里我们不需要太重点关注。

在这里,主要关注pct waits,如果出现比较多的pct waits,那就需要增加回滚段的数量或者增大回滚段的空间。另外,观察一下各个回滚段使用的情况,比较理想的是各个回滚段上Avg Active比较均衡。

在oracle 9i之前,回滚段时手工管理的,可以通过指定optimal值来设定一个回滚段收缩的值,如果不设定,默认也应当为initial+(minextents-1)*next extents ,这个指定的结果,就是限制了回滚段不能无限制的增长,当超过optimal的设定值后,在适当的时候,oracle会shrinks到optimal大小。但是9i之后,undo一般都设置为auto模式,在这种模式下,我们无法指定optimal值,好像也没有默认值,所以无法shrinks,回滚段就会无限制的增长,一直到表空间利用率达到为100%,如果表空间设置为自动扩展的方式,这种情况下,就更糟糕,undo将无限制的增长。在这里,我们也可以看到,shrinks的值为0,也就是说,从来就没收缩过。

Segment Summary

  • Min/Max TR (mins) - Min and Max Tuned Retention (minutes)
  • STO - Snapshot Too Old count, OOS - Out of Space count
  • Undo segment block stats:
  • uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed
  • eS - expired Stolen, eR - expired Released, eU - expired reUsed
Undo TS#Num Undo Blocks (K)Number of TransactionsMax Qry Len (s)Max Tx ConcurcyMin/Max TR (mins)STO/ OOSuS/uR/uU/ eS/eR/eU
1219.12113,40506130.95/239.250/00/0/0/13/24256/0

Back to Undo Statistics
Back to Top

Undo Segment Stats

  • Most recent 35 Undostat rows, ordered by Time desc
End TimeNum Undo BlocksNumber of TransactionsMax Qry Len (s)Max Tx ConcyTun Ret (mins)STO/ OOSuS/uR/uU/ eS/eR/eU
25-Dec 15:18182,02174,309051310/00/0/0/13/24256/0
25-Dec 15:0857170032390/00/0/0/0/0/0
25-Dec 14:586831022290/00/0/0/0/0/0
25-Dec 14:481944,256042190/00/0/0/0/0/0
25-Dec 14:3857012,299052090/00/0/0/0/0/0
25-Dec 14:2836,04721,328062000/00/0/0/0/0/0
25-Dec 14:1870907031620/00/0/0/0/0/0
25-Dec 14:0891105031540/00/0/0/0/0/0

Back to Undo Statistics
Back to Top

Latch Statistics

Back to Top

Latch是一种低级排队机制,用于防止对内存结构的并行访问,保护系统全局区(SGA)共享内存结构。Latch是一种快速地被获取和释放的内存锁。如果latch不可用,就会记录latch free miss 。

有两种类型的Latch:willing to wait和(immediate)not willing to wait。

对于愿意等待类型(willing-to-wait)的latch,如果一个进程在第一次尝试中没有获得latch,那么它会等待并且再尝试一次,如果经过_spin_count次争夺不能获得latch, 然后该进程转入睡眠状态,百分之一秒之后醒来,按顺序重复以前的步骤。在8i/9i中默认值是_spin_count=2000。睡眠的时间会越来越长。

  对于不愿意等待类型(not-willing-to-wait)的latch,如果该闩不能立即得到的话,那么该进程就不会为获得该闩而等待。它将继续执行另一个操作。

  大多数Latch问题都可以归结为以下几种:

  没有很好的是用绑定变量(library cache latch和shared pool cache)、重作生成问题(redo allocation latch)、缓冲存储竞争问题(cache buffers LRU chain),以及buffer cache中的存在"热点"块(cache buffers chain)。

另外也有一些latch等待与bug有关,应当关注Metalink相关bug的公布及补丁的发布。

当latch miss ratios大于0.5%时,就需要检查latch的等待问题。

如果SQL语句不能调整,在8.1.6版本以上,可以通过设置CURSOR_SHARING = force 在服务器端强制绑定变量。设置该参数可能会带来一定的副作用,可能会导致执行计划不优,另外对于Java的程序,有相关的bug,具体应用应该关注Metalink的bug公告。

下面对几个重要类型的latch等待加以说明:

\1) latch free:当‘latch free’在报告的高等待事件中出现时,就表示可能出现了性能问题,就需要在这一部分详细分析出现等待的具体的latch的类型,然后再调整。

\2) cache buffers chain:cbc latch表明热块。为什么这会表示存在热块?为了理解这个问题,先要理解cbc的作用。ORACLE对buffer cache管理是以hash链表的方式来实现的(oracle称为buckets,buckets的数量由_db_block_hash_buckets定义)。cbc latch就是为了保护buffer cache而设置的。当有并发的访问需求时,cbc会将这些访问串行化,当我们获得cbc latch的控制权时,就可以开始访问数据,如果我们所请求的数据正好的某个buckets中,那就直接从内存中读取数据,完成之后释放cbc latch,cbc latch就可以被其他的用户获取了。cbc latch获取和释放是非常快速的,所以这种情况下就一般不会存在等待。但是如果我们请求的数据在内存中不存在,就需要到物理磁盘上读取数据,这相对于latch来说就是一个相当长的时间了,当找到对应的数据块时,如果有其他用户正在访问这个数据块,并且数据块上也没有空闲的ITL槽来接收本次请求,就必须等待。在这过程中,我们因为没有得到请求的数据,就一直占有cbc latch,其他的用户也就无法获取cbc latch,所以就出现了cbc latch等待的情况。所以这种等待归根结底就是由于数据块比较hot的造成的。
解决方法可以参考前面在等待事件中的3) buffer busy wait中关于热块的解决方法。

\3) cache buffers lru chain:该latch用于扫描buffer的LRU链表。三种情况可导致争用:1)buffer cache太小 ;2)buffer cache的过度使用,或者太多的基于cache的排序操作;3)DBWR不及时。解决方法:查找逻辑读过高的statement,增大buffer cache。

\4) Library cache and shared pool 争用:
library cache是一个hash table,我们需要通过一个hash buckets数组来访问(类似buffer cache)。library cache latch就是将对library cache的访问串行化。当有一个sql(或者PL/SQL procedure,package,function,trigger)需要执行的时候,首先需要获取一个latch,然后library cache latch就会去查询library cache以重用这些语句。在8i中,library cache latch只有一个。在9i中,有7个child latch,这个数量可以通过参数_KGLLATCH COUNT修改(最大可以达到66个)。当共享池太小或者语句的reuse低的时候,会出现‘shared pool’、‘library cache pin’或者 ‘library cache’ latch的争用。解决的方法是:增大共享池或者设置CURSOR_SHARING=FORCE|SIMILAR ,当然我们也需要tuning SQL statement。为减少争用,我们也可以把一些比较大的SQL或者过程利用DBMS_SHARED_POOL.KEEP包来pinning在shared pool中。
shared pool内存结构与buffer cache类似,也采用的是hash方式来管理的。共享池有一个固定数量的hash buckets,通过固定数量的library cache latch来串行化保护这段内存的使用。在数据启动的时候,会分配509个hash buctets,2*CPU_COUNT个library cache latch。当在数据库的使用中,共享池中的对象越来越多,oracle就会以以下的递增方式增加hash buckets的数量:509,1021,4093,8191,32749,65521,131071,4292967293。我们可以通过设置下面的参数来实现_KGL_BUCKET_COUNT,参数的默认值是0,代表数量509,最大我们可以设置为8,代表数量131071。
我们可以通过x$ksmsp来查看具体的共享池内存段情况,主要关注下面几个字段:
KSMCHCOM—表示内存段的类型
ksmchptr—表示内存段的物理地址
ksmchsiz—表示内存段的大小
ksmchcls—表示内存段的分类。recr表示a recreatable piece currently in use that can be a candidate for flushing when the shared pool is low in available memory; freeabl表示当前正在使用的,能够被释放的段; free表示空闲的未分配的段; perm表示不能被释放永久分配段。
降低共享池的latch 争用,我们主要可以考虑如下的几个事件:
1、使用绑定变量
2、使用cursor sharing
3、设置session_cached_cursors参数。该参数的作用是将cursor从shared pool转移到pga中。减小对共享池的争用。一般初始的值可以设置为100,然后视情况再作调整。
4、设置合适大小的共享池

\5) Redo Copy:这个latch用来从PGA中copy redo records到redo log buffer。latch的初始数量是2*COU_OUNT,可以通过设置参数_LOG_SIMULTANEOUS_COPIES在增加latch的数量,减小争用。

\6) Redo allocation:该latch用于redo log buffer的分配。减小这种类型的争用的方法有3个:
增大redo log buffer
适当使用nologging选项
避免不必要的commit操作

\7) Row cache objects:该latch出现争用,通常表明数据字典存在争用的情况,这往往也预示着过多的依赖于公共同义词的parse。解决方法:1)增大shared pool 2)使用本地管理的表空间,尤其对于索引表空间

Latch事件建议解决方法
Library cache使用绑定变量; 调整shared_pool_size.
Shared pool使用绑定变量; 调整shared_pool_size.
Redo allocation减小 redo 的产生; 避免不必要的commits.
Redo copy增加 _log_simultaneous_copies.
Row cache objects增加shared_pool_size
Cache buffers chain增大 _DB_BLOCK_HASH_BUCKETS ; make it prime.
Cache buffers LRU chain使用多个缓冲池;调整引起大量逻辑读的查询

注:在这里,提到了不少隐藏参数,也有利用隐藏参数来解决latch的方法描述,但是在实际的操作中,强烈建议尽量不要去更改隐藏参数的默认值。

Latch Activity

  • "Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for willing-to-wait latch get requests
  • "NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
  • "Pct Misses" for both should be very close to 0.0
Latch NameGet RequestsPct Get MissAvg Slps /MissWait Time (s)NoWait RequestsPct NoWait Miss
ASM db client latch11,8830.0000
AWR Alerted Metric Element list18,2520.0000
Consistent RBA5,5080.020.0000
FOB s.o list latch7310.0000
JS broadcast add buf latch6,1930.0000
JS broadcast drop buf latch6,1940.0000
JS broadcast load blnc latch6,0570.0000
JS mem alloc latch80.0000
JS queue access latch80.0000
JS queue state obj latch218,0860.0000
JS slv state obj latch310.0000
KCL gc element parent latch2,803,3920.040.0101080.00
KJC message pool free list43,1680.060.00014,5320.01
KJCT flow control latch563,8750.000.0000
KMG MMAN ready and startup request latch1,5760.0000
KSXR large replies3200.0000
KTF sga latch230.0001,5340.00
KWQMN job cache list latch3520.0000
KWQP Prop Status50.0000
MQL Tracking Latch00940.00
Memory Management Latch001,5760.00
OS process2070.0000
OS process allocation1,7170.0000
OS process: request allocation730.0000
PL/SQL warning settings2260.0000
SGA IO buffer pool latch20,6790.060.00020,8690.00
SQL memory manager latch70.0001,5750.00
SQL memory manager workarea list latch439,4420.0000
Shared B-Tree1820.0000
Undo Hint Latch00120.00
active checkpoint queue latch7,8350.0000
active service list50,9360.0001,6210.00
archive control50.0000
begin backup scn array72,9010.000.0000
business card320.0000
cache buffer handles331,1530.020.0000
cache buffers chains48,189,0730.000.0001,201,3790.00
cache buffers lru chain891,7960.340.000991,6050.23
cache table scan latch0010,3090.01
channel handle pool latch990.0000
channel operations parent latch490,3240.010.0000
checkpoint queue latch671,8560.010.000555,4690.02
client/application info3350.0000
commit callback allocation120.0000
compile environment latch173,4280.0000
dml lock allocation243,0870.000.0000
dummy allocation1340.0000
enqueue hash chains1,539,4990.010.0302630.00
enqueues855,2070.020.0000
error message lists640.0000
event group latch380.0000
file cache latch4,6940.0000
gcs drop object freelist8,4510.190.0000
gcs opaque info freelist38,5840.000.0000
gcs partitioned table hash9,801,8670.0000
gcs remaster request queue310.0000
gcs remastering latch1,014,1980.000.3300
gcs resource freelist1,154,5510.030.000771,6500.00
gcs resource hash3,815,3730.020.00020.00
gcs resource scan list40.0000
gcs shadows freelist795,4820.000.000779,6480.00
ges caches resource lists209,6550.020.000121,6130.01
ges deadlock list8400.0000
ges domain table366,7020.0000
ges enqueue table freelist487,8750.0000
ges group table543,8870.0000
ges process hash list59,5030.0000
ges process parent latch908,2320.00010.00
ges process table freelist730.0000
ges resource hash list862,5900.020.28072,2660.01
ges resource scan list5340.0000
ges resource table freelist135,4060.000.0000
ges synchronous data1600.630.0002,9540.07
ges timeout list3,2560.0004,4780.00
global KZLD latch for mem in SGA210.0000
hash table column usage latch590.0001,2790.00
hash table modification latch1160.0000
job workq parent latch00140.00
job_queue_processes parameter latch860.0000
kks stats3840.0000
ksuosstats global area3290.0000
ktm global data2960.0000
kwqbsn:qsga1820.0000
lgwr LWN SCN6,5470.180.0000
library cache235,0600.000.000220.00
library cache load lock4860.0000
library cache lock49,2840.0000
library cache lock allocation5660.0000
library cache pin27,8630.000.0000
library cache pin allocation2040.0000
list of block allocation10,1010.0000
loader state object freelist1080.0000
longop free list parent60.00060.00
message pool operations parent latch1,4240.0000
messages222,5810.000.0000
mostly latch-free SCN6,6491.430.0000
multiblock read objects29,2300.030.0000
name-service memory objects18,8420.0000
name-service namespace bucket56,7120.0000
name-service namespace objects150.0000
name-service pending queue6,4360.0000
name-service request440.0000
name-service request queue57,3120.0000
ncodef allocation latch770.0000
object queue header heap37,7210.0007,4570.00
object queue header operation2,706,9920.060.0000
object stats modification220.0000
parallel query alloc buffer9390.0000
parallel query stats720.0000
parallel txn reco latch6300.0000
parameter list1930.0000
parameter table allocation management680.0000
post/wait queue4,2050.0002,7120.00
process allocation46,8950.000380.00
process group creation730.0000
process queue1750.0000
process queue reference2,6210.00024062.50
qmn task queue latch6680.151.0000
query server freelists1590.0000
query server process80.00070.00
queued dump request23,6280.0000
redo allocation21,2060.570.0004,706,8260.02
redo copy004,707,1060.01
redo writing29,9440.010.0000
resmgr group change latch690.0000
resmgr:actses active list1370.0000
resmgr:actses change group520.0000
resmgr:free threads list1300.0000
resmgr:schema config70.0000
row cache objects1,644,1490.000.0003210.00
rules engine rule set statistics5000.0000
sequence cache3600.0000
session allocation535,5140.000.0000
session idle bit3,262,1410.000.0000
session state list latch1660.0000
session switching770.0000
session timer1,6200.0000
shared pool60,3590.000.0000
shared pool sim alloc130.0000
shared pool simulator4,2460.0000
simulator hash latch1,862,8030.0000
simulator lru latch1,719,4800.010.00046,0530.00
slave class20.0000
slave class create812.501.0000
sort extent pool1,2840.0000
state object free list40.0000
statistics aggregation2800.0000
temp lob duration state obj allocation20.0000
threshold alerts latch2020.0000
transaction allocation2110.0000
transaction branch allocation770.0000
undo global data779,7590.070.0000
user lock1020.0000

Back to Latch Statistics
Back to Top

Latch Sleep Breakdown

  • ordered by misses desc
Latch NameGet RequestsMissesSleepsSpin GetsSleep1Sleep2Sleep3
cache buffers lru chain891,7963,06113,060000
object queue header operation2,706,9921,75531,752000
KCL gc element parent latch2,803,3921,186111,176000
cache buffers chains48,189,0734961495000
ges resource hash list862,59016044116000
enqueue hash chains1,539,49979278000
gcs remastering latch1,014,198312000
qmn task queue latch668110000
slave class create8110000

Back to Latch Statistics
Back to Top

Latch Miss Sources

  • only latches with sleeps are shown
  • ordered by name, sleeps desc
Latch NameWhereNoWait MissesSleepsWaiter Sleeps
KCL gc element parent latchkclrwrite080
KCL gc element parent latchkclnfndnewm046
KCL gc element parent latchKCLUNLNK011
KCL gc element parent latchkclbla010
KCL gc element parent latchkclulb011
KCL gc element parent latchkclzcl010
cache buffers chainskcbnew: new latch again020
cache buffers chainskclwrt010
cache buffers lru chainkcbzgws010
enqueue hash chainsksqcmi: if lk mode not requested020
event range base latchNo latch011
gcs remastering latch69010
ges resource hash listkjlmfnd: search for lockp by rename and inst id0230
ges resource hash listkjakcai: search for resp by resname0130
ges resource hash listkjrmas1: lookup master node050
ges resource hash listkjlrlr: remove lock from resource queue0233
ges resource hash listkjcvscn: remove from scan queue010
object queue header operationkcbo_switch_q_bg030
object queue header operationkcbo_switch_mq_bg024
object queue header operationkcbw_unlink_q020
object queue header operationkcbw_link_q010
slave class createksvcreate010

Back to Latch Statistics
Back to Top

Parent Latch Statistics

No data exists for this section of the report.

Back to Latch Statistics
Back to Top

Child Latch Statistics

No data exists for this section of the report.

Back to Latch Statistics
Back to Top

Segment Statistics

Back to Top

DBA_HIST_SEG_STAT

desc DBA_HIST_SEG_STAT

v$sesstat

v$statname

Segments by Logical Reads

  • Total Logical Reads: 16,648,792
  • Captured Segments account for 85.2% of Total
OwnerTablespace NameObject NameSubobject NameObj. TypeLogical Reads%Total
ICCI01ICCIDAT01ICCICCS_PKINDEX1,544,8489.28
ICCI01ICCIDAT01CUSCAD_TMPTABLE1,349,5368.11
ICCI01ICCIDAT01ICCIFNSACT_PKINDEX1,268,4007.62
ICCI01ICCIDAT01IND_OLDNEWACTINDEX1,071,0726.43
ICCI01ICCIDAT01CUID_PKINDEX935,5845.62

Back to Segment Statistics
Back to Top

Segments by Physical Reads

  • Total Physical Reads: 322,678
  • Captured Segments account for 64.2% of Total
OwnerTablespace NameObject NameSubobject NameObj. TypePhysical Reads%Total
ICCI01ICCIDAT01CUID_TMPTABLE116,41736.08
ICCI01ICCIDAT01CUMI_TMPTABLE44,08613.66
ICCI01ICCIDAT01CUSM_TMPTABLE26,0788.08
ICCI01ICCIDAT01CUSVAA_TMP_PKINDEX19,5546.06
ICCI01ICCIDAT01CUIDTABLE2590.08

Back to Segment Statistics
Back to Top

Segments by Row Lock Waits

当一个进程予在正被其它进程锁住的数据行上获得排它锁时发生这种等待。这种等待经常是由于在一个有主键索引的表上做大量INSERT操作。

No data exists for this section of the report.

**Back to Segment Statistics
[Back to Top

](http://blog.itpub.net/26736162/viewspace-1869086/#top)**Segments by ITL Waits

No data exists for this section of the report.

Back to Segment Statistics
Back to Top

Segments by Buffer Busy Waits

No data exists for this section of the report.

Back to Segment Statistics
Back to Top

Segments by Global Cache Buffer Busy

  • % of Capture shows % of GC Buffer Busy for each top segment compared
  • with GC Buffer Busy for all segments captured by the Snapshot
OwnerTablespace NameObject NameSubobject NameObj. TypeGC Buffer Busy% of Capture
SYSSYSTEMTSQ$TABLE2100.00

Back to Segment Statistics
Back to Top

Segments by CR Blocks Received

  • Total CR Blocks Received: 4,142
  • Captured Segments account for 95.6% of Total
OwnerTablespace NameObject NameSubobject NameObj. TypeCR Blocks Received%Total
SYSSYSTEMUSER$TABLE1,00124.17
SYSSYSTEMTSQ$TABLE72217.43
SYSSYSTEMSEG$TABLE44610.77
SYSSYSTEMOBJ$TABLE2646.37
SYSSYSTEMI_OBJ2INDEX1744.20

Back to Segment Statistics
Back to Top

Segments by Current Blocks Received

  • Total Current Blocks Received: 15,502
  • Captured Segments account for 84.8% of Total
OwnerTablespace NameObject NameSubobject NameObj. TypeCurrent Blocks Received%Total
ICCI01ICCIDAT01CUSM_TMPTABLE5,76437.18
ICCI01ICCIDAT01CUMI_TMPTABLE2,79418.02
ICCI01ICCIDAT01CUID_TMPTABLE2,58516.68
SYSSYSTEMSEG$TABLE3612.33
SYSSYSTEMTSQ$TABLE3612.33

Back to Segment Statistics
Back to Top

Dictionary Cache Statistics

Back to Top

/* 库缓存详细信息,。

Get Requests**get表示一种类型的锁,语法分析锁。这种类型的锁在引用了一个对象的那条SQL语句的语法分析阶段被设置在该对象上。每当一条语句被语法分析一次时 Get Requests的值就增加1。**

pin requests**pin也表示一种类型的锁,是在执行发生的加锁。每当一条语句执行一次,pin requests的值就增加1。**

reloads**reloads列显示一条已执行过的语句因Library Cache使该语句的已语法分析版本过期或作废而需要被重新语法分析的次数。**

invalidations**:失效发生在一条已告诉缓存的SQL语句即使已经在library cache中,但已被标记为无效并迎词而被迫重新做语法分析的时候。每当已告诉缓存的语句所引用的对象以某种方式被修改时,这些语句就被标记为无效。**

pct miss**应该不高于1%。**

Reloads /pin requests <1**%,否则应该考虑增大SHARED_POOL_SIZE。**

该部分信息通过**v$librarycache**视图统计得到:

select namespace,gethitratio,pinhitratio,reloads,invalidations

from v$librarycache

where namespace in ('SQL AREA','TABLE/PROCEDURE','BODY','TRIGGER', 'INDEX');

Dictionary Cache Stats

  • "Pct Misses" should be very low (< 2% in most cases)
  • "Final Usage" is the number of cache entries being used
CacheGet RequestsPct MissScan ReqsPct MissMod ReqsFinal Usage
dc_awr_control860.00041
dc_constraints5991.530201,350
dc_files230.000023
dc_global_oids4060.000035
dc_histogram_data6730.15001,555
dc_histogram_defs47224.36004,296
dc_object_grants580.0000154
dc_object_ids1,9746.13001,199
dc_objects95519.580562,064
dc_profiles300.00001
dc_rollback_segments3,3580.000037
dc_segments2,7702.5601,5791,312
dc_sequences933.33095
dc_table_scns6100.00000
dc_tablespace_quotas1,55828.5001,5543
dc_tablespaces346,6510.00007
dc_usernames4340.000014
dc_users175,5850.000043
outstanding_alerts5771.93001

Back to Dictionary Cache Statistics
Back to Top

Dictionary Cache Stats (RAC)

CacheGES RequestsGES ConflictsGES Releases
dc_awr_control800
dc_constraints88220
dc_histogram_defs11500
dc_object_ids1431010
dc_objects2531110
dc_segments3,228490
dc_sequences1730
dc_table_scns600
dc_tablespace_quotas3,0934410
dc_users810
outstanding_alerts113410

Back to Dictionary Cache Statistics
Back to Top

Library Cache Statistics

Back to Top

Library Cache Activity

  • "Pct Misses" should be very low
NamespaceGet RequestsPct MissPin RequestsPct MissReloadsInvali- dations
BODY1050.002470.0000
CLUSTER30.0040.0000
INDEX1346.152642.3150
SQL AREA56100.001,857,0020.023212
TABLE/PROCEDURE17935.753,4778.02630
TRIGGER3230.003860.0000

Back to Library Cache Statistics
Back to Top

Library Cache Activity (RAC)

NamespaceGES Lock RequestsGES Pin RequestsGES Pin ReleasesGES Inval RequestsGES Invali- dations
BODY50000
CLUSTER40000
INDEX26226170
TABLE/PROCEDURE1,949285632440

Back to Library Cache Statistics
Back to Top

Memory Statistics

Back to Top

Process Memory Summary

  • B: Begin snap E: End snap
  • All rows below contain absolute values (i.e. not diffed over the interval)
  • Max Alloc is Maximum PGA Allocation size at snapshot time
  • Hist Max Alloc is the Historical Max Allocation for still-connected processes
  • ordered by Begin/End snapshot, Alloc (MB) desc
CategoryAlloc (MB)Used (MB)Avg Alloc (MB)Std Dev Alloc (MB)Max Alloc (MB)Hist Max Alloc (MB)Num ProcNum Alloc
BOther136.425.258.5524272626
Freeable13.500.001.501.11399
SQL0.330.160.030.03021210
PL/SQL0.120.060.010.01002424
EOther138.654.788.2024272929
Freeable14.940.001.361.0431111
SQL0.390.190.030.03021512
PL/SQL0.180.110.010.01002726

Back to Memory Statistics
Back to Top

SGA Memory Summary

这部分是关于SGA内存分配的一个描述,我们可以通过show sga等命令也可以查看到这里的内容。

Fixed Size:

oracle 的不同平台和不同版本下可能不一样,但对于确定环境是一个固定的值,里面存储了SGA 各部分组件的信息,可以看作引导建立SGA的区域。

Variable Size:

包含了shared_pool_size、java_pool_size、large_pool_size 等内存设置。

Database Buffers:

指数据缓冲区,在8i 中包含db_block_buffer*db_block_size、buffer_pool_keep、buffer_pool_recycle 三部分内存。在9i 中包含db_cache_size、db_keep_cache_size、db_recycle_cache_size、 db_nk_cache_size。

Redo Buffers:

指日志缓冲区,log_buffer。对于logbuffer,我们会发现在v$parameter、v$sgastat、v$sga的值不一样。v$parameter是我们可以自己设定的值,也可以设定为0,这时候,oracle降会以默认的最小值来设置v$sgastat的值,同时v$sga也是最小的值。v$sgastat的值是基于参数log_buffer的设定值,再根据一定的计算公式得到的一个值。v$sga的值,则是根据v$sgastat的值,然后选择再加上8k-11k的一个值,得到min(n*4k)的一个值。就是说得到的结果是4k的整数倍,也就是说v$sga是以4k的单位递增的。

SGA regionsBegin Size (Bytes)End Size (Bytes) (if different)
Database Buffers3,506,438,144
Fixed Size2,078,368
Redo Buffers14,696,448
Variable Size771,754,336

Back to Memory Statistics
Back to Top

SGA breakdown difference

  • ordered by Pool, Name
  • N/A value for Begin MB or End MB indicates the size of that Pool/Name was insignificant, or zero in that snapshot
PoolNameBegin MBEnd MB% Diff
javafree memory16.0016.000.00
largePX msg pool1.031.030.00
largefree memory14.9714.970.00
sharedASH buffers15.5015.500.00
sharedCCursor8.588.853.09
sharedKQR L PO8.758.800.55
shareddb_block_hash_buckets22.5022.500.00
sharedfree memory371.80369.61-0.59
sharedgcs resources66.1166.110.00
sharedgcs shadows41.6541.650.00
sharedges big msg buffers13.7513.750.00
sharedges enqueues7.447.561.63
sharedges reserved msg buffers7.867.860.00
sharedlibrary cache10.7810.931.41
sharedrow cache7.167.160.00
sharedsql area27.4928.503.67
buffer_cache3,344.003,344.000.00
fixed_sga1.981.980.00
log_buffer14.0214.020.00

Back to Memory Statistics
Back to Top

Streams Statistics

Back to Top

Streams CPU/IO Usage

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Streams Capture

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Streams Apply

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Buffered Queues

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Buffered Subscribers

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Rule Set

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Resource Limit Stats

  • only rows with Current or Maximum Utilization > 80% of Limit are shown
  • ordered by resource name
Resource NameCurrent UtilizationMaximum UtilizationInitial AllocationLimit
gcs_resources349,392446,903450063450063
gcs_shadows400,300447,369450063450063


Back to Top

init.ora Parameters

Parameter NameBegin valueEnd value (if different)
audit_file_dest/oracle/app/oracle/admin/ICCI/adump
background_dump_dest/oracle/app/oracle/admin/ICCI/bdump
cluster_databaseTRUE
cluster_database_instances2
compatible10.2.0.3.0
control_files/dev/rora_CTL01, /dev/rora_CTL02, /dev/rora_CTL03
core_dump_dest/oracle/app/oracle/admin/ICCI/cdump
db_block_size8192
db_domain
db_file_multiblock_read_count16
db_nameICCI
dispatchers(PROTOCOL=TCP) (SERVICE=ICCIXDB)
instance_number1
job_queue_processes10
open_cursors800
pga_aggregate_target1073741824
processes500
remote_listenerLISTENERS_ICCI
remote_login_passwordfileEXCLUSIVE
sga_max_size4294967296
sga_target4294967296
sort_area_size196608
spfile/dev/rora_SPFILE
thread1
undo_managementAUTO
undo_retention900
undo_tablespaceUNDOTBS1
user_dump_dest/oracle/app/oracle/admin/ICCI/udump


Back to Top

More RAC Statistics


Back to Top

Global Enqueue Statistics

StatisticTotalper Secondper Trans
acks for commit broadcast(actual)18,5373.923.31
acks for commit broadcast(logical)21,0164.453.75
broadcast msgs on commit(actual)5,1931.100.93
broadcast msgs on commit(logical)5,4911.160.98
broadcast msgs on commit(wasted)4500.100.08
dynamically allocated gcs resources00.000.00
dynamically allocated gcs shadows00.000.00
false posts waiting for scn acks00.000.00
flow control messages received00.000.00
flow control messages sent20.000.00
gcs assume cvt00.000.00
gcs assume no cvt9,6752.051.73
gcs ast xid10.000.00
gcs blocked converts7,0991.501.27
gcs blocked cr converts8,4421.791.51
gcs compatible basts450.010.01
gcs compatible cr basts (global)2730.060.05
gcs compatible cr basts (local)12,5932.662.25
gcs cr basts to PIs00.000.00
gcs cr serve without current lock00.000.00
gcs dbwr flush pi msgs2230.050.04
gcs dbwr write request msgs2230.050.04
gcs error msgs00.000.00
gcs forward cr to pinged instance00.000.00
gcs immediate (compatible) converts2,9980.630.54
gcs immediate (null) converts170,92536.1630.53
gcs immediate cr (compatible) converts00.000.00
gcs immediate cr (null) converts722,748152.88129.11
gcs indirect ast306,81764.9054.81
gcs lms flush pi msgs00.000.00
gcs lms write request msgs1890.040.03
gcs msgs process time(ms)16,1643.422.89
gcs msgs received1,792,132379.09320.14
gcs out-of-order msgs00.000.00
gcs pings refused00.000.00
gcs pkey conflicts retry00.000.00
gcs queued converts20.000.00
gcs recovery claim msgs00.000.00
gcs refuse xid00.000.00
gcs regular cr00.000.00
gcs retry convert request00.000.00
gcs side channel msgs actual4370.090.08
gcs side channel msgs logical21,0864.463.77
gcs stale cr3,3000.700.59
gcs undo cr50.000.00
gcs write notification msgs230.000.00
gcs writes refused30.000.00
ges msgs process time(ms)1,2890.270.23
ges msgs received138,89129.3824.81
global posts dropped00.000.00
global posts queue time00.000.00
global posts queued00.000.00
global posts requested00.000.00
global posts sent00.000.00
implicit batch messages received81,18117.1714.50
implicit batch messages sent19,5614.143.49
lmd msg send time(ms)00.000.00
lms(s) msg send time(ms)00.000.00
messages flow controlled15,3063.242.73
messages queue sent actual108,41122.9319.37
messages queue sent logical222,51847.0739.75
messages received actual474,202100.3184.71
messages received logical1,931,144408.50344.97
messages sent directly25,7425.454.60
messages sent indirectly137,72529.1324.60
messages sent not implicit batched88,85918.8015.87
messages sent pbatched1,050,224222.16187.61
msgs causing lmd to send msgs61,68213.0511.02
msgs causing lms(s) to send msgs85,97818.1915.36
msgs received queue time (ms)911,013192.71162.74
msgs received queued1,931,121408.50344.97
msgs sent queue time (ms)5,6511.201.01
msgs sent queue time on ksxp (ms)66,76714.1211.93
msgs sent queued215,12445.5138.43
msgs sent queued on ksxp243,72951.5643.54
process batch messages received120,00325.3821.44
process batch messages sent181,01938.2932.34


Back to Top

Global CR Served Stats

StatisticTotal
CR Block Requests10,422
CURRENT Block Requests251
Data Block Requests10,422
Undo Block Requests2
TX Block Requests20
Current Results10,664
Private results4
Zero Results5
Disk Read Results0
Fail Results0
Fairness Down Converts1,474
Fairness Clears0
Free GC Elements0
Flushes370
Flushes Queued0
Flush Queue Full0
Flush Max Time (us)0
Light Works2
Errors0


Back to Top

Global CURRENT Served Stats

  • Pins = CURRENT Block Pin Operations
  • Flushes = Redo Flush before CURRENT Block Served Operations
  • Writes = CURRENT Block Fusion Write Operations
StatisticTotal% <1ms% <10ms% <100ms% <1s% <10s
Pins17,53499.960.010.030.000.00
Flushes7748.0546.755.190.000.00
Writes2555.4953.7340.000.780.00


Back to Top

Global Cache Transfer Stats

  • Immediate (Immed) - Block Transfer NOT impacted by Remote Processing Delays
  • Busy (Busy) - Block Transfer impacted by Remote Contention
  • Congested (Congst) - Block Transfer impacted by Remote System Load
  • ordered by CR + Current Blocks Received desc
CRCurrent
Inst NoBlock ClassBlocks Received% Immed% Busy% CongstBlocks Received% Immed% Busy% Congst
2data block3,94587.2012.800.0013,32499.710.260.04
2Others191100.000.000.002,19096.483.520.00
2undo header11100.000.000.002100.000.000.00


Back to Top

End of Report


OLTP:联机事务处理

OLAP是主要应用数据仓库系统

OLTP是一般的项目开发用到的基本的、日常的事务处理;比如数据库记录的增、删、改、查。



理论实践:循序渐进理解AWR细致入微分析性能报告

黄凯耀 (Kaya) ACOUG核心会员,高级技术专家

曾经工作于Oracle Real World Database Performance Group,一个隶属于Oracle公司总部数据库产品管理的核心团队。大学及研究生时期专注于Linux应用开发和Linux内核开发工作。

编辑手记:AWR是Oracle数据库中一个非常重要的诊断工具,通过度量而展现问题,每一个DBA都应当深入理解这其中的知识,本文通过讲解和分析,展示AWR分析的过程。

概述:本篇文章重点对 AWR 报告中的 DB Time、DBCPU、IO 等数据进行了说明,可帮助读者更加清楚的理解这些数据代表的含义,与数据库的性能表现有何关系。同时通过两个简短的例子,实践如何分析 AWR 报告。

\1. AWR 概述

Automatic Workload Repository(AWR) 是10g引入的一个重要组件。在里面存贮着近期一段时间内(默认是7天)数据库活动状态的详细信息。

AWR 报告是对 AWR 视图进行查询而得到的一份自动生成的报告。可以通过下面的脚本手工得到一份 AWR 报告。

img

通过 AWR 和 AWR 报告,DBA 可以容易地获知最近数据库的活动状态,数据库的各种性能指标的变化趋势曲线,最近数据库可能存在的异常,分析数据库可能存在的性能瓶颈从而对数据库进行优化。

AWR 报告所有的数据来源于 AWR 视图,即以 DBA_HIST_开头的所有系统表,Database Reference 有对所有这些系统表的描述,这应该是 Oracle 官方对 AWR 报告的官方注释了。而对于如何有效地去分析 AWR 报告,这可能更需要 DBA 经验的日积月累。

AWR的前身是Statspack,Statspack在10g和11g中也有提供,同时和AWR一起做了同步更新,而且Statspack是公开源代码的,因此,关于Statspack的资料,还有Statspack的源代码,都是理解AWR的一个有用的辅助。

本文着重对AWR中的一些要点进行剖析,欢迎一起讨论AWR相关的问题。

\2. DB CPU - CPU负载分析

如果关注数据库的性能,那么当拿到一份 AWR 报告的时候,最想知道的第一件事情可能就是系统资源的利用情况了,而首当其冲的,就是 CPU。

而细分起来,CPU 可能指的是:

OS 级的 User%,Sys%, Idle%

DB 所占 OS CPU 资源的 Busy%

DBCPU 又可以分为前台所消耗的 CPU 和后台所消耗的 CPU

如果数据库的版本是11g,那么很幸运的,这些信息在AWR报告中一目了然:

img

img

分析上面的图片,我们可以得出下面的结论:

OS 级的 User%,Sys%,Idle%:

OS 级的 %User 为75.4,%Sys 为2.8,%Idle 为21.2,所以 %Busy 应该是 100-21.1=78.8。

DB所占OSCPU资源的Busy%

DB占了OS CPU资源的69.1,%Busy CPU则可以通过上面的数据得到:

%Busy CPU = %Total CPU/(%Busy) 100 = 69.1/78.8 100 = 87.69,和报告的87.7相吻合。

如果是10g呢,则需要手工对 Report 里的一些数据进行计算了。

Host CPU 的结果来源于 DBA_HIST_OSSTAT,AWR 报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是centi second,也就是1/100秒)

img

根据上面的数据,稍加计算分析便可得出下面的结果。

OS级的User%,Sys%,Idle%:

%User = USER_TIME/ (BUSY_TIME+IDLE_TIME)100 =146355/ (152946+41230)100 = 75.37

%Sys = SYS_TIME/ (BUSY_TIME+IDLE_TIME)100=5462/(152946+41230)100=2.81

%Idle = IDLE_TIME/ (BUSY_TIME+IDLE_TIME)100=21230/(152946+41230)100=10.93

值得注意的,这里已经隐含着这个AWR报告所捕捉的两个Snapshot之间的时间长短了。有下面的公式:

BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT

注意:正确的理解这个公式可以对系统CPU资源的使用及其度量的方式有更深一步的理解。

因此ELAPSED_TIME =(152946+41230)/8/100 = 242.72 seconds

至于DB对CPU的利用情况,这就涉及到10g新引入的一个关于时间统计的视图V$SYS_TIME_MODEL,简单而言,Oracle采用了一个统一的时间模型对一些重要的时间指标进行了记录,具体而言,这些指标包括:

\1) Background elapsed time

\2) Background CPU time

\3) RMAN CPU time (backup/restore)

\1) DB time

\2) DB CPU

\2) Connection management call elapsed time

\2) Sequence load elapsed time

\2) SQL execute elapsed time

\2) Parse time elapsed

\3) Hard parse elapsed time

\4) Hard parse (sharingcriteria) elapsed time

\5) Hard parse (bindmismatch) elapsed time

\3) Failed parse elapsed time

\4) Failed parse (out of sharedmemory) elapsed time

\2) PL/SQL execution elapsed time

\2) Inbound PL/SQL RPC elapsed time

\2) PL/SQL compilation elapsed time

\2) Java execution elapsed time

\2) Repeated bind elapsed time

这里我们关注的只有和 CPU 相关的两个: Background CPU time 和 DB CPU。

这两个值在 AWR 里面也有记录:

img

Total DB CPU = DB CPU + Background CPUtime = 1305.89 + 35.91 = 1341.8 seconds

Total DB CPU除以总的 BUSY_TIME + IDLE_TIME可得出% Total CPU。

% Total CPU = 1341.8/1941.76 = 69.1%,这刚好与上面Report的值相吻合。

其实,在 Load Profile 部分,我们也可以看出DB对系统CPU的资源利用情况。

img

用 DBCPU per Second 除以 CPU Count 就可以得到 DB 在前台所消耗的 CPU% 了。这里 5.3/8 = 66.25 %比69.1%稍小,说明DB在后台也消耗了大约3%的 CPU,这是不是一个最简单的方法了呢?

\3. DB Time – 进程消耗时间分析

DB CPU 是一个用于衡量 CPU 的使用率的重要指标。假设系统有N个 CPU,那么如果 CPU全部处于繁忙状态的话,一秒钟内的 DBCPU 就是N秒。

如何去表征一个系统的繁忙程度呢?除了利用 CPU 进行计算外,数据库还会利用其它计算资源,如网络、硬盘、内存等等,这些对资源的利用同样可以利用时间进行度量。假设系统有M个 Session 在运行,同一时刻,有的 Session 可能在利用 CPU,有的 Session 可能在访问硬盘,那么,在一秒钟内,所有 Session 的时间加起来就可以表征系统在这一秒内的繁忙程度,一般的,这个和的最大值应该为 M。这其实就是 Oracle 提供的另一个重要指标:DB Time,它用以衡量前端进程所消耗的总时间。

对除 CPU 以外的计算资源的访问,Oracle 用等待事件进行描述。同样地,和 CPU 可分为前台消耗 CPU 和后台消耗 CPU一样,等待事件也可以分为前台等待事件和后台等待事件。

DB Time 一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。等待时间通过 V$SYSTEM_EVENT 视图进行统计,DB Time 和 DBCPU 则是通过同一个视图,即V$SYS_TIME_MODEL 进行统计。

Load Profile 一节就有了对 DB Time 的描述:

img

这个系统的 CPU 个数是8,因此我们可以知道前台进程用了系统 CPU 的7.1/8=88.75%。 DB Time/s 为11.7,可以看出这个系统是 CPU 非常繁忙的。里面 CPU 占了7.1,则其它前台等待事件占了11.7 –7.1 = 4.6 Wait Time/s。DB CPU 占 DB Time 的比重呢? 7.1/11.7= 60.68%

Top 5 Timed Events,或许很多人都对它有所耳闻,按照 CPU/ 等待事件占 DB Time 的比例大小,这里列出了 Top 5。如果一个工作负载是 CPU 繁忙型的话,那么在这里应该可以看到 DB CPU 的影子。

img

注意到,我们刚刚已经算出了 DB CPU 的 %DB time 为60%左右。

其它的 externaltable read,direct path write, PX Deq: read credit, PXDeq: Slave Session Stats 这些就是占比重40%的等待事件里的 Top 4了。

回过头再研究下这个 Top 5 Timed Foreground Events,如果先不看 Load Profile,你能说出这个一个 CPU-Bound 的工作负载吗?

答案是否定的,要知道系统 CPU 的繁忙程序,还要知道这个 AWR 所基于两个 Snapshot 的时间间隔,还要知道系统 CPU 的个数。否则,系统可以是一个很 IDLE 的系统呢。记住 CPU 利用率= DB CPU/(CPU_COUNT*Elapsed TIME)。

这个 Top5 给我们的信息只是这个工作负载应该是并行查询,从外部表读取数据,并用 insert append 的方式写入磁盘,同时,主要时间耗费在 CPU 的运算上。

上面提到,DB Time 一般的应该等于 DB CPU + 前台等待事件所消耗时间的总和。在下面有对这三个值的统计:

img

DB CPU = 6474.65

DB TIME = 10711.2

FG Wait Time = 1182.63

明显的,DBCPU + FG Wait Time < DB Time,只占了71.5%

其它的28.5%被消耗到哪里去了呢?这里其实又隐含着一个 Oracle 如何计算 DBCPU 和 DB Time 的问题。当 CPU 很忙时,如果系统里存在着很多进程,就会发生进程排队等待 CPU 的现象。在这样,DB TIME 是把进程排队等待 CPU 的时间算在内的,而 DB CPU 是不包括这一部分时间。这是造成 DB CPU + FG Wait Time < DB Time 的一个重要原因。如果一个系统 CPU 不忙,这两者应该就比较接近了。

不要忘了在这个例子中,这是一个 CPU 非常繁忙的系统,而71.5%就是一个信号,它提示着这个系统可能是一个 CPU-Bound 的系统。

\4. IO数据分析

除了 DBCPU、DB Time,或许另一个比较常用的指标应该是 IO 的利用情况。关于 IO 的指标就比较多了,单单在 Load Profile 里面就有5个,在 DBTime 和 DB CPU 的下面:

img

这5个指标的值都来自 V$SYSTAT 视图,分别是:

Redo Size: 'redo size'

Logical reads = 'session logical reads'or ('db block gets' + 'consistent gets')

Blocks Changes = 'db block changes'

Physical reads = 'physical reads'

Physical writes = 'physical writes'

具体指标的解释可以参考Database Reference()

如何得到系统大致的 MBPS(Megabits Per Second) 呢?

MBPS= (Physical reads + Physical writes) Block_Size = (196,271.4+2.0)8*1024/1024/1024 = 1533 MB/s

更准确的 MBPS 可以从 Instance Activity Stats 部分获得。

img

Physical IO disk bytes = physical read total bytes+ physical write total bytes

值得注意的是这里 physical write total bytes 大致是 physical writebytes 的两倍。这应该是 physical write total bytes 统计的是磁盘的 IO,而这里,我们做了 ASM,normal redundancy,一份数据写了两遍的原因。

Load Profile 剩下的部分主要是关于各种执行情况的统计,除了 W/A MB processed 来自 V$PGASTAT(单位其实也是 Byte,不是 MB),其它数据都是来自于 V$SYSSTAT。

Blocks Changes: 'db block changes'

User calls: 'user calls'

Parses: 'parse count (total)'

Hard parses: 'parse count (hard)'

Logons: 'logons cumulative'

Executes: 'execute count'

Rollbacks: 'user rollbacks'

Tranasactions: 'user rollbacks' + 'usercommits'

W/A MB processed: 'bytes processed'

一般而言,Hard parses < Parses < Executes < User Calls。

AWR 的一般性介绍我想差不多就这些了,其它部分的介绍借助于一些更具体的 AWR 报告进行分析可能会更加方便和清晰。

\5. AWR 报告分析 – 实战1

构建 DSS 系统的第一步离不开数据加载,通过文本文件加载是最常见的方式,Oracle 提供了外部表加载的方法,即把一个文本文件当成一个正常的表来进行操作,通过类似 insert /+ append / into table select from external_table 的方式进行加载。

数据加载是一个 CPU-Bound 的过程,不过是通过什么工具,external table 也好,sqlldr 也好,imp 也好,impdp 也好。换句话说,如果连数据加载都出现 IO 瓶颈,这个系统的配置就说不过去了。

这个过程的 AWR 报告会是什么样子的呢?

先做个一般的假定,从外部表加载数据到一个本地分区表。

Top 5 TimedEvents 类似下面:

img

如果去抓取这段时间 DBA_HIST_ACTIVE_SESS_HISTORY 的数据,并转换为图表的话,我们会得到更形象的 Top 10 Wait Events。(如何实现这一步可以参考用 Oracle 实现 ASH 的数据透视图:http://www.cnblogs.com/rootq/archive/2009/09/24/1573200.html

img

enq: HV –contention 是什么东西呢?

在11.2以前,对于分区表的 parallel direct-path load,Oracle 采用的是 brokered load 的方式,即所有的 PX Slaves 共享对每个分区的 high water mark 的访问,通过轮流持有 high water mark 实现对每个 segment 添加新的 blocks。这种方法对于充分利用 extent 的空间是有帮助的,不过带来的问题就是对 high water mark 的竞争,也就是这里的 enq: HV – contention。在执行计划中,这以 RANDOM LOCAL 标记。下面是一个例子:

img

一个好消息是,11.2引入了一种新的方式,叫做 PKEY distribution。在这种方式下,一个特定的分区只交给一个或多个特定的 PX slave 负责,这种方式不仅减少了对 high water mark 的争用,而且可以实现 Partition 内更好的压缩率。

\6. AWR报告分析 – 实战2

有一次跟一个 QQ 上的朋友一起探讨了另一个对系统 CPU 进行度量的指标: CPUused by this session。

他刚好有一份 AWR 报告,在这份报告里,出现了严重的 CPU used by this session 和 DB CPU 不一致的现象。

下面是这份报告的一些片断:

img

img

img

img

再做进一步的归纳:

OS Busy% =1821080/(1821080+5384293) = 25%

Inst CPU% (usingDB CPU) = 8934.22*100/ (1821080+5384293)=12%

Inst CPU% (usingCPU used by this session) = 418035/ (1821080+5384293) = 6%

用 CPU used by this session 计算出的 CPU 利用率竟然只是用 DB CPU 计算出来的利用通率的一半!

我的第一个反应是在 Jonathan Lewis 网站看到的一篇相关文章,里面提到了 DB CPU 和 CPUused by this session 计算时的不同之处:()

"Prior to10g Oracle usually updated time figures at the end of each database call; butfrom 10g there are some views where time is updated more regularly.

The "DB CPU" from v$sess_time_model increases every six seconds, while the "CPU used by this session" from v$sesstat changes only at the end of the test."

如何验证这一点呢?

在浏览这份报告的 TOP SQL 时,我们发现了下面的现象:

img

这是从 SQL ordered by Elapsed Time 截取出来的 Top 3 SQL。TOP 1 的 SQL 用了 DB Time 的30.10%,用了2517s 的 CPU Time。但请注意它的 Executions 的值却为0。也就是说,这里的 CPU Time 是还没有被计算入 CPU used by this session 这个指标里面的。

我们再把2517s加回来,看出误差缩小多少:

(251700+418035)/(1821080+5384293) = 9%

这时和用 DB CPU 计算出来的12%还是有1/4的差距。

从这个例子可以看出,用 DB CPU 度量还是比用 CPU usedby this session 来得准确的。特别在有大查询在跑的过程中抓的 AWR,这个误差很有可能会被放大。这是一个有趣的实际例子。

\7. 总结

AWR 是分析数据库运行状况的利器,将其运用好可帮助 DBA 提早发现数据库中存在的问题并加以解决。文中主要对 DB CPU、DB Time、IO 等 AWR 报告中的数据进行了分析说明,当然分析AWR报告不能仅限于此,更需要DBA日积月累的经验。希望本文对想了解 AWR 的朋友有一定帮助。

标签:

头像

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

19 − 6 =

 

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部
返回顶部