Here I am putting down a simple method of removing SQL Server 2016 named or default instance. I am assuming here that there are no user databases on this instance. I stopped all SQL Server services before I started this uninstall process.
- To begin the uninstall process, go to Control Panel and then Programs and Features.
- Select Microsoft SQL Server 2016 and select Uninstall. Then click Remove. This starts the Remove SQL Server 2016 Wizard.
- Setup Support Rules runs to verify your computer configuration. Since there is only one instance of SQL server 2016 on this machine, wizard selects it for you. Otherwise, you can use the drop-down menu to select your instance for removal. To continue, click Next.
4. After hitting NEXT, you will get Ready to Remove dialog box showing the summary of Engine and features that are going to be removed. Click Remove. The removal process will begin and it may take several minutes depending on your installation.
- If everything goes smoothly, you will receive a success message. You can go to the hyperlinked text file to see the report of the whole process of removal. Click Close to complete the removal of SQL Server 2016 instance.
In the end, you can refer to this TechNet document for more detailed instructions. https://technet.microsoft.com/en-us/windows/ms143412(v=sql.90)
Today, I explained to my internal IT team and a DBA on another team about the advantages of using AG for Disaster Recovery scenario. They had lot of questions and I prepared myself with these documents. I drew the scenario on my board and took the picture of it. I modified the presentation I got from one of the SQL Saturdays I attended. I downloaded Word document on this topic from MSDN site.
Building a High Availability and Disaster Recovery Solution using AlwaysOn Availability Groups
I think people are hesitant to change because they do not want to come out of their comfort zone and\or not knowing enough about the new technology makes them less confident. They like to stick to Log Shipping because it works. Another uncertainty was about geo-clustering or AG on different subnet for DR. Here I also lack knowledge so I pointed out this would be a good oppurtunity for all of us to learn and we will have one more option for DR in case log shipping feature is not available in future SQL Server releases. Then there was bad experience that the team had several years ago with Failover Clustering. It used to take time for SQL Server services to come up. I know I have lot to do to change the mindset but so little time. In the end, I got the agreement that we will create one DR box in the second data center where I will do the log shipping and also will include it in my current Availability group configuration. Let us see how it goes.