Best Practices for SQL Server Decommission

In this post I would like to share some Best Practices about SQL Server Decommission:

1. Be aware of your Client IT Policy

The process of uninstalling / removing permanently a SQL Server Instance(s) goes beyond the technical scope. The stakeholders must be aware of what will happen and how their business will be impacted. Depending on the client’s IT policy, even minor changes on test envrionments must have a clear documentation and technical timeline of the events. This is usually done through a Change Management Tool. Some other factors to consider are:

  • Extra caution is required when removing a single SQL Server Instance on a Cluster environment with another Instances in production that will not be part of the decommission;
  • Make sure to understand if the Client is willing to decommission only the SQL Server product or the whole Windows Server infrastructure, and if another teams are involved;
  • Understand the big picture of why the SQL Server is being removed. Despite it may look obvious ( nowadays most of the times it is cost-saving related), does the client know for sure what he is doing? As the DBA, part of your duties should be a trusted advisor for the client in case you notice they are doing something wrong.

Example: You identify the client need only to remove a single user database instead of uninstalling everything (Consider the non-technical business users) because they do not the difference between a SQL Server instance name, User database name, or even DNS name which they use to connect remotely.

2. Backups

This is a common quote from many SQL Server books: “If you don’t have backups, then you do not have a database at all”. This applies to Decommission scenarios as well.  Chances of the client requesting back the disposed databases might be minimal. Let’s imagine they are of 1% only.  Can you think of the consequences of telling the client their MSSQL is gone for good and and can no longer be restored due to lack of backups? This could cost your Job.

Ensure they are complete before uninstalling MSSQL. If for any reason you are unable to guarantee 100% of backups, it is better to suspend than to move forward to avoid pressure from above. Having the client to pay for some more time for that server running (assuming the decommission is cost-saving related) is preferable over the harsh task of bringing bad news later.

3. Collect useful data

Another tip is to collect useful data that can be helpful in the event of a rebuild. This type of information is commonly used on the client technical documentations (inventory), but it is worth to run some T-SQL scripts to capture actual information from the server prior the change. Such as: Configuration data (Data and Transaction Log locations, Service Pack /Cumulative Update level) are just a few examples.

4. Always use the standard removal method

Microsoft has specific procedures about uninstalling SQL Server Instances from versions 2000 to 2012, either through Standard setup (Add/Remove Programs) and manual ones, where you may need to deal with the Registry Hive. Be careful with this second option and always back up your registry prior changing anything, as it can damage the whole Operating System if something goes wrong there. If the standard removal setup is failing, consider reviewing the Setup Bootstrap Logs and identify what is causing the error and troubleshoot from there on.

These are 4 simple tips. Feel free to add your own comments or any questions you may have about this subject.

Best Regards!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s