为档案进行碎片整理/压缩数据库的最佳方法

我们有一个用于电子邮件归档的SQL Server实例（由第三方归档软件包提供）。每隔一段时间，该软件就会被转移到一个新的空数据库中。我们过去每个季度都会做一次，但现在希望每月进行一次。每月要存档的数据量约为15-20 GB，并且大部分数据仅存储在少数几个表中（通常为2-4个）。

一旦我们转到新的数据库，旧数据库就会严格用作只读数据库。我想做的是将其优化为一个美观，紧凑的数据文件，所有表/索引都相邻并且具有很高的填充系数，并且数据文件末尾没有太多的空白空间。另外，我们在此服务器上使用标准版，但存在所有限制（否则，我将已经在使用数据压缩）。

我能想到的几种可能性：

1. 重建/重新组织索引，DBCC SHRINKFILE（好吧，这不是一个明智的选择，因为DBCC SHRINKFILE会将小便从它接触的任何部分中剔除掉，​​但出于完整性考虑，我将其包括在内。）
2. 创建一个新数据库并关闭自动统计。编写脚本并从源数据库重新创建所有表。使用bcp以集群键顺序将数据导出/导入到新数据库中。编写脚本并重新创建所有索引。使用全面扫描重新计算所有统计信息。
3. 创建一个新数据库并关闭自动统计。编写脚本并从源数据库重新创建所有表。使用SSIS或T-SQL将数据传输到新数据库。编写脚本并重新创建所有索引。使用全面扫描重新计算所有统计信息。

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

还有什么其他好的/更好的选择呢？我的担心是以逻辑上连续的方式移动数据，以保留高填充因子。

编辑：

我应该提到，大约75％的数据似乎存储在图像（LOB）列中。

为了消除文件中的物理碎片，您可以将具有拖放功能的聚簇索引移动到新文件组中。由于它们将成为RO，因此将它们的填充系数全部设为100％，因为不需要插入空间，更新导致的页面拆分。

如果您决定转至企业版，这还可以使您执行零碎的还原并使数据库快速联机。Enterprise还允许使用列存储索引，从而大大减少了此只读数据的查询时间，而后者是一个巨大的圆角。

在切换为只读之前，可以使用一次rinklefile选项，而不会出现任何严重的碎片问题，可以根据需要删除文件末尾的空间。

附带一提，只需检查您是否正在为LOBS使用最新的数据类型。即nvarchar（max）或varchar（max）代替ntext或text，varbinary（max）代替image？

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