March 28, 2008 at 4:37 am
We have a SQL 2005 Enterprise Edition (no SP) cluster with 2 nodes (Windows 2003 Server Enterprise Edition SP1).
We face a partially corrupted installation of SQL server in node2 (when it has the resources it's very slow, the maintenance plans are not executed etc)
What can we do?
a) We run SQL Server 2005 setup in the active node1, take out node2 from SQL cluster, and then put it back hoping that the installation program will put back all the appropriate SQL files in node2?
b) Must we evict node2 from the windows cluster and put it back?
Something other?
Thank you
March 28, 2008 at 5:26 am
What can we do?
a) We run SQL Server 2005 setup in the active node1, take out node2 from SQL cluster, and then put it back hoping that the installation program will put back all the appropriate SQL files in node2?
- Run the setup.exe from Node1. Choose to change the installation and choose the instance you want to change. Select to remove the corrupted node2. The installer will then remove the binaries from node2 and you'll be running a single node cluster.
- Reboot Node2 and check for errormessages (btw - do you know why it was slow?). Solve errormessages and check os is working normally. Do you have same Service Pack on both nodes - if Node2 is behaving abnormally you could now reapply SP1. Reboot
- Run setup.exe from Node1 and change the installation to contain Node2. Binaries will be installed again and you should apply sql servicepack on node2 (also remember to update the cluster unaware components on each node).
You should test this procedure in VMWare or MS Virtual Server/PC and have all steps available before doing it in production.
2) Dont evict from cluster unless you want to reinstall OS on Node2.
Hope this helps!
March 28, 2008 at 8:02 am
Agreed, don't evict the node, it should not be necessary unless something is drastically wrong with the operating system configuration.
The maintenance plans not running makes sense from the perspective of a partially corrupted SQL Server install. But the performance problems likely have another, more fundamental reason. As the previous poster indicated, I would look to determine that was no longer present before re-installing SQL Server onto the second node.
K. Brian Kelley
@kbriankelley
April 2, 2008 at 11:58 pm
Thank you guys,
I'll schedule it very soon.
I'll check your comments about the performance issue.
April 11, 2008 at 3:06 am
Finally there was a problem with one of the 2 controllers of our SAN. Our 2 servers belong to an HP farm EVA 4000. Because we were not sure about the file integrity in our 2 clustered servers we decided to kill them.
So we transfered the databases to a Microsoft virtual server to have our users working (again SQL Server 2005 enterprise edition with no SP). We killed the 2 servers, we reinstalled the operating system (Windows 2003 Enterprise Edition SP1) through the HP interface, we applied all the Windows updates, we created again the cluster and finally we reinstalled clustered SQL Server 2005 successfully.
We backed up the databases on the virtual server and then then we tried to restore the first production database back to the cluster. The percentage went normally and quickly to 90% and then stopped proceeding. We left it as it was and today we found that the restore was successful. Seeing the SQL current log we saw that the restore was finished 8 hours from the beginning!
We thought that we must apply SQL SP2. We put it and then we tried the restore again. It stopped proceeding again to 90%. After 1 hour we stopped the restore action and we deleted the database.
Why do we have this big delay in the restore action? Is it a matter of SQL Server tuning?
Another question: Must we upgrade the SQL workstation components in our PCs to SP2 as well?
Thank you
April 11, 2008 at 3:22 am
About the maintenance plans not running.
First of all you should install SP2 because maintenance plans on the RTM version had quite a lot of bugs.
Second maintenace plans make use of Integration services. SSIS is by default not installed as a cluster resource. You have to install SSIS manually on node2.
Hope this helps
[font="Verdana"]Markus Bohse[/font]
April 11, 2008 at 7:16 am
When the databases stopped - did you have any issues with disk? Try restore again and monitor the physical/logical disk performance of the volume you have the data and logfiles. There should be heavy write operations (disk queue lenght) during the restore.
If it behaves normally then there is a sql issue. I have never experienced this myself.
Please update.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply