Timeout occurred while waiting for latch: class ‘ACCESS_METHODS_DATASET_PARENT’

USE [master]
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE procedure [dbo].[sp_findtask](@parent_task_address varbinary(8))
as 
BEGIN
SELECT 
t.spid,t.lastwaittype,t.open_tran,t.status,t.hostname,t.program_name,t.loginame,dc.text 
FROM master.sys.sysprocesses t cross apply master.sys.dm_exec_sql_text(t.sql_handle) dc
WHERE spid in (select distinct session_id from sys.dm_os_tasks where parent_task_address=@parent_task_address)
END
GO

关联到的多少个视图:sys.sysprocesses,sys.dm_os_tasks都足以经过官网查到相关列的辨证,这里不再详述。对于SQLOS职责调度涉及的定义参考:SQLOS义务调度算法

ACCESS,ACCESS_METHODS_DATASET_PARENT — Used to
synchronize child dataset access to the parent dataset during parallel
operations.

Timeout occurred while waiting for latch: class 'ACCESS_METHODS_DATASET_PARENT', id 00000009A5670C58, type 4, Task 0x0000000B655BC508 : 188, waittime 300, 
flags 0x1a, owning task 0x00000000170DC748. Continuing to wait.

 

官网的解释相比草率,于是写SQL来抓取引发难题的作业SQL,为便利起见创造为sp存款和储蓄进程。

前天有个别SQL
Server数据库的荒谬日志爆出如下错误:

在本例中大家先去找由于latch
timeout生成的体系转储文件,然后再用windbg实行剖析即可。由于SQL
Server只会在第三遍报出latch
timeout时生成转储文件,我们得以设置838trace来使每一遍报错都生成dump,以便获得更可信赖和一体化的音讯。

dbcc traceon(838,-1)

首先觉得是互为查询的题材,于是翻笔记查看’ACCESS_METHODS_DATABASE_PARENT’到底是怎么着LATCH,能够参见sys.dm_os_latch_stats的官网解释来询问一点儿。

那般下次面世难题,只要能从错误日志中快速找到owning
task的address(就是sys.dm_os_tasks中的parent_task_address列),就足以获得难题SQL的详细消息了。

相关文章