我使用 sp_rename 作为 ETL 存储过程过程的最后一步来切换临时表和最终表的名称。
由于此操作需要 SCH M 锁，所以我面临以下情况。
假设一个长时间运行的 SELECT 查询正在 FINALTABLE 上运行，此时存储过程也被调用并且它已到达 sp_rename 语句，那么 FINALTABLE 上的任何其他 SELECT 查询都会被阻止。
我理解这是因为选择查询 (SCH S) 在 sp_rename (SCH M) 后面排队。
我正在阅读有关处理此问题的方法，解决方案似乎是使用分区切换和等待低优先级语法，这有助于在一定时间后终止正在进行的 SELECT 或 ALTER TABLE 查询。然而，分区切换的第一步是截断最终表，这也会在最终表上获取 SCH M 锁，并且无法在 truncate 语句上以低优先级使用 wait。因此，在持续的长时间选择查询期间，当调用 SP 导致运行 truncate 语句时，此时截断会被阻止，因为它需要 SCH M 锁，因此它会阻止来自其他会话的所有后续选择查询。
因此，我试图了解在这方面与使用 sp_rename 相比，分区切换究竟如何更好，以防止出现上述情况。
在事务中，您可以将最终表切换到另一个空临时表，而不是截断它。 完成后，您将拥有 Sch-M 锁，并且切换临时表将会成功。
第一个交换机可以以低优先级等待，因此新的 SELECT 查询不会被阻止。
或者，您可以使用 RCSI 并更新插入最终表，从而无需任何 Sch-M 锁。