开庭日三

7月1日下午我会去朝阳区亚运村法庭领传票,这一次的开庭应该是在7月初的某一天,具体日期等领到传票再公布。 希望这是最后一次开庭。 Update@2008-7-1 第三次开庭日期:2008年7月9日上午9:00 地点:朝阳法院第三法庭(朝阳公园南路甲2号) 开庭的地点变了,不再是前两次的亚运村法庭,法院的人说,因为亚运村法庭一是太小,二是最近空调坏了。。。 Update@2008-7-9 开庭结束了,下午飞银川开始我的工作。 今天在法庭上,对方的律师当庭承认确实存在第三者,存在婚内不忠行为,我在法庭上随即质问了那如何解释之前对方父子面对CCTV的采访,均矢口否认第三者的存在这样的事实?法庭上,对方律师没有任何回答,那这里我再问一次,是今天律师您欺骗了法庭还是之前对方父子欺骗了媒体??是谁在污蔑谁在诽谤谁在睁着眼睛说瞎话?? 最后的时候,法官问,双方愿意接受调解吗?对方说愿意,我看了一眼李律师,截然地说我们不接受,随之大旗网的代表也同样说不接受调解。调解?能怎么调解?说了,奉陪到底,那就一直到底吧。 应该说这是最后一次开庭了吧,当庭没有判决,法官说,“择日发布判决结果”。 因为法庭的规定,热心网友对于今天庭审的现场报导半途停止了,对天涯社区的这位热心朋友说一句,辛苦了,天气热,别上火 🙂 等待结果吧,期望这一切,相信这一切。对所有热心的朋友们再说一句,谢谢你们,真心的。Cheers。

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应该是明智的选择。 没有时间去检查为什么产品环境中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 测试环境中:…