未完成的简单 SQL 查询

Question

我不太知道如何表述这个问题，因为我们还不太了解，但我想早点问，因为这看起来不应该被忽视。

本周我们的数据库服务器开始出现问题。这似乎是一个数据一致性问题，即使在非常简单的查询和小表上也表现为超时。我们在本周早些时候通过重新启动服务器“修复”了这个问题，它消失了，但现在它似乎又回来了，这次是在更重要的表上。例如，我刚刚做了一些调查，我正在查看这样的查询：

SELECT * FROM table WHERE id = 1234

对于特定的 ID。该表有大约 30 多万行。但它似乎只发生在一小部分记录中。我敢打赌，当我重新启动服务器或备份并在另一台服务器上恢复数据库时，一切都会好起来的。但是我会尝试。

此时，我正在运行：

DBCC CHECKTABLE ('table', NOINDEX)

但它似乎将永远运行。当我们第一次遇到问题时，我检查了有问题的表格，结果很好。这张新桌子要大得多。

一些背景技术信息：

• SQL Server 2008 R2、Windows Server 2008 R2
• AWS/EC2、m2.2xlarge、32 GB RAM、4 个 1TB RAID 0
• 几乎没有磁盘IO，似乎大部分db都在内存中
• 总数据库大小：100GB

ELB 卷是“全新的”。我们在本周创建了它们。

编辑：我只是使用了以下命令：

SELECT
    sqltext.TEXT,
    req.session_id,
    req.blocking_session_id,
    req.wait_type,
    req.wait_time,
    req.last_wait_type,
    req.wait_resource,
    req.open_transaction_count,
    req.transaction_id,
    req.total_elapsed_time
FROM
    sys.dm_exec_requests req
CROSS APPLY
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

并发现我的查询正在等待共享锁（LCK_M_S），其中阻塞会话正在等待另一个被不存在的会话阻塞的共享锁。

编辑 2：好的，会话存在（我发现它使用sys.dm_exec_sessions），但它现在似乎没有做任何事情。

编辑 3：我找不到任何关于会话的有趣内容。我看到它来自哪个网络服务器，但没有其他太多。

编辑 4： 编辑 4：我们在我们的代码中发现了一个可能的错误：一个不能确保数据库连接关闭的函数。另一方面，看起来函数使用的事务被正确处理，在这种情况下，所有的锁都应该被清除。我还不是很清楚，但这似乎是可能的原因。我们将修复该错误并密切关注它。

Answer 1

DBCC CHECKDB尝试在有问题的数据库上运行并等待其完成。如果存在物理数据不一致而产生这种奇怪的行为，那么使用此数据库就太危险了，因为您可能会丢失所有数据。

1. 尽快进行备份。
2. 检查数据库。

但

如果表中存在数据量较大的 BLOB 列，则检查该表需要较长时间是完全正常的。