2

We have a single node cluster (SQL2K8 R2) currently utilizing storage on our old SAN. We'd like to migrate to storage on the new SAN without rebuilding or moving the user DB. The infrastructure team's idea is to present the new LUNs to the server/cluster and then move all the files to these new LUNs.

The obvious problem here is that the system DBs can't simply be moved via the methods user DBs can be moved. And, while I could use the documented methods to move the system DBs, under SQL2K8 and later, the Resource DB can't be moved at all. So, it doesn't seem like this is possible in a straightforward way.

I'm thinking this would possible using sort of a shell game of shutting down SQL Server, copying all files to the new LUNs, renaming the old LUNs, renaming the new LUNs to the original old LUN names, and then bringing up SQL Server. I've not tried this before but it seems like as long as the new LUNs eventually had the original name of the old when the instance came back up (and we'd properly presented the LUNs to the cluster), this might work.

I know this isn't ideal. Ideally, I'd move all these DBs to the existing "real" cluster on the new SAN but changing client connectivity is a challenge right now.

Any gotchas to consider? There's no failover to test since it's a single-node cluster.

Improve this question

1 Answer 1

Reset to default
2

As long as the path names remain the same for your database files, this approach should work. This assumes that when you say "copying all files", your are ONLY moving the database files (data/log) and not the SQL Server binaries. If your SQL binaries and/or resourcedb need to be moved, you have a much stickier task ahead of you.

Your biggest gotcha should be maintaining the directory and database file permissions. I would handle this using ROBOCOPY with the /copyall switch to move the files while keeping all perms and attributes intact.

While outside of scope, if your end goal is to move the database to your full cluster and you're hurdle is client connectivity, have you considered using a DNS Alias to redirect traffic? I understand that the connectivity change could be larger in scope, but it could give you a path to consolidating your databases to where you want them.

Improve this answer
5
  • Well, not the binaries. On a cluster, these are on the C: drive on the server, so those don't move. It's all the database files (and the logs and what's under the FTDATA folder) INCLUDING the Resource DB, which is on the data LUN. This is a named instance so we did not setup a DNS Alias/CNAME.
    – Sandra
    Commented Apr 16, 2013 at 18:19
  • Your setup sounds very much like mine. If your path names and file perms don't change, you should be fine.
    – Mike Fal
    Commented Apr 16, 2013 at 19:32
  • Even for the Resource DB? I'm kind of worried about that one.
    – Sandra
    Commented Apr 16, 2013 at 21:26
  • Your resourcedb is going to live with your binaries. If you're not moving the binaries, you're not moving that, it will remain in the same location. For example, I have a cluster where my binaries are on the C:\, but all the other instance database files are on an attached LUN. I can move those other files in the attached LUN to wherever(even another LUN with the same name/path), but since I'm not moving my binaries, the resourcedb will always be on the C:\.
    – Mike Fal
    Commented Apr 16, 2013 at 21:35
  • Aarg.... There's a difference between 2005 and 2008 R2. (I actually have one of each instance on this server, something I neglected to mention.) My mssqlsystemresource .mdf and .ldf files are on the shared disk for the 2005 instance. But, there's no restriction on moving the Resource DB for 2005 - it just needs to be in the same location as the Master DB, which it will be. It doesn't look like I need do anything special on this?
    – Sandra
    Commented Apr 16, 2013 at 22:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.