Actually recently had to stop writing directly to an audit database for this very reason. In our scenario the audit DB was locked by some insert statement from the Policy Server; at that point it just queued up requests until all Policy Servers stopped responding.
Fix was essentially like David Geneve mentioned with using the smauditimport tool
(1) write to a flat text file and rotate logs on X schedule
(2) run a regularly scheduled job which: (a) executes the "smauditimport" to insert data from rotated log into DB and (b) zip up / move successful imports to long-term data retention location
That seems to be working ok thus far. There's only a small time lag since it's having to rotate and the import across which can take a little time. But from a security standpoint if IMMEDIATE (i.e., down to like the last 5 mins) information is required, then the flat file is still there for manual investigation.
----------------------
Would be a nice enhancement though for there to be an option that instead of queuing up requests, it would revert to a local log file until DB connection was restored.
There was an idea posted a while back, but only got 2 votes and status is "not planned". So doesn't seem CA has any plans on implementing it.
Siteminder Audit DB Fallback to Local log file