将 SQL Server 实例迁移到 Azure SQL 托管实例SQL Server instance migration to Azure SQL Managed Instance

适用于:是Azure SQL 托管实例 APPLIES TO: yesAzure SQL Managed Instance

本文介绍如何将 SQL Server 2005 或更高版本实例迁移到 Azure SQL 托管实例In this article, you learn about the methods for migrating a SQL Server 2005 or later version instance to Azure SQL Managed Instance. 有关迁移到单一数据库或弹性池的信息,请参阅迁移到 SQL 数据库For information on migrating to a single database or elastic pool, see Migrate to SQL Database. 有关从其他平台迁移的迁移信息,请参阅 Azure 数据库迁移指南For migration information about migrating from other platforms, see Azure Database Migration Guide.

备注

要快速入门并试用 Azure SQL 托管实例,可转到快速入门指南而不是本页。If you want to quickly start and try Azure SQL Managed Instance, you might want to go to the quickstart guide instead of this page.

概括而言,数据库迁移过程如下所示:At a high level, the database migration process looks like:

迁移过程

备注

要将单个数据库迁移到单一数据库或弹性池,请参阅将 SQL Server 数据库迁移到 Azure SQL 数据库To migrate an individual database into either a single database or an elastic pool, see Migrate a SQL Server database to Azure SQL Database.

评估 SQL 托管实例兼容性Assess SQL Managed Instance compatibility

首先,确定 SQL 托管实例是否与应用程序的数据库要求相符。First, determine whether SQL Managed Instance is compatible with the database requirements of your application. SQL 托管实例旨在轻松地直接迁移大多数使用 SQL Server 的现有应用程序。SQL Managed Instance is designed to provide easy lift and shift migration for the majority of existing applications that use SQL Server. 但是,有时可能需要用到一些目前尚不支持的功能,而实现某种解决方法的成本过高。However, you may sometimes require features or capabilities that are not yet supported and the cost of implementing a workaround is too high.

使用数据迁移助手可检测影响 Azure SQL 数据库功能的潜在兼容性问题。Use Data Migration Assistant to detect potential compatibility issues impacting database functionality on Azure SQL Database. 如果报告了某些阻塞性问题,则可能需要考虑替代选项,例如 Azure VM 上的 SQL ServerIf there are some reported blocking issues, you might need to consider an alternative option, such as SQL Server on Azure VM. 下面是一些示例:Here are some examples:

  • 需要直接访问操作系统或文件系统(例如,为了在装有 SQL Server 的同一个虚拟机上安装第三方代理或自定义代理)。If you require direct access to the operating system or file system, for instance to install third-party or custom agents on the same virtual machine with SQL Server.
  • 严重依赖于目前尚不支持的功能,如 FileStream/FileTable、PolyBase 和跨实例事务。If you have strict dependency on features that are still not supported, such as FileStream/FileTable, PolyBase, and cross-instance transactions.
  • 绝对需要保持使用特定的 SQL Server 版本(如 2012)。If you absolutely need to stay at a specific version of SQL Server (2012, for instance).
  • 计算要求比托管实例的要求低得多(如只需一个 vCore),且数据库整合不可接受。If your compute requirements are much lower than managed instance offers (one vCore, for instance), and database consolidation is not an acceptable option.

如果已解决所有已识别的迁移阻碍并继续迁移到 SQL 托管实例,请注意,某些更改可能会影响工作负载的性能:If you have resolved all identified migration blockers and are continuing the migration to SQL Managed Instance, note that some of the changes might affect performance of your workload:

  • 如果你定期使用简单/批量记录的模型或按需停止备份,则强制性完整恢复模型和定期自动备份计划可能会影响工作负荷或维护/ETL 操作的性能。Mandatory full recovery model and regular automated backup schedule might impact performance of your workload or maintenance/ETL actions if you have periodically used simple/bulk-logged model or stopped backups on demand.
  • 不同的服务器或数据库级别配置,例如跟踪标志或兼容性级别。Different server or database level configurations such as trace flags or compatibility levels.
  • 使用的新功能(例如透明数据库加密 (TDE) 或自动故障转移组)可能会影响 CPU 和 IO 使用率。New features that you are using such as Transparent Database Encryption (TDE) or auto-failover groups might impact CPU and IO usage.

即使发生严重的情况,SQL 托管实例也能保证 99.99% 的可用性,因此,无法禁用这些功能造成的开销。SQL Managed Instance guarantees 99.99% availability even in critical scenarios, so overhead caused by these features cannot be disabled. 有关详细信息,请参阅可能导致 SQL Server 和 Azure SQL 托管实例上出现不同性能的根本原因For more information, see the root causes that might cause different performance on SQL Server and Azure SQL Managed Instance.

创建性能基线Create a performance baseline

如果需要将托管实例上工作负载的性能与 SQL Server 上运行的原始工作负载的性能进行比较,需要创建用于比较的性能基线。If you need to compare the performance of your workload on a managed instance with your original workload running on SQL Server, you would need to create a performance baseline that will be used for comparison.

性能基线是一组参数,例如平均/最大 CPU 使用率、平均/最大磁盘 IO 延迟、吞吐量、IOPS、平均/最大页生存期、平均/最大 tempdb 大小。Performance baseline is a set of parameters such as average/max CPU usage, average/max disk IO latency, throughput, IOPS, average/max page life expectancy, and average max size of tempdb. 迁移后,你希望获得相似甚至更好的参数,因此,测量并记录这些参数的基线值非常重要。You would like to have similar or even better parameters after migration, so it is important to measure and record the baseline values for these parameters. 除系统参数以外,还需要在工作负载中选择一组代表性的查询或最重要的查询,并测量最小/平均/最大持续时间,以及所选查询的 CPU 使用率。In addition to system parameters, you would need to select a set of the representative queries or the most important queries in your workload and measure min/average/max duration and CPU usage for the selected queries. 使用这些值可将托管实例上运行的工作负载的性能与源 SQL Server 实例上的原始值进行比较。These values would enable you to compare performance of workload running on the managed instance to the original values on your source SQL Server instance.

需要在 SQL Server 实例上测量的一些参数如下:Some of the parameters that you would need to measure on your SQL Server instance are:

  • 监视 SQL Server 实例上的 CPU 使用率,并记录平均和峰值 CPU 使用率。Monitor CPU usage on your SQL Server instance and record the average and peak CPU usage.
  • 监视 SQL Server 实例上的内存使用量,并确定不同组件(如缓冲池、计划缓存、列存储池、内存中 OLTP 等)使用的内存量。此外,还应查找页生存期内存性能计数器的平均值和峰值。Monitor memory usage on your SQL Server instance and determine the amount of memory used by different components such as buffer pool, plan cache, column-store pool, In-Memory OLTP, etc. In addition, you should find average and peak values of the Page Life Expectancy memory performance counter.
  • 使用 sys.dm_io_virtual_file_stats 视图或性能计数器监视源 SQL Server 实例上的磁盘 IO 使用率。Monitor disk IO usage on the source SQL Server instance using sys.dm_io_virtual_file_stats view or performance counters.
  • 要从 SQL Server 2016+ 版本迁移,请检查动态管理视图或查询存储,以监视工作负载和查询性能或 SQL Server 实例。Monitor workload and query performance or your SQL Server instance by examining Dynamic Management Views or Query Store if you are migrating from a SQL Server 2016+ version. 确定工作负载中最重要查询的平均持续时间和 CPU 使用率,以将其与托管实例上运行的查询进行比较。Identify average duration and CPU usage of the most important queries in your workload to compare them with the queries that are running on the managed instance.

备注

如果你发现 SQL Server 上的工作负载出现任何问题(如 CPU 使用率高、持续存在内存压力,或者 tempdb 或参数化问题),则在创建基线和执行迁移之前,应尝试在源 SQL Server 实例上解决这些问题。If you notice any issue with your workload on SQL Server such as high CPU usage, constant memory pressure, or tempdb or parameterization issues, you should try to resolve them on your source SQL Server instance before taking the baseline and migration. 将已知问题带到任何新系统可能会导致意外的结果,并使得任何性能比较失效。Migrating known issues to any new system might cause unexpected results and invalidate any performance comparison.

作为此活动的结果,应该记录源系统上的平均和峰值 CPU、内存和 IO 使用率,以及工作负载中首要和最关键查询的平均和最大持续时间与 CPU 使用率。As an outcome of this activity, you should have documented average and peak values for CPU, memory, and IO usage on your source system, as well as average and max duration and CPU usage of the dominant and the most critical queries in your workload. 以后应使用这些值将托管实例上工作负载的性能与源 SQL Server 实例上工作负载的基线性能进行比较。You should use these values later to compare performance of your workload on a managed instance with the baseline performance of the workload on the source SQL Server instance.

部署到大小最适合的托管实例Deploy to an optimally sized managed instance

SQL 托管实例是为要迁移到云中的本地工作负载量身定制的。SQL Managed Instance is tailored for on-premises workloads that are planning to move to the cloud. 它引入了一个新的购买模型,这让你在为工作负荷选择适当的资源级别时更具灵活性。It introduces a new purchasing model that provides greater flexibility in selecting the right level of resources for your workloads. 在本地环境中,你可能习惯于使用物理核心和 IO 带宽来调整这些工作负荷的大小。In the on-premises world, you are probably accustomed to sizing these workloads by using physical cores and IO bandwidth. 托管实例的购买模型基于虚拟核心 (vCore),而且可以单独提供更多存储和 IO 资源。The purchasing model for managed instance is based upon virtual cores, or "vCores", with additional storage and IO available separately. 借助 vCore 模型可以更方便地根据当前在本地使用的计算资源,来了解云中的计算要求。The vCore model is a simpler way to understand your compute requirements in the cloud versus what you use on-premises today. 使用此新模型可以适当地调整云中目标环境的大小。This new model enables you to right-size your destination environment in the cloud. 下面介绍了一些可帮助你选择适当服务层级和特征的常规指导:Some general guidelines that might help you to choose the right service tier and characteristics are described here:

  • 根据基线 CPU 使用率,可以预配一个与 SQL Server 上使用的核心数匹配的托管实例,但请注意,可能需要缩放 CPU 特征才能匹配安装了托管实例的 VM 的特征Based on the baseline CPU usage, you can provision a managed instance that matches the number of cores that you are using on SQL Server, having in mind that CPU characteristics might need to be scaled to match VM characteristics where the managed instance is installed.
  • 根据基线内存使用率选择具有匹配内存的服务层级Based on the baseline memory usage, choose the service tier that has matching memory. 无法直接选择内存量,因此,需要选择 vCore 数目与内存匹配(例如,在 Gen5 中为 5.1 GB/vCore)的托管实例。The amount of memory cannot be directly chosen, so you would need to select the managed instance with the amount of vCores that has matching memory (for example, 5.1 GB/vCore in Gen5).
  • 根据文件子系统的基线 IO 延迟,在“常规用途”(延迟大于 5 毫秒)与“业务关键”(延迟小于 3 毫秒)服务层级之间进行选择。Based on the baseline IO latency of the file subsystem, choose between the General Purpose (latency greater than 5 ms) and Business Critical (latency less than 3 ms) service tiers.
  • 根据基线吞吐量预先分配数据或日志文件的大小,以获得预期的 IO 性能。Based on baseline throughput, pre-allocate the size of data or log files to get expected IO performance.

可在部署时选择计算和存储资源,稍后再使用 Azure 门户对其进行更改,而不必让应用程序关闭:You can choose compute and storage resources at deployment time and then change it afterward without introducing downtime for your application using the Azure portal:

托管实例大小调整

若要了解如何创建 VNet 基础结构和托管实例,请参阅创建托管实例To learn how to create the VNet infrastructure and a managed instance, see Create a managed instance.

重要

请务必根据托管实例 VNet 要求保留目标 VNet 和子网。It is important to keep your destination VNet and subnet in accordance with managed instance VNet requirements. 任何不兼容性问题都可能导致无法创建新实例或使用已创建的实例。Any incompatibility can prevent you from creating new instances or using those that you already created. 详细了解如何新建网络和配置现有网络。Learn more about creating new and configuring existing networks.

选择迁移方法,然后迁移Select a migration method and migrate

SQL 托管实例面向需要从本地或 Azure VM 数据库实现迁移大量数据库的用户方案。SQL Managed Instance targets user scenarios requiring mass database migration from on-premises or Azure VM database implementations. 如果需要直接迁移定期使用实例级功能和/或跨数据库功能的应用程序的后端,则托管实例是最佳选择。They are the optimal choice when you need to lift and shift the back end of the applications that regularly use instance level and/or cross-database functionalities. 若采用此方案,可将整个实例转移到 Azure 中对应的环境,而无需重新构建应用程序。If this is your scenario, you can move an entire instance to a corresponding environment in Azure without the need to re-architect your applications.

若要转移 SQL 实例,需要认真规划:To move SQL instances, you need to plan carefully:

  • 迁移需要并置的所有数据库(在同一个实例上运行的数据库)。The migration of all databases that need to be collocated (ones running on the same instance).
  • 迁移应用程序依赖的实例级对象,包括登录名、凭据、SQL 代理作业和操作员,以及服务器级触发器。The migration of instance-level objects that your application depends on, including logins, credentials, SQL Agent jobs and operators, and server-level triggers.

SQL 托管实例是一项托管服务,可便于将一些常规 DBA 活动委托给平台,就像平台中已内置这些活动一样。SQL Managed Instance is a managed service that allows you to delegate some of the regular DBA activities to the platform as they are built in. 因此,不需要迁移某些实例级数据,例如日常备份的维护作业或 Always On 配置,因为系统中内置了高可用性Therefore, some instance-level data does not need to be migrated, such as maintenance jobs for regular backups or Always On configuration, as high availability is built in.

SQL 托管实例支持以下数据库迁移选项(目前仅支持这些迁移方法):SQL Managed Instance supports the following database migration options (currently these are the only supported migration methods):

  • Azure 数据库迁移服务 - 几乎无需停机即可实现迁移。Azure Database Migration Service - migration with near-zero downtime.
  • 本机 RESTORE DATABASE FROM URL - 使用来自 SQL Server 的本机备份,且需要停机一段时间。Native RESTORE DATABASE FROM URL - uses native backups from SQL Server and requires some downtime.

Azure 数据库迁移服务Azure Database Migration Service

Azure 数据库迁移服务是一项完全托管的服务,旨在实现在最短的停机时间内从多个数据库源无缝迁移到 Azure 数据平台。Azure Database Migration Service is a fully managed service designed to enable seamless migrations from multiple database sources to Azure data platforms with minimal downtime. 此服务简化了将现有第三方和 SQL Server 数据库移到 Azure 所需执行的任务。This service streamlines the tasks required to move existing third-party and SQL Server databases to Azure. 公共预览版中的部署选项包括 Azure SQL 数据库中的数据库和 Azure 虚拟机中的 SQL Server 数据库。Deployment options at public preview include databases in Azure SQL Database and SQL Server databases in an Azure virtual machine. 数据库迁移服务是迁移企业工作负载的建议方法。Database Migration Service is the recommended method of migration for your enterprise workloads.

如果在本地 SQL Server 上使用 SQL Server Integration Services (SSIS),虽然数据库迁移服务尚不支持迁移存储 SSIS 包的 SSIS 目录 (SSISDB),但可在 Azure 数据工厂中预配 Azure-SSIS Integration Runtime (IR),这会在托管实例中创建新的 SSISDB,以便你将包重新部署到其中。If you use SQL Server Integration Services (SSIS) on SQL Server on premises, Database Migration Service does not yet support migrating the SSIS catalog (SSISDB) that stores SSIS packages, but you can provision Azure-SSIS Integration Runtime (IR) in Azure Data Factory, which will create a new SSISDB in a managed instance so you can redeploy your packages to it. 请参阅在 Azure 数据工厂中创建 Azure-SSIS IRSee Create Azure-SSIS IR in Azure Data Factory.

要详细了解此方案以及数据库迁移服务的配置步骤,请参阅使用数据库迁移服务将本地数据库迁移到托管实例To learn more about this scenario and configuration steps for Database Migration Service, see Migrate your on-premises database to managed instance using Database Migration Service.

从 URL 本机还原Native RESTORE from URL

还原取自 SQL Server 实例的本机备份(.bak 文件)(在 Azure 存储上提供)是 SQL 托管实例的一项重要功能,可实现快速轻松的脱机数据库迁移。RESTORE of native backups (.bak files) taken from a SQL Server instance, available on Azure Storage, is one of the key capabilities of SQL Managed Instance that enables quick and easy offline database migration.

下图高度概括了该过程:The following diagram provides a high-level overview of the process:

迁移流

下表提供了可以根据所运行的源 SQL Server 版本使用的方法的详细信息:The following table provides more information regarding the methods you can use depending on source SQL Server version you are running:

步骤Step SQL 引擎和版本SQL Engine and version 备份/还原方法Backup/restore method
将备份放入 Azure 存储Put backup to Azure Storage 早于 2012 SP1 CU2Prior to 2012 SP1 CU2 将 .bak 文件直接上传到 Azure 存储Upload .bak file directly to Azure Storage
2012 SP1 CU2 - 20162012 SP1 CU2 - 2016 使用已弃用的 WITH CREDENTIAL 语法直接备份Direct backup using deprecated WITH CREDENTIAL syntax
2016 和更高版本2016 and above 使用 WITH SAS CREDENTIAL 直接备份Direct backup using WITH SAS CREDENTIAL
从 Azure 存储还原到托管实例Restore from Azure Storage to a managed instance 使用 SAS CREDENTIAL 执行 RESTORE FROM URLRESTORE FROM URL with SAS CREDENTIAL

重要

  • 使用本机还原选项将透明数据加密保护的数据库迁移到托管实例时,需要先迁移本地或 Azure VM SQL Server 中的相应证书,再还原数据库。When you're migrating a database protected by Transparent Data Encryption to a managed instance using native restore option, the corresponding certificate from the on-premises or Azure VM SQL Server needs to be migrated before database restore. 有关详细步骤,请参阅将 TDE 证书迁移到托管实例For detailed steps, see Migrate a TDE cert to a managed instance.
  • 不支持还原系统数据库。Restore of system databases is not supported. 要迁移实例级对象(存储在 master 或 msdb 数据库中),我们建议编写 T-SQL 脚本,并在目标实例上运行这些脚本。To migrate instance-level objects (stored in master or msdb databases), we recommend to script them out and run T-SQL scripts on the destination instance.

有关介绍如何使用 SAS 凭据将数据库备份还原到托管实例的快速入门,请参阅从备份还原到托管实例For a quickstart showing how to restore a database backup to a managed instance using a SAS credential, see Restore from backup to a managed instance.

监视应用程序Monitor applications

迁移到托管实例后,应跟踪应用程序的行为和工作负载的性能。Once you have completed the migration to a managed instance, you should track the application behavior and performance of your workload. 此过程包括以下活动:This process includes the following activities:

将性能与基线进行比较Compare performance with the baseline

成功迁移后需要立即采取的第一个活动是将工作负荷的性能与基线工作负荷性能进行比较。The first activity that you would need to take immediately after successful migration is to compare the performance of the workload with the baseline workload performance. 此活动旨在确认托管实例上的工作负载性能是否符合需求。The goal of this activity is to confirm that the workload performance on your managed instance meets your needs.

在大多数情况下,将数据库迁移到托管实例会保留数据库设置及其原始兼容性级别。Database migration to a managed instance keeps database settings and its original compatibility level in majority of cases. 在可能的情况下会保留原始设置,以减少相比源 SQL Server 实例,性能出现一定的下降的风险。The original settings are preserved where possible in order to reduce the risk of some performance degradations compared to your source SQL Server instance. 如果某个用户数据库的兼容级别在迁移之前为 100 或更高,则迁移后,其兼容级别保持相同。If the compatibility level of a user database was 100 or higher before the migration, it remains the same after migration. 如果用户数据库的兼容性级别在迁移前为 90,那么在升级后的数据库中,兼容性级别设置为 100,这是托管实例支持的最低兼容性级别。If the compatibility level of a user database was 90 before migration, in the upgraded database, the compatibility level is set to 100, which is the lowest supported compatibility level in a managed instance. 系统数据库的兼容级别为 140。Compatibility level of system databases is 140. 由于迁移到托管实例实际上是迁移到最新版 SQL Server 数据库引擎,因此应注意,需要重新测试工作负载的性能,以避免出现某些意外的性能问题。Since migration to a managed instance is actually migrating to the latest version of the SQL Server database engine, you should be aware that you need to re-test performance of your workload to avoid some surprising performance issues.

作为先决条件,请确保已完成以下活动:As a prerequisite, make sure that you have completed the following activities:

备注

在许多情况下,托管实例和 SQL Server 上的性能无法做到完全一致。In many cases, you would not be able to get exactly matching performance on the managed instance and SQL Server. Azure SQL 托管实例是一个 SQL Server 数据库引擎,但托管实例上的基础结构和高可用性配置可能会造成某种差异。Azure SQL Managed Instance is a SQL Server database engine, but infrastructure and high-availability configuration on a managed instance may introduce some differences. 你可能已预料到有些查询的速度较快,而有些查询的速度可能较慢。You might expect that some queries would be faster while some others might be slower. 比较的目的是验证托管实例中的工作负载性能是否与 SQL Server 上的性能匹配(平均值),并识别性能与原始性能不匹配的任何关键查询。The goal of comparison is to verify that workload performance in the managed instance matches the performance on SQL Server (on average), and identify any critical queries with the performance that don't match your original performance.

性能比较的结果可能是:The outcome of the performance comparison might be:

  • 托管实例上的工作负载性能与 SQL Server 上的性能相当,或者优于后者。Workload performance on the managed instance is aligned or better than the workload performance on SQL Server. 如果存在这种情况,则表示迁移成功。In this case, you have successfully confirmed that migration is successful.
  • 工作负载中的大多数性能参数和查询可正常工作,但也存在一些例外和性能下降的情况。The majority of the performance parameters and the queries in the workload work fine, with some exceptions with degraded performance. 对于这种情况,需要识别差异及其重要性。In this case, you would need to identify the differences and their importance. 如果某些重要查询出现性能下降,则你应该调查是基础 SQL 计划已经更改还是查询遇到了某些资源限制。If there are some important queries with degraded performance, you should investigate whether the underlying SQL plans changed or the queries are hitting some resource limits. 这种情况的缓解措施可能是直接或使用计划指南对关键查询应用一些提示(如已更改的兼容性级别、旧版基数估算器),重新生成或创建可能会影响计划的统计信息和索引。Mitigation in this case could be to apply some hints on the critical queries (for example, changed compatibility level, legacy cardinality estimator) either directly or using plan guides, rebuild or create statistics and indexes that might affect the plans.
  • 与源 SQL Server 实例相比,托管实例上的大多数查询速度较慢。Most of the queries are slower on a managed instance compared to your source SQL Server instance. 对于这种情况,请尝试识别差异的根本原因,如即将达到资源限制(如 IO 限制、内存限制、实例日志速率限制,等等)。如果没有任何资源限制会导致出现差异,请尝试更改数据库的兼容性级别,或更改数据库设置(例如传统基数估算),然后重新开始测试。In this case, try to identify the root causes of the difference such as reaching some resource limit like IO limits, memory limit, instance log rate limit, etc. If there are no resource limits that can cause the difference, try to change the compatibility level of the database or change database settings like legacy cardinality estimation and re-start the test. 查看托管实例或查询存储视图中提供的建议来识别使性能倒退的查询。Review the recommendations provided by the managed instance or Query Store views to identify the queries that regressed performance.

重要

Azure SQL 托管实例具有内置的自动计划更正功能(默认已启用)。Azure SQL Managed Instance has a built-in automatic plan correction feature that is enabled by default. 此功能确保过去正常工作的查询在将来不会导致性能下降。This feature ensures that queries that worked fine in the paste would not degrade in the future. 在更改新设置,使托管实例能够了解基线性能和计划之前,请确保启用此功能,并使用旧设置执行工作负载足够长的时间。Make sure that this feature is enabled and that you have executed the workload long enough with the old settings before you change new settings in order to enable the managed instance to learn about the baseline performance and plans.

更改参数或升级服务层级以融合到最佳配置,直到工作负荷的性能符合需求为止。Make the change of the parameters or upgrade service tiers to converge to the optimal configuration until you get the workload performance that fits your needs.

监视性能Monitor performance

SQL 托管实例提供许多高级工具用于监视和故障排除,你应使用这些工具来监视实例的性能。SQL Managed Instance provides a lot of advanced tools for monitoring and troubleshooting, and you should use them to monitor performance on your instance. 需要监视的某些参数如下:Some of the parameters that you would need to monitor are:

  • 实例上的 CPU 使用率:确定预配的 vCore 数目是否与工作负载适当匹配。CPU usage on the instance to determine if the number of vCores that you provisioned is the right match for your workload.
  • 托管实例上的页生存期:确定是否需要增加内存Page-life expectancy on your managed instance to determine if you need additional memory.
  • 统计信息(例如 INSTANCE_LOG_GOVERNORPAGEIOLATCH):告知是否存在存储 IO 问题,尤其是在“常规用途”层级上,可能需要在其中预先分配文件才能获得更好的 IO 性能。Statistics like INSTANCE_LOG_GOVERNOR or PAGEIOLATCH that will tell if you have storage IO issues, especially on the General Purpose tier, where you might need to pre-allocate files to get better IO performance.

利用高级 PaaS 功能Leverage advanced PaaS features

进入完全托管的平台并已确认工作负载性能与 SQL Server 工作负载性能匹配后,即可使用作为服务的一部分自动提供的优势。Once you are on a fully managed platform and you have verified that workload performances are matching your SQL Server workload performance, use advantages that are provided automatically as part of the service.

即使迁移过程中未在托管实例中进行一些更改,也仍很有很可能需要在操作实例时启用一些新功能,以利用数据库引擎的最新改进功能。Even if you don't make some changes in managed instance during the migration, there are high chances that you would turn on some of the new features while you are operating your instance to take advantage of the latest database engine improvements. 一些更改只会在数据库兼容性级别已更改后才启用。Some changes are only enabled once the database compatibility level has been changed.

例如,无需在托管实例上创建备份 - 服务会自动执行备份。For instance, you don�t have to create backups on managed instance - the service performs backups for you automatically. 不再需要考虑计划、创建和管理备份。You no longer must worry about scheduling, taking, and managing backups. 在 SQL 托管实例中,可使用时点恢复 (PITR) 还原到此保留期内的任意时间点。SQL Managed Instance provides you the ability to restore to any point in time within this retention period using Point in Time Recovery (PITR). 此外,无需考虑设置高可用性,因为系统中内置了高可用性Additionally, you do not need to worry about setting up high availability, as high availability is built in.

要增强安全性,请考虑使用 Azure Active Directory 身份验证审核威胁检测行级别安全性动态数据掩码To strengthen security, consider using Azure Active Directory Authentication, auditing, threat detection, row-level security, and dynamic data masking.

除了高级管理和安全功能以外,托管实例还提供一组高级工具来帮助你监视和优化工作负载In addition to advanced management and security features, a managed instance provides a set of advanced tools that can help you to monitor and tune your workload. 托管实例中的自动优化会持续监视 SQL 计划执行统计信息的性能,并自动修复已确定的性能问题。Automatic tuning in managed instances continuously monitors performance of your SQL plan execution statistics and automatically fixes the identified performance issues.

后续步骤Next steps