使用 SSDT 将数据库迁移到 SQL Azure

(本文翻译自SSDT团队官方博客)

随着当今对云计算的兴趣日渐浓厚，将传统数据库迁移到 SQL Azure 已然成为热点话题。这是一个重大任务，在体系结构上有许多需要考虑的挑战。其中，在 SQL Azure 中不完全支持或者尚不支持 SQL Server 的某些功能，这要求您确定并解决您的数据库对这些功能的任何依赖。

如果没有此类依赖关系，则数据库管理方案大体上就是迁移数据库自身。使用 SQL 2012 中的 SSMS，您可以从数据库中提取 dacpac（仅限架构），然后将其部署到 SQL Azure；或者，如果您想要将数据与架构一起部署，则可以使用 SQL Server 2012 中新增的“将数据库部署到 SQL Azure” 功能，该功能在后台导出 dacpac 并且将其导入到 SQL Azure。您还可以使用 SSDT 仅部署架构，但是，如果您不进行任何更改，则只会增加很少的价值。在所有这些方法中一个共有的事项就是验证管道，如果它检测到 SQL Azure 兼容性问题，将会阻止部署。

如果在未进行任何更改的情况下而数据库不能部署，您可利用 SSDT 的许多功能解决这个问题。您将需要标识数据库所依赖的任何不支持的功能，然后相应对数据库的设计（以及任何受影响的应用程序）进行改编。SSDT 使您可以在数据库项目中脱机处理架构。在指定 SQL Azure 为目标平台的情况下，生成项目会突出显示任何兼容性问题，然后您可以选择处理、更正或删除不合适的对象定义。在项目生成后，您可以使用 Local DB（SSDT 随附的轻型沙箱数据库服务）对数据库进行本地部署和测试，然后将其部署到 SQL Azure 以便在云中完成您的测试。

让我们演练一个示例，看一下上述工作方式并且探讨一些有趣的选项。我们将使用 Adventure Works LT 2008 数据库，尽管它小到几分钟就可以演练完成，但具有足够多的问题可供我们很好地阐释该过程。

首先您需要使用 SQL Server 2008 或更高版本。您还需要来自 SQL Server 2012 的 SSMS 和 SSDT。或者，如果您想要跳过演练的 SSMS 部分，则可以仅下载和安装 SSDT（免费）。接下来，下载并安装 AdventureWorksLT2008 示例数据库。如果您想要将数据库部署到云，还将需要一个 SQL Azure 帐户。您可以从此处开立一个免费试用帐户。

首先，让我们看一下已下载的 Adventure Works 数据库是否与 SQL Azure 兼容。我们可尝试部署该数据库。打开 SSMS 并连接至该数据库，然后点击“任务”>“将数据库部署到 SQL Azure”。这是您可以对数据库执行的若干 DAC 相关任务之一。在 SQL Server 2012 中，SSMS 和 SSDT 支持统一的 DAC 基础结构，因此，这两个工具都可以处理由其中任何一种工具创建的 dacpac。

 

执行部署向导并且在您的 SQL Azure 帐户上挑选一个小型的 Web 版数据库  – 此时不要担心会产生成本，因为该操作将失败。

 

在您收到一个很长的错误列表时（上面的右侧），它只是来自该任务的报告并且不能以互动方式使用。但是，如果我们切换到 SSDT，就可以看到如何利用其集成的 SQL Azure 验证来帮助我们更正这些错误。稍后我们将返回到 SSMS。

首先，让我们将该数据库导入到一个 SQL Server 数据库项目中。SSDT 提供两个“导入”入口点 – 您可以在解决方案资源管理器中创建一个 SQL Server 数据库项目，然后从数据库导入它（见下文）…

 

…或者，您可以在 SQL Server 对象资源管理器 (SSOX) 中定位该数据库，然后选择“创建新项目”（见下文）。

 

上述两种方法会得到相同的结果 – 一个完整描述该 Adventure Works 数据库的项目。

项目被创建后，您需要在“项目属性”对话框的“项目设置”选项卡上将其目标平台更改为 SQL Azure。

  

更改目标平台后，每当您生成该项目时, 系统便对数据库架构进行平台验证。此时，您将获得一个较长的错误列表，与您尝试在 SSMS 中部署数据库时看到的列表相同，只有到现在您才能开始修复它们。许多错误都是系统性的 – 例如，SQL Azure 不支持扩展属性，而 Adventure Works 在此帐户中广泛使用它们来用于许多错误。双击某一错误会将您带到有问题的代码，这样您可以对其进行修复。以此方式修复这些错误是非常谨慎的，因为您可以单独查看和斟酌每个问题。尽管这是一个需要彻底完成的重要的一次性任务，但它也可能会占用很长时间。让我们看一下另一个方法，至少，它可以更快地解决其中一些问题。

您可以使用架构比较来从数据库有选择地填充项目，而不是使用导入。架构比较将比较任何两个架构，并且根据一个架构更新另一个架构。让我们使用它将 Adventure Works 数据库架构与一个空项目进行比较。如果您仅是比较然后更新目标，则架构比较在行为上与导入类似并且生成相同结果。但是，架构比较支持可能会影响结果的几种方法。您可以查看比较结果并且从更新中排除单独的操作，例如，您可以从每个对象中排除扩展属性。尽管这会比在导入后从脚本中删除它们更容易一点，但执行时间仍较长。更有趣的是，架构比较能够从比较中排除特定类型的对象并因此进行更新。让我们看一下它是如何实现的。

首先使用“SQL > 架构比较 > 新架构比较”创建一个新比较。然后打开“比较选项”对话框，在“对象类型”选项卡上，取消选中您要排除的对象类型。这使您可以执行排除操作，例如在所有对象上排除扩展属性。单击一下您就可能去除数百个错误！当然，它不需要停止使用扩展属性 - 有许多 SQL Azure 不支持并且可由架构比较排除的对象类型。您可以在下面的“选项”对话框中看到其中一些类型，在本文的末尾提供了要排除的对象的完整列表。

 

假定您需要取消选中许多对象并且您可能要重复该过程，则最好在配置对象列表后但在设置源和目标架构前保存比较结果。然后，可以将此文件用作迁移比较“配置文件”。（我建议使用该文件的副本，因为很容易就会无意中改写该文件。）现在让我们看一下如何使用我们的新文件。

首先创建一个空的数据库项目。然后，使用我们刚创建的 .scmp 文件的副本，选择 Adventure Works 数据库作为源架构，选择新项目作为目标架构，然后对这两个架构进行比较。该比较将显示您按下“更新”后将应用的一系列添加操作。（如果您在结果网格中选择某些表，而不取消选中该操作，则可以在底部显示的脚本中看到没有扩展属性。）按下“更新”，现在将填充该项目，并且没有任何支持的对象。

如果您现在将项目的目标平台设置为 SQL Azure 并且生成该项目，将会看到少得多的错误。尽管筛选出不支持的项目将会消除大多数问题，但在很少几个对象上仍有您将需要解决的一些不支持的属性。您将需要修复以下问题（尽管下面的快速修复程序将会“解决”这些问题，但在您的长期整体解决方案中需要考虑并相应调整每个更改的影响）：

• 删除不能在 SQL Azure 中使用的用户 [NT AUTHORITY\NETWORK SERVICE]。
• 删除在 UniqueIdentifier 列上使用的所有 ROWGUIDCOL。 （若要进行修复，请转到第一处出现 ROWGUIDCOL 的地方，选择该字符串并且使用查找并替换功能 (Ctrl + H)；按下“全部替换”可替换项目中所有出现 ROWGUIDCOL 的地方。）
• 删除使用的所有 NOT FOR REPLICATION。
• 从生成中删除视图 [vProductModelCatalogDescription]，因为它使用 XQuery。（将文件上的“生成操作”属性从“Build”更改为“None”，然后再次生成该项目。请注意这是如何保留定义以便在以后修复的。）
• 将 ProductModel.CatalogDescription 列的数据类型从 XML 修改为 nvarchar(max)。

此时，您将需要再次生成该项目。这将显示 dbo.BuildVersion 表的一个剩余的错误: 没有 SQL Azure 所要求的聚集索引。如果您将 SystemInformationID 列标记为主键，将会修复此问题。再次生成并且应不会有错误了。既然我们“修复”了这些问题，我们的架构转换现已完成（显然，您需要解决存储问题并且在以后从整体上处理目录说明数据）。如果您想要查看已更改的所有内容的汇总，则可以打开新的架构比较并且将该项目与您的原始数据库进行比较。

此时，您可以按下 F5，以便使用 Local DB 在本地部署和测试该架构，或者将其发布到 SQL Azure 以便进行测试。如果您不想部署来自原始数据库的数据，则您的架构迁移任务将会高效率地完成。

此时，一个替换方法是更新您的原始数据库以使其与 SQL Azure 兼容，然后使用 SSMS 和我们之前尝试的 bacpac 机制将该数据库与其数据一起部署到云。让我们单步执行该方法，因为这不仅更有趣，而且让我们可以了解全貌。

首先，将项目的目标平台重置为其原始值（承载您的 Adventure Works 数据库的 SQL Server 版本）。这确保该数据库将被正确验证并且可部署到该目标，并且还阐释如何使用切换目标平台来确保设计是非特定于平台的。

接下来，将您的已更改的架构发布回 Adventure Works 数据库。发布将更新您的原始数据库（从架构中删除若干对象并且丢失一些数据），因此，您最好对数据库的副本执行此操作。若要对某个数据库进行此类彻底的更改，您将需要覆盖默认的两个部署/更新选项：

取消选中         如果可能会出现数据丢失，则阻止增量部署
选中                 删除目标中的对象，而非项目中的对象

通过在“发布”对话框上按下“高级…”按钮，您将找到这些选项 - 下面的屏幕快照将显示设置了这些选项以便允许更改。

 

如果您在发布后打开“数据工具操作”窗口，则可以打开汇总了这些更改的预览，或者可以查看实际使用的脚本。（发布还可以让您生成一个脚本，如果您无权更新数据库，则可以将该脚本转交给 DBA。）

在 Adventure Works 数据库更新后，您应该能够将该数据库及其数据部署到 SQL Azure。返回到 SSMS 并且再次对更新的数据库尝试“将数据库部署到 SQL Azure”任务，并且现在它应该能够非常成功地工作!

摘要

将数据库迁移到云是一个重大的体系结构更改，通常要求对数据库架构进行更改；在这个迁移过程中，SSDT 和 SSMS 可提供宝贵的支持。

• SSDT 让您将数据库架构脱机导入项目，在该项目中，您可以将其更改为与 SQL Azure 兼容。
• 可以在创建项目时使用架构比较筛选出不兼容的对象。
• 将目标平台设置为 SQL Azure 将导致 SSDT 报告兼容性错误, 然后您可使用 Local DB 在本地修复和测试这些错误。
• SSDT 可以将架构部署到云或更新数据库，以便可以使用 SSMS 将它与其数据一起部署。

附录

要从比较中排除的 SQL Azure 不支持的对象：

• 聚合
• 应用程序角色
• 程序集
• 非对称密钥
• 代理优先级
• 证书
• 约定
• 默认值
• 扩展属性
• FileGroup
• FileTable
• 全文目录
• 全文索引
• 全文非索引字表
• 消息类型
• 分区函数
• 分区方案
• 队列
• 远程服务绑定
• 规则
• 序列
• 服务
• 对称密钥
• 用户定义类型 (CLR)
• XML 索引
• XML 架构集合

另请参阅以下两个链接：

• http://msdn.microsoft.com/en-us/library/ee336253.aspx
• http://msdn.microsoft.com/en-us/library/windowsazure/ee336267.aspx