sql - 由于长时间运行的事务，SQL Server 2000 中的数据不一致

Question

我们在其中一台生产服务器中面临一种情况。
我们有一个特定的存储过程，它对数据库中最大的表之一执行插入操作(它有超过几百万行)。该表是数据库中最繁忙的表，并且有许多操作依赖于它。

最近，我们在一台特定的生产服务器上遇到了问题。

我们在一个事务中执行插入 SP 和其他一些更新 SP，并且我们经常面临插入 SP 的“长时间运行事务”问题。当我们遇到这个问题时，我们会发现插入表中的数据的典型行为。日期时间列值被插入为“空”。它有时会发生在所有行中，有时会发生在几行中。日期时间值是从应用程序传递的。
但是在插入操作之前和之后执行的其他更新操作运行良好。

我们在我们的测试环境(不在生产​​服务器中)运行了 sql profiler trace，但发现日期时间值每次都被正确传递。

同样，当我们在生产中遇到问题时，我们观察到:

@@trancount 等于 '0' 但
DBCC OPENTRAN 显示
特定的公开交易。

Last Wait 类型的值为“NETWORKIO”。

等待类型是“0x0000”。

状态是“ sleep ”。

隔离级别未提交。

所以我们关心的是

为什么仅在这种特殊情况下才将日期时间插入为“NULL”？

如何避免这种情况以及长时间运行的事务？

在一台特定服务器中出现这种情况的原因可能是什么？

在此先感谢您的帮助，

阿比 git

Answer 1

我认为这里有几件事需要同时解决。首先，也是最重要的一点，我强烈建议您查看该事务，以了解您可以采取哪些措施来减少它给您的系统带来的负载。它可以分解成多个较小的交易吗？添加更好的索引会有帮助吗？捕获数据的子集并将其放入临时表会减少对主表运行的 SELECTS 数量吗？这里的问题 list 可能会持续一段时间。

接下来，查看启动事务的“应用程序”。它正在传递日期？如果是这样，它是如何做到的？如果只是传入GetDate()然后它让 SQL Server 完成工作。但是，如果应用程序传入日期值，我会确保该日期值始终有效。如果是，请查看表格以确保日期格式设置正确。例如，如果您的应用程序以 14-05-2011 的欧洲日期格式通过，如果您的应用程序期望 Month-Day-Year 因为 14 不会转换为一个月，则它可能会窒息。

第三，查看您的表格，看看您是否在表格上设置了任何触发器。如果这样做，请非常仔细地查看每个触发器。触发器很可能在您的事务中引起冲突。也许您正在写入数据并且您的触发器正在返回并更新数据(或者它正在评估日期并说它无效 - 请参见上面的示例)。

第四，在离开交易前检查数据。进来就读，在INSERT之后再读已执行。可能在事务完成后正在进行的客户端操作会清除日期值。

最后，您需要查看您的测试环境。如果这在测试中有效但在生产中无效，则两个系统之间存在某些不同。这就是原因，无论是直接的还是间接的。也许它与硬件有关(坏 RAM？)或者它的设置有所不同(锁定，客户端试图对数据执行操作的事实等)

除此之外，这是一个论坛链接，其中包含一些其他可能的答案:

http://groups.google.com/group/comp.databases.ms-sqlserver/browse_thread/thread/1063b65df1f97492/8649bee2002646a2