I don't think there is simple rule to estimate the size. For data-change auditing it all depends on the update volume and types of data changes. One this if changing numbers in small tables, another is changing large text values and updating lots of tables. For the user/system activity auditing it depends mostly on how many users how many operations performed in the db. The best way to estimate size requirements is to turn on full auditing and let it run for a week or 2 measuring space every day. You can then forecast with a high degree of accuracy how much space you would need to store audit data for any given period of time. In any case, if you want to keep the audit trail size under control, you can enable automated audit trail purge procedures to automatically delete old stuff and store only recent auditing results, or alternatively use the Alert Center option to off-load audit trails to a central repository database. : We have an implementation of DB Audit running on W2K3, MSSQL2000. : We've enabled all data triggers within the tool, in addition our application : writes : to DB Audit on particular events. : The MSSQL2000 db is aprox 2Gb, however the DB Audit size has grown to 10Gb : I suspect there's a problem in the application interface to DB Audit however : I'd like to know if there is a general rule for the : relative size of DB v Audit DB?
|