Moving SQL Server System databases to new drives

  • My employer is changing the SAN Vendor.  All DBs have to be moved to the new SAN. I have a plan ready to move user and system DBs and I am confident about it. However, there is a problem, we have got thousands of SQL Server jobs that run SSIS packages. The SSIS package paths are hard coded in the SQL Server agent jobs, the packages are on the same drive where .mdf files are hosted. There is no way to make changes to all these jobs without involving a large number of people.

    To stop all the SQL Server jobs from failing, the new drives will have to renamed back to original letters. So, we have got drives D: and E. Drive D: has log files for system as well as user DBs. Drive E: has .mdf & .ndf files and SSIS packages. I can move user DBs, system DBs and SSIS packages to 2 new drives, X: and Y. After doing this X: will have to be renamed back to D: and Y: to  E.

    If eventually the drive letters are going to be the same, do I need to change startup parameters the master DB at all and for that matter ALTER the path for other system DBs and user DBs? Can I just stop SQL Server services, copy all contests (.mdf, .ldf files for user and system DBs, SSIS packages and everything else) on the existing drives (D: & E:) to the new Drives (X: and Y:), rename the existing drive letters  to say P and Q and rename X and Y to D and E?

    Will there be any issues with SQL Server instance coming up? Would SQL Server be able see that though the drive letters are same but these are not the same drive and take objection to it?

    Appreciate the help.

  • i would think about slicing the new SAN into three drives; two big ones for the SQL stuff for db and logs, and a new,smaller one for the disk-based packages.

    move the databases to the new bigger drives, then move the packages to the smaller drive. then rename that original D: drive to X:, and rename the smaller one to the D: drive or whatever is expected.
    then the dependency for data drive <> package drive

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • jay81 - Tuesday, July 11, 2017 11:02 AM

    My employer is changing the SAN Vendor.  All DBs have to be moved to the new SAN. I have a plan ready to move user and system DBs and I am confident about it. However, there is a problem, we have got thousands of SQL Server jobs that run SSIS packages. The SSIS package paths are hard coded in the SQL Server agent jobs, the packages are on the same drive where .mdf files are hosted. There is no way to make changes to all these jobs without involving a large number of people.

    To stop all the SQL Server jobs from failing, the new drives will have to renamed back to original letters. So, we have got drives D: and E. Drive D: has log files for system as well as user DBs. Drive E: has .mdf & .ndf files and SSIS packages. I can move user DBs, system DBs and SSIS packages to 2 new drives, X: and Y. After doing this X: will have to be renamed back to D: and Y: to  E.

    If eventually the drive letters are going to be the same, do I need to change startup parameters the master DB at all and for that matter ALTER the path for other system DBs and user DBs? Can I just stop SQL Server services, copy all contests (.mdf, .ldf files for user and system DBs, SSIS packages and everything else) on the existing drives (D: & E:) to the new Drives (X: and Y:), rename the existing drive letters  to say P and Q and rename X and Y to D and E?

    Will there be any issues with SQL Server instance coming up? Would SQL Server be able see that though the drive letters are same but these are not the same drive and take objection to it?

    Appreciate the help.

    You'll need to arrange downtime to complete this.
    Set the new volumes up and give them temporary drive letters.
    Copy all the folders and data including the ACls, Robocopy will help you here.
    Remove the drive letters from the old volumes and assign them to the new volumes.
    The sql instance should start without issue if the paths and ACLs have been preserved

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply