ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 案例分析总结连载:第四章

案例分析总结连载:第四章

原创 Linux操作系统 作者:db2ring 时间:2011-07-09 10:52:15 0 删除 编辑
案例分析总结

 

数据库不合理的基础设计将给性能优化带来极大的困难。大家知道,数据库设计的顺序是先逻辑设计后物理设计,但数据库上线后出现问题时,往往是物理问题先暴露出来。下面的文字是在这个优化项目中,我写的一封邮件,对有问题的物理设计所做的回顾。

2010428 笔记整理                            地点:上海

这次优化解决磁盘I/O问题的思路是,首先考虑采取并行I/O。例如,一个分区表内的几个分区分别存放在不同的表空间,在查询数据时,各个表分区所在的表空间的I/O可以并行处理,这样将大大提高效率。

除了使用并行的方法之外,还要提高磁盘的I/O吞吐量。对于该系统物理设计优化,SSDSolid-state disk)磁盘代替当前的普通硬盘是一个好办法。目前,采用SSD磁盘已是物理设计的新趋势。与普通硬盘相比,它性能大幅提高,普通硬盘无法比拟。尤其是在应用中存在大量随机I/O的时候,SSD磁盘效果更为明显,可以使OLTP应用的事务吞吐率提高10倍甚至更高。如果将SSD磁盘应用到日志设备上,可以从它的低延迟时间上,获得巨大的性能提升。在数据仓库领域,SSD对处理热数据问题非常奏效,在临时表空间的问题上更为明显。

除了以上I/O问题外,我们也采取措施应对表空间被占满的情况,增加存储是唯一的选择。这种问题在物理设计初期考虑清楚其实不难。

表空间被占满造成的故障有以下特征:

1)系统上线初期正常,稳定运行一段时间后出现故障;

2)对数据库的所有写入操作均失败:用户业务流程无法正常流转,录入数据无法保存;

3)应用系统响应慢,甚至宕机;

4)应用系统和数据库系统重启故障依然存在;

5DB2数据库能正常连接,Select语句执行正常,Insert语句执行报错。

如果发现DB2表空间满了,解决的办法有以下几种:

1.改变容器的大小

ALTER TABLESPACE TS1

RESIZE (device 'dev/y1' 2000,device '/dev/y2' 2000);

注意:只能扩大不能缩小,执行此操作后DB2需要重新组织数据,会有好几个小时DB2服务器CPU占用率在90%以上,执行此操作最好选择在系统空闲时间操作。

2.增加新的容器

ALTER TABLESPACE TS1

EXTEND (FILE '/conts/cont0' 1000,

DEVICE '/dev/rcont1' 1500,

FILE 'cont2' 1300);

3表空间设为自增长

ALTER TABLESPACE TS1

AUTORESIZE YES INCREASESIZE 512 K MAXSIZE NONE

我还在邮件中告诉小白,所讲的这些与其说是解决的办法,不如说是一种思路。有些技术人员不能熟练掌握各种监控工具,有些则是观察问题日志的能力亟待提高。平时我们应该注意整理DB2服务器的硬件配置和数据库的各项配置,还应该及时安装一些补丁。作为一名合格的DBA,需要锻炼多种能力,不但要能把问题讲明白,还要能把问题分析清楚。

小白收到信,立刻告诉我他五一后要在一个技术交流会上发言,向我求助怎么把枯燥的技术问题讲得生动些。这个问题对技术人员非常重要,我在下一章会与大家一起分享。

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24801454/viewspace-701742/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-04-26

  • 博文量
    21
  • 访问量
    13708