June 9, 2008 at 2:37 pm
I guess I'm not sure what you mean by trace files. Are you talking about having some piece of the database/application write data to a separate file and use that for logging?
I was referring to the SQL Server trace files created by sp_trace_create, sp_trace_setevent, etc which is the method SQL Profiler uses.
David
June 9, 2008 at 3:00 pm
I've been using trigger-based Audit Trails since SQL6, and every customer I've set them up for has loved them. Although there have been some use cases for workflow reporting and undo, the primary purpose has been tracking who-changed-what-when. Although you have classified this as Blamethrowing, it actually serves many other purposes. For instance, a user asks why their scheduled search did not return an expected result when expected, and I can show them that a) they added a criteria after the matching event had happened, and b) how to figure that out without asking me next time. It also answers questions about how a record got into a certain strange state, when there can be many users using multiple applications... and it can thereby turn up cases that need to be handled better in code.
I agree that the audit trail tables can be tampered with by anyone with permission, but so far I haven't had to satisfy a legal requirement... if I did, I would just keep the log files as a backup in case there was any question.
Also, although there seems to be a consensus that triggers need to be hard-coded to the table structure for speed, and thus rebuilt when the schema changes, I have worked out a way to quickly loop through existing columns, and only save changes, eliminating updates to the same value. I will be interested to see where your next article stands on this.
June 9, 2008 at 8:59 pm
Hi,
I just want to point you to a free tool for monitoring the SQL Log files.
It is Log Parser currently in v2.2 form Microsoft.
It is using a query engine and can read all kinds of log files and event logs.
It can output to the SQL database so you can build your own reporting on top.
SQL server uses the event log too for sending info so it is not enough to look into the logs but also into the Event log (I ussually start from there).
It would be interesting if you investigate the tool against those $1000 bucks tools.
Florin
June 10, 2008 at 4:38 am
Good tip! Thanks!
--Jeff Moden
Change is inevitable... Change for the better is not.
June 10, 2008 at 11:28 am
fmuntean (6/9/2008)
Hi,I just want to point you to a free tool for monitoring the SQL Log files.
It is Log Parser currently in v2.2 form Microsoft.
It is using a query engine and can read all kinds of log files and event logs.
It can output to the SQL database so you can build your own reporting on top.
SQL server uses the event log too for sending info so it is not enough to look into the logs but also into the Event log (I ussually start from there).
It would be interesting if you investigate the tool against those $1000 bucks tools.
Florin
I was actually looking at that product a little while ago. From what I could tell, it could parse the event file, error log, etc., but I can't tell from the web page whether it will read an SQL Server transaction log. Have you tried that? Does it work well for it?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 13, 2008 at 9:51 am
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply