Audit Trail Migration

MaheshNalapaneni

Hello,

We have a requirement to migrate some documents and their audit trails from one repository to another repository. Both the repository name and ID are different.
Could you please suggest how can we achieve Audit trail migration in this case?.

Thanks,
Mahesh.

DCTM_Guru

Object ID of document has docbase ID embedded in it, so if you try to export/import it into another repository, the object ID will be different.  I know dump/load api has option to preserve object ID, but I havent used this api in a long time, so I dont know if its still supported on your content server version.

As for the audit trail, its just normal table, so if you want to export rows and import then to your new repository, you can do this using specific db tools (eg MS SSIS)

Hicham Bahi

Migrating the audit trail is going to be very difficult. I don't think that dump & load will include the related audit records, but give it a try.

Otherwise, you best option might be to export the wanted audit record into a text file or some database table.

DCTM_Guru

@bacham3 - why do you think exporting selected set of records from audit trail would be difficult?  Presumably the OP has dba access, so dba would just need to find the applicable records in audittrail (ie the ones that match the object IDs of docs) and export the query results and then import them into target audittrail.  AFAIK, besides the object ID, there is no other dependency in the audittrail object/table.  The dump/load was purely for the docs such that object IDs are maintained.

Hicham Bahi

Because the migrated audit records should get a new object ID based on the target docbase. How are you going to achieve that? If you import them via SQL, who knows what side-effects it might cause.

It is possible via HVS (High Volume Server) to reserve a range of object IDs and then insert them directly, but a license is required for that. In any case it's a lot of work and you need to figure out if it's worth it.

DCTM_Guru

I was thinking the other way - the audit records should preserve the original object ID of the original document.  So I guess this depends on whether the OP can perform dump/load with preserved obj ID option.  If this works, then my option should work.  If this doesnt work, then the OP would have to do some data cleanup with the migrated audit trails.  We actually did something similar (migrating docs to diff repository).  We copied object ID into custom attribute field and then used that to perform translation between old object ID and new object ID.

Hicham Bahi

I was also referring to the IDs of the dm_audittrail objects. Forget about the relocate option in dump & load. It was designed primarily for internal use when using object replication and the archive functionality. You are not supposed to use it, and definitely not if the target docbase and a different docbase ID.

DCTM_Guru

Ah - I didnt think about the object ID of the audittrail object themselves.  I guess if you want to query audittrail object within DCTM, this may cause an issue.  My personal experience is that audittrail is so large that we often offload it to datamart/datawarehouse or logging app (eg splunk) to find the appropriate information.

I would have to disagree about your statement "... it was designed for object replication and archive replication".  It was used for this, but it was also used for migrating content and application components before Composer was available.  We used this to move apps from DEV to TST to PRD; all of these docbases would have different docbase IDs.

Now I would agree that it may no longer be supported (based on version of CS).

crittedv

Assuming the requirement is to maintain the legacy audit, you could create a custom table, or type, & do the export @DCTM_Guru mentioned. Export the pertinent single-value rows to the new table and you should be fine.