May 4, 2015 at 8:29 pm
Comments posted to this topic are about the item Can Auditing Fail?
May 4, 2015 at 11:23 pm
Guess I am that "someone" whose auditing requirements surprised you 😀
one of the needs for auditing to be async is, in most of the shops, the infrastructure and applications are handled by purely different teams. If the auditing is failing, infra team is held purely responsible for it and application teams don't want any impact to the application and obviously don't want to be held answerable.
Regards,
Raj
May 5, 2015 at 12:02 am
I fully agree with the editorial. If there are legal or policy requirements auditing must not fail.
May 5, 2015 at 4:21 am
What is the cost of the audit, and what are the alternatives? The cost aren't just IT costs, but lost business or operations. I'd like to see a switch that could override the auditing on a logged basis. In the end, it is someone attesting to the system that makes it part of the record.
412-977-3526 call/text
May 5, 2015 at 7:06 am
Auditing for the purpose of solving a system problem seems reasonable. But auditing for legal reasons makes me feel I am being held hostage by the crooks. We do it because we have to prove we are doing something right. Would anyone ever do that on their own system if no one else was ever using it? Sometimes I years for those good old days when the company was really small and we could just do things to the system and data whenever we needed to to keep things running smoothly. Now we have to prove to the outside world that we aren't the bad guys.
May 5, 2015 at 7:15 am
In most scenarios the auditing operation should be done asynchonously, if possible, for performance reasons. But you can't do that if the auditing operation is bundled within batch transaction.
Another reason for separating the auditing operation from the batch transaction is that in the event the batch transaction fails, so does the audit event. I'm sure we're all familiar with the scenario where an error occurs, the error is logged to an audit table... but then the audit table insert is rolled back along with the rest of the batch transaction thus leaving no evidence that the error occurred.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 5, 2015 at 7:18 am
Agree totally!
One of the most frustrating things about the default tracee was the fact that one can not change the size and number of the rollover files. This meant for us that in some cases the default trace was rolling over all files in as little as 5 hours. Ok its easy to say increase your off host backups etc., but to what frequency? Should the servers get busier then do we keep on increasing these? Do we set up a filewatcher to check that the trace has rolled over and then back up the previous file. Why can we not just have the ability to amend the size and number of the default trace files?
In the end we created another trace based on the default but with bigger and more numerous files.
Regards
May 5, 2015 at 7:22 am
If your auditing process is failing, then that should be a top priority for investigation, and in something like a financial transaction database, you may want to consider suspending operation until the root cause is discovered and corrected.
It's sort of like a branch manager walking into the bank one morning and finding the security guard's post empty for the first time in years. Maybe there is a mundane explanation, perhaps the guard suddenly got sick, but it still leaves one with an uneasy feeling that something is off and needs to be resolved before opening the doors for normal business.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 5, 2015 at 7:26 am
In case, if you haven't read today's article
http://www.sqlservercentral.com/articles/Audit/124740/ 🙂
Regards,
Raj
May 5, 2015 at 7:29 am
lol - I had but thanks 😀
May 5, 2015 at 8:43 am
arr.nagaraj (5/4/2015)
Guess I am that "someone" whose auditing requirements surprised you 😀one of the needs for auditing to be async is, in most of the shops, the infrastructure and applications are handled by purely different teams. If the auditing is failing, infra team is held purely responsible for it and application teams don't want any impact to the application and obviously don't want to be held answerable.
I get not wanting to be impactful, but then what's the point of auditing? If it's just to troubleshoot or check when things go wrong, this might be fine. If it's to provide an accurate record of what happens, this isn't doing that. Or at least not guaranteeing that.
May 5, 2015 at 8:45 am
Eric M Russell (5/5/2015)
In most scenarios the auditing operation should be done asynchonously, if possible, for performance reasons. But you can't do that if the auditing operation is bundled within batch transaction.Another reason for separating the auditing operation from the batch transaction is that in the event the batch transaction fails, so does the audit event. I'm sure we're all familiar with the scenario where an error occurs, the error is logged to an audit table... but then the audit table insert is rolled back along with the rest of the batch transaction thus leaving no evidence that the error occurred.
This this isn't auditing, nor is it architected well. If I wanted to teach someone about auditing, this would be the issue. Need a variable that can be logged at the end storing the actions.
May 5, 2015 at 8:57 am
Steve Jones - SSC Editor (5/5/2015)
Eric M Russell (5/5/2015)
In most scenarios the auditing operation should be done asynchonously, if possible, for performance reasons. But you can't do that if the auditing operation is bundled within batch transaction.Another reason for separating the auditing operation from the batch transaction is that in the event the batch transaction fails, so does the audit event. I'm sure we're all familiar with the scenario where an error occurs, the error is logged to an audit table... but then the audit table insert is rolled back along with the rest of the batch transaction thus leaving no evidence that the error occurred.
This this isn't auditing, nor is it architected well. If I wanted to teach someone about auditing, this would be the issue. Need a variable that can be logged at the end storing the actions.
That's why I prefer to raise the error back to the calling application, or return a status code. I hate looking at a stored procecure that's six pages long and two of them are just error handling and auditing. It's a lot cleaner to implement global auditing and error handling in the application.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 5, 2015 at 9:02 am
I think we are discussing two entirely different requirements here. One relates to a company / legal requirement to ensure that various activities are traced in their entirety irrespective of where or how they were initiated. The other is not auditing as such, but application event logging.
May 5, 2015 at 9:07 am
I'd argue auditing needs to be in the database when it affects data or legal requirements. App logging certainly should always be included.
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply