September 25, 2017 at 12:25 pm
Hi Log shipping had been working fine. Now on all DBs I have a similar error after power outage. Message: *** Error: The log in this backup set begins at LSN 193489000090302900001, which is too recent to apply to the database. An earlier log backup that includes LSN 192973000046320700001 can be restored.. Using Restore HEADERONLY I found the LSN in a Tlog backup and restored it manually which I had read was the proper thing to do. The restore with NORECOVERY was successful but when I rerun the LSRESTORE it fails with the same error looking for the same LSN. Am I missing something? I really don't want to have to rebuild log shipping for this whole instance. The DBs are huge (over 1.5 TB each). Thanks in advance!!
Kevin
September 25, 2017 at 4:31 pm
You can also query the backup history and get the LSNs - that might be easier than doing a restore header on all the backups. You may want to check that to see where the LSNs are for the backup files. You could also use the to check what backups are in the backup share for log shipping. You could use something like:
DECLARE @DatabaseName Nvarchar(128)
SET @DatabaseName = N'YourDatabaseName'
SELECT s.[database_name],
m.physical_device_name,
s.backup_finish_date,
s.first_lsn, --lsn of the first or oldest log record in the backup set
s.last_lsn, --lsn of the next log record after the backup set.
s.checkpoint_lsn, --lsn most recent checkpoint at the time the backup was created, where redo must start
s.database_backup_lsn, --lsn of most recent full database backup
CASE s.[type]
WHEN 'D'
THEN 'Full'
WHEN 'I'
THEN 'Differential'
WHEN 'L'
THEN 'Transaction Log'
END AS BackupType,
s.server_name,
s.recovery_model
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m
ON s.media_set_id = m.media_set_id
WHERE s.[database_name] = @DatabaseName
ORDER BY backup_finish_date desc
Sue
September 26, 2017 at 1:51 am
CheckPoint - Monday, September 25, 2017 12:25 PMAm I missing something?
Yup, another log backup (or multiple log backups) that happened between the one that succeeded and the one that's failing
Check that you don't have a scheduled log backup job as well as the log shipping, because that will absolutely break log shipping. If you're doing log shipping, it must be the only thing taking log backups.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 26, 2017 at 3:41 am
Had faced somewhat similar issue . A log backup other than the log backup from the Log Shipping config ruins the sequence. As no other change has been done other than the restart then this probably should be the issue , as pointed by Gail.
September 26, 2017 at 8:48 am
Thanks to all!!! I really appreciate the input. I thought I had covered that item because I saw a previous posy by Gail on a similar issue. Little did I know someone did a backdoor backup. Time to rebuild log shipping I guess!!!
Sue thanks for the handy query also!!
Cheers!!
Kevin
September 26, 2017 at 10:38 am
If you can find that log backup that was taken, you can restore that and then log shipping will resume. If you can't however, you'll have to rebuild the log shipping.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply