Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

FIX:BizTalk Server Log Shipping fails when the "DaysToKeep" parameter is set to 1 on a BizTalk Server 2006 R2


View products that this article applies to.

Symptoms

Consider the following scenario:
  • You use BizTalk Server 2006 R2 on a computer that is configured in the "GMT+" time zone. For example, the computer is in GMT+3 time zone.
  • You configure BizTalk Server to do BizTalk log shipping by using a destination system.

    Note For detail instructions about how to do BizTalk log shipping, refer to the �More Information� section.
  • You set the DaysToKeep parameter to 1 in the Clear Backup History step of "Backup BizTalk Server (BizTalkMgmtDb)" SQL Server agent job.
In this scenario, BizTalk log shipping may fail. Additionally, an event message that resembles the following is logged in the Application log on the destination system:
Event Type: Warning
Event Source: SQLSERVERAGENT
Event Category: Job Engine
Event ID: 208
Description:
SQL Server Scheduled Job 'BTS Log Shipping - Restore Databases (DBServer: "<database server>", DBName: "biztalkmgmtdb")' (0xF4AF5857347CD9409AB688920136032E) - Status: Failed - Invoked on: <Date Time> - Message: The job failed. The Job was invoked by Schedule 5 (Restore Logs Schedule). The last step to run was step 1 (Restore Logs).
When you view the job history for "BTS Server Log Shipping Restore Databases" SQL Server agent job on the destination system, you receive an error message that resembles the following:
<Date time>,BTS Log Shipping - Restore Databases (DBServer: "<database server name>", DBName: "BizTalkMgmtDb"),Error,1,DRGMBTSQL,BTS Log Shipping - Restore Databases (DBServer: "<database server name>"<c/> DBName: "BizTalkMgmtDb"),Restore Logs,,Executed as user: <user>. The log in this backup set begins at LSN <LSN Number><c/> which is too recent to apply to the database. An earlier log backup that includes LSN <LSN Number> can be restored. [SQLSTATE 42000] (Error 4305) RESTORE LOG is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed.,00:00:00,16,3013,,,,0
Note This issue typically occurs when there is a slow network connection. Therefore, the backup operation takes longer to transfer to the destination system.

↑ Back to the top


Cause

This issue occurs because the backup history is deleted after 1 day. This happens when the DaysToKeep parameter is set to 1. Therefore, the destination system cannot find logs to restore when the full backup is running at midnight.

↑ Back to the top


Resolution

The hotfix that resolves this problem is included in cumulative update package 2 (CU2) for BizTalk Server 2006 R2 SP1.

For more information about how to obtain the cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:
2211420� Cumulative update package 2 for BizTalk Server 2006 R2 Service Pack 1
For more information about BizTalk Server 2006 R2 SP1 hotfixes, click the following article number to view the article in the Microsoft Knowledge Base:
974563� List of Microsoft BizTalk Server hot fixes that are included in BizTalk Server 2006 R2 Service Pack 1
For more information about BizTalk Server hotfixes, click the following article number to view the article in the Microsoft Knowledge Base:
2003907� Information on BizTalk Server hotfixes

↑ Back to the top


Workaround

To work around this issue, reset the DaysToKeep parameter value to 2 or more. We recommend that you to keep the default value of 14 because this value is not related to disk space. This value only influences table rows in a history table that may be needed during a longer disaster recovery.

↑ Back to the top


Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

↑ Back to the top


More information

Important After you apply the CU2, the following changes are made to BizTalk Server.
  1. A UseLocalTime parameter is added as an optional parameter in all three steps of the �Backup BizTalk Server (BizTalkMgmtDb)" SQL Server agent job. This parameter should be consistent across all three steps. Valid values are (1,1,1), (0,0,0). The default value on all steps is 0.
    • If UseLocalTime is set to 0, UTC timestamps is used in history and full backup is taken at 12:00AM UTC if backup hour is not specified.
    • If UseLocalTime is set to 1, local timestamps is used in history and full backup is taken at 12:00AM local time if backup hour is not specified.
    • If Backup hour (0 to 23) is specified in first step, full backup is in that particular hour (local time) irrespective of the UseLocalTime setting.
  2. When the job is run for the first time, the full backup is taken despite all other settings. The timestamp is local time if UseLocalTime is set to 1 and is UTC if�UseLocalTime is set to 0.
  3. History table will contain at least one full backup history and subsequent history log backups irrespective of the�DaysToKeep parameter setting. They will not be deleted until another full backup is taken.
For more information about BizTalk Server log shipping, visit the following Microsoft Developer Network (MSDN) website: For more information about how to configure the backup BizTalk Server job, visit the following MSDN website: For more information about how to configure the destination system for log shipping, visit the following MSDN website:

↑ Back to the top


Keywords: kbbtsadmin, kbqfe, kbfix, kbsurveynew, kbexpertiseadvanced, kbbiztalk2006r2presp2fix, KB2028622

↑ Back to the top

Article Info
Article ID : 2028622
Revision : 2
Created on : 7/30/2010
Published on : 7/30/2010
Exists online : False
Views : 425