如何获取引发SQLCLR异常的底层异常？

以下是几种无需解析错误消息字符串就能确定6549错误底层原因的方法：

1. 捕获数据库层面的死锁事件 #

6549是SQLCLR对底层数据库异常的包装，实际触发它的死锁事件可以通过SQL Server原生工具捕获：

• 扩展事件（推荐）：直接查看系统自带的system_health会话（默认已启用），它会自动捕获死锁图，可通过以下查询提取：

  SELECT 
      XEventData.query('event/data/value/deadlock') AS DeadlockGraph
  FROM 
      (SELECT 
           CAST(target_data AS XML) AS TargetData
       FROM 
           sys.dm_xe_session_targets st
           JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
       WHERE 
           s.name = 'system_health'
           AND st.target_name = 'ring_buffer') AS Data
  CROSS APPLY 
      TargetData.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(XEventData);
  

  死锁图会清晰展示造成死锁的进程、锁定资源、执行的SQL语句等关键信息。你也可以自定义创建针对deadlock_graph事件的扩展会话，更精准地捕获目标场景的死锁。
• SQL Trace：虽已被扩展事件替代，但仍可通过跟踪Deadlock Graph事件（事件ID 123）捕获死锁详情。

2. 利用动态管理视图(DMV)在CLR中补充错误上下文 #

在CLR函数捕获6549错误时，通过上下文连接查询相关DMV，获取当前会话的锁状态、执行SQL等信息，将这些内容附加到抛出的异常中：

using (SqlConnection conn = new SqlConnection("context connection=true"))
{
    conn.Open();
    try
    {
        // 你的数据读取逻辑
    }
    catch (SqlException ex)
    {
        if (ex.Number == 6549)
        {
            // 收集当前会话的锁信息
            StringBuilder lockInfo = new StringBuilder();
            using (SqlCommand cmd = new SqlCommand(@"
                SELECT resource_type, resource_description, request_mode, request_status
                FROM sys.dm_tran_locks
                WHERE request_session_id = @@SPID", conn))
            {
                using (SqlDataReader reader = cmd.ExecuteReader())
                {
                    while (reader.Read())
                    {
                        lockInfo.AppendLine($"资源类型: {reader[0]}, 描述: {reader[1]}, 请求模式: {reader[2]}, 状态: {reader[3]}");
                    }
                }
            }
            // 收集当前执行的SQL文本
            string sqlText = string.Empty;
            using (SqlCommand cmd = new SqlCommand(@"
                SELECT text
                FROM sys.dm_exec_sql_text(@@SPID)", conn))
            {
                sqlText = cmd.ExecuteScalar()?.ToString();
            }
            // 抛出包含补充信息的新异常
            throw new Exception($"CLR执行触发死锁：\n{lockInfo}\n执行SQL：{sqlText}", ex);
        }
        else
        {
            throw;
        }
    }
}

注意：此方法需要将CLR函数的PERMISSION_SET设置为EXTERNAL_ACCESS或UNSAFE，因为访问部分DMV需要更高权限。

3. 检查SQL Server错误日志 #

死锁发生时，SQL Server默认会将死锁的简要信息写入错误日志。你可以通过SQL Server Management Studio的「管理」→「SQL Server日志」查看，或者用以下查询读取：

EXEC xp_readerrorlog 0, 1, 'deadlock';

日志中会包含死锁发生的时间、涉及的进程ID、锁定资源等核心信息。

4. 结合应用层与数据库层的阻塞检测 #

在应用层捕获6549错误时，除了重试逻辑，还可以调用数据库的sp_who2存储过程，或查询sys.dm_exec_requests获取当前会话的阻塞情况，辅助定位死锁的触发场景。

内容的提问来源于stack exchange，提问作者Dan Def