iniestandroid 发表于 2014-6-20 16:08:00

关于“db file sequential read”

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



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



Maclean Liu(刘相兵 发表于 2014-6-20 16:12:21

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

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




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

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

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

ML，AWR已经传上来了。

Maclean Liu(刘相兵 发表于 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        的值是一样的，但最后的结果是 让你看到的现象天差地别

iniestandroid 发表于 2014-6-20 16:39:04

Maclean Liu(刘相兵 发表于 2014-6-20 16:18 static/image/common/back.gif
这个问题 我不细看了， 看了AWR开头 我认为大致知道什么情况了

你的生产


谢谢ML..
刚没说清楚，这两个AWR是生产库不同时段的，不大明白AMM管理内存时，为什么Buffer Cache会有这么大的变化？？

Maclean Liu(刘相兵 发表于 2014-6-21 16:41:09

iniestandroid 发表于 2014-6-20 16:39 static/image/common/back.gif
谢谢ML..
刚没说清楚，这两个AWR是生产库不同时段的，不大明白AMM管理内存时，为什么Buffer Cache会有这 ...

实际就是AMM 就是有这么大的主观能动性。

iniestandroid 发表于 2014-6-24 10:22:15

谢谢ML,确实就是这个问题造成的，AMM将memory_target的大部分都分给了PGA,后来手动设置了sga_target参数后问题得到解决！
页: [1]
查看完整版本: 关于“db file sequential read”