合 【MOS】RAC 环境中最常见的 5 个数据库和或实例性能问题 (Doc ID 1602076.1)

RAC 环境中最常见的 5 个数据库和/或实例性能问题 (Doc ID 1602076.1)

Top 5 Database and/or Instance Performance Issues in RAC Environment (Doc ID 1373500.1)

用途

本文旨在提供关于 RAC 环境中最常见的数据库和/或实例性能问题的摘要以及可能的解决方案

请注意，问题 3（Mutexes 上的大量等待）和问题 5（高 CPU 和内存开销）是一般性数据库问题，并非特定于 RAC 的问题。不过，本文中讨论这些问题是因为这些是最常见的问题之一，会在 RAC 环境中的某一个实例发生。

适用范围

DBAs

详细信息

问题 1：大量块丢失 (gc lost blocks, gc current/cr lost blocks)

症状

I. AWR 报告中显示有大量块丢失。

II. netstat -s 报告数据包重新组装故障（reassambly failure）和丢失数据包（dropped packets）增加。

解决方案

使用以下文档进行故障排除并解决丢失块问题。该文档描述了症状、可能原因以及解决方案。

Document 563566.1 - gc block lost diagnostics

问题 2：大量 log file sync 等待

症状

I. AWR 报告中显示 log file sync 始终位于 Top 5 等待事件列表中。

II. 平均 log file sync 时间很长（> 20 毫秒）。

III. 平均 log file parallel write 时间很长（> 10 毫秒）。

III. 平均 redo write broadcast ack time 或者 wait for scn ack 时间很长（> 10 毫秒）。

IV. 平均 log file sync 时间很短，但 log file sync 等待次数太多。

背景

用户会话在提交或回退时，会话的重做信息需要由 LGWR 刷新到重做日志文件。用户会话等待“log file sync”的同时，等待 LGWR 通知确认所有重做更改已安全存放在磁盘上。

示例：

WAIT #0: nam='log file sync' ela= 977744 buffer#=754 p2=0 p3=0 obj#=114927 tim=1212384670107387

参数：

P1 = buffer#
P2 = 未使用
P3 = 未使用
obj# = object_id

对这个 buffer（在重做日志缓冲区）的所有更改必须刷新到磁盘并确认写入，以确保事务处理已提交，并且在实例关闭之前一直保持为已提交状态。

“log file sync”等待的典型生命周期

1. 用户会话发布提交或回退操作，然后开始等待 log file sync。
2. LGWR 收集要写入重做日志文件的重做信息，发布 IO 并将 BOC 入队到 LMS 进程，然后通知 LMS 进程。
3. LGWR 等待将重做信息刷新到磁盘以及等待 SCN 被确认收到
4. 完成 IO 并从 LMS 收到 SCN 的确认信息，表示写入完成。LGWR 然后通知前台进程继续。
5. 前台进程被唤醒，并且 log file sync 等待结束。

与 log file sync 相关的重要统计信息和事件

redo write time - 从重做日志缓冲区向当前重做日志文件写入所用的总时间，以10毫秒为单位。
redo writes - LGWR 向重做日志文件写入的总次数。“写入重做块数”除以此 统计信息等于每次写入的块数。
log file parallel write - 完成 I/O 的用时。虽然重做记录是并行写入的，但在最后一个 I/O 写入到磁盘上之前，并行写入不会完成。
redo write broadcast ack time - 在提交时，除了日志写入等待时间之外，与广播相关的总等待时间长度，以毫秒为单位。
user commits - 用户提交的数量。在用户提交事务时，必须将所生成的、反映对数据库块更改的重做写入到磁盘。提交操作通常代表的是最接近用户事务率的内容。
user rollbacks - 用户手动发布 ROLLBACK 语句的次数或者用户事务处理出误的次数。
Document 1064487.1 - Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) 中提供的脚本可以用于搜集诊断log file sync问题的有用信息。

可能原因

I. 重做日志文件所在设备的 IO 服务时间和吞吐量不理想。

II. Oracle Bug。有关已知 Oracle Bug，请查看 WAITEVENT: "log file sync" Reference (Document 34592.1)。

III. LMS 未在 RT（实时）类中运行。

IV. LGWR 进程调度延迟。

V. 提交数太多。

VI. 操作系统资源紧张。

解决方案

I. 如果日志文件并行写入始终很高（> 10 毫秒），则将重做日志文件移动到具有较高吞吐量和更短响应时间的磁盘上。日志文件并行写入理想范围应在 1-2 毫秒之间。

II. 应用适用于您的环境的已知 Oracle Bug 修复。获取这些修复的最有效方法是应用最新 PSU 补丁程序。Document 756671.1 提供了有关最新 PSU 的详细信息。

III. 确保 LMS 进程在 RT 类中运行。LMS 进程默认情况下在 RT 类中运行。

IV. 使用批量提交而不是在每次 DML 操作之后提交，可以减少提交数量。

V. 查看是否有任何活动可以使用 NOLOGGING/UNRECOVERABLE 选项安全地完成。

VI. 查看是否可以使用 COMMIT NOWAIT 选项。有关详细信息，请参阅 Document 857576.1。

@For Support Only: Renice LGWR to run at higher priority or run LGWR in RT class by adding LGWR to the parameter: _high_priority_processes='VKTM|LMS|LGWR". Consider doing this only if log file sync is high and scheduling delay of LGWR is found to be causing it. Be prepared to test it thoroughly.

问题 3：Mutexes 上的长时间等待

Mutexes 是比闩锁(latches)更为轻型且粒度更细的并行机制。获取 Mutex 的目的是为了确保正确管理特定操作的并行执行，例如，如果一个会话正在更改内存中的数据结构，则其他会话等到获取Mutex 后，才能进行类似的更改。下面是最常见的与 Mutex 相关的等待：

A. cursor: pin S wait on X
B. cursor: pin S
C. library cache: Mutex X

症状 (A)

AWR 报告中显示“cursor: pin S wait on X as one of the top wait”。

背景 (A)***

会话等待此事件是在它尝试获取共享模式的 Mutex 锁时，其他会话在相同游标对象上以独占方式持有 Mutex 锁。通常，等待“Cursor: pin S wait on X”是症状而非原因。其中可能需要进行底层的优化或者是已知问题。

可能原因 (A)

请查看 Troubleshooting 'cursor: pin S wait on X' waits (Document 1349387.1).

解决方案 (A)

请查看 Troubleshooting 'cursor: pin S wait on X' waits (Document 1349387.1).

症状 (B)

AWR 报告中显示“cursor: pin S as one of the top waits”

背景 (B)

会话在申请共享模式下特定游标上的特定 Mutex 时，虽然没有并行的排他持有者，但无法立即获取 Mutex，这时会等待“cursor: pin S”。这看上去有些不合理，因为用户可能会不理解为什么在没有排他模式持有者的情况下会存在这种等待。出现这种等待的原因是，为了在共享模式下获取 Mutex（或释放Mutex），会话必须增加（或减少）Mutex 引用计数，这需要对 Mutex 结构本身进行独占原子更新。如果有并行会话在尝试对 Mutex 进行这样的更新，则一次只有一个会话能够实际增加（或减少）引用计数。如果由于其他并行请求使得某个会话无法立即进行这种原子更新，则会出现等待“cursor: pin S”。
在 RAC 环境中，Mutex 只作用于本地实例。

参数：
P1 = idn
P2 = 值
P3 = where（10.2 中为 where|sleeps）

idn 是 Mutex 标识符值，与正在等待以获取 Mutex 的 SQL语句的 HASH_VALUE 相匹配。可以用以下格式的查询找到使用对应 IDN 的 SQL 语句：

SELECT sql_id, sql_text, version_count
FROM V$SQLAREA where HASH_VALUE=&IDN;

如果游标显示的 SQL_TEXT 格式为“table_x_x_x_x”，则这是特殊的内部游标，有关将此类游标映射到对象的详细信息，请参阅 Document 1298471.1。

P1RAW 是采用十六进制值的相同值，可用于在跟踪文件中搜索与该 hash（散列）值匹配的 SQL。

可能原因 (B)

I. 某个特定 Mutex 有大量并行操作，特别是在多个 CPU 的系统上。

II. 在高负载情况下，会等待非常多不同的“idn”值。

III. Oracle Bugs
Bug 10270888 - ORA-600[kgxEndExamine-Bad-State] / mutex waits after a self deadlock
Bug 9591812 - Wrong wait events in 11.2 ("cursor: mutex S" instead of "cursor: mutex X")
Bug 9499302 - Improve concurrent mutex request handling
Bug 7441165 - Prevent preemption while holding a mutex (fix only works on Solaris)
Bug 8575528 - Missing entries in V$MUTEX_SLEEP.location

解决方案 (B)

I. 应用 Bug 10411618 的修复。

II. 对于任何已标识的“热点”SQL，用户可以通过将 SQL 替换为一些由其他会话执行的变体，来减少特定游标上的并行操作。有关详细信息，请查看 WAITEVENT: cursor: pin S Reference (Document 1310764.1)。

III. 应用其他已知 Oracle bug 的修复。获取修复的最有效方法是应用最新 PSU patch（补丁程序）。 Document 756671.1 提供了有关推荐补丁程序的详细信息。

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。