SQL Server中的历史表

Question

我已经在一个项目上工作了一段时间。该项目已经发布并处于生产模式。

我们现在已经注意到，其中一个存储产品事件的表正在快速增长，它每月产生大约650万行给出/需要几十万行。这当然是数据库占用了大量的硬盘空间它不会变小，大小约12GB，我们正在走出太空。

我想到了每晚运行脚本以保持少量历史记录行的想法，但这当然不会释放hdd-space，这里我需要缩小数据库文件。已经在网上阅读了有关数据文件缩小的内容。

为了一个人不应该这样做而获得利弊。历史表的处理是否可以通过其他方式完成，还是应该在维护计划中运行删除脚本，每周/月运行一次维护计划中的收缩作业？

我现在有一个维护计划： - 重组指数（每周3次） - 更新静态（每周3次） - 在某些表中清除旧的不需要的行。 （每晚）

它自己有超过14 000个单位的系统每分钟或2分钟进行选择/写入，它有时可能非常慢，而且一些sql-questions似乎得到命令超时（30s）。

Answer 1

您还可以选择进行表格分区。您可以将多个文件组分配给不同的磁盘，并将这些资源分配给表。 SQL将根据您指定的值执行水平表分区。

这是SQL表分区的良好概述： http://databases.about.com/od/sqlserver/a/partitioning.htm

如果您的表也主动插入和删除了数据 - 您将在truncate而不是delete上获得更好的性能。唯一不同的是不记录truncate操作，因此您无法回滚该语句。

希望这有帮助

Answer 2

将DB文件大小保持在数据的稳态大小。不要进入收缩 - 生长周期。就这样。收缩应该是一次性清理。

如果删除行不能为您提供空间，则缩小也不会。你需要重新组织或重建。

Answer 3

数据存档可能很棘手。您可以将历史记录复制到另一个数据库（可能在另一台服务器上），这有助于解决您的硬盘空间问题。但即使没有谈论您决定使用旧数据做什么，一旦从表中删除它，您就不必缩小数据库。该空间将在数据库文件中释放，您可以将其重用于该表中的传入记录。您不想缩小的主要原因是，当它需要空间时，您最终会再次扩展该文件，这将导致碎片和性能问题。此外，您将拥有一堆不必要的IO来缩小和扩展文件，重新组织/重建这些碎片索引等。

所以我会说保留数据库文件，并尝试将其保持为相同的大小，只需删除并添加记录到该大表。如果它继续增长，因为你继续添加超过删除的数量，那么你需要找出另一种解决方案，例如为更多数据文件添加额外的硬盘。