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

案例分析总结

 

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

2010年4月28日  笔记整理                             地点：上海

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

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

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

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

1）系统上线初期正常，稳定运行一段时间后出现故障；

2）对数据库的所有写入操作均失败：用户业务流程无法正常流转，录入数据无法保存；

3）应用系统响应慢，甚至宕机；

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

5）DB2数据库能正常连接，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/25714482/viewspace-701138/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25714482/viewspace-701138/