首先，是的，收缩是不好的。永远不要使用它。我明白。不幸的是，这是一种 SOP，我无法争论，因为它通常是权宜之计，直到我们可以获得一个维护窗口来分配更多空间并重建/重组索引。
我们最近遇到了一个问题，我们从传统备份切换到第三方工具。由于数据库的大小和我们最近删除的一些大对象，在转换之前使用新工具进行干净备份之前缩小它是有意义的。我有一些保留意见，但我们继续这样做，因为它很少引起问题。显然，清除日志并不是真正的问题，但我们正在缩小 mdf。这导致了对少数大型、高度事务性对象的大量阻塞，并且正确地提出了一些关于我们如何使用它的非常严重的问题。
我已经做了很多研究，但还没有找到足够让我满意的细节。
是否有任何地方可以实际描述 SHRINK 操作的内部结构？
有没有办法确定哪些物体比其他物体更碎片化以及它如何释放空间？或者，与表中的其他表相比，表的碎片化程度是否无关紧要，并且更多的是关于对象的整体大小？
保罗兰德尔在这里谈了一点，但还不够详细。
我知道您可以基于 dm 索引统计数据进行排序，但是由于大小和过度索引，在我们的一些较大的数据库上运行非常困难。我也不确定这是否就是我需要关心的全部。主表存储为堆，只有索引真正碎片化，但我不确定不同的分区如何影响事物，或者底层数据库的其他部分是否也可以被释放。
我确实也看到了这个问题，但我不确定我是否能够将它配置为我们正在寻找的那种粒度。
链接服务器“001”的 OLE DB 访问接口“SQLNCLI11”返回消息“由于打开服务器连接延迟，无法完成登录过程”。消息 7303，级别 16，状态 1，第 19 行无法初始化链接服务器“001”的 OLE DB 访问接口“SQLNCLI11”的数据源对象。
我意识到有很多潜在适用的 SO 帖子和谷歌点击（其中许多我已经阅读了很多次），所以让我来看看我们所看到的和我们已经尝试过的。老实说，我现在不知道还有什么可看的。
我们将链接服务器 001（目标）转到 002（源）作为 SQL 登录名，该登录名从 C#/.Net 应用程序代码作为 proc 通过数据访问方法和 SSPI 连接字符串通过具有适当权限的服务帐户调用。我相信 .Net 版本是 4.3，现在是 4.7，但问题在两者中都存在。它是从不同网络上的旧 2008R2 环境迁移而来的，这在物理设备上从来都不是问题，而且两个新的当前都是 64 位 2016 虚拟机。
它在问题期间始终可重现，但在其他情况下则不然，并且似乎总是相同的调用。对于阻塞/死锁/奇怪的锁定页面或对象，sp_what 中没有显示任何内容。如果未报告该问题，则该问题将无法重现。有时它只发生一次或两次，有时持续 10-15 周，然后它会正常工作数周。不确定它是否相关，但是当我们看到这个时，应用程序偶尔也会显示线程中止，但我认为这更像是一种症状。
我在这里缺少什么？