数据库始终以恢复模式启动

Question

每次我重新启动我的服务器时，数据库总是处于恢复模式，它需要大约 20 分钟才能正常运行。这总是并且只有在我重新启动服务器时才会发生，所以我有几个问题......

1. 有人告诉我这可能是由大日志文件引起的吗？那可能是正确的吗？如果不是，那么其他原因可能是什么？
2. 我需要降低日志文件的空间以防止恢复。哪个更好：缩小还是截断？
3. 如何缩小或截断日志文件/数据库以减小大小？语法是什么？

我目前正在使用 Microsoft SQL Server 2008。

Answer 1

我有同样的问题，我相信我已经解决了它，但我无法对其进行全面测试以确认。

我相信这些问题与您的日志文件中的 VLF 数量有关，而不是与它的大小有关。如果您有一个很大的日志文件，它很可能是通过自动增长事件有机增长的，而不是有意计划的增长。如果是这种情况，您的日志文件中可能有数千个 VLF。

这是一个查询，用于查看我从这里使用的 VLF 数量：

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

有关什么是 VLF 的进一步说明，请参阅此链接。

我认为问题在于，对于如此多的 VLF，SQL 服务器需要很长时间来评估它们的状态，然后使数据库退出恢复状态。如果您将日志文件缩小到最小的大小，通常是在日志文件中创建的第一个 VLF 的大小，那么您可以立即有意地再次增大它，从而让它创建正确数量的 VLF（小于16)。

一旦完成，我相信您将能够看到您的数据库更快地恢复。

在解决了我们自己的 VLF 问题后，我还没有机会测试我们生产实例的故障转移，所以我很好奇您是否能确认这是问题的根本原因。通过实验，我已经看到在我们的临时环境中恢复所需的时间因此而大大减少，所以希望就是这样。

Answer 2

来自这篇 MSDN文章：

长时间运行的未提交事务会增加所有类型检查点的恢复时间。

通常不建议在生产数据库上运行任何类型的 DBCC 收缩文件。此外，日志截断行为从早期版本更改为 2008 年（感谢 @Edward） - 根据此博客：

SQL 2008 中不再支持使用 trucate_only 备份日志。如果您的数据库处于批量日志记录或完全恢复模式，则定期安排 T-Log 备份，它将保持您的 t-log 正常。

我再次提到，你们多久备份一次数据库？通常，定期备份可以最好地“管理”日志大小。