[原创]XX公司数据库性能优化方案_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3303 | 回复: 0   主题: [原创]XX公司数据库性能优化方案        下一篇 
jie.liang
注册用户
等级:少校
经验:1003
发帖:77
精华:0
注册:2013-10-11
状态:离线
发送短消息息给jie.liang 加好友    发送短消息息给jie.liang 发消息
发表于: IP:您无权察看 2014-4-1 16:23:42 | [全部帖] [楼主帖] 楼主

宋体" lang="EN-US">1.引言

XX公司的ORACLE数据库平时运行正常,而在特定的业务高峰期出了数据库的繁忙,日志切换频繁,buffer wait等一系列的问题。出现这些问题也是正常的,XX公司的数据库支持用户数量高,数据量大,以及事务频繁。而发生这样业务的瓶颈来自己于IO问题,而接下来我们解决的问题思路是,减少IO的查询量,减少IO之间的竞争以及建议。

宋体" lang="EN-US">2.日志问题

2.1.根据业务规划REDO大小font-family:宋体" lang="EN-US">

目前的REDO日志过小,但是有很多组,这是因为当归档有压力的情况下,就加REDO的个数,在一定的情况下可以缓解压力,但是由于REDO太小,不断的归档那就需要不断的由ORACLE ARC进程来在文件系统上建立新文件,申请新的I节点,占用blocks这非常消费时间,个人的建议增加REDO的大小,增加到4G,而不是一味的增多个数。

2.2.font-family:宋体" lang="EN-US">REDO镜像与存储

REDO压力大,还需要存储来配合,有条件的话,尽量放在最高速度的存储设备上,由于REDO文件在ORACLE本身采用镜像的技术对其进行了保护。在配置了多组REDO文件且放在不同的物理存储设备上,大可以放心,不必过份考虑REDO的安全性。

2.3.font-family:宋体" lang="EN-US">REDO单一成员的危险

REDO空间的组数为一,这个问题建议立刻解决,这个操作在业务不忙期,操作没有难度也非常安全,而如果REDO只有一组日志,而如果REDO出了问题,而数据库崩溃的话,只有采用不完且恢复了。虽然这个几率不高,希望也应该重视,至少在应用归档时,也不希望有问题。

宋体" lang="EN-US">3.大表问题

3.1.分区表解决查询问题

现在的数据库有很多大表,数据量最大的已经超过20G,索引也达到上G,这样的大表就命中索引或者进行一次运算,要扫描20G的数据量。造成大量的物理读,大规模的SELECT一样可以阻塞其他操作。所以建议采用分区表,这需要和开发人员的沟通,根据业务需求例如出一个月的报表,三个月的报表;或者根据地区,A地区,B地区等,这样可以直接读取有效的数据,减少对磁盘的压力。

3.2.分区表解决DML问题

DML操作修改和删除首先都要SELECT,然后在操作。采用分区表能更快的定位到数据块加快DML操作速度。

3.3.物化视图解决报表问题

对于报表的问题,通常会在月底或者月初出,而这一段时间又是各个数据库压力最大的时候,而如果让这些报表定时刷新,比如月报,那么我们每一天都对这个报表进行刷新,而月底的压力就被分散到三十天中进行,这样数据库月底、有初的压力就会变小。物化视图可以解决这样的问题。

3.4.分区表与索引14.0pt;font-family:宋体" lang="EN-US">

在现在有的大表中的部分索引也达到了1G,这样的全局索引在查询时,也存在大量的IO,没有显示出索引的特性。利用分区表建立本地索引,所关注的数据变少,更能加快SELECT的速度,而对于很少用的历史数据,可以删除索引,节约空间

Calibri" lang="EN-US">4.索引的问题_Toc277274374">

14.0pt;mso-fareast-font-family:Calibri;mso-bidi-font-family:Calibri" lang="EN-US">4.1.索引过多,并不一定能加快SELECT速度。14.0pt" lang="EN-US">

索引可以加快查询的速度,但这些都是有条件的,如果你所做的操作数据量比较大,那个索引并有是好的选择,虽然ORACLE基于COSTSELECT方式,可以判断是不是用索引,但是还是要依赖于执行计划是不是及的收回,和数据库的数据量是否,而没有大的改变,有很多操作直接影响到执行计划的稳定,SELECT操作也不一定走索引。

14.0pt;mso-fareast-font-family:Calibri;mso-bidi-font-family:Calibri" lang="EN-US">4.2.索引过多,严重影响DML数据14.0pt" lang="EN-US">

索引过多,每一条DML操作都要更新索引,有的表索引达到了十几个,这样一条DML操作就是等要做十次操作以上,并且产生大量的index blocks split,造成ROW lock的等待事件,导致insert,update,delete commit的速度非常慢。造成数据库阻塞交易。

Calibri" lang="EN-US">5.执行计划问题_Toc277274377">

数据库的执行计划并没有定时收集,收集和更新计划任务对数据库没有影响和害处,在9I之后。ORACLE引入基本COST的方式,用执行计划来判断SQL的执行方式,所有执行计划要定时收集。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论