February 18, 2010 at 8:14 am
What is the inherent utility of using C2 Audit log vs. using the Default Trace log for audit logging and monitoring of a SQL Server instance?
Both appear to use the same columns from the same schema (Event Class). I know that the C2 is constant and gets much larger, much faster creating huge numbers of files as each fills up. Default trace does NOT capture as many events (it appears ?).
Why would I want to use C2? Is there a better solution to 7 x 24 auditing to meet strict compliance (security and auditing) guidelines my environment requires.
Accidental DBA
Zee - Atlanta GA
February 18, 2010 at 11:05 am
You've kind of hit on all the high points yourself, so i'll just expound a bit.
first, format-wise, a trace is a trace; it's designed to capture exactly 64 columns of data, and those fields are already defined by MS; the difference between the C2 trace and a default trace are what EVENTS occur;
the default trace is designed to capture recent DDL events, while the C2 trace is capturing much more than that...
The C2 trace is an audit, so it never rolls over, just keeps adding new files as the events keep coming; this is so you can satisfy some SOX requirements, so those files need to be archived off on occasion so you don't eat up all your harddrive space. If you don't have a NEED for C2 auditing, you don't meed turn it on;
the default trace is just a tool to capture the last 100 meg worth of changes, so as the next 20 meg increment gets started, the oldest file is deleted and a new one created.
you can create other traces to track DML changes or any of the other multitude of events that you can review in sys.trace_events; creating a DML trace can help you find slow running queries, or who is running a certain query at 12 noon and killing performance, for example.
Lowell
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply