无法使服务器上的任何数据库联机
Unable To Bring Online Any Database On A Server
周末我的开发服务器遇到了一个非常有趣的问题。我有一个脚本，可以定期使多个数据库脱机，然后再将它们重新联机。他们 运行，并使所有指定的数据库脱机，但随后未能使它们再次联机，指定的错误消息是：
Msg 5011, Level 14, State 7, Line 4 User does not have permission to
alter database 'XXX', the database does not exist, or the database is
not in a state that allows access checks. Msg 5069, Level 16, State 1,
Line 4 ALTER DATABASE statement failed.
这对我来说似乎不对，因为我们 运行 来自具有以下属性集的用户帐户：
我通过登录到该服务器进一步验证这不是权限问题，运行以管理员身份使用 SSMS 并使用我的 windows 凭据（也是管理员帐户）登录并在离线数据库上执行以下 SQL：
USE [master]
GO
ALTER DATABASE [XXX] SET ONLINE
GO
结果相同...
我查看了 SQL 日志以了解有关特定错误的更多详细信息，但是没有与此问题相关的条目。我可以在此特定服务器上的每个数据库上重现此问题。我能够使数据库联机的唯一方法是取消附加并重新附加它们。
涉及此错误消息的大多数其他堆栈溢出票据特定于一个数据库或特定用户帐户。我的问题涉及我到目前为止尝试过的所有数据库和所有管理员用户，我的问题也发生在一个脚本上，该脚本以前在此服务器和帐户上运行良好，显然周末发生了一些变化，导致此查询现在失败。我想知道是否有其他人以前遇到过这个问题？
更新 1
This post 谈到文件安全如何触发此错误消息，我 g运行 对其中一个数据库上的用户组进行完全访问，然后重新运行 在线命令，没有运气。我的 SQL 服务器服务 运行 正在 "Administrator" 用户组的服务帐户下运行，并且对所有数据库文件具有完全访问权限。
更新 2
各种有趣的点子put forward here, also discussed here。关于如何使用 SQL 命令等多种修复组合修复损坏数据库的许多命令和想法，不幸的是 none 它们在我的情况下有效，它们要么不会 运行 离线数据库，或者在分离和重新附加之后不报告任何错误。当然，总是有一些帖子简单地坚持认为解决方案是基于许可的，并且 运行ning: GRANT ALTER ON DATABASE 将解决所有问题。对于我的管理员用户帐户，它应该没有什么区别，但这是一个有争议的问题，因为我什至不能 运行 在离线数据库上执行该命令...
终于找到了问题所在，显然我们在同一台服务器上有一个完全不相关的 SQL 数据库实例处于恢复模式。在它恢复期间，我们无法将任何离线实例联机。 Detach/re-attach 可以，我们可以很好地恢复数据库，但不能将其设置为联机。
单独的数据库已完成恢复，我们现在可以运行命令没有问题。我想将来，如果我不关心正在恢复的数据库（我经常不关心），我会按照 the linked steps 来摆脱它，然后重新启动 SQL 服务器和进行中：
Stop SQL Server
Delete MDF + LDF
Start SQL Server
Restore (may need to drop first, comes up suspect)
周末我的开发服务器遇到了一个非常有趣的问题。我有一个脚本，可以定期使多个数据库脱机，然后再将它们重新联机。他们 运行，并使所有指定的数据库脱机，但随后未能使它们再次联机，指定的错误消息是：
Msg 5011, Level 14, State 7, Line 4 User does not have permission to alter database 'XXX', the database does not exist, or the database is not in a state that allows access checks. Msg 5069, Level 16, State 1, Line 4 ALTER DATABASE statement failed.
这对我来说似乎不对，因为我们 运行 来自具有以下属性集的用户帐户：
我通过登录到该服务器进一步验证这不是权限问题，运行以管理员身份使用 SSMS 并使用我的 windows 凭据（也是管理员帐户）登录并在离线数据库上执行以下 SQL：
USE [master]
GO
ALTER DATABASE [XXX] SET ONLINE
GO
结果相同...
我查看了 SQL 日志以了解有关特定错误的更多详细信息，但是没有与此问题相关的条目。我可以在此特定服务器上的每个数据库上重现此问题。我能够使数据库联机的唯一方法是取消附加并重新附加它们。
涉及此错误消息的大多数其他堆栈溢出票据特定于一个数据库或特定用户帐户。我的问题涉及我到目前为止尝试过的所有数据库和所有管理员用户，我的问题也发生在一个脚本上，该脚本以前在此服务器和帐户上运行良好，显然周末发生了一些变化，导致此查询现在失败。我想知道是否有其他人以前遇到过这个问题？
更新 1
This post 谈到文件安全如何触发此错误消息，我 g运行 对其中一个数据库上的用户组进行完全访问，然后重新运行 在线命令，没有运气。我的 SQL 服务器服务 运行 正在 "Administrator" 用户组的服务帐户下运行，并且对所有数据库文件具有完全访问权限。
更新 2
各种有趣的点子put forward here, also discussed here。关于如何使用 SQL 命令等多种修复组合修复损坏数据库的许多命令和想法，不幸的是 none 它们在我的情况下有效，它们要么不会 运行 离线数据库，或者在分离和重新附加之后不报告任何错误。当然，总是有一些帖子简单地坚持认为解决方案是基于许可的，并且 运行ning: GRANT ALTER ON DATABASE 将解决所有问题。对于我的管理员用户帐户，它应该没有什么区别，但这是一个有争议的问题，因为我什至不能 运行 在离线数据库上执行该命令...
终于找到了问题所在，显然我们在同一台服务器上有一个完全不相关的 SQL 数据库实例处于恢复模式。在它恢复期间，我们无法将任何离线实例联机。 Detach/re-attach 可以，我们可以很好地恢复数据库，但不能将其设置为联机。
单独的数据库已完成恢复，我们现在可以运行命令没有问题。我想将来，如果我不关心正在恢复的数据库（我经常不关心），我会按照 the linked steps 来摆脱它，然后重新启动 SQL 服务器和进行中：
Stop SQL Server
Delete MDF + LDF
Start SQL Server
Restore (may need to drop first, comes up suspect)