Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.ms-sqlserver    |    Notorious Rube Goldberg contraption    |    19,505 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 17,599 of 19,505    |
|    Erland Sommarskog to bernie sprouster    |
|    Re: SQL Server Transaction Log Auditing    |
|    03 Aug 09 21:48:23    |
      71bdf18a       From: esquel@sommarskog.se              bernie sprouster (mike.cutts@hotmail.co.uk) writes:       > We supply an application which runs on a SQL Server backend (SQL 2000       > and 2005 currently). I am aware that the Full Recovery Model provides       > for a transaction log which contains DDL and DML transactions       > (excluding Select statements).       >       > We are putting some communication out to our customers advising they       > consider implementing an auditing strategy for the database. We have       > previously suggested products such as Lumigent Log Explorer (now       > discontinued I believe) and Apex SQL Log.       >       > I now see from a couple of other posts that the translation and       > interrogation of the log file is not recommended as an auditing       > solution. I am interested to know why this is and also any products on       > the market which have successfully been used by people to fully audit       > a SQL Server database.              I think the answer is in your own post "now discontinued". When Log       Explorer came out it was a major feat. Lumigent's Lead Engineer spent       a year or so reverse-engineering the transaction log for SQL 2000,       and maybe SQL 7 as well. Maybe they were able to catch up with SQL 2005,       but apparently they did not make the move to SQL 2008.              The problem is that since the format is proprietary, Microsoft changes       it as they like, and it's difficult for vendors to keep the pace.              Certainly a transaction-log based solution for auditing is a very       palatable option on the surface. No dependency on triggers that a       rogue DBA easily could disable. And for several years, I kept recommending       people that they should use transaction log-based audit over trigger-       based, but today this is difficult.              I should add the disclaimer that this is mainly based on what I've picked       from discussions among my MVP colleagues. I have not examined the market       myself.                     --       Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se              Links for SQL Server Books Online:       SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx       SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx       SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca