AWR报告解读_CSR报告

需积分: 50 84 浏览量更新于2023-12-26 评论 1 收藏 1.96MB DOC 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

where a.header_file=b.p1 and a.header_block=b.p2 and b.event='buffer busy waits'

union

select 'Freelist Groups' class,a.segment_type,a.segment_name,a.partition_name from dba_segments

a,v$session_wait b

where a.header_file=b.p1 and b.p2 between a.header_block+1 and (a.header_block+a.freelist_groups)

and a.freelist_groups>1 and b.event='buffer busy waits'

union

select a.segment_type||' block' class,a.segment_type,a.segment_name,a.partition_name from

dba_extents a,v$session_wait b

where a.file_id=b.p1 and b.p2 between a.block_id and a.block_id+a.blocks-1 and b.event='buffer busy

waits' and not exists(select 1 from dba_segments where

header_file=b.p1 and header_block= b.p2);

查询的第一部分：如果等待的块类型是 segment header，那么可以直接拿 buffer busy waits 事件的

p1 和 p2 参数去 dba_segments 视图中匹配 header_file 和 header_block 字段即可找到等待的

segment 名称和 segment 类型，进行相应调整

查询的第二部分：如果等待的块类型是 freelist groups，也可以在 dba_segments 视图中找出对应的

segment 名称和 segment 类型，注意这里的参数 p2 表示的 freelist groups 的位置是在 segment 的

header_block+1 到 header_block+freelist groups 组数之间，并且 freelist groups 组数大于 1

查询的第三部分：如果等待的块类型是普通的数据块，那么可以用 p1、p2 参数和 dba_extents 进行

联合查询得到 block 所在的 segment 名称和 segment 类型

对于不同的等待块类型，我们采取不同的处理办法：

1.data segment header：

进程经常性的访问 data segment header 通常有两个原因：获取或修改 process freelists 信息、扩展

高水位标记，针对第一种情况，进程频繁访问 process freelists 信息导致 freelist 争用，我们可以增

大相应的 segment 对象的存储参数 freelist 或者 freelist groups；若由于数据块频繁进出 freelist 而导

致进程经常要修改 freelist，则可以将 pctfree 值和 pctused 值设置较大的差距，从而避免数据块频繁

进出 freelist；对于第二种情况，由于该 segment 空间消耗很快，而设置的 next extent 过小，导致频

繁扩展高水位标记，解决的办法是增大 segment 对象的存储参数 next extent 或者直接在创建表空间

的时候设置 extent size uniform

2.data block：

某一或某些数据块被多个进程同时读写，成为热点块，可以通过如下这些办法来解决这个问题：

(1)降低程序的并发度，如果程序中使用了 parallel 查询，降低 parallel degree，以免多个 parallel

slave 同时访问同样的数据对象而形成等待降低性能

(2)调整应用程序使之能读取较少的数据块就能获取所需的数据，减少 buffer gets 和 physical reads

(3)减少同一个 block 中的记录数，使记录分布于更多的数据块中，这可以通过若干途径实现：可以

调整 segment 对象的 pctfree 值，可以将 segment 重建到 block size 较小的表空间中，还可以用

alter table minimize records_per_block 语句减少每块中的记录数

(4)若热点块对象是类似自增 id 字段的索引，则可以将索引转换为反转索引，打散数据分布，分散热

点块

3.undo segment header：

undo segment header 争用是因为系统中 undo segment 不够，需要增加足够的 undo segment，根

据 undo segment 的管理方法，若是手工管理模式，需要修改 rollback_segments 初始化参数来增加

rollback segment，若是自动管理模式，可以减小 transactions_per_rollback_segment 初始化参数的

值来使 oracle 自动增多 rollback segment 的数量

4.undo block：

undo block 争用是由于应用程序中存在对数据的读和写同时进行，读进程需要到 undo segment 中去

获得一致性数据，解决办法是错开应用程序修改数据和大量查询数据的时间

小结：buffer busy waits 事件是 oracle 等待事件中比较复杂的一个，其形成原因很多，需要根据 p3

参数对照 Oracle 提供的原因代码表进行相应的诊断，10g 以后则需要根据等待的 block 类型结合引

起等待时间的具体 SQL 进行分析，采取相应的调整措施

】

4) latch free：当闩锁丢失率高于 0.5%时，需要调整这个问题。详细的我们在后面的 Latch Activity for

DB 部分说明。

latch 是一种低级排队机制，用于保护 SGA 中共享内存结构。latch 就像是一种快速地被获取和释放

的内存锁。用于防止共享内存结构被多个用户同时访问。如果 latch 不可用，就会记录 latch 释放失败

(latch free miss )。有两种与闩有关的类型:

　　■ 立刻。

　　■ 可以等待。

　　假如一个进程试图在立刻模式下获得闩，而该闩已经被另外一个进程所持有，如果该闩不能立

可用的话，那么该进程就不会为获得该闩而等待。它将继续执行另一个操作。

　　大多数 latch 问题都与以下操作相关:

　　没有很好的是用绑定变量(library cache latch)、重作生成问题(redo allocation latch)、缓冲存储

竞争问题(cache buffers LRU chain)，以及 buffer cache 中的存在"热点"块(cache buffers chain)。

　　通常我们说，如果想设计一个失败的系统，不考虑绑定变量，这一个条件就够了，对于异构性

强的系统，不使用绑定变量的后果是极其严重的。

　　另外也有一些 latch 等待与 bug 有关，应当关注 Metalink 相关 bug 的公布及补丁的发布。当

latch miss ratios 大于 0.5%时，就应当研究这一问题。

　　Oracle 的 latch 机制是竞争，其处理类似于网络里的 CSMA/CD，所有用户进程争夺 latch，对

于愿意等待类型(willing-to-wait)的 latch,如果一个进程在第一次尝试中没有获得 latch,那么它会等待并且再

尝试一次,如果经过_spin_count 次争夺不能获得 latch, 然后该进程转入睡眠状态，持续一段指定长度的时

间，然后再次醒来，按顺序重复以前的步骤.在 8i/9i 中默认值是_spin_count=2000。

　　如果 SQL 语句不能调整，在 8.1.6 版本以上，Oracle 提供了一个新的初始化参数:

CURSOR_SHARING 可以通过设置 CURSOR_SHARING = force 在服务器端强制绑定变量。设置该参数

可能会带来一定的副作用，对于 Java 的程序，有相关的 bug，具体应用应该关注 Metalink 的 bug 公告。

***Latch 问题及可能解决办法

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

* Library Cache and Shared Pool (未绑定变量---绑定变量,调整 shared_pool_size)

每当执行 SQL 或 PL/SQL 存储过程,包,函数和触发器时,这个 Latch 即被用到.Parse 操作中

此 Latch 也会被频繁使用.

* Redo Copy (增大_LOG_SIMULTANEOUS_COPIES 参数)

重做拷贝 Latch 用来从 PGA 向重做日志缓冲区拷贝重做记录.

* Redo Allocation (最小化 REDO 生成,避免不必要提交)

此 Latch 用来分配重做日志缓冲区中的空间,可以用 NOLOGGING 来减缓竞争.

* Row Cache Objects (增大共享池)

数据字典竞争.过度 parsing.

* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS 应增大或设为质数)

"过热"数据块造成了内存缓冲链 Latch 竞争.

* Cache Buffers Lru Chain (调整 SQL，设置 DB_BLOCK_LRU_LATCHES,或使用多个缓

冲区池)

扫描全部内存缓冲区块的 LRU(最近最少使用)链时要用到内存缓冲区 LRU 链 Latch.太小内

存缓冲区、过大的内存缓冲区吞吐量、过多的内存中进行的排序操作、DBWR 速度跟不上

工作负载等会引起此 Latch 竞争。

5) Enqueue 队列是一种锁，保护一些共享资源，防止并发的 DML 操作。队列采用 FIFO 策略，注意

latch 并不是采用的 FIFO 机制。比较常见的有 3 种类型的队列：ST 队列，HW 队列，TX4 队列。

ST Enqueue 的等待主要是在字典管理的表空间中进行空间管理和分配时产生的。解决方法：1）将

字典管理的表空间改为本地管理模式 2）预先分配分区或者将有问题的字典管理的表空间的 next

extent 设置大一些。

HW Enqueue 是用于 segment 的 HWM 的。当出现这种等待的时候，可以通过手工分配 extents 来

解决。

TX4 Enqueue 等待是最常见的等待情况。通常有 3 种情况会造成这种类型的等待：1）唯一索引中

的重复索引。解决方法：commit 或者 rollback 以释放队列。 2）对同一个位图索引段（bitmap index

fragment）有多个 update，因为一个 bitmap index fragment 可能包含了多个 rowid，所以当多个用

户更新时，可能一个用户会锁定该段，从而造成等待。解决方法同上。3）有多个用户同时对一个数

据块作 update，当然这些 DML 操作可能是针对这个数据块的不同的行，如果此时没有空闲的 ITL 槽，

就会产生一个 block-level 锁。解决方法：增大表的 initrans 值使创建更多的 ITL 槽；或者增大表的

pctfree 值，这样 oracle 可以根据需要在 pctfree 的空间创建更多的 ITL 槽；使用 smaller block size，

这样每个块中包含行就比较少，可以减小冲突发生的机会。

AWR 报告分析--等待事件-队列.doc

6) Free Buffer 释放缓冲区：这个等待事件表明系统正在等待内存中的可用空间，这说明当前 Buffer 中

已经没有 Free 的内存空间。如果应用设计良好，SQL 书写规范，充分绑定变量，那这种等待可能说

明 Buffer Cache 设置的偏小，你可能需要增大 DB_CACHE_SIZE。该等待也可能说明 DBWR 的写

出速度不够，或者磁盘存在严重的竞争，可以需要考虑增加检查点、使用更多的 DBWR 进程，或者

增加物理磁盘的数量,分散负载，平衡 IO。

7) Log file single write：该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号

时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。更新日志文件头这个操作在

后台完成，一般很少出现等待，无需太多关注。

8) log file parallel write：从 log buffer 写 redo 记录到 redo log 文件，主要指常规写操作(相对于 log

file sync)。如果你的 Log group 存在多个组成员，当 flush log buffer 时，写操作是并行的，这时候

此等待事件可能出现。尽管这个写操作并行处理，直到所有 I/O 操作完成该写操作才会完成(如果你

的磁盘支持异步 IO 或者使用 IO SLAVE，那么即使只有一个 redo log file member,也有可能出现此等

待)。这个参数和 log file sync 时间相比较可以用来衡量 log file 的写入成本。通常称为同步成本率。

改善这个等待的方法是将 redo logs 放到 I/O 快的盘中，尽量不使用 raid5，确保表空间不是处在热备

模式下，确保 redo log 和 data 的数据文件位于不同的磁盘中。

9) log file sync：当一个用户提交或回滚数据时，LGWR 将会话的 redo 记录从日志缓冲区填充到日志

文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到

数据库性能，那么就需要修改应用程序的提交频率, 为减少这个等待事件，须一次提交更多记录，或

者将重做日志 REDO LOG 文件访在不同的物理磁盘上，提高 I/O 的性能。

当一个用户提交或回滚数据时，LGWR 将会话期的重做由日志缓冲器写入到重做日志中。日志文件

同步过程必须等待这一过程成功完成。为了减少这种等待事件，可以尝试一次提交更多的记录(频繁的提

交会带来更多的系统开销)。将重做日志置于较快的磁盘上，或者交替使用不同物理磁盘上的重做日志，

以降低归档对 LGWR 的影响。

　　对于软 RAID，一般来说不要使用 RAID 5，RAID5 对于频繁写入得系统会带来较大的性能损失，

可以考虑使用文件系统直接输入/输出，或者使用裸设备(raw device)，这样可以获得写入的性能提高。

10) log buffer space：日志缓冲区写的速度快于 LGWR 写 REDOFILE 的速度,可以增大日志文件大小，

增加日志缓冲区的大小，或者使用更快的磁盘来写数据。

当你将日志缓冲(log buffer)产生重做日志的速度比 LGWR 的写出速度快，或者是当日志切换(log

switch)太慢时，就会发生这种等待。这个等待出现时，通常表明 redo log buffer 过小，为解决这个问题，

可以考虑增大日志文件的大小，或者增加日志缓冲器的大小。

　　另外一个可能的原因是磁盘 I/O 存在瓶颈，可以考虑使用写入速度更快的磁盘。在允许的条件下设置

可以考虑使用裸设备来存放日志文件，提高写入效率。在一般的系统中，最低的标准是，不要把日志文件

和数据文件存放在一起，因为通常日志文件只写不读，分离存放可以获得性能提升。

11) logfile switch：通常是因为归档速度不够快。表示所有的提交(commit)的请求都需要等待"日志文件

切换"的完成。Log file Switch 主要包含两个子事件:

log file switch (archiving needed) 这个等待事件出现时通常是因为日志组循环写满以后，第一个日志

归档尚未完成，出现该等待。出现该等待，可能表示 io 存在问题。解决办法:① 可以考虑增大日志文

件和增加日志组；②移动归档文件到快速磁盘；③调整 log_archive_max_processes。

log file switch (checkpoint incomplete) 当日志组都写完以后，LGWR 试图写第一个 log file，如果这

时数据库没有完成写出记录在第一个 log file 中的 dirty 块时(例如第一个检查点未完成)，该等待事件

出现。该等待事件通常表示你的 DBWR 写出速度太慢或者 IO 存在问题。为解决该问题，你可能需

要考虑增加额外的 DBWR 或者增加你的日志组或日志文件大小，或者也可以考虑增加 checkpoint 的

频率。

12) DB File Parallel Write：文件被 DBWR 并行写时发生。解决办法：改善 IO 性能。

处理此事件时，需要注意

剩余63页未读，继续阅读

疾风蜗牛

粉丝: 0
资源: 2

会员权益专享

"解读Oracle AWR报告：统计信息分析与报表生成"

评论0

会员权益专享

最新资源

"解读Oracle AWR报告：统计信息分析与报表生成"

评论0

AWR鹰眼系列AWR报告全面指标分析

AWR 报告深度解读：Time Model Statistics 信息的计算和获取

AWR详细分析

awr1642代码解读

python如何读取oracle AWR报告的html格式并获取指定内容

AWR报告 中的sql执行计划怎么找

写一段python代码能够获取ORACLE AWR报告的html格式的指定信息

oracle awr

awr中 sql出现 ** SQL Text Not Available **

Oracle AWR

WORKLOAD REPOSITORY report for 中可以看到sql的执行计划吗

DBA如何在日常维护中使用oracle awr

oracle指定时间查询表执行了哪些语句操作

awr1642学习文档

oracle根据时间查询执行次数

oracle语句追踪工具

awr1642 matlab demo

awr1642入门·

awr13.0安装问题

awr2243 时间同步

会员权益专享

最新资源

AWR报告中的sql执行计划怎么找

awr中 sql出现 SQL Text Not Available