拯救SQL Server数据库事务日志文件损坏

在数据库的日常管理中，我们不可避免的会遇到服务器突然断电（没有进行电源冗余），服务器故障或者 SQL Server 服务突然停掉，

头大的是ldf事务日志文件也损毁了，SQL Server服务器起来之后，发现数据库处于"Recovery Pending" 状态。

更麻烦的是该数据库没有任何备份或者备份已经比较久远；

当然这些都不是最难的，最难的是连资深DBA使出ATTACH_REBUILD_LOG和 DBCC CEHECKDB 的 REPAIR_ALLOW_DATA_LOSS 选项等招数时候，

即使已经做好了最坏打算，做了丢失部分数据的准备，数据库还是无法上线。

测试环境： SQL Server 2022，Windows 2016

注意：做任何操作之前注意先做备份！ 

模拟环境

首先，在数据库 testdb 中创建 testObject 表，并不停插入所有对象数据。

在窗口一我们运行插入数据脚本，使用多次 CROSS JOIN，以获得足够多的数据，插入数据脚本实际是一个模拟的大事务。

--窗口1

CREATE DATABASE testdb
GO
USE testdb
GO        

SELECT * INTO testObject FROM sys.all_objects


--前面脚本执行完成再执行下面的插入语句
INSERT INTO dbo.testObject
SELECT o.* FROM sys.all_objects o
 CROSS JOIN sys.all_objects o1
 CROSS JOIN sys.all_objects o2
 CROSS JOIN sys.all_objects o3
 CROSS JOIN sys.all_objects o4

在窗口二我们在关闭测试实例时，窗口一的插入事务仍然在运行。

这将使得数据库处于不一致状态，在数据库启动时，执行数据库恢复。

SHUTDOWN WITH NOWAIT

数据库停服后，将testdb数据库 的ldf事务日志文件改名或者移到其他路径，重新启动SQL Server 服务，可以看到，testdb 数据库处于“恢复挂起”状态。

因为在停服时候，还有未提交的插入事务保存在ldf事务日志文件，需要在数据