Issues installing SQL2K5 on existing SQL2k cluster

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

Old Forums

CLOSED - SQL Server 2005/Yukon

Issues installing SQL2K5 on existing SQL2k cluster

Author

Topic

eyechart
Master Smack Fu Yak Hacker

3575 Posts

Posted - 2006-04-22 : 17:47:04

We have run into serious problems installing SQL2K5 on our existing 64bit x64 SQL 2K cluster environment. Please do not install SQL2K5 on any similar environment without reading this thread.

We have run into issues when running the following configuration:

1. 64bit hardware running 64bit x64 edition of Win2k3 SP1
2. Cluster environment
3. Have existing installed 32bit SQL2K virtual hosts
4. Use Veritas Storage Foundation (or other software that uses vssadmin list writers)
5. Have applied a hotfix and workaround to vssadmin slowness - see below
6. Attempt an install of 64bit SQL 2005.

Please see the latest posts for more information.

-ec

~~whatever you do, do not install SQL 2005 in a cluster environment that already has SQL 2000 virtual hosts. This will completely jack up your system and (so far) there is no easy recovery from this.~~

EDIT:
I have changed the name of this thread and edited the text now that the problem is understood a little better. The previous subject was called "DO NOT INSTALL SQL 2005 on a cluster w/SQL 2000"

eyechart
Master Smack Fu Yak Hacker

3575 Posts

Posted - 2006-04-23 : 00:24:25

now that I am off the phone with microsoft, I thought I might post to let people know the problem we are having.

here is our situation:

1. Opteron hardware, 64bit x64 windows 2003 sp1
2. 1 existing 32 bit SQL 2000 sp4+ instance installed and functioning perfectly
3. Installation of SQL2k5 64bit fails at the last step (bringing cluster resources online)

After the failed installation of 2k5, the other sql 2000 instance fails to come online using cluster admin. we can bring the instance online using the services applet, but we can only make shared memory connections to it (no named pipes, or tcp). The only way to get a named pipe or tcp connection to work is to use an alias in cliconfg. Even when using an alias, the instance fails to come online with cluadmin.

We get crazy errors in the cluster log and application event log. I will post them here later.

recent changes to the environment:

1. addition of the latest security hotfixes (including mdac hotfix) on 4/14/2006
2. installation of sql2k5 on 4/20/2006

the cluster worked fine after the security hotfixes were installed. We rebooted multiple times and performed a rolling upgrade. After the failed 2k5 installation we attempted to uninstall it. This was only partially successful and we had to use msizap and msiinv to completely (we think) remove 2k5 from the system. I think there are still remnants, because even after uninstalling 2k5 we could not bring 2k online.

We also performed a complete uninstall of the SQL 2k instance and installed from scratch. The install failed at the last step (just like 2k5 did) when bringin the cluster resources online.

I am not certain that this is a problem with SQL 2k5 and SQL 2k, I would just be very careful if you are planning to install both of these on the same hardware, especially when installed on a cluster.

-ec

Kristen
Test

22859 Posts

Posted - 2006-04-23 : 00:48:23

Thanks for the Heads Up ec. Good luck with sorting it out.

Jen's Fridays turning into your Saturdays, or what?

Kristen

eyechart
Master Smack Fu Yak Hacker

3575 Posts

Posted - 2006-04-23 : 00:49:50

quote:
Originally posted by Kristen

Thanks for the Heads Up ec. Good luck with sorting it out.

Jen's Fridays turning into your Saturdays, or what?

Kristen

well, it actually started on thursday...

-ec

Kristen
Test

22859 Posts

Posted - 2006-04-23 : 01:46:18

MS making a drama into a Three Part Mini Series, eh?!

eyechart
Master Smack Fu Yak Hacker

3575 Posts

Posted - 2006-05-09 : 00:51:10

I have been able to successfully clean our environment and then install SQL2K and SQL2K5 without killing our cluster. I have also been able to determine the config that kills the system and have passed that information on to microsoft for further study.

basically, the issue we ran into will only occur if you hve the following setup:

1. 64bit hardware running 64bit x64 edition of Win2k3 SP1
2. Cluster environment
3. Have existing installed 32bit SQL2K virtual hosts
4. Use Veritas Storage Foundation (or other software that uses vssadmin list writers)
5. Have applied a hotfix and workaround to vssadmin slowness - see below
6. Attempt an install of 64bit SQL 2005.

Step 5 is the critical one here. Because the vss junk is 64bit it expects to find information about SQL Server in the 64bit portion of the registry. Since only 32bit SQL is installed (at that point) there is no SQL info in the 64bit portion of the registry. This registry problem caused any software that utilized VSS to timeout. We would get the following eventlog errors when that occured:

Event Type: Error 
Event Source: VSS Event 
Category: None 
Event ID: 6013 
Date: 4/7/2006 
Time: 4:37:07 
PM User: N/A 
Computer: XXXXXXXXXX
Description: Sqllib error: OLEDB Error encountered calling 
IDBInitialize::Initialize. hr = 0x80004005. SQLSTATE: 08001, Native
Error: 17 Error state: 1, Severity: 16 Source: Microsoft OLE DB 
Provider for SQL Server Error message: [DBNETLIB][ConnectionOpen
(Connect()).]SQL Server does not exist or access denied.

This error causes a timeout, and the software that you are running will hang for 20 to 40 minutes becuase of this. That is no fun when you are trying to configure new disk using the Veritas Enterprise Admin tool. Btw, this same error can occur if you use some other software that uses the vss functionality in win2k3. Usually, this is going to be disk or backup related software. Remember, that this problem only occurs in the config outlined above.

The workaround from Microsoft to fix these timeouts is to copy The SQL Server portions of the 32bit registry area (HKLM\SOFTWARE\Wow6432Node\Microsoft) to the 64bit area (HKLM\Microsoft). This prevents the vss stuff from timing out and your software then runs at acceptable speeds. Apparently the presence of this information also causes the SQL2K5 installer to completely lose it's mind. Not only that, but it totally jacks your cluster up and you will be unable perform any cluster failovers after the 2k5 install fails.

Since this workaround came directly from microsoft, we are having them look into it a little further for us. The simple solution that I see right now is to remove that information prior to attempting a 2k5 install on your system. Because, once 2k5 is successfully installed there will be real registry information in that 64bit portion that the vss junk is looking at. However, if you fail to remember to do that - If you leave the copied 32bit registry info in the 64bit registry area - you are hosed.

I have not yet determined if there is an easy fix once you've hosed your environment, so far we have had to clean the entire system of all SQL Server and remove every bit of SQL Server from the registry in order to reinstall SQL 2000 and get it running again. Not fun when you have 5 instances installed on your cluster.

-ec

Subscribe to SQLTeam.com

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -

Resources