在数据库的日常管理中，我们不可避免的会遇到服务器突然断电（没有进行电源冗余），服务器故障或者 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事务日志文件，需要在数据
