Answer by Blackhawk-17

Log files need to be applied in sequence and this is determined by the LSN (Log Sequence Number) in the transaction log file. One of the common causes of this is if the source database has been switched to Simple Recovery mode, say for data loading, and then back to Full or Bulk-logged. The log chain is broken and unable to be applied to the secondary. Another possibility is when a transaction log backup has been taken outside of the Log Shipping set and not placed in a location available to Log Shipping. A gap in the LSNs is created and restores are no longer applied as they *could* result in data loss/corruption/integrity issues so SQL Server will not allow them. Unless the missing gap can be found Log Shipping has to be re-initialized. What frequency are the T-log backups taken at? Do you have a maintenance plan in place that is also backing up Transaction Logs? Do you have a third-party backup application that backs up T-logs as well? There are many ways to find out where the gap may have occurred. The following query may assist you: USE msdb; SELECT BS.server_name , BS.database_name , CONVERT(CHAR(8), BS.backup_finish_date - BS.backup_start_date, 8) AS [Duration] , BS.type , CAST((BF.backup_size / 1024 /1024) AS DECIMAL(10,2) )AS [Backup Size MB] , BS.backup_start_date , BS.backup_finish_date , BMF.physical_device_name , BF.file_number , BF.physical_name FROM backupmediafamily BMF JOIN backupset BS ON BMF.media_set_id = BS.media_set_id JOIN backupfile BF ON BS.backup_set_id = BF.backup_set_id WHERE DATEDIFF(DAY, BS.backup_start_date, getdate())