伪简单的Server恢复是真的吗？

Question

“伪简单的Server恢复”是术语和场景，我刚刚在一个(现在删除的)新问题服务器只使用副本备份截断事务日志的注释中知道。

我去了post 伪简单Server恢复模型，2019年年10月7日，由Rajendra Gupta，并在那里使用了一些代码，而我自己的一些代码做了一些测试。

创建数据库(Rajendra的代码)

CREATE DATABASE RecoveryModel;

并验证它是否完整(Rajendra的代码)

SELECT name, 
    recovery_model_desc
FROM sys.databases
WHERE name = 'RecoveryModel';

做些工作(Rajendra的代码，稍作修改)

Use RecoveryModel
CREATE TABLE test(id INT);
GO 
INSERT INTO test
VALUES(1);
GO 5000

查看使用了多少日志空间(我的代码)

select file_id
, type_desc
, name
, substring([physical_name],1,3) AS [Drive]
, physical_name
, state_desc
, size / 128 as 'AllocatedSizeMB'
, FILEPROPERTY([name],'SpaceUsed') /128 AS 'SpaceUsedMB'  --Addapted from https://sqlperformance.com/2014/12/io-subsystem/proactive-sql-server-health-checks-1
, (1- (FILEPROPERTY([name],'SpaceUsed') / CAST (size AS MONEY))) *100 AS 'PercentFree'
, growth / 128 as 'GrowthSettingMB'

 from sys.database_files
 order by type_desc Desc, name

我们发现原木被填满了。再次运行工作并检查大小，日志就会增长，这并不奇怪。

尝试运行t-log (我的代码)

BACKUP LOG [RecoveryModel] TO  
DISK = N'E:\SQLBackups\RecoveryModel.trn' WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD 
GO

它在消息中失败：

由于没有当前数据库备份，无法执行Msg 4214、级别16、状态1、第8行备份日志。Msg 3013，16级，状态1，第8行备份日志正在异常终止。

如果您试图在简单恢复中备份数据库，那么这一点一点也不简单。你收到消息了

Msg 4208，级别16，状态1，第19行不允许语句备份日志，而恢复模型很简单。使用备份数据库或使用更改恢复模型。

只运行副本备份(我的代码)

BACKUP DATABASE [RecoveryModel] TO  
DISK = N'E:\SQLBackups\RecoveryModel.bak' WITH NOFORMAT, INIT, COPY_ONLY,  
NAME = N'RecoveryModel-Full Database Backup', SKIP, NOREWIND, NOUNLOAD
GO

它运行良好，检查日志空间，但没有缩小。再运行几次工作负载，日志空间就会继续增长。运行t日志备份，它将继续失败。

运行差异备份(我的代码)

BACKUP DATABASE [RecoveryModel] TO  
DISK = N'E:\SQLBackups\RecoveryModel.dif' WITH  DIFFERENTIAL , NOFORMAT, NOINIT,  
NAME = N'RecoveryModel-Diff Database Backup', SKIP, NOREWIND, NOUNLOAD
GO

它就像t_log一样失败

Msg 3035、级别16、状态1、第13行不能对数据库"RecoveryModel“执行差异备份，因为不存在当前的数据库备份。通过重新发出备份数据库来执行完整的数据库备份，同时省略WITH差分选项。

那么，什么是“伪简单”呢？日志增长，t日志和不同的备份失败。数据库处于完全恢复状态，没有完全备份。

编辑--看起来，在我的构建中，有一些特定于服务器的东西，导致了不同于其他人所看到的结果。我接受了乔什的回答。

Answer 1

伪简单意味着完整恢复模型中的数据库在第一次完全备份(备份后的最后一个日志序列号被记录下来之前)的行为就像在简单恢复模型中一样。

换句话说，处于完全恢复模型中的数据库需要一个有效的备份链，而一个有效的备份链需要一个完整的备份才能启动。然后，您可以执行日志和差异备份并行您的心脏的内容，其中每一个是基于这个初始的完全备份。

正如您在运行的脚本中所看到的，在运行完整(只复制)备份之前，没有建立备份链。一旦运行，您就启动了一个备份链，但是因为您做了一个只复制的备份，所以您混淆了一些事情。

差异备份是将需要还原到特定时间点的日志备份数量减少的快捷方式。它们依赖于非COPY ONLY的完整备份，因为仅复制备份不会重置用于跟踪自上次完全备份以来修改的区段的差异位图。

如果您完成了标准的完全备份(没有COPY ONLY)，您的差异就会成功，数据库将不再处于伪简单状态。更令人困惑的是，在简单的恢复模型中，如果没有完整的(非复制的)备份来启动链，差异备份也会在数据库上失败。

Answer 2

我(关于这个问题的OP)不明白为什么“伪简单SQL Server恢复”会像在多个帖子中定义的那样工作，但是我没有在我的系统上看到这些测试。

在研究阶段，我将数据库放入SIMPLE并重新创建测试，所使用的日志文件的大小与在FULL中的大小相同，这表明控制事务持久性存在一些问题，但进一步的测试排除了这一点。

经过更多的研究和测试，我发现了！(感谢一位帮助我解决问题的同事。)

• 我们使用50 We作为“模型”的启动大小，这意味着RecoveryModel启动相同。(默认SQL 2017为8MB)
• 这将创建4个VLFs，每个大约12.5MB
• 我在上面的测试中使用的工作负载在每次运行时都会在日志中创建大约2MB的数据。
• 在执行COPY ONLY备份之前，我运行了3到5次测试工作负载(6到10 of的日志)。
• VLF使用的空间在增长，但由于它从未填满第一个VLF，它停留在状态2，什么也没有释放。
• 当测试似乎给出了意想不到的结果时，我删除了数据库，开始了一个新的测试。
• 在后续测试中，我运行工作负载来创建~15 2MB的日志，然后运行COPY ONLY并使用空间降至2MB，第一个VLF返回状态0，第二个VLF保存最后2MB。
• 这可以通过使用下面的代码来验证，除此之外，还可以自己修改和测试。

。

USE [RecoveryModel]
GO
DBCC LOGINFO

有关VLF的相关信息：-我如何截断它们?太多的？