AboutSQL Server, Analytics, .Net, Machine Learning, R, Python Archives
About Me
Mitch Wheat has been working as a professional programmer since 1984, graduating with a honours degree in Mathematics from Warwick University, UK in 1986. He moved to Perth in 1995, having worked in software houses in London and Rotterdam. He has worked in the areas of mining, electronics, research, defence, financial, GIS, telecommunications, engineering, and information management. Mitch has worked mainly with Microsoft technologies (since Windows version 3.0) but has also used UNIX. He holds the following Microsoft certifications: MCPD (Web and Windows) using C# and SQL Server MCITP (Admin and Developer). His preferred development environment is C#, .Net Framework and SQL Server. Mitch has worked as an independent consultant for the last 10 years, and is currently involved with helping teams improve their Software Development Life Cycle. His areas of special interest lie in performance tuning |
Saturday, January 10, 2009SQL Server’s Built-in Traces
Most people are aware that when SQL Server is installed, it starts a lightweight background trace known as the default trace. If this has not been disabled (and it’s unlikely that it will have been), this trace will be running with a trace ID of 1:
SELECT * FROM sys.traces This trace includes a small set of events for server starts and stops, object deletion and creation, log and data file autogrowth and other changes at the database level. One of the things this trace is useful for is unexpected events, such as finding out who dropped a table. You can examine the default trace’s contents in the same way as any other trace using fn_trace_gettable(): DECLARE @path varchar(256) SELECT @path = path FROM sys.traces where id = 1 SELECT * FROM fn_trace_gettable(@path, 1) Another less known background trace that comes preconfigured with SQL Server 2005 is the BlackBox trace. Its primary use is in diagnosing intermittent server crashes and can be started by setting the @options parameter of sp_trace_create to 8. This trace uses 2 rollover files and toggles between them as one reaches its maximum size, which is configurable. A great tip from Chapter 2 of “Inside Microsoft SQL Server 2005: Query Tuning and Optimisation” is to wrap the blackbox trace definition in a stored procedure, and configure the stored procedure to run when SQL Server starts (that way intermittent problems are more likely to be captured after restarts): USE master GO CREATE PROCEDURE StartBlackBoxTrace AS BEGIN DECLARE @TraceId int DECLARE @maxfilesize bigint SET @maxfilesize = 25 –- 25MB maximum file size EXEC sp_trace_create @TraceId OUTPUT, @options = 8, @tracefile = NULL, -- NULL = default SQL Server data file folder location: you might want to change this… @maxfilesize = @maxfilesize EXEC sp_trace_setstatus @TraceId, 1 END GO Set the procedure to start automatically when SQL Server is started: EXEC sp_procoption 'StartBlackBoxTrace', 'STARTUP', 'ON' |
ContactMSN, Email: mitch døt wheat at gmail.com LinksFavorites
Blogs |