sql统计在数据库性能分析中扮演着关键角色,主要包括以下几个方面的排序:
-
按运行时间排序的SQL:该排序依据是SQL语句在监控范围内的总执行时间(Elapsed Time),而不是单次执行的时间。Elapsed Time包括CPU时间和等待时间。报告中显示了占总数据库时间的百分比(%Total DB Time),CPU占比(%CPU),以及用户I/O等待时间占比(%IO)。这里特别关注执行次数和平均每次运行时间,尤其是那些平均运行时间较长的SQL,因为它们通常是CPU和I/O消耗的主要来源。

-
按CPU时间排序的SQL:此排序展示了在监控范围内占用CPU时间最长的SQL。报告中同样包括了CPU占比和I/O占比。重点关注的是每次执行的CPU时间(CPU per Exec)和CPU占比。

-
按用户I/O等待时间排序的SQL:排序基于SQL在监控范围内的总用户I/O等待时间。重点关注的是每次执行的用户I/O等待时间(UIO per Exec)和I/O占比,通常与会话堵塞和全表扫描有关。

-
按Gets排序的SQL:此排序展示了在监控范围内占用buffer gets(逻辑I/O)最多的SQL。关注点包括每次执行的Gets数量(Gets per Exec)、CPU占比和I/O占比。Gets是衡量SQL性能的主要指标之一。

-
按读取排序的SQL:此排序基于SQL在监控范围内的总物理读(物理I/O)次数。过高的物理读次数可能导致数据库性能下降,解决方案包括SQL优化、增加SGA大小、调整_small_table_threshold等。

-
按物理读取排序的SQL(未优化):此排序展示了未优化物理读取的SQL。未优化读请求是物理读请求减去优化读请求。该指标主要适用于Exadata系统,对于其他系统没有参考意义。

-
按执行排序的SQL:此排序展示了在监控范围内执行次数最多的SQL。关注执行次数、每次执行的行数、运行时间、CPU占比和I/O占比。

-
按解析调用排序的SQL:此排序展示了在监控范围内解析次数最多的SQL。解析次数过多可能导致性能问题,特别是当解析次数大于执行次数时。

-
按共享内存排序的SQL:此排序展示了占用library cache内存最多的SQL。关注点是占用的共享内存大小(Sharable Mem)。

-
按版本计数排序的SQL:此排序展示了打开子游标数量最多的SQL。版本计数高可能导致库缓存锁定等问题。

-
SQL文本的完整列表:提供所有SQL语句的详细文本信息,便于进一步分析和调优。

总体来看,SQL统计从多个维度列出了系统中执行较慢的SQL,用户可以通过点击详情获取更多信息,并利用执行计划进行SQL优化。
以上就是一个Oracle小白的AWR报告分析(五)的详细内容,更多请关注php中文网其它相关文章!