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.

Anyway.

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:

• backup all user databases
• shut down SQL Server.
• add new LUNs, map to new drives in windows
• copy SQL Server mdf/ldf files over
• remove old LUNs
• map new LUNs to the same drive letters as the old ones
• start SQL Server.

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.