关于等待事件"read by other session"(r3笔记第89天)

在查看数据库负载的时候,发现早上10点开始到12点的这两个钟头,系统负载异常的高。于是抓取了一个awr报告。

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

24027

18-Dec-14 10:00:43

3065

6.6

End Snap:

24033

18-Dec-14 11:00:48

3441

6.5

Elapsed:

60.08 (mins)

DB Time:

3,650.67 (mins)

可以从profile里看到,系统的IO负载还是很高的。 Load Profile

Per Second

Per Transaction

Per Exec

Per Call

DB Time(s):

60.8

1.2

0.02

0.01

DB CPU(s):

10.2

0.2

0.00

0.00

Redo size:

1,835,598.3

35,780.1

Logical reads:

1,910,437.0

37,238.9

Block changes:

4,923.1

96.0

Physical reads:

182,370.1

3,554.8

Physical writes:

1,670.7

32.6

User calls:

7,331.1

142.9

Parses:

2,128.1

41.5

Hard parses:

8.4

0.2

W/A MB processed:

48.0

0.9

Logons:

3.5

0.1

Executes:

3,911.2

76.2

Rollbacks:

1.5

0.0

Transactions:

51.3

等待事件的情况如下:

Top 5 Timed Foreground Events

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

db file sequential read

24,806,147

91,539

4

41.79

User I/O

read by other session

20,260,140

37,030

2

16.91

User I/O

DB CPU

36,766

16.79

direct path read

3,090,582

30,292

10

13.83

User I/O

log file sync

191,401

7,738

40

3.53

Commit

看完awr报告,大概能够定位是sql的问题了,直接生成了一个addm报告,作为参考。最后确认发现的几个问题sql已经在修复了,还没有部署到生产中。 今天想仔细的分析一下,毕竟很多东西都是在实践中总结出来的。 对于read by other session自己还是比较陌生的。 从metalink的描述来看。这个等待事件是在10g之后对于buffer busy waits 的一个细分。(MOS ID "Read By Other Session" Wait Event (Doc ID 732891.1)) This wait event occurs when we are trying to access a buffer in the buffer cache but we find that the buffer is currently being read from disk by another user so we need to wait for that to complete before we can access it. In previous versions, this wait was classified under the "buffer busy waits" event. However, in Oracle 10.1 and higher, the wait time is now broken out into the "read by other session" wait event.

Excessive waits for this event are typically due to several processes repeatedly reading the same blocks, e.g. many sessions scanning the same index or performing full table scans on the same table. Tuning this issue is a matter of finding and eliminating this contention.

对于这个等待事件可以结合awr和ash来进行排查。 首先我们在awr报告中已经得知这个等待事件,一般都会存在sequential read。但是通过awr不能清晰的定位出哪些sql语句和这个等待事件相关。 使用ash可以把时间段有针对性的调整在一个合理的范围。如果问题已经发生了一段时间,我们可以通过历史数据能够大体定位。 Top SQL with Top Events

SQL ID

Planhash

Sampled # of Executions

% Activity

Event

% Event

Top Row Source

% RwSrc

SQL Text

guqd44uzkyy56

3622987757

73

8.72

direct path read

6.48

TABLE ACCESS - FULL

6.48

SELECT /*+leading(CYC_CUST) p...

db file sequential read

1.30

INDEX - RANGE SCAN

0.80

a6a7y2bsmmpjb

2808023112

4

8.54

CPU + Wait for CPU

4.42

INDEX - UNIQUE SCAN

1.41

SELECT COUNT(1) FROM (/*

db file sequential read

2.28

INDEX - UNIQUE SCAN

1.74

read by other session

1.56

INDEX - UNIQUE SCAN

1.56

fg5mc598u799u

2134445868

6

7.24

db file sequential read

3.58

TABLE ACCESS - BY INDEX ROWID

2.61

select /*+ leading (bpm_ai bpm...

read by other session

2.14

TABLE ACCESS - BY INDEX ROWID

1.88

db file parallel read

1.12

TABLE ACCESS - BY INDEX ROWID

1.12

6h6dj1tnz3gwt

1565267664

35

5.03

direct path read

4.71

TABLE ACCESS - FULL

4.71

SELECT /*+parallel(CYC_PAY...

6w3p95uqduya3

561414009

71

4.27

direct path read

3.87

TABLE ACCESS - FULL

3.87

SELECT SUB.CUSTOMER_ID FROM SU...

对于read by other session,和热点块也是相关的。 我们可以使用下面的sql语句来查看一下指定时间段内的等待事件的细节。 通过ash中的Top Event P1/P2/P3 Values能够直接找到。

Event

% Event

P1 Value, P2 Value, P3 Value

% Activity

Parameter 1

Parameter 2

Parameter 3

db file sequential read

43.11

"1","3386","1"

0.04

file#

block#

blocks

direct path read

25.62

"5","756618","127"

0.07

file number

first dba

block cnt

read by other session

3.98

"46","1609148","1"

0.07

file#

block#

class#

db file scattered read

2.53

"3","116107","126"

0.04

file#

block#

blocks

db file parallel read

2.50

"2","2","2"

0.51

files

blocks

requests

或者通过如下的sql语句来看看对应的热点块。

SQL> SELECT relative_fno, owner, segment_name, segment_type FROM dba_extents
       WHERE file_id = 46
       AND 1609148 BETWEEN block_id AND block_id + blocks - 1;
RELATIVE_FNO OWNER                          SEGMENT_NAME                                                                      SEGMENT_TYPE
------------ ------------------------------ --------------------------------------------------------------------------------- ------------------
          20   APPO                            PAYMENT_DETAILS_PK                                                            INDEX PARTITION
 

a6a7y2bsmmpjb这条sql语句在文章(巧用rowid简化sql查询 http://blog.itpub.net/23718752/viewspace-1240404/)已经做了讨论。 但是不知道什么原因被遗漏了,和客户做了确认。 fg5mc598u799u这条sql语句是在产品线中统一规划的,已经使用Hint稳定了执行计划,但是涉及的几个表都是千万的大表,查询中使用了并行,同时需要在多台服务器中同时执行这条语句。这样的话,就会存在多个session执行 多个并行查询。从这个角度来说发生read by other session也是意料之中的。因为这个查询是一个分页查询,从操作上也可以做一些优化,目前是每隔10分钟做一次查询,然后查取1000条相关的数据。和业务部分协调的结果是,每隔半个小时执行一次查询,每次查取3000条数据。 可能一个等待事件中能够体现出一个表象。更多的细节还需要排查确认,很多优化工作不止能从数据库层面做,还可以从业务层面调整。 关于IO诊断的一些问题,可以参考 Troubleshooting I/O Related Waits (Doc ID 223117.1)

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-12-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

物化视图相关的性能改进 (r7笔记第58天)

今天早上开发的一个同事找到我说他早上做了一个统计查询,但是感觉速度很慢,已经过了一个小时了还没有反应。想让我看看是什么情况。 我通过v$session查到有一个...

34150
来自专栏杨建荣的学习笔记

生产环境sql语句调优实战第六篇(r2笔记91天)

生产环境中有大量的sql语句在运行,尽管有awr,ash做数据的收集统计,但是dba的调优工作大多数情况都是在问题已经发生后做排查的,有些sql语句可能执行的时...

28040
来自专栏数据和云

极限优化:从75到2000,由技能到性能提升岂止80倍

崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 编辑手记:感谢崔华授权我们独家转载其精品文章,也欢迎大家向“Oracl...

28950
来自专栏杨建荣的学习笔记

关于drop user的cascade选项解惑(52天)

在数据库中,有时候需要删除用户,大多数时候都需要使用cascade选项,有些时候却不需要,想知道在这个简单的命令之后数据库倒底在干什么, 这时候给一些指定的操作...

39980
来自专栏杨建荣的学习笔记

生产环境sql语句调优实战第七篇(r2笔记99天)

在数据迁移完成之后,开始了例行的后期数据库维护,早上一来就发现了一个sql执行时间很长了。达到了37279秒。最后在改进调优之后执行速度在1分钟以内。 这个速度...

35880
来自专栏乐沙弥的世界

高水位线和全表扫描

   高水位线好比水库中储水的水位线,用于描述数据库中段的扩展方式。高水位线对全表扫描方式有着至关重要的影响。当使用delete 操作 表记录时,高水位线并不...

8620
来自专栏数据和云

追本溯源:Oracle 只读表空间的探索实践

作者简介 ? 胡中豪 云和恩墨西区交付工程师,多年一线 DBA 经验,曾服务于运营商、电网、政府行业、银行等行业客户;擅长数据库故障处理、性能优化、实施升级 本...

29530
来自专栏杨建荣的学习笔记

一个普通数据库用户所能查到的"意料之外"的信息(r2笔记98天)

有时候限于工作环境的情况,大多数开发人员只得到了一个权限收到限制的数据库用户。 可能你都不知道你所拥有的数据库用户都能查到哪些你想象不到的数据库信息,其实你知道...

34880
来自专栏数据库新发现

如何使用USE_CONCAT提示

USE_CONCAT提示强迫优化器扩展查询中的每一个OR谓词为独立的查询块. 最后合并所有查询块的结果,返回结果集给用户。

13820
来自专栏杨建荣的学习笔记

海量数据迁移之外部表并行抽取(99天)

在10g开始的新特性中,外部表是一个不容忽视的好工具。对于大型项目中海量数据使用sqlloader是一种全新的方式,不过很明显,sqlloader的可扩展性更强...

38150

扫码关注云+社区

领取腾讯云代金券