我们有一个 SQL Server 2012 Enterprise 实时事务数据库，现在每月增长超过 1G，并且对我们来说已经成为一个大小问题。目前是23G。字符类型字段都是 Unicode，我已经计算出节省了 5G 的空间，将 2 个这样的字段平均每个 206 个字符转换为非 Unicode，如果我们将它们中的一些从 nchar 和 nvarchar 转换为 char 和几乎 10G 的空间varchar 类型。这些字段永远不需要保存不能在 SQL_Latin1_General_CP1_CI_AS 归类中的 Unicode 字符，因为它们最初是作为纯 ASCII 出现的，并且将始终按照协议标准这样做。
我是软件架构师和首席 C# 开发人员，尽管我只是一个 DBA 黑客，否则我不会将我们的数据库设计为具有用于大容量表的 Unicode 字段，而在 3 年前创建数据库时，这些字段不需要 Unicode。在我们最终转换到 AlwaysOn 环境以帮助解决各种性能和备份问题之前，我现在想纠正这个错误。
在缩小这两个或更多字段后，我们希望将数据库缩小一次，以利用节省的空间进行完整备份，并为 AlwaysOn 环境做种。
问题是——
将列从 nchar/nvarchar 缩小到 char/varchar 类型的最安全和最有效的转换技术是什么？特别是 当同一个表中有多个字段需要转换时。我测试了我想从 nvarchar(max) 转换为 varchar(max) 的两个主要字段的“添加新列，设置新=旧，删除旧，重命名旧到新”，并且花了 81 分钟我们的测试服务器（4 个虚拟核心，8G 内存）在磁盘空间耗尽之前，即使磁盘上还剩下 8G，并且数据库设置了无限大小（无法为对象“dbo.abc”分配空间。“PK_xyz”在数据库 'xxx' 中，因为 'PRIMARY' 文件组已满）。在收到磁盘警告后，我确实在完成之前删除了一个旧数据库，所以它可能没有计算新空间。无论如何，它太慢了。这只是在这些列中最大的两列（12.6M 行）上，并且只运行 2% 到 3% 的 CPU 繁忙，因此看起来效率不高，并且如果我们甚至要转换这两个字段而不是任何附加字段，则表明停机时间是不可接受的。这两个字段的平均字段大小仅为 206 个字符或每个 412 个字节。我计划尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌子上有一个 FK 和索引要处理。我计划尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌子上有一个 …