我们安装了 SQL Server 2008，其中包含主服务器、镜像服务器和监视服务器，镜像服务器已同步并设置为自动故障转移。我们最近发现一种情况，主服务器上的空间不足，这导致使用数据库的应用程序瘫痪，但没有导致故障转移，即使应用程序运行的每个查询都得到了错误答复：
The transaction log for database 'XXXX' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
我正在尝试弄清楚为什么没有发生故障转移。是因为镜像/见证服务器仍然认为服务器在响应 ping 和查询时处于启动状态（尽管都存在错误）吗？还是我们配置错误了？我们是否需要在应用层添加代码来检测此类数据库错误并启动故障转移？
同时，我们正在改进我们的监控，以尽量避免磁盘空间问题，但我们仍然希望提高自动故障转移的可靠性。
答案1
在这种情况下，您的数据库并没有“宕机”，只是由于空间或分配问题导致日志填满。只有当主数据库/实例脱机时才会发生故障转移，然后见证服务器和镜像服务器可以决定镜像服务器应为新的主数据库/实例。
您可以定期运行脚本（或使用 SQL 警报）检查此情况，然后启动故障转移，但这可能有点棘手。
答案2
您的配置错误 - 但不是在 SQL Server 上。
错误：* 使用扩展文件而不观察操作系统级别（可用磁盘空间）* 磁盘开始进入定义的临界级别时，显然没有适当的操作管理程序。* 然后想知道为什么事情会失败。
基本上：数据库上的 discc 子系统永远不会满 - 错误不是“磁盘已满”，而是“管理员不称职”。
人们可以争论 SQL Sever 是否应该进行故障转移，但鉴于这种情况完全是操作服务器的问题 —— 抱歉，我不指望 SQL Server 可以处理这个问题。
顺便说一句，生产负载数据库永远不应该扩展文件；）适当调整它们的大小，尽可能调整它们的大小，但永远不要自动扩展它们。