我正在为 SQL Server 2012 EE 制定一项计划，以正确缩小和键入（nchar 到 char 类型）一些不必要的 Unicode nvarchar(max) 字段，并希望通过一次性收缩来优化数据库大小作为停机时间的一部分。实验显示节省了 50% 的分配空间，即 11G 数据。
经过阅读和试验，很明显缩小数据库会导致索引碎片，重建索引会导致数据库扩展。真实的 Catch-22 情况。我不想在数据库中留下 50% 的可用空间，在这种情况下是 11G 的磁盘存储空间。
以下是一次性缩减的一种不错的方法，它允许以非碎片索引和最新的索引统计信息结束吗？
o 带验证的备份和重复备份。
o 删除所有索引。
o 通过复制到新表重建任何太胖的表，然后删除并重命名表。这目前运作良好。
o 缩小数据库，留出合理数量的可用空间。
o 重新创建所有被删除的索引。
o 验证数据库并检查碎片。
指出任何需要考虑的注意事项、建议、陷阱或备选方案，非常感谢。
谢谢，戴夫
我们有一个 SQL Server 2012 Enterprise 实时事务数据库，现在每月增长超过 1G，并且正在成为我们的一个大小问题。目前为23G。字符类型字段都是 Unicode，我计算出仅将 2 个这样的字段平均每个 206 个字符转换为非 Unicode 节省了 5G 空间，如果我们将其中的一些从 nchar 和 nvarchar 转换为 char 和varchar 类型。这些字段永远不需要保存不能出现在 SQL_Latin1_General_CP1_CI_AS 排序规则中的 Unicode 字符，因为它们最初以纯 ASCII 形式出现，并且始终按照协议标准这样做。
我是软件架构师和首席 C# 开发人员，尽管只是 DBA 黑客，否则我不会将我们的数据库设计为具有 Unicode 字段用于大量表，而这些表在 3 年前创建数据库时不需要这些字段的 Unicode。在我们最终转换到 AlwaysOn 环境以帮助解决各种性能和备份问题之前，我现在想纠正这个错误。
在缩减这两个或更多字段后，我们希望将数据库缩小一次，以利用节省的空间进行完整备份，并为 AlwaysOn 环境播种。
问题是——
将列从 nchar/nvarchar 类型缩减为 char/varchar 类型的最安全、最有效的转换技术是什么？特别是 当同一个表中有多个字段需要转换时。我测试了为我想从 nvarchar(max) 转换为 varchar(max) 的两个主要字段执行“添加新列、设置 new=old、删除旧的、将旧的重命名为新的”，这花了 81 分钟我们的测试服务器（4 个虚拟核心，8G 内存）在磁盘空间用完之前即使磁盘上还剩下 8G，并且数据库设置了无限大小（无法为对象'dbo.abc'分配空间。'PK_xyz'在数据库 'xxx' 中，因为 'PRIMARY' 文件组已满）。在收到磁盘警告后，我确实在完成之前删除了一个旧数据库，所以它可能没有计算那个新空间。不管它太慢了。这只是这些列中最大的两个（1260 万行），并且只占用 2% 到 3% 的 CPU 忙，因此看起来效率不高，并且如果我们要转换这两个字段甚至更不用说任何其他字段，则表示不可接受的停机时间。这两个字段的平均字段大小仅为 206 个字符或 412 个字节。我打算尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌面上有一个 FK 和索引要处理。我打算尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌面上有一个 FK 和索引要处理。我打算尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌面上有一个 FK 和索引要处理。
如果我弄清楚如何在可接受的维护窗口内有效地执行#1，那么进行一次性收缩并最终得到有组织/重建的索引和更新的统计信息的最安全做法是什么？我理解不进行常规收缩的逻辑，有时它实际上可以增加尺寸。
是否有任何第三方工具可以进行备份并将其恢复到具有修改后的字段定义或以其他方式转换某些字段类型的新数据库中？
欢迎提出任何建议和最佳实践。
谢谢，戴夫