How to correct the CU20 - KB5063814 security SQL patching failure

Question

How to correct the CU20 - KB5063814 security SQL patching failure

Luk, Ben 0

We are trying to apply the security SQL patching - KB5063814 into an Azure SQL2022 instance; however, the patching is failed during the installation and we cannot even bring the SQL instance backup. Finally, we decided to restore the disks backup (good image before the crash) and successfully bring the SQL instance backup but all SQL replications configuration are gone.

User's image

And the error log shows

User's image

And the above causing the SQL instance failed to start.

1 answer

Your answer

Answer 1

Erland Sommarskog 124.9K MVP Volunteer Moderator

It's not clear to me what your current situation is, but the root cause of the problem is that the table MSreplication_subscriptions is missing somewhere, possibly in the database HUBCMSSYS1. Assuming that this database is a subscriber, that table should be there. So I think you need to try to repair replication in this database.

The missing table itself does not cause the script to fail, but there is some poor error handling, so that the stored procedure exists with an open transaction, and then later the upgrade fails entirely when trying to change the compatibility level inside a transaction.

Luk, Ben 0 Reputation points

2025-08-20T21:06:27.12+00:00

Thanks for the comment Erland; my understanding to your comment is that better to correct any existing problem on subscription in order to avoid any hitting any error, so that the stored procedure will exit properly and the upgrade will not hitting the same error. Indeed, the root cause the failure is on the error handling on the specific stored procedure? Alternatively, we actually lost all the SQL replications configuration after the VM restore, so it is better applying the specific security SQL patching now before reconfiguring the SQL replication, right.
Erland Sommarskog 124.9K Reputation points MVP Volunteer Moderator

2025-08-20T21:12:24.7166667+00:00

It's a little mysterious how you would lose the replication configuration by restoring the VM - unless the VM backup is old and predates when you set up replication. But in such case, you have a lot of data loss as well.

Yes, if all traces of replications are gone, you might as well try the CU again. I'm just a little nervous that there may still be remnants, which the upgrade will try to handle and fail again.

One thing I forgot to mention: If the upgrade fails again, you can continue by adding -T902 to the startup options to bypass the error. Then again, it still a situation which needs to be sorted out.
Luk, Ben 0 Reputation points

2025-08-21T18:07:09.5866667+00:00

Actually, the restore is on disks only, not the full VM for the Azure SQL VM - IaaS. we have system disk c:, MSSQL system disk F:, K: and L: restored where only C: and F: is SQL system related. Also tempdb drive T:, user db data and user db log drive E:+H: did not get restore which is our recovery strategy, do you see any issue on this. Please share your professional comment on this recovery strategy.

Only highlighted disks are restored, and all DBs are online without issue; except the SQL replications are gone, which is weird to my understanding.
Erland Sommarskog 124.9K Reputation points MVP Volunteer Moderator

2025-08-21T20:48:19.23+00:00

Since I don't the details of your system it is hard for me to comment. It sounds funny to me that you restored the data drives, but not the log drives. I'm thinking that it would not be possible to start up the databases if the data files and the log files are in sync. But it seems from your post that things are working nevertheless.

Why the replication configuration is gone, I don't know. More exactly, how do you tell that the configuration is missing?
Luk, Ben 0 Reputation points

2025-08-22T19:57:12.5433333+00:00

The F: is restored which including system DBs and log together as shown in the bottom screenshot earlier; however both Drive E: contains user DBs log files (.ldf) and Drive H: contains all user DBs data file (.mdf/**.ndf) are not restored from backup since we did not backup these two drive because we have the DBs backup in the RecoveryVault which can be always for DB recovery if need.

I guess this should explain why the SQL instance can startup successfully with all user DBs online; only mystery is why the replication setup/configuration is gone, any clue.

Share via

How to correct the CU20 - KB5063814 security SQL patching failure

1 answer

Your answer