0

问题已经在标题中，但我会尝试在这里提供一些背景。

我有一个myTable正在通过 nHibernate 从 Web 应用程序查询的表。它包含 500K 行。时不时地（假设每 15 分钟）我需要刷新此表内容，即删除所有内容并插入另外 500K 行（可能不同）。

免责声明：是的，我知道这不是正确的架构:-) 不过，无论如何我都需要了解这种行为。

由于插入大约需要 60 秒，这就是我这样做的方式：

  1. 将 500K 行插入myTable_backup
  2. 重命名myTable为myTable_temp
  3. 重命名myTable_backup为myTable
  4. 重命名myTable_temp为myTable_backup

第 2-4 点旨在快速换桌，因此myTable几乎总是可用的。

尽管我的意图是最好的，但我在尝试访问时遇到了 SQL 超时myTable——这或多或少地发生在执行“重命名”的时候。

我的问题是：为什么？

会不会，myTable因为 500K 插入导致索引仍在其上重建，所以它不可用？尽管它已经设法更改了名称，但仍在进行后台重新索引？

如果是这样，是否可以myTable_backup在第 1 点和第 2 点之间显式执行重建索引，有帮助吗？

但随后又弹出另一个问题，这是我对本文的官方问题：第 3 点）是否重命名myTable_backup以myTable导致索引重建？这对我来说似乎是一个奇怪的想法，但是它可以解释我的超时（索引重建大约需要 10 秒）。

你能帮忙吗？如果您不知道答案，也许您可​​以建议如何找出答案？

谢谢，PKD

4

1 回答 1

2

不，重命名表不会导致索引重建。

但它会获得一个SCH-M（模式修改）锁，为此它需要等待任何现有的读者释放他们的锁。

与此同时，任何新的读者都必须在SCH-M锁请求后面排队，而不是跳过队列并可能饿死它。（这是与之前版本的行为变化）。

您可以检查sys.dm_os_waiting_tasks以查看超时期间发生的等待类型。

于 2015-08-16T15:18:29.097 回答