回收站(recyclebin)引发row cache lock

昨天一哥们 QQ 发来消息,说有个 insert ... 语句插入了 30 分钟还没完成,请求帮忙优化, SQL 语句如下:
 
1.  INSERT INTO Temp_CheckSExit101320166  
2.    SELECT KEYCOL,  
3.           CARDNETWORK,  
4.           CARDID,  
5.           EXITSTATION,  
6.           EXITDATE,  
7.           TOTALTOLL,  
8.           PAYMETHOD,  
9.           DEALSTATUS,  
10.          FREEKIND,  
11.          SPLITTOLLINFO,  
12.          ECARDTYPE,  
13.          OWNERNUM,  
14.          0,  
15.          NULL,  
16.          NULL,  
17.          NULL FROMCHECK_SEXIT201108  
18.    WHERE  PAYMETHOD  =  2   
19.      AND  CARDNETWORK  =  3201   
20.      AND SUBSTR(EXITNETWORK, 1, 2) = 32  
21.      AND  ECARDTYPE  =  22   
22.      AND EXITDATE  < = 20110829  
23.      AND  validflag  =  1   
24.      AND  ENDFLAG  =  0   

 
这个 SQL 很简单,就是从另外一个表抽取数据到另外一个表,执行计划很简单,是全表扫描,询问得知表 CHECK_SEXIT201108 只有 0.8G ,跑 30 分钟确实不应该
让他监控等待事件,绝大部分等待是 row cache lock
处理问题的方法:
1. 由于是 insert .... select  没有  sequence ,所以 sequence 因素排除了
2. 让他检查  alert.log  搜寻十分有  ROW CACHE LOCK 关键字,搜索完毕之后没发现有该关键字,所以 ORACLE BUG  基本 排除了
3. 查看 AWR TOP 5 Timed Events ,没有发现 ROW CACHE LOCK ,所以  row cache lock  竞争也排除了
Top 5 Timed Events

Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
CPU time
 
9,610
 
74.7
 
db file sequential read
660,851
2,590
4
20.1
User I/O
db file scattered read
284,346
456
2
3.5
User I/O
gc cr multi block request
448,707
112
0
.9
Cluster
gc cr disk read
296,228
97
0
.8
Cluster

SQL ordered by Elapsed Time
·          Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
·          % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

Elapsed Time (s)
CPU Time (s)
Executions
Elap per Exec (s)
% Total DB Time
SQL Id
SQL Module
SQL Text
6,083
6,079
3,035
2.00
47.24
 
select obj#, type#, flags, ...
3,510
3,491
9,879
0.36
27.25
delete from RecycleBin$ ...
3,445
3,377
1
3444.94
26.75
PL/SQL Developer
begin -- Call the procedure ...
3,088
3,027
0
 
23.97
JDBC Connect Client
BEGIN DBMID.PRCSPLITALL ( :V1,...
3,074
3,019
0
23.87
JDBC Connect Client
INSERT INTO Temp_CheckSExit101...
2,109
2,071
0
 
16.37
PL/SQL Developer
INSERT INTO Temp_CheckSExit211...
1,546
1,526
0
 
12.01
toad.exe
INSERT INTO Temp_CheckSExit2...
1,247
1,222
2
623.44
9.68
TOAD 9.7.0.51
begin DBMID.PRCTRANSDATA('DBMI...
1,231
1,214
2
615.55
9.56
DataTransServer.exe
INSERT INTO DBMID.TRANS_EXIT20...
848
848
2
424.16
6.59
TOAD 9.7.0.51
select * from v$access where o...
620
602
3
206.83
4.82
TOAD 9.7.0.51
begin DBMID.PRCTRANSDATA('DBMI...
613
596
3
204.29
4.76
TOAD 9.7.0.51
INSERT INTO DBMID.TRANS_Entry2...
507
329
247
2.05
3.93
 
select file#, block# from seg...
262
199
48
5.46
2.03
JDBC Thin Client
BEGIN dbmid.PRCCOSMRECORD(:1, ...
252
169
15
16.79
1.96
JDBC Thin Client
BEGIN dbmid.PrcGetCardMFlux(:1...
160
151
0
 
1.24
TOAD 9.7.0.51
SELECT * FROM DBMTC.RAW_EXIT20...
156
156
4
39.07
1.21
toad.exe
select * from v$access where o...

 
通过查看 TOP SQL ,我发现 recyclebin 居然没有关闭,这实在是不应该, recyclebin 通常是需要关闭的,于是让该哥们查看表空间使用率
给了他一个脚本,结果跑半天没结果。。。遇到了 library cache lock  由于我不能登录他的数据库,所以建议该哥们关闭回收站,因为我怀疑 insert 的时候由于表空间几乎满了
导致 ORACLE 去清空回收站,从而引发 row cache lock 。果然,当那哥们关闭回收站之后, insert  报错  ORA-01653: unable to extend table.... by 128 in tablespace...
现在已经证明了是回收站引发的 row cache lock ,那个哥们添加了 2 个数据文件之后 insert  很快,最后让那个哥们 purge recyclebin
其实还有个方法可以快速定位是回收站引发的问题,这里就不说了




本文转自 vfast_chenxy 51CTO博客,原文链接:http://blog.51cto.com/chenxy/742905,如需转载请自行联系原作者
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值