需要更改生产数据库中的列类型 (SQL Server 2005)答案

【问题标题】：Need to alter column types in production database (SQL Server 2005)需要更改生产数据库中的列类型 (SQL Server 2005)
【发布时间】：2011-03-16 17:29:10
【问题描述】：

我需要帮助编写一个 TSQL 脚本来修改两列的数据类型。

我们正在更改两列：

uniqueidentifier -> varchar(36) * * * 有一个主键约束
xml -> nvarchar(4000)

我主要关心的是脚本的生产部署...

该表格被一个每小时获得数千次点击的公共网站积极使用。因此，我们需要脚本快速运行，同时不影响前端的服务。另外，如果发生错误，我们需要能够自动回滚事务。

幸运的是，该表仅包含大约 25 行，所以我猜更新会很快。

此数据库是 SQL Server 2005。

（仅供参考 - 由于第 3 方工具与 SQL Server 的 xml 和 uniqueidentifier 类型不兼容，因此需要更改类型。我们已经在 dev 中测试了更改，并且更改没有功能问题。）

【问题讨论】：

标签： sql sql-server sql-server-2005 transactions

【解决方案1】：

正如大卫所说，在生产数据库中执行脚本而不进行备份或停止站点并不是最好的主意，也就是说，如果您只想在一个表中进行更改并减少行数，您可以准备一个脚本：

开始交易
用final创建一个新表你想要的结构。
从原始表中复制数据到新表
将旧表重命名为，例如， original_name_old
将新表重命名为 original_table_name
结束交易

这将以一个名为原始表但具有您想要的新结构的表结束，此外，您使用备份名称维护原始表，因此如果您想回滚更改，您可以创建一个脚本简单地删除新表并重命名原始表。

如果表有外键，脚本会稍微复杂一些，但仍然可以不做太多工作。

【讨论】：

+1。在这种情况下，我会说这是一种可以接受的安全方式。我只是补充一点：不要忘记在新表上设置权限以匹配原始表上的权限。
@Doliveras - 他可能也需要索引，但可能不需要在 25 行表上 :)
还有我。在我打字的时候。 +1
与仅在事务中包装两个“更改表”语句相比，您的方法有什么优势吗？通过创建新表、重命名等获得什么优势？
使用此方法，您可以完整地保留原始数据的副本，以防由于某种原因需要将其回滚到原始状态。除此之外都是一样的。但考虑到您说的是生产系统，欢迎采取任何预防措施。

【解决方案2】：

因此，我们需要脚本运行速度快，不影响服务在前端。

这只是一种意见，但它基于经验：这是个坏主意。最好有一个短暂的（如果可能的话预先宣布）计划停机时间而不是冒险。

唯一的例外是，如果您真的不在乎这些表中的数据是否损坏，并且您可能会长时间停机。

在这种情况下，根据您所做的更改类型和您已经执行的测试，听起来风险非常小，因为您已经测试了更改并且应该能够做到安全，但没有任何保证。

首先，您需要制定一个备用计划，以防出现问题。 MINIMAL 合理计划的简短版本包括：

关闭网站
备份数据库
运行您的脚本
测试数据库的完整性
让网站重新上线

在网站运行时尝试进行此类更新是非常不明智的。如果出现问题，您可能会长期处于低谷状态。

一个好的计划还可以让您首先针对数据库副本和网站副本（测试/登台环境）进行测试，然后按照上述步骤进行实时服务器更新。 您已经这样做了。向你致敬！

还有更好的方法来进行此类更新，但在大多数情况下，为了安全而牺牲停机时间是不费吹灰之力的。

【讨论】：

您忘记了将数据库置于单用户模式的部分（任何重大更改都必须这样做），否则我同意。

【解决方案3】：

如果你绝对需要在现场这样做，那么你可以考虑这样做：

1) 使用新的数据类型和复制的数据构建表的离线版本。 2）在离线表上构建所有需要的键和索引。 3）在事务中交换表。 00 您可以将旧表重命名为其他名称作为紧急备份。

sp_help 'sp_rename'

但首先在类似产品的环境中测试所有这些。并确保您的备份是最新的。并且在您最不忙的时候执行此操作。

【讨论】：

如果您不关闭数据库，那么最不忙很重要。