Dav_笔记5-使用性能视图的实例优化 OWI

Instance Tuning Using Performance Views

在初始配置数据库之后，定期监控和调整实例对于消除任何潜在的性能瓶颈非常重要。 本章讨论使用Oracle V $性能视图的调优过程。

本章包含以下部分：

■一：实例调整步骤

■二：解释Oracle数据库统计信息

■三：等待事件统计

■四：实时SQL监控

■五：调整实例恢复性能：快速启动故障恢复

一：实例调整步骤

这些是实例调优的Oracle性能方法的主要步骤：

1.确定问题Define the Problem

获得用户关于性能问题范围的坦率反馈。

2.检查主机系统并检查Oracle数据库统计信息

■获取完整的操作系统，数据库和应用程序统计数据后，请检查数据是否存在任何性能问题的证据。

■考虑常见性能错误列表，以查看收集的数据是否表明他们正在对问题做出贡献。

■使用收集的性能数据构建系统上正在发生的事情的概念模型。

3.实施和衡量变更

提出要进行的更改以及实施更改的预期结果。然后，实施更改并测量应用程序性能。

4.确定是否满足步骤1中定义的性能目标。如果不是，则重复步骤2和3，直到达到性能目标。

本章的其余部分讨论使用Oracle数据库动态性能视图进行实例调优。但是，Oracle建议使用自动工作量资源库（AWR）和自动数据库诊断监视器（ADDM）进行统计信息收集，监视和调整，这是由于扩展功能列表所致。请参阅第5-8页上的“自动负载库”概述和第6-1页上的“自动数据库诊断监视器概述”。

Define the Problem

在尝试实施解决方案之前，深入理解调优练习的目的和问题的性质至关重要。没有这种理解，实施有效的改变几乎是不可能的。在此阶段收集的数据有助于确定下一步要采取的措施以及要检查的证据。

收集以下数据：

1.确定绩效目标。

可接受性能的衡量标准是什么？一小时或几秒钟的响应时间内会有多少次交易达到要求的性能水平？

2.确定问题的范围。

受减速影响的是什么？例如，整个事例是否缓慢？它是特定的应用程序，程序，特定操作还是单个用户？

3.确定发生问题的时间。

问题只在繁忙时间出现吗？在一天中的表现会恶化吗？减速是渐进的（在几个月或几周的时间内）还是突然的？

4.量化放缓。

这有助于确定问题的严重程度，并且在决定实施解决问题的措施是否实际上有所改进时，也可以作为比较措施。找到响应时间或作业运行时间的一致可重复的度量。时间比程序运行良好时还要糟糕多少？

5.识别任何更改。

确定性能可接受后发生了什么变化。这可能会迅速缩小可能的原因。例如，操作系统软件，硬件，应用程序软件或Oracle数据库版本是否已升级？是否有更多的数据加载到系统中，或者数据量或用户数量增长了？

在这个阶段结束时，你应该对症状有很好的理解。如果症状可以被识别为程序或程序集的本地特征，那么问题的处理方式与实例范围内的性能问题不同。

检查主机系统

查看数据库服务器和数据库实例上的负载。考虑操作系统，I / O子系统和网络统计数据，因为检查这些区域有助于确定哪些值得进一步调查。在多层系统中，还要检查应用程序服务器中间层主机。

检查主机硬件通常给出系统瓶颈的有力指示。这确定了哪些Oracle数据库性能数据可用于交叉引用和进一步诊断。

要检查的数据包括以下内容：

■CPU使用率

■识别I / O问题

■识别网络问题

CPU使用率

如果有大量闲置的CPU，则可能会出现I / O，应用程序或数据库瓶颈。请注意，等待I / O应被视为空闲CPU。

如果CPU使用率过高，则确定CPU是否正在有效使用。大部分CPU使用率是由于少量使用高CPU的程序引起的，还是由均匀分布的工作负载消耗的CPU？

如果少量高用量程序使用CPU，则查看程序以确定原因。检查某些进程是否单独使用一个CPU的全部功能。根据过程的不同，这可能表示CPU或过程限制工作负载，可以通过划分或并行化过程活动来解决。

非Oracle进程

如果这些程序不是Oracle程序，那么确定它们是否合法地要求这么多的CPU。如果是这样，确定他们的执行是否延迟到非高峰时段。识别这些CPU密集型进程还可以帮助缩小特定活动（如I / O，网络和分页）消耗的资源，以及它如何与数据库工作负载相关联。

Oracle进程

如果少量Oracle进程占用大部分CPU资源，则使用SQL_TRACE和TKPROF来标识SQL或PL / SQL语句，以查看是否可以调整特定查询或PL / SQL程序单元。例如，如果一个SELECT语句的执行涉及许多高速缓存中的数据读取（逻辑读取），并且可以通过更好的SQL优化来避免，则该语句可能占用大量CPU资源。

Oracle数据库cPU统计数据

Oracle数据库CPU统计信息在几个V $视图中可用：

■V$SYSSTAT显示所有会话的Oracle数据库CPU使用情况。此会话统计信息使用的CPU显示所有会话使用的聚合CPU。解析时间CPU统计信息显示用于解析的总CPU时间。

■V$SESSTAT显示每个会话的Oracle数据库CPU使用情况。使用此视图可以确定哪个特定会话使用最多的CPU。

■当Oracle数据库资源管理器运行时，V$RSRC_CONSUMER_GROUP显示每个使用者组的CPU利用率统计信息。

解释CPU统计信息

认识到CPU时间和实时性是不同的，这一点很重要。使用八个CPU，实时任意给定分钟，CPU时间可用八分钟。在Windows和UNIX上，这可以是用户时间或系统时间（Windows上的特权模式）。因此，系统上所有进程（线程）使用的平均CPU时间可能会大于每分钟实时间隔一分钟。

在任何时候，您都知道Oracle数据库在系统上使用了多少时间。因此，如果八分钟可用且Oracle数据库使用四分钟时间，那么您知道Oracle使用全部CPU时间的50％。如果你的过程没有消耗那么多时间，那么其他过程就是这样。确定使用CPU时间的进程，找出原因，然后尝试调整它们。请参见第21章“使用应用程序跟踪工具”。

如果CPU使用率均匀分布在许多Oracle服务器进程中，请检查V $ SYS_TIME_MODEL视图以帮助准确理解大部分时间花费在哪里。请参阅第10-14页的表10-1“等待事件和潜在原因”。

识别I / O问题

过度活动的I / O系统可以通过磁盘队列长度大于2或磁盘服务时间超过20-30ms来证明。如果I / O系统过度活动，则检查可能通过将I / O分配到更多磁盘而受益的潜在热点。还要确定是否可以通过降低使用这些资源的程序的资源需求来降低负载。如果I / O问题是由Oracle数据库引起的，则可以开始I / O调优。如果Oracle数据库没有使用可用的I / O资源，请确定使用I / O的进程。确定进程使用I / O的原因，然后调整此过程。

可以使用Oracle数据库中的V $视图和操作系统中的监视工具来识别I / O问题，如以下各节所述：

■使用V $视图识别I / O问题

■使用操作系统监视工具识别I / O问题

使用V $视图识别I / O问题

检查V $ SYSTEM_EVENT中的Oracle等待事件数据以查看顶级等待事件是否与I / O相关。 I / O相关事件包括db文件顺序读取，db文件分散读取，db文件单写，db文件并行写入以及日志文件并行写入。这些都是对应于针对数据文件和日志文件执行的I / O的事件。如果任何这些等待事件对应于高平均时间，则调查I / O争用。

将主机I / O系统数据与“自动存储库”报告中的I / O部分交叉引用以标识热门数据文件和表空间。同时比较操作系统报告的I / O时间和Oracle数据库报告的时间，看它们是否一致。

一个I / O问题也可以用非I / O相关的等待事件表现出来。例如，在缓冲区高速缓存中查找空闲缓冲区的难度或将日志刷新到磁盘的高等待时间也可能是I / O问题的症状。在调查I / O系统是否需要重新配置之前，请确定I / O系统上的负载是否可以减少。

为了减少Oracle数据库引起的I / O负载，请使用以下视图检查为数据库所做的所有I / O调用收集的I / O统计信息：

■V $ IOSTAT_CONSUMER_GROUP

V $ IOSTAT_CONSUMER_GROUP视图捕获消费者组的I / O统计信息。如果启用Oracle数据库资源管理器，则会捕获属于当前已启用资源计划一部分的所有使用者组的I / O统计信息。

■V $ IOSTAT_FILE

V $ IOSTAT_FILE视图捕获已访问或已被访问的数据库文件的I / O统计信息。 SMALL_SYNC_READ_LATENCY列显示单个数据块同步读取的延迟（以毫秒为单位），直接转换为客户端在进入下一个操作之前需要等待的时间量。这定义了基于当前负载的存储子系统的响应性。如果关键数据文件的延迟很大，则可能需要考虑重新定位这些文件以缩短服务时间。要计算延迟统计信息，timed_statistics必须设置为TRUE。

■V$IOSTAT_FUNCTION

V $ IOSTAT_FUNCTION视图捕获数据库函数（例如LGWR和DBWR）的I / O统计信息。

一个I / O可以由具有不同功能的各种Oracle进程发布。顶层数据库函数被分类在V $ IOSTAT_FUNCTION视图中。在I / O功能发生冲突的情况下，I / O被放置在FUNCTION_ID较低的存储桶中。例如，如果XDB从缓冲区缓存中发出I / O，那么I / O将被归类为XDB I / O，因为它具有较低的FUNCTION_ID值。任何未分类的功能都放置在其他存储桶中。您可以通过查询V $ IOSTAT_FUNCTION视图来显示FUNCTION_ID层次结构：

select FUNCTION_ID, FUNCTION_NAME

from v$iostat_function

order by FUNCTION_ID;

FUNCTION_ID FUNCTION_NAME

----------- ------------------

0 RMAN

1 DBWR

2 LGWR

3 ARCH

4 XDB

5 Streams AQ

6 Data Pump

7 Recovery

8 Buffer Cache Reads

9 Direct Reads

10 Direct Writes

11 Others

这些V $ IOSTAT视图包含单块和多块读取和写入操作的I / O统计信息。 单块操作是小于或等于128千字节的小I / O。 多块操作是大于128千字节的大I / O。 对于这些操作中的每一个，都会收集以下统计信息：

■标识

■总等待时间（以毫秒为单位）

■执行的等待次数（针对消费者群体和功能）

■每个操作的请求数量

■读取单个和多个块字节的数量

■写入的单个和多个块字节的数量

您还应该查看通过查询V $ SQLAREA视图执行多次物理读取的SQL语句，或者查看“自动负载存储库”报告中的“Read by order by SQL”部分。 检查这些语句以了解如何调整它们以减少I / O数量。

使用操作系统监视工具识别I / O问题

使用操作系统监视工具来确定整个系统上正在运行的进程以及监视磁盘对所有文件的访问。请记住，保存数据文件和重做日志文件的磁盘也可以保存与Oracle数据库无关的文件。减少对包含数据库文件的磁盘的大量访问。您只能通过操作系统工具而不是通过V $视图来监视对非数据库文件的访问。

许多UNIX系统上的实用程序（如sar -d（或iostat）和Windows系统上的管理性能监视工具）检查整个系统的I / O统计信息。

识别网络问题

使用操作系统实用程序，查看网络往返ping时间和冲突次数。如果网络在响应时间上造成大量延迟，请调查可能的原因。

要识别远程访问数据库文件导致的网络I / O，请检查V $ IOSTAT_NETWORK视图。该视图包含访问远程数据库实例上的文件导致的网络I / O统计信息，其中包括：

■启动网络I / O的数据库客户端（例如RMAN和PLSQL）

■发布的读取和写入操作的数量

■读取和写入的千字节数

■读取操作的总等待时间（以毫秒为单位）

■写入操作的总等待时间（以毫秒为单位）

在确定网络问题的原因之后，可以通过将大量数据传输调度到非高峰时间来减少网络负载，或者通过将应用程序编码为批量向远程主机发送请求，而不是一次（或多次）访问远程主机以执行一次请求。

检查Oracle数据库统计信息

您应该检查Oracle数据库统计信息并将其与操作系统统计信息进行交叉引用，以确保对问题进行一致的诊断。操作系统统计信息可以指示开始调整的好地方。但是，如果目标是调整Oracle数据库实例，那么在实施纠正措施之前，请查看Oracle数据库统计信息以从数据库角度确定资源瓶颈。请参阅第10-11页的“解释Oracle数据库统计信息”。

以下各节讨论调整时使用的常见Oracle数据源。

设置统计收集水平

Oracle数据库提供了初始化参数STATISTICS_LEVEL，该参数控制数据库中的所有主要统计信息集合或建议。此参数设置数据库的统计信息收集级别。

根据STATISTICS_LEVEL的设置，收集某些建议或统计信息，如下所示：

■基本信息：不收集任何咨询或统计数据。监控和许多自动功能被禁用。 Oracle不建议使用此设置，因为它会禁用重要的Oracle数据库功能。

■典型：这是默认值，可确保收集所有主要统计数据，同时提供最佳总体数据库性能。该设置应该适用于大多数环境。

■ALL：包含使用TYPICAL设置收集的所有公告或统计信息，以及定时操作系统统计信息和行源执行统计信息。

V $ STATISTICS_LEVEL

该视图列出由STATISTICS_LEVEL控制的统计或顾问的状态。

等待事件

等待事件是由服务器进程或线程递增的统计信息，以指示它必须等待事件完成才能继续处理。 等待事件数据显示可能影响性能的各种问题症状，例如锁定争用，缓冲区争用和I / O争用。 请记住，这些只是问题的症状，而不是实际原因。

等待事件被分组到类中。 等待事件类包括：管理，应用程序，集群，提交，并发，配置，空闲，网络，其他，调度程序，系统I / O和用户I / O。

服务器进程可以等待以下内容：

■可用的资源，如缓冲区或锁存器。

■要完成的操作，例如I / O。

■更多的工作要做，比如等待客户端提供下一条要执行的SQL语句。 识别服务器进程正在等待更多工作的事件称为空闲事件。

三：等待事件统计信息：包括等待事件的次数和等待事件完成的时间。 如果初始化参数TIMED_STATISTICS设置为true，那么您还可以看到每个资源等待的时间。

为了最大限度地减少用户响应时间，减少服务器进程等待事件完成所花费的时间。 并非所有的等待事件都有相同的等待时间。 因此，检查等待时间最多的事件而不是发生次数较多的等待事件更为重要。 通常，至少在监视性能时最好将动态参数TIMED_STATISTICS设置为true。 有关STATISTICS_LEVEL设置的信息，请参阅第10-7页的“设置统计信息集合级别”。

包含等待事件统计的动态性能视图

这些动态性能视图可以查询等待事件统计信息：

■V$ ACTIVE_SESSION_HISTORY

V$ACTIVE_SESSION_HISTORY视图显示活动的数据库会话活动，每秒采样一次。请参阅第5-3页的“活动会话历史记录”。

■V$SESS_TIME_MODEL和V $ SYS_TIME_MODEL

V$SESS_TIME_MODEL和V $ SYS_TIME_MODEL视图包含时间模型统计信息，其中包括数据库时间，即数据库调用花费的总时间。

■V$ SESSION_WAIT

V$SESSION_WAIT视图显示有关每个会话当前或最后一次等待的信息（例如等待ID，班级和时间）。

■V$SESSION

V $ SESSION视图显示有关每个当前会话的信息，并包含与V $ SESSION_WAIT视图中相同的等待统计信息。如果适用，此视图还包含有关会话当前正在等待的对象（如对象号，块号，文件号和行号）的详细信息，负责当前等待的阻塞会话（例如阻塞会话ID，状态和类型）以及等待的时间量。

■V $ SESSION_EVENT

V $ SESSION_EVENT视图提供会话自启动以来等待的所有事件的摘要。

■V $ SESSION_WAIT_CLASS

V $ SESSION_WAIT_CLASS视图提供每个会话的每个等待事件类别的等待次数和时间。

■V $ SESSION_WAIT_HISTORY

V $ SESSION_WAIT_HISTORY视图显示有关每个活动会话的最近10个等待事件的信息（例如事件类型和等待时间）。

■V $ SYSTEM_EVENT

V $ SYSTEM_EVENT视图提供实例启动后所有事件等待的摘要。

■V $ EVENT_HISTOGRAM

V $ EVENT_HISTOGRAM视图显示等待次数，最大等待时间和总事件等待时间的直方图。

■V $ FILE_HISTOGRAM

V $ FILE_HISTOGRAM视图显示每个文件在单个块读取期间等待的时间直方图。

■V $ SYSTEM_WAIT_CLASS

V $ SYSTEM_WAIT_CLASS视图为等待次数和每类等待事件花费的时间提供实例全时间总计。

■V $ TEMP_HISTOGRAM

V $ TEMP_HISTOGRAM视图显示每个临时文件在单个数据块读取期间等待的时间直方图。

在执行反应性性能调整时调查等待事件和相关的时间数据。对他们列出的时间最多的事件往往是性能瓶颈的强烈迹象。例如，通过查看V $ SYSTEM_EVENT，您可能会注意到很多缓冲区正在等待。可能有很多进程插入到同一个块中，并且必须等待其他进程才能插入。解决方案可能是使用自动段空间管理或对有问题的对象进行分区。有关视图V $ SESSION_WAIT，V $ SESSION_EVENT和V $ SYSTEM_EVENT之间差异的描述，请参阅第10-17页的“等待事件统计信息”。

系统统计

系统统计信息通常与等待事件数据结合使用，以查找性能问题原因的进一步证据。

例如，如果V $ SYSTEM_EVENT指示最大等待事件（就等待时间而言）是事件缓冲区忙等待的事件，则查看视图V $ WAITSTAT中可用的特定缓冲区等待统计量，以查看哪个块类型具有最高等级等待计数和最长的等待时间。

在块类型被识别之后，还可以在问题发生时实时查看V $ SESSION，或在经历问题后查看V $ ACTIVE_SESSION_HISTORY和DBA_HIST_ACTIVE_SESS_HISTORY视图，以使用指示的对象编号标识争用对象。这些数据的组合表明适当的纠正措施。

统计信息在许多V $视图中可用。一些常见的观点包括以下内容：

■V $ ACTIVE_SESSION_HISTORY

■V $ SYSSTAT

■V $ FILESTAT

■V $ ROLLSTAT

■V $ ENQUEUE_STAT

■V $ LATCH

V $ ACTIVE_SESSION_HISTORY

该视图显示活动的数据库会话活动，每秒采样一次。请参阅第5-3页的“活动会话历史记录”。

V $ SYSSTAT

这包含Oracle数据库许多不同部分的总体统计数据，包括回滚，逻辑和物理I / O以及解析数据。来自V $ SYSSTAT的数据用于计算比率，例如缓冲区缓存命中率。

V $ FILESTAT

这包含每个文件的详细文件I / O统计信息，包括每个文件的I / O数量和平均读取时间。

V $ ROLLSTAT

这包含每个段的详细回滚和撤消段统计信息。

V $ ENQUEUE_STAT

这包含每个队列的详细入队统计信息，包括请求入队的次数和入队等待的次数以及等待时间。

V $ LATCH

这包含每个锁存器的详细锁存器使用情况统计信息，包括每个锁存器请求的次数以及锁存器等待的次数。

Segment-Level Statistics 段级统计

您可以收集细分级别统计信息，以帮助您发现与各个细分受众群相关的性能问题。收集和查看段级统计信息是有效识别实例中热表或索引的好方法。

查看等待事件和系统统计数据以确定性能问题后，可以使用段级统计信息查找导致问题的特定表或索引。例如，考虑V $ SYSTEM_EVENT指示缓冲区繁忙等待会导致相当长的等待时间。您可以从V $ SEGMENT_STATISTICS中选择导致缓冲区繁忙等待的顶部段。然后，您可以专注于消除这些细分市场中的问题。

您可以通过以下动态性能视图查询段级统计信息：

■V $ SEGSTAT_NAME此视图列出正在收集的细分市场统计信息以及每个统计信息的属性（例如，如果它是抽样统计信息）。

■V $ SEGSTAT这是一个高效的实时监控视图，显示统计值，统计名称和其他基本信息。

■V $ SEGMENT_STATISTICS这是统计值的用户友好视图。除了V $ SEGSTAT的所有列外，它还包含有关段所有者和表空间名称等信息。它使统计易于理解，但成本更高。

实施和衡量变化

通常在调整过程结束时，可以确定两到三次可能会缓解问题的更改。为了确定哪个变更提供了最大的好处，建议一次只实施一个变更。应该根据在问题定义阶段发现的基准数据来衡量变化的影响。

通常，大多数具有严重性能问题的网站一次实施多个重叠更改，因此无法确定哪些更改会带来任何好处。虽然这不是一个直接问题，但如果变化提供了最大的利益和优先考虑哪些努力，这就成为一个重大障碍。

如果无法单独实施更改，则尝试测量不同更改的影响。例如，衡量执行初始化更改以优化重做生成的效果，与创建新索引的效果分开以提高修改的查询的性能。如果调整SQL，操作系统磁盘布局发生变化，并且初始化参数也同时发生更改，则无法衡量执行操作系统升级的好处。

性能调优是一个迭代过程。这不太可能找到解决实例范围性能问题的“银弹”。在大多数情况下，出色的性能需要迭代整个性能调优阶段，因为解决一个瓶颈往往会揭示另一个（有时候更糟糕）的问题。

知道何时停止调整也很重要。性能的最佳衡量标准是用户感知，而不是统计与理想值的接近程度。

二：解释Oracle数据库统计信息

收集涵盖实例出现性能问题时的统计信息。如果您先前捕获了用于比较的基准数据，则可以将当前数据与基准中代表问题工作负荷的数据进行比较。

比较两份报告时，请确保两份报告来自系统运行可比较工作负载的时间。

检查负载

通常，等待事件是首先检查的数据。但是，如果您有基线报告，请检查负荷是否已更改。无论您是否有基准，查看资源使用率是否高，都很有用。

要检查的负载相关统计信息包括重做大小，会话逻辑读取，db块更改，物理读取，物理读取总字节数，物理写入数量，物理写入总字节数，分析计数（总计），分析计数（硬）以及用户调用。这些数据是从V $ SYSSTAT中查询的。最好是在几秒钟内完成这些数据的标准化处理。通过使用物理读取总字节数和物理写入总字节数的总和，检查每秒MB的总I / O负载也很有用。组合的值包括用于缓存缓存，重做日志，归档日志，Recovery Manager（RMAN）备份和恢复以及任何Oracle数据库后台进程的I / O。

在AWR报告中，查看“load profile 加载配置文件”部分。数据已经过交易和几秒钟的标准化。

改变负载

数秒内的负载配置文件统计信息显示吞吐量的变化（即实例是否每秒执行更多工作）。通过将这些数据与基准报告中的相应统计数据进行比较，交易统计数据识别应用程序特性的变化。

高活动率

检查在数秒内标准化的统计数据以确定活动率是否非常高。由于每个站点上的阈值不同，因此很难在高值上提供一揽子建议，这取决于应用程序特性，CPU数量和速度，操作系统，I / O系统和Oracle数据库版本。

以下是一些通用示例（每个站点的可接受值有所不同）：

■每秒超过100次的硬解析速率表明系统上存在大量的硬解析。高硬解析率导致严重的性能问题，必须进行调查。通常，高硬解析率伴随着共享池和库高速缓存锁存器上的锁存争用。

■检查与在V中找到的统计数据库时间相比，库高速缓存和共享池锁存事件（锁存器：库高速缓存，锁存器：库高速缓存引脚，锁存器：库高速缓存锁定和锁存器：共享池）的等待时间之和是否显着$ SYSSTAT。如果是这样，请检查AWR报告的“分析调用”部分所订购的SQL。

■高软解析率可能在300秒或更高的速度。不必要的软解析也限制了应用程序的可伸缩性。理想情况下，应该在每个会话中对SQL语句进行一次软解析并执行很多次。

Using Wait Event Statistics to Drill Down to Bottlenecks

使用等待事件统计来深入研究瓶颈

每当Oracle进程等待某个事件时，都会使用一组预定义的等待事件中的一个记录等待事件。 这些等待事件分组在等待类中。 空闲等待类将进程等待的所有事件分组，这些事件没有工作要做，并且正在等待更多工作要执行。 非空闲事件表示等待资源或动作完成所花费的非生产时间。

使用等待事件数据的最有效方法是按等待时间排序事件。 这只有在TIMED_STATISTICS设置为true时才有可能。 否则，等待事件只能按等待的次数排序，这通常不是最能代表问题的次序。

注意：

并非所有症状都可以通过等待事件得到证实。 有关可以检查的统计信息，请参阅第10-15页的“附加统计信息”。

要了解何时花费的时间，请按照下列步骤操作：

1.检查V$SYSTEM_EVENT的数据收集。 感兴趣的事件应按等待时间排序。

确定等待时间最重要的等待事件。 要确定等待时间的百分比，请为所有等待事件（不包括空闲事件，例如Null事件，来自客户端的SQL * Net消息，SQL * Net消息到客户端以及SQL * Net更多数据到客户端）添加总等待时间。 通过将每个事件的等待时间除以等待所有事件的总时间来计算五个最显着事件的相对百分比。或者，查看“自动负载信息库”报告开头的“前5个定时事件”部分。 本节自动命令等待事件（省略空闲事件），并计算相对百分比：

在某些情况下，可能会有一些事件具有相似的百分比。 如果所有事件都与相同类型的资源请求（例如，所有I / O相关事件）相关，这可以提供额外的证据。

2.查看等待这些事件的次数以及平均等待时间。 例如，对于I / O相关事件，平均时间可能有助于确定I / O系统是否缓慢。 以下数据示例来自AWR报告的等待事件部分：

3.最高的等待事件确定下一个要调查的地方。 表10-1列出了常见等待事件表。 快速查看高负载SQL通常是个好主意。

4.检查等待事件指示的相关数据，以查看此数据提供的其他信息。 确定此信息是否与等待事件数据一致。 在大多数情况下，有足够的数据开始就性能瓶颈的潜在原因开发理论。

5.为了确定这个理论是否有效，你可以用可用的其他统计数据来检查你所检查的数据的一致性。 相应的统计信息因问题而异，但通常包括V $ SYSSTAT中的负载配置文件相关数据，操作系统统计信息等。 与其他数据进行交叉核对以确认或反驳发展中的理论

Table of Wait Events and Potential Causes

等待事件表和潜在原因

Additional Statistics 附加统计

有几个统计信息可以指示没有相应等待事件的性能问题。

重做日志空间请求统计

V $ SYSSTAT统计重做日志空间请求指示服务器进程必须等待联机重做日志中的空间多少次，而不是重做日志缓冲区中的空间。使用此统计信息和等待事件表示您必须调整检查点，DBWR或归档活动，而不是LGWR。增加日志缓冲区的大小并没有帮助。

读一致性

为了保持一致的视图，系统可能会花费过多时间回滚块的更改。考虑以下情况：

■如果在发生更改的同一个表上的后台运行多个小事务并且正在运行长时间运行的查询，则查询可能需要经常回滚这些更改，以获取读取一致的映像的表格。比较以下V $ SYSSTAT统计信息以确定是否发生这种情况：

-consistent：更改统计信息指示数据库块应用回滚条目以执行块的一致读取的次数。产生大量一致变化的工作量可能会消耗大量资源。

-consistent gets：statistic统计一致模式下的逻辑读取次数。

■如果很少有大量回滚段，那么系统可能会在延迟块清理期间花费大量时间回滚事务表，以便准确找出事务提交的系统更改号（SCN）。当Oracle数据库提交事务时，所有修改的块不一定会立即使用提交SCN进行更新。在这种情况下，在块被读取或更新时，稍后按要求完成。这被称为延迟块清除。

以下V$SYSSTAT统计数据的比率应接近1：

比率=事务表一致读取 - 应用撤消记录 / 事务表一致的读回滚

推荐的解决方案是使用自动撤销管理。

■如果回滚段数不足，则存在回滚段（标题或块）争用。此问题的证据可通过以下方式获得：

■将WAITS的数量与V$ROLLSTAT中GETS的数量进行比较; WAITS与GETS的比例应该很小。

■检查V$WAITSTAT以查看CLASS“撤消报头”的缓冲区是否有许多WAITS。

推荐的解决方案是使用自动撤销管理。

Table Fetch by Continued Row

按连续行取表

您可以通过检查V$SYSSTAT中的表访存连续行统计信息来检测迁移或链接的行。少量的链接行（小于1％）不太可能影响系统性能。但是，很大比例的链接行可能会影响性能。

链接大于块大小的行是不可避免的。考虑对这些数据使用块大小较大的表空间。

但是，对于较小的行，您可以通过使用合理的空间参数和良好的应用程序设计来避免链接。例如，不要插入行中填充了键值并将其置于大多数其他列中，然后使用实际数据更新该行，导致行的大小增加。而是插入从一开始就充满数据的行。

如果UPDATE语句增加了一行中的数据量，以使该行不再适合其数据块，则Oracle数据库将尝试查找具有足够空闲空间的另一个块来保存整行。如果这样的块可用，则Oracle数据库将整个行移动到新块。该操作称为行迁移。如果行太大而不能放入任何可用块中，则数据库将该行分割成多个块并将每个块存储在单独的块中。这个操作被称为行链接。数据库在插入时也可以链接。

迁移和链接对性能特别有害，具体如下：

■导致迁移和链接性能较差的UPDATE语句

■选择迁移或链接行的查询，因为这些查询必须执行附加的输入和输出

名为CHAINED_ROWS的示例输出表的定义显示在您的分发介质上的SQL脚本中。这个脚本的通用名称是UTLCHN1.SQL，尽管它的确切名称和位置取决于您的平台。您的输出表必须与CHAINED_ROWS表具有相同的列名，数据类型和大小。

增加PCTFREE可以帮助避免迁移的行。如果您在块中留出更多可用空间，则该行有空间可以增长。您也可以重新组织或重新创建具有高删除率的表和索引。如果表经常删除行，那么数据块可以有部分空闲空间。如果插入行并稍后展开，则插入的行可能会以已删除行的块进行着陆，但仍然没有足够的空间进行展开。重组表格确保主空闲空间完全是空的块。

Parse-Related Statistics

应用程序解析得越多，竞争的可能性就越大，系统等待的时间就越多。 如果解析时间CPU占CPU时间的很大比例，那么时间将花在解析而不是执行语句上。 如果是这种情况，那么应用程序可能使用的是文字SQL，因此无法共享SQL，或者共享池配置不良。有几种统计数据可用于确定Oracle解析所花费的时间。 从V $ SYSSTAT查询与分析相关的统计信息。 例如：

SELECT NAME, VALUE

FROM V$SYSSTAT

WHERE NAME IN ( 'parse time cpu', 'parse time elapsed',

'parse count (hard)', 'CPU used by this session' );

可以计算各种比率来帮助确定解析是否是一个问题：

■parse time CPU / parse time elapsed

这个比率表示分析花费的时间是由分析操作本身决定的，而不是等待资源（如锁存器）。 比例为1表示经过时间未用于等待高度争用的资源。

■parse time CPU / CPU used by this session

此比率表示Oracle服务器进程使用的CPU总量中有多少用于分析相关的操作。 接近于零的比率是好的，表明大部分CPU不用于解析。

Wait Events Statistics

V $ SESSION，V $ SESSION_WAIT，V $ SESSION_HISTORY，V $ SESSION_EVENT和V $ SYSTEM_EVENT视图提供有关等待什么资源的信息，以及如果配置参数TIMED_STATISTICS设置为true，则等待每个资源等待多久。

在执行反应性性能调整时调查等待事件和相关的时间数据。对他们列出的时间最多的事件往往是性能瓶颈的强烈迹象。

以下视图包含相同数据的相关但不同视图：

■V $ SESSION列出每个当前会话的会话信息。它列出当前正在等待的事件，或者每个会话最后等待的事件。该视图还包含有关阻塞会话，等待状态和等待时间的信息。

■V $ SESSION_WAIT是当前状态视图。它列出当前正在等待的事件，或者每个会话最后等待的事件，等待状态和等待时间。

■V $ SESSION_WAIT_HISTORY列出每个当前会话的最近10个等待事件以及相关的等待时间。

■V $ SESSION_EVENT列出了每个会话等待的事件的累积历史记录。会话退出后，该会话的等待事件统计信息将从该视图中删除。

■V $ SYSTEM_EVENT列出实例启动后整个实例等待的事件和时间（即所有会话等待事件数据汇总）。

因为V $ SESSION_WAIT是一个当前状态视图，它还包含比V $ SESSION_EVENT或V $ SYSTEM_EVENT更细的信息。它包括三个参数列中的当前事件的附加识别数据：P1，P2和P3。

例如，V$SESSION_EVENT可以显示会话124（SID = 124）在分散读取的db文件上有许多等待，但它不显示哪个文件和块的编号。但是，V$SESSION_WAIT显示P1中的文件编号，P2中读取的块编号以及P3中读取的块数（P1和P2让您确定发生了哪些等待事件）。

本节重点介绍使用V $ SESSION_WAIT的示例。但是，Oracle建议在一段时间内捕获性能数据并保留此数据以进行性能和容量分析。通过AWR从V $ SYSTEM_EVENT视图查询这种形式的汇总数据。请参阅第5-8页上的“自动负载库的概述”。

本章描述了最常遇到的事件，并以区分大小写的字母顺序列出。其他与事件相关的数据也包括在内。用于每个事件名称的情况是出现在V $ SYSTEM_EVENT视图中的情况。

与以前的版本不同，Oracle Database 11g对等待事件（例如V $ SYSTEM_EVENT视图中）的等待计数和超时进行了积累。持续等待某些类型的资源（如排队）在内部被分成一组较短的等待呼叫。在之前的版本中，每个单独的内部等待电话都被视为一次单独的等待。从版本11.1开始，单个资源等待被记录为一次等待，而不管在等待期间会话经历的内部超时数量。

此更改允许Oracle数据库显示更具代表性的等待计数以及等待资源所需的准确总时间。超时现在指的是资源等待，而不是个别的内部等待呼叫。此更改也会影响平均等待时间和最长等待时间。例如，如果用户会话必须等待排队才能使事务行锁更新表中的单个行，并且需要10秒才能获取排队，Oracle数据库将排队等待分解为3秒等待调用。在这个例子中，将会有三个3秒的等待电话，然后等待1秒钟。然而从会议的角度来看，只有一次排队等待。

在之前的版本中，V$SYSTEM_EVENT视图将代表这种等待场景，如下所示：

■TOTAL_WAITS：4个等待（3个3秒等待，1个1秒等待）

■TOTAL_TIMEOUTS：3次超时（前三次等待超时并在最终等待期间获得入队）

■TIME_WAITED：10秒（4次等待的时间总和）

■AVERAGE_WAIT：2.5秒

■MAX_WAIT：3秒

在Oracle数据库11g中，此等待方案表示为：

■TOTAL_WAITS：1等待（等待10秒钟）

■TOTAL_TIMEOUTS：0超时（排队在资源等待期间获取）

■TIME_WAITED：10秒（资源等待的时间）

■AVERAGE_WAIT：10秒

■MAX_WAIT：10秒

以下常见等待事件受此更改影响：

■Enqueue waits (such as enq: name - reason waits)

■Library cache lock waits

■Library cache pin waits

■Row cache lock waits

以下统计数据受到此更改的影响：

■Wait counts

■Wait time outs

■Average wait time

■Maximum wait time

以下视图受此更改的影响：

■V $ EVENT_HISTOGRAM

■V $ EVENTMETRIC

■V $ SERVICE_EVENT

■V $ SERVICE_WAIT_CLASS

■V $ SESSION_EVENT

■V $ SESSION_WAIT

■V $ SESSION_WAIT_CLASS

■V $ SESSION_WAIT_HISTORY

■V $ SYSTEM_EVENT

■V $ SYSTEM_WAIT_CLASS

■V $ WAITCLASSMETRIC

■V $ WAITCLASSMETRIC_HISTORY

buffer busy waits

此等待表明缓冲区缓存中有多个进程正试图同时访问的缓冲区。 查询V $ WAITSTAT获取每类缓冲区的等待统计信息。 具有缓冲区繁忙等待的公共缓冲区类包括数据块，段标题，撤销标题和撤消块。

检查以下V $ SESSION_WAIT参数列：

■P1：文件ID

■P2：块ID

■P3：Class ID

原因

要确定可能的原因，首先查询V $ SESSION以在会话等待缓冲区忙等待时识别ROW_WAIT_OBJ＃的值。 例如：

SELECT row_wait_obj#

FROM V$SESSION

WHERE EVENT = 'buffer busy waits';

要标识争用的对象和对象类型，请使用从V $ SESSION返回的ROW_WAIT_OBJ＃的值查询DBA_OBJECTS。 例如：

SELECT owner, object_name, subobject_name, object_type

FROM DBA_OBJECTS

WHERE data_object_id = &row_wait_obj;

操作

所需的操作取决于争用的块的类别和实际的段。

段头

如果争用在段头上，那么这很可能是空闲列表争用。

本地管理的表空间中的自动段空间管理消除了指定PCTUSED，FREELISTS和FREELIST GROUPS参数的需要。如果可能，请从手动空间管理切换到自动段空间管理（ASSM）。

如果您无法使用ASSM，则以下信息是相关的（例如，因为表空间使用字典空间管理）。

空闲列表是一个空闲数据块的列表，通常包括段中存在几个不同区域的块。空闲列表由可用空间尚未达到PCTFREE的块或已用空间缩小到PCTUSED以下的块组成。使用FREELISTS参数指定进程空闲列表的数量。 FREELISTS的默认值是1。最大值取决于数据块大小。

要查找该段的空闲列表的当前设置，请运行以下命令：

SELECT SEGMENT_NAME, FREELISTS

FROM DBA_SEGMENTS

WHERE SEGMENT_NAME = segment name

AND SEGMENT_TYPE = segment type;

设置空闲列表，或增加空闲列表的数量。 如果添加更多空闲列表并不能缓解问题，那么请使用空闲列表组（即使在单个实例中，这可能会有所不同）。 如果使用Oracle RAC，则确保每个实例都有自己的空闲列表组。

数据块

如果争用在表或索引（而不是段头）上：

■检查右侧索引。 这些是由许多进程在同一点插入的索引。 例如，那些使用序列号生成器作为键值的。

■考虑使用ASSM，全局散列分区索引或增加空闲列表以避免尝试插入同一个块的多个进程。

undo header

对于rollback segment header的争用：

■如果您未使用自动撤消管理，请添加更多回滚段。

undo block

对于rollback segment block的争用：

■如果您未使用自动撤消管理，请考虑增大回滚段大小。

db file scattered read

此事件表示用户进程正在将缓冲区读取到SGA缓冲区缓存中，并等待物理I / O调用返回。分散读取的db文件发出散乱的读取以将数据读取到多个不连续的存储器位置。分散读取通常是多块读取。除了全表扫描以外，还可以进行快速全面扫描（索引）。

db文件分散读取等待事件标识正在进行完整扫描。在对缓冲区高速缓存执行全面扫描时，将读取的块读入彼此物理上不相邻的存储器位置。这种读取称为分散读取调用，因为这些块分散在整个内存中。这就是为什么相应的等待事件被称为“db文件散读”的原因。多块（最多DB_FILE_MULTIBLOCK_READ_COUNT块）由于完全扫描到缓冲区缓存中而显示为等待'db文件散读'。

检查以下V $ SESSION_WAIT参数列：

■P1：绝对文件编号

■P2：正在读取的块

■P3：块的数量（应大于1）

操作

在一个健康的系统上，物理读取等待应该是空闲等待后最大的等待时间。但是，还应考虑是否存在直接读取等待（表示具有并行查询的全表扫描）或db文件分散读取等待应该执行小索引访问的操作（OLTP）系统。

其他可能表明系统上的I / O负载过多的情况包括：

■较差的缓冲区缓存命中率

■这些等待事件会导致用户遇到响应时间较长的大部分等待时间

管理过多的I / O

有几种方法可以处理过多的I / O等待。按照有效性的顺序，这些如下：

■通过SQL调优减少I / O活动。

■通过管理工作负载来减少对I / O的需求。

■使用DBMS_STATS包收集系统统计信息，允许查询优化器精确计算使用完整扫描的可能访问路径。

■使用自动存储管理。

■添加更多磁盘以减少每个磁盘的I / O数量。

■通过在现有磁盘上重新分配I / O来缓解I / O热点。

第一步应该是找到减少I / O的机会。检查由等待这些事件和语句的会话运行的SQL语句，这些事件和语句会导致来自V$SQLAREA的高物理I / O。可能会对导致过多I / O的执行计划产生不利影响的因素包括：

■不适当优化的SQL

■缺少索引

■表格的高度并行性（将优化器偏向扫描）

■优化器缺乏准确的统计信息

■将DB_FILE_MULTIBLOCK_READ_COUNT初始化参数的值设置得太高，这有利于完整扫描

I / O分配不足

除了减少I / O外，还要检查磁盘上文件的I / O分布情况。 I / O是否均匀分布在磁盘上，或者某些磁盘上是否存在热点？磁盘的数量是否足以满足数据库的I / O需求？

查看数据库的总I / O操作（读取和写入），并将其与所用磁盘的数量进行比较。请记住包含LGWR和ARCH进程的I / O活动。

查找由Sessions等待I / O执行的SQL语句

使用以下查询来确定在某个时间点哪些会话正在等待I / O：

SELECT SQL_ADDRESS, SQL_HASH_VALUE

FROM V$SESSION

WHERE EVENT LIKE 'db file%read';

查找需要I / O的对象

要确定可能的原因，首先查询V $ SESSION以在会话等待db文件分散读取时识别ROW_WAIT_OBJ＃的值。 例如：

SELECT row_wait_obj#

FROM V$SESSION

WHERE EVENT = 'db file scattered read';

要标识争用的对象和对象类型，请使用从V$SESSION返回的ROW_WAIT_OBJ＃的值查询DBA_OBJECTS。 例如：

SELECT owner, object_name, subobject_name, object_type

FROM DBA_OBJECTS

WHERE data_object_id = &row_wait_obj;

数据库文件顺序读取

此事件表示用户进程正在将缓冲区读入SGA缓冲区缓存，并等待物理I / O调用返回。顺序读取是单块读取。

单块I / O通常是使用索引的结果。很少，由于范围界限或缓冲区，全表扫描调用可能会被截断为单个块调用

也可以看看：

第8章“I / O配置和设计”出现在缓冲区缓存中。这些等待也会显示为db文件顺序读取。

检查以下V $ SESSION_WAIT参数列：

■P1：绝对文件编号

■P2：正在读取的块

■P3：块的数量（应为1）

操作

在一个健康的系统上，物理读取等待应该是空闲等待后最大的等待时间。但是，还要考虑在大型数据仓库中是否有db文件顺序读取操作，该大型数据仓库应该可以看到大多数使用并行查询的全表扫描。

图10-1描述了以下等待事件之间的差异：

■db文件顺序读取（将单个块读入一个SGA缓冲区）

■分散读取db文件（将多块读入许多不连续的SGA缓冲区）

■直接读取（将单个或多个块读入PGA，绕过SGA）

direct path read and direct path read temp

当会话从磁盘直接读取缓冲区到PGA（与SGA中的缓冲区缓存相对）时，它会等待此事件。如果I / O子系统不支持异步I / O，则每个等待都对应一个物理读取请求。

如果I / O子系统支持异步I / O，那么进程可以将发出的读请求与处理PGA中存在的块重叠。当进程尝试访问尚未从磁盘读取的PGA中的块时，它会发出一个等待调用并更新此事件的统计信息。因此，等待的数量不一定与读取请求的数量相同（不像db文件分散读取和db文件顺序读取）。

检查以下V$SESSION_WAIT参数列：

■P1：读取调用的File_id

■P2：为读取的调用启动block_id

■P3：读取调用中的块数

原因

这种情况发生在以下情况：

■种类太大而不适合内存，某些排序数据直接写入磁盘。稍后使用直接读取读回该数据。

■并行从站用于扫描数据。

■服务器进程处理缓冲区的速度比I / O系统可以返回缓冲区的速度快。这可能表示过载的I / O系统。

操作

file_id显示读取是针对TEMP表空间中的对象（排序到磁盘）还是通过并行从属进行全表扫描。这一等待是大型数据仓库网站的最大等待时间。但是，如果工作负载不是决策支持系统（DSS）工作负载，请检查这种情况发生的原因。

排序到磁盘

检查会话当前正在运行的SQL语句，等待查看导致排序的原因。查询V $ TEMPSEG_USAGE以查找正在生成排序的SQL语句。还从V $ SESSTAT查询会话的统计信息以确定排序的大小。查看是否可以通过调整SQL语句来减少排序。如果WORKAREA_SIZE_POLICY为MANUAL，则考虑增加系统的SORT_AREA_SIZE（如果排序不太大）或单个进程。如果WORKAREA_SIZE_POLICY为AUTO，则调查是否增加PGA_AGGREGATE_TARGET。请参阅第7-39页的“PGA内存管理”。

全表扫描

如果表的定义具有高度的并行性，那么这个设置可能会使优化器倾向于使用并行从机的全表扫描。使用直接路径读取检查正在读入的对象。如果全表扫描是工作负载的有效部分，那么确保I / O子系统足以满足并行度。如果您尚未使用磁盘分条或Oracle自动存储管理（Oracle ASM），请考虑使用磁盘分条。

哈希区域大小

对于调用散列连接的查询计划，HASH_AREA_SIZE太小可能导致过多的I / O。如果WORKAREA_SIZE_POLICY是MANUAL，那么考虑增加系统或单个进程的HASH_AREA_SIZE。如果WORKAREA_SIZE_POLICY为AUTO，则调查是否增加PGA_AGGREGATE_TARGET。

direct path write and direct path write temp

当一个进程直接从PGA写入缓冲区（而不是DBWR从缓冲区缓存写入缓冲区）时，进程等待该事件完成写入调用。可以执行直接路径写入的操作包括在磁盘上排序，并行DML操作，直接路径INSERT，并行创建表作为select以及一些LOB操作。

与直接路径读取一样，如果I / O子系统支持异步写入，等待次数与发出的写入次数不同。会话等待它是否处理了PGA中的所有缓冲区，并且直到I / O请求完成时才能继续工作。

检查以下V $ SESSION_WAIT参数列：

■P1：写入调用的File_id

■P2：为写入呼叫启动block_id

■P3：写入呼叫中的块数

原因

这发生在以下情况：

■排序太大而无法放入内存并写入磁盘

■发布并行DML以创建/填充对象

■直接路径加载

操作

有关大量排序，请参阅第10-24页的“对磁盘进行分类”。

对于并行DML，请检查磁盘之间的I / O分布并确保I / O子系统针对并行度进行了充分配置。

enqueue (enq:) waits

排队是协调对数据库资源访问的锁。 此事件表明会话正在等待另一个会话持有的锁定。

enqueue的名称作为等待事件名称的一部分包含，形式为enq：enqueue_type - related_details。 在某些情况下，可以为不同目的保留相同的队列类型，例如以下相关的TX类型：

■enq：TX - 分配ITL条目

■enq：TX - 争用

■enq：TX - 索引争用

■enq：TX - 行锁争用

V $ EVENT_NAME视图提供了所有enq：wait事件的完整列表。

您可以查看以下V $ SESSION_WAIT参数列以获取更多信息：

■P1：锁定TYPE（或名称）和MODE

■P2：锁的资源标识符ID1

■P3：锁的资源标识符ID2

寻找锁和锁持有人

查询V $ LOCK查找持有锁的会话。对于等待事件排队的每个会话，V $ LOCK中有一行，REQUEST <> 0.使用以下两个查询之一查找持有锁并等待锁的会话。

如果有排队等待，您可以使用以下语句查看这些排队：

SELECT * FROM V $ LOCK WHERE request> 0;

要仅显示持有者和服务员等待的锁，请使用以下内容：

SELECT DECODE（request，0，'Holder：'，'Waiter：'）||

sid sess，id1，id2，lmode，request，type

 from V$LOCK 

WHERE（id1，id2，type）IN（SELECT id1，id2，type from V$LOCK WHERE request> 0）

ORDER BY id1,request;

操作

适当的操作取决于排队的类型。

ST入队

如果争用排队是ST入队，那么问题很可能是动态空间分配。当数据段中没有更多可用空间时，Oracle数据库会动态地为该段分配一个扩展区。该排队仅用于字典管理的表空间。

解决对此资源的争用：

■检查临时（即排序）表空间是否使用TEMPFILES。如果不是，则切换到使用TEMPFILES。

■如果包含动态增长段的表空间是字典管理的，则切换到使用本地管理的表空间。

■如果无法切换到本地管理的表空间，则可以通过将增长对象的下一个扩展区大小更改为足够大以避免不变的空间分配来减少ST排队资源使用情况。要确定哪些分段不断增长，请监视所有SEGMENT_NAME的DBA_SEGMENTS视图的EXTENTS列。有关显示有关空间使用情况的信息，请参见“Oracle数据库管理指南”。

■例如，通过使用ALTER TABLE ALLOCATE EXTENT SQL语句分配盘区来预分配段中的空间。

HW enqueue 硬件入队用于序列化超出一个段的高水位标记的空间分配。

■V$SESSION_WAIT.P2 / V $ LOCK.ID1是表空间编号。

■V$SESSION_WAIT.P3 / V $ LOCK.ID2是正在分配空间的对象的段头的相对数据块地址（dba）。

如果这是一个对象的争用点，那么手动分配盘区解决了这个问题。

TM入队

在TM锁上等待的最常见原因往往涉及约束列未编入索引的外键约束。索引外键列以避免此问题。

TX入队

当事务发起其第一次更改并持续到事务执行COMMIT或ROLLBACK时，它们将被取消。

■在模式6中等待TX：当会话正在等待另一个会话持有的行级别锁定时发生。这发生在一个用户正在更新或删除一行时，另一个会话想要更新或删除。这种TX入队等待对应于等待事件enq：TX - 行锁争用。

解决方案是让第一个会话持有锁执行COMMIT或ROLLBACK。

■如果会话正在等待块中的ITL（感兴趣的事务处理列表）插槽，则可能发生模式4中的TX等待。当会话想要锁定块中的一行时，会发生这种情况，但一个或多个其他会话的行在同一个块中被锁定，并且该块中没有空闲的ITL槽。通常，Oracle数据库会动态添加另一个ITL插槽。如果块中没有足够的可用空间来添加ITL，则这可能不可行。如果是，则会话在模式4中等待TX入队的插槽。这种TX入队等待对应于等待事件enq：TX - 分配ITL入口。

解决方法是通过更改表的INITRANS或MAXTRANS（通过使用ALTER语句或通过重新创建具有更高值的表）来增加可用ITL的数量。

■如果会话由于UNIQUE索引中潜在的重复而等待，也可能发生模式4中的TX等待。如果两个会话尝试插入相同的密钥值，则第二个会话必须等待以查看是否应提出ORA-0001。这种TX入队等待对应于等待事件enq：TX - 行锁争用。

解决方案是让第一个会话持有锁执行COMMIT或ROLLBACK。

■如果由于共享位图索引片段导致会话正在等待，那么也可以在模式4中等待TX。位图索引索引键值和一系列rowid。位图索引中的每个条目可以覆盖实际表格中的许多行。如果两个会话要更新同一位图索引片段覆盖的行，则第二个会话通过等待模式4中的发送锁定等待第一个事务处理为COMMIT或ROLLBACK。此类TX匹配等待对应于等待事件enq：TX - 行锁争用。

■等待模式4中的TX也可能发生，以等待PREPARED事务。

■当在索引中插入行的事务必须等待索引块拆分的结束由另一个事务完成时，才会发生模式4中的TX等待。这种TX入队等待对应于等待事件enq：TX - 索引争用。

其他等待课中的事件

此事件属于其他等待类，通常不应在系统上发生。此事件是其他等待类中所有其他事件的集合，例如无锁存，并仅用于V $ SESSION_EVENT和V $ SERVICE_EVENT视图。在这些视图中，其他等待类中的事件不会在每个会话中单独维护。相反，这些事件将汇总到此单个事件中，以减少用于维护其他等待类中的事件统计信息的内存。

免费缓冲区等待

此等待事件表明服务器进程无法找到空闲缓冲区，并通过写出脏缓冲区来发布数据库写入程序以释放空闲缓冲区。脏缓冲区是其内容已被修改的缓冲区。当DBWR将块写入磁盘时，脏缓冲区被释放以供重用。

原因

在以下情况下，DBWR可能无法跟上脏缓冲区的写入：

■I / O系统速度慢。

■正在等待的资源，如锁存器。

■缓冲区缓存非常小，因此DBWR大部分时间都会清除缓冲区以用于服务器进程。

■缓冲区缓存非常大，以至于一个DBWR进程不足以释放缓存中足够的缓冲区以满足请求。

操作

如果此事件频繁发生，则检查会话是否等待DBWR查看是否有任何延迟DBWR的事件。

写

如果它正在等待写入，那么确定什么是延迟写入并修复它。检查以下内容：

■检查V $ FILESTAT以查看大部分写入正在发生的位置。

■检查I / O系统的主机操作系统统计信息。写入时间可以接受吗？

如果I / O速度慢：

■考虑使用更快的I / O替代方法来加快写入时间。

■在大量主轴（磁盘）和控制器之间传播I / O活动。有关平衡I / O的信息，请参见第8章“I / O配置和设计”。

缓存太小

DBWR可能非常活跃，因为缓存太小。通过查看缓冲区缓存命中率是否较低来调查这是否是可能的原因。还可以使用V $ DB_CACHE_ADVICE视图来确定较大的缓存大小是否有利。请参阅第7-7页上的“调整缓冲区高速缓存的大小”。

对于一个DBWR，缓存太大

如果缓存大小足够且I / O均匀分布，则可以通过使用异步I / O或使用多个数据库编写器来修改DBWR的行为。

考虑多个数据库编写器（DBWR）进程或I / O从站

当事务速率很高或缓冲区高速缓存大小过大以致单个DBWn进程无法跟上负载时，配置多个数据库写入器进程或使用I / O从站很有用。

DB_WRITER_PROCESSES

DB_WRITER_PROCESSES初始化参数允许您配置多个数据库写入器进程（从DBW0到DBW9以及从DBWa到DBWj）。配置多个DBWR进程分配标识要写入的缓冲区所需的工作，并将I / O负载分配给这些进程。强烈建议对于具有多个CPU（至少每8个CPU有一个数据库写入器）或多个处理器组（至少与处理器组一样多的数据库写入器）的系统使用多个数据库写入器进程。

根据CPU数量和处理器组数量，Oracle数据库为DB_WRITER_PROCESSES选择适当的默认设置或调整用户指定的设置。

DBWR_IO_SLAVES

如果使用多个DBWR进程是不切实际的，那么Oracle数据库提供了一种工具，可以将I / O负载分布到多个从进程上。 DBWR进程是扫描要写出的块的缓冲区缓存LRU列表的唯一进程。但是，这些块的I / O由I / O从站执行。 I / O从站的数量由参数DBWR_IO_SLAVES决定。

DBWR_IO_SLAVES适用于不能使用多个DB_WRITER_PROCESSES的情况（例如，只有一个CPU的情况下）。当异步I / O不可用时，I / O从站也很有用，因为多个I / O从站通过释放DBWR来继续标识要写入的高速缓存中的块来模拟非阻塞异步请求。操作系统级别的异步I / O（如果有的话）通常是首选。

DBWR I / O从站在进行第一个I / O请求时立即在数据库打开后进行分配。除执行I / O操作外，DBWR继续执行与DBWR相关的所有工作。 I / O从站仅代表DBWR执行I / O。批处理的写入在I / O从站之间并行化。

选择多个DBWR进程和I / O从站

当单个DBWR进程无法跟上所需的工作负载时，配置多个DBWR进程可以提高性能。但是，在配置多个DBWR进程之前，请检查系统上是否有可用和配置的异步I / O。如果系统支持异步I / O但目前未使用异步I / O，则启用异步I / O以查看是否可以缓解问题。如果系统不支持异步I / O，或者配置了异步I / O并且仍然存在DBWR瓶颈，则配置多个DBWR进程。

注意：

如果异步I / O在您的平台上不可用，则可以通过将DISK_ASYNCH_IO初始化参数设置为FALSE来禁用异步I / O。

使用多个DBWR可并行收集和写入缓冲区。 因此，多个DBWn进程应该比具有相同数量的I / O从站的一个DBWR进程提供更多的吞吐量。 出于这个原因，I / O从站的使用已被弃用，以支持多个DBWR进程。 只有在无法配置多个DBWR进程时才能使用I / O从站。

空闲等待事件

这些事件属于空闲等待类，并指出服务器进程正在等待，因为它没有工作。 这通常意味着如果存在瓶颈，那么瓶颈不适用于数据库资源。 调优时大多数空闲事件应该被忽略，因为它们并不能表明性能瓶颈的性质。 一些闲置事件可以用来指示瓶颈不是什么。 这种类型的事件的一个例子是客户端遇到的最常见的空闲等待事件SQL Net消息。 表10-2列出了这个和其他空闲事件（及其类别）。

闩锁事件

锁存器是Oracle数据库用于保护存储器结构的低级内部锁。 当服务器进程试图获取锁存器时，更新锁存器事件，并且锁存器在第一次尝试时不可用。

对于通常会产生显着争用的更受欢迎的锁存器，有一个与锁相关的专用等待事件。 对于这些事件，锁存器的名称出现在等待事件的名称中，例如latch：library cache或latch：cache buffers chains。 这使您能够快速确定特定类型的锁存器是否导致大部分与锁存器相关的争用。 等待所有其他锁存器分组在通用锁存器等待事件中。

操作

如果锁定等待是系统整体等待时间的重要部分，或者是个人用户遇到问题，那么这个事件应该只是一个问题。

■检查相关资源的资源使用情况。 例如，如果库高速缓存闩锁严重争用，则检查硬解析速率和软解析速率。

■检查出现锁定争用的会话的SQL语句，以查看是否有任何共同点。

检查以下V $ SESSION_WAIT参数列：

■P1：锁存器的地址

■P2：锁存号码

■P3：进程休眠的次数，等待锁存器

示例：查找当前等待的锁存器

SELECT EVENT, SUM(P3) SLEEPS, SUM(SECONDS_IN_WAIT) SECONDS_IN_WAIT

FROM V$SESSION_WAIT

WHERE EVENT LIKE 'latch%'

GROUP BY EVENT;

前一个查询的问题是，它会告诉更多关于会话调整或即时实例调优的信息，而不是实例或长时间实例调优。

以下查询提供了有关长时间实例调整的更多信息，显示了闩锁在整个数据库时间内是否等待显着。

SELECT EVENT, TIME_WAITED_MICRO,

ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME

FROM V$SYSTEM_EVENT,

(SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S

WHERE EVENT LIKE 'latch%'

ORDER BY PCT_DB_TIME ASC;

不特定于等待锁定的更一般的查询如下：

SELECT EVENT, WAIT_CLASS,

TIME_WAITED_MICRO,ROUND(TIME_WAITED_MICRO*100/S.DBTIME,1) PCT_DB_TIME

FROM V$SYSTEM_EVENT E, V$EVENT_NAME N,

(SELECT VALUE DBTIME FROM V$SYS_TIME_MODEL WHERE STAT_NAME = 'DB time') S

WHERE E.EVENT_ID = N.EVENT_ID

AND N.WAIT_CLASS NOT IN ('Idle', 'System I/O')

ORDER BY PCT_DB_TIME ASC;

共享池和库缓存闩锁争用

共享池或库缓存闩锁争用的主要原因是解析。 有几种技术可以用来识别不必要的解析和几种不必要的解析：

■非共享SQL

■重新共享可共享SQL

■按会话

■缓存lru链

■缓存缓冲区链

■行缓存对象

非共享SQL

此方法标识在文字被绑定变量替换时可以共享的类似SQL语句。 这个想法是要么：

■手动检查只有一个执行的SQL语句，以查看它们是否相似：

SELECT SQL_TEXT FROM V$SQLSTATS

WHERE EXECUTIONS < 4

ORDER BY SQL_TEXT;

或者，通过分类可能是类似的陈述来自动化这个过程。 估计可能相同的SQL语句的字节数，并将SQL语句按此字节数进行分组。 例如，以下示例组只在前60个字节后有所不同。

SELECT SUBSTR(SQL_TEXT, 1, 60), COUNT(*)

FROM V$SQLSTATS

WHERE EXECUTIONS < 4

GROUP BY SUBSTR(SQL_TEXT, 1, 60)

HAVING COUNT(*) > 1;

或报告具有相同执行计划的不同SQL语句。 以下查询选择至少四次共享相同执行计划的不同SQL语句。 这些SQL语句可能使用文本而不是绑定变量。

SELECT SQL_TEXT FROM V$SQLSTATS WHERE PLAN_HASH_VALUE IN

(SELECT PLAN_HASH_VALUE

FROM V$SQLSTATS

GROUP BY PLAN_HASH_VALUE HAVING COUNT(*) > 4)

ORDER BY PLAN_HASH_VALUE;

Reparsed Sharable SQL

Check the V$SQLSTATS view. Enter the following query:

SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS

FROM V$SQLSTATS

ORDER BY PARSE_CALLS;

当PARSE_CALLS值接近给定语句的EXECUTIONS值时，您可能会不断地重新解析该语句。 使用较高数量的解析调用调整语句。

按会话

通过识别发生的会话识别不必要的解析呼叫。 可能是特定的批处理程序或某些类型的应用程序执行了大部分重新分析。 要实现此目标，请运行以下查询：

SELECT pa.SID, pa.VALUE "Hard Parses", ex.VALUE "Execute Count"

FROM V$SESSTAT pa, V$SESSTAT ex

WHERE pa.SID = ex.SID

AND pa.STATISTIC#=(SELECT STATISTIC#

FROM V$STATNAME WHERE NAME = 'parse count (hard)')

AND ex.STATISTIC#=(SELECT STATISTIC#

FROM V$STATNAME WHERE NAME = 'execute count')

AND pa.VALUE > 0;

结果是所有会话的列表以及它们执行的重新分析的数量。 对于每个会话标识符（SID），请转到V $ SESSION以查找导致重新分析的程序的名称。

注意：

因为这个查询会在实例启动后统计所有解析调用，所以最好查找具有高解析速率的会话。 例如，已连接50天的连接可能会显示较高的解析数字，但第二个连接可能已连续10分钟并以更快的速度解析。

缓存lru链

缓存缓冲区lru链锁存器保护缓存中的缓冲区列表。在添加，移动或从列表中移除缓冲区时，必须获得锁存器。

对于对称多处理器（SMP）系统，Oracle数据库自动将LRU锁存器的数量设置为等于系统上CPU数量一半的值。对于非SMP系统，一个LRU锁存器就足够了。

争用LRU锁存器可能会妨碍具有大量CPU的SMP计算机的性能。通过查询V $ LATCH，V $ SESSION_EVENT和V $ SYSTEM_EVENT来检测LRU锁存器争用情况。为避免争用，请考虑优化应用程序，绕过DSS作业的缓冲区缓存或重新设计应用程序。

缓存缓冲区链

高速缓存缓冲区链锁存器用于保护缓冲区高速缓存中的缓冲区列表。这些锁存器用于在缓冲区缓存中搜索，添加或删除缓冲区。对这个锁存器的争夺通常意味着有一个非常有争议的块（称为热块）。

为了识别大量访问的缓冲区链，并因此争用块，请使用视图V $ LATCH_CHILDREN查看缓存缓冲区链锁存器的锁存统计信息。如果存在与其他子锁存器相比具有更多GETS，MISSES和SLEEPS的特定缓存缓冲区链子锁存器，则这是争用子锁存器的。

该锁存器具有一个内存地址，由ADDR列标识。使用与X $ BH表连接的ADDR列中的值来标识受此锁存器保护的块。例如，给定地址（V $ LATCH_CHILDREN.ADDR）的高度竞争锁存器，这将查询文件和块号码：

SELECT OBJ data_object_id, FILE#, DBABLK,CLASS, STATE, TCH

FROM X$BH

WHERE HLADDR = 'address of latch'

ORDER BY TCH;

X $ BH.TCH是缓冲区的触摸计数。 X $ BH.TCH的高值表示热块。

每个锁存器都保护许多块。 其中一个缓冲区可能会成为热点区块。 任何具有高TCH值的块都是潜在的热点块。 多次执行此查询，并确定始终显示在输出中的块。 确定热块后，使用文件编号和块编号查询DBA_EXTENTS，以标识段。

在确定了热点区块后，您可以使用以下查询来识别它所属的区段：

SELECT OBJECT_NAME, SUBOBJECT_NAME

FROM DBA_OBJECTS

WHERE DATA_OBJECT_ID = &obj;

在查询中，＆obj是X $ BH上一个查询中OBJ列的值。

row cache objects

行缓存对象锁存器保护数据字典。

日志文件并行写入

此事件涉及将重做记录写入日志缓冲区中的重做日志文件。

库缓存引脚

该事件管理库缓存并发性。固定对象会导致堆被加载到内存中。如果客户想要修改或检查该对象，则客户必须在锁定后获取一个PIN。

库缓存锁

此事件控制库高速缓存的客户端之间的并发性。它获取对象句柄的锁定，以便执行以下操作之一：

■一个客户端可以阻止其他客户端访问同一个对象

■客户端可以长时间保持依赖关系，这不允许其他客户端更改对象

该锁也可以在库缓存中找到对象。

log buffer space 日志缓冲区空间

当服务器进程正在等待日志缓冲区中的可用空间时发生此事件，因为所有的重做生成都比LGWR可以写出的时间快。

操作

修改重做日志缓冲区大小。如果日志缓冲区的大小合理，请确保联机重做日志驻留的磁盘不会遭受I / O争用。日志缓冲区空间等待事件可能表示重做日志驻留的磁盘上的磁盘I / O争用或者过小的日志缓冲区。检查包含重做日志的磁盘的I / O配置文件，以调查I / O系统是否是瓶颈。如果I / O系统不是问题，那么重做日志缓冲区可能太小。增加重做日志缓冲区的大小，直到此事件不再有意义。

log file switch 日志文件切换

通常遇到两个等待事件：

■日志文件切换（需要归档）

■日志文件切换（检查点不完整）

在这两个事件中，LGWR都无法切换到下一个联机重做日志文件。所有的提交请求都等待这个事件。

操作

对于日志文件切换（需要归档）事件，请检查归档人员无法及时归档日志的原因。这可能是由于以下原因：

■存档目标的可用空间不足。

■Archiver无法快速读取重做日志（与LGWR竞争）。

■Archiver无法足够快地写入（对归档目标的争用，或没有足够的ARCH进程）。如果您排除了其他可能性（例如慢速磁盘或完整归档目标），请考虑增加ARCn进程的数量。默认值是2。

■如果您有强制远程发货的存档日志，请检查此过程是否由于网络延迟而减慢，或者由于错误导致写入未完成。

根据瓶颈的性质，您可能需要重新分配I / O或向归档目标添加更多空间以缓解问题。对于日志文件切换（检查点不完整）事件：

■检查DBWR是否很慢，可能是由于I / O系统过载或速度太慢。检查DBWR写入次数，检查I / O系统，并在必要时分配I / O。请参见第8章“I / O配置和设计”。

■检查是否有太少或太少的重做日志。如果您有一些重做日志或小重做日志（例如，2 x 100k日志），并且在DBWR能够完成检查点之前，系统会产生足够的重做来遍历所有日志，那么请增加大小或数量的重做日志。请参阅第4-3页上的“调整重做日志文件大小”。

log file sync 日志文件同步

当用户会话提交（或回滚）时，会话的重做信息必须由LGWR刷新到重做日志文件。执行COMMIT或ROLLBACK的服务器进程在此事件下等待写入重做日志以完成。

操作

如果此事件的等待时间构成系统的重大等待时间，或者遇到响应时间问题的用户等待的大量时间或系统上，则检查等待的平均时间。

如果等待的平均时间很短，但等待的数量很高，那么应用程序可能在每次INSERT后提交，而不是批量提交。应用程序可以通过提交50行后而不是每行来减少等待时间。

如果等待的平均时间很长，那么检查会话是否等待日志编写者，并查看大部分时间花费和等待的时间。如果等待是由于I / O速度较慢，请尝试以下操作：

■减少包含重做日志的磁盘上的其他I / O活动，或使用专用磁盘。

■在不同磁盘上备用重做日志，以尽量减少归档器对日志记录器的影响。

■将重做日志移动到更快的磁盘或更快的I / O子系统（例如，从RAID 5切换到RAID 1）。

■考虑使用原始设备（或由磁盘供应商提供的模拟原始设备）加速写入。

■根据应用程序的类型，可以通过提交每N行而不是每行来批处理COMMIT，这样可以减少日志文件同步。

rdbms ipc reply

此事件用于等待来自其中一个后台进程的回复。

SQL * Net事件

以下事件表示数据库进程正在等待来自数据库链接或客户端进程的确认：

■SQL * Net中断/重置到客户端

■SQL * Net中断/重置为dblink

■来自客户端的SQL * Net消息

■来自dblink的SQL * Net消息

■客户端的SQL * Net消息

■SQL * Net消息到dblink

■来自客户端的SQL * Net更多数据

■来自dblink的SQL * Net更多数据

■SQL *将更多数据网络传输到客户端

■SQL * Net向dblink添加更多数据

如果这些等待时间构成系统等待时间的重要部分或用户遇到响应时间问题，则网络或中间层可能是瓶颈。

与客户端相关的事件应该按照来自客户端的事件SQL * Net消息的描述进行诊断。与dblink相关的事件应按照来自dblink的事件SQL * Net消息的描述进行诊断。

来自客户端的SQL * Net消息

虽然这是一个闲置事件，但解释什么时候可以用这个事件来诊断什么不是问题很重要。此事件表示服务器进程正在等待来自客户端进程的工作。但是，有几种情况可能会导致用户遇到响应时间较长的大部分等待时间。原因可能是客户端进程中的网络瓶颈或资源瓶颈。

网络瓶颈

如果应用程序在服务器和客户端之间导致大量流量，并且网络延迟（往返时间）很长，则可能会出现网络瓶颈。症状包括以下内容：

■大量等待此事件

■大部分时间数据库和客户端进程都处于空闲状态（等待网络通信量）

为了缓解网络瓶颈，请尝试以下操作：

■调整应用程序以减少往返次数。

■探索减少延迟的选项（例如，与VSAT链路相反的地面线路）。

■更改系统配置以将更高流量组件移至较低延迟链路。

客户流程中的资源瓶颈

如果客户端进程正在使用大部分资源，那么在数据库中没有任何事情可以完成。症状包括以下内容：

■等待的次数可能并不多，但等待的时间可能很长

■客户端进程的资源使用率很高

在某些情况下，您可以看到等待用户密切跟踪客户端进程使用的CPU数量的等待时间。术语“客户端”在此指的是除n层架构中的数据库进程（中间层，桌面客户端）以外的任何进程。

来自dblink的SQL * Net消息

此事件表示会话已向远程节点发送消息并正在等待数据库链接的响应。这一次可能会因以下原因而增加：

■网络瓶颈

有关信息，请参阅第10-37页上的“来自客户端的SQL * Net消息”。

■在远程节点上执行SQL的时间

查看正在远程节点上运行的SQL很有用。登录到远程数据库，找到由数据库链接创建的会话，并检查它正在运行的SQL语句。

■往返消息的数量

会话和远程节点之间的每条消息都会增加延迟时间和处理开销。要减少交换的消息数量，请使用数组提取和数组插入。

SQL *向客户端提供更多数据

服务器进程正在向客户端发送更多数据或消息。之前对客户的操作也是发送。

四：Real-Time SQL Monitoring 实时SQL监控

Oracle数据库的实时SQL监视功能使您能够监视SQL语句执行时的性能。默认情况下，SQL监控会在SQL语句并行运行时自动启动，或者在单次执行中消耗至少5秒的CPU或I / O时间时自动启动。

您可以使用V $ SQL_MONITOR和V $ SQL_PLAN_MONITOR视图监视SQL语句执行的统计信息。您可以将这些视图与以下视图结合使用以获取有关正在监视的执行的附加信息：

■V $ ACTIVE_SESSION_HISTORY

■V $ SESSION

■V $ SESSION_LONGOPS

■V $ SQL

■V $ SQL_PLAN

在启动监视之后，数据库会向动态性能视图V $ SQL_MONITOR添加一个条目。此条目跟踪为执行收集的关键性能指标，包括已用时间，CPU时间，读写次数，I / O等待时间以及各种其他等待时间。这些统计数据会随着语句的执行而近乎实时地刷新，通常每秒钟刷新一次。执行结束后，监视信息不会立即删除，而是保留在V $ SQL_MONITOR视图中至少一分钟。该条目最终将被删除，因此在监视新语句时可以回收它的空间。

V $ SQL_MONITOR视图包含V $ SQL中可用统计信息的子集。但是，与V $ SQL不同，监控统计数据不会在多次执行时累积。相反，V $ SQL_MONITOR中的一个条目专用于单个SQL语句的执行。如果数据库监视同一SQL语句的两次执行，则每个执行在V $ SQL_MONITOR中都有一个单独的条目。

为了唯一标识同一个SQL语句的两个执行，会生成一个名为执行键的组合键。该执行键由三个属性组成，每个属性对应于V $ SQL_MONITOR中的一列：

■用于标识SQL语句的SQL标识符（SQL_ID）

■开始执行时间戳（SQL_EXEC_START）

■内部生成的标识符以确保此主键真正唯一（SQL_EXEC_ID）

本节包含以下主题：

■SQL计划监视

■并行执行监控

■生成SQL监视器报告

■启用和禁用SQL监视

SQL Plan Monitoring

实时SQL监视还包括监视正在监视的SQL语句的执行计划中每个操作的统计信息。这些数据在V $ SQL_PLAN_MONITOR视图中可见。与V $ SQL_MONITOR视图相似，随着SQL语句的执行，V $ SQL_PLAN_MONITOR中的统计信息每秒更新一次。这些统计信息在执行结束后保持不变，持续时间与V $ SQL_MONITOR相同。对于正在监视的每个SQL语句，V $ SQL_PLAN_MONITOR中将有多个条目;每个条目将对应于语句执行计划中的一个操作。

并行执行监控

只要执行开始，数据库就会自动监控并行查询，DML和DDL语句。 V $ SQL_MONITOR和V $ SQL_PLAN_MONITOR视图将参与并行执行的每个进程的监视信息记录为单独的条目。

V $ SQL_MONITOR有一个用于并行执行协调器进程的入口，每个并行执行服务器进程有一个入口。每个条目在V $ SQL_PLAN_MONITOR中都有相应的条目。由于为并行执行SQL语句分配的进程正在协作执行相同的操作，因此这些条目共享相同的执行键（复合SQL_ID，SQL_EXEC_START和SQL_EXEC_ID）。因此，您可以聚合执行键以确定并行执行的总体统计信息。

生成SQL监视器报告

您可以使用SQL监视器报告查看SQL监视数据。 SQL监视器报告使用来自多个视图的数据，其中包括：

■GV $ SQL_MONITOR

■GV $ SQL_PLAN_MONITOR

■GV $ SQL

■GV $ SQL_PLAN

■GV $ ACTIVE_SESSION_HISTORY

■GV $ SESSION_LONGOPS

要生成SQL监视器报告，请运行DBMS_SQLTUNE包中的REPORT_SQL_MONITOR函数：

variable my_rept CLOB;

BEGIN

:my_rept :=DBMS_SQLTUNE.REPORT_SQL_MONITOR();

END;

/

print :my_rept

DBMS_SQLTUNE.REPORT_SQL_MONITOR函数接受几个输入参数来指定执行情况，报告中的详细程度以及报告类型（'TEXT'，'HTML'或'XML'）。 默认情况下，如果没有指定参数（如示例中所示），则会为最后一次执行的监视生成文本报告。

示例10-1显示了SQL监视器报告的输出，用于上次执行监视的SQL语句。

Example 10–1 Sample SQL Monitor Report

set long 10000000

set longchunksize 10000000

set linesize 200

select dbms_sqltune.report_sql_monitor from dual;

SQL Text

----------------------------------------------------------------------------------------

select * from (select O_ORDERDATE, sum(O_TOTALPRICE)

from orders o, lineitem l

where l.l_orderkey = o.o_orderkey

group by o_orderdate

order by o_orderdate) where rownum < 100

----------------------------------------------------------------------------------------

在本报告的“全球信息”部分中，“状态”字段显示此语句仍在执行。 “活动时间”列显示操作活动的时间（第一个活动时间与最后一个活动时间之间的时间差）。 “Start Active”列以秒为单位显示执行计划中的操作相对于SQL语句执行开始时间开始的时间。在这份报告中，ID 5的快速全扫描操作是第一个开始（+ 1秒开始活动）并且跑了82秒。

Starts列显示执行计划中的操作执行次数。行（实际）列指示生成的行数，行（预测）列显示优化程序的估计基数。 Memory和Temp列指示执行计划的每个操作所占用的内存量和临时空间量。

活动（百分比）和活动详细信息（样本编号）列是通过加入V $ SQL_PLAN_MONITOR和V $ ACTIVE_SESSION_HISTORY视图派生的。活动（百分比）显示执行计划的每个操作消耗的数据库时间的百分比。活动详细信息（示例＃）显示该活动的性质（如CPU或等待事件）。在本报告中，此列显示大部分数据库时间36.68％被操作ID 8（ORDERS的TABLE ACCESS FULL）占用。该活动由73个样本（28 + 3 + 42）组成，其中一半以上的活动归因于直接路径读取（42个样本），另外三分之一归因于CPU（28个样本）。

最后一列Progress显示V $ SESSION_LONGOPS视图中操作的进度监控信息。在本报告中，它显示哈希连接操作已完成87％。

set linesize 200

col comm format a200

SELECT dbms_sqltune.report_sql_monitor(

sql_id => '2hxhny9phgu37',

report_level => 'ALL',

type=>'TEXT'

) comm

FROM dual;

Enabling and Disabling SQL Monitoring

初始化参数设置为ALL或TYPICAL（默认值）。 此外，CONTROL_MANAGEMENT_PACK_ACCESS参数必须设置为DIAGNOSTIC + TUNING（缺省值），因为SQL监视是Oracle数据库调整包的一个功能。 所有长时间运行的查询都会自动启动SQL监视。

两个语句级别的提示可用于强制或防止监视SQL语句。 要强制执行SQL监视，请使用MONITOR提示：

select /*+MONITOR*/ from dual;

仅当CONTROL_MANAGEMENT_PACK_ACCESS参数设置为DIAGNOSTIC + TUNING时，此提示才有效。 为了防止监视提示的SQL语句，请使用NO_MONITOR反向提示。

五：Tuning Instance Recovery Performance: Fast-Start Fault Recovery

本节介绍实例恢复，以及Oracle的快速启动故障恢复如何在发生崩溃或实例故障时提高可用性。 它还提供了调整执行崩溃和实例恢复所需时间的指导原则。

本节包含以下主题：

■关于实例恢复

■配置高速缓存恢复的持续时间：FAST_START_MTTR_TARGET

■调整FAST_START_MTTR_TARGET并使用MTTR Advisor

About Instance Recovery

实例和崩溃恢复是在发生崩溃或系统故障后自动将重做日志记录应用于Oracle数据块。在正常操作期间，如果干净地关闭实例（如同使用SHUTDOWN IMMEDIATE语句时），而不是异常终止，那么未写入磁盘上的数据文件的内存中的更改将作为在关机期间执行检查点。

但是，如果单个实例数据库崩溃或Oracle RAC配置的所有实例崩溃，则Oracle数据库在下次启动时执行崩溃恢复。如果Oracle RAC配置的一个或多个实例崩溃，则幸存的实例会自动执行实例恢复。实例和崩溃恢复分两步进行：高速缓存恢复，然后是事务恢复。

数据库可以在缓存恢复完成后立即打开，因此提高缓存恢复的性能对于提高可用性很重要。

Cache Recovery (Rolling Forward)

高速缓存恢复（向前滚动）

在高速缓存恢复步骤中，Oracle数据库将所有已提交和未提交的重做日志文件更改应用于受影响的数据块。缓存恢复处理所需的工作与数据库更改速率（每秒更新事务）和检查点之间的时间成正比。

Transaction Recovery (Rolling Back)

事务恢复（回滚）

要使数据库保持一致，必须撤消在崩溃时未提交的更改（换言之，回滚）。在事务恢复步骤中，Oracle数据库应用回滚段来撤消未提交的更改。

Checkpoints and Cache Recovery

检查点和高速缓存恢复

Oracle数据库定期记录一个检查点。检查点是最高系统更改编号（SCN），使得所有小于或等于该SCN的数据块已知被写入数据文件。如果发生故障，则只需在恢复过程中应用包含高于检查点的SCN更改的重做记录。缓存恢复处理的持续时间由两个因素决定：SCN上的更改数高于检查点的SCN的数据块数，以及需要读取以查找这些更改的日志块数。

检查点如何影响性能

经常检查点将脏缓冲区写入数据文件的次数比其他次数多，并且因此在发生实例故障时减少缓存恢复时间。如果点校验频繁，那么在当前检查点位置和日志结束之间的重做日志中应用重做记录涉及处理相对较少的数据块。这意味着恢复的缓存恢复阶段相当短。

但是，在高更新系统中，经常检查点可能会降低运行时性能，因为检查点导致DBWn进程执行写操作。

快速缓存恢复权衡

为了最小化高速缓存恢复的持续时间，您必须经常强制Oracle数据库检查点，从而将恢复期间应用的重做日志记录数保持为最小。但是，在高更新系统中，频繁检查点增加了常规数据库操作的开销。

如果日常运营效率比缩短恢复时间更重要，那么由于检查点而减少写入数据文件的频率。这应该会提高运营效率，但也会增加缓存恢复时间。

Configuring the Duration of Cache Recovery: FAST_START_MTTR_TARGET

快速启动故障恢复功能可缩短高速缓存恢复所需的时间，并通过限制脏缓冲区的数量以及最近重做记录和最后一个检查点之间生成的重做记录的数量，使恢复有限且可预测。

快速启动故障恢复的基础是快速启动检查点体系结构。取代传统的事件驱动（即日志切换）检查点，它执行批量写入，快速启动检查点增量发生。每个DBWn进程周期性地将缓冲区写入磁盘以提前检查点位置。首先写入最早修改的块，以确保每次写入都能让检查点前进。快速启动检查点消除了批量写入以及传统检查点发生的I / O尖峰。

借助快速启动故障恢复功能，FAST_START_MTTR_TARGET初始化参数可简化实例或系统故障的恢复时间配置。 FAST_START_MTTR_TARGET指定预期恢复平均时间（MTTR）的目标，即启动实例并执行缓存恢复所需的时间（以秒为单位）。在设置FAST_START_MTTR_TARGET之后，数据库会管理增量检查点写入操作，以尝试满足该目标。如果您为FAST_START_MTTR_TARGET选择了实用值，则可以预计数据库平均恢复时间大约为您选择的秒数。

注意：

使用FAST_START_MTTR_TARGET时，您必须禁用或删除FAST_START_IO_TARGET，LOG_CHECKPOINT_INTERVAL和LOG_CHECKPOINT_TIMEOUT初始化参数。 设置这些参数会干扰管理缓存恢复时间以满足FAST_START_MTTR_TARGET的机制。

Practical Values for FAST_START_MTTR_TARGET

FAST_START_MTTR_TARGET的最大值为3600秒（一小时）。 如果将该值设置为3600以上，那么Oracle数据库将其舍入为3600。

以下示例显示如何设置FAST_START_MTTR_TARGET的值：

SQL> ALTER SYSTEM SET FAST_START_MTTR_TARGET=30;

原则上，FAST_START_MTTR_TARGET的最小值为1秒。但是，您可以将FAST_START_MTTR_TARGET设置得很低这一事实并不意味着可以实现此目标。由于数据库启动时间等因素，可实现的最小MTTR目标存在实际限制。

在给定FAST_START_MTTR_TARGET当前值的情况下，数据库可以实现的MTTR目标称为有效MTTR目标。您可以通过查看V $ INSTANCE_RECOVERY视图的TARGET_MTTR列来查看当前有效的MTTR。

数据库的MTTR目标值的实际范围被定义为数据库的最低可实现有效MTTR目标与最坏情况下启动和高速缓存恢复所用时间最长的范围（也就是说，当整个缓冲区缓存很脏）。 “确定FAST_START_MTTR_TARGET的实际范围”（第10-46页）介绍了确定可实现的MTTR目标值范围的过程，这是调整FAST_START_MTTR_TARGET值过程中的一个步骤。

注意：

将FAST_START_MTTR_TARGET设置为实际范围之外的值通常没有用处。 如果FAST_START_MTTR_TARGET值小于实际范围的下限，则效果就好像将其设置为实际范围的下限。 在这种情况下，有效的MTTR目标将是系统可以实现的最佳MTTR目标，但是检查点将处于最大值，这可能会影响正常的数据库性能。 如果您将FAST_START_MTTR_TARGET设置为比实际范围更长的时间，则MTTR目标不会比最差情况好。

降低检查点频率以优化运行时性能

要降低检查点频率并优化运行时性能，可以执行以下操作：

■将FAST_START_MTTR_TARGET的值设置为3600.这将启用快速启动检查点和快速启动故障恢复功能，但会将其对运行时性能的影响降至最低，同时避免需要对FAST_START_MTTR_TARGET进行性能调整。

■根据系统生成的重做量设置联机重做日志文件的大小。尝试最多每20分钟切换一次日志。让日志文件太小可能会增加检查点活动并降低性能。还要注意所有的重做日志文件应该是相同的大小。

使用V$INSTANCE_RECOVERY监控高速缓存恢复

V$INSTANCE_RECOVERY视图显示当前的恢复参数设置。您还可以使用此视图中的统计信息来确定哪个因素对检查点的影响最大。

下表列出了在监视预测高速缓存恢复性能时最有用的列：

有关V $ INSTANCE_RECOVERY中列的更多详细信息，请参阅Oracle数据库参考。

作为数据库持续监控的一部分，您可以定期将V$INSTANCE_RECOVERY.TARGET_MTTR与您的FAST_START_MTTR_TARGET进行比较。 如果FAST_START_MTTR_TARGET值在实际范围内，则这两个值通常应该相同。 如果TARGET_MTTR的持续时间长于FAST_START_MTTR_TARGET，则将FAST_START_MTTR_TARGET设置为不小于TARGET_MTTR的值。 如果TARGET_MTTR一直较短，则将FAST_START_MTTR_TARGET设置为不大于TARGET_MTTR的值。

Tuning FAST_START_MTTR_TARGET and Using MTTR Advisor

要为您的数据库确定FAST_START_MTTR_TARGET的适当值，请使用以下四个步骤过程：

■校准FAST_START_MTTR_TARGET

■确定FAST_START_MTTR_TARGET的实际范围

■使用MTTR Advisor评估不同的目标值

■确定重做日志的最佳大小

校准FAST_START_MTTR_TARGET

FAST_START_MTTR_TARGET初始化参数使数据库计算内部系统触发器值，以限制重做日志的长度和数据高速缓存中脏数据缓冲区的数量。该计算使用估计的时间来读取重做块，估计读取和写入数据块的时间以及系统典型工作负载的特性，例如有多少脏缓冲区与多少变化向量相对应等等。

最初，计算中使用内部默认值。这些默认值会随着时间的推移而被系统操作期间收集的I / O性能数据和实际的缓存恢复所取代。

您必须执行多次实例恢复才能正确校准FAST_START_MTTR_TARGET值。在开始校准之前，您必须确定FAST_START_MTTR_TARGET是针对数据库崩溃还是硬件崩溃进行校准。如果您的数据库文件存储在文件系统中，或者您的I / O子系统具有内存缓存，则这是一个考虑因素，因为根据是否缓存文件，读取和写入磁盘的时间有很大差异。 FAST_START_MTTR_TARGET的适当值取决于哪种类型的崩溃对于从快速恢复更重要。

要有效地校准FAST_START_MTTR_TARGET，请确保您足够长时间运行系统的典型工作负载，并执行多次实例恢复，以确保在恢复期间读取重做块的时间以及读取或写入数据块的时间能够被准确记录。

确定FAST_START_MTTR_TARGET的实际范围

校准后，您可以执行测试以确定数据库的FAST_START_MTTR_TARGET的实际范围。

确定FAST_START_MTTR_TARGET的下限：方案

要确定实际范围的下限，请将FAST_START_MTTR_TARGET设置为1，然后启动数据库。然后检查V $ INSTANCE_RECOVERY.TARGET_MTTR的值，并将此值用作FAST_START_MTTR_TARGET的下限。数据库启动时间（而不是缓存恢复时间）通常是确定此限制的主要因素。

例如，将FAST_START_MTTR_TARGET设置为1：

SQL> ALTER SYSTEM SET FAST_START_MTTR_TARGET=1;

Then, execute the following query immediately after opening the database:

SQL> SELECT TARGET_MTTR, ESTIMATED_MTTR

FROM V$INSTANCE_RECOVERY;

Oracle Database responds with the following:

18秒的TARGET_MTTR值是系统可以达到的最小MTTR目标值，也就是FAST_START_MTTR_TARGET的最低实际值。 此最小值基于平均数据库启动时间计算。

ESTIMATED_MTTR字段包含基于正在运行的数据库的当前状态的估计平均恢复时间。 由于数据库刚刚打开，因此系统包含很少脏缓冲区，因此如果实例在此时失败，则不需要太多缓存恢复。 这就是为什么ESTIMATED_MTTR目前可以低于最低可能的TARGET_MTTR。

ESTIMATED_MTTR可能会受到近期数据库活动的短期影响。 假定您在数据库中的一段繁重的更新活动之后立即查询V $ INSTANCE_RECOVERY。 Oracle数据库响应以下内容：

TARGET_MTTR ESTIMATED_MTTR

18 30

现在有效的MTTR目标仍然是18秒，估计的MTTR（如果发生崩溃）是30秒。 这是可以接受的结果。 这意味着某些检查点写入操作可能尚未完成，因此缓冲区高速缓存包含的目标更多的脏缓冲区。

现在等待60秒，然后将查询重新发送到V $ INSTANCE_RECOVERY。 Oracle数据库响应以下内容：

此时估计的MTTR已降至25秒，因为在此期间已经写出了一些脏缓冲区。

确定FAST_START_MTTR_TARGET的上限

要确定实际范围的上限，请将FAST_START_MTTR_TARGET设置为3600，并在典型工作负载下操作数据库一段时间。然后检查V $ INSTANCE_RECOVERY.TARGET_MTTR的值。此值是FAST_START_MTTR_TARGET的上限。

该过程与第10-46页的“确定FAST_START_MTTR_TARGET：方案的下限”中的过程基本相似。

为FAST_START_MTTR_TARGET选择初始值

确定FAST_START_MTTR_TARGET参数的实际界限后，为参数选择一个初始值。如果您关心的是数据库性能，请在实际范围内选择一个较高的值，如果您的优先级较短，则在实际范围内选择一个较低的值。当然，实际范围越窄，选择越容易。

例如，如果您发现实际范围在17到19秒之间，那么选择19会非常简单，因为恢复时间差异相对较小，同时最小化检查点对系统性能的影响。但是，如果您发现实际范围在18到40秒之间，则可以选择折衷值30，并相应地设置参数：

SQL> ALTER SYSTEM SET FAST_START_MTTR_TARGET=30;

您可能会继续使用MTTR Advisor来确定最佳值。

使用MTTR Advisor评估不同的目标值

为FAST_START_MTTR_TARGET选择初步值后，可以使用MTTR Advisor评估不同的FAST_START_MTTR_TARGET设置对系统性能的影响，与您选择的设置相比较。

启用MTTR顾问

要启用MTTR Advisor，请设置两个初始化参数STATISTICS_LEVEL和FAST_START_MTTR_TARGET。

STATISTICS_LEVEL决定是否所有顾问都已启用，并且不是特定于MTTR顾问。确保它被设置为TYPICAL或ALL。然后，当FAST_START_MTTR_TARGET设置为非零值时，启用MTTR Advisor。

使用MTTR顾问

启用MTTR Advisor后，运行一段时间的典型数据库工作负载。当MTTR Advisor处于ON状态时，数据库将模拟FAST_START_MTTR_TARGET当前值下的检查点队列行为，以及有效FAST_START_MTTR_TARGET值范围内的最多四个其他不同MTTR设置。 （在这种情况下，数据库将在测试范围中的不同值之前确定FAST_START_MTTR_TARGET本身的有效范围。）

查看MTTR顾问结果：V $ MTTR_TARGET_ADVICE

动态性能视图V $ MTTR_TARGET_ADVICE允许您查看由MTTR Advisor收集的统计数据或咨询。

数据库将填充V $ MTTR_TARGET_ADVICE，并提供有关数据库每个FAST_START_MTTR_TARGET设置效果的建议。对于FAST_START_MTTR_TARGET的每个可能的值，该行都包含有关在测试的工作负载下针对该值FAST_START_MTTR_TARGET执行多少个高速缓存写入的详细信息。

具体来说，每行包含有关缓存写入，总物理写入（包括直接写入）以及该值FAST_START_MTTR_TARGET的总I / O（包括读取）的信息，表示为操作总数和比率您选择的FAST_START_MTTR_TARGET值。例如，比率为1.2表示高速缓存写入多20％。

了解不同的FAST_START_MTTR_TARGET设置对缓存写入活动和其他I / O的影响，可以让您更好地确定哪个FAST_START_MTTR_TARGET值最适合您的恢复和性能需求。

如果MTTR Advisor目前处于开启状态，则V $ MTTR_TARGET_ADVICE显示收集的顾问信息。如果MTTR Advisor当前处于关闭状态，则该视图将显示自数据库启动以来MTTR Advisor上次收集的信息（如果有）。如果数据库自上次使用MTTR Advisor后已重新启动，或者从未使用过，则视图将不显示任何行。

确定重做日志的最佳大小

您可以使用V $ INSTANCE_RECOVERY视图列OPTIMAL_LOGFILE_SIZE来确定联机重做日志的大小。此字段显示以MB为单位的重做日志文件大小，根据FAST_START_MTTR_TARGET的当前设置将其视为最佳。如果此字段始终显示的值大于最小联机日志的大小，则应将所有联机日志配置为至少为此大小。

但请注意，重做日志文件大小会影响MTTR。 在某些情况下，您可以通过以建议的最佳日志文件大小重新运行MTTR Advisor来优化对最佳FAST_START_MTTR_TARGET值的选择。