作为OLTP的应用系统，有时因为业务需要，也不得不保留很多的历史数据。如果需要频繁的访问历史数据，最直接的办法还是把历史数据移到另一服务器。以免影响业务系统的性能。但是如果对历史数据的访问只是偶尔查询一下的话，分机器或分库都会对程序的开发带来一定的影响。
上周去看了一下BMCP的项目，所用数据库是SQL2005。数据文件已经达到600G之多，所有用户表都存于主文件中。但是其中只有几个表是特别大的，记录数已经达到9位。这时表中存在冗余、字段类型选择不合适、索引建立的不合适对容量都会有很大的影响。备份数据库成了一个大难题。因为系统的需要，要尽量保留所有的数据。每天几千条甚至几万条的增加记录，磁盘存储也成了一个大难题。
大家都知道SQL2005提供了表分区的功能，除非万不得以，OLTP型的系统还是不要使用这种功能。因为分区字段可能是个很难决定的问题，如果选择不好，可能还会对系统性能产生负面作用。必要的一点就是最好选择那些值不会被修改的字段作为分区字段，非要修改的话也不能被频繁的修改。比如你可以选择把工作流的状态设置成分区字段，状态不会被频繁修改。所以不会造成记录在磁盘中多次被移动。
面对BMCP项目中的记录数超过9位数的大表，没办法只能对表进行分区了。索引也使用分区索引功能与表分区放于同一分区中，这样做的好处是当需要移除历史数据时，可以快速的进行分区切换，而不需要磁盘I/O操作。分区之后，可以把不同分区存放于不同的物理位置。但是无论怎样，数据的大小还是没有变化。用户在问再过段时间之后，要怎么保存新的数据？
很简单，压缩存储历史数据，从而减少对磁盘的占用。
前面我们已经把大表进行了分区，这时我们可以把一些比较旧的分区所对应的文件组设置成只读。这样也可以防止不小心更新了这些比较久的历史数据，然后把这些文件组中所包含的文件进行压缩。直接使用compact命令或是在资源管理器中找到相应的数据文件后在界面中进行操作。最近需要操作的分区所在的文件组还可以是可读写的，业务系统照样可以对这些记录进行修改操作。如此一般操作后，整个数据库的大小起码会减少到原大小的1/3。
但是，这也是有代价的。前面我说的前提是如果对历史数据的访问不是很频繁时比较合适，因为压缩后会对读取的性能有一定的影响。不过这也可以通过扩展磁盘来满足性能要求。而且要想对数据文件进行压缩，必须要在数据库不可用时才能进行压缩，你可以把数据库设置成离线，然后再去压缩数据文件。这时如果是多个系统在同一服务器时，一定不能在访问高峰期去做这种操作，我在前面的分离数据库后导致CPU使用率增加中已经说明，因为这种操作会清空所有的缓存计划。
我们不停的把比较久的分区所在的文件组设置成只读之后，这时就可以使用SQL2005中的部分备份功能，备份一次只读文件后。其它的可读写文件就像普通的备份操作一样，可以快速的完成备份任务。或是使用文件组/文件的备份方式，不过这种操作要求必须要保留第一次完整文件或文件组备份之后的日志备份才可以恢复确保不丢失数据。给备份的自动化带来很大的挑战，如果稍不留神把某个日志备份删除后，后续的日志备份因为日志链已经断开就不能再还原上去了。不知道各位有没有试过这种方式，有什么高招也请赐教一下。
不知道你们对海量数据的存储有没有更好的办法，请赐教！
最新评论