重建索引

作者: 数据库信息  发布:2019-06-26

图片 1

所以重建聚焦索引的长河中会对表和涉及的索引加Sch-M的架构锁,而此架构锁与具备其余锁争执,因而不能够再奉行其它针对此表的增加和删除改查。

在SQLOS的职分调节算法中,有一个概念叫做context switch,同Computer原理中的CPU切换同样,意思是同叁个CPU针对并发的对话进行线程切换。我们那边只有多个会话一条语句,因而疑忌是互相产生的场景。

自此测验了非集中索引的图景,加锁景况一致因而不作研讨。

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

尔后展开了往往测量试验,发掘开分裂的并行数(MAXDOP)目得到的S锁数目与并行数同样,因而这里得request_exec_context_id每一个值对应三个相互线程。而针对性同贰个能源S锁和Sch-M是不相称的,由此以为这里的S锁是贰个显得小BUG。

这里出现了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.

今早某现场报二个重建索引退步的题目,远程查看后发掘是全自动收缩的在那之中会话引发的锁申请超时,突然想起来本身的加锁实验还没完毕目录重建部分,明日有空正好做一下:

图片 2

据此那边有三个难题:区别的request_exec_context_id代表的TAB类型的S锁到底是什么?为什么与Sch-M锁不争辨?

Ps:下图里的object_id与事先的不等是因为不是二个表,没有须求在意。

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行:

先试了下聚焦索引的重建,以下是连锁会话的持有加锁意况:

本文由金沙澳门官网发布于数据库信息,转载请注明出处:重建索引

关键词: 金沙澳门官网