SQL Server作业报错特别案例剖析
发明题目
一个作业报错，报错信息如下，从差错信息基本看不出为何出错，手工运转作业又成功了。一时不分明什么缘由导致作业出错。
Message
Executed 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 |
指挥系统题目并且是致命差错，这意味着正在施行某语句或批处置的 数据库引擎 任务已休止运转。 此任务记载了所产生事件的有关信息，然后终止。 在大多数状况下，利用程序与 数据库引擎 实例的连贯也可能终止。 要是产生这种状况，该题目可能使利用程序没法从新连贯。 |
|
20 |
指挥语句碰到了题目。 因为该题目只影响了目前任务，数据库自身未必已经损坏。 |
|
21 |
指挥碰到了影响目前数据库中所有任务的题目，但数据库自身未必已经损坏。 |
|
22 |
指挥新闻中所指定的表或索引因软件或硬件题目而损坏。 |
|
23 |
指挥整个数据库的完备性因硬件或软件题目而涌现题目。 |
|
24 |
指挥介质故障。 系统治理员可能需要复原数据库。 您可能还需要致电硬件供应商 |
参考材料：
https://docs.microsoft.com/zh-cn/sql/relational-databases/errors-events/database-engine-error-severities?view=sql-server-2017
总结
以上就是这篇文章的全部内容了，但愿本文的内容对大家的学习或者工作拥有一定的参考学习价值，感谢大家对我们的支撑。
