当一个有性能问题的数据库摆在你的面前,作为责任人,你的处理思路是什么?

元芳曰:这种情况基本都成为了DBA的家常便饭,经常要去处理用户提交来的性能问题或者是工程人员提交上来的AWR报告,一般遇到这种情况,解决的方法有很多。
OLTP
(1)先要弄清楚数据库的类型是什么 OLTP 在线事务处理 or OLAP 在线分析系统,因为不同的数据库类型选择优化的方法也不同。例如 OLTP 强调系统的内存命中率,内存的效率决定数据库效率。
(2)如果用户的并发数很大可扩大内存的容量缓存更多的数据,还可以调整data buffer cache、shared pool、java pool、large pool的大小及PGA大小包括sort区hash区等。
(3)如果用户的在线请求数较多,可以尝试着进行SQL的变量绑定,缓解SQL的硬解析,当遇到成千上万的查询操作时,能够不经过解析过程直接使用缓存的执行计划,那效率可以提高n倍。因为硬解析会做2个分析。第一 语法分析:检查代码的语法是否正确。第二 语义分析:检查代码执行的对象是否存在及对执行对象的权限是否有。解析过程十分的耗费CPU资源。
(4)数据块的争用,是因为数据分配的不均匀造成的,可以使用hash算法平均打散到各个磁盘上来减少热块的产生
(5)还有很多系统性能间接的反应为数据库性能,例如 网络的延迟  主机的应用程序较多  没有采用中间件策略构建预处理缓冲池
OLAP
(6)如果是OLAP 在线分析系统的话,当一个用户找你来说查询一张报表很慢,你可以通过用户会话来找到查询的SQL语句,检查这条语句逻辑上效率如何,可以使用Hint方式来改变sql的执行计划,检查数据的访问方式,是走全表扫描还是走索引效率最高,调整SQL的执行计划,选择合适的索引
(7)因为SQL大多数就是集合的数学运算操作,SQL表的关联方式是不是最优化,哪种join最适合,这都是要考虑的范围
(8)当你手工测试完后,对表进行统计分析,看看优化器和你选的执行计划是不是相同的
(9)CBO模式的选择,对于需要快速响应用户的请求,可以设置成first_rows(优先把部分数据返回),对于用户响应不是很严格的业务,可以设置成all_rows(所有处理数据一次性返回)
(10)如果系统的整体开销不大,可以考虑并行技术
(11)对于OLAP系统最直接的提高数据库性能方法增加磁盘I/O和CPU吞吐量,如果硬件搞不了,可以采用数据库压缩技术,减少空间提高I/O

(12)随着数据量的增加,以前不是问题的问题也变成了问题,对于OLAP系统SQL的效率决定数据库效率




 本文转自 leonarding151CTO博客,原文链接:http://blog.51cto.com/leonarding/1065143,如需转载请自行联系原作者


上一篇:Linux中断处理驱动程序编写【转】


下一篇:python联接主流SQL的类库个人收藏