SQLServer误区30日谈

Paul S. Randal是首屈一指的SQL Server专家，这个关存储备份的系列文章揭示了大多数误区，本系列文章不仅仅是每篇文章所涵盖的知识点，每一篇文章都可以看作一个知识块的切入点。我们团队将这个系列进行了翻译，目录如下，希望你看完有所收获。 SQL Server误区30日谈系列文章深入探讨了在使用Microsoft SQL Server时常见的错误理解和实践，由著名SQL Server专家Paul S. Randal撰写，涵盖了多个关键领域，以下是对文章中提到的知识点的详细解读。 误区#1：服务器故障转移后，正在运行的事务继续执行 当SQL Server实例发生故障转移时，例如使用集群、镜像、日志传送或SAN复制技术，原先正在执行的事务不会继续执行。故障转移发生时，由于连接可能被断开，SQL Server在新的服务器上无法重新建立事务上下文，导致所有未提交的事务将被回滚。对于故障转移集群，新的节点将重新启动实例，而数据库需要经历Recovery阶段；数据库镜像和事务日志传送则涉及日志的Redo和Undo操作；SAN复制则涉及I/O的远程重放。在所有情况下，Recovery步骤是必须的，以确保数据库的一致性。唯一能够让正在执行的事务在故障转移后继续执行的情况是使用具有实时迁移功能的虚拟化技术，因为连接在技术上并没有断开。但是，如果连接失效，正在执行的事务还是会丢失，因此需要在应用层实现事务重试的逻辑。 误区#2: DBCC CHECKDB会引起阻塞 DBCC CHECKDB是一个用于检查SQL Server数据库完整性的命令，过去的版本可能会因为加锁机制导致阻塞。早期版本的DBCC CHECKDB通过嵌套循环和表锁来检查数据的一致性，这种机制效率低下且会造成阻塞。在SQL Server 2000时代，Steve Lindell改进了DBCC CHECKDB，通过分析事务日志来检查数据一致性，尽管这样做不需要阻止日志截断，但是仍然存在检查失败的情况，并且还会使用SCH_S锁，这仅阻塞表扫描和表结构的改变。在SQL Server 2005时，Paul Randal进一步改进了DBCC CHECKDB，引入了数据库快照技术，允许在不需要对原数据库加锁的情况下检查数据一致性。使用数据库快照技术后，DBCC CHECKDB不会产生任何锁，从而避免了阻塞问题。不过，如果用户显式地使用WITHTABLOCK提示，仍会引发表锁，这种做法并不推荐，因为它会延长操作时间并可能引发资源争用。 这些误区揭示了在使用SQL Server时需要特别注意的问题，以及随着时间推移，一些命令和操作在不同版本的SQL Server中所经历的改进。通过纠正这些误区，数据库管理员和开发者可以更有效地维护SQL Server数据库的稳定性和性能。对于那些希望深入了解DBCC CHECKDB命令全面信息的人，Paul Randal建议阅读相关的详细文章，其中包含了DBCC CHECKDB的各个阶段描述、可能的资源不足问题、数据库快照在遇到问题时的行为以及DBCC CHECKDB使用隐藏快照时可能出现的问题。