我对鬼魂清理过程的理解是，每五秒钟它就会去除一个索引中的鬼影logging。 所以它不会使系统过载，一次只能“清理”大约十页。
那么，这意味着它每五秒只能清理大约80K的logging？ 看起来像我的索引总是会充满幻影logging，清理永远不会完成。
所以，假设我运行了一个删除操作（可能是一百万行），这些数百万行的索引logging大小约为8Gb。 大约是80k的10万倍。 这是否意味着鬼魂清理过程将花费50万，或者将近六天才能完成？
显然我在这里错过了一些东西，因为清理幻影logging需要很长时间是没有意义的。 那么其他的活动也是如此呢？ 幽灵清理过程是否导致等待，或者必须等待其他过程？
[我们在OpsMgrDW中看到的性能问题带来了这个问题，我们想更多地了解这个过程]
我写了两篇全面的博客文章来解释幽灵的清理（这是唯一可以在任何地方，无论是在印刷版还是在网上进行解释的地方）。
第一个是在存储引擎内部：深入的Ghost清理，第二个是Ghost清理还原 。 是的，每次都有10页，而且鬼的清理任务可能无法赶上大量的连续删除。
通过确保存储引擎能够“看到”幻影logging，可以大大触发除10页 – 每5秒之外的Ghost清除。 使用类似的方法强制扫描受影响的表或索引
（index = problem-index）从[problem-table]中select*
这将排队请求清理幽灵纪录积极。 但要小心，它会产生大量的事务日志。 它们也应该通过索引重build或重新组织，作为定期索引维护的一部分。
希望这可以帮助。
我一直认为索引重build会在结构转移时“修复”剩余的问题。
几年前，我遇到了这个问题，无法通过configuration修复它，触发了幽灵清理，或者其他类似的事情。 我正在使用一个连续插入和删除的数据库，并且由于ghost清除触发，SQLServer会有效地locking。
我最终的解决办法是按时间分解问题表，而不是删除旧的行，我只能删除旧的表。 这非常有帮助。 这可能不适合你的情况，但适用于很多，有一些变化。
我们也有类似的情况。 我们的表中有一个鬼logging很多，这些logging不是由Ghost清理过程清理。 DB收缩，DBCC Cleantable，重build索引和重组索引没有用。 为了解决这个问题，我们将数据传输到临时表，然后将表格trucate并将数据传回到截断表。 该表包含LOB数据（2个nvarchar（最大）列）。 有没有其他方法可以解决这个问题？