性能管理的许多实例已经告诉我们，系统性能缓慢危害不亚于系统直接崩溃一天，但在大型机上调整数据库却相对轻松许多，只需花很少的时间通常就能获得较大的性能提升。

随着时间的推移，厂商已经增加了许多无需用户干预的方式来执行数据库重组，使得重组变得更加容易被用户忽视，直到数据库响应慢得他们无法接受，管理员想知道为什么新数据库的响应速度没有达到他们的预期，本文将介绍重组时的注意事项，以减少让你头疼的麻烦事。

　　关于数据库优化

数据库重组修复数据存储次佳选择 - 一个和死亡、税收一样不可避免的问题，从你启动数据库的那一刻起，数据就开始不断堆积，性能也从最开始的最优状态逐渐下降，这是如何发生的？大致有以下几种途径：

数据库存储和一些数据类型成比例，和另一些不成比例增长：
我们增加新的数据类型，应用旧的（不适当的）的优化技术；
我们使用数据库的方式不同了，特别是使用新的查询模式时，它们与旧的数据存储设计不匹配；
相同磁盘上竞争相同存储的其它数据存储，导致数据库选择次佳优化存储。

随着时间的推移，这些趋势降低了应用程序的性能，在一个不断有更新的联机事务处理（OLTP）数据库中，一年时间足以引起5%到15%的性能下降，以后每年性能也会以类似的比例逐渐下降，根据以往的经验，这与是否在大型机上运行数据库没有多大的关系，其它环境也和这差不多，事实上，在诸如Prime这样的平台上，虚拟存储访问方法（VSAM）的低版本意味着每增加100个用户它的办公自动化套件可能需要多花10分钟启动，因为用户数据在磁盘上呈碎片化，除非你重组它们，但用户哪里知道重组他们的数据呢。

现在我们执行一次大型机数据库重组修复数据存储次佳选择问题，重组主要是优化它当前状态的存储，重组可以改变索引格式，让索引更少访问磁盘，从磁盘更快地加载数据，重组可以整合磁盘上的数据，以便磁盘柱面读/写头不从磁盘柱面的一端到另一端来回折腾，这和Windows系统中的磁盘碎片整理程序类似，此外，重组可以改变缓存大小，以免数据库在磁盘和内存之间频繁执行不必要的数据交换，但重组仅仅是一个时间点的改进，时间和利用将最终导致数据库性能下降。

自从我30年前作为CCA MODEL 204大型机数据库管理员首次见到重组以来，它已经有了巨大的改进，现在，大多数主流大型机数据库厂商已经实现自动化在线重组，这意味着你的大多数大型机数据库，取决于你的版本，以及你是否需要启用重组，它们都提供了自动化重组，周期大约1年一次，包括需要24/7可用的大型机数据库重组支持。

但是在执行数据库重组时也需要注意一些事情，首先，虽然许多现代数据库厂商都提供了自动化重组功能，但不能保证你的数据库就刚好具备这项功能，即使可以使用自动重组，也没有哪个厂商愿为你的系统提供特殊优化，其次，你的重组不一定会经常运行，性能一样会逐渐下降，如果经常在线运行重组，其自身引起的性能开销也很大，另外，如果厂商没有提醒你，极有可能没有启用重组功能。

关于数据库重组的思考

最好安排每年检查一次你的数据库重组功能，包括信息管理系统（IMS）和VSAM，并作出下面这些决定：

首先，确定你是在线还是离线运行重组，离线重组可能需要数据库和应用程序停机许久，当你有足够的停机时间，或停机不会引起业务受损时，离线重组才可取，同样，在线重组也会使其它进程变慢，当数据库性能处于峰值时不建议执行在线重组。

接下来确定你执行重组的频率，你应该对一年内数据库和数据存储的变化有清晰的了解，例如，有多少不同类型的索引发生了变化，有多少更新，有多少新建和修改目录元数据定义，认真检查每一个因素，然后再决定每存储1GB数据后性能的总体趋势变化，如果数据库变化较快，你应该将重组频率加快，如果变化较慢，就尽量少执行重组。

根据以往的经验，每发生1%的增长，意味着1%的下降，如果是在线重组，要确定好放在一年中的哪一天，什么时间执行，大多数大型机数据库管理员都清楚什么时候数据库最忙，什么时候最清闲，如果你重组的当口遇到了数据库事务峰值，你应该立即停止重组，重新安排别的时间执行。

例如，假设你在英国增加了一个国外子公司，新的峰值将会比美国提前5个小时抵达，按年来说也一样，例如，其它国家的年终假期和美国也不一样，因此，如果你服务于一家全球公司，需要注意各国的年终抢购时间。

最后，确定你是否需要修改数据库在磁盘上的空间分配，虽然这不是做重组决定，但它与重组有很大的关系，特别是，你数据库性能下降是因其他数据存储竞争相同空间引起的，你可以通过对你的磁盘柱面做一个简单的映射来确定 - 特别是当你使用存储区域网络时 - 显示你数据库的数据存储夹杂了多少其它数据，如IMS记录之间的空白，你应该通过重新定义数据库的物理磁盘分配来预防出现这种情况。