(本文翻译自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