为什么完全恢复模型是可用性组的要求？

Question

我们有我们所有的生产数据库在简单的恢复模型，并对它非常高兴，因为它完全满足我们的RPO和RTO。

现在我们想为我们的数据库实现AG DR解决方案，我们发现完全恢复模型是一个要求。

我的问题是为什么？从理论上讲，AG或其他SQL Server DR解决方案(日志传送、DB镜像)不适用于简单的恢复模型，从理论上讲，有什么技术原因吗？

Answer 1

在医管局内，如果容许DR技术进行简单的回收，是没有意义的。事务日志是实时恢复所必需的。事务日志是DR技术用于重播在Log航运/镜像数据库上执行的事务的方法，而且由于简单恢复中不可能进行日志备份，所以您也不能在简单恢复中配置HA/DR。在镜像中，事务日志块更改被发送到镜像服务器；在日志传送中，事务日志备份被发送。因此，您可以看到镜像/日志/AlwayON工作的基本概念是事务日志。

事务日志是数据库中最重要的部分--在发生崩溃时，它是唯一能够保证对数据库的所有更改进行描述的地方。单个事务的日志记录由LSNs链接，几乎就像时间戳一样。这个时间戳在内部用于链接各种事务并在DR服务器上重放。

DR技术的主要目的是提供尽可能少的数据丢失，只有在事务日志保持结构一致的情况下才能做到这一点。在简单恢复中，事务日志在事务提交时被截断，这意味着不需要信息，旧事务占用的空间现在将用于写入新事务。在这种情况下，旧的信息丢失了。如果你想得到它，你不能。但在完全康复的时候你可以做到。

Answer 2

这是因为这些方法依赖于事务日志，而事务日志本身仅在完全恢复模型中是可靠的。请完整阅读下面的一页，因为有几个提示说明了简单恢复和完全恢复之间的区别，以及为什么full对DR如此重要：

• 为什么事务日志不断增长或耗尽空间？

如果您想使用简单的恢复，那么您只能通过进行完整的和差异的备份来实现DR。在这种情况下，你会失去及时恢复。

在某些情况下，这是可以的，但我们不知道您的RPO/RTO是什么，我们也不知道您对数据丢失、备份所使用的磁盘空间等的容忍度。如果您想一整天每分钟进行一次完整或不同的备份，您可以保持简单的恢复模式，并拥有相对可靠的RPO。日志备份往往是实现最优RPO的一种更快、更容易和更可靠的方法，而且我怀疑大多数人已经在使用完全恢复了。因此，AlwaysOn和其他利用该模型的技术的需求通常不是什么绊脚石或伤脑筋。但是这是一个很难的要求，原因是不相关的，但您可能会认为，最基本的原因之一是，在简单的恢复(甚至大容量日志记录)中，您实际上可能会丢失那些永远不会被发送到次要文件的事务，从而使其处于不一致的状态。

一切都是交换。我的感觉是，很多人更喜欢简单的恢复，因为他们需要处理的事务日志问题较少(不过，这些问题已经减少到0 )。这就像很多事情一样--这种交换非常有效，直到你真正经历磁盘故障、人为错误或其他需要你恢复备份的停机。在完全恢复过程中，您会被迫主动地管理日志(否则它们会消耗您的磁盘)，而且在发生故障时，您总是可以到达特定的时间点。简单地说，对我来说，这似乎是一个非常容易的网关，根本不注意备份。这只是一个观点，而不是一个技术上的事实，但它是基于一个非常大的样本规模。

Answer 3

假设我在一个恢复模型为full的数据库上运行以下查询：

INSERT INTO dbo.MY_FAVORITE_MSFT_EMPLOYEES WITH (TABLOCK)
SELECT 'SEAN GALLARDY' UNION ALL SELECT 'JOE SACK';

在完全恢复模型下，Server将写入插入到事务日志的数据的某些表示形式。这允许辅助数据库上的重做线程读取事务日志，并将主数据库上发生的事务应用到辅助数据库。这是可能的，因为在事务日志中有一些"JOE“和"SEAN”的表示。

现在假设我使用简单的恢复模型和插入的符合最小日志记录的条件在数据库上运行相同的查询：

INSERT INTO dbo.MY_FAVORITE_MSFT_EMPLOYEES WITH (TABLOCK)
SELECT 'SEAN GALLARDY' UNION ALL SELECT 'JOE SACK';

在这种情况下，Server可能不会写入插入到事务日志的数据的完整表示形式。相反，它可能只记录页面ids或区段ids。这个博客帖子很有教育意义：

在最小日志记录下，Server不记录单个行，只记录页和区段分配。因此，如果每个页面可以容纳100行，我们将用100条日志记录换取1条日志记录，这是一个显著的改进。

了解所更改内容的页ids或区段ids就足以使Server在必要时执行回滚。但是，对于重做编写器来说，将事务应用于辅助数据库是不够的。主数据库和辅助数据库需要字节对字节的副本，因此简单的恢复模型与AG不兼容。