出于存档目的对数据库进行碎片整理/压缩的最佳方法

Question

我们有一个用于电子邮件归档的 SQL Server 实例（由 3rd 方归档包提供）。每隔一段时间，软件就会滚动到一个新的空数据库。我们过去每季度进行一次，但现在我们希望每月进行一次。每月存档的数据量约为 15 - 20 GB，大部分数据仅驻留在少数表中（通常为 2 - 4 个）。

一旦我们滚动到一个新数据库，旧数据库就会严格按照只读方式使用。我想做的是将它优化成一个漂亮的、紧凑的数据文件，所有的表/索引都是连续的并且具有非常高的填充因子，并且数据文件末尾没有太多的空白空间。此外，我们在这台服务器上使用标准版，但存在所有隐含的限制（否则我已经在使用数据压缩了）。

我能想到的几种可能性：

1. REBUILD/REORGANIZE 索引、DBCC SHRINKFILE（好吧，这不是一个明智的选择，因为 DBCC SHRINKFILE 会将它接触到的任何东西都分割开来，但为了完整起见，我将其包括在内。）
2. 创建一个关闭自动统计的新数据库。编写脚本并从源数据库重新创建所有表。使用 bcp 按集群键顺序将数据导出/导入到新数据库中。编写脚本并重新创建所有索引。使用完整扫描重新计算所有统计信息。
3. 创建一个关闭自动统计的新数据库。编写脚本并从源数据库重新创建所有表。使用 SSIS 或 T-SQL 将数据传输到新数据库。编写脚本并重新创建所有索引。使用完整扫描重新计算所有统计信息。

每种情况下的最后一步都是将数据库设置为只读模式。

这样做还有哪些其他好的/更好的选择？我关心的是以这样一种方式移动数据，以保持高填充因子，并以逻辑上连续的方式。

编辑：

我应该提到大约 75% 的数据似乎存储在图像 (LOB) 列中。

Answer 1

我在使用第三方工具时遇到了类似的问题，该工具也使用图像数据类型来存储非结构化数据，我通过将列转换为使用filestream解决了这个问题。您将需要进行一些测试，以确保应用程序仍按预期运行，但这将使您能够编写自己的归档流程，以有效的方式将数据移动到归档数据库。