none
DPM 2010 tbl_rm_recoverysource in DPMDB very large RRS feed

  • Question

  • We have a newer (6 months) installation of DPM 2010 which we are using to backup our Exchange 2010 implementation.  Over the last 2 months we have noticed that our DPMDB database has continued to grow and is now over 40GB in size.  After closer evaluation of the database, the table: tbl_rm_recoverysource is the main contributor to the growth of the database.  I was unsure of the cause, but after searching the web I found a thread in this community (http://social.technet.microsoft.com/Forums/en-US/dataprotectionmanager/thread/26089aaa-8cd3-4f5a-9abb-a567ff13a8d1) that discussed the IsValid column in the table.  I queried our database with the following:

     

    SELECT COUNT(*)

      FROM [DPMDB].[dbo].[tbl_RM_RecoverySource]

      WHERE IsValid=0

    and it returned a count of 232,359.  This is out of a total count of 265,809.  I've tried to find out what causes these rows to be added with the IsValid=0, but have not found much information.  My question: is it safe to run the following on the table to reduce the size:

     

    UPDATE tbl_RM_RecoverySource
    SET BackupMetadataXml=NULL
    WHERE IsValid=0
    GO

    DBCC SHRINKDATABASE ('DPMDB')
    GO

    I'd like to get this under control so our database doesn't continue to grow.  So first step is to shrink the size and second step would be to understand why some many rows are in the table that have IsValid=0.

    Any help and insight is much appreciated!

    -Tom

     

     

    Wednesday, January 19, 2011 2:54 PM

All replies

  • Hey,

    The Table is used to create certain indexes for recoverypoints.  The larget it gets... the longer it will take to enumerate.  So not only many space is lost, but also the time to enumerate the recoverypoints will increase.

    You can use a query to rebuild the index of that table which will regain you space and increase the speed.

    All the information to do that is to be found here: http://technet.microsoft.com/en-us/library/ff399024.aspx

    Hope it helps

    Cheers,

    Mike Resseler


    Visit System Center User Group Belgium @ http://scug.be and http://scug.be/blogs/scdpm
    Wednesday, January 19, 2011 3:09 PM
    Moderator
  • Mike,

    Thanks for your quick response to my post.  I talked with one of our DBAs about this issue and he told me that a majority of the space taken by the data is this table is from the BackupMetadataXml column.  I don't see how rebuilding the index will decrease the size of that data field.  Will it affect our recoverability of recovery points if we run the command to set that value to NULL if the IsValid=0?

    If it is OK to NULL those values, what should we use as a regular maintenance to clean these up?  Any idea why we would have so many of our rows where IsValid=0?  Is there something else we should be checking or configuring differently?

    Thanks,

    Tom

    Wednesday, January 19, 2011 10:07 PM
  • Any thoughts on this?  Is it OK to set BackupMetadataXml to NULL where IsValid=0?  Will that prevent any restores of data?

    Thanks,

    Tom

    Monday, January 24, 2011 2:45 PM
  • Tom,

    First: Make sure that you take a backup first... The advice I'm going to give could be dangerous :-)

    Yes, it should be OK to do this

    UPDATE tbl_RM_RecoverySource
    SET BackupMetadataXml=NULL
    WHERE IsValid=0
    GO

    DBCC SHRINKDATABASE ('DPMDB')
    GO

    It will make sure that the expired recovery points are gone from the database (and they should have pruned anyway from your storage so...)

    But still, I would advise the first time to take a backup ;-)

    PS: sorry for the late reply

    Cheers,

    Mike


    Visit System Center User Group Belgium @ http://scug.be and http://scug.be/blogs/scdpm
    Tuesday, January 25, 2011 8:41 AM
    Moderator
  • Hi Tom,

    We don't recommend doing changes on DPMDB manually. It may result in Sevier issues.

    Are the rows with Isvalid = 0, are more than 30 days old? DPM garbage collector should have been deleting these entries automatically.

    Are you seeing issues for the nightly jobs? 

    Regards

    Mukul Shekhawat [MSFT]

    This posting is provided AS IS, with no warranties, and confers no rights.

    Thursday, February 10, 2011 7:38 AM
  • I'm also having the same issue. The DPMDB is now at 88GBs.

    Mukul, to answer you question, yes these items are well over 30 days old. No issues have resulted from the size. This DMP server is running backups for about 15 different SGs, and is also being backed up by a second DPM. The second DPM doesn't have a DPMDB near the size of the primary.

    I've tried running the above command without success. The operation ran so long that all the resources of the system were depleted and the system froze. I'm no db engineer so troubleshooting this has me in a spot.

    Is there a way to replace this db wihtout rebuilding the DPM, or perhaps a finessed command to clear these invalid entries?

    It would also be helpful to find out why the DPM is nor purging these entries.

     

    -Adam

    Wednesday, May 11, 2011 12:04 PM