今天凌晨4点多钟，在客户现场的负责人打电话给我，说非常奇怪，下载功能时快时慢。此下载功能非常复杂，之前一直是我优化，在半梦半醒中打开电脑，通过远程看着现场同事在PL/SQL developer中操作。运行同一条SQL，时快时慢，快的时候大概0.6s，慢的时候超过1分钟。
这条SQL有调用一个函数，功能是动态生成接近200条查询语句，SQL中都是有绑定变量的。是现场的測试环境，刚刚部署，心想应该不是数据库负载所致。
1. 抓取数据库AWR报告，全然没有压力，数据库server配置都是杠杠的。此刻心里有点乱，头一次遇到这样的问题。现场9点钟要跟客户演示，此时已经快5点钟了。
2. 神器出场，打算用10046 trace定位到究竟是那条SQL有问题，trace了多次，仅仅有一次是慢的。期间也有插曲，现场不太会用sqlplus,交互化了非常多时间。从众多的SQL中抽丝剥茧，最终定位到SQL，对照是:
SELECT DISTINCT D.ID, D.TABLE_NAME, DCT.COLUMN_NAME, GG.DATA_TYPE,
GG.TECHPARAM_NAME,DCT.SORT_NO FROM GG_CLASSIFY_TECHPARAM DCT, GG_TECHPARAM
GG, GG_CLASSIFY D, REL_OID_CLASSIFY T WHERE DCT.TECHPARAM_ID = GG.ID AND
D.ID = DCT.CLASSIFY_ID AND T.CLASSIFY_ID = D.ID
call count cpu elapsed disk query current rows
——- —— ——– ———- ———- ———- ———- ———-
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 61.00 61.04 0 25968917 0 156
——- —— ——– ———- ———- ———- ———- ———-
total 3 61.00 61.04 0 25968917 0 156
call count cpu elapsed disk query current rows
——- —— ——– ———- ———- ———- ———- ———-
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.80 0.81 0 32461 0 156
——- —— ——– ———- ———- ———- ———- ———-
total 3 0.80 0.81 0 32461 0 156
3. 分析问题，第一感觉是SQL逻辑是否有问题，可惜10046里面没有trace到运行计划，只是看逻辑读，慢的那次应该是产生了笛卡尔积。经过简单的检查，SQL逻辑没有问题，人的第一感觉不一定靠谱。
4. 我在想是什么导致运行计划不准呢，猛然想起REL_OID_CLASSIFY是全局暂时表，高速的想到一种可能，REL_OID_CLASSIFY的统计信息不准导致，通过user_tables查看这张表是没有统计信息的。那就是每次运行都动态採集啰，在Oracle
11g中运行autotrace，发现level=2,我想试试把动态採样的级别，说干就干。
SELECT /*+ dynamic_sampling(T 10) */DISTINCT D.ID, D.TABLE_NAME, DCT.COLUMN_NAME, GG.DATA_TYPE,
GG.TECHPARAM_NAME,DCT.SORT_NO FROM GG_CLASSIFY_TECHPARAM DCT, GG_TECHPARAM
GG, GG_CLASSIFY D, REL_OID_CLASSIFY T WHERE DCT.TECHPARAM_ID = GG.ID AND
D.ID = DCT.CLASSIFY_ID AND T.CLASSIFY_ID = D.ID;
发给开发者，改动相关函数。增量后，多次測试后发现问题攻克了。此时已经快7点了，天已经大亮，我有点倦意，但无法再次入睡。
总结：对于这次暂时表的问题，我想问题在于採样率低了以后造成的恶果。对于全局暂时表要注意两点，一是要锁定暂时表收集统计信息的功能，由于你收集的统计信息肯定是错的；二是使用它时最好是使用动态採用。学习知识，基础非常重要。
