www.johntimney.com

MOSS audit logs if enabled and left to go wild can grow very fast indeed.  Every 150,000,000 entries will consume about 40gig of database space.  So about 300 bytes per audit record give or take a few bytes.

if you enable item level auditing then this will grown at a rather rapid rate and few architects actually consider this additional space requirement when they plan their corpus storage.  

http://msdn.microsoft.com/en-us/library/bb397403.aspx

Working this out is based on the number of transaction per day that will be audited, so you need to know which sites will have auditing enabled.  

In a site trying to achieve compliance, or prove an audit trail as legally admissable the audit storage requirements can be taking up space that the MOSS admin has not factored in, and can't find.  If you have vanishing space - look here first!

The lesson here is don't enable auditing without thinking carefully about the impact of it from a performance perspective (item level auditing is a performance killer) and from an audit management perspective.  Fortunately, Microsoft recently released the
the infrastructure update for MOSS which contaisn the new Trimauditlog Stsadm command.  It basically allows you to manage the audit table and remove old entries (hooray!) without hacking the DB audit table which is of course unsupported.

http://technet.microsoft.com/en-us/library/cc706879.aspx

One tip worth remembering.  if you are clearing out the dbo.AuditData table you might want to back it up.  This is explianed in the Item Level auditing paper

By default SharePoint 2007 has Diagnostic logging turned in Central Administration logging and reporting, and typically stores 48 hours worth of log data. The default setting can be as much of a killer as the Audit logs to the unwary.

As well as Audit Logs, Diagnostic Logging can also consume a considerable amount of disk space in the “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS” folder.

On a heavy site, each log file can be about 150-200 meg. With new log files being created every 30 minutes this can quickly eat up 15 to 20Gb of space over a 2 day period. So be careful that your root partitions on your WFE servers are large enough to cater for poor diagnostics logging planning.