Tag Info

New answers tagged

0

I am providing you the link of the tool http://www.lepide.com/sql-server-audit/ and this tool do supports the capture of DML activities.


0

To know the details about the successful and failed logins in the SQL Server, I can recommend you to try in a Lepide's tool which has the ability to examine each and every activities regarding the who, what, when and where for each logins done in the SQL Server. The tool has the speciality in generating the report telling the details of who, what, when and ...


1

You have to use DDL event groups that can be used to run a DDL trigger or an event notification, and also the Transact-SQL statements they cover. Refer BOL for more details on what can be tracked. I have posted an answer here for How to get notified when a deadlock occurs using Event notification. The concept is similar and can be applied to audit Full ...


2

SQL Server 2008 (r1) introduced Extended Events and with that came SQL Server Audit and works similar to XEvents to audit events. So it is less intrusive than C2 Auditing and server side traces. It is very granular and fairly easy to setup. This feature is available in all editions of SQL Server 2008 R2. A good write-up intro/how-to can be found here by ...


1

I know that ApexSQL Log can audit changes made by DBAs LIKE INSERT, DELETE, UPDATE, ALTER (etc.) but CANNOT audit DBA Logins. However, they are announcing a new tool that can track "who saw what" and attempted logins, so there might be something there: Sneak Peek: ApexSQL Comply - Part II, Introducing ApexSQL Comply It seems that it can also track ...


2

I'd probably stick with triggers, for the same reasons gbn described, but if performance becomes an issue, you may want to consider using Service Broker to perform the work asynchronously (if business requirements will allow that). The typical design would be to have a trigger call a stored procedure that sends a Service Broker message, and the Service ...


5

Personally, I would use triggers for auditing. If they fail, then the main DML gets rolled back (same) The main update requires the DML to succeed A table will typically have several DML paths You may not be able to use code You will have direct table update that bypass code at some point Ok, so we'll use triggers. Some notes Ensure they work for ...


-1

In general, I'd recommend against using triggers for any heavy lifting - it's not a question of whether the performance is "better" or "worse" - it's that performance becomes unpredictable and issus are hard to debug. Most performance problems follow a hockey stick curve - performance declines roughly linearly for a while until you hit a bottleneck, and ...


0

Sadly CDC will not work as a replacement. CDC doesn't include the WHO when captruing data changes; only the what and the when. If you don't need to know who made the change then CDC will work but if the WHO is as important as the what and when then sadly, CDC falls short; very short.



Top 50 recent answers are included