January 30, 2017 at 10:39 pm
On a fresh SQL 2016 SP1 CU1 upgrade (via restore) from an older version of SQL Server, I ran a full backup, a Diff, then transaction log backups on a very frequent basis.
In all previous versions, if RESTORE HEADERONLY shows LastLSN <= FirstLSN, then the transaction log backup CANNOT be restored because it is "empty" - if you try, you get both Msg 3013 and Msg 3254, The volume on device '%ls' is empty.
This used to be fine - check the LSN's with RESTORE HEADERONLY and skip what must be skipped.
Unfortunately, now on SQL 2016 SP1 CU1, I have found multiple log backups where the LastLSN is strictly greater than the FirstLSN, and yet SQL Server STILL complains with the 3013/3254 pair!
Is this a genuine bug, is there some other validation of log files to do before the restore attempt, or is some other code required to deal with this? Is there some what (other than CONTINUE_AFTER_ERROR) to instruct SQL Server that the fact that it made an empty backup file is no reason to error out on a restore? Or to tell SQL Server during the log backup that if it's going to be "empty", don't save a file in the first place?
Thank you all for your time and help.
March 15, 2017 at 11:35 pm
This was removed by the editor as SPAM
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply