标签：truncate acl select 经验 占用 研究 报错 兼容性问题 img
从事一年DBA工作，经验尚浅，但是遇到问题总还是能够解决，今天就谈下我遇到的一个比较奇葩的问题。
运维人员告知我下午过后ETL一直卡住没有继续，那时我以为又是什么兼容性问题引起的，就重跑一下ETL，谁知又在第五步就卡住了，好几次都这样，单独执行ETL的那个节点也执行了很长时间都没有结束，也不报错。平时只要1秒就执行完的事，而且取消也花了好多时间。中午跑的时候没有问题啊，怎么会这样。以下是该图SQL的执行过程：
刚开始查表的高水位线，没有异常，因为表入数据前都要进行truncate的，排除。
查找表坏块，没有异常，排除。
锁也排除。
查看SQL执行计划，由于有远程表，执行计划不详细，但可以肯定SELECT语句执行没有问题，SELECT语句1秒就执行完了。
查看AWR分析报告
数据库重启了，也没有用
因为一直都没有执行完，看不出毛病，除了占用时间长之外。
后来就尝试新建表代替SAP_MO_SHORT这张表，谁知道结果还是一样，刚建的新表........
顿时很无语，以这条SQL建视图很快，但建表就很慢，而且插入SAP_MO_SHORT也是一样，超级久超级慢，真的更无语了..........
马上ETL作业又要跑了，无奈之下只能把JOB停了......
排除表问题后，就研究了一下SELECT语句，但执行很快啊，中午也没有问题，于是就把关联方式改了一下
居然执行不到1秒，数据量一样......有点怀疑人生了........
标签：truncate acl select 经验 占用 研究 报错 兼容性问题 img
原文地址：http://www.cnblogs.com/guipeng/p/7442210.html
