Mike, you are correct, the performance should be affected much. If you are still worried here are a number of things you can do to make it faster. A. If you got the most recent version of DB Audit you can set an audit filter by user. This way only certain users can be audited and the load process can be excluded from auditing on that level. If you don't have the most recent version you can download it now from here http://www.softtreetech.com/dbaudit/index.htm B. If the performance is affected more than you want you can always modify these triggers and add an "IF" like to ignore the auditing on a time-basis. I don't know which database you have, but the idea is to do something like
IF system time between 1:00 AM and 5:00 AM THEN RETURN C. You can do a similar "IF" thing for a specific "load" application. IF application name is ... THEN RETURN; D. You can probably modify your load process and have it disable audit triggers when it starts and then re-enable triggers after it ends. In this case you don't need to touch code of existing triggers. : We have a P.O. sitting on the Veeps desk for Db Audit, but he is
: having second thoughts, and wants to be assured that the
: audit triggers will not impact performance on our
: DSS/Warehouse database. We will not be auditing the nightly
: data loads, only a small number of updates and deletes
: during the non-load hours. : I have tried to assure him that a low-oltp environment like
: this one will not suffer because of such audit triggers,
: but he wants to have some proof. Aside from any little
: test we can rig up on our test box, do any of you know
: of any white papers on the overhead with audit triggers?
: Has anyone tested this?
|
