Created
September 8, 2014 11:35
-
-
Save potatoqualitee/7fbfbd0976bace497838 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1. Took note at the exact version of SQL Server, down to the build number | |
2. Made backups of all databases, including the system databases | |
3. Stopped the SQL server role within the Failover Cluster Manager | |
4. Once the disks went offline within Windows, took a storage-level snapshot of the shared disks. I named this snap “ent version”. | |
5. Copied the system databases, and their logs (mdfs and ldfs) to backup directories just in case the snapshot didn’t work (one can never be too safe) | |
6. Used VMware to snapshot both Windows nodes (alternatively, you can shut them down and snap them at the storage level) | |
7. Uninstalled SQL Server from both nodes using the Remove Node from Cluster option. This will delete the system dbs, but not the user dbs. | |
8. Deleted templog.ldf from my system directory (it was the only one that the uninstall didn’t get rid of) | |
9. Reinstalled SQL Server Standard exactly as Enterprise was before on both nodes – down to the IP, service account, name, directory structure, filestream share etc. | |
10. Patched both nodes of SQL Server until I was back at the same build | |
11. Ensured the SQL role was stopped within the cluster and that disks were offline | |
12. Snapshotted the storage again, naming this snap “std version” | |
13. Restored storage back to “ent version” | |
14. Started SQL role within the cluster | |
15. Voila! The version was now SQL Standard and all of my dbs/logins/settings were just as they were. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment