We will open traces whenever a slow performing process needs to be pinpointed. We never experienced a high overhead until today.
A couple of our production sites and services started to time out and SQL Server started login this errror:
From: SQLAlerts [mailto:SQLAlerts@xyz.com]
Sent: Monday, October 04, 2010 10:13 AM
Subject: SQL Server Alert System: ‘Severity 020′ occurred on \\XYZ
DATE/TIME: 10/4/2010 10:12:41 AM
DESCRIPTION: The client was unable to reuse a session with SPID 345, which had been reset for connection pooling. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.
JOB RUN: (None)
We stopped the trace and everything went back to normal. The trace was being stored to a file.
Is the overhead that high to cause these kind of errors? We’ll try to figure it out.
Tags: SPID, sql server, sql server 2005, sql trace