数据库调优的三板斧[已结贴]

gszoracle

前面这么多招，何止三板斧，LZ可以总结了。

jacalwu

kelsoncong 发表于 2012-7-1 21:06
你是建立的日分区？

对

jacalwu

gszoracle 发表于 2012-7-1 21:40
实际系统中总有那么一些数据不能及时到达，事后要往历史中补，对应用带来冲击，请问有无可行的策略或手段

那会儿整的是些日志类的数据，延后不会太多。当时是在流程上动给处理这种延后。 数据加载到的table实际上是一个staging table，每月头的batch 会对上月的数据进行汇总，时间trunc 到HH24.  

lsh0159

有一次一个业务查询需要对将近3万个客户进行一个查询，每个客户的查询结果又分别调用4个函数计算数值，这样一个查询下来就要进行10万多次的函数调用，我感觉这里肯定对性能有影响，后来写了一个存储过程通过游标的方式进行逐一的计算，将函数的功能放在了游标的计算中，这样速度有了一些提高。不知别人是否有遇到过类似情况，频繁的调用函数对速度有多大影响，这样解决是否是合理的，是否还有其他好的方式，多谢！

leonarding

虫兄 斧头 蛮快的嘛

leonarding

看了2段了 分区表 还是蛮好用的

jimn1982

finalarrow 发表于 2012-6-25 13:54
调优开发不努力参与，只靠DBA，真是本末倒置。

支持。

jimn1982

kelsoncong 发表于 2012-6-25 16:27
具体是什么bug，什么情况下会发生？压缩表我在生产环境下用过不少啊，还是比较稳定的

表压缩我不一定能提高查询的性能吧

kelsoncong

jimn1982 发表于 2012-7-2 15:38
表压缩我不一定能提高查询的性能吧

呵呵，调优的工作中基本没有绝对的事情，这个要看具体场景的。
如果你的表有良好的索引，压缩表意义可能不太大，压缩表的作用原理是通过降低表所占用的IO，来大幅减少全表扫描的IO，从而获得更好的性能。

gszoracle

我也有一贴入围！