此图表显示执行最大物理读取数的 SQL 语句。
提高 SQL 性能通常是提高应用程序性能的最有效的方法。在识别最有可能提高性能的语句时，您可能应该考虑 I/O 需求最高的语句。换句话说，考虑具有最大读取请求数的语句，且这些读取请求会导致访问磁盘上的数据文件。
另一个值得考虑的因素是执行该语句的频率。高 I/O 级别的语句可能每天只执行一次，执行次数比其他每天执行数千次的较低 I/O 级别语句要少得多。
查询导致过多磁盘读取的原因有很多种；例如一个全表扫描正在被执行。
还有大量的下钻图表可用于进一步诊断 I/O 的起因，它们包括：
有关如何最佳优化特定 SQL 语句的进一步研究，可通过选择所列出的任一 SQL 语句并使用 SQL Analyze 工具来进行。
此图表包括下列数据项：
此图表显示完整 SQL 文本，该文本是在某些 TOP SQL 图表中截断的。
某些 TOP SQL 图表中所显示的 SQL 是一种截断值，因为从 V$SQLAREA 中只可获得截断值。要获取完整 SQL 文本，必须查询 V$SQLTEXT_WITH_NEWLINES，以聚集查询的各个段。出于性能上的考虑，仅会在需要显示完整 SQL 文本时才显示此图表。
此图表包括下列数据项：
此图表使用可从数据库获得的统计数据为用户显示我们对总响应时间的最佳估计。这里将响应时间定义为数据库内所有会话所消耗的总等待时间加上总 CPU 时间，它除以提交数与回退数之和就得出每个事务处理的值。如果正在以只读模式访问数据库，或者未将 TIMED_STATISTICS 设置为 TRUE，则每个事务处理的值可能显示为 0。
监视只读数据库时，度量响应时间的较好方法可能基于每个执行，即每个 SQL 语句执行的平均时间长度。要查看此统计数据，请参阅每个执行花费的时间图表。
有关响应时间的各个部分 (即 CPU 时间和等待时间) 的进一步研究结果，可通过下钻到等待或受 CPU 限制得到。
此图表包括下列数据项：
此图表显示在采样周期内提交和回退的事务处理，以及 SQL 执行计数。这是一个良好的吞吐量概览。
此图表包括下列数据项：
此图表基于每个用户显示每个事务处理响应时间的细目分类。
跨每个用户的所有会话来总计 CPU 时间和等待时间。此图表有助于监视将其功能分散到不同用户的应用程序的响应时间。
此图表包括下列数据项：
此图表按用户显示吞吐量或负载统计数据。跨用户的所有会话来总计这些统计数据。
此图表包括下列数据项：
此图表是一个跨例程的事件列表，按照每个事件类型的等待时间总和来排序。
此列表将使用户能够快速识别例程等待哪个事件时间最长。每种事件类型受不同参数和条件的影响。进一步下钻是通过选择感兴趣的特定等待事件来完成的。一些等待事件具有专门的下钻图表以帮助诊断该等待的原因。
还有一般下钻，可用于所有等待事件。要确定有多少会话当前正在等待特定的事件，请使用等待此事件的会话图表。类似地，要查看当前正在等待此事件的 SQL 语句，请使用等待此事件的 SQL 语句图表。这会将您快速引向正在经历等待的 SQL 语句，并帮助您确定此等待对应用程序的影响。
此图表包括下列数据项：
此图表显示在采样周期内发生的例程范围内的等待数。仅显示具有非零计数的事件。也将显示等待计数以及超时数。
等待计数不如等待花费的实际时间重要。一个会话可能请求一种资源，并发出一个等待，但请求可能会被立即批准。尽管实际上并未发生等待时间，但等待计数仍将增加。
此图表包括下列数据项：
此图表与缓冲区忙事件有关。确定数据库正在等待的块 (缓冲区) 的类型将决定一种可能的解决方案，以减少对那些块的争用。我们感兴趣的三种类型的块是段标题块、数据块和空闲列表块。
本节简要说明这三种块类型。
段标题块等待数：
问题：由于对某个表有大量插入，事务处理的空闲列表就可能不足，因而访问事务处理的空闲列表就成了一个瓶颈。解决方案：添加更多的空闲列表组。还可能添加更多的空闲列表组，以解决太小的块限制空闲列表数 (甚至在独占模式下也是如此) 的局限性。
问题：由于表在不断增大，且不断地将所有的块用于空闲列表的新插入条目，所以该表的高水线标记 (HWM) 可能会一直增加。提升 HWM 的缺省值是 5，在一个忙碌的系统上，或相对平均插入大小，此值可能太小。解决方案：可以通过 init.ora 参数 _BUMP_HIGHWATER_MARK_COUNT 将 HWM 值增加到 255。注：此参数将确定在提升 HWM 时每个空闲列表应分配多少个块。因此，如果空闲列表的数目也很高的话，会使表增加到非常大。例如，如果我们有 100 个空闲列表，且设置 _BUMP_HIGHWATER_MARK_COUNT=100，这就意味着将 10000 个块 (可能) 添加到了区中。
问题：区的容量太小，因此表在持续增长。作为一条规则，拥有少量非常大的区比拥有大量很小的区要好。解决方案：增大每个区的尺寸。
数据块：用来存储数据 (索引或数据)。问题：多个会话可能同时从磁盘上读取同一个块 (这个问题每个块类都可能发生)。只有一个会话将进行读取，其他的会话将一直在缓冲区高速缓存中等待该块被读完。这些其他会话将在该缓冲区忙的等待事件中一直等待下去。解决方案：缓冲区高速缓存可能太小，无法将当前工作集保留在内存中。增大缓冲区高速缓存 (db_block_buffers) 将会有帮助，或者使用缓冲池以减少一个对象可能占用的缓冲区数 (例如，限制随机访问大型表或历史记录表在缓冲区高速缓存中可能占用的缓冲区数)。
问题：多个会话都在试图访问某个块中的同一行。因为每个块有太多的行 (大数据块中的很多小行)，所以可能出现此问题。解决方案：减少每个块的行数 (需要更改 pctfree/pctuse 设置)。这是时间优化的空间。此表将使用更多的空间，但缓冲区忙等待的等待时间将减少。
问题：多个会话试图插入同一个块。为何是同一个块的原因是只有一个空闲列表 (或者空闲列表不够)。空闲列表只有一个头部。解决方案：将多个空闲列表添加到对象中将增加空闲列表的头部数目。这样就将争用点分布于各个空闲列表上，从而减少了缓冲区忙等待数。
空闲列表块：添加更多的空闲列表。如果是并行服务器，请确保每个例程都有其自身的一个或多个空闲列表组。
还原标题块：添加更多的回退段 (在独占模式下运行时)。将每个回退段的事务处理设置为 1 (独占模式)。
还原块：请考虑在独占模式下使回退段变大或仅以并行服务器模式增加 PCM 锁 (GC_ROLLBACK_LOCKS) 的数目。 此图表包括下列数据项：
此图表与缓冲区忙事件有关。确定数据库正在等待的块 (缓冲区) 的类型将决定一种可能的解决方案，以减少对那些块的争用。我们感兴趣的三种类型的块是段标题块、数据块和空闲列表块。
本节简要说明这三种块类型。
段标题块等待数：问题：由于对某个表有大量插入，事务处理的空闲列表就可能不足，因而访问事务处理的空闲列表就成了一个瓶颈。解决方案：添加更多的空闲列表组。还可能添加更多的空闲列表组，以解决太小的块限制空闲列表数 (甚至在独占模式下也是如此) 的局限性。
问题：由于表在不断增大，且不断地将所有的块用于空闲列表的新插入条目，所以该表的高水线标记 (HWM) 可能会一直增加。提升 HWM 的缺省值是 5，在一个忙碌的系统上，或对于平均插入大小，此值可能太小。解决方案：可以通过 init.ora 参数 _BUMP_HIGHWATER_MARK_COUNT 将 HWM 值增加到 255。注意：此参数将确定在提升 HWM 时每个空闲列表应分配多少块。因此，如果空闲列表的数目也很高的话，会使表增加到非常大。例如，如果我们有 100 个空闲列表，且设置 _BUMP_HIGHWATER_MARK_COUNT=100，这就意味着将 10000 个块 (可能) 添加到了区中。
数据块：用来存储数据 (索引或数据)。问题：多个会话可能同时从磁盘上读取同一个块 (这个问题每个块类都可能发生)。只有一个会话将进行读取，其他的会话将一直在缓冲区高速缓存中等待该块被读完。这些其他会话将在该缓冲区忙的等待事件中一直等待下去。解决方案：可能是缓冲区高速缓存太小以致于不能将当前工作集保存在内存中。增大缓冲区高速缓存 (db_block_buffers) 将会有帮助，或者使用缓冲区池以减少一个对象在缓冲区高速缓存中可能占用的缓冲区数 (例如，限制随机访问大型表或历史记录表在缓冲区高速缓存中可能占用的缓冲区数)。
问题：多个会话都在试图访问某个块中的同一行。因为每个块有太多的行 (大数据块中的很多小行)，所以可能出现此问题。解决方案：减少每个块的行数 (需要更改 pctfree/pctuse 设置)。这是时间优化的空间。表将使用更多的空间，但缓冲区忙等待的等待时间将减少。
问题：多个会话试图插入同一个块。为何是同一个块的原因是只有一个空闲列表 (或者空闲列表不够)。空闲列表只有一个头部。解决方案：把多个空闲列表添加到对象将增加空闲列表的头部数目。这样就将争用点分布于各个空闲列表上，从而减少了缓冲区忙等待数。
问题：因为对空闲列表的新插入导致此表增大并用尽块，所以可能持续增加此表的高水线标记。提升 HWM 的缺省值是 5，在一个忙碌的系统上，或对于平均插入大小，此值可能太小。解决方案：可以通过 init.ora 参数 _BUMP_HIGHWATER_MARK_COUNT 将 HWM 值增加到 255。注意：此参数将确定在提升 HWM 时每个空闲列表应分配多少块。因此，如果空闲列表的数目也很高的话，会使表增加到非常大。例如，如果我们有 100 个空闲列表，且设置 _BUMP_HIGHWATER_MARK_COUNT=100，这就意味着将 10000 个块 (可能) 添加到了区中。
数据块：用来存储数据 (索引或数据)。问题：多个会话可能同时从磁盘上读取同一个块 (这在每个块类上都可能发生)。只有一个会话将进行读取，其他的会话将一直在缓冲区高速缓存中等待该块被读完。这些其他会话将在该缓冲区忙的等待事件中一直等待下去。解决方案：可能是缓冲区高速缓存太小以致于不能将当前工作集保存在内存中。增大缓冲区高速缓存 (db_block_buffers) 将会有帮助，或者使用缓冲区池以减少一个对象在缓冲区高速缓存中可能占用的缓冲区数 (例如，限制随机访问大型表或历史记录表在缓冲区高速缓存中可能占用的缓冲区数)。
问题：多个会话都在试图访问某个块中的同一行。因为每个块有太多的行 (大数据块中的很多小行)，所以可能出现此问题。解决方案：减少每个块的行数 (需要更改 pctfree/pctuse 设置)。这是时间优化的空间。表将使用更多的空间，但缓冲区忙等待的等待时间将减少。
问题：多个会话试图插入同一个块。为何是同一个块的原因是只有一个空闲列表 (或者空闲列表不够)。空闲列表只有一个头部。解决方案：把多个空闲列表添加到对象将增加空闲列表的头部数目。这样就将争用点分布于各个空闲列表上，从而减少了缓冲区忙等待数。
空闲列表块：添加更多的空闲列表。如果是并行服务器，请确保每个例程都有其自身的一个或多个空闲列表组。
还原标题块：添加更多的回退段 (在独占模式下运行时)。将每个回退段的事务处理设置为 1 (独占模式)。
还原块：请考虑在独占模式下使回退段变大或仅以并行服务器模式增加 PCM 锁 (GC_ROLLBACK_LOCKS) 的数目。 此图表包括下列数据项：
此图表显示执行最大缓冲区获取数的 SQL 语句。
提高 SQL 性能通常是提高应用程序性能的最有效的方法。在标识最有可能提高性能的语句时，您可能需要考虑缓冲区获取最高的语句。缓冲区获取数 (或逻辑读取数) 是 CPU 时间的贡献者之一，因为它要求从高速缓存中定位和检索缓冲区。
另一个值得考虑的因素是执行该语句的频率。高缓冲区获取数的语句可能每天只执行一次，执行次数比其他每天执行数千次的较少缓冲区获取数语句要少得多。
查询导致过多缓冲区获取的原因有很多种；例如一个全表扫描正在被执行。
有关如何最佳优化特定 SQL 语句的进一步研究，可通过选择所列出的任一 SQL 语句并使用 SQL Analyze 工具来进行。
优化这些语句将导致用于应用程序的 CPU 时间的减少。在确定应该首先优化哪一条 SQL语句时执行计数也是重要的。最高缓冲区获取计数的语句可能一天执行一次，频率比列表中的另一个语句要少得多。调整最高计数的 SQL 语句对此情况下应用程序或系统的改善可能会不如执行频率高得多的语句。
此图表将标识执行最大缓冲区获取数的 SQL 语句。为何查询正在执行这些缓冲区获取可能有多种原因，其中全表扫描是一个常见的原因。为帮助进一步诊断引起问题的原因，有很多可用的下钻图表。此图表中显示的 SQL 限定了固定的字符数。要查看全 SQL 文本，请使用 SQL 文本 。要查看此查询引用的表和检查优化程序所使用的统计数据的有效性，请使用此查询所引用的表图表。要查看按“物理读取数”排序的 SQL，请使用顶层 SQL (物理读取数)图表。
有关如何最佳优化特定 SQL 语句的进一步研究，可通过选择所列出的任一 SQL 语句并使用 SQL Analyze 工具来实现。
此图表包括下列数据项：
此图表将按照 I/O 的平均成本为最差的数据库文件排列在最前面。I/O 的成本是指读取时间/物理读取数。此图表将显示一个给定文件可以被选来进行条带化处理，或者显示应该增加条带宽度或条带化处理中涉及的磁盘总数。
如果每个 I/O 的平均成本很高，则表示需要增加条带宽度或条带化处理所涉及的磁盘总数。另外，请查看每个事务处理的总 I/O 数,每个事务处理的 I/O 速率，然后查看有多少并发事务处理正在运行。例如：如果每个事务处理需要两个读操作和一个写操作，并希望每秒执行 1000 个事务处理，则此计算要求系统实际上每秒能处理 3000 次 I/O。因此，如果一个磁盘每秒钟可以执行 50-100 次 I/O，则至少需要 60 个磁盘 (3000/50)。现在如果需求从每秒 1000 个事务处理增加一倍，即 2000 个事务处理，则需要将磁盘数增加一倍。
此图表包括下列数据项：
此图表列出数据库的数据文件并显示每秒的物理读取数和每秒的块读取数。此图表能够快速指出数据库中的热点文件。
此图表包括下列数据项：
此图表列出数据库的数据文件并显示每秒的物理写入数和每秒的写入块数。此图表能够快速指出数据库中的热点文件。
此图表包括下列数据项：
此图表显示对哪些文件执行了全表扫描、范围扫描或单块读取。正在执行单块 (以及它们内部的对象) 读取的文件可能被选来用于索引选择。
单个 I/O 操作中读取的块数由 init.ora 参数 db_file_multi_block_read_count 确定。
当某个文件的物理读取数与物理块读取数接近 (即当物理读取数除以物理块读取数的结果接近 1) 时，则在该文件上正在发生单块读取。如果结果值不接近 1，则在该文件上正在执行全表扫描或范围扫描。
对于正在执行单块读取的文件，请查看文件内的对象，以确定对这些对象进行索引是否适当。要减少散列读取数据库文件的成本，请检查每个磁盘上的文件位置、磁盘数和每个磁盘的条带大小 (此值应该为 2 * db_file_multi_block_read_count)
此图表有助于识别休眠计数最大的栓锁。休眠计数是通过轮选没有获取栓锁并强制栓锁休眠的次数。
当栓锁空闲等待数很大时，确定正在请求哪个栓锁是很重要的。当瓶颈是单个栓锁时，增大轮选计数可以有帮助。在这种情况下，轮选 CPU 比让进程休眠付出的成本要“更便宜”。另外，识别休眠数最高的栓锁将指向应用程序/数据库中的瓶颈。如果通过进一步的分析您可以消除此瓶颈，您将增大吞吐量比率。
栓锁被用来使对数据库中各种资源的访问同步化。调整各个栓锁要求对各个栓锁的进一步研究。
此图表包括下列数据项：
此图表显示所有栓锁的获取和丢失比率。此处的值是实际比率。计算对这些栓锁的争用并在栓锁争用 (>1% 潜在问题) 图表中显示。
此图表包括下列数据项：
此图表显示栓锁的争用量。如果以下两个条件之一为真，则栓锁争用可能会影响性能：
如果对于某个栓锁这两个条件之一为真，则尽量减少对该栓锁的争用。虽然一些具有许多 CPU 的计算机也许能够容许更多的争用而不会降低性能，但是这些争用阈值适合于大多数操作系统。
大多数栓锁争用事例发生在两个或多个 Oracle 进程并发地试图获取同一栓锁的时候。栓锁争用极少发生在单 CPU 计算机上，在此计算机上一次只能有一个进程是活动的。
要减少对重做分配栓锁的争用，您应该将任何单个进程持有栓锁的时间减至最少。要减少这一时间，请减少在重做分配栓锁上的复制。减小初始化参数 LOG_SMALL_ENTRY_MAX_SIZE 的值会减小在重做分配栓锁上复制的重做条目的数目和大小。
在多 CPU 计算机上，多个重做复制栓锁允许多个进程并发地将条目复制到重做日志缓冲区中。LOG_SIMULTANEOUS_COPIES 的缺省值是您的 Oracle 例程可用的 CPU 数。
如果您观察到对重做复制栓锁的争用，则通过增大 LOG_SIMULTANEOUS_COPIES 的值来添加更多的栓锁。请考虑使重做复制栓锁数为 Oracle 例程可用的 CPU 数的两倍。
LRU (最近最少使用) 栓锁控制缓冲区高速缓存中缓冲区的替换。对于对称多处理器 (SMP) 系统，Oracle 自动地将 LRU 栓锁数设置为等于系统上 CPU 数一半的值。对于非 SMP 系统，一个 LRU 栓锁就足够了。
对 LRU 栓锁的争用可能降低具有大量 CPU 的 SMP 计算机上的性能。通过查询 V$LATCH，V$SESSION_EVENT 和 V$SYSTEM_EVENT 您可以检测到 LRU 栓锁争用。要避免争用，请考虑绕过缓冲区高速缓存或重新设计应用程序。
通过使用初始化参数 DB_BLOCK_LRU_LATCHES，您可以指定系统上的 LRU 栓锁数。此参数设置所需 LRU 栓锁数的最大值。每个 LRU 栓锁控制一组缓冲区；Oracle 在这些组之间平衡替换缓冲区的分配。
要为 DB_BLOCK_LRU_LATCHES 选择适当的值，请考虑以下事项：
此图表包括下列数据项：
此图表显示为查找空闲缓冲区而扫描的平均缓冲区数。如果您的系统必须扫描前台中的太多缓冲区以查找空闲缓冲区，那么它会浪费 CPU 资源。
要解决此问题，请调整要更频繁地进行写入的一个或多个 DBWn 进程。您也可以增大缓冲区高速缓存的大小以启用一个或多个要维持的数据库写入器进程。通常，您将应该看到 1 个或 2 个缓冲区被扫描。如果正在被扫描的缓冲区数大于此数目，则请增大缓冲区高速缓存的大小或调整这个 (些) DBWn 进程。
此图表包括下列数据项：
此图表深入研究围绕“空闲缓冲区等待”事件的细节。空闲缓冲区等待可能是由在 LRU (最近最少使用)列表尾部扫描以查找空闲缓冲区的会话导致的。如果灰数据列表已满，则前台进程必须等待灰数据缓冲区写入磁盘。或者，扫描太多缓冲区的会话 (db_block_max_scan_count) 可以引起空闲缓冲区等待。在 Oracle7 中，很可能灰数据缓冲区列表比比任何其他列表都要完整，所以增加 db_block_write_batch 应该就足够了。
公式 1 + (已检查的空闲缓冲区数/已请求的空闲缓冲区数) 将计算会话为查找空闲缓冲区在 LRU 的尾部扫描的平均缓冲区数。如果此数字接近 1，则意味着会话能够很快找到平均缓冲区。如果此数目很大，这通常意味着大量“持续读取” (CR) 缓冲区正在 LRU 的尾部等待。
如果扫描的平均空闲缓冲区数太大，则 db_block_max_scan_count 参数可能太高，或者您可能需要增大 db_block_write_batch 参数。
此图表包括下列数据项：
此图表显示总分析计数、硬分析计数和执行计数。将 SQL 语句分析计数与执行计数相比，我们可以得知重新分析 SQL 语句的频率。在应用程序中通过更有效地使用游标、赋值变量等进行此区域内的大量优化可能是最好的。
如果分析计数很高，则应该检查以下事项：
此图表包括下列数据项：
此图表表明会话高速缓存游标的命中率。命中率对分析调用在会话游标高速缓存中找到游标的次数进行计数。
如果一个应用程序反复发出对同一 SQL 语句组的分析调用，则会话游标的重新打开可能影响系统性能。可以将会话游标存储在会话游标高速缓存中。此功能对于使用 Oracle Forms 设计的应用程序尤其有用，因为从一个表格切换到另一个表格会关闭与第一个表格相关联的所有会话游标。
Oracle 使用共享的 SQL 区域来确定是否对给定语句发出了多于三个分析请求。如果是这样，Oracle 将假定与此语句相关联的会话游标应该被存入高速缓存并将游标移动到会话游标高速缓存中。然后借助同一会话分析该 SQL 语句的随后请求在会话游标高速缓存中找到游标。
要启用会话游标高速缓存，您必须设置初始化参数 SESSION_CACHED_CURSORS。此参数的值是一个正整数，指定在高速缓存中存放的最大会话游标数。LRU (最近最少使用) 算法在需要时删除会话游标高速缓存中的条目以便为新条目腾出空间。
如果此统计数据在会话的总分析调用计数中所占百分比相对较低，您应该考虑将 SESSION_CACHED_CURSORS 设置为一个更大的值 (只要该值不会对操作系统分页和交换活动产生负作用)。
此图表包括下列数据项：
此图表显示监视缓冲区高速缓存连接动作时的一些关键统计数据。
Oracle 依靠 SGA 中的数据库缓冲区来存储最近使用的从磁盘读取的数据库数据块。一个例程中的数据库缓冲区集是数据库缓冲区高速缓存。缓冲区高速缓存被组织在以下两个列表中：灰数据列表和 LRU 列表。灰数据列表包含尚未写入磁盘的已修改缓冲区。LRU 列表包含空闲缓冲区、已连接缓冲区和灰数据缓冲区。DBWR 管理数据库缓冲区高速缓存以便用户进程总是能够找到空闲缓冲区。
此图表显示监视缓冲区高速缓存连接动作时的这些关键统计数据：
因为在这种情况下客户机并不打算使用缓冲区，所以客户机在释放缓冲区之前执行这样的检查时不会增大这些统计数据。
这些统计数据度量缓冲区上的长久持续读取连接频率为多大是有益的。如果客户机能够多次重用已连接缓冲区，那么这表明连接缓冲区是有用的。
此图表包括下列数据项：
此图表显示数据库中的响应时间，它被分解为两个组成部分：等待时间和 CPU 时间。用户应该能够从显示的百分比中快速确定哪一部分正在消耗花费时间的最大部分。通过选择等待时间或 CPU 时间并下钻到专用于这两个特定部分的图表可以完成对任一部分的进一步诊断。
此图表包括下列数据项：
Oracle 依靠 SGA 中的数据库缓冲区来存储最近使用的从磁盘读取的数据库数据块。一个例程中的数据库缓冲区集是数据库缓冲区高速缓存。缓冲区高速缓存被组织在以下两个列表中：灰数据列表和 LRU 列表。灰数据列表包含尚未写入磁盘的已修改缓冲区。LRU 列表包含空闲缓冲区、已连接缓冲区和灰数据缓冲区。
DBWR 管理数据库缓冲区高速缓存以便用户进程总是能够找到空闲缓冲区。缓冲区高速缓存效率 (由命中率度量)，记录特定查询所请求的数据块已在内存中的次数百分比。因为最近 (通常也是最频繁地) 使用的数据保存在内存中，所以缓冲区高速缓存的有效使用可以大大减少数据库上的 I/O 负载。
如果缓冲区高速缓存太小，频繁访问的数据将很快被从缓冲区高速缓存中清除出来，这将迫使从磁盘重新提取信息。因为磁盘访问比内存访问要慢得多，所以应用程序的性能将受到损害。另外，加在 I/O 子系统上的额外负担可能在一个或多个设备处带来瓶颈，进一步降低性能。
此图表包括下列数据项：
每秒的用户调用和递归调用速率
此图表包括下列数据项：
递归调用数占用户调用数的百分比
此图表包括下列数据项：
每秒的数据库 I/O
此图表包括下列数据项：
通过使用表扫描而不是索引访问返回的行数百分比
此图表包括下列数据项：
各类表扫描的每秒速率
此图表包括下列数据项：
每秒通过网络发送和/或接收的字节数
此图表包括下列数据项：
每次表扫描获得的总块数
此图表包括下列数据项：
此图表指示正在被请求的平均 I/O 大小。如果平均 I/O 大小很小，通常是由于小事务处理或引起频繁 redo_synch_writes 的高并发性而造成的。 此图表包括下列数据项：
重做日志活动统计数据
此图表包括下列数据项：
此图表显示有关 CPU 分析 SQL 语句所花费的时间的信息。
当 Oracle 执行 SQL 语句时，它首先对其进行分析以确定其语法和内容是否正确。此进程会消耗相当大的开销。一旦分析后，除非分析信息从内存高速缓存中超龄释放并不再可用，否则 Oracle 不会再分析此语句。SQL 语句之间的无效内存共享可能导致重新分析。
此图表有助于检测分析时的一般响应时间。您的应用程序分析越多，存在的争用就越多，您的系统在等待上花费的时间就越多。如果分析时间 CPU 代表 CPU 时间的较大百分比，则时间被用于分析而不是用于执行语句。如果是这种情况，则可能是应用程序正在使用文字 SQL 且未共享它，或者没有很好地配置共享池。如果“其他”所占的百分比最大，请查看执行最多缓冲区获取和物理读取的 SQL 语句。
此图表包括下列数据项：
此图表表示排序效率，它由在内存中执行 (与转到磁盘上相对) 的排序次数百分比度量。
为获得最佳性能，大多数排序都应该在内存中进行，因为执行到磁盘的排序是昂贵的。如果排序区域太小，排序操作期间将需要运行额外的排序。这将增加 CPU 和 I/O 资源开销。
如果在磁盘上发生过多的排序，请考虑增大 SORT_AREA_SIZE 初始化参数，以增大排序区域的大小。更大的排序区域可使 Oracle Server 保持在内存中排序，从而减少用当前的排序区域大小完成等量的工作所需要的 I/O 操作数。
此图表包括下列数据项：
此图表表示排序效率，它由在内存中执行 (与转到磁盘上相对) 的排序次数百分比度量。
为获得最佳性能，大多数排序都应该在内存中进行，因为执行到磁盘的排序上是昂贵的。如果排序区域太小，排序操作期间将需要运行额外的排序。这将增加 CPU 和 I/O 资源开销。
如果在磁盘上发生过多的排序，请考虑增大 SORT_AREA_SIZE 初始化参数，以增大排序区域的大小。更大的排序区域可使 Oracle Server 保持在内存中排序，从而减少用当前的排序区域大小完成等量的工作所需要的 I/O 操作数。
此图表包括下列数据项：
与排序有关的初始化参数
此图表包括下列数据项：
排序和表扫描统计数据
此图表包括下列数据项：
每次排序行数规格
此图表包括下列数据项：
分配给排序的最大块数
此图表包括下列数据项：
与 DBWR 处理空闲块有关的统计数据
此图表包括下列数据项：
说明 LRU 列表的 DBWR 扫描数的统计数据
此图表包括下列数据项：
要求 DBWR 标记检查点的次数
此图表包括下列数据项：
按文件计的 SGA 中的块数
此图表包括下列数据项：
与游标有关的初始化参数
此图表包括下列数据项：
SGA 中的数据库块数
此图表包括下列数据项：
重做日志缓冲区大小 (字节)
此图表包括下列数据项：
LRU 栓锁数
此图表包括下列数据项：
与缓冲池有关的初始化参数
此图表包括下列数据项：
此图表显示每个表空间的数据文件数。
此图表包括下列数据项：
此图表显示每个表空间的状态；例如是联机、脱机，还是只读。
此图表包括下列数据项：
此图表显示每个表空间的以下各值的大小 (以块为单位)： 此图表包括下列数据项：
此图表显示每个表空间的空闲空间 (以块为单位) 百分比。随着表空间内的段的增长，该表空间内的空闲空间将减小。如果空闲空间变得不足，创建新段或扩展现有段的操作将失败。
如果空闲空间不足，请通过启用其数据文件之一的自动扩展，手动调整其数据文件之一的大小，或者添加新的数据文件来增加表空间的大小。
此图表包括下列数据项：
此图表显示每个表空间的空闲空间总计 (KB)。随着表空间内的段的增长，该表空间内的空闲空间将减小。如果空闲空间变得不足，创建新段或扩展现有段的操作将失败。
如果空闲空间不足，请通过启用其数据文件之一的自动扩展，手动调整其数据文件之一的大小，或者添加新的数据文件来增加表空间的大小。
此图表包括下列数据项：
此图表显示每个表空间的空闲区数。
此图表包括下列数据项：
数据字典高速缓存是共享池的一部分，用来将字典对象的定义保留在内存中。数据字典的示例有权限、用户、表、列、约束条件、索引等。当指定 SHARED_POOL_SIZE init.ora 参数时，间接调整数据字典高速缓存的大小。该字典将由 Oracle 自动优化。当首次启动 Oracle 并首次访问对象时，由于需要有磁盘读取才能访问信息，所以将发生丢失。理想化的情况是，由于将字典信息放置在内存中，从此之后将不再有丢失。不幸的是，并不总是这种情况。
所有获取的丢失数与获取数之比应该在 7-10% 之间。如果该百分比超出希望的范围，请通过增大 SHARED_POOL_SIZE init.ora 参数的值来降低该百分比。然后关闭数据库并将其重新启动，以便使新的 SHARED_POOL_SIZE 生效。
此图表包括下列数据项：
数据字典高速缓存是共享池的一部分，用来将字典对象的定义保留在内存中。数据字典的示例有权限、用户、表、列、约束条件、索引等。当指定 SHARED_POOL_SIZE init.ora 参数时，不能直接调整数据字典高速缓存的大小。该字典将由 Oracle 自动调整。当首次启动 Oracle 并首次访问对象时，由于需要有磁盘读取才能访问信息，所以将发生丢失。理想的情况是，由于将字典信息放置在内存中，从此以后将不再有丢失。不幸的是，并不总是这种情况。
所有获取的丢失数与获取数之比应该在 7-10% 之间。如果该百分比超出希望的范围，请通过增大 SHARED_POOL_SIZE init.ora 参数的值来将该百分比降低。然后关闭数据库并将其重新启动，以便使新的 SHARED_POOL_SIZE 生效。
此图表包括下列数据项：
每个高速缓存的计数
此图表包括下列数据项：
每个高速缓存每秒的高速缓存丢失数
此图表包括下列数据项：
此图表显示发现游标已存在于高速缓存中的分析请求的百分比。有关此规格的含义的完整说明，可在此图表中的项目说明中找到。
此图表中的下钻将有助于确定命中百分比为何很低的原因。
此图表包括下列数据项：
对回退段的争用反映在对包含回退段块的缓冲区的争用上。此图表代表访问回退段标题时无等待的次数百分比。此值应大于 99%。
此图表包括下列数据项：
此图表按每个用户分解等待事件。
此图表包括下列数据项：
用户等待每个事件的次数
此图表包括下列数据项：
每个用户的所有分析和执行的总计
此图表包括下列数据项：
每秒速率
此图表包括下列数据项：
按用户的 CPU 使用情况
此图表包括下列数据项：
此图表显示有关每个用户的 CPU 使用情况的信息，其 CPU 使用情况可以分解为子组成部分。
当 Oracle 执行 SQL 语句时，它首先对其进行分析以确定其语法和内容是否正确。此进程会消耗相当大的开销。一旦分析后，除非分析信息从内存高速缓存中超龄释放并不再可用，否则 Oracle 不会再分析此语句。SQL 语句之间的无效内存共享可能导致重新分析。
此图表有助于检测分析的一般响应时间。您的应用程序分析越多，存在的争用就越多，您的系统在等待上花费的时间就越多。如果分析时间 CPU 代表 CPU 时间的较大百分比，则时间被用于分析而不是用于执行语句。如果是这种情况，那么很可能是应用程序正在使用文字 SQL 且不共享它，或者是共享池配置得很差。如果“其他”占据的百分比最大，请查找正在执行最大缓冲区获取数和物理读取数的 SQL 语句。
此图表包括下列数据项：
每个用户的块和 I/O 速率
此图表包括下列数据项：
每秒每个用户的统计数据
此图表包括下列数据项：
此图表代表排序效率，它由在磁盘上 (与在内存中相对) 执行的排序次数的百分比度量。
为了获得最佳性能，大多数排序应该在内存中进行，因为执行到磁盘的排序的代价是昂贵的。如果排序区域太小，排序操作期间将需要运行额外的排序。这将增加 CPU 和 I/O 资源开销。
如果磁盘上发生了过多的排序，请考虑增大 SORT_AREA_SIZE 初始化参数，以增加排序区域的大小。更大的排序区域使 Oracle Server 能够将排序保持在内存中，从而减少了使用当前大小的排序区域完成等量工作所需的 I/O 操作数。
此图表包括下列数据项：
每次排序的行数
此图表包括下列数据项：
UGA (每个用户) 内存使用峰值
此图表包括下列数据项：
此采样周期内此用户的所有分析花费的时间
此图表包括下列数据项：
等待每次分析花费的平均时间
此图表包括下列数据项：
对回退段的争用反映在对包含回退段块的缓冲区的争用上。此图表代表访问回退段标题时无等待时的次数百分比。此值应大于 99%。
此图表包括下列数据项：
请求回退段标题时的命中百分比
此图表包括下列数据项：
回退段访问速率
此图表包括下列数据项：
未完成的事务处理的状态和当前编号
此图表包括下列数据项：
列出所有可以碎片化的段
列出所有用户和每秒的大型表扫描数
此图表包括下列数据项：
列出所有用户和每秒的小型表扫描数
此图表包括下列数据项：
按用户列出对具有链接行或移植行的表的表扫描
此图表包括下列数据项：
按用户列出绕过缓冲区高速缓存的表扫描
此图表包括下列数据项：
按用户计的各种表扫描统计数据
此图表包括下列数据项：
SGA 中可用的字节数
此图表包括下列数据项：
失败或导致丢失的库高速缓存请求次数
此图表包括下列数据项：
SGA 组件的大小，以兆字节报告。
此图表包括下列数据项：
重新加载/请求百分比和共享池保留列表丢失/请求百分比
此图表包括下列数据项：
锁管理器顶层图表
此图表包括下列数据项：
数据库大小 (兆字节)
此图表包括下列数据项：
最大重做日志缓冲区大小
此图表包括下列数据项：
方案、用户、表等的数目。
此图表包括下列数据项：
全部会话 (活动会话、非活动会话等) 的计数。
此图表包括下列数据项：
并发会话数的当前计数
并发事务处理数的计数
此图表包括下列数据项：
此图表显示当前正在执行的 SQL 语句类型的分解。只有在采样时标记为活动的语句才会出现在报告的数据中。所以此图表的结果可能产生误导。所报告的值仅对执行查询的那一瞬间才有效。
此图表包括下列数据项：
此图表显示执行 SQL 语句平均花费的时间，也显示将花费时间分解为等待时间和 cpu 时间这两个组成部分。要使这些图表有效，必须将 TIMED_STATISTICS 参数设置为 TRUE。TIMED_STATISTICS 可通过每个图表上都可用的工具启用。此处显示的两个图表为等待或受 CPU 限制和每次执行花费的时间。
这向用户显示我们从数据库内可用的统计数据得出的总响应时间的最佳估计。响应时间在这里被定义为总等待时间加上数据库内的所有会话所消耗的总 CPU 时间，它除以执行数就是每次执行的值。显示了每次执行的值，我们就可以精确报告只读访问和事务处理访问。关于每个事务处理的响应时间，请查看平均事务处理时间 (秒) 图表。
响应时间的各个部分：CPU 时间和等待时间的进一步研究，可以通过下钻到等待或受 CPU 限制来进行。
此图表包括下列数据项：
每个用户每次语句执行平均花费的时间
此图表包括下列数据项：
此图表显示数据库中的响应时间被分解为两个组成部分：等待时间和 CPU 时间。用户根据显示的百分比应该能够快速确定哪个部分正在消耗花费时间的最大部分。通过选择等待时间或 CPU 时间并下钻到为特定组成部分定制的图表可以完成任一组成部分的诊断
此图表包括下列数据项：
此图表显示将 CPU 使用情况分解为各个组成部分，它们按连接到数据库的每个应用程序分类。程序名取自 V$SESSION 表，用于计算这些值的统计数据是为执行该命名程序的用户所启动的所有会话合计的。
当 Oracle 执行 SQL 语句时，它首先对其进行分析以确定其语法和内容是否正确。此进程会消耗相当大的开销。一旦分析后，除非分析信息从内存高速缓存中超龄释放并不再可用，否则 Oracle 不会再分析此语句。SQL 语句之间的无效内存共享可能导致重新分析。现在您可以检测分析的一般响应时间。您的应用程序分析越多，存在的争用就越多，您的系统在等待上花费的时间就越多。如果分析时间 CPU 代表 CPU 时间的较大百分比，则时间被用于分析而不是用于执行语句。如果是这种情况，那么很可能是应用程序正在使用文字 SQL 且不共享它，或者是共享池配置得很差。如果“其他”占据的百分比最大，请查找正在执行最大缓冲区获取数和物理读取数的 SQL 语句。
此图表包括下列数据项：
此图表是一种组图表，显示有关等待事件的摘要信息。其中一个图表等待此事件的会话显示当前正在等待特定事件的会话数；另一个图表按时间的等待事件显示此示例过程中已经完成等待的前 5 个等待事件。
此图表说明在数据库中 CPU 时间被用于何处。它除了包含单个程序、用户和远程节点的 CPU 分解外，还包含整个数据库的 CPU 分解。根据这些图表您应该能够快速确定您的 CPU 在何处以及如何被消耗。
当 Oracle 执行 SQL 语句时，它首先对其进行分析以确定其语法和内容是否正确。此进程会消耗相当大的开销。一旦分析后，除非分析信息从内存高速缓存中超龄释放并不再可用，否则 Oracle 不会再分析此语句。SQL 语句之间的无效内存共享可能导致重新分析。现在您可以检测分析的一般响应时间。您的应用程序分析越多，存在的争用就越多，您的系统在等待上花费的时间就越多。如果分析时间 CPU 代表 CPU 时间的较大百分比，则时间被用于分析而不是用于执行语句。如果是这种情况，那么很可能是应用程序正在使用文字 SQL 且不共享它，或者是共享池配置得很差。如果“其他”占据的百分比最大，请查找正在执行最大缓冲区获取数和物理读取数的 SQL 语句。
一种组图表，显示高级别的例程范围内的 I/O 统计数据，以及访问得最频繁或者访问成本最高的数据库文件。
根据选作排序统计数据的统计数据增量值按降序显示会话。
此图表可用来创建定制“顶层会话”视图。会话中所有可用的统计数据和标识符都会缺省地在一个大表中显示。通过使用工具栏上的“设置选项”按钮，可以定制图表仅显示感兴趣的项，并可更改排序准则。这样，就可以保存、命名定制图表和直接通过名称对其进行访问。
此图表包括下列数据项：
每个会话每个事务处理平均花费的时间
此图表包括下列数据项：
此采样周期内提交数、回退数、执行数等的实际值
此图表包括下列数据项：
每个会话每次语句执行平均花费的时间
此图表包括下列数据项：
数据库文件的散列读取事件通常表明全表扫描或范围扫描。在单个 I/O 操作中读取的块数由 init.ora 参数 db_file_multi_read_count 确定。此图表将显示那些已在其上执行了扫描的文件。如果物理读取数接近物理块读取数，那么正在发生单个块的读取。如果不是这种情况，那么在该特定文件上没有发生全扫描或范围扫描。此图表将显示哪些文件正在进行单个块的读取，并标识出可能用于索引选择的那些文件以及其中的对象。
如果物理读取/物理块读取接近 1，那么正在发生单个块的读取，并且在文件上没有发生扫描。检查驻留在文件中的对象。并查看是否有索引可能适合于这些对象。为降低数据库文件散列读取的成本，请检查每个磁盘上的文件位置、磁盘数目和每个磁盘的条带大小 (这应该是 2 * db_file_mutli_block_read_count)
此图表提供栓锁活动的综合概览。为进一步研究提供了栓锁争用、栓锁休眠和总的栓锁统计数据。
花费时间的 CPU 时间和等待时间组成部分
此图表包括下列数据项：
对按用户的 CPU 使用情况的进一步研究
此图表与缓冲区忙事件有关。此图表将显示哪些块在哪些文件中，以及当前会话为何等待这些块。块可能正由另一个会话读取或者修改。至此我们可以了解到会话在特定文件以及这些文件中的块上有何种类型的争用。
此图表包括下列数据项：
排序统计数据组图表
使用 DBMS_APPLICATION_INFO 程序包的应用程序的 SQL 语句
此图表包括下列数据项：
使用 DBMS_APPLICATION_INFO 程序包的应用程序的 SQL 语句
此图表包括下列数据项：
当前模块和使用该模块的会话计数的列表
此图表包括下列数据项：
按当前等待特定事件类型的会话数排序的跨例程的事件列表。此列表允许用户快速识别从整体上例程等待哪个事件时间最长。每种事件类型受不同参数和条件的影响。进一步的下钻是通过选择感兴趣的特定等待事件来完成的。一些等待事件具有专门的下钻图表以帮助诊断该种等待的原因。
还有一般下钻，可用于所有等待事件。要确定当前正在等待特定事件的各个会话，请使用等待此事件的会话图表。类似地，要查看当前正在等待该事件的 SQL 语句，请使用等待此事件的 SQL 语句图表。这会将您快速引向正在经历等待的 SQL 语句，并帮助您确定此等待对应用程序的影响。
此图表包括下列数据项：
并行查询图表
此图表包含有关会话游标高速缓存的使用和大小的统计数据。此高速缓存可通过 SESSION_CURSOR_CACHE 参数启用。
将 CPU 时间分解为分析、递归和其他
此图表包括下列数据项：
表空间统计数据、状态、空闲空间百分比、空闲字节数等
此图表将显示用于说明“重做日志”和 LGWR 活动的整个健康状况的各种统计数据。
为 CP 分析显示或收集的大多数图表和统计数据要求将初始化参数 timed_statisics 设置为 TRUE。这使数据库能够收集有关服务器中操作的 CPU 和所花费时间的信息。打开此统计数据定时所引起的开销很低。能够精确跟踪资源和花费时间消耗所获得的好处远大于相关的成本。如果图表中当前显示的值是 "FALSE"，通过使用与此图表相关联的工具下拉式菜单中找到的相关联的“打开定时统计数据工具”，您就可以动态打开 timed_statistics。用鼠标右键单击任何图表就可以查看“工具”、“下钻”、“历史集合”和其他选项。
此图表包括下列数据项：
此图表用来显示不同的“共享池”统计数据，这些数据决定是增大还是减小“共享池大小”参数来调整库高速缓存性能。
库高速缓存是共享池中的动态内存结构之一。库高速缓存持有 SQL 游标、PL/SQL 程序和 JAVA 类的可执行形式。库高速缓存有大小限制并由一种 LRU 算法控制，这样如果共享池用尽空间，则从此高速缓存中超龄释放对象。库高速缓存丢失可能发生在处理 SQL 语句的分析阶段或执行阶段。
此图表显示在最后一个采样周期内由起源于所列主机的会话所使用的 CPU 时间百分比。您应该能够快速发现哪些远程节点应对数据库内的大量 CPU 消耗负责。此图表对将中间层服务器专用于特定应用程序的环境尤其有用。 此图表包括下列数据项：
此图表显示在最后一个采样周期内由列出的程序所使用的 CPU 时间百分比。您应该能够快速发现哪些程序应对数据库内的大量 CPU 消耗负责。此图表对于其中的各种应用程序具有唯一图像名的环境尤其有用。 此图表包括下列数据项：
此图表显示 LRU 缓冲区列表中所找到的灰数据缓冲区数和此采样周期内的写入请求数的总和。总计的灰队列长度是完成写入请求后停留在灰数据队列中的块数。如果存在许多灰数据缓冲区，那么一个或多个 DBWn 进程很可能无法继续下去。请增大缓冲区高速缓存的大小或调整 DBWn 进程。 此图表包括下列数据项：
此图表显示 DBWR 是否正在将灰数据块保留在 LRU 队列中，此队列在每次写入完成后被找到，或者由试图将新数据块加载到高速缓存中的影子进程找到。这两个统计数据的值都 > 1 可以表明 I/O 问题、高速缓存大小调整的问题或者 DBWR 进程数不足。 此图表包括下列数据项：
通过使用在这里成组显示的图表，您应该能够确定 DBWR 是否正在以一个足以满足数据库要求的级别运行。在每个特定图表中，都可以进一步研究各个统计数据和可能纠正问题的操作。
此图表是诊断数据库性能问题的起点。组图表中的每个子图表都具有下钻，下钻将引导您进一步分析由在该图表上显示的统计数据所表示的潜在问题。
某些下钻与特定上下文有关。如果有多于一个项目在图表中显示，则在使用鼠标右键单击下钻之前选择感兴趣的单个项目将为工具提供最佳的上下文。
每秒生成的重做大小 (字节)
此图表包括下列数据项：
每个 I/O 操作从每个文件读取或写入每个文件的平均块数
此图表包括下列数据项：
此图表显示一个 I/O 操作在特定文件上平均花费的时间。 此图表包括下列数据项：
此图表将向您显示此查询所引用的表。如果查询较大，您可能不会很容易了解到它实际上访问了哪些表。如果查询正在执行很多 I/O，则它可能正在对其中一个表进行全表扫描。如果正在使用基于成本的优化程序，它可能正在基于过时的统计数据来选择一个很差的策略。请使用此图表中的信息来决定表的统计数据是否有效。如果不是，请使用其中一个分析工具选项来更新任何一个表的统计数据。很高的链接行百分比可能表明此表中的平均行无法存入一个数据块中。这可能是由于增大记录大小并强制它们移植到其他块的更新或行大小刚好超过 db_block_size 所引起的。使用“重新编排”向导来确定是否应该重新编排具有高链接行百分比的表。 此图表包括下列数据项：
软分析是在高速缓存中查找已分析的 SQL 语句并能够重用现有条目的分析。硬分析不在高速缓存中查找 SQL 语句，并会消耗处理周期来完成分析步骤。如果软分析百分比较小，您应该查看高速缓存中的 SQL 语句。通过使用“顶层 SQL”图表您应该能够确定是否正在使用赋值变量。SQL 语句必须完全匹配，以便有效地使用 SQL 高速缓存。 此图表包括下列数据项：
此图表显示正在分析尚未驻留在高速缓存中的 SQL 语句的会话。通常，这是由于在 SQL 查询中使用文字而不是赋值变量而引起的。通过下钻到此会话图表的打开游标中可以找到会话正在使用的 SQL 语句。 此图表包括下列数据项：
此图表是了解哪个会话正在执行大部分排序的起点，也是最终了解哪个查询正在执行大部分排序起点。根据此图表，您可以下钻到此会话的打开游标，然后按行排序对那些查询进行排序，以确定哪些查询正在导致排序。 此图表包括下列数据项：
此图表使您能很好地了解哪些会话对大量的数据库读取 I/O 负责。在此图表中，您可以下钻到打开 SQL (当按物理读取数排序时) 以获得能使您了解哪些查询对 I/O 的会话负责。 此图表包括下列数据项：
此图表使您能很好地了解更改此表对应用程序的其他部分所造成的影响，不管是通过添加索引来改进查询还是通过更新表的内部统计数据。 此图表包括下列数据项：
SQL 文本
平均事务处理时间长度 (秒)
事务处理和语句执行速率
每个用户的平均事务处理长度
用户事务处理比率 (插入/更新)
按时间的等待事件
等待事件计数
按时间的块等待
用户操作
块等待计数
用户操作
顶层 SQL (缓冲区获取数)
I/O 的平均成本
文件读取操作数
文件写入操作数
DB 文件的散列读取
栓锁休眠数
栓锁获取/丢失比率
栓锁争用 (>1% 潜在问题)
减少栓锁争用
减少对重做分配栓锁的争用
减少对重做复制栓锁的争用
减少对 LRU 栓锁的争用
可用缓冲区扫描数
空闲缓冲区统计数据
分析统计数据
游标高速缓存命中百分比
已连接缓冲区的次数计数
会话等待或 CPU？
缓冲区高速缓存命中百分比
调用速率
递归调用与用户调用的比率
每秒的 I/O 速率
通过表扫描已检索的行数百分比
表扫描速率
每秒网络字节数
每次表扫描的块数
重做日志写入的平均大小
重做日志统计数据
例程范围内的 CPU 分解
内存排序百分比
内存排序比率
排序区大小
排序数与扫描数
每次排序的行数
最大排序分配
DBWR 空闲块统计数据
DBWR 扫描统计数据
DBWR 检查点
缓冲池
游标例程参数
SGA 中的 DB 块
重做日志缓冲区大小
LRU 栓锁计数
缓冲池参数
每个表空间的数据文件计数
说明
每个表空间的状态
说明
每个表空间的块计数
说明
每个表空间的空闲空间 (%)
说明
用户操作
每个表空间的空闲空间 (KB)
说明
用户操作
每个表空间的空闲区数
说明
数据字典丢失百分比
数据字典命中/丢失比率
每个高速缓存的数据字典条目计数
每个高速缓存的数据字典丢失率
库高速缓存命中百分比
回退段无等待百分比
每个用户按时间的等待事件
每个用户按计数的等待事件
用户分析和执行总计
用户分析和执行的比率
用户 CPU 总计
用户 CPU 分解
用户 I/O 速率
用户排序速率
用户磁盘排序与内存排序的比率
用户排序数与已排序行数的比率
用户 UGA 内存使用情况
用户花费的分析时间
用户平均等待分析的时间
回退段无等待率 (>99%)
回退段命中百分比
回退段访问速率
回退段状态
表空间 (段) 碎片
具有大型表 (>5 个块) 表扫描的用户
具有小型表 (<5 个块) 表扫描的用户
具有链接行或移植行的表上的表扫描
绕过缓冲区高速缓存的表扫描 (直接到磁盘)
用户表扫描比率
SGA 空闲内存
SGA 请求失败和丢失速率
SGA 分解
SGA 命中百分比
锁管理器
数据库大小
重做日志缓冲区大小
对象计数
会话计数
并发会话计数
并发事务处理计数
当前操作分解
响应时间概览
每次执行花费的时间
用户每次执行花费的时间
等待或受 CPU 限制？
程序 CPU 分解
等待分析概览
CPU 概览
I/O 浏览
顶层会话
每个会话的平均事务处理长度
会话事务处理比率 (插入/更新)
每个会话每次执行花费的时间
DB 文件的连续读取分析
栓锁分析
用户花费时间的各组成部分
用户 CPU 分析
处于忙等待状态的会话缓冲区
排序统计数据浏览
按模块、操作、物理读取数排序的 SQL
按模块、操作、缓冲区获取数排序的 SQL
应用程序模块动作
处于等待状态的会话数
并行查询
游标概览图表
每个主机的 CPU 分解
表空间概览
重做分析
定时统计数据
SGA 概览
主机总的 CPU 时间
程序总的 CPU 时间
总计的灰队列长度
DBWR 效率统计数据
DBWR 分析
数据库健康状况 (直观的)
重做大小/秒
每个 I/O 的块数
I/O 时间
此查询所引用的表
软分析百分比
按硬分析计数的顶层会话数
按已排序行数的顶层会话数
按物理读取数的顶层会话数
高速缓存中访问此表的所有 SQL