2008年6月20日
生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。…
Execution Plan!
今天客户做系统升级，从原先的Oracle 8.1.7.4升级为Oracle 9.2.0.8 RAC，并且将应用系统从1.1版本升级为2.0版本，是一个很大的举动。 其中牵涉到数据转换，软件开发商用简单的insert into xxx select ... from yyy@dblink a, zzz b where a.ccc=b.ccc这样的语句完成数据转换，之前已经在测试环境中多次运行过，但是今天却仍然发生了问题，本来在测试环境中只需要运行100秒的转换过程在生产环境中运行了将近1个小时也没有结束，因为转换过程是大量顺序执行的insert语句，因此其中一个语句堵塞了，下面的语句也无法运行。 包括客户、软件开发商在内的十数人站在身后，为什么测试环境中运行如此快的SQL在产品环境中变得如此缓慢？该如何解决？如果在已经严格计算过的时间窗口内无法解决，是否需要回退整个升级工作？情况看上去很紧急。 因为牵涉到dblink，因此检查网络，没有发现问题。 让软件开发商在测试环境中重新跑这个SQL，速度仍然很快，检查执行计划，发现在测试环境中是Full table scan + Hash Join，而生产环境中却是Index range scan + Merge Join，检查互相Join的表，一个只有几千条记录，一个有几十万，很明显Hash Join应该是明智的选择。…