SQL Server捕获发生The query processor ran out of internal resources and could not produce a query plan...错误的SQL语句

最近收到一SQL Server数据库服务器的告警邮件,告警内容具体如下所示:

DATE/TIME: 10/23/2018 4:30:26 PM

DESCRIPTION:  The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.

COMMENT:   (None)

JOB RUN:   (None)

关于“8623 The query processor ran out of internal resources and could not produce a query plan”这个错误,这篇文章不分析错误产生的原因以及解决方案。这里仅仅介绍如何捕获产生这个错误的SQL语句。因为出现这个错误,具体对应的SQL语句不会写入到错误日志。不能定位到具体SQL语句,很难解决这错误。所以解决问题的前提是先定位SQL语句。我们可以通过扩展事件或服务器端跟踪两种方式来定位SQL语句。

扩展事件(Extended Events)捕获

如下所示,脚本只需根据实际情况修改filename、metadatafile参数对应的值。就会创建扩展事件(Extented Events)overly_complex_queries

CREATE EVENT SESSION
overly_complex_queries

ON SERVER

ADD EVENT sqlserver.error_reported

(

ACTION (sqlserver.sql_text, sqlserver.tsql_stack, sqlserver.database_id, sqlserver.username)

WHERE ([severity] = 16

AND [error_number] = 8623)

)

ADD TARGET package0.asynchronous_file_target

(set filename = ‘D:\DB_BACKUP\overly_complex_queries.xel‘ ,

metadatafile = ‘D:\DB_BACKUP\overly_complex_queries.xem‘,

max_file_size = 10,

max_rollover_files = 5)

WITH (MAX_DISPATCH_LATENCY = 5SECONDS)

GO

-- Start the session

ALTER EVENT SESSION overly_complex_queries

ON SERVER STATE = START

GO

然后我们测试,使用网上一个脚本测试验证,如下所示,执行这个脚本就会报“8623 The query processor ran out of internal resources and could not produce a query plan”错误,如下所示:

选中扩展事件(Extented Events)overly_complex_queries,单击右键“Watch Live Data"就能查看是那个SQL语句出现这个错误(sql_text),当然,也可以通过选项“View Target Data”查看所有捕获的数据。

 

注意:这个扩展事件只能运行在SQL Server 2012及后续版本,如果是SQL Server 2008的相关版本部署,就会报下面错误:

Msg 25706, Level 16, State 8, Line 1

The event attribute or predicate source, "error_number", could not be found.

Msg 15151, Level 16, State 1, Line 18

Cannot alter the event session ‘overly_complex_queries‘, because it does not exist or you do not have permission.

 

服务器端跟踪(Server Side Trace)捕获

如上所示,刚好我们这台数据库服务器的版本为SQL Server 2008 R2,我们只能采取Server Side Trace来捕获这个错误的SQL语句。设置Server Side Trace脚本如下(相关参数需根据实际情况等设定):

-- 定义参数  
declare @rc int  

declare @TraceID int  

declare @maxfilesize bigint  

set @maxfilesize = 1024   

 

-- 初始化跟踪  

exec @rc = sp_trace_create @TraceID output, 0, N‘D:\SQLScript\trace_error_8623‘, @maxfilesize, NULL   

--此处的D:\SQLScript\trace_error_8623是文件名(可自行修改),SQL会自动在后面加上.trc的扩展名  

if (@rc != 0) goto error  

 

-- 设置跟踪事件  

declare @on bit  

set @on = 1  

 

 

--trace_event_id=13  SQL:BatchStarting   trace_event_id=22 ErrorLog

exec sp_trace_setevent @TraceID, 13, 1,  @on    

exec sp_trace_setevent @TraceID, 13, 3,  @on  

exec sp_trace_setevent @TraceID, 13, 6,  @on  

exec sp_trace_setevent @TraceID, 13, 7,  @on  

exec sp_trace_setevent @TraceID, 13, 8,  @on  

exec sp_trace_setevent @TraceID, 13, 11, @on  

exec sp_trace_setevent @TraceID, 13, 12, @on 

exec sp_trace_setevent @TraceID, 13, 14, @on 

exec sp_trace_setevent @TraceID, 13, 15, @on 

exec sp_trace_setevent @TraceID, 13, 35, @on  

exec sp_trace_setevent @TraceID, 13, 63, @on  

 

exec sp_trace_setevent @TraceID, 22, 1,  @on    

exec sp_trace_setevent @TraceID, 22, 3,  @on  

exec sp_trace_setevent @TraceID, 22, 6,  @on  

exec sp_trace_setevent @TraceID, 22, 7,  @on  

exec sp_trace_setevent @TraceID, 22, 8,  @on  

exec sp_trace_setevent @TraceID, 22, 12, @on 

exec sp_trace_setevent @TraceID, 22, 11, @on  

exec sp_trace_setevent @TraceID, 22, 14, @on 

exec sp_trace_setevent @TraceID, 22, 14, @on 

exec sp_trace_setevent @TraceID, 22, 35, @on  

exec sp_trace_setevent @TraceID, 22, 63, @on  

-- 启动跟踪  

exec sp_trace_setstatus @TraceID, 1  

 

-- 记录下跟踪ID,以备后面使用  

select TraceID = @TraceID  

goto finish  

 

error:   

select [email protected]  

 

finish:   

GO  

 

上面SQL会生成一个服务器端跟踪事件,并返回对应的id,如下查看所示:

注意:上面捕获SQL:BatchStarting事件(trace_event_id=13),是因为捕获ErrorLog(trace_event_id=22)等事件时,都

无法捕获到对应的SQL(对应的trace column没有捕获SQL语句,暂时还没有找到一个好的解决方法)。这里也有个弊端,就是会捕获大量无关的SQL语句。

测试过后,你可以使用SQL Profile工具打开D:\SQLScript\trace_error_8623.trc找到错误信息,对应的SQL语句(在这个时间点附近的SQL语句,一般为是错误信息后面的第一个SQL语句,需要做判断),如下截图所示:

也可以使用脚本查询,如下所示,也是需要自己判断定位SQL语句,一般都是“8623 The query processor ran out of internal resources and could not produce a query plan”出现后紧接着的SQL。

SELECT StartTime,EndTime,
    TextData, ApplicationName,SPID,Duration,LoginName

FROM ::fn_trace_gettable(N‘D:\SQLScript\trace_error_8623.trc‘,DEFAULT)

WHERE spid=64

ORDER BY StartTime

参考资料:

https://www.mssqltips.com/sqlservertip/5279/sql-server-error-query-processor-ran-out-of-internal-resources-and-could-not-produce-a-query-plan/

https://www.mssqltips.com/sqlservertip/1035/sql-server-performance-statistics-using-a-server-side-trace/

原文地址:https://www.cnblogs.com/kerrycode/p/9860653.html

时间: 2024-08-02 21:00:36

SQL Server捕获发生The query processor ran out of internal resources and could not produce a query plan...错误的SQL语句的相关文章

8623错误:The query processor ran out of internal resources and could not pro

8623错误:The query processor ran out of internal resources and could not produce a query plan 问题描述: 配置了SQL Server安全性16的告警,发送邮件通知,如下: 收到如下告警信息: 查看错误日志: Error: 8623, Severity: 16, State: 1.    The query processor ran out of internal resources and could n

(4.7)怎么捕获和记录SQL Server中发生的死锁?

转自:https://blog.csdn.net/c_enhui/article/details/19498327 怎么捕获和记录SQL Server中发生的死锁? sql server如何让错误日志记录死锁 2014年02月19日 18:25:55 阅读数:1313 我们知道,可以使用SQL Server自带的Profiler工具来跟踪死锁信息.但这种方式有一个很大的敝端,就是消耗很大.据国外某大神测试,profiler甚至可以占到服务器总带宽的35%,所以,在一个繁忙的系统中,使用profi

SQL SERVER数据库备份时出现“操作系统错误5(拒绝访问)。BACKUP DATABASE 正在异常终止。”错误的解决办法

一般备份文件选择的目录为磁盘根目录或备份所选分区未授予sqlserver用户读写权限时会出现此错误. 解决办法就是给sqlserver用户授予权限: 选择要备份的文件夹 ,右键-->属性-->安全-->看下"组或用户"是否包涵Authenticated Users 这个用名,因为是包括在计算机上或活动目录中的所有通过身份验证的账户,如果有了则给其分配读写的权限,若没有点击-->编辑-->添加-->高级-->查找 找到此用户后添加,再给其分配权限

Microsoft SQL Server Version List(SQL Server 版本)

原帖地址 What version of SQL Server do I have? This unofficial build chart lists all of the known Service Packs (SP), Cumulative Updates (CU), patches, hotfixes and other builds of MS SQL Server 2014, 2012, 2008 R2, 2008, 2005, 2000, 7.0, 6.5 and 6.0 tha

SQL Server 2008性能故障排查(二)——CPU

原文:SQL Server 2008性能故障排查(二)--CPU 承接上一篇:SQL Server 2008性能故障排查(一)--概论 说明一下,CSDN的博客编辑非常不人性化,我在word里面都排好了版,贴上来就乱得不成样了.建议CSDN改进这部分.也请大家关注内容不要关注排版.同时在翻译的过程中本人也整理了一次思路,所以还似乎非常愿意翻译,虽然有点自娱自乐,但是分享给大家也是件好事 CPU 瓶颈: CPU瓶颈可能因为某个负载所需的硬件资源不足而引起.但是过多的CPU使用通常可以通过查询优化(

Performance Monitor3:监控SQL Server的内存压力

SQL Server 使用的资源受到操作系统的调度,同时,SQL Server在内部实现了一套调度算法,用于管理从操作系统获取的资源,主要是对内存和CPU资源的调度.一个好的数据库系统,必定在内存中缓存足够多的信息,以减少从物理硬盘中读取数据的次数:如果内存是系统瓶颈,那么SQL Server一定会运行的非常慢.监控SQL Server的内存压力,需要从Widnows级别上,对内存使用的整体使用情况进行监控:从SQL Server级别上,监控SQL Server对内存资源的使用情况. 一,从Wi

50种方法优化SQL Server数据库查询(转载)

原文地址:http://www.cnblogs.com/zhycyq/articles/2636748.html 查询速度慢的原因很多,常见如下几种: 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用

在SQL Server 2016里使用查询存储进行性能调优

作为一个DBA,排除SQL Server问题是我们的职责之一,每个月都有很多人给我们带来各种不能解释却要解决的性能问题. 我就多次听到,以前的SQL Server的性能问题都还好且在正常范围内,但现在一切已经改变,SQL Server开始糟糕, 疯狂的事情不能解释.在这个情况下我介入,分析下整个SQL Server的安装,最后用一些神奇的调查方法找出性能问题的根源. 但很多时候问题的根源是一样的:所谓的计划回归(Plan Regression),即特定查询的执行计划已经改变.昨天SQL Serv

sql语句优化SQL Server

MS   SQL   Server查询优化方法查询速度慢的原因很多,常见如下几种 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)          2.I/O吞吐量小,形成了瓶颈效应.          3.没有创建计算列导致查询不优化.          4.内存不足          5.网络速度慢          6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)          7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)