We are running SQL Server 2014 Web Edition (64-bit). On three occasions now we have had two of our live secondary log shipping databases become unusable through the log shipping process. We ship logs to these databases every five minutes, and generally the process works fine.However, on three occasions in as many months we have suddenly received alerts warning us that the transaction log restores could not be performed on the secondary databases. The SQL Server Error Log revealed the following:Date,Source,Severity,Message10/13/2015 04:01:16,spid52,Unknown,Setting database option SINGLE_USER to ON for database 'ObfuscatedName'.10/13/2015 04:01:17,spid52,Unknown,Starting up database 'ObfuscatedName'.10/13/2015 04:01:17,spid52,Unknown,Recovery is writing a checkpoint in database 'ObfuscatedName' (8). This is an informational message only. No user action is required.10/13/2015 04:01:17,spid52,Unknown,CHECKDB for database 'ObfuscatedName' finished without errors on 2015-10-13 03:01:41.260 (local time). This is an informational message only; no user action is required.10/13/2015 04:01:17,spid52,Unknown,Starting up database 'ObfuscatedName'.10/13/2015 04:01:17,spid52,Unknown,CHECKDB for database 'ObfuscatedName' finished without errors on 2015-10-13 03:01:41.260 (local time). This is an informational message only; no user action is required.10/13/2015 04:01:17,Backup,Unknown,"Log was restored. Database: ObfuscatedName, creation date(time): 2015/04/02(10:54:18), first LSN: 29435:800:1, last LSN: 29435:816:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\ServerName\Log Shipping\ObfuscatedName\ObfuscatedName_20151013035845.trn'}). This is an informational message. No user action is required."10/13/2015 04:01:17,spid52,Unknown,Setting database option MULTI_USER to ON for database 'ObfuscatedName'.10/13/2015 04:06:16,spid52,Unknown,Setting database option SINGLE_USER to ON for database 'ObfuscatedName'.10/13/2015 04:06:17,spid52,Unknown,Starting up database 'ObfuscatedName'.10/13/2015 04:06:17,spid52,Unknown,Recovery is writing a checkpoint in database 'ObfuscatedName' (8). This is an informational message only. No user action is required.10/13/2015 04:06:17,spid52,Unknown,CHECKDB for database 'ObfuscatedName' finished without errors on 2015-10-13 03:01:41.260 (local time). This is an informational message only; no user action is required.10/13/2015 04:06:17,spid52,Unknown,Starting up database 'ObfuscatedName'.10/13/2015 04:06:17,spid52,Unknown,CHECKDB for database 'ObfuscatedName' finished without errors on 2015-10-13 03:01:41.260 (local time). This is an informational message only; no user action is required.10/13/2015 04:06:17,Backup,Unknown,"Log was restored. Database: ObfuscatedName, creation date(time): 2015/04/02(10:54:18), first LSN: 29435:816:1, last LSN: 29435:832:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\ServerName\Log Shipping\ObfuscatedName\ObfuscatedName_20151013040345.trn'}). This is an informational message. No user action is required."10/13/2015 04:06:17,spid52,Unknown,Setting database option MULTI_USER to ON for database 'ObfuscatedName'.10/13/2015 04:11:16,spid52,Unknown,Setting database option SINGLE_USER to ON for database 'ObfuscatedName'.10/13/2015 04:11:16,spid52,Unknown,Starting up database 'ObfuscatedName'.10/13/2015 04:11:18,spid52,Unknown,"An error occurred while processing the log for database 'ObfuscatedName'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log."10/13/2015 04:11:18,spid52,Unknown,"An error occurred during recovery, preventing the database 'ObfuscatedName' (8:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support."The extract above shows two previously successful restores to the secondary database. Suddenly, at 04:11:16, the database can no longer be started up or restored to. This is despite CHECKDB giving a clean bill of health only five minutes earlier. The result is that the last three lines are then repeated ad infinitum.The only way we have managed to get around this issue so far is to replace the secondary database with a recent backup of the primary. Once this is in place, any outstanding transaction logs are successfully applied when the log shipping restore job next runs. However, this seems rather drastic.Can anyone please confirm what is going on here, and if anything can be done to prevent this from happening? It is rather concerning that our warm-standby databases continue to become corrupted without any apparent explanation from SQL Server.
↧