default trace - a beginner's guide

8/13/2019 Default Trace - A Beginner's Guide

1/5

http://www.sqlservercentral.com/articles/SQL+Server+2005/64547/

Printed 2010/06/18 01:34AM

Default trace - A Beginner's Guide

ByAdam Haines,2008/10/03

We have all been subject to or know someone who has been in a situation where an object has been

altered/created/deleted, without our knowledge, and the application comes to a screeching halt. After fixing the

problem, your boss asks you some questions, like what happened, why did it happen, and who did it. SQL Server 2005

introduced a new type of trigger called a DDL trigger that can provide all the answers we need; however, you did not

get a chance to implement this functionality. So... what do you do?

Some would tell their boss "I do not know, but I can find out" and then search franticly for 3rd party tools to read the

transaction log, hoping for instantaneous salvation. What these few do not know is an answer is silently running in the

background. SQL Server 2005 has built in functionality that gives administrators the answers to all these questions.

The answers lie in a new background trace called the default trace. The default traceis exactly what the name

specifies, a trace. Default trace is always running in the background of your instance capturing events thatadministrators can use to troubleshoot problems. The default trace is enabled by default and does not burden the

system because it is fairly lightweight. Chances are you had not even noticed this trace running on your instance. To

those concerned about overhead, yes there is overhead, but in my mind the benefits far outweigh the minimal

overhead. The default trace is not intended to replace DDL trigger functionality and should be used as a means to

monitor an SQL Instance, or quickly obtain detailed information about problematic events.

The default trace does not capture all trace events, but captures enough information to become a powerful tool in

your toolkit. The default trace captures key information including auditing events, database events, error events, full

text events, object creation, object deletion and object alteration. From my experiences and observations on forums, I

will be focusing on object level events. It seems that a greater number of people want the "who done it" answer for

object DDL events.

The first piece of code is to check the default trace to see if it is enabled.

SELECT * FROM sys.configurations WHERE configuration_id = 1568

If this feature is not available, you will have to configure the advanced option "default trace enabled". Below is the

code to enable the trace. Note: you will need the ALTER SETTNGS permission or be in the sysadmin or serveradmin

fixed server role to reconfigure.

sp_configure 'show advanced options', 1;

GORECONFIGURE;

GO

sp_configure 'default trace enabled', 1;

GO

RECONFIGURE;

GO

The next piece of information we need is the default trace file path, and the function below will return the current trace

file. You can grab the initial trace file (log.trc) and rollup every trace file into a single table, but there is a higher

overhead associated to bringing more data in. You should use the trace file that best represents the information you

are looking for.

Note: the path is defaulted to the \MSSQL\LOG directory, but we can use the function below to get the path
http://www.sqlservercentral.com/Authors/Articles/Adam_Haines/468817/http://www.sqlservercentral.com/Authors/Articles/Adam_Haines/468817/http://www.sqlservercentral.com/Authors/Articles/Adam_Haines/468817/http://www.sqlservercentral.com/Authors/Articles/Adam_Haines/468817/


2/5

--get the current trace rollover file

SELECT * FROM ::fn_trace_getinfo(0)

Now that we have all the information we need we can get into the trace data. Let's start by creating a new database

call TraceDB.

USE [master]

GO

CREATE DATABASE TraceDB

Now open the trace file, as shown below. As you can see, we were able to gather some pretty significant information

about who created the database and when the database was created. I have used category id of 5 and a trace_event_id

of 46 to filter the data correctly. Event ID 46 represents Object:Created and category 5 is objects. I will provide queries

that list all events and categories at the end of this article.

** Make sure to use your trace file path below. Yours may be different than mine.

SELECT

loginname,

loginsid,spid,

hostname,

applicationname,

servername,

databasename,

objectName,

e.category_id,

cat.name as [CategoryName],

textdata,

starttime,

eventclass,eventsubclass,--0=begin,1=commit

e.name as EventName

FROM ::fn_trace_gettable('C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\log.trc',0)

INNER JOIN sys.trace_events e

ON eventclass = trace_event_id

INNER JOIN sys.trace_categories AS cat

ON e.category_id = cat.category_id

WHERE databasename = 'TraceDB' AND

objectname IS NULL AND --filter by objectname

e.category_id = 5 AND --category 5 is objects

e.trace_event_id = 46--trace_event_id: 46=Create Obj,47=Drop Obj,164=Alter Obj

You will see more than one entry per object create because these objects have two event sub classes -beginand commit. Each subclass will have an entry.

You can remove the databasename filter to get object creation events for all databases.Results (Trimmed for Simplicity):


3/5

Now, we have seen what default trace is capable of. Let's create another object and repeat the query. This time around

we are going to create a table called "MyTable". Use the following code to create the table.

USE [TraceDB]

GO

CREATE TABLE [dbo].[MyTable](

[id] [int] IDENTITY(1,1) NOT NULL,

[sometext] [char](3) NULL

) ON [PRIMARY]

Now query the default trace using the same query as above. Note you can use the ObjectName column to filter for the

specific object you are looking for; otherwise all created database objects are returned.


objectname = 'MyTable' AND --filter by objectname

e.category_id = 5 AND --category 5 is objects

e.trace_event_id = 46

--trace_event_id: 46=Create Obj,47=Drop Obj,164=Alter Obj

Results (Trimmed for Simplicity):

Let's take the demo a step further by altering MyTable. Issue an alter table statement and add a new column to

MyTable, as shown below.

USE [TraceDB]

GO

ALTER TABLE MyTable

ADD col INT

We can now search trace information on the alter event for MyTable. We can use the same query as before but need

to make a small modification. You must change the trace_event_id to 164 because event 164 represents the

object:Altered event.


objectname = 'MyTable' AND --filter by objectnamee.category_id = 5 AND --category 5 is objects




Now lets drop MyTable and view the trace details. You must change the trace_event_id to 47 because event 47

represents the object:Deleted event, as shown below.


4/5

USE [TraceDB]

GO

DROP TABLE MyTable

We can view trace data by changing the trace_event_id to 47.


objectname = 'MyTable' AND --filter by objectnamee.category_id = 5 AND --category 5 is objects




As you can see, default trace gives an administrator the ability to find the history of any DDL transaction. I want to

point out that default trace is not limited to object DDL history. Among other things, default trace captures log growth

events, which can be invaluable to troubleshooting disk capacity problems.

For example, say your log file spontaneous grows enormous. It is important to understand why the log grew

spontaneously. No one would argue that one of the first place to look may be SQL Jobs. There are many commands

within a job that can potentially cause the log to grow enormous, like reindexing, bulk inserts, bulk deletes etc. By

using the trace data you can more easily identify the problem because you can pin-point the exact time the log file

began to grow. This greatly reduces the number of possible suspects, which reduces the amount of time required tofind the culprit.

The query below will pull all trace data using the log auto growth event. Note: You will not have any log growth for

TraceDb because we have not done in large inserts to make the log grow. You should apply this query to another

database where you want to monitor log growth.

SELECT

loginname,

loginsid,

spid,hostname,

applicationname,

servername,

databasename,

objectName,

e.category_id,

cat.name,

textdata,

starttime,

endtime,

duration,

eventclass,

eventsubclass,

e.name as EventName

FROM ::fn_trace_gettable('C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\log.trc',0)


5/5


ON eventclass = trace_event_id

INNER JOIN sys.trace_categories AS cat

ON e.category_id = cat.category_id


e.category_id = 2 AND --category 2 is database

e.trace_event_id = 93 --93=Log File Auto Grow

Summary:

The default trace is a valuable tool for the modern DBA's tool belt. It offers a wealth of information, while minimally

impacting the system. The default trace is not a widely publicized feature of SQL Server 2005, but is slowly gaining

fame. The default trace gives administrators the ability to get detailed information about auditing events, database

events, error events, full text events, object creation, object deletion and object alteration events. With this much

information at their fingertips, administrators are more productive and can more easily identify problems in a

production environment. My recommendations are to look through the events and see what information already exists

for your instances. Default trace should not only be used reactively but proactively. A proactive mentality will reveal

small problems before they escalate to bigger problems.

Event and Category Queries

--list of events

SELECT *

FROM sys.trace_events

--list of categories

SELECT *

FROM sys.trace_categories

--list of subclass values

SELECT *

FROM sys.trace_subclass_values

--Get trace Event ColumnsSELECT

t.EventID,

t.ColumnID,

e.name AS Event_Descr,

c.name AS Column_Descr

FROM ::fn_trace_geteventinfo(1) t


ON t.eventID = e.trace_event_id

INNER JOIN sys.trace_columns c

ON t.columnid = c.trace_column_id

References:

List of available events:

http://blogs.technet.com/vipulshah/archive/2007/04/16/default-trace-in-sql-server-2005.aspx

How to enable default trace:

http://msdn.microsoft.com/en-us/library/ms175513(SQL.90).aspx

Copyright 2002-2010 Simple Talk Publishing. All Rights Reserved.Privacy Policy.Terms of Use.Report Abuse.
http://blogs.technet.com/vipulshah/archive/2007/04/16/default-trace-in-sql-server-2005.aspxhttp://blogs.technet.com/vipulshah/archive/2007/04/16/default-trace-in-sql-server-2005.aspxhttp://msdn.microsoft.com/en-us/library/ms175513(SQL.90).aspxhttp://msdn.microsoft.com/en-us/library/ms175513(SQL.90).aspxhttp://www.sqlservercentral.com/About/Privacy/http://www.sqlservercentral.com/About/Privacy/http://www.sqlservercentral.com/About/Termshttp://www.sqlservercentral.com/About/Termsmailto:[email protected]:[email protected]:[email protected]:[email protected]://www.sqlservercentral.com/About/Termshttp://www.sqlservercentral.com/About/Privacy/http://msdn.microsoft.com/en-us/library/ms175513(SQL.90).aspxhttp://blogs.technet.com/vipulshah/archive/2007/04/16/default-trace-in-sql-server-2005.aspx

default trace - a beginner's guide

Documents