Blog Post

WITH DATA_PURITY (from recent experience, the key to knowing if patching to 14.0.3015.40 was okay)

,

So there I am, all keen on keeping ahead of the latest security issue, as usual, whilst handling my patching addiction well by hitting up a few servers in lower environments.

With a glance at xp_readerrorlog, only to discover that after patching to CU3 for 2017, the latest, by default on restart, you'll see that the instance looks great from the log....when it's not:

dbcc checkdb(master) with ALL_ERRORMSGS, Data_purity

Save yourself the unwanted setup.exe /action="rebuilddatabase" fix down the road when you're not ready for it, by having a copy of your system database files to rollback to, or have scripted out all your logins, jobs, etc from system databases, but especially a full check on master with ALL_ERRORMSGS, Data_purity added to post-patching procedure. I just want to push this as a takeaway, since on startup it'll be just a regular consistency check console command only, and thus you'll miss allocation unit errors I encountered thanks to the data purity option.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating