这是某客户关键系统的一个TOP SQL：
sql
INSERT INTO /*+ append */ TF_B_OCS_BATDEAL (...... )性能优化
SELECT F_SYS_GETSEQID(EPARCHY_CODE, 'batch_id')微信
......session
FROM TF_F_USER B并发
WHERE B.REMOVE_TAG = '0' AND USER_ID = :B1 AND B.USER_STATE_CODESET = '0' AND oracle
LENGTH(SERIAL_NUMBER) = '11' AND SERIAL_NUMBER LIKE '1%' AND app
NOT EXISTS 性能
(优化
SELECT 1spa
FROM TF_F_USER_SHARE_RELA C
WHERE B.USER_ID = C.USER_ID_B AND C.END_DATE > SYSDATE
);
根据下图sqlhc获取的信息，该SQL平均每次插入不到一条记录，每半小时执行10万次左右。
为何cpu时间消耗不多，大部分等待时间是application等待？
sqlhc里面也有交待：
这些wait class是application的具体等待事件是enq:TM - contention，也就是表锁。在AWR报告的TOP 10事件中，也出现了这个事件，并且占DB time的4.6%，可见一个SQL就对系统形成了较大的影响：
这个表锁是如何生成的？
罪魁祸首就是SQL中使用的append Hint。
append的Hint通常使用在insert select语句，插入大量结果集的时候，采用直接路径（direct path）在表的高水位线以上直接写入数据。在没有commit以前，sql会一直持有表锁。
这个Hint在数据仓库的SQL中使用较多，一次插入记录几十万以上，执行频率低。
可是，在本例OLTP系统中，频繁执行并且插入少许记录的SQL也使用了append的hint，形成的后果就是：
一、sql执行效率低，大量的表锁等待，并发越多等待越严重。
二、插入的表TF_B_OCS_BATDEAL，有大量的空间被浪费，每插入一条记录都会占用一个block。并且即便有大量记录被delete，这些高水位线如下的空闲块不会被从新使用。
解决方法：
这种频繁执行，每次插入少许记录的状况，不能使用append，必须立刻去掉这个hint。
补充：
并行DML开启时，默认启用append插入模式。
insert /*+ parallel(4) */ into xxx select ....
这个SQL默认并无开启并行DML，只是后面的select部分使用了并行，这种状况没有使用append。
alter session enable parallel dml; --启用并行DML
insert /*+ parallel(4) */ into xxx select
这时就启用了并行DML，不加append的hint，默认也是append插入模式。
本文分享自微信公众号 - 老虎刘谈oracle性能优化（sql_tigerliu）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。