最近这里的烂系统总是问题不断，昨天又因为一些系统切换之后的性能问题加班一天（开发那边的协调力太差了）。
先是周六开发说切换后的系统性能下降（有个查询据说差了8倍），直觉告诉我很可能是执行计划的问题，但10G都是自动收集了，为啥还会有这样的问题呢？不看环境想也是白想，于是就有了第二天的加班（周末啊！大晴天啊！）。
一大早来到公司登上系统，晕，一点压力都没有，让开发的尝试重新执行那些出问题的应用，结果告诉我准备些什么什么东西（这一等我一天都没看到他们说出了问题的应用）。那就等前台业务量上来吧，等他们说有人反映还是慢的时候，我还是啥都没看到，因为他们说慢的时间已经把自己的应用执行完了。无奈之极，指望不上他们自己来吧，先把statspack打开（AWR还不熟而且没配EM），然后就是无奈的等待。
期间发生了件很让人气恼的事情，还好我最近心情不错，没有上火。先是开发的头儿让重新统计一下数据库信息，虽然建议不能说是错的，但从当初导入导出参数设置来看，统计信息在导入时已经有了，而且看系统视图也证明了这一点，我要求最好先重现应用然后做跟踪，那白痴非要重新统计，靠，统计就统计呗，正在做统计时候还好像自己很懂的样子，我心说你连oracle怎么收集统计信息都没搞清楚。收集完让前台再试，没效果，不说话了（我心说你让他们试的时候告诉我一声啊，靠，随你的便了，懒着争，玩我的开心网）。后来那个白痴发来一个用友的数据库初始化参数修改建议，又强烈要求改，我一看那个气，刚才重新收集信息还是沾边，这次的修改建议简直就是扯淡了，一看就是哪儿抄来个互联网的应用的参数修改建议，而且还tm是9I的，我说这不合理，竟然说我工作态度有问题，有点要上火，不是我的直属领导有什么资格这么说别人，算了，跟个白痴叫什么劲，你说改咱就改，改到最后一个参数10G已经没有了，我这时候告诉他，这些参数都是9i的，出了问题我不负责，然后重启了数据库，白痴不说话走开了。（事实在一次证明我对用友的看法，就是一个农民公司，水平不咋地，牛气的不得了。）
耍戏是耍戏，问题还是要帮着解决的，问题应该是出在执行效率差异上，可为啥导入后不行，重新收集后也不行呢？如果CBO真向oracle吹的那么好，自动选择的执行计划效率不应该前后差异那么大，不抓到执行语句可能很难判断原因。
要说运气还真不错，无意之间在琢磨10G收集信息时发现，新库收集统计信息的METHOD_OPT参数缺省是FOR ALL COLUMNS SIZE SKEWONLY（命令select dbms_stats.GET_PARAM('METHOD_OPT') from dual），而10G默认应该是FOR ALL COLUMNS SIZE AUTO，检查老库发现也是FOR ALL COLUMNS SIZE AUTO，难道问题在这里？对比了一下新旧库的DBA_TAB_HISTOGRAMS情况，果然发现有些区别，感觉上skewonly在收集过来的信息上没有auto的全面，而且高度和频度的使用似乎不是很正确（不过也是，用途就不太一样嘛）。修改为auto之后，重新收集统计信息，问题解决。
其实一直不喜欢用CBO，现在这里用的都是10G，不多琢磨琢磨不行喽。
对于这次的问题我很无奈的，应该说运气还是不错。不过开发那边的水平确实不怎么样，特别是那个头儿，感觉从管理到技术要嘛没嘛，最可悲是没有城府，听说在以前的企业口碑也很差，不知道怎么混过来的。要这么下去这里的业务开发水平不可能上去。现在的职务没人家高，也就不多说什么了，还好现在自己的领导是个比较明事理而且很有技术水平的一个人，以后自己这边要干的事还很多，趁着还年轻得多挑战挑战自己。
阅读(1754) | 评论(0) | 转发(0) |
