AWS部署SQL Server崩溃后丢失30分钟提交数据是否正常？Oracle用户的技术问询

先直接给你拍板：这种主库崩溃就丢30分钟已提交数据的情况绝对不是SQL Server的正常操作，你们完全有理由提出异议——这要么是你们的新DBA对AWS上SQL Server的高可用配置理解有误，要么是给核心业务部署了完全不合规的灾备方案。

SQL Server从2012年推出Always On可用性组开始，就支持和Oracle Data Guard同步模式完全对标零数据丢失的高可用方案：

• 采用同步提交模式的Always On AG：主库上的事务必须等备库确认已经把日志写入磁盘后，才会向应用返回“提交成功”的响应。只要备库处于健康状态，主库彻底崩溃后切换到备库，不会丢失任何已提交的交易数据，和你熟悉的Oracle环境逻辑一致。
• 就算是用更早的镜像技术（现在虽被AG替代但仍可用），同步镜像模式也能做到零数据丢失。

那个“30分钟延迟”的说法，大概率是指用了日志传送方案——但日志传送本质是灾难恢复工具，不是高可用切换方案。它的延迟来自日志备份的间隔（比如每30分钟备份一次事务日志再传到备库），这种方案只适合对数据丢失容忍度极高的非核心系统，绝对不能用在支付、发票这类核心业务上。

不管你是用AWS RDS托管的SQL Server，还是自己在EC2上搭建：

• RDS for SQL Server只要开启多AZ部署，AWS会自动维护一个同步的备用实例，主库的事务实时同步到备库，故障自动切换时RPO（恢复点目标）是0，完全不会丢数据。
• EC2自建的话，部署同步模式的Always On AG，同样能实现零数据丢失的高可用切换。

你在Oracle环境没遇到这种情况，是因为大家默认用Data Guard同步模式做高可用；SQL Server这边的同步AG就是对标这个的，逻辑完全一致——你们遇到的只是配置错误，不是SQL Server的固有问题。

• 马上和DBA拉通，明确问清楚当前用的是什么高可用方案：是异步AG？日志传送？还是根本没配置合规的高可用？
• 明确提出核心业务的RPO要求是0数据丢失，要求立刻切换到同步提交的高可用方案（RDS多AZ或同步AG）。
• 如果DBA还坚持这是“正常情况”，那要么是他对SQL Server高可用的认知有严重偏差，要么是在偷工减料——这种情况你们必须提出异议，因为这直接威胁到核心业务的数据安全。

内容的提问来源于stack exchange，提问作者Joe DiNottra