http://www.dbform.com 面朝大海，春暖花开 Tue, 01 Jul 2008 08:48:45 +0000 http://backend.userland.com/rss092 en 7月1日下午我会去朝阳区亚运村法庭领传票，这一次的开庭应该是在7月初的某一天，具体日期等领到传票再公布。 希望这是最后一次开庭。 Update@2008-7-1 第三次开庭日期：2008年7月9日上午9:00 地点：朝阳法院第三法庭（朝阳公园南路甲2号） 开庭的地点变了，不再是前两次的亚运村法庭，法院的人说，因为亚运村法庭一是太小，二是最近空调坏了。。。 http://www.dbform.com/html/2008/496.html 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 生日快乐。 http://www.dbform.com/html/2008/495.html 今天客户做系统升级，从原先的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 ... http://www.dbform.com/html/2008/494.html 很早之前记录过一个问题 - oracle可执行文件s位导致的Cluster资源组无法正常启动的问题解决。 今天在另外一个客户处又出现了同样的问题，解决方法一样，但是问题现象却不一样，着实折腾了很久。问题现象是，启动数据库没有任何报错，启动监听也没有任何问题，lsnrctl services命令显示一切正常，但是在远程客户端通过监听登陆数据库，第一次会报Oracle not available的错误，之后再次尝试会报TNS-12516错误, "TNS:listener could not find instance with matching protocol stack"，此时再次检查lsnrctl services，会发现监听的状态变为blocked。 同样是使用tar包安装的Oracle9i软件，同样是在Solaris 9中，似乎这是Solaris系统中tar命令的一个毛病。 最后执行chmod解决问题。 chmod u+s,g+s $ORACLE_HOME/bin/oracle http://www.dbform.com/html/2008/493.html 英文版地址：SQL Server 2008 Compared to Oracle Database 11g 中文版地址：SQL Server 2008与Oracle Database 11g相比较 计划找个时间批驳一下。:D http://www.dbform.com/html/2008/492.html 多次尝试，总算把自己的Windows XP SP2升级到了SP3，在升级过程中碰到了“Access is denied”报错，每次尝试都是升级到一半报错，之后Windows又会回滚所有的改动，然后再重启机器，简直是噩梦一般的体验。 如果在升级Windows XP Service Pack 3的过程中你也碰到了同样的报错，首先要确认是不是错在注册表更新这一步上，检查SP3的升级log，在Windows的安装目录下可以找到svcpack.log这个文件，查看最后的报错信息，如果找到诸如“DoRegistryUpdates failed”这样的报错，那么恭喜你，你通过下面的方法可以解决问题了。 1723.172: DoRegistryUpdates:UpdSpInstallFromInfSection Failed for ProductInstall.GlobalRegistryChanges.Install error: 0x5 1723.172: INF_REGISTRY Failed 1723.172: DoInstallation:DoRegistryUpdates failed 1728.625: Unregistration of sprecovr successful 1729.047: Access is denied. 1884.422: Message displayed to the user: Access is denied. 在微软官方站点上的技术文章949377中提到了这个问题，但是提供了三种解决方法。 方法一：下载完全版的Windows XP Service Pack 3安装程序，一个有316 MB的庞然大物，然而该方法无效。 方法二：重启机器，禁用所有的杀毒软件和防间谍软件，再次重新安装SP3，此方法也同样无效。 方法三：重设注册表和文件权限，重新安装SP3，有效！ 方法三比较复杂，简单描述一下。 1. 首先要下载Subinacl.exe程序，该程序用来修改注册表权限设置。 2. 打开记事本，将以下代码copy进去，然后将新文件保存为Reset.cmd。 cd /d "%ProgramFiles%\Windows Resource Kits\Tools" subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f ... http://www.dbform.com/html/2008/491.html 如果基于Veritas SF V4.1 MP2来安装Oracle 9.2.0.6 RAC for Solaris，不能完全按照Veritas官方文档“VERITAS Storage FoundationTM 4.1 for OracleRAC Installation and Configuration Guide”中提到的更新VCSIPC library的方法。 在文档中提到： For a 32-bit version: $ cp /opt/VRTSvcs/rac/lib/libskgxp92_32.so $ORACLE_HOME/lib/libskgxp9.so For 64-bit version: $ cp /opt/VRTSvcs/rac/lib/libskgxp92_64.so $ORACLE_HOME/lib/libskgxp9.so 但是实际上如果这样做的话，可能会在启动数据库以后在/var/adm/messages收到如下的警告信息，该警告信息会重复打印到终端窗口，比较烦人。 Jun 14 02:51:27 xxdb-server2 oracle[23169]: [ID 939233 user.alert] VCSIPC for Oracle: Minor version mismatch: oracle 4, ipc library 2, Jun 14 02:51:27 xxdb-server2 ... http://www.dbform.com/html/2008/490.html 创造吉尼斯世界记录。体验更好的互联网。听上去很不错吧！您只需要在下载日下载Firefox 3就可以──就是这么简单。我们不会要求您表演杂技或者在脸上放30把勺子，没有那么困难，不过倒也是非常有趣的事情。 http://www.dbform.com/html/2008/488.html http://www.dbform.com/html/2008/487.html 2008-5-27的开庭没有决定性意义的进展，法官又给了一个月的举证期。 而下一次开庭的时间会是在举证期之后，所以推测是2008-6-27前后，但是还不确定，法院会另行通知确切的开庭日。 感谢大家持续的关心，也感谢你们提供的所有帮助。正常的生活还会继续，一个月以后再见。 :) Update@2008-05-30 谢谢《王刚讲故事》的记者，你们是迄今为止我看到的唯一客观讲述了整个事情的朋友。 http://www.dbform.com/html/2008/486.html