SQLServer误区详解：事务处理与故障恢复

"SQLServer误区30日谈" 在SQL Server的使用过程中，存在许多常见的误解，这些误解可能导致不必要的问题甚至数据丢失。以下是对标题和描述中提到的两个误区的详细解释： 误区#1：在服务器故障转移后，正在运行的事务继续执行 实际上，无论是通过集群、数据库镜像、日志传送还是SAN复制进行的故障转移，都无法保证正在执行的事务在故障转移后能够继续执行。这是因为每次故障转移都伴随着恢复过程，未提交的事务在新的服务器上会被回滚。例如，故障转移集群会进行数据库恢复，数据库镜像会在切换后进行Redo操作并进入恢复模式，日志传送需要执行恢复步骤，而SAN复制也会有类似的恢复过程。只有使用支持实时迁移的虚拟化技术，才能在一定程度上保持事务的连续性，但这依然不保证所有事务都能继续，因此需要在应用程序中实现事务重试机制。 误区#2：DBCC CHECKDB会引起阻塞，因为这个命令默认会加锁 这是一个常见的误解。实际上，自SQL Server 7.0以来，DBCC CHECKDB命令默认使用一种叫做"离散页检查"（disconnected page checking）的模式，这不会对其他用户造成阻塞。在这个模式下，DBCC CHECKDB可以并发运行，不会锁定整个数据库。然而，如果需要对整个数据库进行更严格的检查，可以使用WITH CHECK_OPTION参数，这将导致检查过程中锁定数据库，但这通常只在数据库维护窗口期间执行。 除此之外，了解这些误区可以帮助我们更好地理解和规划SQL Server的高可用性和灾难恢复策略。例如，为了确保事务的完整性和一致性，应当设计应用程序以处理可能的事务丢失情况，包括在故障转移后重新执行未完成的事务。同时，使用DBCC CHECKDB进行数据库健康检查时，可以放心地在生产环境中运行，因为它在大多数情况下不会引起阻塞。在进行深度检查时，应选择合适的时间窗口，并考虑可能的锁定影响。 理解SQL Server的工作原理和这些误区，能帮助管理员和开发人员避免潜在的问题，提高系统的稳定性和可靠性。通过学习和掌握正确的知识，我们可以确保SQL Server的高效运行，并为关键业务提供更强大的保障。