诊断Microsoft SQL Server错误9001：数据库的日志不可用

在周末，我运行的一个网站停止运行，每次向该网站提出请求时，都会在事件查看器中记录以下错误：

赛事ID：9001

数据库“ 数据库名称 ” 的日志不可用。检查事件日志中是否有相关的错误消息。解决所有错误，然后重新启动数据库。

该网站托管在专用服务器上，因此我能够RDP进入服务器并四处浏览。该LDF数据库的文件存在于该C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA文件夹中，但是尝试从Management Studio中对数据库进行任何操作都会导致一个对话框，报告相同的错误-9001：数据库日志不可用...

这是我第一次收到此错误，并且两年来一直在此专用Web服务器上托管此网站（及其他网站）。

据我了解，此错误表明日志文件已损坏。我能够通过拆下数据库，然后从几天前恢复备份的方式使网站恢复在线，但是我担心的是，该错误表明存在更严重的问题，即硬盘故障。

我通过电子邮件寄给了网络托管公司的支持，这是他们的回复：

在事件日志中似乎没有其他指示原因的指示，因此该日志可能已损坏。当前，内存的资源为87％，这可能也会产生影响，但不太可能。

日志是否可以“损坏”？

我的问题：诊断该问题应采取哪些下一步措施？如何确定这确实是硬件问题？如果是的话，除了更换磁盘还有其他选择吗？

谢谢

超过99％的数据库损坏问题是由存储系统造成的。其余问题中的一半是由于内存不足，另一半是SQL Server中的错误。

奇怪的是这是一个存储问题。

如果再次发生，请对数据库运行DBCC CHECKDB，这将为您提供有关损坏的更多信息，并且如果不进行还原即可解决问题。您可能需要在紧急模式下使数据库联机以对数据库运行checkdb。

内存使用率为87％与该问题无关。根据设计，SQL Server会将内存一直运行到100％（或接近100％）。

通过在Management Studio中使数据库脱机，然后立即使其重新联机，我能够解决此问题。dbcc checkdb在执行此操作后抛出了已解决的错误。我不能说，为什么这个工作只知道它做的工作。

我最近也遇到了这个问题，经过大量研究，将数据库设置为AUTO CLOSE似乎很常见。我将所有数据库设置为AUTO CLOSE = FALSE。首先从一个数据库开始，然后又移到两个数据库，然后将其放在所有数据库上。我只是重新启动了SQL Server实例服务，而不是还原数据库。解决该症状的另一种方法是使有问题的数据库脱机，然后再次使其重新联机。

MS SQL将使受影响数据库的日志脱机，以避免数据库损坏。这就是为什么您会收到9001错误的原因。

当使受影响的数据库脱机/联机时，MS SQL将启用受影响的数据库日志，直到再次发生错误。

解决此问题的另一种方法是将Auto_Close选项更改为OFF

http://sqlmag.com/blog/worst-practice-allowing-autoclose-sql-server-databases

我要猜测/希望您对SQL服务器的磁盘进行了一次突袭。如果您怀疑硬件问题，那么我要做的第一件事就是运行RAID维护/诊断工具。

第二件事（如果可能的话，可能并发执行）是在数据库（也许还有系统数据库）上运行dbcc checkdb。

好的，第一步，将日志和mdf文件备份到完全不同的驱动器上。很快！（文件副本）

另外，尝试执行完整的数据库备份。

接下来，尝试以下操作。如果可以，请使用当前数据库将其分离，然后删除日志文件，或将其移动到磁盘上完全不同的位置。然后重新附加数据库，它将与日志文件一起显示在gui中，单击删除（或删除）该日志文件以使其不显示，然后单击“确定”。基本上在没有日志的情况下附加它，将强制它在默认位置为数据库创建一个日志文件。

让我知道。

是的，我也遇到了同样的问题，它涉及tempDb错误9001，即日志不可用。我们重新启动了服务，一切都很好。

其背后的问题是SAN或存储问题，虽然I / O写入操作，但其写入时间不能超过15秒。

昨天，我收到了相同的错误“数据库'％'的日志不可用。致命错误9001，消息21。请与管理员联系”-

解决方法-我检查了'TempDB'，但无法像其他系统数据库一样访问它。然后在寻求修复选项之前，我只是重新启动了该实例的SQL服务，问题得到解决:) :)

我已经看到，当没有可用的磁盘空间用于日志扩展时，就会发生这种情况。您可以验证C：\上是否有足够的空间，以及是否正在管理您的日志，即，如果处于完全恢复模式，则进行备份。

如果可以的话，我会将您的ldf（和mdf）从引导卷上移开。