vnsc5858威尼斯城官网 > 编程技术 > 重新创设索引

原标题:重新创设索引

浏览次数:82 时间:2019-09-21

USE [数据库名]
GO
ALTER INDEX <索引名> ON dbo.<表名> REBUILD PARTITION = ALL WITH ( MAXDOP = 4, ONLINE = OFF, SORT_IN_TEMPDB = OFF )
GO

Ps:下图里的object_id与之前的不同是因为不是一个表,无需在意。

先试了下聚集索引的重建,以下是相关会话的所有加锁情况:

因此重建聚集索引的过程中会对表和涉及的索引加Sch-M的架构锁,而此架构锁与所有其他锁冲突,因此不能再执行任何针对此表的增删改查。

图片 1

在SQLOS的任务调度算法中,有一个概念叫做context switch,同计算机原理中的CPU切换一样,意思是同一个CPU针对并发的会话进行线程切换。我们这里只有一个会话一条语句,因此猜测是并行造成的现象。

之后测试了非聚集索引的情况,加锁情况一致因此不作讨论。

这里出现了4个TAB类型的S锁和一个表级的Sch-M锁以及一个聚集索引的Sch-M锁,从官网提供的锁兼容图来看S锁和Sch-M锁是不兼容的,因此这几个S锁的出现就比较诡异了,查看dm_tran_locks发现request_exec_context_id不一样,而官网对此字段的解释就一句:Execution context ID of the process that currently owns this request.

所以这里有一个问题:不同的request_exec_context_id代表的TAB类型的S锁到底是什么?为何与Sch-M锁不冲突?

55     5     1589580701 0     TAB         S     GRANT
55     5     1589580701 0     TAB         S     GRANT
55     5     1589580701 0     TAB         S     GRANT
55     5     1589580701 0     TAB         S     GRANT
55     5     1589580701 0     TAB         Sch-M   GRANT
55     5     1605580758 0     TAB         Sch-M   GRANT

从以上的锁分布情况来分析,首先我们过滤掉所有非相关表的锁,那么整个结果集只剩下了6行:

图片 2

事后进行了多次测试,发现开不同的并行数(MAXDOP)目得到的S锁数目与并行数一样,因此这里得request_exec_context_id每个值对应一个并行线程。而针对同一个资源S锁和Sch-M是不兼容的,因此感觉这里的S锁是一个显示小BUG。

昨晚某现场报一个重建索引失败的问题,远程查看后发现是自动收缩的内部会话引发的锁申请超时,突然想起来自己的加锁实验还没完成索引重建部分,今天有空正好做一下:

本文由vnsc5858威尼斯城官网发布于编程技术,转载请注明出处:重新创设索引

关键词:

上一篇:没有了

下一篇:安装及配置mysql,7安装教程