ALTER TABLE NOCHECK CONSTRAINT超时随机

问题描述：

我有一个C＃应用程序，表现ETL过程。对于自引用表，应用程序将运行“ALTER TABLE [tableName] NOCHECK CONSTRAINT [constraintName]”，关闭此表的任何FK约束（s）检查。一旦所有的数据被加载，约束（s）被再次启用。ALTER TABLE NOCHECK CONSTRAINT超时随机

数据库超时设置为3分钟，但是，上面的SQL命令会因30秒内的数据库超时而失败。

什么可能是这个超时的原因？

是否有数据库系统表我应该检查异常？

其他信息：我检查了应用程序，它只有一个活动线程在执行ETL，所以我不认为应用程序锁定了任何数据库资源。另外，数据库与应用程序在同一台机器上运行。

事件应用程序关闭其所有数据库连接，如果它下次运行ETL过程，它将再次超时。如果我使用SQL Manager Studio手动运行SQL，它完全没有问题。

谢谢

更新 - 应用程序正在关闭一些约束。事实证明，超时只发生在1个特定的约束条件下。此约束是引用日期维度表。

更新 - 它看起来像我工作的测试数据库有一些奇怪的异常。我尝试了与其他数据仓库相同的ETL过程，到目前为止它没有问题。团队中的其他开发人员也没有遇到过这个问题。此应用程序每半夜运行一次。我会保持它一夜之间运行，并希望我可以在其他数据库上重现相同的问题。到目前为止，没有运气来弄清楚发生了什么事情。

你提到'数据库超时设置为3分钟...'你在哪里做这个设置？从您的问题中可以看出，30秒内的默认时间仍然如此。 – 2011-01-14 17:30:12

尽管事实上你认为没有其他的连接关系，但我会认为原因会被阻止。我会想象这将是一个快速的元数据更改，所以延迟的唯一范围将等待`Sch-M`锁定。 – 2011-01-14 18:04:49

答

更改表格需要对表格进行排它锁定。如果有另一个进程正在读取/写入正在讨论的表，那么在该进程释放其锁之前，无法进行模式更改。

当您经历表的长时间运行时，请在不同的连接中运行sp_who2，并查看是否有任何连接阻塞了ETL连接。然后，您可以查看该连接的命令缓冲区，以确定其操作。

ALTER TABLE NOCHECK CONSTRAINT超时随机

相关推荐