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