SQL Server Log Shipping for Server Migration - What's the final step?

Question

Working with a server running SQL Server that was the log shipping target for two other servers as part of server consolidation/migration. In other words, server B was log shipping to server A and server C was log shipping to server A and the we failed over both to A and retired B and C.

Server A is happily chugging along. All the old log shipping related jobs were paused and deleted long ago.

Enter a new DB monitoring tool we are trialing (Spotlight Cloud) that throws warnings about our server being a secondary with a high restore latency (2 years! lol). Now, I know this isn't really an issue (afaik) but it does cause me to wonder -- what step did I skip in those failovers?

I still have entries in dbo.log_shipping_secondary. Should I? I have looked through SQL Docs online and don't really see anything covering this scenario as far as final steps.

Answer 1

You need to remove the log shipping metadata. The correct way to do this is via stored procedures, which also removes the jobs (I'm guessing you've deleted those manually).

1. Execute sp_delete_log_shipping_secondary_primary. This removes the information about the old primaries on the secondary server (Server A). Also removes the jobs if they exist.
2. Execute sp_delete_log_shipping_secondary_database. This removes the information about the secondary database. NOTE: This does not remove the DB itself, even though the documentation wording makes it sound like it might. Also, this should be called as part of step 1's stored proc, however, I've found that with orphaned log shipping configs, sometimes it doesn't execute so I run it manually afterwards.