db file async I/O submit+enq: KO - fast object checkpoint 等待事件

zengmuansha

今天 看了下 ＩＯ　这个%ＵＴＩＬ　一直处于高位运行.　
ＩＯ负载也很高.　有５个大表基本上都是全表扫描的.
[oracle@vps ~]iostat -d -x sda -m 5 10
Linux 2.6.32.12-0.7-pae (vps)   05/20/2014      _i686_

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               1.76   138.77   46.28   28.70     0.03     0.01     0.96     0.12    1.62   0.21   1.55

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               7.00     6.80  481.20    9.60    79.80     0.05   333.19     5.25   10.67   1.93  94.72

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               8.80     9.60  692.40    9.80   145.48     0.06   424.46     3.98    5.69   1.38  97.20

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               6.00    18.40  446.00   24.60   117.70     0.13   512.76     2.66    5.63   1.74  81.92

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               3.20    18.80  437.00   30.40    52.96     0.14   232.65     2.63    5.66   1.35  62.96

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    14.00   74.40   22.00     1.33     0.10    30.46     0.49    5.09   2.49  24.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               8.40    10.00   22.80   15.20     0.41     0.07    26.19     0.17    4.61   3.89  14.80

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               4.60    14.60  105.40   18.20     3.39     0.10    57.75     1.27   10.27   2.03  25.12

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda              12.00    23.60  337.60   40.20     6.03     0.17    33.63     2.11    5.60   1.34  50.64

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               6.80     7.60   25.20    9.20     0.63     0.05    40.60     0.19    5.56   3.93  13.52

zengmuansha

SQL> show sga

Total System Global Area 2494251008 bytes
Fixed Size                  1338280 bytes
Variable Size            1526727768 bytes
Database Buffers          956301312 bytes
Redo Buffers                9883648 bytes
SQL> select 956301312/1024/1023 as size_mb from  dual;

  SIZE_MB Database Buffers
----------
912.891496

SQL> select 2494251008/1024/1024 as size_mb from dual;

   SIZE_MB Total System Global Area
----------
2378.70313

SQL> select 9883648/1024/1024 as size_mb from dual;

   SIZE_MB Redo Buffers
----------
9.42578125

SQL> select 1526727768/1024/1024 as size_mb from dual;

   SIZE_MB Variable Size
----------
1456.00106

zengmuansha

ＡＷＲ　报表中
Segments by Direct Physical Reads
Object Name        Subobject Name        Obj. Type　        Direct Reads        %Total
CCPS_TRADERECORD                 　　　　TABLE        　　67,666,000        91.15

IOStat by Function summary
Function Name              Reads: Data
Direct Reads                     565.2G
Buffer Cache Reads    146G
DBWR                          Writes: Data  3.1G

这样看还是直接路径读了很多 导致DBWR写得慢

Yong Huang

> 我一直认为32位系统上运行的oracle有1.7g的内存限制，难道这个限制只是在windows上有？

If I remember right, 32-bit Windows allows 2G for user space in a process by default (i.e. you don't mess with PAE stuff in c:\boot.ini or equivalent). Linux allows 3G by default. That is, Windows allows the other 2G for kernel space and Linux allows 1G for kernel.

But as I said, nowadays most shops use 64-bit OS. That knowledge is mostly of historical interest only.

zengmuansha's problem is simply short of memory. The system memory is low, and SGA is not even half of that. And worse, buffer cache is squeezed by shared pool to yet another lower-than-half of SGA (a common problem with ASMM or AMM, usually due to unshared SQL statements). With so little buffer cache, Oracle strongly prefers direct path read bypassing buffer cache.

zergduan

Yong Huang 发表于 2014-5-21 00:35
> 我一直认为32位系统上运行的oracle有1.7g的内存限制，难道这个限制只是在windows上有？

If I remember ...

谢谢。的确，11g是否使用直接路径读来做全表扫描，是看表是否超过一定的大小，而阈值是一个固定的系数*db_cache_size.提高sga会提高db_cache_size，会减少直接路径读的全表扫描。

zergduan

但是，全表扫描真的是必要的么，楼主可以看看全表扫描的sql，应该有办法改变访问路径，消除全表扫描

zengmuansha

zergduan 发表于 2014-5-24 20:25
但是，全表扫描真的是必要的么，楼主可以看看全表扫描的sql，应该有办法改变访问路径，消除全表扫描

很多没有必要的全扫描! 我找出了180个,自己还优化了7个! 送给JAVA开发人员. 人家不鸟.连那个大表做分区,也不鸟了之了!

Yong Huang

> 的确，11g是否使用直接路径读来做全表扫描，是看表是否超过一定的大小，而阈值是一个固定的系数*db_cache_size.
> 提高sga会提高db_cache_size，会减少直接路径读的全表扫描。

According to
http://blog.tanelpoder.com/2012/ ... _statistics_driven/
11.2.0.2 and up also checks table/index statistics for direct path read decisions, controlled by _direct_read_decision_statistics_driven.

zergduan

Yong Huang 发表于 2014-5-27 22:56
> 的确，11g是否使用直接路径读来做全表扫描，是看表是否超过一定的大小，而阈值是一个固定的系数*db_cache ...

Thx，长知识