SQL Server故障转移误区解析

"SQL Server误区30日谈——解析常见误解与解决方法" 本文系列源自sqlskill.com上PAUL的博客，聚焦于SQL Server中容易出现的误区，并提供了相应的解决方案。文章通过团队的翻译和整理，发布在AgileSharp平台上，旨在帮助读者理解和避免在SQL Server管理与使用过程中可能遇到的问题。 误区#1: 在服务器故障转移后，正在运行的事务继续执行 这个观点是不正确的。在任何类型的故障转移（如集群、镜像、日志传送或SAN复制）中，都会伴随数据恢复过程。当服务器或实例崩溃导致未提交的事务中断时，SQL Server无法在新服务器上重建事务上下文并继续执行。例如： - 集群故障转移时，新的SQL Server实例在另一个节点启动，所有数据库都要经历恢复，回滚未提交的事务。 - 数据库镜像中，日志不断传输至镜像服务器，切换后，原镜像服务器的日志进入恢复模式，回滚未完成的事务。 - 日志传送方案下，辅助服务器在主服务器崩溃后恢复，同样涉及回滚未提交事务。 - SAN复制情况下，尽管I/O复制到远程站点，故障转移后仍需执行恢复步骤，回滚未提交事务。 唯一可能在不丢失事务的情况下实现故障转移的技术是使用支持实时迁移的虚拟化技术，但即便如此，如果连接中断，仍需在应用程序层面实现事务的重新执行逻辑。 误区#2: DBCC CHECKDB会引起阻塞，因为它默认加锁 这是一个误导。在SQL Server 7.0及更早版本中，DBCC CHECKDB确实可能导致阻塞，因为它默认会对数据库加锁。但在后续版本中，SQL Server优化了这一行为，现在DBCC CHECKDB默认在检查模式下运行，不会锁定整个数据库，允许其他读取操作同时进行。当然，如果需要更全面的检查，可以使用WITH CHECKSUM选项，这可能会影响并发性，但通常在维护窗口执行此操作以减少影响。 这些误区揭示了理解SQL Server核心概念的重要性，包括故障转移、恢复机制以及DBCC命令的正确使用。通过深入了解这些知识，可以更好地管理和保护数据库，确保高可用性和数据完整性。