Comments on: Performance and Stability Related Fixes in Post-SQL Server 2014 SP3 Builds

By: Glenn Berry

Glenn Berry — Fri, 12 Jul 2019 22:20:04 +0000

In reply to Brain2000. Well, if you think you have discovered a bug with log restores in SQL Server 2014 SP3 CU3, you should open a case with Microsoft CSS. Given that error message (which I have seen many times before), I think it is more likely that something external (like Veeam or DPM) is running log backups that you are missing when you try to restore.

By: Brain2000

Brain2000 — Fri, 12 Jul 2019 19:36:09 +0000

In reply to Glenn Berry.

The log grew to that size in a matter of two days, from the time that I seeded the full backup, until I had finished seeding the rest of the databases on that server. So it was due to me not taking a log backup in two days.

On all other servers I have, 11,000 or so managed just fine over that two day period. The one that is CU3 ended up with many databases with gigantic log files 4x as large as the data file. The biggest being the 60GB one.

The reason why I do not believe that the transactions restores are working properly is because I can successfully restore a log one day, then the next day I get this error:

“This log cannot be restored because a gap in the log chain was created. Use more recent data backups to bridge the gap.”

And this has happened multiple times on CU3, but has not happened on our other backup server that has a previous version.

I’ve also noticed that some backups will continue to show up in the dm_exec_requests table even the VDI has pushed a COMPLETED notification (I wrote my own VDI).

Just because you haven’t heard about this yet doesn’t mean it isn’t an issue. We’re an edge case, log shipping over 12000 databases…

By: Glenn Berry

Glenn Berry — Fri, 12 Jul 2019 14:57:09 +0000

In reply to Brain2000. What is the log reuse wait description on these databases where the transaction log is growing? For the missing log backups, is it possible that something else, outside of SQL Server is running transaction log backups, which explains why you are missing them when you try to restore log backups on the backup server? SQL Server 2014 SP3 CU3 only had four public hotfixes, and it was released back in April. If there was some basic problem with the transaction log backup/restore process, I think it would have been noticed by many people already, and would have been well publicized. I have not seen or heard of any problems like that.

By: Brain2000

Brain2000 — Fri, 12 Jul 2019 07:27:28 +0000

I believe the latest SQL 2014 SP3 CU3 (12.0.6259) has a rather large issue with transaction logs during runtime and restores. With one instance updated, and 8 instances on an older version, I’m finding runaway transaction files (i.e. 60GB transaction files on a 20GB database, in a matter of 2 days). This particular server has over 800 databases, and we have been jumping through hoops this week to keep the logs from running out of space on a daily basis.

On the other side of this, I have two backup servers, one on SQL 2014 SP3 CU1 and one on SQL 2014 SP3 CU3. The CU3 instance is just plain MISSING log restores!!! Meaning, I can backup and restore a log on Monday, no problem. Then on Tuesday, I backup and restore to the same database and I get this error:

“This log cannot be restored because a gap in the log chain was created. Use more recent data backups to bridge the gap.”

This has happened multiple times now on the CU3 instance. It has not happened EVER on the CU1 instance.

Now, granted, we are log shipping around 12,000 databases on a daily basis… or we were. Someone at Microsoft has really botched things up. Maybe it was the same guy who programs the Windows 10 UI….