博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【Oracle】-【COMMIT对索引的影响】-从trace看COMMIT对索引的影响
阅读量:5864 次
发布时间:2019-06-19

本文共 2737 字,大约阅读时间需要 9 分钟。

之前看过老杨的一篇文章,讲述了INSERT操作对全文索引无操作,但DELETE时为了防止删除的数据仍能通过索引的ROWID访问产生的错误,此时会进行索引的删除操作,因此大批量的DELETE-COMMIT就会耗时,甚至导致数据库挂起。

最近因为工作上的需求,有个任务涉及到数据迁移,因此一直关注COMMIT耗时的问题,就想按照老杨的方法,看看对于普通索引,上述所说的COMMIT是否有影响。

测试环境:Oracle 10.2.0.4+Linux x86_64

用例1:INSERT后COMMIT操作。

SQL> create table t as select * from dba_objects;

Table created.

SQL> create index t_idx on t(object_id);

Index created.

SQL> insert into t(object_id) values(1);

1 row created.
SQL> alter session set sql_trace=true;
Session altered.
SQL> commit;
Commit complete.
SQL> alter session set sql_trace=false;
Session altered.

用例2:DELETE后COMMIT操作。

重登陆

SQL> delete from t where object_id=1;

1 row deleted.
SQL> alter session set sql_trace=true;
Session altered.
SQL> commit;
Commit complete.
SQL> alter session set sql_trace=false;
Session altered.

这里重登陆再trace是为了防止重用会话缓存的游标,从而使结果更清晰。

用例1的trace文件:

*** 2013-07-31 08:56:57.328

*** ACTION NAME:() 2013-07-31 08:56:57.328
*** MODULE NAME:(sqlplus@vm-vmw4131-t (TNS V1-V3)) 2013-07-31 08:56:57.328
*** SERVICE NAME:(SYS$USERS) 2013-07-31 08:56:57.328
*** SESSION ID:(508.20733) 2013-07-31 08:56:57.327
=====================
PARSING IN CURSOR #1 len=6 dep=0 uid=0 oct=44 lid=0 tim=1343000212234337 hv=3480936638 ad='0'
commit
END OF STMT
PARSE #1:c=0,e=54,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000212234330
XCTEND rlbk=0, rd_only=0
EXEC #1:c=0,e=374,p=0,cr=0,cu=1,mis=0,r=0,dep=0,og=0,tim=1343000212235249
=====================
PARSING IN CURSOR #2 len=33 dep=0 uid=0 oct=42 lid=0 tim=1343000219675725 hv=525901419 ad='0'
alter session set sql_trace=false
END OF STMT
PARSE #2:c=0,e=47,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000219675717
EXEC #2:c=0,e=28,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000219675914

用例2的trace文件:

*** 2013-07-31 08:57:43.829

*** ACTION NAME:() 2013-07-31 08:57:43.828
*** MODULE NAME:(sqlplus@vm-vmw4131-t (TNS V1-V3)) 2013-07-31 08:57:43.828
*** SERVICE NAME:(SYS$USERS) 2013-07-31 08:57:43.828 
*** SESSION ID:(508.20743) 2013-07-31 08:57:43.828
=====================
PARSING IN CURSOR #3 len=6 dep=0 uid=0 oct=44 lid=0 tim=1343000257645312 hv=3480936638 ad='0'
commit
END OF STMT
PARSE #3:c=0,e=130,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000257645304
XCTEND rlbk=0, rd_only=0
EXEC #3:c=0,e=424,p=0,cr=0,cu=1,mis=0,r=0,dep=0,og=0,tim=1343000257646177
=====================
PARSING IN CURSOR #1 len=33 dep=0 uid=0 oct=42 lid=0 tim=1343000265207698 hv=525901419 ad='0'
alter session set sql_trace=false
END OF STMT     
PARSE #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000265207690
EXEC #1:c=0,e=31,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000265207917

由此可见,两种操作后的trace显示仅仅包含COMMIT操作,并没有类似文章中提到的对全文索引那样的维护操作。换句话说,我理解COMMIT操作自身除触发LGWR外,没有其它的耗时。如果COMMIT的时间长,一方面可能是LGWR的问题,另一方面可能是COMMIT之前的操作问题,需要具体问题具体分析。

 

转载地址:http://eiynx.baihongyu.com/

你可能感兴趣的文章
2个小练习:Javascript打印菱形和99乘法表
查看>>
MySQL 慢查询日志及相关信息
查看>>
深入理解Java内存模型(二)——重排序
查看>>
Android proguard.flags
查看>>
使用命令行启动服务
查看>>
Android实现的网络收音机示例利用Vitamio组件
查看>>
关于PyQt5响应QML发送信号的方法?
查看>>
ListView图标图像不清晰的解决方法
查看>>
我的友情链接
查看>>
我的友情链接
查看>>
MySQL中常见的函数&常见的问题
查看>>
tomcat 启动内存溢出
查看>>
iptables详解
查看>>
mysql.user表中Host为%的含义
查看>>
mysql或者mariadb多线程复制
查看>>
数据库容量规划
查看>>
mongo聚合函数count问题
查看>>
Linux:用户管理
查看>>
python 2.7 中文教程及自动化测试介绍
查看>>
ADRMS部署系列之(四)—配置ADRMS
查看>>