I noticed that my DPM 2012 server disk space gets filled on daily basis, the DPMDB transaction log (LDF file) under Microsoft System Center 2012DPMDPMDPMDB grows till it fill the disk space and all jobs fail accordingly. This issue occurs when the Sharepoint Catalog Task starts, If you are not protecting any Sharepoint Workload you won’t notice this issue.

After working several hours with Microsoft DPM Escalation Team, it turned to be a bug in one of the procedures after System center 2012 Rollup 3 implementation.

For more information about Rollup 3 for System Center 2012, please check the following link: http://support.microsoft.com/kb/2756127

For that we modified store procedure prc_PRM_SharePointRecoverableObject_Update. (You can find it under the SQL Management Studio – DPMDB – Programability – Stored Procedures), Just take a DPM backup before any change for your reference.

From:

USE[DPMDB]
GO
/****** Object: StoredProcedure [dbo].[prc_PRM_SharePointRecoverableObject_Update] Script Date: 11/02/2012 17:42:07 ******/
SETANSI_NULLS ON
GO
SETQUOTED_IDENTIFIER ON
GO
ALTERPROCEDURE [dbo].[prc_PRM_SharePointRecoverableObject_Update]
(
@Captionnvarchar(40),
@ComponentTypenvarchar(16),
@RecoverableObjectIdBIGINT
)
AS
DECLARE@error INT,
@rowCountINT
SET@error = 0

SETNOCOUNT ON

UPDATEtbl_RM_SharePointRecoverableObject SET Caption =@Caption
UPDATEtbl_RM_SharePointRecoverableObject SET Caption =@Caption,
ComponentType= @ComponentType
WHERERecoverableObjectId =@RecoverableObjectId

SELECT@error = dbo.udf_DPS_CheckRowCount(1)

SETNOCOUNT OFF
RETURN@error

To:

USE[DPMDB]
GO
/****** Object: StoredProcedure [dbo].[prc_PRM_SharePointRecoverableObject_Update] Script Date: 11/03/2012 01:36:08 ******/
SETANSI_NULLS ON
GO
SETQUOTED_IDENTIFIER ON
GO
ALTERPROCEDURE [dbo].[prc_PRM_SharePointRecoverableObject_Update]
(
@Captionnvarchar(40),
@ComponentTypenvarchar(16),
@RecoverableObjectIdBIGINT
)
AS
DECLARE@error INT,
@rowCountINT
SET@error = 0

SETNOCOUNT ON

— UPDATE tbl_RM_SharePointRecoverableObject SET Caption = @Caption
UPDATEtbl_RM_SharePointRecoverableObject SET Caption =@Caption,
ComponentType= @ComponentType
WHERERecoverableObjectId =@RecoverableObjectId

SELECT@error = dbo.udf_DPS_CheckRowCount(1)

SETNOCOUNT OFF
RETURN@error

After that we had a successful SharePoint catalog task that didn’t cause TempDB or DPMDB transaction log to grow.

I also have this fix update on Microsoft DPM Technet Forum

http://social.technet.microsoft.com/Forums/en-US/dataprotectionmanager/thread/e0e70be6-7249-438d-b43c-a0456f7c1338/#a93a3ed8-39bd-40bc-8224-ef7d6232299e