February 4, 2009 at 9:17 am
Why dont you look at the instalation log (check event log for link) then you will find the reason.
In my case - it was caused by me changing default DB store location - so the same problem as Doug
suggested. After I change it back to default it works as expected.
May 12, 2009 at 3:37 am
No need to stop or failover.
Only the instances that are running on the current node can be patched.
May 13, 2009 at 7:26 am
I had the same problem on my cluster. I installed sp3 on the primary node, waited while it tried to patch the secondary node and the database patch failed. Everything else patched fine.
May 13, 2009 at 12:13 pm
Same problem here on a active/passive cluster.
I shutdown the passive node and the installation succeeded. Then started a failover and shutdown the passive node and the installation succeeded again ....
Found this somewhere else, but worked fine for me.
May 13, 2009 at 2:19 pm
My Active/Passive Cluster SP3 installation was smooth and successful.
1. Connect to Active node, Install SP3 on Active node (with everything running, no failover, no shutdown)
2. when finished on Active node ( it suggested to restart Active node, But I didn't do it), connect to Passive node and install SP3; after selecting the features to install/update, it popped up a message asking me to restart the computer adn I DID it ( as it is a passive node, i thought)
3. When the passive node was back alive, I installed the SP3 again and this time there was no locked files, and the installation was quick as there was no database engine update.
4. Once passive was done, I reconnected to Active node and did a failover to passive node, and restarted the computer
5. After the rebooting, failback to the active node again and then all are good with SP3. 🙂
May 14, 2009 at 1:17 pm
Meredith Ryan (1/21/2009)
I left sql running on each node and no, it didn't pick up the second node when I did the install. Reboot was required for each node.In retrospect, if I had failed one sql instance over so that both instances were on one node it probably would have installed both at once... but then you still have non-clustered components like SSIS and client tools that need the update so you would still be running the install twice.
It would be good to keep all SP's, and even hotfixes, clean when installed and go for a reboot. We install our critical updates during our maintenance window (early Sunday mornings, 2am-5am) and always reboot, it's just easier that way and you don't have to second guess. Sometimes you can get away with doing it on passive nodes during the day, reboot, fail over, than repeat on primary node, before failing back. However, I do not recommend that method, better to do it all at once, and just tell the boss you're coming in late on Monday morning as you had to do the update.
Gaby
________________________________________________________________
"In theory, theory and practice are the same. In practice, they are not."
- Albert Einstein
May 14, 2009 at 1:30 pm
Gaby Abed (5/14/2009)
Meredith Ryan (1/21/2009)
I left sql running on each node and no, it didn't pick up the second node when I did the install. Reboot was required for each node.In retrospect, if I had failed one sql instance over so that both instances were on one node it probably would have installed both at once... but then you still have non-clustered components like SSIS and client tools that need the update so you would still be running the install twice.
It would be good to keep all SP's, and even hotfixes, clean when installed and go for a reboot. We install our critical updates during our maintenance window (early Sunday mornings, 2am-5am) and always reboot, it's just easier that way and you don't have to second guess. Sometimes you can get away with doing it on passive nodes during the day, reboot, fail over, than repeat on primary node, before failing back. However, I do not recommend that method, better to do it all at once, and just tell the boss you're coming in late on Monday morning as you had to do the update.
I do generally do a reboot after each update (sp or hotfix) for that very same reason... well, that and habit I suppose 🙂 and I am loathe to do updates during production hours. I've had that bite me in the rear too many times to risk it. I love it when vendors tell me that 'xyz' doesn't require a reboot and then have it do one anyways...
April 30, 2011 at 10:45 pm
Hi Firends,
This may be an old post but my doubt is vaild.
I have done a cumulative update for 2005 SP3 on a cluster.
The patching got failed due to some reason.
Only one node shows the latest version number. All other nodes are still in old one.
Question is should I install the CU from all other nodes to make it equal on alll nodes or uninstall the CU from aleardy instsalled node, then do a fresh install?
Notes:
Patching failed because it couldn't create temp_MS_AgentSigningCertificate_database.mdf database.
Cheers
John
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply