☰

日志移动后 SQL Server 2008 R2 数据库“可疑”

tag-icon • tag-icon sql-server-2008
日志移动后 SQL Server 2008 R2 数据库“可疑”

我们有一位客户使用我们的 MSSQL 软件，我们正在尝试为他们解决问题。我们更多地使用 MySQL，所以请原谅我对 MSSQL Server 的无知。

他们在该物理服务器上有 3 个卷：C:\；D:\；和 L:\。D:\ 卷保存 SQL DB，L:\ 卷保存事务日志。

由于一些非常糟糕的准备和管理，L:\ 卷已被填满，在联系我们之前，他们停止了 SQL，将 SQL 事务日志移至有空间的 D:\，继续使用更大的物理磁盘创建新的 L:\ raid，然后将事务日志移回并重新启动 SQL 服务。

从那时起，他们就无法登录 SQL Management Studio 或访问数据库。

我能够进入，但所有数据库都被标记​​为（可疑）。我根本无法检索数据库上的任何属性。

谷歌搜索显示了一些建议的查询，可以针对数据库运行以修复此问题，但我不愿意运行它们。看起来其中一部分是针对数据库的 DBCC 检查，但我对其余部分不熟悉。

这里是链接。

有谁对解决这个问题有什么建议或者知道可能发生了什么吗？

提前感谢你的帮助，

亚伦

答案1

备份数据库（停止服务，复制 .mdf），然后运行该脚本。REPAIR_ALLOW_DATA_LOSS 行可能会造成破坏。

此处的脚本可供将来参考：

EXEC sp_resetstatus [YourDatabase];
ALTER DATABASE [YourDatabase] SET EMERGENCY
DBCC checkdb([YourDatabase])
ALTER DATABASE [YourDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([YourDatabase], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [YourDatabase] SET MULTI_USER

如果有任何安慰的话，我们的产品使用合并复制，因此我们在现场有数千台笔记本电脑运行 SQL Express，并且我们经常看到可疑数据库。备份数据库后运行该脚本可以修复问题，成功率达 99%，且不会产生任何不良影响。

至于原因，很难说，你可能需要仔细研究日志。如果是 Express，则可能仅限于启用日志记录的内容，但可能的原因是：

  1. 不正确地关闭 SQL Server 服务（如终止服务、硬重启机器）
  2. 硬件故障
  3. 写入数据时磁盘空间不足
  4. 数据库文件的各种损坏

所有其他方法都失败了，请恢复备份（如果存在）。上述步骤应该让你很快就能运行。

相关内容