云中的新 DBA - 在迁移后管理 Azure SQL 数据库New DBA in the cloud – Managing Azure SQL Database after migration

适用于:是Azure SQL 数据库 APPLIES TO: yesAzure SQL Database

从传统的自我管理、自我控制环境过渡到 PaaS 环境后,一开始我们可能有点不适应。Moving from the traditional self-managed, self-controlled environment to a PaaS environment can seem a bit overwhelming at first. 应用开发人员或 DBA(数据库管理员)希望了解该平台中可让应用程序始终保持可用性、高效性、安全性和弹性的核心功能。As an app developer or a DBA, you would want to know the core capabilities of the platform that would help you keep your application available, performant, secure and resilient - always. 本文正好介绍了这些内容。This article aims to do exactly that. 本文简要地整理了一下资源,并指导如何充分利用 Azure SQL 数据库中的单一和共用数据库的主要功能在云中管理应用程序,使应用程序保持高效运行并获得最佳效果。The article succinctly organizes resources and gives you some guidance on how to best use the key capabilities of Azure SQL Database with single and pooled databases to manage and keep your application running efficiently and achieve optimal results in the cloud. 本文主要面向:Typical audience for this article would be those who:

  • 正在评估向 Azure SQL 数据库迁移应用程序(使应用程序现代化)的人员。Are evaluating migration of their application(s) to Azure SQL Database - Modernizing your application(s).
  • 正在迁移应用程序(现行迁移方案)的人员。Are In the process of migrating their application(s) - On-going migration scenario.
  • 最近已完成“到 Azure SQL 数据库的迁移 - 云中的新 DBA”的人员。Have recently completed the migration to Azure SQL Database - New DBA in the cloud.

本文讨论 Azure SQL 数据库的一些核心特性。作为一个平台,Azure SQL 数据库非常便于你在使用单一数据库和弹性池中的共用数据库时加以利用。This article discusses some of the core characteristics of Azure SQL Database as a platform that you can readily leverage when working with single databases and pooled databases in elastic pools. 这些特征包括:They are the following:

  • 使用 Azure 门户监视数据库Monitor databases using the Azure portal
  • 业务连续性和灾难恢复 (BCDR)Business continuity and disaster recovery (BCDR)
  • 安全性与符合性Security and compliance
  • 智能数据库监视和维护Intelligent database monitoring and maintenance
  • 数据移动Data movement

使用 Azure 门户监视数据库Monitor databases using the Azure portal

Azure 门户中,可以通过选择数据库并单击“监视”图表来监视单个数据库的利用率。In the Azure portal, you can monitor an individual database’s utilization by selecting your database and clicking the Monitoring chart. 这将显示“指标”窗口,可通过单击“编辑图表”按钮来对其进行更改。This brings up a Metric window that you can change by clicking the Edit chart button. 添加以下指标:Add the following metrics:

  • CPU 百分比CPU percentage
  • DTU 百分比DTU percentage
  • 数据 IO 百分比Data IO percentage
  • 数据库大小百分比Database size percentage

添加这些指标后,可以继续在“监视”图表上查看它们,并可在“指标”窗口上查看更多详细信息。Once you've added these metrics, you can continue to view them in the Monitoring chart with more information on the Metric window. DTU 的平均利用率百分比。All four metrics show the average utilization percentage relative to the DTU of your database. 有关服务层级的详细信息,请参阅基于 DTU 的购买模型基于 vCore 的购买模型文章。See the DTU-based purchasing model and vCore-based purchasing model articles for more information about service tiers.

在服务层监视数据库性能。

还可针对性能指标配置警报。You can also configure alerts on the performance metrics. 在“指标”窗口中单击“新建预警规则”按钮。Click the New alert rule button in the Metric window. 按照向导说明来配置警报。Follow the wizard to configure your alert. 可选择在指标超出或低于特定阈值时显示警报。You have the option to alert if the metrics exceed a certain threshold or if the metric falls below a certain threshold.

例如,如果期望数据库上的工作负荷增长,可选择配置在数据库的任意性能指标达到 80% 时发出电子邮件警报。For example, if you expect the workload on your database to grow, you can choose to configure an email alert whenever your database reaches 80% on any of the performance metrics. 可以将此警报用作预警,以确定你何时需要切换到下一个更高的计算大小。You can use this as an early warning to figure out when you might have to switch to the next highest compute size.

性能指标还可以帮助你确定是否能够降级到更低的计算大小。The performance metrics can also help you determine if you are able to downgrade to a lower compute size. 假定正在使用标准 S2 数据库,所有性能指标均显示该数据库在任意给定时间的平均使用率都不超过 10%。Assume you are using a Standard S2 database and all performance metrics show that the database on average does not use more than 10% at any given time. 采用标准 S1 很可能使该数据库正常工作。It is likely that the database will work well in Standard S1. 但是,在决定转换到更低的计算大小之前,请注意出现峰值或波动情况的工作负荷。However, be aware of workloads that spike or fluctuate before making the decision to move to a lower compute size.

业务连续性和灾难恢复 (BCDR)Business continuity and disaster recovery (BCDR)

发生灾难时,可以借助业务连续性和灾难恢复功能使业务像平时一样继续。Business continuity and disaster recovery abilities enable you to continue your business, as usual, in case of a disaster. 灾难可能是数据库级别的事件(例如,某人错误地删除了某个重要表)或数据中心级别的事件(区域性灾难,例如海啸)。The disaster could be a database level event (for example, someone mistakenly drops a crucial table) or a data-center level event (regional catastrophe, for example a tsunami).

如何在 SQL 数据库中创建和管理备份How do I create and manage backups on SQL Database

不要在 Azure SQL 数据库中创建备份,因为没有这个必要。You don't create backups on Azure SQL Database and that is because you don't have to. SQL 数据库会自动备份数据库,因此我们不再需要考虑如何计划、执行和管理备份。SQL Database automatically backs up databases for you, so you no longer must worry about scheduling, taking and managing backups. 该平台每周创建完整备份,每隔几小时创建差异备份,每隔 5 分钟创建日志备份,以确保灾难恢复的有效性,并尽量减少数据丢失。The platform takes a full backup every week, differential backup every few hours and a log backup every 5 minutes to ensure the disaster recovery is efficient, and the data loss minimal. 创建数据库后,首次完整备份会立即发生。The first full backup happens as soon as you create a database. 在称为“保留期”的某段时间内,这些备份均可用,可用情况因所选服务层级而有所不同。These backups are available to you for a certain period called the "Retention Period" and varies according to the service tier you choose. 在 SQL 数据库中,可以使用时间点恢复 (PITR) 还原到此保留期内的任意时间点。SQL Database provides you the ability to restore to any point in time within this retention period using Point in Time Recovery (PITR).

服务层Service tier 保留期(天)Retention period in days
基本Basic 77
标准Standard 3535
高级Premium 3535

此外,使用长期保留 (LTR) 功能,还可将备份文件特意保留更长时间(最长达 10 年),且可在该期间任意时间点通过备份还原数据。In addition, the Long-Term Retention (LTR) feature allows you to hold onto your backup files for a much longer period specifically, for up to 10 years, and restore data from these backups at any point within that period. 此外,数据库备份保存在异地复制存储中,可确保从区域性灾难中复原。Furthermore, the database backups are kept in geo-replicated storage to ensure resilience from regional catastrophe. 还可以在保留期内的任意时间点恢复 Azure 区域中的任何备份。You can also restore these backups in any Azure region at any point of time within the retention period. 请参阅业务连续性概述See Business continuity overview.

如果发生数据中心级灾难或地区灾难,如何确保业务连续性How do I ensure business continuity in the event of a datacenter-level disaster or regional catastrophe

数据库备份存储在异地复制的存储中,确保在发生区域性灾难时,可将备份还原到另一个 Azure 区域。Because your database backups are stored in geo-replicated storage to ensure that in case of a regional disaster, you can restore the backup to another Azure region. 这称为异地还原。This is called geo-restore. 此方案的 RPO(恢复点目标)通常小于 1 小时,ERT(估计恢复时间)通常为几分钟到几小时。The RPO (Recovery Point Objective) for this is generally < 1 hour and the ERT (Estimated Recovery Time - few minutes to hours).

对于关键数据库,Azure SQL 数据库提供有效异地复制。For mission-critical databases, Azure SQL Database offers, active geo-replication. 实质上,此方案的工作原理是在另一个区域创建原始数据库的异地复制辅助副本。What this essentially does is that it creates a geo-replicated secondary copy of your original database in another region. 例如,如果数据库最初托管在 Azure 中国北部区域,而你希望在发生区域性灾难时具有复原能力。For example, if your database is initially hosted in Azure North China region and you want regional disaster resilience. 那么,可以在中国东部或其他区域创建中国北部数据库的活动异地副本。You'd create an active geo replica of the database in North China to say East China. 当中国北部发生灾难时,可以故障转移到中国东部区域。When the calamity strikes on North China, you can failover to the East China region. 最好将它们配置到自动故障转移组中,因为这样可以确保在发生灾难时数据库自动故障转移到美国东部的辅助数据库。Configuring them in an auto-failover Group is even better because this ensures that the database automatically fails over to the secondary in East US in case of a disaster. 此方案的 RPO 小于 5 秒,ERT 小于 30 秒。The RPO for this is < 5 seconds and the ERT < 30 seconds.

如果没有配置自动故障转移组,那么你的应用程序需要主动监视灾难,并启动向辅助数据库的故障转移。If an auto-failover group is not configured, then your application needs to actively monitor for a disaster and initiate a failover to the secondary. 可以在不同的 Azure 区域中最多创建 4 个此类活动异地副本。You can create up to 4 such active geo-replicas in different Azure regions. 这样,效果会更好。It gets even better. 还能以只读方式访问这些辅助活动异地副本。You can also access these secondary active geo-replicas for read-only access. 这样可以非常方便地减少异地分布式应用程序方案的延迟。This comes in very handy to reduce latency for a geo-distributed application scenario.

我的灾难恢复计划如何从本地转变为 SQL 数据库How does my disaster recovery plan change from on-premises to SQL Database

总而言之,SQL Server 设置要求使用故障转移群集、数据库镜像、事务复制或日志传送等功能来主动管理可用性,并维护和管理备份以确保业务连续性。In summary, SQL Server setup requires you to actively manage your Availability by using features such as Failover Clustering, Database Mirroring, Transaction Replication, or Log Shipping and maintain and manage backups to ensure Business Continuity. 使用 SQL 数据库时,平台会自动管理这些任务,因此,你可以专注于开发和优化数据库应用程序,而无需过多考虑灾难管理。With SQL Database, the platform manages these for you, so you can focus on developing and optimizing your database application and not worry about disaster management as much. 可以配置备份和灾难恢复计划,操作时只需在 Azure 门户中点击几下(或者使用 PowerShell API 执行几个命令)。You can have backup and disaster recovery plans configured and working with just a few clicks on the Azure portal (or a few commands using the PowerShell APIs).

若要了解有关灾难恢复的详细信息,请参阅:Azure SQL 数据库灾难恢复 101To learn more about Disaster recovery, see: Azure SQL Database Disaster Recovery 101

安全性与符合性Security and compliance

SQL 数据库严肃对待安全性和隐私性。SQL Database takes Security and Privacy very seriously. SQL 数据库中的安全性在数据库级别和平台级别实施,在划分为多个层后最好理解。Security within SQL Database is available at the database level and at the platform level and is best understood when categorized into several layers. 在每个层,可以控制和提供应用程序的最佳安全性。At each layer you get to control and provide optimal security for your application. 这些层包括:The layers are:

Azure 安全中心为 Azure、本地和其他云中运行的工作负载提供集中式安全管理。Azure Security Center offers centralized security management across workloads running in Azure, on-premises, and in other clouds. 你可以查看是否已在所有资源上配置诸如审计透明数据加密 [TDE]之类的基本 SQL 数据库保护,并根据你自己的需求创建策略。You can view whether essential SQL Database protection such as Auditing and Transparent Data Encryption [TDE] are configured on all resources, and create policies based on your own requirements.

SQL 数据库中提供哪些用户身份验证方法What user authentication methods are offered in SQL Database

SQL 数据库中提供了两种身份验证方法:There are two authentication methods offered in SQL Database:

不支持传统的 Windows 身份验证。The traditional windows authentication is not supported. Azure Active Directory (Azure AD) 是集中式的标识和访问管理服务。Azure Active Directory (Azure AD) is a centralized identity and access management service. 这意味着,为简化身份验证,凭据将在所有 Azure 服务之间共享。What this means is that the credentials are shared across all Azure services for simpler authentication. Azure AD 支持 Azure 多重身份验证,只需点击几下鼠标,Azure AD 就能与 Windows Server Active Directory 集成。Azure AD supports Azure Multi-Factor Authentication and with a few clicks Azure AD can be integrated with Windows Server Active Directory. SQL 身份验证的工作方式与以往并无不同。SQL Authentication works exactly like you've been using it in the past. 只需提供用户名/密码,就能让用户在给定服务器上的任何数据库中进行身份验证。You provide a username/password and you can authenticate users to any database on a given server. 此外,还允许 SQL 数据库和 SQL 数据仓库在 Azure AD 域中提供多重身份验证和来宾用户帐户。This also allows SQL Database and SQL Data Warehouse to offer Multi-Factor Authentication and guest user accounts within an Azure AD domain. 如果你已经有一个本地 Active Directory,则可以将该目录与 Azure Active Directory 联合在一起,以将目录扩展到 Azure。If you already have an Active Directory on-premises, you can federate the directory with Azure Active Directory to extend your directory to Azure.

如果你…If you... SQL 数据库/SQL 数据仓库SQL Database / SQL Data Warehouse
不想在 Azure 中使用 Azure Active Directory (Azure AD)Prefer not to use Azure Active Directory (Azure AD) in Azure 使用 SQL 身份验证Use SQL authentication
在本地 SQL Server 上使用 ADUsed AD on SQL Server on-premises 将 AD 与 Azure AD 联合,并使用 Azure AD 身份验证。Federate AD with Azure AD, and use Azure AD authentication. 借此,你可以使用单一登录。With this, you can use Single Sign-On.
需要强制实施多重身份验证Need to enforce Multi-Factor Authentication 使用支持多重身份验证的 Azure AD 通用身份验证Use Azure AD Universal authentication with Multi-Factor Authentication support.
有来自 Microsoft 帐户(live.com、outlook.com)或其他域 (gmail.com) 的来宾帐户Have guest accounts from Microsoft accounts (live.com, outlook.com) or other domains (gmail.com) 在利用 Azure AD B2B 协作的 SQL 数据库/数据仓库中使用 Azure AD 通用身份验证Use Azure AD Universal authentication in SQL Database/Data Warehouse, which leverages Azure AD B2B Collaboration.
使用来自联合域的 Azure AD 凭据登录到 WindowsAre logged in to Windows using your Azure AD credentials from a federated domain 使用 Azure AD 集成身份验证Use Azure AD integrated authentication.
使用来自未与 Azure 联合的域的凭据登录到 WindowsAre logged in to Windows using credentials from a domain not federated with Azure 使用 Azure AD 集成身份验证Use Azure AD integrated authentication.
具有需要连接到 SQL 数据库或 SQL 数据仓库的中间层服务Have middle-tier services which need to connect to SQL Database or SQL Data Warehouse 使用 Azure AD 集成身份验证Use Azure AD integrated authentication.

如何限制或控制对数据库的连接访问How do I limit or control connectivity access to my database

你可以自行使用多种方法来获得应用程序的最佳连接组织方式。There are multiple techniques at your disposal that you could use to attain optimal connectivity organization for your application.

  • 防火墙规则Firewall Rules
  • VNet 服务终结点VNet Service Endpoints
  • 保留 IPReserved IPs

防火墙Firewall

防火墙阻止外部实体访问你的服务器,只允许特定的实体访问你的服务器。A firewall prevents access to your server from an external entity by allowing only specific entities access to your server. 默认情况下,将拒绝与服务器内数据库的所有连接,来自其他 Azure 服务的 (optionally7) 连接除外。By default, all connections to databases inside the server are disallowed, except (optionally7) connections coming in from other Azure Services. 使用防火墙规则,可以只对批准的实体(例如开发人员计算机)开放服务器的访问,并允许该计算机的 IP 地址通过防火墙。With a firewall rule you can open access to your server only to entities (for example, a developer machine) that you approve of, by allowing that computer's IP address through the firewall. 此外,还可指定允许其访问服务器的 IP 范围。It also allows you to specify a range of IPs that you would want to allow access to the server. 例如,可以在防火墙设置页中指定范围,一次性添加组织中的多个开发人员计算机 IP 地址。For example, developer machine IP addresses in your organization can be added at once by specifying a range in the Firewall settings page.

可以在服务器级别或数据库级别创建防火墙规则。You can create firewall rules at the server level or at the database level. 可使用 Azure 门户或通过 SSMS 创建服务器级 IP 防火墙规则。Server level IP firewall rules can either be created using the Azure portal or with SSMS. 有关如何设置服务器级和数据库级防火墙规则的详细信息,请参阅:在 SQL 数据库中创建 IP 防火墙规则For learning more about how to set a server-level and database-level firewall rule, see: Create IP firewall rules in SQL Database.

服务终结点Service endpoints

默认情况下,数据库配置为“允许 Azure 服务访问服务器”- 这表示 Azure 中的所有虚拟机都可尝试连接到你的数据库。By default, your database is configured to "Allow Azure services to access server" - which means any Virtual Machine in Azure may attempt to connect to your database. 这些尝试仍需经过身份验证。These attempts still do have to get authenticated. 但是,如果不想让任何 Azure IP 都可访问数据库,则可禁用“允许 Azure 服务访问服务器”。However, if you would not like your database to be accessible by any Azure IPs, you can disable "Allow Azure services to access server". 此外,还可配置 VNet 服务终结点Additionally, you can configure VNet Service Endpoints.

通过服务终结点 (SE) 可以仅向自己在 Azure 中的专用虚拟网络公开关键 Azure 资源。Service endpoints (SE) allow you to expose your critical Azure resources only to your own private virtual network in Azure. 以此从根本上阻止了对资源的公共访问。By doing so, you essentially eliminate public access to your resources. 虚拟网络与 Azure 间的流量位于 Azure 主干网络上。The traffic between your virtual network to Azure stays on the Azure backbone network. 无 SE 时,可获得强制隧道数据包路由。Without SE you get forced-tunneling packet routing. 虚拟网络强制组织的 Internet 流量和 Azure 服务流量通过相同的路由。Your virtual network forces the internet traffic to your organization and the Azure Service traffic to go over the same route. 借助服务终结点,可优化这进程,因为数据包直接从虚拟网络流向 Azure 主干网络上的服务。With Service Endpoints, you can optimize this since the packets flow straight from your virtual network to the service on Azure backbone network.

VNet 服务终结点

保留 IPReserved IPs

另一种方法是为 VM 预配保留 IP,并在服务器防火墙设置中添加这些特定的 VM IP 地址。Another option is to provision reserved IPs for your VMs, and add those specific VM IP addresses in the server firewall settings. 通过分配保留 IP,就可以避免通过更改 IP 地址来更新防火墙规则的麻烦。By assigning reserved IPs, you save the trouble of having to update the firewall rules with changing IP addresses.

要通过哪个端口连接到 SQL 数据库What port do I connect to SQL Database on

端口 1433。Port 1433. SQL 数据库通过此端口通信。SQL Database communicates over this port. 若要从企业网络内部建立连接,必须在组织的防火墙设置中添加出站规则。To connect from within a corporate network, you have to add an outbound rule in the firewall settings of your organization. 作为一项准则,应避免在 Azure 边界外部公开端口 1433。As a guideline, avoid exposing port 1433 outside the Azure boundary.

如何监控服务器上以及 SQL 数据库中的数据库上的活动How can I monitor and regulate activity on my server and database in SQL Database

SQL 数据库审核SQL Database Auditing

使用 SQL 数据库时,可以启用“审核”以跟踪数据库事件。With SQL Database, you can turn ON Auditing to track database events. SQL 数据库审核记录数据库事件,并将事件写入 Azure 存储帐户中的审核日志文件。SQL Database Auditing records database events and writes them into an audit log file in your Azure Storage Account. 若要洞察潜在的安全和策略违规、保持合规性或实现其他类似目的,审核功能特别有用。使用审核可以定义和配置你认为需要审核的事件类别,而基于这些类别,可以获取预配置的报告和仪表板来大致了解数据库中发生的事件。Auditing is especially useful if you intend to gain insight into potential security and policy violations, maintain regulatory compliance etc. It allows you to define and configure certain categories of events that you think need auditing and based on that you can get preconfigured reports and a dashboard to get an overview of events occurring on your database. 可以在数据库级别或服务器级别应用这些审核策略。You can apply these auditing policies either at the database level or at the server level. 有关如何启用服务器/数据库审核的指南,请参阅:启用 SQL 数据库审核A guide on how to turn on auditing for your server/database, see: Enable SQL Database Auditing.

威胁检测Threat detection

使用威胁检测可以轻松地对“审核”功能发现的安全或策略违规采取措施。With threat detection, you get the ability to act upon security or policy violations discovered by Auditing very easily. 无需安全方面的专业知识即可解决系统中的潜在威胁或违规。You don’t need to be a security expert to address potential threats or violations in your system. 威胁检测还提供一些内置功能,例如 SQL 注入检测。Threat detection also has some built-in capabilities like SQL Injection detection. SQL 注入是指尝试改动或破坏数据,这是攻击数据库应用程序的一种常见手段。SQL Injection is an attempt to alter or compromise the data and a quite common way of attacking a database application in general. 威胁检测运行多组算法,这些算法可以检测潜在漏洞和 SQL 注入攻击,以及异常的数据库访问模式(如来自异常位置或不熟悉主体的访问)。Threat detection runs multiple sets of algorithms which detect potential vulnerabilities and SQL injection attacks, as well as anomalous database access patterns (such as access from an unusual location or by an unfamiliar principal). 如果在数据库中检测到威胁,安全管理人员或其他指定管理员将收到电子邮件通知。Security officers or other designated administrators receive an email notification if a threat is detected on the database. 每个通知都会提供可疑活动的详细信息,以及如何进一步调查和缓解威胁的建议。Each notification provides details of the suspicious activity and recommendations on how to further investigate and mitigate the threat. 若要了解如何启用威胁检测,请参阅:启用威胁检测To learn how to turn on Threat detection, see: Enable threat detection.

如何在 SQL 数据库中对数据采取常规保护How do I protect my data in general on SQL Database

加密是防范入侵者盗取敏感数据的强大机制。Encryption provides a strong mechanism to protect and secure your sensitive data from intruders. 如果入侵者没有解密密钥,已加密的数据对他们而言毫无用处。Your encrypted data is of no use to the intruder without the decryption key. 因此,它在 SQL 数据库内置的现有安全层之上再增加了一个保护层。Thus, it adds an extra layer of protection on top of the existing layers of security built in SQL Database. 保护 SQL 数据库中的数据时,需要考虑两个方面:There are two aspects to protecting your data in SQL Database:

  • 数据和日志文件中的静态数据Your data that is at-rest in the data and log files
  • 正在处理的数据Your data that is in-flight

在 SQL 数据库中,默认情况下,存储子系统上的数据和日志文件中的静态数据始终完全通过透明数据加密 [TDE] 进行加密。In SQL Database, by default, your data at rest in the data and log files on the storage subsystem is completely and always encrypted via Transparent Data Encryption [TDE]. 备份也会加密。Your backups are also encrypted. 使用 TDE 时,不需要在访问此数据的应用程序端进行更改。With TDE there are no changes required on your application side that is accessing this data. 顾名思义,加密和解密以透明方式进行。The encryption and decryption happen transparently; hence the name. 为了保护处理中和静态的敏感数据,SQL 数据库提供一项称作 Always Encrypted (AE) 的功能。For protecting your sensitive data in-flight and at rest, SQL Database provides a feature called Always Encrypted (AE). AE 是客户端加密的一种形式,它对数据库中的敏感列进行加密(因此,它们位于数据库管理员和未授权用户的已加密文本中)。AE is a form of client-side encryption which encrypts sensitive columns in your database (so they are in ciphertext to database administrators and unauthorized users). 服务器首先接收加密的数据。The server receives the encrypted data to begin with. Always Encrypted 的密钥也存储在客户端,因此只有授权的客户端可以解密敏感列。The key for Always Encrypted is also stored on the client side, so only authorized clients can decrypt the sensitive columns. 服务器和数据管理员无法看到敏感数据,因为加密密钥存储在客户端上。The server and data administrators cannot see the sensitive data since the encryption keys are stored on the client. AE 对表中的敏感列进行端到端加密,以防未经授权的客户端访问物理磁盘。AE encrypts sensitive columns in the table end to end, from unauthorized clients to the physical disk. AE 目前支持等式比较,因此数据库管理员可以继续查询加密列,这是其 SQL 命令一部分。AE supports equality comparisons today, so DBAs can continue to query encrypted columns as part of their SQL commands. Always Encrypted 可以与各种密钥存储选项结合使用,如 Azure Key Vault、Windows 证书存储和本地硬件安全模块。Always Encrypted can be used with a variety of key store options, such as Azure Key Vault, Windows certificate store, and local hardware security modules.

特征Characteristics Always EncryptedAlways Encrypted 透明数据加密Transparent Data Encryption
加密范围Encryption span 端到端End-to-end 静态数据At-rest data
服务器可访问敏感数据Server can access sensitive data No 是,因为加密针对静态数据Yes, since encryption is for the data at rest
允许的 T-SQL 操作Allowed T-SQL operations 等式比较Equality comparison 所有 T-SQL 外围应用可用All T-SQL surface area is available
使用此功能所要做出的应用更改App changes required to use the feature 最少Minimal 很少Very Minimal
加密粒度Encryption granularity 列级别Column level 数据库级别Database level

如何限制对数据库中敏感数据的访问How can I limit access to sensitive data in my database

每个应用程序在数据库中都有一个特定的敏感数据位,需要防止向任何人透露该位。Every application has a certain bit of sensitive data in the database that needs to be protected from being visible to everyone. 组织中的特定人员需要查看此数据,但是,其他人不应能够查看此数据。Certain personnel within the organization need to view this data, however others shouldn't be able to view this data. 一个示例是员工工资。One example is employee wages. 经理需要访问其直接下属的工资信息,但是,单个团队成员不应有权访问其同级的工资信息。A manager would need access to the wage information for their direct reports however, the individual team members shouldn't have access to the wage information of their peers. 另一种情况是数据开发人员在开发或测试阶段可能要与敏感数据(例如客户的 SSN)交互。Another scenario is data developers who might be interacting with sensitive data during development stages or testing, for example, SSNs of customers. 同样,不需要向开发人员公开此信息。This information again doesn't need to be exposed to the developer. 在此情况下,敏感数据需要掩码,或者根本不公开。In such cases, your sensitive data either needs to be masked or not be exposed at all. SQL 数据库提供以下两种方案用于防止未经授权的用户查看敏感数据:SQL Database offers two such approaches to prevent unauthorized users from being able to view sensitive data:

动态数据掩码是一种数据掩码功能,它通过掩码应用层上的非特权用户来限制敏感数据的公开。Dynamic Data Masking is a data masking feature that enables you to limit sensitive data exposure by masking it to non-privileged users on the application layer. 可以定义屏蔽规则来创建屏蔽模式(例如,只显示国家/地区 ID 号的最后 4 位数:XXX-XX-0000,并将大部分编号标记为 X),并确定哪些用户被排除在屏蔽规则之外。You define a masking rule that can create a masking pattern (for example, to only show last four digits of a national ID SSN: XXX-XX-0000 and mark most of it as Xs) and identify which users are to be excluded from the masking rule. 掩码是即时发生的,对于不同的数据类别,可以使用不同的掩码功能。The masking happens on-the-fly and there are various masking functions available for various data categories. 动态数据掩码可以自动检测数据库中的敏感数据并对其应用掩码。Dynamic data masking allows you to automatically detect sensitive data in your database and apply masking to it.

使用行级安全性可在行级别控制访问。Row Level security enables you to control access at the row level. 这意味着,可以根据执行查询的用户(组成员或执行上下文)来隐藏数据库表中的某些行。Meaning, certain rows in a database table based on the user executing the query (group membership or execution context) are hidden. 访问限制是在数据库层上完成的,而不是在应用层,以此简化你的应用逻辑。The access restriction is done on the database tier instead of in an application tier, to simplify your app logic. 首先创建筛选器谓词,过滤掉不要公开的行和安全策略,然后定义有权访问这些行的用户。You start by creating a filter predicate, filtering out rows that are not be exposed and the security policy next defining who has access to these rows. 最后,最终用户运行其查询,根据该用户的特权,他们可以或者无法查看这些受限制的行。Finally, the end user runs their query and, depending on the user's privilege, they either view those restricted rows or are unable to see them at all.

如何在云中管理加密密钥How do I manage encryption keys in the cloud

有用于 Always Encrypted(客户端加密)和透明数据加密(静态加密)的密钥管理选项。There are key management options for both Always Encrypted (client-side encryption) and Transparent Data Encryption (encryption at rest). 建议定期轮换加密密钥。It's recommended that you regularly rotate encryption keys. 轮换频率应与内部组织法规与符合性要求一致。The rotation frequency should align with both your internal organization regulations and compliance requirements.

透明数据加密 (TDE)Transparent Data Encryption (TDE)

TDE 中有一个双密钥层次结构 - 每个用户数据库中的数据都通过对称 AES-256 数据库唯一的数据库加密密钥 (DEK) 进行加密,该密钥反过来又由服务器唯一的不对称 RSA 2048 主密钥进行加密。There is a two-key hierarchy in TDE - the data in each user database is encrypted by a symmetric AES-256 database-unique database encryption key (DEK), which in turn is encrypted by a server-unique asymmetric RSA 2048 master key. 主密钥的管理方式可以是:The master key can be managed either:

  • 由平台 - SQL 数据库自动管理。Automatically by the platform - SQL Database.
  • 由你使用 Azure Key Vault(用作密钥存储)进行管理。Or by you using Azure Key Vault as the key store.

为方便起见,透明数据加密的主密钥默认由 SQL 数据库服务托管。By default, the master key for Transparent Data Encryption is managed by the SQL Database service for convenience. 如果组织想要控制主密钥,可使用 Azure Key Vault 作为密钥存储。If your organization would like control over the master key, there is an option to use Azure Key Vault as the key store. 通过使用 Azure Key Vault,组织假定控制密钥预配、轮换使用和权限控制。By using Azure Key Vault, your organization assumes control over key provisioning, rotation, and permission controls. 轮换或切换 TDE 主密钥类型非常快,因为它仅重新加密 DEK。Rotation or switching the type of a TDE master key is fast, as it only re-encrypts the DEK. 对于安全性与数据管理角色分开的组织来说,安全管理员可以为 Azure Key Vault 中的 TDE 主密钥预配密钥材料,并为数据库管理员提供 Azure Key Vault 密钥标识符,用于在服务器上进行静态加密。For organizations with separation of roles between security and data management, a security admin could provision the key material for the TDE master key in Azure Key Vault and provide an Azure Key Vault key identifier to the database administrator to use for encryption at rest on a server. Key Vault 的设计可确保 Azure 不会看到或提取任何加密密钥。The Key Vault is designed such that Azure does not see or extract any encryption keys. 此外,可对组织的密钥进行集中式管理。You also get a centralized management of keys for your organization.

始终加密Always Encrypted

Always Encrypted 中还有两个密钥层次结构 - 一列敏感数据通过 AES 256 列加密密钥 (CEK) 加密,而该密钥反过来又由列主密钥 (CMK) 进行加密。There is also a two-key hierarchy in Always Encrypted - a column of sensitive data is encrypted by an AES 256-column encryption key (CEK), which in turn is encrypted by a column master key (CMK). 为 Always Encrypted 提供的客户端驱动程序在 CMK 长度上没有任何限制。The client drivers provided for Always Encrypted have no limitations on the length of CMKs. CEK 的加密值存储在数据库中,而 CMK 存储在受信任的密钥存储库中,如 Windows 证书存储、Azure Key Vault 或硬件安全模块。The encrypted value of the CEK is stored on the database, and the CMK is stored in a trusted key store, such as Windows Certificate Store, Azure Key Vault, or a hardware security module.

  • CEK 和 CMK 都可轮换使用。Both the CEK and CMK can be rotated.
  • CEK 轮换是有一定规模的数据操作,根据包含加密列的表大小,此操作可能十分耗时。CEK rotation is a size of data operation and can be time-intensive depending on the size of the tables containing the encrypted columns. 因此,明智的做法是相应地规划 CEK 轮换。Hence it is prudent to plan CEK rotations accordingly.
  • 但是,CMK 轮换不会影响数据库性能,并可以使用单独的角色来完成。CMK rotation, however, does not interfere with database performance, and can be done with separated roles.

下图显示了 Always Encrypted 中的列主密钥的密钥存储选项The following diagram shows the key store options for the column master keys in Always Encrypted

Always Encrypted CMK 存储提供程序

如何优化和保护组织与 SQL 数据库之间的流量How can I optimize and secure the traffic between my organization and SQL Database

通常,组织与 SQL 数据库之间的网络流量是通过公共网络路由的。The network traffic between your organization and SQL Database would generally get routed over the public network. 但是,如果选择优化此路径并使它更安全,可查看 Azure ExpressRoute。However, if you choose to optimize this path and make it more secure, you can look into Azure ExpressRoute. 实质上,ExpressRoute 是通过专用连接将企业网络扩展到 Azure 平台中的。ExpressRoute essentially lets you extend your corporate network into the Azure platform over a private connection. 这样,就不需要经由公共 Internet。By doing so, you do not go over the public Internet. 此外,还可以提高安全性、可靠性并优化路线,与平时使用公共 Internet 时相比,网络延迟会降低,速度会大大加快。You also get higher security, reliability, and routing optimization that translates to lower network latencies and much faster speeds than you would normally experience going over the public internet. 如果打算在组织与 Azure 之间传输大量的数据区块,则使用 ExpressRoute 可带来成本效益。If you are planning on transferring a significant chunk of data between your organization and Azure, using ExpressRoute can yield cost benefits. 可以选择三种不同的连接模型在组织与 Azure 之间建立连接:You can choose from three different connectivity models for the connection from your organization to Azure:

使用 ExpressRoute 还能将购买的带宽限制免费提升 2 倍。ExpressRoute also allows you to burst up to 2x the bandwidth limit you purchase for no additional charge. 还可使用 ExpressRoute 来配置跨区域连接。It is also possible to configure cross region connectivity using ExpressRoute. 若要查看 ExpressRoute 连接提供商列表,请参阅:ExpressRoute 合作伙伴和对等位置To see a list of ExpressRoute connectivity providers, see: ExpressRoute Partners and Peering Locations. 以下文章更详细介绍了 Express Route:The following articles describe Express Route in more detail:

SQL 数据库是否符合任何规章要求,这对我组织的合规性有什么帮助Is SQL Database compliant with any regulatory requirements, and how does that help with my own organization's compliance

SQL 数据库符合一系列合规要求。SQL Database is compliant with a range of regulatory compliancies. 若要查看 SQL 数据库已满足的最新一组合规要求,请访问 Azure 信任中心,并向下钻取到对你的组织至关重要的合规要求,以了解 SQL 数据库是否包含在合规的 Azure 服务下。To view the latest set of compliancies that have been met by SQL Database, visit the Azure Trust Center and drill down on the compliancies that are important to your organization to see if SQL Database is included under the compliant Azure services. 需要注意的是,尽管 SQL 数据库可能被认证为合规服务,它有助于确保组织服务的符合性,但不会自动保证这一点。It is important to note that although SQL Database may be certified as a compliant service, it aids in the compliance of your organization's service but does not automatically guarantee it.

迁移后的智能数据库监视和维护Intelligent database monitoring and maintenance after migration

将数据库迁移到 SQL 数据库之后,需要监视数据库(例如,检查资源利用率的大致情况,或执行 DBCC 检查)和执行定期维护(例如,重新生成或重新组织索引、统计信息等)。Once you've migrated your database to SQL Database, you are going to want to monitor your database (for example, check how the resource utilization is like or DBCC checks) and perform regular maintenance (for example, rebuild or reorganize indexes, statistics etc.). 幸运的是,SQL 数据库是智能化的,即,它可以使用历史趋势和记录的指标与统计信息来主动帮助你监视和维护数据库,使应用程序始终以最佳方式运行。Fortunately, SQL Database is Intelligent in the sense that it uses the historical trends and recorded metrics and statistics to proactively help you monitor and maintain your database, so that your application runs optimally always. 在某些情况下,Azure SQL 数据库可根据配置设置自动执行维护任务。In some cases, Azure SQL Database can automatically perform maintenance tasks depending on your configuration setup. 监视 SQL 数据库中的数据库需要考虑三个方面:There are three facets to monitoring your database in SQL Database:

  • 性能监视和优化。Performance monitoring and optimization.
  • 安全优化。Security optimization.
  • 成本优化。Cost optimization.

性能监视和优化Performance monitoring and optimization

通过查询性能见解,可获得专门针对数据库工作负载的建议,以便应用程序始终以最佳运行状态。With Query Performance Insights, you can get tailored recommendations for your database workload so that your applications can keep running at an optimal level - always. 还可以进行相应的设置,以便自动应用这些建议,避免干扰维护任务的执行。You can also set it up so that these recommendations get applied automatically and you do not have to bother performing maintenance tasks. 借助 SQL 数据库顾问,可根据工作负载自动实施索引建议,这就是所谓的“自动优化”。With SQL Database Advisor, you can automatically implement index recommendations based on your workload - this is called Auto-Tuning. 建议会根据应用程序工作负荷的变化而不断改进,以提供最有价值的建议。The recommendations evolve as your application workload changes to provide you with the most relevant suggestions. 还可以选择手动审查这些建议,并根据自己的判断应用这些建议。You also get the option to manually review these recommendations and apply them at your discretion.

安全优化Security optimization

SQL 数据库提供可行的安全建议,帮助保护数据,威胁检测可用于识别和调查可能对数据库构成威胁的可疑数据库活动。SQL Database provides actionable security recommendations to help you secure your data and threat detection for identifying and investigating suspicious database activities that may pose a potential thread to the database. 漏洞评估是一项数据库扫描和报告服务,允许你大规模监视数据库的安全状态、识别安全风险以及偏离你定义的安全基线的行为。Vulnerability assessment is a database scanning and reporting service that allows you to monitor the security state of your databases at scale and identify security risks and drift from a security baseline defined by you. 每次扫描之后,都会提供可行步骤和修正脚本的自定义列表,还会提供有助于你满足符合性要求的评估报告。After every scan, a customized list of actionable steps and remediation scripts is provided, as well as an assessment report that can be used to help meet compliance requirements.

Azure 安全中心不时地传送安全建议,只需点击一下鼠标就能应用这些建议。With Azure Security Center, you identify the security recommendations across the board and apply them with a single click.

成本优化Cost optimization

Azure SQL 平台会分析服务器中数据库的利用率历史记录,作出评估并给出成本优化建议。Azure SQL platform analyzes the utilization history across the databases in a server to evaluate and recommend cost-optimization options for you. 此分析通常每隔两周执行一次,生成可行的建议。This analysis usually takes a fortnight to analyze and build up actionable recommendations. 弹性池就是这样的一个选项。Elastic pool is one such option. 建议以横幅形式显示在门户上:The recommendation appears on the portal as a banner:

弹性池建议

也可以在“顾问”部分下面查看此分析:You can also view this analysis under the "Advisor" section:

弹性池建议 - 顾问

如何在 SQL 数据库中监视性能和资源利用率How do I monitor the performance and resource utilization in SQL Database

在 SQL 数据库中,可以利用平台的智能见解来监视性能并相应地进行优化。In SQL Database you can leverage the intelligent insights of the platform to monitor the performance and tune accordingly. 可以使用以下方法监视 SQL 数据库中的性能和资源利用率:You can monitor performance and resource utilization in SQL Database using the following methods:

Azure 门户Azure portal

Azure 门户通过选择数据库并单击“概述”窗格中的图表来显示数据库的利用率。The Azure portal shows a database's utilization by selecting the database and clicking the chart in the Overview pane. 可以修改图表以显示多个指标,包括 CPU 百分比、DTU 百分比、数据 IO 百分比、会话百分比和数据库大小百分比。You can modify the chart to show multiple metrics, including CPU percentage, DTU percentage, Data IO percentage, Sessions percentage, and Database size percentage.

监视图表

监视图表 2

在此图表中,还可以按资源配置警报。From this chart, you can also configure alerts by resource. 通过这些警报,可以使用电子邮件响应资源状态,写入 HTTPS/HTTP 终结点或执行操作。These alerts allow you to respond to resource conditions with an email, write to an HTTPS/HTTP endpoint or perform an action. 有关详细信息,请参阅创建警报For more information, see Create alerts.

动态管理视图Dynamic management views

可以查询 sys.dm_db_resource_stats 动态管理视图,以返回最近一个小时的资源使用统计信息历史记录,也可以查询 sys.resource_stats 系统目录视图,返回过去 14 天的历史记录。You can query the sys.dm_db_resource_stats dynamic management view to return resource consumption statistics history from the last hour and the sys.resource_stats system catalog view to return history for the last 14 days.

Query Performance InsightQuery Performance Insight

可以使用查询性能见解查看特定数据库那些排名靠前的资源消耗查询和长时间运行查询的历史记录。Query Performance Insight allows you to see a history of the top resource-consuming queries and long-running queries for a specific database. 可以根据资源利用率、持续时间和执行频率快速识别排名靠前的查询。You can quickly identify TOP queries by resource utilization, duration, and frequency of execution. 可以跟踪查询和检测回归。You can track queries and detect regression. 此功能需要为数据库启用和激活查询存储This feature requires Query Store to be enabled and active for the database.

Query Performance Insight

我注意到了性能问题:我的 SQL 数据库故障排除方法与 SQL Server 有何不同I am noticing performance issues: How does my SQL Database troubleshooting methodology differ from SQL Server

诊断查询和数据库性能问题时所用的大多数故障排除方法是相同的。A major portion of the troubleshooting techniques you would use for diagnosing query and database performance issues remain the same. 毕竟云是由同一个数据库引擎驱动的。After all the same database engine powers the cloud. 但是,Azure SQL 数据库平台具有内置的“智能”。However, the platform - Azure SQL Database has built in 'intelligence'. 它可以帮助你更轻松地排查和诊断性能问题。It can help you troubleshoot and diagnose performance issues even more easily. 此外,它还可以替你执行一些纠正措施;在某些情况下,会自动地主动修复问题。It can also perform some of these corrective actions on your behalf and in some cases, proactively fix them - automatically.

结合使用 Query Performance Insight (QPI)数据库顾问等智能功能对排查性能问题很有用,因此,故障排除方法的差别也体现在这方面 - 不再需要手动找出可能有助于排除手头问题的重要细节。Your approach towards troubleshooting performance issues can significantly benefit by using intelligent features such as Query Performance Insight(QPI) and Database Advisor in conjunction and so the difference in methodology differs in that respect - you no longer need to do the manual work of grinding out the essential details that might help you troubleshoot the issue at hand. 平台能够自动解决棘手的工作。The platform does the hard work for you. 一个例子就是 QPI。One example of that is QPI. 使用 QPI 可以一路深化到查询级别,查看历史趋势并判断查询回归的确切时间。With QPI, you can drill all the way down to the query level and look at the historical trends and figure out when exactly the query regressed. 数据库顾问可针对缺少索引、删除索引、参数化查询等方面提供建议,帮助提高总体性能。The Database Advisor gives you recommendations on things that might help you improve your overall performance in general like - missing indexes, dropping indexes, parameterizing your queries etc.

进行性能故障排除时,请务必确定是应用程序,还是支持它的数据库影响了应用程序的性能。With performance troubleshooting, it is important to identify whether it is just the application or the database backing it, that's impacting your application performance. 通常,性能问题出现在应用程序层。Often the performance problem lies in the application layer. 问题原因可能在于体系结构或数据访问模式。It could be the architecture or the data access pattern. 例如,假设某个频繁通信的应用程序对网络延迟很敏感。For example, consider you have a chatty application that is sensitive to network latency. 在这种情况下,由于有许多简短请求在应用程序与服务器之间来回传送(“琐碎 I/O”),因此应用程序的性能会受到影响;在拥塞的网络上,往返次数会快速增加。In this case, your application suffers because there would be many short requests going back and forth ("chatty") between the application and the server and on a congested network, these roundtrips add up fast. 若要在此情况下提高性能,可以使用批处理查询To improve the performance in this case, you can use Batch Queries. 使用批处理可以带来很大的帮助,因为现在请求会在批中处理;因此,可帮助减少往返延迟并提高应用程序的性能。Using batches helps you tremendously because now your requests get processed in a batch; thus, helping you cut down on the roundtrip latency and improve your application performance.

此外,如果注意到数据库总体性能下降,则可以监视 sys.dm_db_resource_statssys.resource_stats 动态管理视图,了解 CPU、IO 和内存消耗情况。Additionally, if you notice a degradation in the overall performance of your database, you can monitor the sys.dm_db_resource_stats and sys.resource_stats dynamic management views in order to understand CPU, IO, and memory consumption. 由于数据库的资源严重不足,因此性能可能受到影响。Your performance maybe impacted because your database is starved of resources. 你可能会需要根据工作负荷需求的增加和减少来更改计算大小和/或服务层级。It could be that you may need to change the compute size and/or service tier based on the growing and shrinking workload demands.

有关优化性能问题的全套建议,请参阅:优化数据库For a comprehensive set of recommendations for tuning performance issues, see: Tune your database.

如何确保我使用的是适当的服务层级和计算大小How do I ensure I am using the appropriate service tier and compute size

SQL 数据库提供了各种服务层级:“基本”、“标准”和“高级”。SQL Database offers various service tiers Basic, Standard, and Premium. 在每个服务层级,将获得与该服务层级对应的有保障且可预测的性能。Each service tier you get a guaranteed predictable performance tied to that service tier. 根据工作负荷情况,活动可能会激增,资源利用率可能会达到当前所处计算大小的上限。Depending on your workload, you may have bursts of activity where your resource utilization might hit the ceiling of the current compute size that you are in. 对于这种情况,最好是先评估任何优化措施(例如,添加或更改索引等)是否有所帮助。In such cases, it is useful to first start by evaluating whether any tuning can help (for example, adding or altering an index etc.). 如果仍然存在限制问题,请考虑转移到更高的服务层级或计算大小。If you still encounter limit issues, consider moving to a higher service tier or compute size.

服务层Service tier 常见用例方案Common Use Case Scenarios
基本Basic 用户较少,数据库不具有高并发性、扩展性和性能要求的应用程序。Applications with a handful users and a database that doesn't have high concurrency, scale, and performance requirements.
标准Standard 并发性、规模和性能要求较高且结合了中低 IO 需求的应用程序。Applications with a considerable concurrency, scale, and performance requirements coupled with low to medium IO demands.
高级Premium 具有大量并发用户、高 CPU/内存和高 IO 需求的应用程序。Applications with lots of concurrent users, high CPU/memory, and high IO demands. 高并发性、高吞吐量和对延迟敏感的应用可利用高级等级。High concurrency, high throughput, and latency sensitive apps can leverage the Premium level.

为确保处于正确的计算大小,可通过“如何监视 SQL 数据库中的性能和资源利用率”中所述的某种方式来监视查询和数据库资源消耗。For making sure you're on the right compute size, you can monitor your query and database resource consumption through one of the above-mentioned ways in "How do I monitor the performance and resource utilization in SQL Database". 如果发现查询/数据库一直在过度消耗 CPU/内存等,则可考虑纵向扩展到更高的计算大小。Should you find that your queries/databases are consistently running hot on CPU/Memory etc. you can consider scaling up to a higher compute size. 同样,如果你发现,即使在繁忙时间,似乎也没有使用多少资源,则可考虑下调当前计算大小。Similarly, if you note that even during your peak hours, you don't seem to use the resources as much; consider scaling down from the current compute size.

如果有 SaaS 应用模式或数据库整合方案,则考虑使用弹性池进行成本优化。If you have a SaaS app pattern or a database consolidation scenario, consider using an Elastic pool for cost optimization. 弹性池是实现数据库整合和成本优化的极佳方式。Elastic pool is a great way to achieve database consolidation and cost-optimization. 若要了解有关使用弹性池管理多个数据库的详细信息,请参阅:管理池和数据库To read more about managing multiple databases using elastic pool, see: Manage pools and databases.

需要以何种频率对数据库运行数据库完整性检查How often do I need to run database integrity checks for my database

SQL 数据库使用某些智能技术来自动处理特定类型的数据损坏,且不丢失任何数据。SQL Database uses some smart techniques that allow it to handle certain classes of data corruption automatically and without any data loss. 这些技术已内置在服务中,由服务根据需要利用。These techniques are built in to the service and are leveraged by the service when need arises. SQL 数据库会定期通过还原整个服务中的数据库备份并对其运行 DBCC CHECKDB,以对其进行测试。On a regular basis, your database backups across the service are tested by restoring them and running DBCC CHECKDB on it. 如果存在问题,SQL 数据库会主动解决问题。If there are issues, SQL Database proactively addresses them. 它利用自动页面修复来修复已损坏或出现数据完整性问题的页面。Automatic page repair is leveraged for fixing pages that are corrupt or have data integrity issues. 始终使用可验证页面完整性的默认 CHECKSUM 设置来验证数据库页面。The database pages are always verified with the default CHECKSUM setting that verifies the integrity of the page. SQL 数据库主动监视并审查数据库的数据完整性,如果出现问题,则以最高优先级解决问题。SQL Database proactively monitors and reviews the data integrity of your database and, if issues arise, addresses them with the highest priority. 除此之外,可以根据需要选择运行自己的完整性检查。In addition to these, you may choose to optionally run your own integrity checks at your will. 有关详细信息,请参阅 SQL 数据库中的数据完整性For more information, see Data Integrity in SQL Database

迁移后的数据移动Data movement after migration

如何使用 Azure 门户在 SQL 数据库中将数据作为 BACPAC 文件导出和导入How do I export and import data as BACPAC files from SQL Database using the Azure portal

  • 导出:可通过 Azure 门户将 Azure SQL 数据库中的数据库作为 BACPAC 文件导出Export: You can export your database in Azure SQL Database as a BACPAC file from the Azure portal

    数据库导出

  • 导入:还可使用 Azure 门户将数据作为 BACPAC 文件导入到 Azure SQL 数据库中的数据库。Import: You can also import data as a BACPAC file into your database in Azure SQL Database using the Azure portal.

    数据库导入

如何在 SQL 数据库与 SQL Server 之间同步数据How do I synchronize data between SQL Database and SQL Server

可通过多种方法实现此目的:You have several ways to achieve this:

  • 数据同步 - 此功能可帮助你在多个 SQL Server 数据库和 SQL 数据库之间双向同步数据。Data Sync - This feature helps you synchronize data bi-directionally between multiple SQL Server databases and SQL Database. 若要与 SQL Server 数据库同步,需要在本地计算机或虚拟机上安装和配置同步代理,并打开出站 TCP 端口 1433。To sync with SQL Server databases, you need to install and configure sync agent on a local computer or a virtual machine and open the outbound TCP port 1433.
  • 事务复制 - 使用事务复制可将数据从 SQL Server 数据库同步到 Azure SQL 数据库,SQL Server 实例作为发布服务器,Azure SQL 数据库作为订阅服务器。Transaction Replication - With transaction replication you can synchronize your data from a SQL Server database to Azure SQL Database with the SQL Server instance being the publisher and the Azure SQL Database being the subscriber. 目前仅支持此设置。For now, only this setup is supported. 要详细了解如何在保证停机时间最短的情况下将数据从 SQL Server 数据库迁移到 Azure SQL,请参阅:使用事务复制For more information on how to migrate your data from a SQL Server database to Azure SQL with minimal downtime, see: Use Transaction Replication

后续步骤Next steps

了解 SQL 数据库Learn about SQL Database.