SharePoint Content Database Log Truncation

Question

Upon searching the web I found that DPM 2010 does not truncate the SQL log when it does the express full. Logs are truncated only when someone does a incremental (log backup)
Now For sharepoint content db, DPM does not do SQL transaction log incremental backup right?
So how are the content db logs truncated?
My recovery type is Full (we use mirroring). Should I backup the databases manually for the log truncation to occur?

Answer 1

They way this works is that DPM will back up the content database, and then back up the ldf file associated with it.  You will see entries in the application event log corresponding to each action.  The important ones to note will be:
Log Name:      Application
Source:        MSSQL$MIRRORA
Date:          4/28/2015 7:53:17 PM
Event ID:      18264
Task Category: Backup
Level:         Information
Computer:      CButchSQL1.domain.com
Description:
Database backed up. Database: WSS_Content_number4, creation date(time): 2015/04/24(19:20:20), pages dumped: 2282, first LSN: 173:445:49, last LSN: 173:465:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE:
{'{72BA7E1C-DB2D-4C40-B4A1-BDAF62B6E213}1'}). This is an informational message only. No user action is required.
This one of course indicates your content database was backed up.  After that, you should see:
Log Name:      Application
Source:        MSSQL$MIRRORA
Date:          4/28/2015 7:53:25 PM
Event ID:      18265
Task Category: Backup
Level:         Information
Computer:      CButchSQL1.domain.com
Description:
Log was backed up. Database: WSS_Content_number4, creation date(time): 2015/04/24(19:20:20), first LSN: 173:163:1, last LSN: 173:472:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'C:\Program Files\Microsoft
SQL Server\MSSQL10_50.MIRRORA\MSSQL\DATA\DPM_SQL_PROTECT\CBUTCHSQL1\MIRRORA\WSS_Content_number4_log.LDF\TempLog\TempLog.log'}). This is an informational message only. No user action is required.
DPM essentially does a temporary backup of the log to the temp location listed and immediately deletes it.  Once the log file is backed up for a database in full recovery mode, SQL will then truncate the log automatically for you.  If you see the
18265 event and the db is in full recovery mode, then SQL is failing somehow to truncate and should be investigated.  If you see 18264 but then no 18265, then you should check to be sure this isn't DPM R2 UR5 protecting SP with SQL Always On backend as
we are investigating an issue where DPM is not properly backing up the log files. Right now, you can manually truncate those log files until a fix is created.
Thanks, Chris Butcher - MSFT This posting is provided "AS IS" with no warranties, and confers no rights