Azure SQL托管实例随机冻结锁死，需重启，求排查解决方法

一、先抓现场诊断数据 #

问题是随机触发，必须在发作时拿到第一手数据：

• 提前开启托管实例的诊断设置，把错误日志、等待统计、性能计数器、事务日志都导出到Log Analytics或存储账户，留足至少30天的日志保留期。

• 发作时立刻跑这几个DMV查询：

  -- 查看当前所有请求状态、等待类型和阻塞情况
  SELECT 
      r.session_id, r.status, r.command, r.wait_type, 
      r.wait_time/1000 AS wait_time_sec, r.blocking_session_id,
      s.login_name, s.host_name
  FROM sys.dm_exec_requests r
  JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
  WHERE r.status != 'sleeping';
  

  重点看wait_type——如果是RESOURCE_SEMAPHORE_QUERY_COMPILE是编译内存不够，LCK_M_X是排他锁阻塞，PAGEIOLATCH_SH是读IO卡了；要是全是SOS_SCHEDULER_YIELD但CPU又接近0，大概率是调度器挂了。

  -- 检查锁持有情况
  SELECT 
      request_session_id, resource_type, resource_description,
      request_mode, request_status
  FROM sys.dm_tran_locks;
  

  找有没有长期持有的大锁，比如表级排他锁。

二、定位资源与平台问题 #

• CPU降到0%但高开销查询超时，不是真的没负载，是资源调度异常：
  • 对比正常时段和异常时段的sys.dm_os_wait_stats，看哪些等待项突然飙升，比如THREADPOOL说明worker线程耗尽，RESOURCE_SEMAPHORE是内存配额不够。
  • 去Azure门户的资源健康页，查发作时段有没有平台维护、节点故障的记录——托管实例偶尔会遇到物理节点的隐性故障，导致调度器卡死，只有重启能恢复。
• 检查服务层限制：如果是弹性池，看同池其他实例有没有突发占用资源；如果是独立实例，确认vCore和内存配额有没有触顶，比如内存不足时大查询会被无限挂起。

三、针对特定场景的优化 #

• 插入base64 PDF这类大对象：
  • 别直接存base64，改用FILESTREAM或者把PDF存在Azure Blob，表中只存链接，能大幅降低IO和内存消耗。
  • 测试插入时的IO延迟：

    SELECT 
        DB_NAME(database_id) AS db_name, 
        file_id, 
        io_stall_read_ms/num_of_reads AS avg_read_stall_ms,
        io_stall_write_ms/num_of_writes AS avg_write_stall_ms
    FROM sys.dm_io_virtual_file_stats(NULL, NULL);
    

    要是读写延迟超过50ms，说明存储层有问题。
• DROP INDEX超时：
  • 先查有没有长事务持有该索引的锁，用sys.dm_tran_active_transactions看事务时长，要是有未提交的大事务，先kill掉再试。
  • 大索引尽量在低峰期操作，或者分批次删除（如果是分区索引）。

四、自动化应急与后续处理 #

• 怕非工作时间炸锅？用Azure自动化做个Runbook：当CPU低于10%+查询超时告警触发时，自动调用Azure REST API重启实例（提前评估业务影响，重启会断连接）。
• 要是之前Azure支持不给力，下次提交工单时一定要附完整的诊断日志包（包含发作前后1小时的错误日志、DMV查询结果、性能计数器），精准定位到时段，微软工程师能更快排查节点或平台问题——很多时候这类问题是底层节点的调度器bug，需要微软迁移实例到健康节点。

内容的提问来源于stack exchange，提问作者A and M Dev