我有一些代码允许用户通过Web浏览器将文件附件上传到SQL Server的varbinary（max）列。它已经工作了近两年，但突然间它停止了工作。它只停止在生产数据库服务器上工作 - 它仍然可以在开发服务器上正常工作。
我只能得出结论，代码很好，并且SQL Server本身的实例也存在一些问题。但我不知道如何隔离问题。
我在ATTACHMENT表中插入一条记录，只插入标题和内容类型等非二进制数据，然后使用以下代码对上传的文件进行chunk-upload：
// get the file stream
System.IO.Stream fileStream = postedFile.InputStream;
// make an upload buffer
byte[] fileBuffer;
fileBuffer = new byte[1024];
// make an update command
SqlCommand fileUpdateCommand = new SqlCommand("update ATTACHMENT set ATTACHMENT_DATA.WRITE(@Data, NULL, NULL) where ATTACHMENT_ID = @ATTACHMENT_ID", sqlConnection, sqlTransaction);
fileUpdateCommand.Parameters.Add("@Data", SqlDbType.Binary);
fileUpdateCommand.Parameters.AddWithValue("@ATTACHMENT_ID", newId);
while (fileStream.Read(fileBuffer, 0, fileBuffer.Length) > 0)
{
fileUpdateCommand.Parameters["@Data"].Value = fileBuffer;
fileUpdateCommand.ExecuteNonQuery(); <------ FAILS HERE
}
fileUpdateCommand.Dispose();
fileStream.Close();
如果它显示“FAILS HERE”，它会暂停一段时间，然后在循环的第一次迭代中出现SQL Server超时错误。如果我改为连接到开发数据库，一切正常（它遍历循环很多次，并且提交成功）。
两台服务器完全相同（SQL Server 9.0.3042），模式也相同。
当我在超时后立即打开活动监视器以查看它是什么时，它说最后一个命令是
(@Data binary(1024),@ATTACHMENT_ID decimal(4,0))update ATTACHMENT set ATTACHMENT_DATA.WRITE(@Data, NULL, NULL) where ATTACHMENT_ID = @ATTACHMENT_ID
我期望但它也说它的状态为“Suspended”，等待类型为“PAGEIOLATCH_SH”。我看了这个，这似乎是一件坏事，但我找不到任何特定的东西。
想法？
好的，这是sys.dm_exec_requests的输出：
session_id request_id start_time status command sql_handle statement_start_offset statement_end_offset plan_handle database_id user_id connection_id blocking_session_id wait_type wait_time last_wait_type wait_resource open_transaction_count open_resultset_count transaction_id context_info percent_complete estimated_completion_time cpu_time total_elapsed_time scheduler_id task_address reads writes logical_reads text_size language date_format date_first quoted_identifier arithabort ansi_null_dflt_on ansi_defaults ansi_warnings ansi_padding ansi_nulls concat_null_yields_null transaction_isolation_level lock_timeout deadlock_priority row_count prev_error nest_level granted_query_memory executing_managed_code
---------- ----------- ----------------------- ------------------------------ ---------------- ---------------------------------------------------------------------------------------------------------------------------------- ---------------------- -------------------- ---------------------------------------------------------------------------------------------------------------------------------- ----------- ----------- ------------------------------------ ------------------- ------------------------------------------------------------ ----------- ------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------- -------------------- -------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------- ------------------------- ----------- ------------------ ------------ ------------------ -------------------- -------------------- -------------------- ----------- -------------------------------------------------------------------------------------------------------------------------------- ----------- ---------- ----------------- ---------- ----------------- ------------- ------------- ------------ ---------- ----------------------- --------------------------- ------------ ----------------- -------------------- ----------- ----------- -------------------- ----------------------
59 0 2010-06-16 10:49:26.130 suspended UPDATE 0x020000003499A22E28282311CAF8CE0730402C45DCD89961 0 0 0x06000E003499A22EB881FD73000000000000000000000000 14 5 4AB28A88-B4B9-4B54-B4F4-311D42C5EA29 0 PAGEIOLATCH_SH 0 PAGEIOLATCH_SH 14:1:547920 1 1 226115095 0x 0 0 187 3687 0 0x0088B3D8 921 0 240166 2147483647 us_english mdy 7 1 1 1 0 1 1 1 1 2 -1 0 1 0 3 490 0
(1 row(s) affected)
修改
好的，我重新启动，没有骰子（无论如何都需要安装一些补丁）。在ATTACHMENT_ID上删除并重建了PK，没有骰子。然后我重建了桌子的统计数据，现在看起来很开心。我只能猜测统计数据中存在一些导致查询优化器失灵的东西。
答案 0 :(得分：1)
从症状看，由于必须执行表扫描，查询超时。表ATTACHMENT在两台服务器上都有ATTACHMENT_ID的索引吗？你能仔细检查吗？如果模式相同但两者都缺少索引，那么这些表的大小是否相当？可能是测试机上的扫描持续时间不到30秒，而生产中的扫描持续时间足够超时。在这种情况下，您需要并索引ATTACHMENT_ID。