sp_send_dbmail 导致会话挂起

Question

昨天我们在生产 (2008R2 SP3) 中遇到了一个问题，开发人员在 SSMS 中运行一段代码，该代码在sp_send_dbmail事务内执行，并包含来自另一台服务器上的网络共享的附件。

开发人员报告代码“似乎比预期花费的时间更长”并试图停止查询。当查询未能停止时，他让我终止他的查询。

使用sp_WhoIsActive，我收集了有关会话的以下信息：

• PREEMPTIVE_OS_GETPROCADRESS 等待继续上升
• 极低的 CPU、内存、IO 使用率
  • 几乎所有的时间都花在等待上
• KILLED/ROLLBACK 状态
• 有 1 个未结交易
• 持有架构修改锁，导致严重阻塞
• 当前语句正在执行 xp_sysmail_attachment_load
  • 调用堆栈是sp_send_dbmail--> sp_GetAttachmentData-->xp_sysmail_attachment_load

由于 PREEMPTIVE_OS 等待，在操作系统产生/返回之前，无法从 SQL Server 终止会话。使用 TCPView，我确认没有从 SQL Server 到带有附件的文件服务器的活动网络连接。我不知道是否有一个连接已经断开连接，或者它是否从未建立连接。

根据数据，我的假设是访问附件时存在一些问题，导致会话挂起，并且操作系统进程永远不会产生/返回。

由于这会导致阻塞而影响生产，因此我们最终将 FCI 故障转移到另一个节点，因此实例重启将迫使会话终止。

我的问题是：

• 有什么方法可以可靠地识别 SQL 正在等待的操作系统进程吗？（因此尝试“帮助”该过程返回 - 杀死它等）
• 来自另一个方向：有没有办法强制会话停止等待具有 PREEMPTIVE_OS 等待的操作系统，以便我们可以在不重新启动 SQL 的情况下杀死它？
• 在这种情况下是否有一些因素使会话xp_sysmail_attachment_load更有可能挂起？（我正在处理一个重现案例，但还不能可靠地重现这个。）
• 如果此问题再次发生，我可以/应该在其他地方查找其他信息吗？