迷之自信的Single_User Mode

Alter database Set Single_User

对于任何DBA来说，恐怕都不陌生。在我们需要获取数据库独占访问权来做一些数据库紧急维护的时候，这可能是大多数DBA的首选，但它真的可以实现“独占访问权”吗？

这次我们聊聊Single_User是如何刷新我们认知的

=============================================华丽丽的分割线=============================================

实验目的：测试Single_User模式下是否可以拿到独占权并为所欲为。

照例交代一下我们的环境：Windows 10 + SQL Server 2019，实际上本次实验的结果基本上是覆盖SQL Server全部版本的

并发测试工具：SQLQueryStress（0.9.7.79）

我们先看一下在单用户模式下，持有锁的情况

从上图可以看到，在成功置为Single_User模式后，我们拥有了一个执行Session（id=60）上，DB级别的S锁

这时，我们开启SQLQueryStress，设置查询语句，并发线程数为2，迭代5000次

再次查询持有锁的情况

Session 71、72是我们压力测试工具设置2个线程产生的，可以看到，除了持有S锁外，他们各自还正在申请X锁，只是相互等待而形成了死锁

由上图可以看到，XEvents中存在大量死锁信息，且下图可以看到死锁的细节信息，由Session 71、72导致

此时，当我们再次准备从Session 60中执行语句，将数据库置为Multi_User时，错误发生了:

Session 60也被死锁牺牲了。由此看来，我们并没有真正的获取数据库的“独占访问权”

=============================================华丽丽的分割线=============================================

分析 & 结论：

1、将数据库置为单用户模式在我们长期的认知中，都是绝对的“独占访问权”。但实际上，在有并发+连续访问的情况下，我们仍有可能因外部访问的死锁而丢掉这个“独占访问权”

2、进一步分析，从将数据库置为单用户模式的时候，数据库系统没有直接将Session的锁级别提升至最高（个人理解，从Alter Database触发的动作，置为SCH-X都不为过），而是温和的放置了DB级的S锁，同时对其他访问相同数据库的请求则要求申请X锁，这就导致了，当外部请求访问数据库时，先放置DB级S锁（这里和Single User Session 的DB级S锁且兼容），而后因为要申请X锁，所以和其他访问同样数据库的请求达成了死锁条件。

3、如果在应急处置中仍需要将DB置为Single User模式，建议停掉外部访问（停账号，修改实例端口号，关闭TCP\IP，禁用外部访问网卡，或者修改数据库名称），以免无法置回Multi User模式。