January 11, 2008 at 8:42 am
The particulars:
SQL Server 2000 sp3 (yeah, I know...)
Windows 2000 Server (yeah, I know...)
*.mdf and *.ldf files on RAID1 array
I am not Captain Hardware. My network guy firmly believes that 'we' can convert a RAID1 hard disk drive array into a RAID5 array without stopping the SQL Server installation that has both its *.mdf and *.ldf files on said RAID1 array.
If I can't move the *.ldf or the *.mdf files from one location to another while SQL Server is running, what reason do I have to believe that 'we' can move these files from RAID1 to RAID5 on-the-fly?
The plan isn't my idea, but it is to perform this migration on a production system without an outage. Please let me know if it is within the realm of possibilities.
Thank you in advance for your time.
January 11, 2008 at 8:52 am
This is really a hardware question about your particular hardware, not a SQL Server question.
That said, I have my doubts about it, and I wouldn’t want to try it on a production system without seeing it tested; especially since it sounds like you cannot afford downtime. I would be worried that you would lose the array entirely, and have to restore from backups.
The question I have is: Why you would want to do this? What is the advantage of this conversion that makes the risk worth it?
January 11, 2008 at 8:57 am
Thank you for your response, Michael. Your point is well-taken, I am the dog being wagged by the tail. Bark-bark. 'We' have outgrown the current RAID1 configuration, I need more hard disk drive space.
January 11, 2008 at 9:06 am
I would recommend just adding another array to the system, create an new partition and format it, and then create new database files in the existing filegroups on the new volume.
New database files can be created while the database is in use, and SQL Server will start using them to put new data into.
You might need some downtime to install the new hardware, but it is probably a less risky approach than what is being proposed now.
January 11, 2008 at 9:14 am
Another approach is to setup a new server, move the databases to that, and rename the new server to the old server name when you are ready. By restoring the DB onto a new server with no recovery and rolling forward the DB with transaction logs until you are ready to transition, you can have a very short downtime, maybe 10 minutes.
This lets you upgrade to faster processors, more memory, larger faster disks, newer OS, etc., and improve performance across the board. I have done this a number of times without any problem.
January 11, 2008 at 9:18 am
I'd be nervous about that new approach, since you're now mixing RAID 1 and RAID 5. (meaning - half of the files in the filegroup would be on RAID1, and the other on RAID 5). You get fairly different performance out of the two, so I wouldn't want to be charged with tuning that.
What kind of size are we talking about? The amount of downtime would be directly proportional to how long it would take to copy the data from the RAID1 volume to the RAID 5 volume. On decent drives, how long could that take?
Like Michael pointed out - I'd be really hesitant to try out this theory (about converting RAID 1 to 5 on the fly). It's one of those where the cost benefit analysis just doesn't compute for me: you might save 20 minutes, but if it fails - you've corrupted your DB which will then cause a much bigger outage to fix....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
January 11, 2008 at 9:25 am
I smell what you are stepping in, Michael. Tail wagging dog, remember? This is the plan I have been instructed to follow: upgrade ServerX from RAID1 to RAID5 on-the-fly, failing this, rebuild ServerX. I just work here, being told what to do, etc. I was told that there are no other/spare servers available.
Yeah, I know.
When the RAID1 to RAID5 conversion on-the-fly-because-we-don't-want-any-downtime fails, 'we' will be down while the server is rebuilt, 146GB database is restored, replication rebuilt, etc.
You guys aren't hiring, are you, Michael?
January 11, 2008 at 9:39 am
Sometimes you just have to step up and tell them you have a better plan. Most bosses would be grateful to have someone that keeps them from making a mistake. Explain the problems with the current plan, explain why your plan is a better alternative, and answer any concerns.
Remember that nothing will prevent them from blaming you if the current plan goes wrong, even if it isn’t your plan. “If you knew that could happen, why didn’t you tell us?…If you didn't know that could happen, why not?...”
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply