云计算行业专家指出，未使用的数据(在内部部署的数据数量可以忽略不计)可能会严重影响企业采用云平台的预算。
![]()
数字化转型正在导致很多企业面临前所未有的海量数据。许多人认为，面对不断增长的数据量和更复杂的分析要求，从Microsoft Azure或AWS云平台运行SQL Server数据库是确保IT性能的优秀方法。但是，对于某些人而言，最初的希望是通过切换到云平台能够以更高的成本效益进行工作。一个重要的原因可能是尚未针对新的云计算环境预先优化数据资产。因此，只有在充分准备之后才能完成迁移。
迁移到云端就像搬入新家：当在家中查看所有物品时，很可能出现自己都不知道拥有的东西。不可避免地出现的问题是：家中的每一件物品都与新房子相关吗?或者是时候彻底清理一下杂物了?
这种方法也可以应用于将SQL Server数据库迁移到云平台中。由于云计算环境的规则与内部部署环境不同，因此在顺利进行迁移之前，应先对数据库进行适当的清理工作。为此，数据库管理员(DBA)首先必须获得所有数据库如何与连接的应用程序进行交互的概述。这使他们可以清除数据集中不必要的混乱数据，并在必要时修改代码。因此在迁移之前，应先进行包含评估和审查阶段的两步过程。
评估阶段：迁移的数据选择
云迁移失败的比较常见的原因之一是成本过高。在许多情况下，这可以归因于以下事实：尚未充分考虑新的云计算收费模式。未使用的数据量(在内部部署运营中可忽略不计)会给云平台中的预算带来极大压力，因为云计算服务的价格由CPU、存储和IOPs决定。与其相反，提前完成全面评估有助于确保尽可能高效地使用新环境。为此，需要确定所有库存数据记录，并将它们依次分配到三个类别：清理、存档、迁移。
清理
大量不再有用的垃圾数据或数据集适合在云迁移之前进行清理。这种类别的数据包括过去创建的数据，但数据质量可能很差，只是出于法律原因才需要进行存储。如果超过法律要求的时限，则可以将其删除。如果是个人数据，则还应根据GDPR法规和其他数据保护法规来考虑数据库存。
存档
在调查过程中，数据库可能还会遇到相反的情况：某些数据集虽然过时了，但其质量适合当前和未来的趋势分析。在此建议继续以只读模式使用数据。例如，如果计划迁移到Microsoft Azure，则可以使用SQL Stretch数据库将数据简单地移动到成本相对较低的存储级别。在那里，数据仍然以只读模式可用，并且可以根据需要进行检索，以用于商业智能操作，用于人工智能或机器学习功能的应用以及用于创建预测分析。
迁移
确定了需要清除和存档的数据后，便自动形成了适合迁移的数据量。尽管这些数据来自内部部署生产系统，但这并不意味着可以将其直接传输到基于云计算的生产系统。为了防止用户可能抱怨他们的报告自从迁移以来不再有意义，下一步是对这些数据进行彻底的质量检查。
检查阶段：数据库质量检查
由于在迁移过程中不应对应用程序和数据库进行任何更改，因此必须消除任何妨碍可靠性能的功能。必须进行额外的质量检查，以确保应用程序和数据库级别之间的平滑交互。因此，应该确保以下几点：
- 诸如表格、视图、触发器、存储过程和用户定义的函数(UDF)之类的对象的一致命名标准。
- 如果所包含的值均不超过32个字符，则不要使用超大的列，例如CHAR(500)。
- GUID(全局唯一标识符)不用作聚集索引。这仅适用于未扩展的小型表格。还必须检查是否将GUID用作集群主键，因为这会导致许多性能问题。
- 没有定义为最大大小的数据类型，例如NVARCHAR(MAX)。
- 没有隐式转换，因为它们会导致严重的代码问题。特别是，当使用对象关系映射(ORM)工具时，更容易发生转换问题，因为对象关系映射(ORM)通常默认情况下使用GUID作为集群索引。
此外，应再次检查查询超时的编码。如果某些查询在内部部署环境中已经发生服务器超时，则这些超时将在云中增加。为避免这种情况，应修改代码，以便与查询超时相比，它在云平台中更具弹性，并且相应地优化了关联的查询。
另一个必要但在某些情况下可能很痛苦的任务是对流行功能的评估和测试，例如创建临时表。尽管通常使用这些功能来改进编码的逻辑，但是只有少数几个功能会对性能产生积极的影响。为了避免在云平台中出现任何意外情况，最好安排对最常用的数据库功能进行测试。
可靠的文档有助于切换到云平台
总体而言，进入云平台只需要根据数据目录创建全面的文档即可。为了避免在迁移后发现应用程序和用户已经迁移进来，必须进行下一个步骤：记录哪些应用程序访问目录中记录的数据。
对于数据库来说，这似乎有些不愉快，就像搬家时必须处理长期遗忘的物品一样。为了简化文档编制过程，需要使用适当的管理工具，这些工具可以自动创建数据源的详细概述。通过这种方式，可以创建合适的条件以实现平稳迁移并有效使用云计算服务。
