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 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 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:
事件参数说明：
事件名：buffer busy waits
参数一：file#
参数二：block#
参数三：9i -原因码，10g - block class#
事件说明：
一、ORACLE会话正在等待PIN住一个缓冲区，会话必须在读取或修改缓冲区之前将该缓冲区PIN住。
二、在任何时侯只有一个进程可以PIN住一个缓冲区。
三、buffer busy waits表明读/读、读/写、写/写争用。
四、根据P3中指明的原因码有不同的处理方式。
五、现象描述：
六、该事件只与SGA中缓冲区相关，与会话私有的PGA中执行的读/写操作无关。
七、处理该等待事件时主要注意以下四方面：
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)争用
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)争用
2) 如果数据块的尺寸较大(>=16K)，则可能强化这种现象，因为较大的块一般在每个块中包含更多的行。
3) 减少这种情况的等待的方法：减少并发；减少块中行的数量；在另一个具有较小块尺寸的表空间中重新构建对象。
4) 具体方法说明：
使用较大的PCTFREE重新构建表或索引；
使用alter table <table_name> minimize records_pre_block命令改变表以最小化每个块的最小行数
从ORACLE9i开始，可以在另一个具有较小块尺寸的表空间中移动或重新构建对象。
注：虽然这些方法可以最小化buffer busy waits问题，但它们无疑会增加全表扫描时间和磁盘空间利用率。
数据段头(类#4)的争用
注：进程出于两个主要原因访问段头，一是，获得或修改FREELISTS信息；二是，为了扩展高水位标记(HWM)。
2) 减少这种情况的等待的方法：
>> 对使用自由表进行段管理的表，增加确认对象的FREELISTS和FREELIST GROUPS(注：FREELIST GROUPS的增加也是必须的)；
>> 确保FCTFREE和PCTUSED之间的间隙不是太小，从而可以最小化FREELIST的块循环。
>> 下一区的尺寸不能太小，当区高速扩张时，建立的新区需要修改在段头中区映射表。可以考虑将对象移动到合理的、统一尺寸的本地管理的表空间中。
撤销段头(类#17)的争用
2) 可以创建并启用私有回滚段，以减少每个回滚段的事务数量。需要修改init.ora文件中的ROLLBACK_SEGMENTS参数。
3) 如果使用公用回滚段可以减少初始化参数transactions_per_rollback_segment的值，ORACLE通过transactions/transactions_per_rollback_segment来获取公有回滚段的最小数量。
撤销块的争用(类#18)
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
DB buffer bussy wait 分析一例相关推荐
- 缓冲区溢出(buffer overflow)机理分析
http://blog.sina.com.cn/s/blog_4c72721c010008vt.html ########################################## ...
- 语音处理：PCM文件中采样值到dB分贝的转换分析
语音处理:PCM文件中采样值到dB分贝的转换分析 问题引入 核心公式 问题回答 举一反三 本文小结 扩展知识 参考资料 问题引入 分析音频文件过程中,发现16bit的PCM文件,采样值显示为2900, ...
- JAVA抽象类和接口的区别【附经典分析用例Door】
这篇文章对抽象类和接口说的很详细,希望对大家有所帮助. abstract class和interface是Java语言中对于抽象类定义进行支持的两种机制,正是由于这两种机制的存在,才赋予了Java强大 ...
- mysql用户阻塞数_MySQL实例阻塞分析一例(线程statistics状态)
本文用实例来分析MySQL阻塞-线程statistics状态. 一. 现象 某日下午下班后低峰期,现网MySQL一个库突然报出大量慢sql,状态是 statistics,但是过后拿这些sql去执行的时 ...
- LINUX IIO子系统分析之五IIO BUFFER子模块实现分析
上一章我们介绍了iio子系统中的iio event模块,本章我们将介绍iio buffer模块,iio buffer主要用于连续数据采集与缓存功能.IIO buffer模块借助IIO DEVICE字符 ...
- 【论文解读】NAACL 2021 对比自监督学习的上下文和一般句子表征:以篇章关系分析为例
前言 本文是NAACL 2021的论文<Contextualized and Generalized Sentence Representations by Contrastive Self-S ...
- 利用ffmpeg对视频文件进行分析几例
1.将视频文件转换为jpg图片文件序列: ffmpeg -i /home/czl/WorkSpace/ffmpeg/H264_REC.raw -r 1 -q:v 2 -f image2 pic-%03 ...
- R实战 | 置换多元方差分析（以PCoA的PERMANOVA分析为例）
adonis-cover 置换多元方差分析(Permutational multivariate analysis of variance,PERMANOVA),又称非参数多因素方差分析(nonpar ...
- 用NCL将GRIB/GRIB2文件转成nc文件（批量转），JRA-55再分析为例
背景: 答主最近需要用到JRA-55再分析数据,但在面对GRIB数据格式时犯难了,便想把GRIB格式转成nc文件再做分析.因为nc文件很容易用python或Matlab处理 尝试了好些方法,发现先安装 ...
最新文章
- 如何在Bash中加入数组元素？
- 去掉标题栏全屏显示代码
- Android之自定义view引用xml,Android自定义View在XML中映射错误
- 自定义函数strcomp()，实现两个字符串的比较
- 三个球A,B,C大小形状相同，且其中有一个球与其他球的重量不同，要求找出这个不一样的球
- 应用实时监控 ARMS 上线用户行为回溯功能
- 软件开发工具--自考2018年10月程序填空
- php date t_php date 参数
- 校招刷题---java选择题笔记01
- [翻译] ios-image-filters
- 从零開始学androidlt;TabHost标签组件.二十九.gt;
- assert断言的概念
- 原生js用ajax上传图片,关于js ajax上传图片
- 仿苹果官网产品页面效果特效
- 计算机主机光盘故障,光驱常见故障及解决办法
- 程度性数据python分析_python数据分析实战之AQI分析
- dad my_【玩转英文绘本】My Dad!《我爸爸》
- 服务器 ftp查询文件是否存在,ftp查看远程服务器文件是否存在
- C、C++、Java到Python，编程入门学习什么语言好?
- 【目标管理】OKR如何助力目标管理？