May 4, 2012 at 1:22 am
[font="Verdana"]Hi Folks,
Can we skip all other old auditing/security techniques (Physical copy tables/Different Audit columns in each tables etc) to utilize the currnet/modern type of auditing/Security features introduced in SQL2K8 e.g. CDC, Track Changes, Audit Traces ... and so on? With a very keen focus on the performance/practicality of techniques!!!!
The Business and the application holds sensitive data and requirement is to figure out each and every operation done by any user by any time 🙂
So what you think what should serve the purpose optimally!
Please comment!!!
Thank you[/font]
May 4, 2012 at 9:09 am
Abrar Ahmad_ (5/4/2012)
[font="Verdana"]Hi Folks,Can we skip all other old auditing/security techniques (Physical copy tables/Different Audit columns in each tables etc) to utilize the currnet/modern type of auditing/Security features introduced in SQL2K8 e.g. CDC, Track Changes, Audit Traces ... and so on?
In short, yes, built-in features give us better options than homegrown solutions using history tables, triggers, etc, etc. Without more detail it's going to be hard to provide any guidance.
So what you think what should serve the purpose optimally!
Please provide more detail, or hit the books:
Comparing Change Data Capture and Change Tracking
Introducing SQL Server Extended Events
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
May 24, 2012 at 10:13 pm
May 24, 2012 at 10:58 pm
ivycool2012 (5/24/2012)
Without more detail it's going to be hard to provide any guidance.
[font="Verdana"]
We dump data in history tables via triggers etc logic in old tracking mechanism, the same kind of data tracking is possible with the help of CDC. The business requirement of the old and the new system with new mechanism (CDC etc) is same! My purpose of post was to have an insight from any old hand to pave the way .. that we have made a good decision to obsolete old hectic techniques with the new ones! 🙂
Meanwhile if the audit of "SELECT" statements is also a business requirement and very rightly we have built-in auditing of SELECT statements in SQL2K8 as well, but the built-in mechanism stores data in Operating system files (system tables etc) then to fulfill the business requirement do we need to write a file reader to read back the logged information? :blink:
Hopefully we are proceeding wit this thread 🙂 Many thanks!
[/font]
May 25, 2012 at 7:36 am
Abrar Ahmad_ (5/24/2012)
ivycool2012 (5/24/2012)
Without more detail it's going to be hard to provide any guidance.[font="Verdana"]
We dump data in history tables via triggers etc logic in old tracking mechanism, the same kind of data tracking is possible with the help of CDC. The business requirement of the old and the new system with new mechanism (CDC etc) is same! My purpose of post was to have an insight from any old hand to pave the way .. that we have made a good decision to obsolete old hectic techniques with the new ones! 🙂
Meanwhile if the audit of "SELECT" statements is also a business requirement and very rightly we have built-in auditing of SELECT statements in SQL2K8 as well, but the built-in mechanism stores data in Operating system files (system tables etc) then to fulfill the business requirement do we need to write a file reader to read back the logged information? :blink:
Hopefully we are proceeding wit this thread 🙂 Many thanks!
[/font]
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply