No Sharepoint. I should've mentioned that in my post, I know that's a common source of large DPMDB size.

• Edited by MarkosP 23 hours 56 minutes ago

Hi,

here are some Posts with more Informations:

https://social.technet.microsoft.com/Forums/en-US/2969e8a1-d5a9-493d-aa93-6ee4e6939860/dpm-2010-tblrmrecoverysource-in-dpmdb-very-large?forum=dataprotectionmanager

https://social.technet.microsoft.com/Forums/en-US/476f4128-4275-4d72-a3fe-6e069bcf48ea/huge-dpm-database-tbltetasktrail?forum=dataprotectionmanager

Thanks for the hints, unfortunately none of those threads provide a definitive fix/answer.

However, I've checked the stored procedures and noticed that our DPMDB doesn't contain prc_TE_GarbageCollect stored proc. at all. I guess that might be the reason why the tasktrail table is so large. I've also checked on another DPM server we have and this sproc isn't there either.

As for the RecoverySource table, it seems the garbage collector isn't running either (or is missing) since the number of lines where IsValid = 0 is almost 490k (from total of 520k) lines.

• Edited by MarkosP 21 hours 20 minutes ago

DPM 2012 SP1 environment.

I've noticed that our DPMDB size reached 40GB (plus 15GB log), which seemed bit high (personal feeling, not based on any data), so I've checked table sizes and sorted them by the space used and the 2 largest tables are tbl_TE_TaskTrail (~18GB) and tbl_RM_RecoverySource (14GB).

What exactly is contained in these DBs and are their sizes normal (as in proportional to the overall DB size)?

• Edited by MarkosP Friday, February 27, 2015 9:59 AM

Hi,

are you backing up a SharePoint Farm, that can be a reason for a large Database?