这种情况我碰到过好几次，本质是SQL Server Agent的作业状态记录和实际执行进程不同步导致的矛盾——作业历史里标记为“执行中”，但实际对应的运行进程可能已经异常终止，或者Agent服务的状态缓存出了问题，所以你调用终止命令时会收到“作业未运行”的报错。

下面是具体的排查和解决步骤：

1. 先确认并终止实际运行的进程（如果存在） #

作业卡在第8步，大概率有对应的SQL会话还在运行（或者僵死），先找到它：

• 可以用以下T-SQL查询当前活跃的会话，重点找和你的作业第8步相关的进程：

  SELECT 
      s.session_id,
      r.command,
      s.login_name,
      r.cpu_time,
      r.total_elapsed_time,
      COALESCE(OBJECT_NAME(r.objectid), st.text) AS executing_content
  FROM sys.dm_exec_sessions s
  JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
  CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
  WHERE s.is_user_process = 1
      -- 替换成作业运行的账号，比如你的作业用sa的话
      AND s.login_name = 'sa'
      -- 或者根据第8步的操作关键词过滤
      OR st.text LIKE '%你的第8步操作关键词%'
  

• 如果找到对应的session_id，直接执行KILL <session_id>;终止这个会话。
• 如果查不到相关会话，说明作业进程已经终止，只是Agent的状态没更新。

2. 重置SQL Server Agent服务状态 #

当Agent的状态缓存和实际不符时，重启Agent是最直接的解决方法：

• 打开Windows服务管理器（按下Win+R输入services.msc），找到**SQL Server Agent (你的实例名)**服务。
• 先停止服务，等待几秒后再启动。注意：重启Agent会中断所有正在运行的作业，尽量选择业务低峰期操作。
• 重启后再查看作业历史，“执行中”的状态应该会消失，作业会回到正常的完成/失败状态。

3. 排查第8步卡住的根本原因 #

解决当前状态问题后，得避免以后再出现：

• 查看作业第8步的执行日志：在SSMS的作业历史里，找到该作业的记录，展开第8步查看详细日志，看有没有超时、死锁、资源不足的报错信息。
• 如果第8步是执行SQL脚本或存储过程，检查是否存在未提交的事务、长时间占用锁的情况，或者查询是否缺少索引导致执行过慢。
• 如果是调用外部程序（比如exe、脚本），确认程序是否有崩溃、依赖资源缺失（如文件权限、网络连接）的问题。

为什么会出现这种矛盾？ #

SQL Server Agent的作业状态是由Agent服务自身维护的，当作业对应的进程因为异常原因终止（比如强制杀掉会话、服务器内存不足导致进程崩溃、网络中断），Agent可能没能及时捕获到这个状态变化，导致作业历史里还保留着“执行中”的标记，但实际作业已经停止，所以调用sp_stop_job时会提示“作业未运行”。

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