0 积分	1 好友	7 主题

发消息

[RAC Clusterware] 关于“db file sequential read”

1^#

发表于 2014-6-20 16:08:00 | 查看: 4124| 回复: 7

Solaris 10 SPARC
11.2.0.1

生产库突然有一个很简单的SQL执行很慢：

正常情况下的执行时间：

SQL文本：

SELECT MAX(T1.RQ)
  FROM ADB_ZW_ZHTGYE T1
WHERE T1.ZQDM = '040801'
AND T1.KMDM LIKE '03%'
AND T1.KMDM <> '0300'

该表大概2亿条记录，按照RQ进行RANGE分区，有一个复合索引  INDxx（col1,col2,ZQDM,KMDM），手动执行该SQL，跑了900s左右，做了10046发现执行计划没有改变：

Rows    Row Source Operation
-------  ---------------------------------------------------
   1  SORT AGGREGATE (cr=919274 pr=919274 pw=0 time=0 us)
      1 FIRST ROW  (cr=919274 pr=919274 pw=0 time=0 us cost=1186 size=21 card=1)
      1 PARTITION RANGE ALL PARTITION: 38 1 (cr=919274 pr=919274 pw=0 time=0 us cost=1186 size=21 card=1)
         1    INDEX FULL SCAN (MIN/MAX) IDX_ADB_ZW_ZHTGYE PARTITION: 38 1 (cr=919274 pr=919274 pw=0 time=0 us cost=1186 size=21 card=1)(object id 98509)

但是有大量的“db file sequential read”等待事件

在ADG备库执行这个SQL 40s左右，10046里唯一不同的是
生产:
==========
call    count    cpu elapsed    disk    query current       rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       1    0.01    0.00       0       0       0          0
Execute    1    0.00    0.00       0       0       0          0
Fetch       1 102.58    924.93 919274    919274       0          1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       3 102.59    924.93    919274    919274       0          1

ADG:
==========
call    count    cpu elapsed    disk    query current       rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       1    0.00    0.00       0       0       0          0
Execute    1    0.00    0.00       0       0       0          0
Fetch       1    46.67    46.67       0    931866       0          1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       3    46.67    46.67       0    931866       0          1

看起来似乎是物理读造成的，大神儿们帮看看呗。。

10046-primary.txt (8.21 KB, 下载次数: 981)

10046-standby.txt (11.1 KB, 下载次数: 1003)

分享0

收藏0 回复只看该作者道具举报

Maclean Liu(刘相兵

2^#

发表于 2014-6-20 16:12:21

需要2侧当时完整AWR做对比

回复只看该作者道具举报

iniestandroid

3^#

发表于 2014-6-20 16:14:28

ads_20140618.html (911.47 KB, 下载次数: 969)

ads_20140620.html (847.7 KB, 下载次数: 934)

业务正常和出现问题时的AWR对比

回复只看该作者道具举报

iniestandroid

4^#

发表于 2014-6-20 16:15:12

Maclean Liu(刘相兵发表于 2014-6-20 16:12
需要2侧当时完整AWR做对比

ML，AWR已经传上来了。

回复只看该作者道具举报

Maclean Liu(刘相兵

5^#

发表于 2014-6-20 16:18:29

这个问题我不细看了，看了AWR开头我认为大致知道什么情况了

你的生产

Begin End
Buffer Cache:    5,632M    5,632M Std Block Size:    8K
Shared Pool Size:    9,984M    9,984M Log Buffer:    130,040K

memory_target 96368328704

你的ADG
Begin End
Buffer Cache:    22,016M    13,568M Std Block Size:    8K
Shared Pool Size:    9,984M    9,984M Log Buffer:    130,040K

memory_target 96368328704

虽然 memory_target 的值是一样的，但最后的结果是让你看到的现象天差地别

回复只看该作者道具举报