Sql-server – SQL Server 2019: InitPersistentVersionStore failed after installing CU2

error loginstallationsql serversql-server-2019

I have installed SQL Server 2019 CU 2 over a vanilla install of SQL Server 2019 RTM.

Now I am puzzled by the following messages in the error log at startup:

RecoveryUnit::InitPersistentVersionStore failed with db [1] name
[master]
RecoveryUnit::InitPersistentVersionStore failed with db [4] name
[msdb]

AFAIK the PersistentVersionStore links to the new feature Accelerated Database Recovery however I have not configured it.

Here's a screenshot from the error log:
screenshot from errorlog

The error occurs again after a service restart.

Is it automatically enabled with CU2 for system databases? Is there anything I can do about this error in order to resolve it?

I already did a web search with the error message but most surprisingly didn't find anything regarding to it.

Quick update (March 16th):

  • Opened a Ticket with Microsoft Support (no answer yet)
  • Installed SQL Server 2019 CU 3: Error persists at service restarts just as with SP 2

Best Answer

Eventually, I got an official answer from Microsoft Support which I am glad to share here:

Hello Martin, Hope you are fine. Thanks for call yesterday. As validated from Product Group:

This is only a info message and not a bug. All system databases that come from SQL17 to SQL19 will not have persisted version store initialized because of the way we did upgrade step in SQL17. But this should not affect customer’s databases.” But we probably will not fix the message on next releases as it’s harmful – that’s why was not fixed until now. The question we have discussed, as this is something that harmful but should not be there, so you will not be charged for this case. I will close the case and mark it as product issue.

It's a bit contradictory on whether the message will be fixed or not....last statement on the phone was that in a problematic case it typically arises as a followup error due to database recovery problems. In my case that is not true and it's totally unproblematic...I even don't use ADR.

A big recommendation for everyone upgrading from SQL 2017: Do not perform an in-place-upgrade but rather do a fresh install of SQL 2019 to avoid seeing this error message.