none
Expected Data Churn Issue DPM 2012 RRS feed

  • Question

  • I have a question regarding the shrinking of databases.

    We have a couple of Exchange databases whose Transaction logs grew VERY large due to a runaway mobile device issue. That has since been cleared up however the databases in DPM show that something like 3TB is allocated to the recovery point volume. When in "Modify Disk Allocation" I try to shrink and it tells me "Based on the expected data churn for the specified retention range, the recovery volume cannot be shrunk further". Why does it think we need 3TB? Is there a way to make DPM realize we don't really need this much and gain it back? The retention period already passed for the old stuff to roll off, so I am not sure what the issue is.

    I have the 0KB issue where it only shows 0KB used for my recovery point volumes, I know this is fixed in RU2, but that update has been pulled. Would the fact it see's 0KB also contribute to this??

    Thanks

    Wednesday, May 14, 2014 5:31 PM

Answers

  • Hi,

    DPM 2012 UR2 was re-released and contains the fix for the 0KB used space issue for recovery point volume.

    For the shrink issue please download the shrink-dispart.zip from this location: https://onedrive.live.com/redir?resid=885774776D4F197A!181&authkey=!AJzph18Kiltxlng&ithint=file%2c.zip

    It contains a DPM Powershell script that will automatically shink RP volumes that are larger than necessary.  This is an automated way of doing the same operation that the SHRINK option does in the DPM GUI.

    When ran it will prompt you to choose one of the three options.  R will only report the volumes that are candidates for shrinking.  S will allow to shrink a RP volume or skip it.   A shrinks all RP volumes that is can.

    R = Report, S = Shrink with confirmation, A = Automatically Shrink all possible volumes

    You will need to review the application event log with the source DEFRAG to investigate any shrink failures.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, May 28, 2014 11:32 PM
    Moderator

All replies

  • Wednesday, May 14, 2014 6:45 PM
  • Thanks for your reply, but this is not an Exchange related issue. The issue was a runaway mobile device that grew transaction logs. Now I am wondering how to get my space back from DPM.
    Wednesday, May 14, 2014 7:01 PM
  • Hi

    this Article describes how  Exchange will calculate the expected Log size.

    There is as Powershell Script which shrinks all Volume from DPM, if possible - http://social.technet.microsoft.com/Forums/en-US/946ce05d-3276-4d8d-a8e5-d257d09ec7be/backup-using-child-partition-snapshot-and-differencing-disks?forum=dpmhypervbackup

    Maybe you can try to remove the DS and re-add to the Protectiongroup, when DPM calculates the same size like before, you should read the Article i wrote to you.


    Seidl Michael | http://www.techguy.at | twitter.com/techguyat | facebook.com/techguyat

    Wednesday, May 14, 2014 7:21 PM
  • I appreciate your feedback
    Wednesday, May 14, 2014 7:25 PM
  • Still looking for feedback on this if possible. Thanks

    Wednesday, May 28, 2014 7:33 PM
  • Hi,

    DPM 2012 UR2 was re-released and contains the fix for the 0KB used space issue for recovery point volume.

    For the shrink issue please download the shrink-dispart.zip from this location: https://onedrive.live.com/redir?resid=885774776D4F197A!181&authkey=!AJzph18Kiltxlng&ithint=file%2c.zip

    It contains a DPM Powershell script that will automatically shink RP volumes that are larger than necessary.  This is an automated way of doing the same operation that the SHRINK option does in the DPM GUI.

    When ran it will prompt you to choose one of the three options.  R will only report the volumes that are candidates for shrinking.  S will allow to shrink a RP volume or skip it.   A shrinks all RP volumes that is can.

    R = Report, S = Shrink with confirmation, A = Automatically Shrink all possible volumes

    You will need to review the application event log with the source DEFRAG to investigate any shrink failures.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, May 28, 2014 11:32 PM
    Moderator
  • Thank you for this. I had a feeling there had to be space to "reclaim". (This found 3.6TB) My last question though is,

    How is this different in finding space to reclaim than the GUI? How could it find it, when the GUI couldn't?

    Thanks again

    Thursday, May 29, 2014 12:34 PM
  • Hi,

    I'm glad that worked to reclaim the disk space.

    The script does all the same checks that the GUI option does except for the churn rate which is what the GUI is saying is the reason why it cannot be shrunk.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, May 29, 2014 2:09 PM
    Moderator