迷之自信的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 Mode插图迷之自信的Single_User Mode插图(1)

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

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

迷之自信的Single_User Mode插图(2)

再次查询持有锁的情况

迷之自信的Single_User Mode插图(3)

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

迷之自信的Single_User Mode插图(4)

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

 

迷之自信的Single_User Mode插图(5)

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

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

迷之自信的Single_User Mode插图(6)

 

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

分析 & 结论:

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

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

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

本站资源均源自网络,若涉及您的版权、知识产权或其他利益,请附上版权证明邮件告知。收到您的邮件后,我们将在72小时内删除。
若下载资源地址错误或链接跳转错误请联系站长。站长q:770044133。

» 迷之自信的Single_User Mode

发表评论

免登录下载网,提供全网最优质的资源集合!