TraceWrite waittype

今天上午突然开发人员叫起来说数据库非常慢，马上连上数据查看。

使用sp_who2和下面脚本可以看到大量的TraceWrite 等待事件。我的第一反应就是有人启用的Profiler在生产服务器上抓数据了。由于这个服务器的sa帐号有很多开发知道（历史旧帐，不提了。不怕大家笑话，开发知道sa帐号，DBA不知道。如果维护机器需要让维护团队的头给开终端上去维护，这都是他妈什么地方。算了，反正是帮忙的，过几天就走了）所以，它们经常一激动就跑到服务器上搞一把。这也不是第一次了。既然知道原因了，马上维护团队的头给分公司的开发团队的头打电话，问他们的兄弟是不是搞什么东西了？过了一会数据库就恢复正常了。总部这边的维护头不干了，一定要找出谁干的。让我查，好吧。苦活都是我的~~~~

先查一下，我收集的一些计数器的值吧。可以看到在40到50之单连接数达到了967的疯值。一般正常的情况这个服务器也就400多点。

再看看errorlog

这个就很明显了，有人启动了profiler，另一个错误信息也提示了为什么当时的connnections那么高。

Error: 18056, Severity: 20, State: 29.
The client was unable to reuse a session with SPID 586, which had been reset for connection pooling. The failure ID is 29. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

可以明白，有人启动了profiler抓数据，造成了服务器内存压力，最后影响到了连接池。造成用户感觉连不上服务。好了下一步就是找出是谁干得了。

突然想起来好像SQL 自带有一个trace，去那里边看看吧。

SELECT *
FROM sys.fn_trace_getinfo(0)

找到那个log_2520.trc，看看里面有什么东西没有。

有了

好了，可以交差了。

SELECT

[owt].[session_id],
[owt].[exec_context_id],
[owt].[wait_duration_ms],
[owt].[wait_type],
[owt].[blocking_session_id],
[owt].[resource_description],
CASE [owt].[wait_type]
WHEN N'CXPACKET' THEN
RIGHT ([owt].[resource_description],
CHARINDEX (N'=', REVERSE ([owt].[resource_description])) - 1)
ELSE NULL
END AS [Node ID],
[es].[program_name],
[est].text,
db_name([er].[database_id]) [database],
[eqp].[query_plan],
[er].[cpu_time]
FROM sys.dm_os_waiting_tasks [owt]
INNER JOIN sys.dm_exec_sessions [es] ON
[owt].[session_id] = [es].[session_id]
INNER JOIN sys.dm_exec_requests [er] ON
[es].[session_id] = [er].[session_id]
OUTER APPLY sys.dm_exec_sql_text ([er].[sql_handle]) [est]
OUTER APPLY sys.dm_exec_query_plan ([er].[plan_handle]) [eqp]
WHERE
[es].[is_user_process] = 1
ORDER BY
[owt].[session_id],
[owt].[exec_context_id];
GO

巴特西

TraceWrite waittype

SQL SERVER – TRACEWRITE – Wait Type – Wait Related to Buffer and Resolution

SQL Trace Architecture and Terminology

Error 18056 can be unwanted noise in certain scenarios

最新文章

热门文章