Oni*_*ght 12 sql-server maintenance locking
尝试运行我的维护计划时，我收到以下错误：
执行查询“”失败，出现以下错误：“无法重新组织表“”上的索引“”（分区 1），因为禁用了页级锁定。”
我们目前在此索引上启用了行级锁定。我可以启用页面级别锁定，但我不确定影响是什么。
我的问题是：这两种锁定方案有什么区别，它们在现实世界（生产中）的后果是什么？
Mar*_*ith 15
执行查询“”失败，出现以下错误：“无法重新组织表“”上的索引“”（分区 1），因为禁用了页级锁定。”
维护计划必须尝试 ALTER INDEX REORGANIZE，这是一项联机操作。要删除碎片（页面不按顺序），必须锁定和移动页面，如果禁用了页面锁定，则这是不可能的。在没有页面锁定的情况下进行碎片整理的唯一方法是锁定整个分区，这对于 REORGANIZE 仅联机是不可能的。
这两种锁定方案有什么区别，它们在现实世界（生产中）的后果是什么？
您需要了解记录和页面是什么来评估禁止特定锁定类型的影响。如果您不熟悉 SQL Server 存储内部结构，请从Anatomy of a Record和Anatomy of a Page 开始。说得非常简单：
如果您要更改允许的锁类型：
我知道有两种情况可以禁止锁定类型。并不意味着没有其他人，希望其他人能够举出例子。
频繁访问的查找表，不经常更改- 通过禁用页级和行级锁，所有读者都将获得共享表锁。这比通常的表上的意图共享更快/更便宜，然后是页面上的意图共享，最后是特定行上的共享锁。
防止特定死锁场景- 如果遇到由并发进程获取频繁位于同一页上的锁而导致的死锁，则禁止行锁会导致使用页锁。一次只有一个进程可以访问该页面，另一个进程必须等待。
第一个例子是微观优化，不太可能在典型系统上产生可衡量的好处。第二个将解决那个特定的死锁场景，但可能会引入意想不到的副作用，例如在不同的代码部分杀死并发。难以全面评估影响，谨慎进场！
默认情况下两者都启用，如果没有正当理由，不应更改此设置。
大概什么都没有。我相信 MS 比你或我更了解
我曾在大容量 OLTP 系统上工作过，从未觉得需要更改设置。应该重试死锁，因为它们无论如何都会发生
引自SQL Server 存储引擎博客“SQL2005 中的锁升级” n，无论如何都值得一读。
默认情况下，我们同时启用了 ROW 和 PAGE 锁...SQL Server 在大多数情况下选择 ROW 锁粒度，但可能会在适当的情况下选择 PAGE 锁。因此，对于您指定的情况，可能是 ROW 锁定。无法在数据库或实例级别关闭 PAGE 锁定。您是否因 PAGE 锁定而遇到阻塞？
我认为，如果您只强制行锁，那么您将消耗可以在其他地方更有效地使用的资源。如果您的负载足够高，那么为什么要消耗内存？博客文章进入了这个
我怀疑这背后有一些迷信，就像这些：