当数据是业务的命脉时，您需要确保数据库是可靠的、安全的，并且在需要执行时可用。服务水平协议（SLA）设定了正常运行时间和性能的期望值，是设计满足业务需求的系统的关键输入。我们最近发布了新版本的SQL数据库SLA，保证了关系数据库服务中最高的可用性，并引入了业界第一个业务连续性SLA。这些更新进一步巩固了我们的承诺，即确保您的数据是安全的，并且您的业务所依赖的应用程序和流程在遇到破坏性事件时继续运行。正如我们在最近的服务更新中指出的，我们在SLA中做了两个主要的更改。首先，azuresqldatabase现在为其业务关键层的区域冗余数据库提供了99.995%的可用性SLA。这是业界所有关系数据库服务中最高的SLA。当SLA没有维护时，它还可以获得每月100%的成本抵免。其次，我们为业务关键层的数据库提供业务连续性SLA，这些数据库在两个不同的Azure区域之间进行地域复制。该SLA提供了非常有力的保证，即5秒恢复点目标（RPO）和30秒恢复时间目标（RTO），包括在未维护SLA时每月100%的成本抵免。azuresqldatabase是业界唯一提供业务连续性SLA的关系数据库服务。下表提供了不同云供应商的sla的快速并排比较。站台可利用性业务连续性正常运行时间最高学分RTO公司最高学分RPO公司最高学分Azure SQL数据库99.995%100%30秒100%5秒100%自动气象站RDS99.95%100%药方药方药方药方GCP云SQL99.95%50%药方药方药方药方阿里云数据库99.9%25%药方药方药方药方甲骨文云99.99%25%药方药方药方药方数据截至2019年7月18日，如有更改，恕不另行通知。了解可用性SLASLA的可用性反映了自动处理每个数据库区域中发生的中断事件的能力。它依赖于计算和存储资源的区域内冗余、持续的运行状况监视和在区域内使用自动故障转移的自愈操作。这些操作依赖于同步复制的数据，并且没有数据丢失。因此，正常运行时间是衡量可用性的最重要指标。Azure SQL Database将继续为其所有服务层提供99.99%的基线可用性SLA，但现在为支持可用性区域的业务关键层或高级层提供更高的99.995%SLA。顾名思义，业务关键层是为性能和可靠性方面要求最高的应用程序而设计的。通过将此服务层与Azure availability zones（AZ）集成，我们利用AZs提供的额外容错和隔离功能，从而允许我们使用跨AZs的计算和存储冗余以及相同的自愈操作来提供更高的可用性保证。因为计算和存储冗余是为业务关键型数据库和弹性池内置的，所以使用可用性区域不会增加您的成本。我们的文档"高可用性和Azure SQL数据库"提供了有关业务关键型服务层如何利用可用性区域的更多详细信息。您还可以在我们的文档"Azure中的可用性区域是什么"中找到支持AZs的区域列表99.99%的可用性意味着对于任何数据库，包括业务关键层的数据库，每年的停机时间不应超过52.56分钟。区域冗余将可用性提高到99.995%，这意味着每年最多停机时间仅为26.28分钟或减少50%。停机一分钟被定义为所有建立连接的尝试都失败的时间段。为了达到这一级别的可用性，您只需在创建业务关键型数据库或弹性池时选择区域冗余配置。您可以使用create或updatedatabaseapi，或在azureportal中以编程方式完成此操作，如下图所示。我们建议使用Gen5计算生成，因为大多数区域的区域冗余容量都基于Gen5。区域冗余配置的转换是一个异步的在线过程，类似于更改服务层或数据库的计算大小时发生的情况。它不需要默认或使您的应用程序脱机。只要连接逻辑正确实现，应用程序在转换期间就不会中断。了解业务连续性SLA业务连续性是指服务在灾难性事件中快速恢复并继续运行的能力，这些事件的影响是区域内自愈操作无法减轻的。虽然这些类型的意外事件很少发生，但其影响可能是巨大的。业务连续性是通过在两个或多个地理位置不同的位置提供数据库的备用副本来实现的。由于这些位置之间的距离很长，所以使用异步数据复制来避免网络延迟对性能的影响。使用异步复制的主要代价是可能会丢失数据。SQL数据库中的主动地域复制功能旨在通过创建和管理地理上冗余的数据库来实现业务连续性。它已经生产了好几年了，我们有大量的遥测设备来支持非常积极的保证。有两种常用的度量标准用于度量业务连续性事件的影响。恢复时间目标（RTO）衡量恢复应用程序可用性的速度。恢复点目标（RPO）衡量恢复可用性后的最大预期数据丢失。我们不仅为RPO提供5秒的服务级别协议，为RTO提供30秒的服务级别协议，而且如果不满足这些服务级别协议，我们还提供业界首屈一指的100%服务积分。这意味着，如果您的任何数据库故障转移请求没有在30秒内完成，或者复制延迟在1小时内超过第99个百分点值的5秒，您就有资格获得相关辅助数据库每月100%的服务积分。要获得服务积分，辅助数据库必须与主数据库具有相同的计算大小。注意，这些指标不应被解释为从灾难性停机中自动恢复的保证。它们反映了azuresql在同步数据时的可靠性和性能，以及应用程序请求时的故障转移速度。如果您喜欢完全自动的恢复过程，您应该考虑使用自动故障转移策略的自动故障切换组，该策略有一个小时的RTO。要度量故障转移请求的持续时间，即RTO遵从性，可以对系统运行状态在辅助服务器上的master数据库中。请注意，操作状态信息仅保留24小时。从中选择datediff（s，start_time，last_modify_time）作为[故障转移时间（秒）]系统运行状态其中major_resource_id='，operation='ALTER DATABASE FORCE FAILOVER ALLOW DATA LOSS'，state=2 ORDER BY start_time DESC；以下查询针对sys.dm_replication_link_状态在主数据库中，将显示在伙伴服务器上创建的辅助数据库的复制延迟（以秒为单位），即RPO符合性。您应该每隔30秒或更短时间运行一次相同的查询，以获得每小时具有统计意义的测量值集。从中选择链接guid、伙伴服务器、复制延迟秒sys.dm_replication_link_状态将可用性和业务连续性结合起来构建任务关键型应用程序更新后的SLA对您实际意义是什么？我们的目标是使您能够在Azure上构建具有高度弹性和可靠性的服务，并以SQL数据库为后盾。但对于一些关键任务应用程序，即使每年停机26分钟也不可接受。将区域冗余数据库配置与业务连续性设计结合起来，可以进一步提高应用程序的可用性。这个SLA版本是实现这个机会的第一步。