我们将SQL Server 2008与主体，镜像和监视器服务器一起设置，镜像被同步并设置为自动故障转移。 我们最近发现，在主服务器上空间不足的情况下，尽pipe应用程序运行的每个查询都返回了一个错误，但它使用数据库使应用程序瘫痪，但并未导致故障切换：
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和查询（所有这些都是有错误的）？ 还是这是我们错误的configuration？ 我们是否需要在应用程序层添加代码来检测这样的数据库错误并启动故障转移？
同时，我们正在改进我们的监控，以尽量避免磁盘空间问题，但我们仍然希望提高自动故障切换的可靠性。
在这种情况下，你的数据库不是“closures”，只是由于空间或分配问题而导致日志填满。 仅当主数据库/实例脱机时，才会发生故障转移，然后证人和镜像可以决定镜像应该是新的主要数据库。
您可以定期运行脚本（或使用SQL警报）来检查这种情况，然后启动故障转移，但这可能有点棘手。
您configuration错误 – 但不是在SQL Server上。
错误：*使用扩展文件而不注意操作系统级别（可用磁盘空间）*当光盘开始进入定义的关键级别时，显然没有任何操作pipe理进程。 *然后想知道为什么事情失败。
基本上：数据库上的discc子系统从来没有满 – 错误不是“全盘”，而是“无能的pipe理员”。
人们可以争论SQL Sever shuld是否已经故障了，但是鉴于这是一个完全是操作服务器的问题，我不希望SQ LServer来处理这个问题。
顺便说一下，生产负载数据库不会扩展文件;）正确调整它们的大小，调整它们的大小，但不要自动扩展它们。