Printed 2017/08/19 01:17PM

Changing Storage for your SQL Server

By Steve Jones, 2010/03/18

A friend pinged me the other day with a question on SQL Server storage. He works as a Windows consultant, a fairly high end Windows/Hyper-V/Exchange guy, and knows a lot. However he likes to double check his plan with an area expert, which in this case was me. It’s a good plan, and it’s one that I use as well. If I need to make Windows changes, or network changes, I’ll call a friend that is an expert in that area.


In this case, he was replacing the storage for a SQL Server. The instance was on a Windows Host and a new set of LUNs from a new SAN were being presented to the server. This was a SAN replacement, and the equivalent of adding new drives to your machine, and yanking the old ones.

Fortunately this wasn’t a simultaneous replacement (add/remove in one step). He plan was:

In this case the system dbs and SQL Server itself were installed on local drives, so they were unaffected. He wanted to make a minimum of effort and changes to the system.

I replied this was a good plan. SQL Server depends no Windows to present storage to it, using simple drive letters or mount points. If you change the underlying storage, but keep the drive letters or mount points the same and SQL Server will just pick up where it left off. As long as the path is there, SQL Server will be fine.

I still would recommend that you detach the databases first and then attach them after. Changes like this shouldn’t matter, but just in case, I like to make sure I can recover to the new storage easily.

Copyright © 2002-2017 Redgate. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.