销售电话: 1-800-867-1380

计划 Azure SQL Database 迁移项目

更新时间: 2014年4月

本主题介绍了作为 Microsoft Azure SQL Database 迁移项目的一部分,计划并实施将内部 SQL Server 数据库迁移到 的最佳做法。本主题涵盖以下问题:

  1. 了解数据库迁移

  2. 在其中设置数据库迁移的项目目标的分析

  3. 规划和设计开发测试稳定化部署阶段管理数据迁移子项目。

作者:Shaun Tinline-Jones
供稿人:Steve Howard
审校:Shawn Hernan

数据库迁移是较大解决方案迁移项目的子项目。应用程序和数据库迁移项目之间通常存在一些集成点和依赖关系。但是,数据库迁移通常可以并行执行而很少有瓶颈。

考虑 Azure SQL Database 迁移项目的方法时应记住以下三个方面:

  • 项目的生命周期在本质上应是灵活和周而复始的。基于早期研究创建初始计划。在规划新一轮回期间,基于以前轮回中完成的研究调整计划。

  • 数据库的大小和复杂性及其关联的应用程序在以下方面影响迁移项目:

    • 数据库的复杂性决定了迁移数据库所需的工程量。

    • 数据库大小(它所含的数据量)决定了填充新数据库并从内部数据库切换到 Azure SQL Database 中托管的数据库所用的时间。

  • 将数据库迁移到新平台通常需要进行一些数据库更改,这些更改可能影响使用该数据库的其他解决方案层。迁移项目必须针对所有受影响的层协调开发工作并统一部署所有已更改的组件。

要迁移的每个数据库可以归入按大小和复杂性划分的四个象限之一。数据库所属的象限可以帮助你了解将数据库迁移到 Azure SQL Database 所需的项目范围并为迁移选择合适的机制。这些象限为:

项目大小和复杂性象限

大型数据库需要更长的时间切换到 Azure SQL Database,因为需要更多的时间在 Internet 上传输数据。数据库越复杂意味着可能需要更多的更改,从而导致工程量加大。

了解源数据库的大小和复杂性是设置迁移项目目标的关键因素。

在分析阶段,设置项目的目标和构想。整体项目目标必须包含要迁移的数据库的目标。

所有数据库必须满足业务要求,如可用性、恢复、响应时间和遵守安全和隐私规则的要求。将数据库迁移到 Azure SQL Database 时,配置数据库服务以便满足这些业务要求或协商 Azure SQL Database 可满足的一组新要求。你还可能需要更改你的管理流程。例如,如果当前正在采用每晚执行数据库备份,可能需要改用 Azure SQL Database 支持的数据库复制或数据层应用程序导出功能。

业务要求不能通过分析现有的数据库和应用程序代码来获得。你必须收集利益相关者和管理员的要求并审查流程文档(如服务级别协议)。

与数据库迁移有关的 迁移项目目标必须满足数据库的业务要求并反映数据库的大小和复杂性。与简单数据库相比,迁移复杂数据库需要更大的工程量。通过将初始项目限制为迁移内部数据库中使用的功能,可以降低迁移复杂数据库项目的风险。可以在后续项目中整合 Azure SQL Database 特有的功能。

分析阶段为规划和设计阶段提供更高层面的指导。在分析阶段审查可能影响迁移的各种问题很重要,但是在此阶段不要过多关注细节。第一轮规划和设计阶段必须深入考虑细节问题以形成更精细的设计和计划。设置一个反馈流程,根据早期规划和设计工作的成果来调整构想和范围文档。

评估 Azure SQL Database 迁移项目的复杂性是指确定完成成功迁移所需的更改量。Azure SQL Database 迁移项目在不同阶段需要越来越精确评估迁移导致的工程更改量大小。初始的一般评估应体现在项目目标定义和启动项目的决定中。它也是早期项目规划和设计工作的基础。后来在项目中做更多深入研究的成果应体现在越来越详细的项目计划、设计以及可能对项目目标的调整上。

作为迁移项目的一部分,需要解决 Azure SQL Database 不支持的功能的所有依赖关系问题。初步确定这些依赖关系时无需访问生产系统,通过比较有关 Azure SQL Database 支持的功能的现有文档和数据库设计文档或应用程序规范即可确定依赖关系。也可以由熟悉数据库和应用程序设计的人审查该文档。接着,使用 Azure SQL Database 迁移向导之类的工具可以确定某些类别的依赖关系。

很多内部数据库可能与数据库外部的服务具有依赖关系。例如,参与复制拓扑、SQL Server Integration Services 提取过程或重复执行的、由 SQL Server 代理管理的维护任务。迁移项目必须包括更改对任意这类服务的依赖关系所需的成本和开发时间。消除对不支持 Azure SQL Database 的任意服务的依赖关系。由于 Azure SQL Database 和 SQL Server 之间的体系结构差异,你可能需要更改不支持 Azure SQL Database 的其他系统。

此外,内部数据库可能具有 Transact-SQL 中不支持的 Azure SQL Database 对象。访问数据库的应用程序、数据库对象(如存储过程或触发器)中的代码也可能使用 Azure SQL Database 不支持的语法元素。

通过就以下方面所述的问题审查数据库和应用程序设计或代码,可以初步评估数据库的复杂性:

将数据库迁移到 Azure SQL Database 通常需要更改使用数据库的应用程序和系统。

首先,你必须执行使应用程序在 Azure SQL Database 环境中高效运行所需的更改。Azure SQL Database 是位于数据中心外部的 Web 服务。这意味着,一些当数据库服务器与应用程序服务器位于同一机架时影响很小的数据库最佳做法在将数据库迁移到 Azure SQL Database 时变得举足轻重了。将 Azure SQL Database 中的每个数据库跨多个服务器组成群集以提高总体可用性。但是,某些操作或你当前的服务器故障可能导致一个暂时性故障转移事件,该事件将关闭所有打开的连接并回滚其活动事务。这使得你的应用程序具有稳健的重试逻辑很重要,该逻辑将在应用程序遇到断开连接错误时重新启动事务。

有关支持良好性能所需的应用程序更改的详细信息,请参阅针对 Azure SQL Database 的性能注意事项

以下文档中讨论了在 Azure SQL Database 中高效运行所需的其他应用程序更改:

你还必须对应用程序进行相应的更改,以便适应对数据库的所有更改。例如,如果从数据库中删除一个用户定义的聚合,则必须更改运行引用该聚合的 Transact-SQL 语句的所有应用程序。

应在复杂性评估过程中开始规划和设计工作。这一阶段的关键在于对以下两节中涉及的问题进行越来越深入的研究:

确定需要更改的功能后,在项目早期阶段初步估计执行这些更改所需的工作量。应在项目每个后续轮回中更全面审查数据库以确定所有更改并更详细阐述所需的更改范围。设置反馈流程,以便调整项目目标和范围,反映在规划和设计期间所做的更详细研究的成果。第一个轮回不需要访问生产环境,但需要比较准确地了解生产环境中的各个组件。

你可以通过使用 Azure SQL Database 迁移向导并比较内部 SQL Server 和 Azure SQL Database 的差异来完成初始规划。这些内容将在相应的标题下进行深入地讨论。SQL Server Data Tools (SSDT) 可能是此阶段的有用工具,特别是数据层的应用程序生命周期管理 (ALM) 包含使用此工具或数据库对象脚本时。该工作量比使用 Azure SQL Database 迁移向导时多一点,但不是太繁重。它为常见的 Visual Studio 生产力功能带来便利,如双击一个警告可直接进入出错行。

你可以使用一些工具检查对问题(如 Transact-SQL 支持)的评估:

  • 你可以将 Azure SQL Database 迁移向导连接到内部数据库的测试或生产副本并生成必须更改才能在 Azure SQL Database 上运行的对象报告。有关详细信息,请参阅操作方法:使用 SQL Database 迁移向导

  • 如果数据层应用程序 (DAC) 支持内部数据库中的所有对象,可以提取 DAC 包并执行以下操作之一:

    • 通过 Azure SQL Database 兼容性评估服务运行 DAC 包,以获取所需更改的报告(当前在测试版中)。

    • 导入 DAC 包以在 SQL Server Data Tools 中创建数据库项目,并将项目目标设置为 Azure SQL Database。

    • 有关详细信息,请参阅操作方法:使用 DAC 包将数据库迁移到 Azure SQL Database

尽管评估工具可以帮助识别 Azure SQL Database 中不支持的功能,但是它们并不能指出可用于完成相同功能的替代功能。项目规划人员必须了解功能的业务用途并设计也支持这些业务用途的替代功能。应根据开发和部署替代功能的成本评估结果确定是否继续,而不要仅因为缺乏功能支持就放弃使用 Azure SQL Database。

避免包括非迁移目标,尤其是对于复杂的迁移。增加复杂性是迁移项目失败的常见原因。通常要考虑是否希望利用向外扩展数据库模型。只有必要时才这样做,例如:

  • 你正在迁移比 Azure SQL Database 支持的最大大小大的数据库。

  • 仅当一开始就实现多租户时,业务案例才是可行的。

  • 数据库的计算要求超过使用单个 Azure SQL Database 数据库达到的能力。

规划和设计应包括成本的考虑。成本因素需要在每个阶段和每个轮回中进行评估,是决定是否继续的重要因素。此因素可能从规划和设计中排除,因为此风险成为问题的概率比较低,但是低估成本的后果会很严重。

一个获得成功的关键因素是识别风险,并为它们分配一个概率和严重性评分。列出所有的风险,甚至是那些看起来微不足道的风险。确保所有利益相关者都认为最有可能的风险已被适当地评分。为了不使风险变为问题,确保每个可能的风险具有一个缓解计划(在规划的可接受级别)。建立一个流程,为在迁移的所有阶段发现的新风险添加计划。在最终部署阶段发现和解决的问题都作为将来项目的风险记录在案。评估应用到云环境的风险也很重要,而不仅仅评估在更熟悉的内部环境中的风险大小。

项目针对 Azure SQL Database 中支持的功能集全面审查数据库使用的所有功能,并估计转换成本和在 Azure SQL Database 中运行数据库的成本,这一点很重要。应在项目早期进行这样的审查,如果项目成本超过项目带来的好处,则应该取消项目。例如,如果项目规划人员没有意识到内部数据库使用的数据压缩不受 Azure SQL Database 支持,那么该 Azure SQL Database 迁移项目就会在后期陷入困境。这种情况会使在 Azure SQL Database 上运行数据库的预计成本发生重大变化,所以应在项目早期加以甄别。

每次规划和设计阶段的轮回应包括数据层中所需更改的更精确评估。例如,第二个轮回可能包括创建功能测试环境的事件探查器跟踪,并通过 SQLAzureMW 运行它。第三个轮回可能进展到性能测试环境,在工具箱中包含性能监视工具,以识别潜在问题、为迁移作准备。

Azure SQL Database 不支持从 SQL Server 2008 和更高版本中删除的 SQL Server 2000 和 SQL Server 2005 功能。例如,Azure SQL Database 不支持指定联接的 *= 或 =* 语法。因此,将这些数据库迁移到 Azure SQL Database 还必须解决从 SQL Server 2000 或 SQL Server 2005 升级时遇到的很多相同问题。可以使用性能监视器计数器、XEvent 和 SQL Server 升级顾问等工具查找这些依赖关系。有关研究这些问题的详细信息,请参阅升级数据库引擎

开发是执行从规划和设计阶段生成的任务的独立操作。分配了开发任务的人不应再负责执行迁移项目其他阶段中的任务。

迁移到 Azure SQL Database 的大多数数据库需要执行影响应用程序层的更改。只要更改了数据类型、返回的列数、动态 Transact-SQL 或输入参数等,将需要修改应用程序代码的数据层。即使迁移时不更改任何数据库对象,Azure SQL Database 体系结构也可能要求进行应用程序更改,如提供稳健的重试逻辑和错误处理方式。简而言之,数据库开发应与应用程序层开发整合。

可以使用支持 SQL Server 数据库的任何数据库开发工具进行数据库开发。使用具有 Azure SQL Database 逻辑的工具(如 SSDT)的一个好处是你可以将数据库项目生成目标设置为 Azure SQL Database,此时 SSDT 会在你编写代码时识别不兼容的语法。有关详细信息,请参阅 Microsoft SQL Server Data Tools。在发布 SSDT 前,开发人员已使用 Azure 仿真包并连接到 SQL Server Express。这提供了便利并具备一点脱机开发的效果,但是它仍是内部功能集,因此可能被误认为在 Azure SQL Database 中受支持。一个更高效的方法是尽可能在规划阶段识别问题,不要拖到编写代码时。如果你不使用具有 Azure SQL Database 逻辑的工具进行开发,可以尽快针对 Azure SQL Database 开始开发。使用诸如 SSDT 的脱机开发工具,多个开发人员可以同时对同一项目进行开发。SSDT 还可以与源代码控制和生成功能集成,如 Team Foundation Server 中所做的那样。如果迁移同时影响应用程序和数据库代码,数据库项目可以集成到相同的生成环境中。如果迁移同时影响应用程序和数据库,SSDT 项目可以集成到应用程序项目生成过程所在的同一解决方案。这样你可以解决在直接针对 Azure SQL Database 开发时遇到的严重连接问题。

如果迁移需要相对较少的数据模型更改,则将数据模型导入 SSDT 并开始应用更改。这样做的好处是单个开发资源可以专注于各自负责的部分开展工作,然后在生成阶段将代码进行整合。

在每个项目轮回中,开发团队必须定期给规划团队反馈并积极在规定时间内回复。要认识到与长时间编写代码而不验证相比,定期验证的风险较小,也能更快从失败中恢复。这不是一种新的范例;但是在开发基于云的解决方案时如果不遵循它将付出高昂的代价。

与迁移项目的应用程序生命周期中的其他活动类似,有些活动和目标不考虑迁移到 Azure SQL Database 的问题。对于测试来说,以下项对 Azure SQL Database 很重要,但是规划人员和开发人员通常可以忽略它们:

  • 错误处理

  • 重试逻辑

  • 响应限制

  • 部署更改

  • 向外扩展范例

  • 网络延迟效应

  • 安全性

  • Logging

请注意这些事项,因为它们是派生功能和性能测试使用案例的基础。此处有很多测试工具可用,重要的是能否隔离数据库活动。功能测试将会提高生产率,缓解开发工具不成熟带来的问题,准确地捕获 SQL Server 中未出现的 Azure SQL Database 功能。根据开发工具和生成机制,功能测试可能不产生问题,而仅作为开始耗时更多、成本更高的性能测试前的一重额外保险。

测试已迁移的解决方案应解决对内部实现影响很小的新使用案例问题。创建强制要求事务重试的错误的测试,并测试出现最大值和峰值负载时的影响。好的云解决方案可以减少故障排除的时间。这可能通过开发应用程序逻辑来实现,该逻辑记录活动并定期分析系统的当前运行状况。因为在数据库中记录操作的成本很高并且仅限于写入另一个表,因此执行数据库调用的应用程序代码应记录错误、警告和持续时间。例如,客户花费了几个小时来排除性能低下的某些服务器的故障。他们尝试利用很多工具来查找问题的根源以便解决问题。几个小时后,服务器突然开始按预期方式工作。该问题与应用程序无关,很可能是执行平台升级所致。如果将应用程序很好地设计为记录数据点且管理员定期分析解决方案的运行状况,则解决这个问题应该不用花费太大力气。他们可以为帮助中心工程师提供更好的数据,使工程师更容易找到问题根源。当然,将来使用这类数据可能包括将消费者重定向到不同的数据中心。

很容易忘记的一个事项是部署经验。测试应包括部署经验,为如何将将来的更改应用到现有环境提供线索或信心。部署新数据库、发布它和使其可供生产使用与将更改部署到现有生产环境有很大不同。对于内部部署没有专门的考虑事项,之所以提及它是出于两个原因:

  • 对内部有效的部署操作可能不适用于基于云的解决方案。

  • 将此包括在测试计划中需要做很多额外工作,而且不会马上有回报。

测试必须也参与迭代模型,这样可以将问题反馈给开发和规划团队。一开始测试可能相当粗浅,与内部测试很相似。在每次轮回中,纳入更多可识别云的测试案例。测试案例应涵盖前文“评估复杂性”一节所述文档中记录的问题。

迁移的复杂性可能是停机时间限制造成的,这提高了测试建议的部署计划的优先级。

这一阶段与常规软件开发生命周期中的目的没有什么不同。对于迁移项目,开发人员仅解决测试中的问题即可,不再对数据库的第一个迁移版本进行编码。

与稳定化类似,迁移到云的部署阶段与内部迁移项目没有什么不同。好的测试增加了在这一阶段获得成功的机会。

良好的沟通是迁移获得成功的关键因素。定期使用相应级别的消费者状态详细信息进行状态更新对于获得经验至关重要,至少可以获得迁移到云的更广业务目标的经验。

在部署阶段能否取得成功取决于前几个阶段的工作质量。如果不认真进行研究、规划、开发和测试,则部署期间遇到问题的可能性大大增加。有时部署问题很严重,导致项目停止并回滚到内部系统。在某些情况下,会使组织质疑他们能否使用基于云的系统。认真进行研究、规划、开发和测试后,部署通常会按计划顺利完成。即使遇到问题,良好的规划通常也会降低问题带来的影响。

本文是否对您有所帮助?
(1500 个剩余字符)
感谢您的反馈
显示:
© 2014 Microsoft