在周末，我运行的网站停止运行，每次向网站发出请求时，都会在事件查看器中logging以下错误：
事件ID： 9001
数据库“ 数据库名称 ”的日志不可用。 检查事件日志中的相关错误消息。 解决任何错误并重新启动数据库。
该网站托pipe在一个专门的服务器，所以我能够RDP到服务器和周围。 数据库的LDF文件存在于C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA文件夹中，但试图对Management Studio中的数据库执行任何操作会导致报告相同错误的对话框 – 9001：数据库日志不可用…
这是我第一次收到这个错误，而且我已经在这个专用的Web服务器上托pipe了这个站点（和其他）两年多了。
这是我的理解，这个错误表明一个损坏的日志文件。 通过分离数据库，然后从几天前恢复备份，我能够恢复网站的在线状态，但是我担心这个错误是一个更严重的问题，即硬盘驱动器故障。
我通过电子邮件发送给networking托pipe公司的支持，这是他们的回复：
在事件日志中似乎没有任何其他原因的迹象，所以可能是日志损坏了。 目前内存的资源是87％，这也可能有影响，但不太可能。
日志只能“损坏”吗？
我的问题：我应该采取什么措施来诊断这个问题？ 我如何确定这是否确实是硬件问题？ 如果是这样，除了更换磁盘之外还有其他的select吗？
谢谢
超过99％的数据库损坏问题是存储系统。 剩下的一半问题是由于内存不足造成的，另一半是SQL Server中的错误。
可能性是存储问题。
如果再次发生，运行DBCC CHECKDB对数据库，这会给你更多的信息有关腐败，如果问题可以修复，而不做恢复。 您可能需要将数据库以紧急模式联机，以针对数据库运行checkdb。
内存使用率达到87％与问题无关。 SQL Server将通过devise将内存一直运行到100％（或接近它）。
我可以通过在Management Studio中将数据库脱机，然后立即将其重新联机来解决此问题。 dbcc checkdb已经抛出了错误，这样做后解决。 我不能说为什么这个工作只是它的工作。
我最近也遇到过这个问题，在数据库设置为“自动closures”（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
我会猜测/希望你有一个RAID为你的SQL服务器的磁盘。 如果您怀疑硬件问题，我会做的第一件事就是运行您的RAID维护/诊断工具。
第二件事（可能同时发生）是在数据库上运行dbcc checkdb（可能还有你的系统数据库）。
好的，第一步，把你的日志和你的mdf文件备份到一个完全不同的驱动器上。 很快！ （文件复制）
另外，请尝试执行完整的数据库备份。
接下来，尝试以下。 使用当前的数据库，如果可以，请将其分离，然后删除该日志文件，或将其移动到磁盘上完全不同的位置。 然后重新连接数据库，它会在一个日志文件中出现在gui中，点击删除（或删除）日志文件，使其不显示，然后单击确定。 基本上没有日志附加它会强制它在默认位置为数据库创build一个日志文件。
让我知道。
是的，我也得到了同样的问题，这是关于tempDb错误9001，即日志不可用。 我们重新启动服务，一切都很好。
这个背后的问题是SAN或存储问题，而I / O写入操作，无法写入超过15秒。
昨天，我收到了同样的错误“日志数据库'％'不可用。致命错误9001，味精21.请联系您的pipe理员” –
解决方法 – 我检查了'TempDB'，但是其余的系统数据库不能访问。 然后在去维修选项之前，我只是重新启动SQL服务的实例和问题得到解决:) 🙂
当没有可用于日志扩展的磁盘空间时，我看到了这种情况; 你能确认C：\有足够的空间，而且你的日志正在被pipe理，也就是说，如果你处于完全恢复模式，那么它将被备份。
如果您有select，我会将您的ldf（和mdf's）从引导卷上移开。