肝了3晚！Oracle 10年DBA私货：I/O性能诊断全景图+硬核实战
askmeta约 25 分钟排除与I/O相关等待的故障
AWR（或Statspack）报告显示I/O等待事件在“前五等待/定时事件”部分中。
具有数据库会话等待事件的SQL跟踪显示，其主要受到I/O等待事件的限制。
操作系统工具显示用于存储数据库文件的磁盘的利用率或饱和度非常高。
排错步骤
故障排除与I/O相关的等待问题。
数据库性能调优中的关键活动是响应时间分析。 这包括查找数据库中时间花费在哪里。时间是性能调优中最重要的属性。 用户通过他们的交易或批处理作业体验到的响应时间来感知系统的性能。 对于Oracle数据库的响应时间分析使用以下公式完成：
Response Time = Service Time + Wait Time
'Service Time' 是使用“此会话使用的CPU”这个统计信息来测量的'Wait Time' 是通过将花费在等待事件上的时间总和来衡量的
注意：尽管在外观上类似，但这个公式不是数学排队论的基本公式。
使用诸如AWR和statspack等工具进行性能调优的方法是通过评估总体响应时间的各个组成部分的相对影响，并将调优工作引导到在耗时方面影响最大的组件上。 参考文档：
Document 190124.1 THE COE PERFORMANCE METHOD
从Oracle 10g开始，上述过程由自动数据库诊断监视器（ADDM）自动执行。请参见：
Document 250655.1 How to use the Automatic Database Diagnostic Monitor
确定I/O等待事件的实际意义。
许多工具，包括AWR和Statspack，会生成最重要的Top等待事件列表。 当面对这样一份等待事件列表时，有时很容易直接立即处理列出的等待事件，而忘记应首先评估它们对总体响应时间的影响。 在'Service Time'（即CPU使用率）比'Wait Time'更显著的情况下，调查等待事件很可能不会产生显着的'Response Time'节省。 因此，应始终将前几个等待事件所需的时间与“此会话使用的CPU”进行比较，并将调优工作引导到最大的消耗者上。
附加信息：在Oracle9i Release 2之前，Statspack报告在名为“Top 5 Wait Events”的部分中包含此信息。现在，“Top 5 Wait Events”部分已更名为“Top 5 Timed Events”，其中通过统计数据“此会话使用的CPU”测量的'Service Time' 列为“CPU时间”（从Oracle9i Release 2开始）。 这意味着现在更容易准确地衡量等待事件对整体'Response Time' 的影响，并正确地针对后续的调优工作。
若错误的理解等待事件的影响可造成诊断方向的偏差：举例说明
以下是两个真实案例，说明调查数据库性能时同时查看'Wait Time' 和'Service Time' 的重要性。
**案例 1 Oracle9i Release 2 之前的Statspack
以下是一个Statspack报告的“Top 5 Wait Events”部分，该报告是从相隔 46 分钟的两个快照中生成的：
Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
direct path read 4,232 10,827 52.
db file scattered read 6,105 6,264 30.
direct path write 1,992 3,268 15.
control file parallel write 893 198.
db file parallel write 40 131.
-------------------------------------------------------------
基于这个列表，我们可能会立即开始查找“direct path read”和“db file scattered read”这些等待的原因，并尝试对它们进行调整。 这种方法没有考虑'Service Time'。以下是来自同一报告的测量'Service Time'.的统计数据：
Statistic Total per Second per Trans
--------------------------------- ---------------- ------------ ------------
CPU used by this session 358,806 130.5 12,372.
如果我们从这些数据中进行一些简单的计算：
'Wait Time' = 10,827 x 100% / 52,01% = 20,817 cs
'Service Time' = 358,806 cs
'Response Time' = 358,806 + 20,817 = 379,623 cs
现在我们对所有'Response Time' 组成部分进行百分比计算：
CPU time = 94.52%
direct path read = 2.85%
db file scattered read = 1.65%
direct path write = 0.86%
control file parallel write = 0.05%
db file parallel write = 0.03%
现在很明显，与整体响应时间相比，与I/O相关的等待事件并不是一个重要组成部分（不到6%），因此应将后续调整工作重点放在服务时间组件即CPU消耗上。
例子 2 Oracle10i Release 2 后的 AWR
注：从Oracle 9i Release 2开始，Statspack报告中也显示类似的信息。
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU 33,615 82.
db file sequential read 3,101,013 7,359 2 18.0 User I/O
log file sync 472,958 484 1 1.2 Commit
read by other session 46,134 291 6 .7 User I/O
db file parallel read 91,982 257 3 .6 User I/O
在AWR中，我们更容易看到CPU是占用时间的重要部分，因为"Top 5 Timed Foreground Events"部分包括了一个CPU组件。 在上面的示例中，我们再次看到等待事件占总时间的比例不到20%，因此后续的调整应该针对服务时间部分，即CPU使用情况。
处理I/O问题的一般方法：
在使用 Statspack（例如）分析数据库响应时间后，如果发现性能主要是由于I/O相关的等待事件造成的，则可以采用多种可能的方法。 请参阅以下部分以了解每个等待事件应采用的方法。其中一些方法可以不考虑特定的等待事件而使用。 在下面的部分中，介绍和解释每种方法的概念和原理。
降低数据库产生的一般 I/O 流量
通过减少数据库中的活动，那么IO活动也可能会减少。可以考虑以下几个方面：
调优产生大量I/O或逻辑读的SQL。即使调优不产生“db file scattered read”的SQL，也可能会减轻一般I/O拥堵。
根据建议设置SGA缓冲池的大小
调整"schema"，例如调查分区是否可以减少IO
查找可以通过在线收缩（利用Segment Advisor）缩小的对象/可与清除旧数据结合使用。
调查使用物化视图来节省数据处理时间和数据IO访问时间（以及可能将数据处理卸载到远程数据库中完成）。
结果缓存允许存储查询、查询片段和函数结果集的结果。有关详细信息，请参见：
Oracle Database Online Documentation 12c Release 1 (12.1) / Database Administration
Database Concepts
Chapter 14 Memory Architecture
Server Result Cache
https://docs.oracle.com/database/121/CNCPT/memory.htm#CNCPT007
调查高级压缩选项（以减少所需的IO量）
将特定对象缓存到SGA缓冲池中
通常没有运行用户SQL的数据库产生很少或几乎不产生任何I/O的，所以理论上讲，数据库产生的所有I/O都可以说是直接或间接地归因于执行了用户的SQL的原因。
这意味着可以通过控制单个 SQL 生成的 I/O 数量来减少数据库对 I/O请求。这可以通过调整 SQL 语句来实现，以便它们的执行计划产生最少数量的 I/O 操作。通常在有问题的情况下，少数具有次优执行计划的SQL 语句就会产生比必要的多得多的物理I/O，从而导致数据库的整体性能降低。
从 Oracle 10g 开始，ADDM 通过自动识别影响最大的 SQL 语句来帮助 SQL 调优过程。 然后可以使用 SQL Tuning Advisor 自动调整这些语句并减少它们的 I/O 资源消耗。
参考文档：
Document 262687.1 How to use the Sql Tuning Advisor
通过调优实例参数降低数据库的 I/O 需求
1. 使用内存缓存来减少 I/O：
数据库所需的 I/O 数量可使用多个内存缓存来减少，例如 Buffer Cache、Log Buffer、各种排序区域等。通过增加 Buffer
Cache，在某种程度上可使数据库进程（逻辑 I/O）从内存中读取数据，而不是必须转到磁盘（物理 I/O）。若内存中有
较大的排序区域，它们在排序操作期间被耗尽并且不得不使用磁盘上的临时表空间的可能性会降低。其他缓存也根据类似
的概念。
调整多块 I/O 读的大小（与 10g 之前相关）
多块 I/O 读的大小由 db_file_multiblock_read_count 参数控制，该参数在 Oracle 10g 第 2 版中变为自调整。从 Oracle 10g 第 2 版开始，此参数会根据缓冲区缓存大小和会话参数自动设置，不建议调整，居然请参考：
Document 1398860.1 How is Parameter DB_FILE_MULTIBLOCK_READ_COUNT Calculated?
附加信息（10g 之前）：
单个多块 I/O 操作的大小可以由实例参数控制。在一定程度上，当少量的大 I/O请求场景下，多块 I/O 的执行速度比大量 较小的 I/O请求时执行得更快。例如，如果在 100 个大小为 1Mb 的请求中完成传输 100Mb 的数据，比在 1,000 个大小 为 100Kb 的请求或 10,000 个大小为 10Kb 的请求中完成的传输速度更快。达到此限制后，差异不再重要：在 100 个大 小为 10Mb 的请求中传输 1Gb 数据（如果操作系统的最大 I/O 传输大小限制允许）几乎与单次传输一样高效大小 1Gb。 这是因为服务 I/O 所花费的时间涉及两个主要部分：
I/O 设置时间：在不同的 I/O 大小之间趋向于相当恒定，并且对于小的 I/O 大小趋向于支配总服务时间。 I/O 传输时间：往往与 I/O 大小成比例增加，对于小 I/O 大小通常小于 I/O 设置时间。
上述结果是，在 10g 第 2 版之前，通常最好通过设置 DB_FILE_MULTIBLOCK_READ_COUNT 来配置实例，以便数据库通
过发起更多大的多块 I/O请求以达到提高IO性能的目的。
让剩下的 IO 尽可能高效 这涉及使用 I/O 功能，例如： 异步 I/O：异步 I/O 不会减少流量，但允许进程在等待 IO 完成时做其他事情。 直接 I/O（绕过操作系统的文件缓存）：直接 IO 不会减少流量，但可以使用更短的代码路径/更少的 CPU 周期来执行IO。
Document 432854.1 Asynchronous I/O Support on OCFS/OCFS2 and Related Settings: filesystemio_options,disk_asynch_io
另一个可能的操作是提高每次传输的最大 I/O 大小限制（在本文中称为 max_io_size）。
使用Oracle ASM（自动存储管理器）平衡数据库I/O
ASM 是随 Oracle10g 引入的。它是内置于数据库内核中的文件系统和卷管理器。它自动在所有可用磁盘驱动器之间并行进行负 载平衡，以防止热点并最大限度地提高性能，即使数据使用模式快速变化也是如此。它可以防止碎片化，因此永远不需要重新定 位数据来回收空间。数据在所有磁盘上均衡且条带化。
详情请见
Document 1187723.1 Primary Note for Automatic Storage Management (ASM)
以下文档讨论了有关 ASM 的基准：
Document 1153664.1 Comparing ASM to Filesystem in benchmarks
还可以使用智能数据放置功能，如下所述：
Oracle Database Online Documentation 11g Release 2 (11.2) / Database Administration
Automatic Storage Management Administrator's Guide
Chapter 4 Administering Oracle ASM Disk Groups
Intelligent Data Placement
https://docs.oracle.com/cd/E11882_01/server.112/e18951/asmdiskgrps.htm#OSTMG
通过使用条带化、 RAID 、 SAN 或 NAS 来平衡数据库 I/O 这种方法依赖于条带化、RAID、存储区域网络 (SAN) 和网络附加存储 (NAS) 等存储技术在多个可用物理磁盘之间自动负载平衡 数据库 I/O，以避免磁盘争用和 I/O 瓶颈存储硬件中仍有可用的未使用磁盘吞吐量。 有关这些技术的更详细讨论，请参阅
Optimal Storage Configuration Made Easy" by J. Loaiza
Document 30286.1 I/O T uning with Different RAID Configurations
通过跨不同文件系统、控制器和物理设备手动放置数据库文件来重新分配数据库 I/O 这是在没有先进的现代存储技术的情况下使用的方法。同样，目标是分配数据库 I/O，以便在仍有未使用的磁盘吞吐量时，不会 有任何一组磁盘或控制器因 I/O 请求而饱和。它比以前的方法更难操作，而且通常不太成功。 重要的是要记住，某些 I/O 将始终存在于大多数数据库中。在考虑了上述所有准则后，如果在现有系统上性能仍然不令人满意， 可以考虑： 通过移出旧数据来减少当前数据库的数据量 投资更多和/或更快的硬件 使用资源管理器管理失控 IO 如果个别会话使用过多的 IO，那么可以使用资源管理器限制它们的活动，这样它们就不会影响数据库上的其他活动。看：
Document 1600965.1 Managing and Monitoring Runaway Query Using Resource Manager
Technical Brief: Effective Resource Management Using Oracle Database Resource Manager
避免外部 IO 争用 如果设备由数据库外部的活动使用，则这些设备可能会与数据库活动竞争并降低其性能。
留意在太多虚拟环境中过度订阅 IO 带宽（Exadata 具有 IORM）
详细安排备份时间以避免与重要的批处理作业竞争（避免同时运行潜在的 IO 繁重操作）
还有哪些其他系统连接到同一个 NAS 存储？他们产生了多少 IO？
存储是否正在执行任何重新同步工作（更换损坏的磁盘镜像）？ASM 再平衡活动？
使用更快的硬件
如果硬件本身很慢，这可能会限制性能。可能有可用的硬件升级或优化：
更快的磁盘（10K rpm 与 7200 rpm，更多磁盘级缓存，无节能模式： - 空转/自旋减少）
使用磁盘的外圈磁道 VS 内圈磁道（智能数据放置）
闪存/智能存储阵列缓存
Exadata 存储（利用 HCC、存储索引）
Infiniband 网络减少 IO（和/或？）更高带宽的网络延迟
利用新技术
技术在不断发展，可能会有新的技术来提高 IO，例如 FS1 Storage Server 等技术。更多信息请参考：
https://www.oracle.com/corporate/pressrelease/fs1-flash-storage-system-092914.html
https://www.oracle.com/us/products/servers-storage/pillar-axiom-software-ds-487459.pdf
数据文件 I/O 相关等待事件
以下等待事件发生在对数据文件的 I/O 操作上。
'db file sequential read'
Document 34559.1 W AITEVENT: "db file sequential read" Reference Note
这是最常见的 I/O 相关等待之一。在大多数情况下，它是单个块读取，例如索引数据块或通过索引访问的表数据块，但也可以看 到数据文件头块上的读取。在早期版本中，它可能是从磁盘上的排序段到缓冲区缓存中的连续（“顺序”）缓冲区的多块读取。要 对出现此事件的高等待时间的情况进行故障排除，请参阅：
Document 1475825.1 Resolving Issues Where Application Queries are Waiting Too Frequently for'db file sequential read'Operations
Document 1477209.1 Resolving Issues Where Application Queries are Waiting Too Long for'db file sequential read'Operations Due to Underlying I/O Issues
如果此等待事件占等待时间的很大一部分，则可以采用多种方法：
在 Physical Reads 中找到 Top SQL 语句（来自 Statspack 或 AWR 报告中标题为“SQL ordered by Reads”的部分或来自视图 V$SQL）并调整它们以降低它们的 I/O 请求：
如果涉及索引范围扫描，若索引是选择性差的，则可能导致读取更多的数据块。
通过强制或允许使用选择性更好的索引来达到只通过较少的索引块（并执行更少的物理 I/O）就能访问相同的表数据的目的。
如果索引是碎片化的，就会导致SQL会访问更多的索引块，这是因为每个索引块里面引用的数据更少造成的。
在这种情况下，可以考虑重建索引，这会使其内容压缩到更少的块中。索引可以（在线）重建、收缩或合并。
如果正在使用的索引具有较大的聚簇因子，则会导致访问更多表数据块：通过重建表，其行按特定索引列排序来减少聚簇因子。
例如，如果表有列 A、B、C 和 D，并且索引在 B、D 上，那么我们可以将表重建为：
CREATE TABLE new AS SELECT * FROM old ORDER BY b,d;
具体信息请参考：
Document 39836.1 Clustering Factor
使用 Partitioning ： 通过 Partition Pruning 减少每条 SQL 语句访问的索引和表数据块的数量。
如果没有发现是由于特定 SQL的执行计划较差导致 I/O 过多，则性能问题可能是如下原因导致的：
由于磁盘上的过度活动，特定数据文件上的 I/O 的服务速度可能会变慢。在这种情况下，查看 Statspack 的"File I/O Statistics"部分（或 V$FILESTAT）将帮助我们找到此类热磁盘并通过手动将数据文件移动到其他存储或使用条带化来分散 I/O， RAID等技术自动为我们进行I/O负载均衡。
从 Oracle 9.2 开始，我们还可以通过使用来自视图 V$SEGMENT_STATISTICS 的新段统计数据，找到哪些段（表或索引）对其执行的物理读取最多。然后我们可以详细查看这些段，看看是否可通过重建索引或使用分区来减少它们的 I/O。
Statspack 从level=7 开始可以生成关于"Segment Statistics"的相关信息。
如果没有执行计划不理想的 SQL，并且 I/O 均匀分布，所有磁盘的响应时间相似，那么更大的缓冲区缓存可能会有所帮助：
在 Oracle8i 中，逐渐增加 DB_BLOCK_BUFFERS，然后测量缓冲区缓存命中率从 Statspack 直到没有进一步的改进。 在 Oracle9i 及更高版本中，使用 Buffer Cache Advisory 工具（也可在 Statspack 报告中找到）来调整 Buffer Cache 的大小。 详情请参考手册：
Oracle9i Database Performance Guide and Reference
Ch. 14 Memory Configuration and Use, Configuring and Using the Buffer Cache
在 Oracle10g 及以上版本中，可以使用自动共享内存管理 (ASMM) 使数据库能够根据最近的工作负载自动确定 Buffer Cache 的最佳大小。有关详细信息，请参阅
Document 257643.1 Oracle Database 10g Automated SGA Memory Tuning
对于热段，可以探索使用多个缓冲池：将此类热索引和表放在 KEEP 缓冲池中。详情请参阅
Document 135223.1 Oracle Multiple Buffer Pools Feature
最后，可以考虑减少最常访问的段中保存的数据（通过将不需要的旧数据移出数据库）或将这些段移动到更快的新磁盘以减少其 I/O 的响应时间。
**_'db file scattered read'_**
Document 34558.1 WAITEVENT: "db file scattered read" Reference Note
这是另一个非常常见的等待事件。当 Oracle 从磁盘执行多块读取到缓冲区缓存中的非连续（'scattered'）缓冲区时，就会发生这种情况。此类操作一次读取DB_FILE_MULTIBLOCK_READ_COUNT 个块。这些通常发生在全表扫描和快速全索引扫描中。要对
### 出现此事件的高等待时间的情况进行故障排除，请参阅：
Document 1476092.1 Resolving Issues Where 'db file scattered read' Waits are Seen Due to IO Performance Problems Document 1475785.1 Resolving Issues Where Application Queries are Waiting To Often for 'db file scattered read'Operations
如果此等待事件占等待时间的很大一部分，则可以采用多种方法：
查找哪些 SQL 语句执行全表或快速全索引扫描并调整它们以确保这些扫描是必要的，而不是执行计划不优导致的。
从 Oracle9i 开始，新视图 V$SQL_PLAN 视图可以帮助：（忽略这些查询输出中的数据字典 SQL）
对于全表扫描：
select sql_text from vsql_plan p
where t.hash_value=p.hash_value and p.operation='TABLE ACCESS'
and p.options='FULL'
order by p.hash_value, t.piece;### 对于快速全索引扫描：
select sql_text from vsql_plan p where t.hash_value=p.hash_value and p.operation='INDEX' and p.options='FULL SCAN' order by p.hash_value, t.piece;
### 否则，一种可能的方法是通过查询此等待事件的 V$SESSION_EVENT 来查找执行多块读取的会话，然后对它们进行 SQL跟踪。或者，可以调查物理读取的 Top SQL 语句，以查看它们的执行计划是否包含全表或快速全索引扫描。
在这种多块扫描发生在最佳执行计划的情况下，可以通过设置实例参数 DB_FILE_MULTIBLOCK_READ_COUNT 调整Oracle 发出的多块 I/O 的大小，以便 DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT = max_io_size of system 有关更多信息，请参考：
Document 30712.1 Init.ora Parameter "DB_FILE_MULTIBLOCK_READ_COUNT" Reference Document 1037322.6 WHAT IS THE DB_FILE_MULTIBLOCK_READ_COUNT PARAMETER?
如前所述，从 Oracle10g 第 2 版开始，DB_FILE_MULTIBLOCK_READ_COUNT 若是没有显式设置，初始化参数会自动调整为默认值。此默认值对应于可以有效执行的最大 I/O 大小。此值取决于平台，对于大多数平台而言为 1MB。因为该参数以块表示，所以它将被设置为等于可以有效执行的最大 I/O 大小除以标准块大小的值
由于使用 Full Table 和 Fast Full Index 扫描读取的块被放置在缓冲区缓存替换列表的最近最少使用的一端，有时使用多个缓冲池并将此类段放入 KEEP 池可能会有所帮助。
欲了解更多信息，请参阅
Document 135223.1 Oracle Multiple Buffer Pools Feature
分区也可用于减少要扫描的数据量，因为分区修剪可以将扫描限制在段分区的子集内。
如果活动主要来自报表或其他类似数据仓库的活动，则考虑将该活动卸载到只读备用数据库或 Active Data Guard 实例，以将其与生产系统上的 OLTP 活动分开。
使用 Database 12c 是将此类表加载到 IM 列存储中（特别是如果可以实现良好的压缩比）。更多信息请参考：
Oracle Database Online Documentation 12c Release 1 (12.1) / Database Administration
Database Administrator's Guide
Chapter 6 Managing Memory
https://docs.oracle.com/database/121/ADMIN/memory.htm#ADMIN
最后，可以考虑减少最常访问的段中保存的数据（通过将不需要的旧数据移出数据库）或将这些段移动到更快的新磁盘
以减少其 I/O 的响应时间。
'db file parallel read'
当 Oracle 从多个数据文件并行读取数据块到内存中的非连续缓冲区（PGA 或缓冲区高速缓存）时，将使用此等待事件。这是在 恢复操作期间或当缓冲区预取被用作优化时完成的，即而不是执行多个单块读取。
如果此等待是等待时间的重要组成部分，请遵循与'db file sequential read'相同的准则。
Direct Path Reads and Writes
'direct path read'
Document 50415.1 WAITEVENT: "direct path read" Reference Note
要对此等待事件的平均时间较高的情况进行故障排除，请参阅：
Document 1476089.1 Resolving Issues Where 'direct path read' Waits are Seen Due to Underlying I/O Performance
Problems
Document 1475655.1 Resolving Issues Where 'direct path write' Waits When I/O is NOT Slow and Cause is Unknown
'direct path write'
Document 50416.1 WAITEVENT: "direct path write" Reference Note
要对此等待事件的平均时间较高的情况进行故障排除，请参阅：
Document 1477235.1 Resolving Issues Where 'direct path write' Waits When I/O is Slow
'direct path read (lob)'
'direct path write (lob)'
上面这些等待事件发生在当数据库进程在磁盘和进程 PGA 内存之间执行特殊类型的多块 I/O 时，这种操作可以绕过数据库buffer cache从而提高性能。此类 I/O 可以同步和异步执行。
它们可能被使用的示例有： o 当内存排序区域耗尽并且临时表空间用于执行排序时对 I/O 排序 o 并行执行（查询和 DML） o 预读操作（缓冲区预取） o 直接加载操作 o I/ O 到 LOB 段（不缓存在 Buffer Cache 中）
由于记录这些等待事件的时间方法特别（它不测量执行 I/O 所花费的时间），所以它们在诸如 Statspack 的“Top 5 Wait/Timed Events”等列表中的的位置不能用于评估它们真正的影响。
调整指南：
建议尽可能使用异步 I/O。
在 Oracle8i 中，通过设置 DB_FILE_DIRECT_IO_COUNT 实例参数来最小化 I/O 请求的数量，以便 DB_BLOCK_SIZE x
DB_FILE_DIRECT_IO_COUNT = max_io_size of system
在 Oracle8i 中，默认为 64 个块。
（在 Oracle9i 中，它被 _DB_FILE_DIRECT_IO_COUNT 取代，它控制 BYTES 中直接 I/O 的大小（而不是块）。默认值为1Mb，但如果系统的 max_io_size 较小，则会缩小。）
Document 1038360.6 Init.ora Parameter "DB_FILE_DIRECT_IO_COUNT" Reference Note
调整内存排序区域，使用于排序的磁盘 I/O 最小化： 在 9i 和更高版本中使用自动 SQL 执行内存管理。 在 8i 中手动调整各种排序区域。
Document 147806.1 Automated SQL Execution Memory Management
Document 109907.1 How to Determine an Optimal SORT_AREA_SIZE
对于 LOB 段，将它们存储在操作系统文件缓冲区缓存可以提供一些内存缓存的文件系统上。 通过查询 VSESSTAT 以获取统计信息来识别执行直接 I/O 的会话： 'ph ysical reads direct', 'physical reads direct (lob)', 'ph ysical writes direct' & 'physical writes direct (lob)' 并调整他们的 SQL 语句。
使用 V$FILESTAT 或 Statspack 的"File IO Statistics" 内容来识别存在磁盘IO瓶颈的数据文件，并移动到其他地方。
### 临时表空间 I/O 相关的等待事件
### 这些等待事件发生在临时表空间的 I/O 访问期间。对这些事件的高等待意味着临时表空间正在发生大量活动。检查是否存在不必
要临时空间的IO操作。例如排序、hash join等。
确保统计信息是最新的，以便优化器有最好的机会获得良好的执行计划。
**_'direct path write temp'_**
等待写入临时表空间完成时发生此事件。检查 I/O 的持续时间以确定是否存在潜在的 I/O 问题，然后参阅以下文章以获得更多帮助：
Document 1576956.1 How to Address High Wait Times for the 'direct path write temp' Wait Event Document 2030900.1 Resolving Issues Where 'direct path write temp' Waits are Seen When I/O is NOT Slow and Cause is Unknown Document 2097893.1 WAITEVENT: "direct path write temp" Reference Note
**_'direct path read temp'_**
等待从临时表空间读取完成时会发生此事件。检查 I/O 的持续时间以确定是否存在潜在的 I/O 问题，然后参阅以下文章以获得
更多帮助：
Document 1476089.1 Resolving Issues Where 'direct path read' Waits are Seen Due to Underlying I/O Performance Problems Document 2097861.1 WAITEVENT: "direct path read temp" Reference Note
### 控制文件 I/O 相关的等待事件
这些等待事件发生在控制文件的一个或所有副本的 I/O 期间。控制文件访问的频率由重做日志文件切换和检查点等活动控制。
因此，它只能通过调整这些活动来间接影响。
**_'control file parallel write'_**
当服务器进程正在更新控制文件的所有副本时，会发生这种情况。如果它很重要，请检查控制文件所有副本的 I/O 路径（控制器、物理磁盘）上的瓶颈。
可能的解决方案：
将控制文件副本的数量减少到最少，以确保不会同时丢失所有副本。
如果的平台允许，请考虑尽量使用异步 I/O。
将控制文件副本移动到不太饱和的磁盘上。
'control file sequential read' and 'control file single write'
这些等待事件发生在访问某单个控制文件上。如果它们很严重，请查明是否该控制文件所在磁盘 I/O 已经饱和。
以下查询可用于查找正在访问的控制文件。它必须在问题发生时运行：
select P1,P2 from V$SESSION_WAIT where EVENT like 'control file%';
要查找 sid 的事件、wait_time、seconds_in_wait，请运行以下命令：
select EVENT, wait_time, seconds_in_wait, state from v$session_Wait where sid = '';
### 可能的解决方案：
### 将有问题的控制文件移动到不太饱和的磁盘上。
### 如果的平台可用，请使用异步 I/O。
**Redo Logging I/O 相关的等待事件**
在 Redo Logging 活动期间会发生许多等待事件，其中大部分与 I/O 相关。两个最重要的是'log file sync' 和'log file parallel
write'。
Oracle 前台进程等待'log file sync'，而 LGWR 进程等待'log file parallel write'。
虽然我们通常会在 Statspack 报告的"Top 5 Wait/Timed Events"部分找到'log file sync' ，但为了理解它，我们将首先查看'log file
parallel write'：
**_'log file parallel write'_**
Document 34583.1 WAITEVENT: "log file parallel write" Reference Note
LGWR 后台进程在将重做记录从内存日志缓冲区缓存复制到磁盘上的日志文件时等待此事件。如果开启了异步IO，那么将使用异步 I/O 来并行写入，否则这些写入将一个接一个地按顺序完成。
但是，LGWR 必须等到对所有成员日志文件的 I/O 都完成后，等待才会结束。因此，决定等待时间长短的因素是 I/O 子系统执行对日志文件成员写入的速度。
要减少等待此事件的时间，一种方法是减少数据库生成的redo数量：
使用 UNRECOVERABLE/NOLOGGING 选项。
减少重做组成员的数量，以确保不会同时丢失所有成员。
不要让表空间长时间处于 BACKUP 模式
仅使用所需的最低级别的补充日志记录（Supplemental Logging），例如 LogMiner、逻辑standby或stream。
另一种方法是调整 I/O 本身：
将重做组成员放在并发写不会引发争用的存储上
不要将 RAID-5 用于重做日志文件。
使用裸设备重做日志文件。
为重做日志文件使用更快的磁盘。
如果正在使用归档，则设置重做存储，以便当前重做组成员的写入不会与当前正在归档的组的读取竞争。
**_'log file sync'_**
Document 34592.1 W AITEVENT: "log file sync" Reference Note
当 Oracle 前台进程发出 COMMIT 或 ROLLBACK 操作并等待它完成时，会发生此等待事件。此等待的部分（但不是全部）包括
等待 LGWR 从日志缓冲区复制会话事务的重做记录内存到磁盘。
因此，在前台进程等待 'log fi le sync'的同时，LGWR 也会在'log file parallel write'上等待一部分时间。
理解延迟'log file sync' 的关键是比较 'log file sync' 和'log file parallel write'两个等待事件的平均时间差：
如果它们几乎相似，那么是日志文件 I/O 延迟造成的，并且应该遵循调整它的指南。 如果'log file parallel write' 明显不同，即更小，则延迟是由在 COMMIT/ROLLBACK 期间发生的 Redo Logging 机制的其他 部分引起的（与 I/O 无关）。 有时会在重做锁存器上发生锁存器争用，由'latch free' 或 'L GWR wait for redo copy'等待事件证明。
**_'log file sequential read' and 'log file single write'_**
这两个等待事件都与 I/O 相关，因此如果重做日志上存在 I/O 争用，它们很可能与 'log fi le parallel write'一起出现。请遵循相同
的准则来调整它们。
**_'switch logfile command' ,'log file switch completion' and 'log file switch (clearing log file)'_**
更多其他 LGWR I/O 相关的 Wait Events，调优方法和前面一样。
**_'log file switch (checkpoint incomplete)'_**
当检查点活动没有及时完成就会发生此等待事件。
有关调整检查点操作的指南，请参阅：
Document 147468.1 Checkpoint Tuning and Troubleshooting Guide Document 76713.1 8i P arameters that Influence Checkpoints
**_'log switch/archive' and 'log file switch (archiving needed)'_**
这些等待事件在启用归档时发生，表明归档执行得不够快。
有关调整归档操作的指南，请参阅：
Document 45042.1 Archiver Best Practices
**Buffer Cache I/O-Related Wait Events**
### 这些等待事件是DBWR 进程和 I/O 从属进程正在对缓冲区缓存进行操作。
**_'db file parallel write' , 'db file single write', 'write complete waits', 'free buffer waits'_**
Document 34416.1 WAITEVENT: "db file parallel write" Reference Note
<Document 2509995.1> Increasing Waits For Db File Async I/O Submit
### 有关调整这些等待的指南，请参阅以下文章：
Document 62172.1 Understanding and Tuning Buffer Cache and DBWR Document 76713.1 8i P arameters that Influence Checkpoints Document 147468.1 Checkpoint Tuning and Troubleshooting Guide
### 脚注
### 作为本文的最后一点说明，每当 I/O 性能和响应时间较差时，都值得检查操作系统日志中的相关错误。如果 I/O 子系统出
**现故障，则在 Oracle 数据库级别调查 I/O 性能毫无意义。如果是这种情况，应联系的硬件、操作系统或文件系统供应
商寻求帮助。**
**请确保已在托管 Oracle 数据库的系统上执行 Oracle 安装手册和管理员参考指南中描述的所有步骤，包括操作系统补丁、
内核参数和相关配置任务。**
### 与谁联系以获取更多信息？
### 果有具体问题，为什么不在 MOS 数据库调优社区中打开一个线程：
https://community.oracle.com/mosc/categories/database_tuning
### 以下有关 I/O 的说明也可能有用：Document 1275596.1 How to Tell if the IO of the Database is Slow Document 432854.1 Asynchronous I/O Support on OCFS/OCFS2 and Related Settings: filesystemio_options, disk_asynch_io Document 30286.1 I/O Tuning with Different RAID Configurations**Community Discussions**
Still have questions? Consider posting a discussion in the Database Tuning Community.
**使用更快的硬件**
如果硬件本身很慢，这可能会限制性能。可能有可用的硬件升级或优化：