By kamus, on June 30th, 2008%
7月1日下午我会去朝阳区亚运村法庭领传票，这一次的开庭应该是在7月初的某一天，具体日期等领到传票再公布。 希望这是最后一次开庭。
Update@2008-7-1 第三次开庭日期：2008年7月9日上午9:00 地点：朝阳法院第三法庭（朝阳公园南路甲2号）
开庭的地点变了，不再是前两次的亚运村法庭，法院的人说，因为亚运村法庭一是太小，二是最近空调坏了。。。
Update@2008-7-9 开庭结束了，下午飞银川开始我的工作。
今天在法庭上，对方的律师当庭承认确实存在第三者，存在婚内不忠行为，我在法庭上随即质问了那如何解释之前对方父子面对CCTV的采访，均矢口否认第三者的存在这样的事实？法庭上，对方律师没有任何回答，那这里我再问一次，是今天律师您欺骗了法庭还是之前对方父子欺骗了媒体？？是谁在污蔑谁在诽谤谁在睁着眼睛说瞎话？？
最后的时候，法官问，双方愿意接受调解吗？对方说愿意，我看了一眼李律师，截然地说我们不接受，随之大旗网的代表也同样说不接受调解。调解？能怎么调解？说了，奉陪到底，那就一直到底吧。
应该说这是最后一次开庭了吧，当庭没有判决，法官说，“择日发布判决结果”。 因为法庭的规定，热心网友对于今天庭审的现场报导半途停止了，对天涯社区的这位热心朋友说一句，辛苦了，天气热，别上火
等待结果吧，期望这一切，相信这一切。对所有热心的朋友们再说一句，谢谢你们，真心的。Cheers。
By kamus, on June 20th, 2008%
生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。
By kamus, on June 20th, 2008%
今天客户做系统升级，从原先的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应该是明智的选择。
没有时间去检查为什么产品环境中Oracle选择了更差的执行计划，加Hint先去解决问题。
添加了/*+USE_HASH(C,B) ORDERED*/提示，重新检查执行计划，已经是想要的Hash Join了，再次执行SQL，40多秒就完成了数据转换。
不同的执行计划差异就是如此之大，CBO任重道远。
Update@2008-6-20
今天主要任务是检查为什么相同SQL的执行计划在不同的机器上会不一样。通过10053 trace看到的区别。
生产环境中： *********************** Table stats Table: XXX Alias: D TOTAL :: CDN: 0 NBLKS: 1 AVG_ROW_LEN: 0
. . . → Read More: Execution Plan!
