March 19, 2013 at 4:13 am
On the server that hosts our Sharepoint databases we are log shipping 4 of them to a sql server instance at our DR site. The issue we are seeing is that for one of the 4 databases the first transaction log generated by the Log Shipping scheduled task after the full backup has been taken is the same size as the database itself (2.4Gb). Following this all subsquent files genrated are much smaller (200 Mb).
I have checked for open / long running transactions but none are reported.
Out of the 4 Sharepoint databases the one with the issue is the only one that has any Sharepoint Workflows configured. However they are configured to run in response to actions rather than at a certain time of day.
Both Servers are SQL Server 2008 SP3 Standard 64 bit.
Has anyone got any thoughts on what might be causing this behavoiur.
March 19, 2013 at 5:06 am
Have you checked this multiple times, are the results same all the time?
There would be transactions/ changes that were in progress when you took the backup and needs to be backed up.
What happens when you take another FULL backup and a Tlog backup following that?
To dig further, you may want to use "RESTORE HEADER ONLY" for the backup taken and review the DatabaseBackupLSN and CHECKPOINTLSN. This might give you a hint for why the LOG Backup is big.
Can also get the similar details from: "msdb..backupset"
Reviewing the above for both backup sets can provide more clarity.
March 20, 2013 at 12:48 am
After investigating further it seems to not be related to when a full backup is taken. It seems to be something to do with either the index optimisation scripts we run, or the fact that the Sharepoint workflows seem to insert a lot of rows into the EventCache table between midnight and 2am.
March 20, 2013 at 2:52 am
Thanks for the update!
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply