如何有效地缩小某些 Unicode 字段的大小？

Question

我们有一个 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 环境做种。

问题是——

1. 将列从 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，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌子上有一个 FK 和索引要处理。我计划尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌子上有一个 FK 和索引要处理。

2. 如果我想出如何在可接受的维护窗口内有效地执行 #1，那么进行一次性收缩并最终得到有组织/重建的索引和更新的统计信息的最安全做法是什么？我理解不定期收缩的逻辑，有时它实际上可以增加尺寸。

3. 是否有任何第三方工具可以进行备份并将其恢复到具有修改过的字段定义的新数据库中或以其他方式转换某些字段类型？

欢迎任何建议和最佳实践。

谢谢，戴夫

Answer 1

关于：

我测试了我想从 nvarchar(max) 转换为 varchar(max) 的两个主要字段的“添加新列，设置新=旧，删除旧，重命名旧到新”，并且花了 81 分钟我们的测试服务器......在磁盘空间耗尽之前......它太慢了。

和

我计划尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。

一般来说，使用理想模式制作表的副本是我的首选方法。但是，如果您现在可能只有足够的空间来转换两列，您确定您有足够的空间来制作整个表的副本吗？

此外，新表只需要具有不同的名称。它不需要在不同的模式中。

由于您使用的是企业版，您是否考虑过甚至考虑过启用数据压缩？它不仅会在NCHAR/NVARCHAR字段上产生您正在寻找的效果，而且还会为其他类型的其他字段节省空间。

有两种类型的压缩：行和页。您应该阅读它们并运行存储过程来估计您的节省量。

启用压缩可以作为一项ONLINE操作完成，但可能需要一些磁盘空间。如果您没有可用空间，那么您可以考虑使用混合方法，将表的副本构建为TableNEW，并已创建聚集索引，并在启用压缩的情况下创建。然后你应该能够慢慢填充TableNEW，数据会随着它进入压缩。当然，你会想要使用 INSERT INTO...SELECT 来批量完成。直到删除原始表并对TableNEW.

• 数据压缩的主要 MSDN 文档。
• 对表或索引启用压缩
• sp_estimate_data_compression_savings（在上面直接列出的“启用压缩”文档中提到）

请记住，在某些情况下，您可能不会节省那么多空间，或者节省空间不值得增加 CPU 活动。但是，这一切都取决于很多因素，因此确实应该在您的系统上进行测试。

你总是可以采取以下方法：

1. 启用压缩，或者直接到当前表作为 ONLINE（如果有足够的空间支持它），或者到启用了压缩的单独表。
2. 如果您发现 CPU 的增长实际上超出了节省空间的好处，那么您可以选择使用常规 VARCHAR 字段再次构建表，而不进行压缩。因为已经启用了压缩，所以您现在绝对应该有空间。

但同样，就像我们所做的任何事情一样，它应该被测试。多年来，我一直听说 CPU 上的“XML 解析”是多么可怕，压缩应该是多么糟糕，但在实践中，这些担忧常常被夸大了。的唯一办法知道是在测试你的系统。（ps，以防万一不清楚是纯文本媒体，这些最终陈述并没有攻击@Kin 在他的回答中所说的关于需要小心 CPU 活动增加的内容。他是正确的，至少在某种程度上是正确的。我只是提醒大家一定要把一切都放在当前硬件和软件以及系统设置的角度来看）。