Fix 0XC0190053 Recovery Name Collision in SQL Server

You're mid-migration or just rebooted the server, and SQL Server won't start. The error log shows STATUS_TRANSACTIONMANAGER_RECOVERY_NAME_COLLISION (0XC0190053). This one's a sneaky beast—it doesn't pop up during normal operations. It only bites when the transaction manager tries to recover databases at startup or failover, and it finds two databases claiming the same recovery name.

I've seen this trip up DBAs right after restoring a database from a backup to a new name, or when someone copies database files from another server without renaming the internal metadata. The collision is real, and SQL Server refuses to continue recovery until you sort it out.

What's a recovery name, anyway?

SQL Server uses a unique identifier internally to track each database during recovery. It's not the database name you see in SSMS—it's a GUID stored in the database's metadata. Normally, this GUID is unique per database. But when you restore a backup, SQL Server assigns a new GUID to the restored database. However, if you copy the MDF/LDF files directly (detach-attach style) or use some third-party tools that don't handle this properly, you can end up with two databases sharing the same recovery GUID.

The transaction manager sees both at startup and throws the collision error. It's not a corrupt database—it's a metadata clash that blocks recovery for all databases.

Find the duplicate

First, you need to identify which databases are colliding. You can't query the recovery GUID easily from T-SQL, but you can check the error log for clues. Run this query to pull the last few lines:

EXEC sp_readerrorlog 0, 1, '0xC0190053';

That will show you the exact database names involved. If it's not in the log, look for lines around the error that mention database names or file paths.

The fix: give one database a new recovery name

Once you know the two databases, pick the one that's a duplicate—usually the one you restored or copied recently. The fix is to make SQL Server generate a new recovery GUID for it. The cleanest way is to detach and reattach that database, but you need to be careful with the order.

Step-by-step

1. Stop SQL Server to avoid any interference. You can do this from Services or net stop MSSQLSERVER (adjust the service name if it's a named instance).
2. Detach the duplicate database. If SQL Server is running, use:

   EXEC sp_detach_db 'YourDatabaseName';

   If it won't start due to the error, you'll need to start SQL Server in minimal configuration mode (sqlservr.exe -f) to bypass recovery, then detach.
3. Reattach the database with the same files. Use:

   CREATE DATABASE YourDatabaseName
   ON (FILENAME = 'C:\path\to\YourDatabaseName.mdf')
   FOR ATTACH;

   This forces SQL Server to assign a fresh recovery GUID.
4. Restart SQL Server normally. Recovery should now proceed past the collision.

That's it. The database keeps its name and data, but its internal GUID is now unique.

Why I prefer detach/attach over ALTER DATABASE

Some folks try to work around this by setting the database offline and online, but that doesn't change the recovery GUID. You need the reattach to force a new one. I've also seen 'ALTER DATABASE ... SET PARTNER OFF' suggested—that's for mirroring, not this. Stick with the detach/attach method; it's the only one that reliably resets that metadata.

If it still fails

Sometimes the collision isn't between two user databases—it can involve the master or msdb system databases. If the error log points to a system database, you're in a trickier spot. In that case, restore those system databases from a known-good backup using the documented recovery steps for your SQL Server version. That's a last resort, but better than a server that won't boot.

Also, double-check that you're not hitting this due to a misconfigured availability group or log shipping. Those features also use recovery identifiers, and a leftover secondary replica can cause a similar clash. If you have AGs, verify the replicas are properly removed before reattaching.

Finally, if the error persists after reattach, it might not be a name collision at all—it could be a deeper issue with the transaction manager. Check the Windows event log for related errors, and consider running DBCC CHECKDB on the database once it's online to rule out corruption.

This error is rare, but when it hits, it's a showstopper. The detach/attach trick has saved my bacon more than once. Now you have it in your toolkit too.