SQL Server作业报错特殊案例示例
这篇文章主要为大家详细介绍了SQL Server作业报错特殊案例示例，具有一定的参考价值，可以用来参考一下。
对此感兴趣的朋友，看看idc笔记做的技术笔记！
发现问题
一个作业报错，报错信息如下，从错误信息根本看不出为什么出错，手工运行作业又成功了。一时不清楚什么原因导致作业出错。
MessageExecuted as user: NT SERVICE\SQLSERVERAGENT. ...eration. [SQLSTATE 01003] (Message 8153) Mar 6 2019 8:09AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:10AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:17AM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:17AM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:03PM [SQLSTATE 01000] (Message 0) Mar 6 2019 4:06PM [SQLSTATE 01000] (Message 0) Mar 7 2019 4:07PM [SQLSTATE 01000] (Message 0) Mar 6 2019 1:40PM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:36PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:02AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:06AM [SQLSTATE 01000] (Message 0) Mar 7 2019 9:47AM [SQLSTATE 01000] (Message 0) Mar 6 2019 5:38PM [SQLSTATE 01000] (Message 0) Mar 7 2019 5:34PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:07AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:09AM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:18PM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:24PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:11AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:12AM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:34AM [SQLSTATE 01000] (Message 0) Mar 7 2019 11:39AM [SQLSTATE 01000] (Message 0) Mar 7 2019 4:20PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:51AM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:44AM [SQLSTATE 01000] (Message 0) Mar 7 2019 7:31AM [SQLSTATE 01000] (Message 0) Mar 6 2019 10:46AM [SQLSTATE 01000] (Message 0) Mar 6 2019 10:10AM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:08AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:04AM [SQLSTATE 01000] (Message 0) Mar 7 2019 3:19PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:02AM [SQLSTATE 01000] (Message 0) Mar 7 2019 9:01AM [SQLSTATE 01000] (Message 0) Mar 7 2019 9:48AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:01AM [SQLSTATE 01000] (Message 0) Mar 6 2019 4:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:17PM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:31AM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:04AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:08AM [SQLSTATE 01000] (Message 0) Mar 6 2019 1:08PM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:04PM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:03PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:18PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:16AM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:14PM [SQLSTATE 01000] (Message 0) Mar 6 2019 4:13PM [SQLSTATE 01000] (Message 0) Mar 7 2019 4:10PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:02AM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:01PM [SQLSTATE 01000] (Message 0) Mar 7 2019 7:44AM [SQLSTATE 01000] (Message 0) Mar 6 2019 5:38PM [SQLSTATE 01000] (Message 0) Mar 7 2019 5:34PM [SQLSTATE 01000] (Message 0) Mar 6 2019 5:38PM [SQLSTATE 01000] (Message 0) Mar 7 2019 5:34PM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:03PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:05PM [SQLSTATE 01000] (Message 0) Mar 7 2019 7:01PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:05AM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:47PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:16AM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:18PM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:18PM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:36PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:20AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:32AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:13AM [SQLSTATE 01000] (Message 0) Mar 6 2019 1:31PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:06AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:07AM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:03AM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:59AM [SQLSTATE 01000] (Message 0) Mar 7 2019 12:01PM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:59PM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:49AM [SQLSTATE 01000] ... The step failed.
【图片暂缺】
如上截图所示，从这里可以看到出错信息的Sql Severity级别为13， 通过数据库引擎错误严重性（Database Engine Error Severities），我们可以知道13意味着Indicates transaction deadlock errors. 也就是说出现死锁，导致作业的会话成为了死锁的牺牲品。不过也很奇怪，以前也遇到过作业由于出现死锁，导致作业失败的情况。都会在Message里面有提示，但是这个实例的版本SQL Server 2012 SP3（11.0.6020.0），出现死锁，居然没有提示相关死锁信息。不清楚是Bug还是其它原因。
【图片暂缺】
严重性级别
下表列出并说明 SQL Server 数据库引擎所引起错误的严重级别。
|
严重级别 |
描述 |
|
0-9 |
返回不太严重的状态信息或报表错误的信息性消息。数据库引擎不会引起严重级别为 0 到 9 的系统错误。 |
|
10 |
返回不太严重的状态信息或报表错误的信息性消息。由于兼容性原因，数据库引擎在将错误信息返回到调用应用程序前将严重性级别从 10 转换为 0。 |
|
11-16 |
指示可由用户纠正的错误。 |
|
11 |
指示给定的对象或实体不存在。 |
|
12 |
特殊严重性，用于因特殊查询提示而不使用锁定的查询。在某些情况下，因为没有用锁保证一致性，由这些语句所执行的读取操作会产生不一致的数据。 |
|
13 |
指示事务死锁错误。 |
|
14 |
指示安全性相关错误，如权限被拒绝。 |
|
15 |
指示Transact-SQL?命令中的语法错误。 |
|
16 |
指示可由用户纠正的常规错误。 |
|
17-19 |
指示无法由用户纠正的软件错误。请将问题通知系统管理员。 |
|
17 |
指示语句导致SQL Server?用尽资源（如数据库的内存、锁或磁盘空间）或超出了系统管理员设置的某些限制。 |
|
18 |
指示数据库引擎软件中有问题，但可完成执行语句，并且可维护到数据库引擎实例的连接。每当出现严重级别为 18 的消息时均应通知系统管理员。 |
|
19 |
指示超出了不可配置的数据库引擎限制并且当前批处理已终止。严重级别为 19 或更高的错误消息将停止执行当前的批处理。严重级别为 19 的错误很少，必须由系统管理员或主要支持提供商更正。当引发严重级别为 19 的消息时，请与系统管理员联系。严重级别从 19 到 25 的错误消息均写入错误日志。 |
|
20-24 |
指示系统问题并且是致命错误，这意味着正在执行某语句或批处理的数据库引擎任务已停止运行。此任务记录了所发生事件的有关信息，然后终止。在大多数情况下，应用程序与数据库引擎实例的连接也可能终止。如果发生这种情况，该问题可能使应用程序无法重新连接。此范围内的错误消息可以影响同一数据库中所有正在访问数据的进程，并可能指示数据库或对象已损坏。严重级别从 19 到 24 的错误消息均写入错误日志。 |
|
20 |
指示语句遇到了问题。由于该问题只影响了当前任务，数据库本身未必已经损坏。 |
|
21 |
指示遇到了影响当前数据库中所有任务的问题，但数据库本身未必已经损坏。 |
|
22 |
指示消息中所指定的表或索引因软件或硬件问题而损坏。很少发生严重级别为 22 的错误。如果发生这种错误，请运行 DBCC CHECKDB 以确定数据库中的其他对象是否也已损坏。这种问题可能只是出现在缓存中而不存在于磁盘本身。如果发生此错误，请重新启动数据库引擎实例更正此问题。若要继续工作，则必须重新连接到数据库引擎实例；否则，请使用 DBCC 修复该问题。在某些情况下，可能需要还原数据库。如果重新启动数据库引擎的实例不能解决此问题，那么问题就是出在磁盘上。有时，销毁错误消息中指定的对象可以解决此问题。例如，如果消息报告数据库引擎的实例在非聚集索引中发现了长度为 0 的行，则请删除该索引并重建。 |
|
23 |
指示整个数据库的完整性因硬件或软件问题而出现问题。很少发生严重级别为 23 的错误。如果发生这种错误，请运行 DBCC CHECKDB 以确定损坏的程度。这种问题可能只是出现在缓存中而未出现在磁盘本身。如果发生此错误，请重新启动数据库引擎实例更正此问题。若要继续工作，则必须重新连接到数据库引擎实例；否则，请使用 DBCC 修复该问题。在某些情况下，可能需要还原数据库。 |
|
24 |
指示介质故障。系统管理员可能需要还原数据库。您可能还需要致电硬件供应商 |
参考资料：
https://docs.microsoft.com/zh-cn/sql/relational-databases/errors-events/database-engine-error-severities?view=sql-server-2017
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对512笔记的支持。
注：关于SQL Server作业报错特殊案例示例的内容就先介绍到这里，更多相关文章的可以留意
作者：喵哥笔记
