应用错误收集

我有一个多流程方案。因此，多个Windows应用程序从不同的PC连接到数据库。

我有两个表的简单构造：

我有一个tblSessions，其中每个进程都有一个使用autoincrement int Id字段的条目
我有一个tblJobs，它使用级联删除从tblSession引用ID。因此，当会话被删除时，所有作业都被删除到。而且tblJobs具有一个autoincrement int Id字段 tblSession中的记录会定期更新。创建和删除记录是一种罕见的事件。

tblJobs被大量使用。记录由INSERT INTO插入。所有较大的操作首先在tblJob上执行TABLOCKX，以防止出现任何死锁情况。从记录中删除记录，并使用简单的DELETE给出作业的特定ID。 tblJobs中的条目数约为100-5000条记录。每行包含5个INT，1个DATETIME字段和1个UID。所以桌子真的很小。因此，它不是大量记录，但是我们在表上运行着永久的INSERT/DELETE语句。

我们在客户站点上发现了运行我们的软件并使用SQL Server 2008（标准版）的问题。我们实施了一些测试程序，并隔离出一个真正的奇怪效果，这种效果在我们的客户身上出现。

我们有一个测试例程，该例程执行简单的SELECT COUNT(*) FROM tblJobs WHERE Data=…来检查我们收集的信息是否仍然正确。通常，此查询应始终返回1！
我们在应用程序中进行更长的计算时就启动了测试，它报告了所需的信息，并成功返回1
记录被重复插入并从tblJobs中删除。
现在程序将运行30秒（最多5分钟），并重复上述测试。现在，tblJobs记录没有显示所需的信息。测试语句返回0，因此没有包含所需信息的记录。并且执行SELECT * FROM tblJobs就像执行下一个操作一样不会显示预期的记录。（两个SELECT语句都不属于一项事务）
由于缺少记录，该过程终止。如果我们不做测试，那么下一条语句将只更新静态表中的一条记录，然后从作业表中删除该记录（丢失的记录），然后继续……是的，我可以忽略这种影响，但是却使我迷失了……记录不应该消失。

隔离级别应为READ COMMITED。但是我看到的情况是我看到与READ UNCOMMITED的会话。在寻找解决方案以及我们遇到问题的原因时，我找到了该SO链接SQL Server: Isolation level leaks across pooled connections

我找不到某些会话显示永久隔离级别READ COMMITED的原因。发生错误时，我也无法说出隔离级别。

我也可以说这仅在SQL Server负载很重的情况下发生。如我所见，服务器没有内存压力。

我做什么：

我产生了完整的SQL事件探查器跟踪。我们可以将其减小为仅100000条语句。从将条目插入到tblJobs的过程开始，直到我们发现SELECT COUNT（*）FROM…WHERE…为所需记录返回0。
在发生错误的那一刻，我们有41个客户端在运行（tblSessions中有41个条目）。 tblLocks大约有3000条记录。
在事件探查器跟踪中，我们找不到丢失记录的任何DELETE语句。我们可以找到数百个影响其他记录的更新，插入和删除。但不是我们要寻找的这张记录。当然，tblSession记录仍然存在，并且该会话的其他记录也仍然存在。

我们还创建了具有相同需求和软件的测试方案，但我们永远无法解决问题。

对程序进行更改并将其推广给客户并非易事。因此，我无法快速提供新信息。

所以我的问题：

在隔离级别为READ COMMITED或READ UNCOMMITED的情况下，是否存在SELECT COUNT（*）语句可能丢失先前返回的记录而又未返回的记录的情况？是否存在导致记录不出现在SELECT语句中的锁定注意事项？

select语句是否可能无法识别早期查询中已存在的行？

1 个答案: