June 26, 2009 at 9:48 am
I am new to this organization and I have acquired a SQL Server 2005 Enterprise 2node cluster system that has a Sharepoint portal running against (as well as some other applications) with a SAN expansion. I've been charged with uninstalling the OS and SQL Server 2005 application and reinstalling it as well as the db instances that currently reside on this PRODUCTION system. Why? Because current configuration doesn't appear to be working correctly and fixing it was not one of the options offered by management.
With that in mind, I am want to be sure I do this correctly because we will have a short window of time to do this. Below are the steps I've put together thus far but I'm not sure how to handle the db instances during this transition. I would appreciate your HELP/SUGGESTIONS! THANKS SO MUCH in advance!!
STEPS:
Back up current db instances
Move back ups to another location??
**not sure on this, does it have to be another sql server or can I move them to a file server
** what about the master db?? do I need to copy and move that to?
Uninstall SQL Server 2005
Uninstall Windows 2003 OS
Reinstall Windows 2003 OS
Configure SAN
Configure Windows Cluster
Reinstall SQL Server 2005/configure cluster
Reinstall necessary SQL Server 2005 add-ons
Apply necessary patches (Windows 2003 OS and SQL Server 2005)
Copy db instances from file server???
Does this sound right so far?? What else do I need to consider or need to do???
June 26, 2009 at 2:09 pm
CORRECTION ON 'STEPS' LISTED ABOVE:
STEPS:
Back up current db instances
Move back ups to another location??
**not sure on this, does it have to be another sql server or can I move them to a file server
** what about the master db?? do I need to copy and move that to?
Reinstall Windows 2003 OS
Configure SAN/Windows Cluster
Reinstall SQL Server 2005/configure cluster
Reinstall necessary SQL Server 2005 add-ons
Apply necessary patches (Windows 2003 OS and SQL Server 2005)
Copy db instances from file server???
Does this sound right so far?? What else do I need to consider or need to do???
June 28, 2009 at 2:19 am
The backups are just files so can go on any server, doesn't have to be a sql server. But - it could be better to detach the databases and copy the .mdf/.ndf/.ldf files as you won't then have to restore from backup and it will be quicker to get up and running (I'd do a backup as well though, just in case!)
The master db will contain all the security information and would be useful to have although the accounts can be scripted out. The msdb db will contain jobs which might be useful.
I'd test out the cluster before and after putting the databases back in.
What errors/problems are you getting that require a total reinstall?
June 28, 2009 at 12:03 pm
I would probably approach this a bit differently. It would require an additional downtime, but I think it would be worth it.
1) Remove second node from cluster
a) Remove SQL Server from the second node
b) Remove node from cluster
2) Rebuild secondary node as *new* single-node cluster
3) Apply all Windows patches up to current
4) Install SQL Server 2005 into cluster, apply service packs
5) Test new configuration
The above steps can be performed during business hours, with the risk that if the primary node has a problem you don't have a failover solution. However, the advantages are the ability to validate and verify the environment before moving.
Once the above has been completed, you can then script out the users from master and the jobs from msdb. Setup the users and jobs on new cluster, restore backups of existing system and validate the system.
At the downtime, you then swap the storage array out and perform a cluster recovery. This will redirect the existing LUN's pointing to the current server over to the new cluster. The new cluster would now own the resources and SQL Server can be brought up on the new cluster with access to the existing databases (no copying needed). Make sure you backup the databases before hand, of course.
The above will require that your new cluster has the same drive presentation. Only move and recover the LUN's that contain the database files and log files. Leave the LUN's that contain your system databases and temp database alone.
Switch application(s) to use new cluster name (or, redirect DNS from old name to new name).
Now, all you need to do is rebuild the old primary node and add it back into the cluster. Once added, you would need to install SQL Server and patch. The only problem you'll have with this is you will need to failover to the new node to apply the SQL Server service packs.
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
June 29, 2009 at 6:48 am
Good morning! And thanks for your reply. I think I will try this approach (in the test environment 1st, of course).
One of the reasons the reinstall has been requested is because whenever one of the servers within the 2-node cluster fails, the other server doesn't properly takeover. For instance, we are running a Sharepoint server where the databases reside within the 2node cluster sql server 2005 server(s). Whenever the server on the active node within the cluster fails, the passive node then assumes the active node role BUT the connection to the Sharepoint server is not re-established. Supposedly, there are other similar instances that I have not experienced.
I have asked can we first look at resolving the issue in the current setup but the direction has been given to do a total reinstall.
June 29, 2009 at 6:49 am
Thanks for your reply. This is a great idea! Only thing is that we will be installing the OS from scratch as well :-(...
June 29, 2009 at 7:58 am
One more question/clarification...are you also suggesting that I detach and copy over all the system databases as well?
I guess I should let you know that I'm also new to SQL Server 2005; I previously did some database administration in an oracle/unix environment. I'm actually seeking a training site that offers the 50006 (previously 7033) - SQL Server 2005 for the Oracle DBA.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply