[ISSUE]
Audit log not migrated when using MergeContentDBS and old entries remain in old database
[DESCRIPTION]
Recently I migrated a site collection from one database to another using the StsAdm command MergeContentDBS. After this migration I found out that audit entries, stored in the audit log table of the database, were still present in the old database. In total this was occupying about 20GB of space. In one of the previous updates of SharePoint, Microsoft introduced the stsadm command trimauditlog, but unfortunately this command cannot be used to trim entries in the old database if the site collection in not in there anymore.
[WORKAROUND]
It would be a possiblity to manually delete the entries in the audit log, however with SharePoint you will end up with an unsupported environment after manually changing databases.
The only workaround I would currently have is to move out all remaining site collections to other databases and then delete the old database.
2 comments:
Hey Yorick. When you ran the mergecontentdb, was the audit table data transferred to the new database or not? The reason I ask is because we've run into an issue where our audit table has grown to several hundred GB's, and using the stsadm command to trim the table kills our SQL server. I'm trying to determine if I can just use mergecontentdb to move over to a new database, and hopefully the audit data won't get moved over with it.
Hi Tray,
When running the MergeContentDBS command, the audit table data is NOT transferred to the new database. So you can use the MergeContentDBS command to move the site collection to a new database and delete the old database. But keep in mind:
When the database still has some other site collections in it, there is no (supported) way to clean out the old audit data. The trimlogs command won't work anymore, as the site collection is not in that database anymore.
Post a Comment