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

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

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

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

我有相同的问题，我相信我已经解决了，但是我无法完全测试它以确认。

我认为问题与日志文件中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 Server需要很长时间才能评估其状态，然后使数据库无法恢复。如果将日志文件缩小到最小大小（通常是在日志文件中创建的第一个VLF的大小），则可以立即有意地再次增大它的大小，从而使它创建正确数量的VLF（小于16）。

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

在解决了我们自己的VLF问题之后，我还没有机会测试生产实例的故障转移，因此如果您可以确认这是问题的根本原因，我将非常好奇。从实验上，我已经看到在过渡环境中恢复所需的时间因此而大大减少了，因此希望如此。

从这篇MSDN 文章中：

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

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

SQL 2008不再支持使用trucate_only的备份日志。如果您的数据库处于大容量日志记录或完全恢复模型，则应定期安排T-Log备份，这将使您的T-log保持良好状态。

同样，我会提到，您多久备份一次数据库？通常，常规备份最好“管理”日志大小。

减少联机事务日志的大小可以解决问题，即加快数据库联机速度，但是在执行此操作之前，您应该考虑灾难恢复。请注意，如果您使用的是简单恢复模式，则将无法还原到某个时间点。另一方面，如果您处于“完全”恢复模式，则保持在线事务日志大小的最佳方法是在常规基础上创建事务日志备份（安排它）。

截断事务日志不会释放物理硬盘空间，它仅允许SQL Server将空间重新用于自上次执行CHEKPOINT（自上次事务日志备份以来）以来发生的事务。

如果收缩数据库，则将减小文件的大小。要将MyDB数据库缩小15％：

DBCC SHRINKDATABASE（MyDB，15）; 走