关于latch: cache buffers chains的sql优化
前段时间，优化了一些耗buffer比较多的sql，但是CPU使用率还是没下来 。
查看操作系统CPU使用率
查看awr，发现又有一条超级耗性能的sql冒出来了。
该SQL每次执行耗费3e多个buffer，结果就是导致内存消耗高，cpu消耗也高。。。
利用工具PLSQL Developer，查询执行该SQL的session
数据库的等待事件为latch: cache buffers chains
SQL代码：
select distinct to_char(t5.summaryno) settlementNo,
to_char(t5.batchtype) settlementType,
to_char(s.writeouttype) certitype,
to_char(t5.payconfirmsequenceno) payConfirmSequenceNo,
to_char(t5.commissionpayno) CommissionPayNo,
to_char(t2.amount) payAmount,
to_char(t2.currencycode) payCurrency,
(case
when t5.unitcode = '012100' then
(select to_char(d.timestamp, 'YYYY-MM-DD HH24:mi:ss')
from mm_dailyreport_detail_td d
where d.seqreportno = t1.seqreportno)
else
to_char(t2.opdate, 'YYYY-MM-DD HH24:mi:ss')
end) payDate,
to_char(s.batch_id) batchid,
t2.coreason payErrorMessage,
'' payedExchangedRate,
(select distinct o.voucherno
from mm_sap_voucher_detail_to o
where o.businessno = t2.inpaymentid
and o.dailyauditno = t3.dailyauditno) accountingDocuments,
(case
when t2.amount > 0 then
'02'
when t2.amount < 0 then
'03'
when t2.amount = 0 then
'01'
end) payStatus,
to_char(t2.inpaymentid) ebankSequenceNo
from mm_writeout_to t1,
mm_inpayment_td t2,
mm_paymentin_events_td t3,
mm_payablemoney_td t4,
mm_batchinfo_td t5,
mm_batchinfo_ti t6,
mm_writeoutstatus_to s
where t2.inpaymentid = t1.businessno
and t1.id = s.id
and t3.newno = t2.inpaymentid
and ((t3.oldno = t4.payableno) or exists
(select 1
from mm_paymentin_events_td p
where p.listno = t3.fatherno
and t4.payableno = p.oldno))
and t6.id = t5.seqbatch
and t6.status = '2'
and t5.opstatus = '0'
and t5.serialno = t4.custseq
and s.batch_id = :1
and exists (select 1
from mm_sap_voucher_detail_to o
where o.businessno = t2.inpaymentid
and o.dailyauditno = t3.dailyauditno)
and s.status in ('00', 'XX')该sql中有个变量值 s.batch_id = :1，利用系统视图dba_hist_sqlbind找出绑定变量值，在测试环境测试，发现每次执行都只要334个buffer
执行计划没错？只消耗334个buffer，而且1s内出结果，完全不像awr中记录的。
dba_hist_sqlbind：查询历史绑定变量信息, dba_hist_sqlbind的信息是从v$sql_bind_capture里面采集的。
v$sql_bind_capture view：只保存最后一次捕获SQL的变量信息，两次捕获之间的间隔为900s，受隐藏参数控制
再次利用视图v$sql_bind_capture抓取最新的值，代入sql中执行，发现sql卡住了。。
查看sql特殊执行计划
Plan hash value: 534203852
-------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
| 1 | TABLE ACCESS BY INDEX ROWID | MM_DAILYREPORT_DETAIL_TD | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 2 | INDEX UNIQUE SCAN | PK_MM_DAILYREPORT_DETAIL_TD | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 3 | HASH UNIQUE | | 1 | 1 | 1 |00:00:00.01 | 8 | 1036K| 1036K| 318K (0)|
| 4 | TABLE ACCESS BY INDEX ROWID | MM_SAP_VOUCHER_DETAIL_TO | 1 | 1 | 1 |00:00:00.01 | 8 | | | |
|* 5 | INDEX RANGE SCAN | IDX_MM_SAP_VOUCHER_DETAIL_TO1 | 1 | 1 | 1 |00:00:00.01 | 7 | | | |
| 6 | HASH UNIQUE | | 1 | 1 | 1 |00:10:57.87 | 335M| 751K| 751K| 359K (0)|
|* 7 | FILTER | | 1 | | 134 |00:27:07.96 | 335M| | | |
| 8 | TABLE ACCESS BY INDEX ROWID | MM_PAYABLEMONEY_TD | 1 | 1 | 21M|00:26:00.03 | 335M| | | |
| 9 | NESTED LOOPS | | 1 | 1 | 86M|00:23:12.83 | 322M| | | |
| 10 | NESTED LOOPS | | 1 | 1 | 64M|00:13:59.99 | 193M| | | |
| 11 | MERGE JOIN CARTESIAN | | 1 | 1 | 64M|00:01:05.38 | 22421 | | | |
| 12 | NESTED LOOPS SEMI | | 1 | 1 | 134 |00:00:00.01 | 72 | | | |
| 13 | NESTED LOOPS | | 1 | 1 | 134 |00:00:00.01 | 65 | | | |
| 14 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 14 | | | |
| 15 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 11 | | | |
| 16 | INLIST ITERATOR | | 1 | | 1 |00:00:00.01 | 7 | | | |
| 17 | TABLE ACCESS BY INDEX ROWID| MM_WRITEOUTSTATUS_TO | 2 | 1 | 1 |00:00:00.01 | 7 | | | |
|* 18 | INDEX RANGE SCAN | IDX_WRITEOUTSTATUS_TEST | 2 | 1 | 1 |00:00:00.01 | 6 | | | |
| 19 | TABLE ACCESS BY INDEX ROWID | MM_WRITEOUT_TO | 1 | 1 | 1 |00:00:00.01 | 4 | | | |
|* 20 | INDEX UNIQUE SCAN | PK_MM_WRITEOUT_TO | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
| 21 | TABLE ACCESS BY INDEX ROWID | MM_INPAYMENT_TD | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
|* 22 | INDEX UNIQUE SCAN | PK_MM_INPAYMENT_TD | 1 | 1 | 1 |00:00:00.01 | 2 | | | |
| 23 | TABLE ACCESS BY INDEX ROWID | MM_PAYMENTIN_EVENTS_TD | 1 | 2 | 134 |00:00:00.01 | 51 | | | |
|* 24 | INDEX RANGE SCAN | IDX_PAYMENTINE_07 | 1 | 2 | 134 |00:00:00.01 | 4 | | | |
|* 25 | INDEX RANGE SCAN | IDX_MM_SAP_VOUCHER_DETAIL_TO1 | 1 | 4538 | 1 |00:00:00.01 | 7 | | | |
| 26 | BUFFER SORT | | 134 | 472K| 64M|00:00:00.83 | 22349 | 56M| 2617K| 49M (0)|
|* 27 | TABLE ACCESS FULL | MM_BATCHINFO_TD | 1 | 472K| 481K|00:00:00.01 | 22349 | | | |
|* 28 | TABLE ACCESS BY INDEX ROWID | MM_BATCHINFO_TI | 64M| 1 | 64M|00:11:32.52 | 193M| | | |
|* 29 | INDEX UNIQUE SCAN | PK_BATCHINFO_TI | 64M| 1 | 64M|00:06:50.50 | 129M| | | |
|* 30 | INDEX RANGE SCAN | IDX_PAYABLEMONEY_09 | 64M| 1 | 21M|00:08:45.52 | 129M| | | |
|* 31 | INDEX RANGE SCAN | IDX_PAYMENTINE_TEST | 21M| 1 | 0 |00:00:22.85 | 0 | | | |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("D"."SEQREPORTNO"=TO_NUMBER(:B1))
5 - access("O"."DAILYAUDITNO"=:B1)
filter(TO_NUMBER("O"."BUSINESSNO")=:B1)
7 - filter(("T3"."OLDNO"="T4"."PAYABLENO" OR IS NOT NULL))
18 - access((("S"."STATUS"='00' OR "S"."STATUS"='XX')) AND "S"."BATCH_ID"='1219626143')
20 - access("T1"."ID"="S"."ID")
22 - access("T2"."INPAYMENTID"=TO_NUMBER("T1"."BUSINESSNO"))
24 - access("T3"."NEWNO"="T2"."INPAYMENTID")
25 - access("O"."DAILYAUDITNO"="T3"."DAILYAUDITNO")
filter("T2"."INPAYMENTID"=TO_NUMBER("O"."BUSINESSNO"))
27 - filter("T5"."OPSTATUS"='0')
28 - filter("T6"."STATUS"='2')
29 - access("T6"."ID"="T5"."SEQBATCH")
30 - access("T5"."SERIALNO"="T4"."CUSTSEQ")
31 - access("P"."LISTNO"=:B1 AND "P"."OLDNO"=:B2)
67 rows selected.id=11处 ，a-rows并不是0条，而是有64000000条记录。他的父级 的连接方式是 NEST LOOP，
也就是说被驱动表MM_BATCHINFO_TI表要被扫描64000000次。。。
定位到问题点，现在就开始优化吧。
尝试优化1：
利用hint（/+ OPT_PARAM(‘_optimizer_mjc_enabled’,’false’) /）禁用笛卡尔积
不见效果，此优化方法失败。
尝试优化2：
利用hint 走hash的连接方式
不见效果，此优化方法也失败。
尝试优化3：
从sql代码中看出，该SQLwhere条件又or子查询，尝试利用union改写or
select distinct to_char(t5.summaryno) settlementNo,
to_char(t5.batchtype) settlementType,
to_char(s.writeouttype) certitype,
to_char(t5.payconfirmsequenceno) payConfirmSequenceNo,
to_char(t5.commissionpayno) CommissionPayNo,
to_char(t2.amount) payAmount,
to_char(t2.currencycode) payCurrency,
(case
when t5.unitcode = '012100' then
(select to_char(d.timestamp, 'YYYY-MM-DD HH24:mi:ss')
from mm_dailyreport_detail_td d
where d.seqreportno = t1.seqreportno)
else
to_char(t2.opdate, 'YYYY-MM-DD HH24:mi:ss')
end) payDate,
to_char(s.batch_id) batchid,
t2.coreason payErrorMessage,
'' payedExchangedRate,
(select distinct o.voucherno
from mm_sap_voucher_detail_to o
where o.businessno = t2.inpaymentid
and o.dailyauditno = t3.dailyauditno) accountingDocuments,
(case
when t2.amount > 0 then
'02'
when t2.amount < 0 then
'03'
when t2.amount = 0 then
'01'
end) payStatus,
to_char(t2.inpaymentid) ebankSequenceNo
from mm_writeout_to t1,
mm_inpayment_td t2,
mm_paymentin_events_td t3,
mm_payablemoney_td t4,
mm_batchinfo_td t5,
mm_batchinfo_ti t6,
mm_writeoutstatus_to s
where t2.inpaymentid = t1.businessno
and t1.id = s.id
and t3.newno = t2.inpaymentid
and t3.oldno = t4.payableno
and t6.id = t5.seqbatch
and t6.status = '2'
and t5.opstatus = '0'
and t5.serialno = t4.custseq
and s.batch_id = '1219639828'
and exists (select 1
from mm_sap_voucher_detail_to o
where o.businessno = t2.inpaymentid
and o.dailyauditno = t3.dailyauditno)
and s.status in ('00', 'XX')
union
select distinct to_char(t5.summaryno) settlementNo,
to_char(t5.batchtype) settlementType,
to_char(s.writeouttype) certitype,
to_char(t5.payconfirmsequenceno) payConfirmSequenceNo,
to_char(t5.commissionpayno) CommissionPayNo,
to_char(t2.amount) payAmount,
to_char(t2.currencycode) payCurrency,
(case
when t5.unitcode = '012100' then
(select to_char(d.timestamp, 'YYYY-MM-DD HH24:mi:ss')
from mm_dailyreport_detail_td d
where d.seqreportno = t1.seqreportno)
else
to_char(t2.opdate, 'YYYY-MM-DD HH24:mi:ss')
end) payDate,
to_char(s.batch_id) batchid,
t2.coreason payErrorMessage,
'' payedExchangedRate,
(select distinct o.voucherno
from mm_sap_voucher_detail_to o
where o.businessno = t2.inpaymentid
and o.dailyauditno = t3.dailyauditno) accountingDocuments,
(case
when t2.amount > 0 then
'02'
when t2.amount < 0 then
'03'
when t2.amount = 0 then
'01'
end) payStatus,
to_char(t2.inpaymentid) ebankSequenceNo
from mm_writeout_to t1,
mm_inpayment_td t2,
mm_paymentin_events_td t3,
mm_payablemoney_td t4,
mm_batchinfo_td t5,
mm_batchinfo_ti t6,
mm_writeoutstatus_to s
where t2.inpaymentid = t1.businessno
and t1.id = s.id
and t3.newno = t2.inpaymentid
and exists
(select 1
from mm_paymentin_events_td p
where p.listno = t3.fatherno
and t4.payableno = p.oldno)
and t6.id = t5.seqbatch
and t6.status = '2'
and t5.opstatus = '0'
and t5.serialno = t4.custseq
and s.batch_id = '1219639828'
and exists (select 1
from mm_sap_voucher_detail_to o
where o.businessno = t2.inpaymentid
and o.dailyauditno = t3.dailyauditno)
and s.status in ('00', 'XX')
--执行计划：
Plan hash value: 1779884842
-------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
| 1 | SORT UNIQUE | | 1 | 2 | 1 |00:00:00.01 | 1212 | 2048 | 2048 | 2048 (0)|
| 2 | UNION-ALL | | 1 | | 134 |00:00:00.01 | 1212 | | | |
| 3 | NESTED LOOPS SEMI | | 1 | 1 | 134 |00:00:00.01 | 1145 | | | |
| 4 | NESTED LOOPS | | 1 | 1 | 134 |00:00:00.01 | 1138 | | | |
| 5 | NESTED LOOPS | | 1 | 1 | 134 |00:00:00.01 | 867 | | | |
| 6 | NESTED LOOPS | | 1 | 1 | 134 |00:00:00.01 | 463 | | | |
| 7 | NESTED LOOPS | | 1 | 1 | 134 |00:00:00.01 | 59 | | | |
| 8 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 14 | | | |
| 9 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 11 | | | |
| 10 | INLIST ITERATOR | | 1 | | 1 |00:00:00.01 | 7 | | | |
| 11 | TABLE ACCESS BY INDEX ROWID | MM_WRITEOUTSTATUS_TO | 2 | 1 | 1 |00:00:00.01 | 7 | | | |
|* 12 | INDEX RANGE SCAN | IDX_WRITEOUTSTATUS_TEST | 2 | 1 | 1 |00:00:00.01 | 6 | | | |
| 13 | TABLE ACCESS BY INDEX ROWID | MM_WRITEOUT_TO | 1 | 1 | 1 |00:00:00.01 | 4 | | | |
|* 14 | INDEX UNIQUE SCAN | PK_MM_WRITEOUT_TO | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
| 15 | TABLE ACCESS BY INDEX ROWID | MM_INPAYMENT_TD | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
|* 16 | INDEX UNIQUE SCAN | PK_MM_INPAYMENT_TD | 1 | 1 | 1 |00:00:00.01 | 2 | | | |
| 17 | TABLE ACCESS BY INDEX ROWID | MM_PAYMENTIN_EVENTS_TD | 1 | 13 | 134 |00:00:00.01 | 45 | | | |
|* 18 | INDEX RANGE SCAN | IDX_PAYMENTINE_08 | 1 | 13 | 134 |00:00:00.01 | 4 | | | |
| 19 | TABLE ACCESS BY INDEX ROWID | MM_PAYABLEMONEY_TD | 134 | 1 | 134 |00:00:00.01 | 404 | | | |
|* 20 | INDEX UNIQUE SCAN | PK_MM_PAYABLEMONEY_TD | 134 | 1 | 134 |00:00:00.01 | 270 | | | |
| 21 | TABLE ACCESS BY INDEX ROWID | MM_BATCHINFO_TD | 134 | 1 | 134 |00:00:00.01 | 404 | | | |
|* 22 | INDEX RANGE SCAN | IDX_BATCH_TD_SERIALNO | 134 | 1 | 134 |00:00:00.01 | 270 | | | |
|* 23 | INDEX RANGE SCAN | IDX_BATCHINFO_TI_01 | 134 | 1 | 134 |00:00:00.01 | 271 | | | |
|* 24 | INDEX RANGE SCAN | IDX_MM_SAP_VOUCHER_DETAIL_TO1 | 1 | 2732 | 1 |00:00:00.01 | 7 | | | |
| 25 | NESTED LOOPS SEMI | | 1 | 1 | 0 |00:00:00.01 | 59 | | | |
| 26 | NESTED LOOPS | | 1 | 1 | 0 |00:00:00.01 | 59 | | | |
| 27 | NESTED LOOPS | | 1 | 1 | 0 |00:00:00.01 | 59 | | | |
| 28 | NESTED LOOPS | | 1 | 1 | 0 |00:00:00.01 | 59 | | | |
| 29 | NESTED LOOPS | | 1 | 1 | 0 |00:00:00.01 | 59 | | | |
| 30 | NESTED LOOPS | | 1 | 1 | 0 |00:00:00.01 | 59 | | | |
| 31 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 14 | | | |
| 32 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 11 | | | |
| 33 | INLIST ITERATOR | | 1 | | 1 |00:00:00.01 | 7 | | | |
| 34 | TABLE ACCESS BY INDEX ROWID| MM_WRITEOUTSTATUS_TO | 2 | 1 | 1 |00:00:00.01 | 7 | | | |
|* 35 | INDEX RANGE SCAN | IDX_WRITEOUTSTATUS_TEST | 2 | 1 | 1 |00:00:00.01 | 6 | | | |
| 36 | TABLE ACCESS BY INDEX ROWID | MM_WRITEOUT_TO | 1 | 1 | 1 |00:00:00.01 | 4 | | | |
|* 37 | INDEX UNIQUE SCAN | PK_MM_WRITEOUT_TO | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
| 38 | TABLE ACCESS BY INDEX ROWID | MM_INPAYMENT_TD | 1 | 1 | 1 |00:00:00.01 | 3 | | | |
|* 39 | INDEX UNIQUE SCAN | PK_MM_INPAYMENT_TD | 1 | 1 | 1 |00:00:00.01 | 2 | | | |
|* 40 | TABLE ACCESS BY INDEX ROWID | MM_PAYMENTIN_EVENTS_TD | 1 | 2 | 0 |00:00:00.01 | 45 | | | |
|* 41 | INDEX RANGE SCAN | IDX_PAYMENTINE_08 | 1 | 13 | 134 |00:00:00.01 | 4 | | | |
| 42 | SORT UNIQUE | | 0 | 1 | 0 |00:00:00.01 | 0 | 73728 | 73728 | |
|* 43 | INDEX RANGE SCAN | IDX_PAYMENTINE_TEST | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 44 | TABLE ACCESS BY INDEX ROWID | MM_PAYABLEMONEY_TD | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 45 | INDEX UNIQUE SCAN | PK_MM_PAYABLEMONEY_TD | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
| 46 | TABLE ACCESS BY INDEX ROWID | MM_BATCHINFO_TD | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 47 | INDEX RANGE SCAN | IDX_BATCH_TD_SERIALNO | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 48 | INDEX RANGE SCAN | IDX_BATCHINFO_TI_01 | 0 | 1 | 0 |00:00:00.01 | 0 | | | |
|* 49 | INDEX RANGE SCAN | IDX_MM_SAP_VOUCHER_DETAIL_TO1 | 0 | 2963 | 0 |00:00:00.01 | 0 | | | |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
12 - access((("S"."STATUS"='00' OR "S"."STATUS"='XX')) AND "S"."BATCH_ID"='1219639828')
14 - access("T1"."ID"="S"."ID")
16 - access("T2"."INPAYMENTID"=TO_NUMBER("T1"."BUSINESSNO"))
18 - access("T3"."NEWNO"="T2"."INPAYMENTID")
20 - access("T3"."OLDNO"="T4"."PAYABLENO")
22 - access("T5"."OPSTATUS"='0' AND "T5"."SERIALNO"="T4"."CUSTSEQ")
23 - access("T6"."STATUS"='2' AND "T6"."ID"="T5"."SEQBATCH")
24 - access("O"."DAILYAUDITNO"="T3"."DAILYAUDITNO")
filter("T2"."INPAYMENTID"=TO_NUMBER("O"."BUSINESSNO"))
35 - access((("S"."STATUS"='00' OR "S"."STATUS"='XX')) AND "S"."BATCH_ID"='1219639828')
37 - access("T1"."ID"="S"."ID")
39 - access("T2"."INPAYMENTID"=TO_NUMBER("T1"."BUSINESSNO"))
40 - filter("T3"."FATHERNO" IS NOT NULL)
41 - access("T3"."NEWNO"="T2"."INPAYMENTID")
43 - access("P"."LISTNO"="T3"."FATHERNO")
45 - access("T4"."PAYABLENO"="P"."OLDNO")
47 - access("T5"."OPSTATUS"='0' AND "T5"."SERIALNO"="T4"."CUSTSEQ")
48 - access("T6"."STATUS"='2' AND "T6"."ID"="T5"."SEQBATCH")
49 - access("O"."DAILYAUDITNO"="T3"."DAILYAUDITNO")
filter("T2"."INPAYMENTID"=TO_NUMBER("O"."BUSINESSNO"))
代入最新值，秒出结果。
后经开发检验，该sql大大改善了系统性能，cpu利用率也随之下降。
关于latch: cache buffers chains的sql优化的更多相关文章
- latch: cache buffers chains故障处理总结(转载)
一大早就接到开发商的电话,说数据库的CPU使用率为100%,应用相应迟缓.急匆匆的赶到现场发现进行了基本的检查后发现是latch: cache buffers chains 作祟,处理过程还算顺利,当 ...
- latch: cache buffers chains故障处理总结
一大早就接到开发商的电话,说数据库的CPU使用率为100%,应用相应迟缓.急匆匆的赶到现场发现进行了基本的检查后发现是latch: cache buffers chains 作祟,处理过程还算顺利,当 ...
- [转帖]深入理解latch: cache buffers chains
深入理解latch: cache buffers chains http://blog.itpub.net/12679300/viewspace-1244578/ 原创 Oracle 作者:wzq60 ...
- 【转载】latch: cache buffers chains
本文转自惜分飞的博客,博客原文地址:www.xifenfei.com/1109.html,支持原创,分享知识! 当一个数据块读入sga区,相应的buffer header会被放置到hash列表上,我们 ...
- Oracle索引失效问题：WHERE C1='' OR C2 IN(SubQuery)，并发请求时出现大量latch: cache buffers chains等待
问题描述: 项目反馈某功能响应时间很长,高峰期时系统整体响应很慢... 获取相应的AWR,问题确实比较严重,latch: cache buffers chains等待,因为这些会话SQL执行时间太长, ...
- 案例：latch: cache buffers chains event tuning
前两天对oracle数据库(single instance)进行了迁移升级从10.2.0.4 升到11.2.0.3,有一个项目迁完后第二天,cpu负载升到了130更高(16cpus). 向用户询问后使 ...
- 又是latch: cache buffers chains惹得祸
前言 一大早,客户给我打电话说: xx,应用很慢,查询数据总是超时,让我看看... 根据多年DBA经验,首当其冲的肯定是去查询数据库在这段时间都在干嘛. 分析 导出awr报告分析 1). 数据库在此时 ...
- latch：cache buffers chains的优化思路
数据块在buffer cache存放是以linked list方式存放的.当一个session想要访问/修改buffer cache的block,首先需要通过hash算法检查该block是否存在于bu ...
- 低效的SQL引发的cache buffers chains latch
1.低效的SQL 低效的SQL语句时发生cache buffers chains 锁存器争用的最重要原因.多个进程同时扫描大范围的索引或表时,可能广泛 地发生cache buffers chains ...
随机推荐
- bzoj 3612: [Heoi2014]平衡【整数划分dp】
其实就是-n~n中求选k个不同的数,和为0的方案数 学到了新姿势叫整数划分,具体实现是dp 详见:https://blog.csdn.net/Vmurder/article/details/42551 ...
- bzoj 3159: 决战【LCT】
只是想复健一下LCT没想到做了不得了的题--调了两天QAQ 题解是这么说的: 但是果然还不太理解--因为swap的前后问题调了好久,(所以一开始养成的习惯后面就不要再改啦-- 总之大概就是把对位置lc ...
- 【插件开发】—— 10 JFace开发详解
前文回顾: 1 插件学习篇 2 简单的建立插件工程以及模型文件分析 3 利用扩展点,开发透视图 4 SWT编程须知 5 SWT简单控件的使用与布局搭配 6 SWT复杂空间与布局搭配 7 SWT布局详解 ...
- SpringMVC异步调用,Callable和DeferredResult的使用
Callable和DeferredResult都是springMVC里面的异步调用,Callable主要用来处理一些简单的逻辑,DeferredResult主要用于处理一些复杂逻辑 1.Callabl ...
- PowerDesigner在PDM转换为sql脚本时报错Generation aborted due to errors detected during the verification of the mod
在设计概念数据模型(CDM)之后,转换为物理数据模型(PDM),之后转换为sql脚本时报错Generation aborted due to errors detected during the ve ...
- [ZPG TEST 108] blockenemy【树形dp】
T3:blockenemy blockenemy.pas/in/out 128M 1s 你在玩电子游戏的时候遇到了麻烦...... 你玩的游戏是在一个虚拟的城市里进行,这个城市里有n个点,都从0~n- ...
- 构造水题 Codeforces Round #206 (Div. 2) A. Vasya and Digital Root
题目传送门 /* 构造水题:对于0的多个位数的NO,对于位数太大的在后面补0,在9×k的范围内的平均的原则 */ #include <cstdio> #include <algori ...
- PWA之serviceWorker应用
1.serviceWorker介绍service worker是一段运行在浏览器后台的JavaScript脚本,在页面中注册并安装成功后,它可以拦截和处理网络请求,实现缓存资源并可在离线时响应用户的请 ...
- JMeter（十一）内存溢出解决方法
使用jmeter进行压力测试时遇到一段时间后报内存溢出outfmenmory错误,导致jmeter卡死了,先尝试在jmeter.bat中增加了JVM_ARGS="-Xmx2048m -Xms ...
- C#_JDBC连接数据库
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.T ...