无奈的DBA
Kaya 发表于 os2ora.com
在检查客户的代码中，有时会深刻地感觉到原代码编写者在调试代码时的无奈。
这使我想起以前调试代码时的经历。一个SQL迟迟不返回结果，一小时过去了，又一小时过去了…… 于是，想了好多调优的方法，调整系统参数，为这个SQL建立很多Index，加上各种各样的Hint ……
于是，现在在代码中看到似曾相识的/*+ index(t_xx, idx_xx) */时，有时会发自内心的笑了，同时，轻巧地把里面的+号删掉了，我就让这些个hint不起作用，不强迫CBO走index了，结果当然是CBO选择了Hash Join，而不是原代码编写者指定的Nested Loop，于是，执行速度嗖一下上去了。
还有另一个有趣的事情，对大表的操作DSS查询或DML操作，检查客户的执行计划，无一例外地没有用并行查询或者并行DML，当然，里面会用到很多类似上面的/*+ index(t_xx, idx_xx) */。于是，心里很纳闷，这样跑DSS查询或DML操作，要跑到啥时候才跑完啊？有趣的地方在于，发现了原代码编写者的一个可能的workaround，对大表进行分割分片处理，一次跑不完，我跑它个几百上千次还可以吧。很聪明的做法，不过也感觉到一阵阵深深的无奈。
不可否以地，很多客户有很复杂的业务逻辑要处理，DBA们和开发者们也很聪明地运用着Oracle的技术。编写的代码质量其实也是可圈可点的。不过，在代码实现与现实世界之间，我们却不得不面对一个折衷，优雅的代码，在糟糕的机器配置之前，只能无能为力，于是，过度的调优也就理所当然，顺理成章的成为了主流。
或许，我们的DBA们要主动地进行呐喊；或许，我们还需要有这样的职位，能够从大局上对系统进行规划，包括对系统硬件的容量规划，系统软件实现上的总体设计，最佳实践上的运用等等；或许，也应该是架构师工作的一部分？
最近评论