July 4, 2011 at 7:29 am
Hi all,
current situation:
we are currently running out of space on production server (SQL 2000)
Databases size 1.3TB
Drive Size (Raid 5+1) 1.45TB
we bought 7 new disks 900gb each one and we installed them on the same Disks Array creating a new raid 5+1.
Now we have a second Drive that have 3.35TB (empty)
the idea:
My plan is to stop all sql services and use ROBOCOPY to clone the old DRIVE (including folders permissions)
Then change the old drive letter from "E" to "O"
Change the new drive letter from "Z" to "E"
Restart the server
I've been searching in the forum but I couldn't find any post about somebody that tried something like this.
Do you have any experience?
Unfortunately I have only sunday for the "migration" and the backup is not fast enough.
I read that on many post to detach, copy/move and reattach the databases but in this way it's faster.
I made already a test with on my test server (desktop Pc with 2x2Tb in raid 0) and it worked pretty fast. 150 Gb in 30mins.
After the restart I checked the integrity on all databases and it was ok.
What do you think? Am I crazy or would it be a good solution?
I'm a SW developer, not a real DBA, the DBA did quit 2 months ago...
Thanks
July 4, 2011 at 8:35 am
I'm no SAN or storage expert but I have to ask... Is there a reason why the new disks can't simply be assigned to the current "E" drive or why you can't create a second "partition" on the new drive letter to store an NDF file or two?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 4, 2011 at 8:49 am
Jeff Moden (7/4/2011)
I'm no SAN or storage expert but I have to ask... Is there a reason why the new disks can't simply be assigned to the current "E" drive or why you can't create a second "partition" on the new drive letter to store an NDF file or two?
Hi Jeff,
the reason it's that we're planning to use them on another server and anyway the old array contains already 10 disks + 2 spare in a 5+1 raid.
I agree with the Sys Adm when he says that too many disks in the same array increses to much the chance to lose the array.
Regards
July 4, 2011 at 12:23 pm
I have done this same procedure on several systems - and it works quite well.
The last time we had to do this, I didn't even have to get involved. The SAN guys used their utilities to present the new drive, implemented a background replication process that replicated the data from the old drive to the new drive and on the day of the transfer, they shut down SQL Server - performed a final synchronization and restarted the server.
During the restart, the system swapped the drives for us and SQL Server came up on the new drives with no issues and no loss of data. It was absolutely spectacular...
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
July 5, 2011 at 3:40 am
Jeffrey Williams-493691 (7/4/2011)
I have done this same procedure on several systems - and it works quite well.The last time we had to do this, I didn't even have to get involved. The SAN guys used their utilities to present the new drive, implemented a background replication process that replicated the data from the old drive to the new drive and on the day of the transfer, they shut down SQL Server - performed a final synchronization and restarted the server.
During the restart, the system swapped the drives for us and SQL Server came up on the new drives with no issues and no loss of data. It was absolutely spectacular...
Thank you Jeffrey, I think I saw a post in this forum where you adviced such a solution, but it was an advice.
So now I'm writing my short script to stop services and (if I find a way) to swap drive letters and finally to restart the server using the shutdown command once copy is finished.
Thank you again.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply