Audit Trails and Impact on Documentum Performance


Audit Trails and Impact on Documentum Performance
From my experience, we have to be careful about turning on audit trails in Documentum.  Turning on tracking for unnecessary events could lead to excessive audit trail creation in the database and will slow down the system.
For example, audit can be turned on for Sysobjects on several events. Two of these events are a bit confusing.
1) dm_getfile and 2) dm_fetch
While these two events sound similar at the first glance, their function is different.
1) dm_getfile occurs when a document is viewed or exported.  This is true “reading” of a document. You will want to turn this on to track which user downloaded/read this document.
2) dm_fetch occurs when webtop gets the documents attributes from the content-server.  This can occur when you perform a search or just browse to a folder.   This means that if you browse to a folder with 50 documents, it could potentially create 5o new audit trail records in the database!!  This is unnecessary, unless you have a strict security policy.
Watch out for this.  In our system, we turned on auditing for dm_fetch and ended up creating 8 million useless records and consuming all the database tablespaces.  After we realised what was happening, we turned off the auditing for dm_fetch and purged the unnecessary records, our system performance improved dramatically.
There are some excellent posts on EMC forums regarding this.  Do check them out.

Comments

Popular posts from this blog

D2 Defination

Documentum LSQM

Documentum D2 Definitions