DB buffer bussy wait 分析一例

 ####sample 1:

DB层分析OI

DB层分析OI的信息如下:

1. 异常时间段,  Logical reads:/ Physical reads/ Physical write  指标都低于正常时间段。说明数据库本身消耗i/o 并不高。但是nmon显示disk 读写非常高,

同时现场分析, I/O 资源消耗最大可达40M-70M/s,任务可以顺利完成。同时注意到

通过topas 来看,在一些时候,hdisk 在 tps和kbps 为0的情况下,磁盘繁忙程度达到99%,所以建议如下:

是这个现在已有的信息能够看到的一些问题,还需要OS层面给一些东西,需要OS介入帮助看看底层是否有什么问题。请主机组检查存储

2. 等待事件buffer busy waits  占首位,消耗了很多资源,主要是sql  2mwvn9xwq1tz3 消耗。建议检查sql

检查这个sql 执行计划2mwvn9xwq1tz3

Elapsed Time (s)

Executions

Elapsed Time per Exec (s)

%Total

%CPU

%IO

SQL Id

SQL Module

SQL Text

80,962.92

24,804

3.26

33.97

0.00

0.00

2mwvn9xwq1tz3

e:IEU:cp:IEU_WL_CS

select (RUNNING_PROCESSES-MAX_...

                                                   分析sql 结果:

 

Sql 执行计划没有变化。主要消耗在buffer busy wait ,说明当时缓存区争用,怀疑跟系统I/O 处理不过来,导致缓存存在问题。

SQL_ID 2mwvn9xwq1tz3

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

select (RUNNING_PROCESSES-MAX_PROCESSES) ,MAX_PROCESSES 

,NVL(SLEEP_SECONDS,0) ,DIAGNOSTIC_LEVEL into :b0,:b1,:b2,:b3:b4  from 

FND_CONCURRENT_QUEUES where ((DBLICATION_ID=:b5 and 

CONCURRENT_QUEUE_ID=:b6) and (TARGET_NODE=:b7 or (TARGET_NODE is null  

and :b7 is null )))

Plan hash value: 356935968

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

| Id  | Operation                   | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT            |                          |       |       |     1 (100)|          |

|   1 |  TABLE ACCESS BY INDEX ROWID| FND_CONCURRENT_QUEUES    |     1 |    22 |     1   (0)| 00:00:01 |

|   2 |   INDEX UNIQUE SCAN         | FND_CONCURRENT_QUEUES_U1 |     1 |       |     0   (0)|          |

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

详细分析如下:

-》 1 。正常时间段:等待事件正常, Logical reads:/ Physical reads/ Physical write  指标都高于 异常时间段。

 

 


Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

36769

12-6月 -17 20:00:52

216

10.5

End Snap:

36773

13-6月 -17 00:00:22

229

9.3

Elapsed:

239.51 (mins)

DB Time:

1,570.72 (mins)

Top 5 Timed Foreground Events

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

db file sequential read

5,750,530

23,950

4

25.41

User I/O

log buffer space

72,789

15,988

220

16.96

Configuration

DB CPU

 

10,941

 

11.61

SQL*Net message from dblink

61,789

7,296

118

7.74

Network

direct path read

385,065

6,336

16

6.72

User I/O

Segments by Buffer Busy Waits

% of Capture shows % of Buffer Busy Waits for each top segment compared

with total Buffer Busy Waits for all segments captured by the Snapshot

Owner

Tablespace Name

Object Name

Subobject Name

Obj. Type

Buffer Busy Waits

% of Capture

MSC

DBS_TS_INTERFACE

MSC_ST_SYSTEM_ITEMS

SYSTEM_ITEMS_3021

TABLE PARTITION

13,842

45.12

DATALOAD

TS_DATA_LOAD

ZTE_ERP_WIP_DETAIL

TABLE

6,058

19.75

DBLSYS

DBS_TS_TX_DATA

FND_CONCURRENT_QUEUES

TABLE

5,119

16.69

Load Profile

 

Per Second

Per Transaction

Per Exec

Per Call

DB Time(s):

6.6

0.5

0.00

0.11

DB CPU(s):

0.8

0.1

0.00

0.01

Redo size:

6,145,675.1

497,949.9

Logical reads:

223,510.5

18,109.8

Block changes:

20,265.5

1,642.0

Physical reads:

2,507.0

203.1

Physical writes:

3,069.3

248.7

User calls:

60.5

4.9

Parses:

3.3

0.3

Hard parses:

0.9

0.1

W/A MB processed:

3.7

0.3

Logons:

0.2

0.0

Executes:

2,988.9

242.2

Rollbacks:

0.3

0.0

Transactions:

12.3

 

-》 2 .异常时间段。等待事件buffer busy waits  占首位,消耗了很多资源,主要是sql  2mwvn9xwq1tz3 消耗。

       Logical reads:/ Physical reads/ Physical write  指标都低于正常时间段。说明数据库本身消耗i/o 并不高。,


Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

36817

14-Jun-17 20:00:02

228

12.8

End Snap:

36821

15-Jun-17 00:00:21

235

10.9

Elapsed:

240.31 (mins)

DB Time:

6,207.36 (mins)

Buffer Cache:

29,184M

29,184M

Std Block Size:

8K

Shared Pool Size:

10,240M

10,240M

Log Buffer:

72,708K

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

buffer busy waits

78,775

207,914

2639

55.82

Concurrency

Segments by Buffer Busy Waits

  • % of Capture shows % of Buffer Busy Waits for each top segment compared
  • with total Buffer Busy Waits for all segments captured by the Snapshot

Owner

Tablespace Name

Object Name

Subobject Name

Obj. Type

Buffer Busy Waits

% of Capture

DBLSYS

DBS_TS_TX_DATA

FND_CONCURRENT_QUEUES

TABLE

90,802

72.49

2mwvn9xwq1tz3

select (RUNNING_PROCESSES-MAX_PROCESSES) , MAX_PROCESSES , NVL(SLEEP_SECONDS, 0) , DIAGNOSTIC_LEVEL into :b0, :b1, :b2, :b3:b4 from FND_CONCURRENT_QUEUES where ((DBLICATION_ID=:b5 and CONCURRENT_QUEUE_ID=:b6) and (TARGET_NODE=:b7 or (TARGET_NODE is null and :b7 is null )))

Load Profile

 

Per Second

Per Transaction

Per Exec

Per Call

DB Time(s):

20.0

1.7

0.06

0.15

DB CPU(s):

0.2

0.0

0.00

0.00

Redo size:

1,836,990.9

154,577.6

Logical reads:

35,973.5

3,027.1

Block changes:

5,531.3

465.4

Physical reads:

343.4

28.9

Physical writes:

550.6

46.3

User calls:

132.6

11.2

Parses:

3.0

0.3

Hard parses:

0.8

0.1

W/A MB processed:

2.6

0.2

Logons:

0.1

0.0

Executes:

332.7

28.0

Rollbacks:

0.5

0.0

Transactions:

11.9

 

è  3. 检查这个sql 执行计划2mwvn9xwq1tz3

6.11没问题:

6.14有问题:

PS:

事件参数说明:

事件号:145
事件名:buffer busy waits
参数一:file#
参数二:block#
参数三:9i -原因码,10g - block class#


事件说明:
一、ORACLE会话正在等待PIN住一个缓冲区,会话必须在读取或修改缓冲区之前将该缓冲区PIN住。
二、在任何时侯只有一个进程可以PIN住一个缓冲区。
三、buffer busy waits表明读/读、读/写、写/写争用。
四、根据P3中指明的原因码有不同的处理方式。
五、现象描述:

会话在SGA中读取或修改缓冲区之前,必须要先获取cahce buffers chains锁存器,获取后然后遍历这个缓冲区链,直到发现它需要的缓冲区头。然后以共享方式或独占方式获取该缓冲区锁或缓冲区头部的PIN,一旦缓冲区被PIN住,会话即释放cache buffers chains锁存器。如果无法获得PIN,会话就在buffer busy waits等待事件上等待。

六、该事件只与SGA中缓冲区相关,与会话私有的PGA中执行的读/写操作无关。
七、处理该等待事件时主要注意以下四方面:

1) 该等待事件主要的原因码是什么?(参数P3)
2) buffer busy waits事件需要的块类?(由P1即可找出等待块的类列)
3) 缓冲区所属的段(由P1和P2参数配合视图v$extents即可找出等待块的所属段)
select s.segment_name, s.partition_name 
  from dba_extents s 
 where <P2的值> between s.block_id and (s.block_id + s.blocks -1) and s.file_id = <P1的值>

八、虽然buffer busy waits事件的发生可能至少有十个不同的原因,但是代码130和220是最常见的原因。基本上,小于200的代码号意味着这种等待是和I/O有关的。

 

带有原因码130的数据块(类#1)争用

1) 等待集中在数据块上,并且原因码是130,则意味着多个会话并发请求相同的数据块,但该数据块并不在缓冲存储器中,并且必须从磁盘读取。
2) 当多个会话请求不在缓冲存储器中的相同数据块时,ORACLE可以聪明地防止每个会话进行相同的操作系统I/O调用。否则,这可能严重地增加系统I/O的数量,所以,ORACLE只允许一个会话执行实际的I/O,而其他的会话在buffer busy waits上等待块,执行I/O的会话在db file sequential read或db file scattered read等待事件上等待。
3) 可在v$session视图中检查SESSION的注册时间,并且等待事件db file sequential(scattered) read和buffer busy waits等待相同的文件号和块号。
4) 解决方法:优化SQL语句,尽可能地减少逻辑读和物理读;

带有原因码220的数据块(类#1)争用

1) 等待集中在数据块上,并且原因码是220,则意味着多个会话同时在相同的对象上执行DML(相同块中的不同行)。
2) 如果数据块的尺寸较大(>=16K),则可能强化这种现象,因为较大的块一般在每个块中包含更多的行。
3) 减少这种情况的等待的方法:减少并发;减少块中行的数量;在另一个具有较小块尺寸的表空间中重新构建对象。
4) 具体方法说明:
使用较大的PCTFREE重新构建表或索引;
使用alter table <table_name> minimize records_pre_block命令改变表以最小化每个块的最小行数
从ORACLE9i开始,可以在另一个具有较小块尺寸的表空间中移动或重新构建对象。
注:虽然这些方法可以最小化buffer busy waits问题,但它们无疑会增加全表扫描时间和磁盘空间利用率。

数据段头(类#4)的争用

1) 如果buffer busy waits的等待事件主要集中在数据段头(即表或索引段头,并且不是UNDO段头)上,这意味着数据库中一些表或索引有高段头活动。
注:进程出于两个主要原因访问段头,一是,获得或修改FREELISTS信息;二是,为了扩展高水位标记(HWM)。
2) 减少这种情况的等待的方法:
>> 对使用自由表进行段管理的表,增加确认对象的FREELISTS和FREELIST GROUPS(注:FREELIST GROUPS的增加也是必须的);
>> 确保FCTFREE和PCTUSED之间的间隙不是太小,从而可以最小化FREELIST的块循环。
>> 下一区的尺寸不能太小,当区高速扩张时,建立的新区需要修改在段头中区映射表。可以考虑将对象移动到合理的、统一尺寸的本地管理的表空间中。

撤销段头(类#17)的争用

1) 如果buffer busy waits等待事件主要集中在撤销段头,这表明数据库中的回滚段过少或者是它们的区尺寸太小,从而造成对段头的频繁更新。如果使用ORACLE9I的由数据库系统管理UNDO段,就不需要处理这种问题,因为ORACLE会根据需要增加额外的的UNDO段。
2) 可以创建并启用私有回滚段,以减少每个回滚段的事务数量。需要修改init.ora文件中的ROLLBACK_SEGMENTS参数。
3) 如果使用公用回滚段可以减少初始化参数transactions_per_rollback_segment的值,ORACLE通过transactions/transactions_per_rollback_segment来获取公有回滚段的最小数量。


撤销块的争用(类#18)

1) 如果buffer busy waits等待事件主要集中在撤销块上,这表明有多个并发会话为保证一致性读同时查询更新的数据。
2) 这是应用程序存在问题,当应用程序在不同时间内运行查询和DML时,这种问题不会存在。


附注:
一、查看系统所有段的有关buffer busy waits事件的统计:
SELECT *
  FROM v$segment_statistics s
 WHERE s.statistic_name = 'buffer busy waits'
   AND s.owner <> 'SYS'

 

######sampe 2:

free buffer waits

1. 10046 debug show one sqll normal run 1S, issue time run 10s.

0:42:35 SQL> oradebug setmypid
Statement processed.

10:44:02 SQL> oradebug event 10046 trace name context forever,level 12;
Statement processed.
10:44:19 SQL> /

TABLESPACE_NAME maxbyes_GB
------------------------------------------------------------ ----------
bytes_GB free_GB use_GB use_% maxuse_%
---------- ---------- ---------- ---------- ----------


USERS 31.9999847
.48828125 .450134277 .038146973 7.81 .12


12 rows selected.

10:44:34 SQL> oradebug event 10046 trace name context off

10:45:08 SQL> oradebug tracefile_name


2.sql  show 10s consume in fetch time,  and more check show wait evnet " free buffer waits " consume 10s. it it the cause.


SELECT a.tablespace_name ,b.maxbytes/1024/1024/1024 "maxbyes_GB",total/1024/1024/1024 "bytes_GB",free/1024/1024/1024 "free_GB",(total-free) /1024/1024/1024 "use_GB",
ROUND((total-free)/total,4)*100 "use_%",ROUND((total-free)/b.maxbytes,4)*100 "maxuse_%"
FROM
(SELECT tablespace_name,SUM(bytes) free FROM DBA_FREE_SPACE
GROUP BY tablespace_name
) a,
(SELECT tablespace_name,sum(case autoextensible when 'YES' then maxbytes else bytes end) maxbytes,SUM(bytes) total FROM DBA_DATA_FILES
GROUP BY tablespace_name
) b
WHERE a.tablespace_name=b.tablespace_name
order by "maxuse_%" desc

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.11 1 4 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.46 10.86 7051 10244 360 12                                                                    < fetch is use 10 s, but cpu only have 0.3s, IO is small 7052 , the more is in wait evnet.
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.48 10.98 7052 10248 360 12

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
12 12 12 SORT ORDER BY (cr=20469 pr=7052 pw=0 time=11032670 us cost=69 size=122 card=2)
12 12 12 HASH JOIN (cr=20469 pr=7052 pw=0 time=11032536 us cost=68 size=122 card=2)
12 12 12 VIEW (cr=156 pr=0 pw=0 time=11691 us cost=5 size=74 card=2)
12 12 12 HASH GROUP BY (cr=156 pr=0 pw=0 time=11678 us cost=5 size=80 card=2)
36 36 36 VIEW DBA_DATA_FILES (cr=156 pr=0 pw=0 time=13109 us cost=4 size=80 card=2)
36 36 36 UNION-ALL (cr=156 pr=0 pw=0 time=13108 us)
0 0 0 NESTED LOOPS (cr=40 pr=0 pw=0 time=2305 us cost=2 size=369 card=1)
0 0 0 NESTED LOOPS (cr=40 pr=0 pw=0 time=2304 us cost=1 size=351 card=1)
0 0 0 NESTED LOOPS (cr=40 pr=0 pw=0 time=2302 us cost=1 size=338 card=1)
36 36 36 FIXED TABLE FULL X$KCCFN (cr=0 pr=0 pw=0 time=575 us cost=0 size=310 card=1)
0 0 0 TABLE ACCESS BY INDEX ROWID FILE$ (cr=40 pr=0 pw=0 time=210 us cost=1 size=28 card=1)
36 36 36 INDEX UNIQUE SCAN I_FILE1 (cr=4 pr=0 pw=0 time=85 us cost=0 size=0 card=1)(object id 43)
0 0 0 FIXED TABLE FIXED INDEX X$KCCFE (ind:1) (cr=0 pr=0 pw=0 time=0 us cost=0 size=39 card=3)
0 0 0 TABLE ACCESS CLUSTER TS$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
0 0 0 INDEX UNIQUE SCAN I_TS# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 7)
36 36 36 NESTED LOOPS (cr=116 pr=0 pw=0 time=10680 us cost=2 size=429 card=1)
36 36 36 NESTED LOOPS (cr=76 pr=0 pw=0 time=9250 us cost=1 size=411 card=1)
36 36 36 NESTED LOOPS (cr=76 pr=0 pw=0 time=1950 us cost=1 size=398 card=1)
36 36 36 NESTED LOOPS (cr=36 pr=0 pw=0 time=1306 us cost=0 size=388 card=1)
36 36 36 FIXED TABLE FULL X$KCCFN (cr=0 pr=0 pw=0 time=366 us cost=0 size=310 card=1)
36 36 36 FIXED TABLE FIXED INDEX X$KTFBHC (ind:1) (cr=36 pr=0 pw=0 time=609 us cost=0 size=78 card=1)
36 36 36 TABLE ACCESS BY INDEX ROWID FILE$ (cr=40 pr=0 pw=0 time=326 us cost=1 size=10 card=1)
36 36 36 INDEX UNIQUE SCAN I_FILE1 (cr=4 pr=0 pw=0 time=121 us cost=0 size=0 card=1)(object id 43)
36 36 36 FIXED TABLE FIXED INDEX X$KCCFE (ind:1) (cr=0 pr=0 pw=0 time=5605 us cost=0 size=39 card=3)
36 36 36 TABLE ACCESS CLUSTER TS$ (cr=40 pr=0 pw=0 time=516 us cost=1 size=18 card=1)
36 36 36 INDEX UNIQUE SCAN I_TS# (cr=4 pr=0 pw=0 time=189 us cost=0 size=0 card=1)(object id 7)
12 12 12 VIEW (cr=20313 pr=7052 pw=0 time=11019748 us cost=62 size=240 card=10)
12 12 12 HASH GROUP BY (cr=20313 pr=7052 pw=0 time=11019746 us cost=62 size=240 card=10)
3034 3034 3034 VIEW DBA_FREE_SPACE (cr=20313 pr=7052 pw=0 time=34905 us cost=61 size=106560 card=4440)
3034 3034 3034 UNION-ALL (cr=20313 pr=7052 pw=0 time=33767 us)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=93 us cost=3 size=67 card=1)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=91 us cost=3 size=61 card=1)
0 0 0 TABLE ACCESS FULL FET$ (cr=22 pr=0 pw=0 time=90 us cost=3 size=39 card=1)
0 0 0 TABLE ACCESS CLUSTER TS$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=22 card=1)
0 0 0 INDEX UNIQUE SCAN I_TS# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 7)
0 0 0 INDEX UNIQUE SCAN I_FILE2 (cr=0 pr=0 pw=0 time=0 us cost=0 size=6 card=1)(object id 44)
3003 3003 3003 NESTED LOOPS (cr=26 pr=0 pw=0 time=31573 us cost=7 size=3796 card=52)
3003 3003 3003 NESTED LOOPS (cr=22 pr=0 pw=0 time=26185 us cost=7 size=3484 card=52)
12 12 12 TABLE ACCESS FULL TS$ (cr=22 pr=0 pw=0 time=147 us cost=7 size=280 card=10)
3003 3003 3003 FIXED TABLE FIXED INDEX X$KTFBFE (ind:1) (cr=0 pr=0 pw=0 time=50358 us cost=0 size=195 card=5)
3003 3003 3003 INDEX UNIQUE SCAN I_FILE2 (cr=4 pr=0 pw=0 time=2250 us cost=0 size=6 card=1)(object id 44)
31 31 31 NESTED LOOPS (cr=20243 pr=7052 pw=0 time=9059909 us cost=36 size=473688 card=4386)
31 31 31 HASH JOIN (cr=20239 pr=7052 pw=0 time=9059463 us cost=36 size=1678716 card=16458)
312 312 312 HASH JOIN (cr=52 pr=0 pw=0 time=1131 us cost=16 size=14615 card=395)
12 12 12 TABLE ACCESS FULL TS$ (cr=22 pr=0 pw=0 time=96 us cost=7 size=280 card=10)
312 312 312 TABLE ACCESS FULL RECYCLEBIN$ (cr=30 pr=0 pw=0 time=123 us cost=9 size=3582 card=398)
92383 92383 92383 FIXED TABLE FULL X$KTFBUE (cr=20187 pr=7052 pw=0 time=6617310 us cost=19 size=6500000 card=100000)
31 31 31 INDEX UNIQUE SCAN I_FILE2 (cr=4 pr=0 pw=0 time=81 us cost=0 size=6 card=1)(object id 44)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=104 us cost=15 size=89 card=1)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=100 us cost=15 size=89 card=133)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=99 us cost=10 size=80 card=1)
0 0 0 NESTED LOOPS (cr=22 pr=0 pw=0 time=96 us cost=10 size=74 card=1)
0 0 0 TABLE ACCESS FULL TS$ (cr=22 pr=0 pw=0 time=95 us cost=7 size=66 card=3)
0 0 0 TABLE ACCESS CLUSTER UET$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=52 card=1)
0 0 0 INDEX RANGE SCAN I_FILE#_BLOCK# (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 9)
0 0 0 INDEX UNIQUE SCAN I_FILE2 (cr=0 pr=0 pw=0 time=0 us cost=0 size=6 card=1)(object id 44)
0 0 0 INDEX RANGE SCAN RECYCLEBIN$_TS (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=133)(object id 144)
0 0 0 TABLE ACCESS BY INDEX ROWID RECYCLEBIN$ (cr=0 pr=0 pw=0 time=0 us cost=5 size=9 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
control file sequential read 157 0.00 0.00
db file sequential read 7052 0.00 0.12
free buffer waits 889 0.01 9.98                                                                 <- more time is in that event .
SQL*Net message from client 2 34.45 34.45
********************************************************************************


3.AWR wait event : (one hour awr show )

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tota Wait % DB
Event Waits Time Avg(ms) time Wait Class
------------------------------ ------------ ---- ------- ------ ----------
free buffer waits 225,109 5009 22 67.9 Configurat
enq: TX - row lock contention 1 2388 2.4E+06 32.4 Applicatio

IOStat by Function summary DB/Inst: PISA/pisa Snaps: 30584-30585
-> 'Data' columns suffixed with M,G,T,P are in multiples of 1024
other columns suffixed with K,M,G,T,P are in multiples of 1000
-> ordered by (Data Read + Write) desc

Reads: Reqs Data Writes: Reqs Data Waits: Avg
Function Name Data per sec per sec Data per sec per sec Count Tm(ms)
--------------- ------- ------- ------- ------- ------- ------- ------- -------
Buffer Cache Re 42.2G 730.4 11.954M 0M 0.0 0M 2642.4K 0.2
DBWR 0M 0.0 0M 27.8G 775.3 7.855M 1930 1489.2 <-dbwr avg is more high avg is 14*9ms
Others 11.3G 13.0 3.205M 10.8G 4.2 3.061M 62.2K 4.0
LGWR 50M 0.9 .014M 10.9G 5.4 3.096M 26.5K 16.5
Direct Writes 0M 0.0 0M 0M 0.0 0M 5 0.0
Streams AQ 0M 0.0 0M 0M 0.0 0M 13 7.2
TOTAL: 53.6G 744.3 15.172M 49.5G 784.9 14.012M 2733.1K 1.5
------------------------------------------------------

Tablespace IO Stats DB/Inst: PISA/pisa Snaps: 30584-30585
-> ordered by IOs (Reads + Writes) desc

Tablespace
------------------------------
Av Av Av 1-bk Av 1-bk Writes Buffer Av Buf
Reads Rds/s Rd(ms) Blks/Rd Rds/s Rd(ms) Writes avg/s Waits Wt(ms)
------- ------- ------- ------- ------- ------- ------- ------- -------- -------
TS_db_DATA
1.4E+06 375 0.4 3.1 2.5E+06 364.9 0 703 2,747 0.3
SYSAUX
5.9E+05 164 0.0 1.1 580 161.8 0 0 1,800 0.2
UNDOTBS1
1.3E+05 36 0.1 1.0 4.0E+05 35.6 0 110 2,135 20.7 <-avg buf wat is 20.7

---workaourd:

change 

db_writer_processes integer
1

 to 

10

原文地址:https://www.cnblogs.com/feiyun8616/p/7041000.html