SP3 upgrade on SQL 2008 issue

  • Hi,

    Recently we tried upgrading SQL 2008 cluster instance from SP2 to SP3. After patching done on passive node, we tried connecting to SQL instance through SSMS, but got the error "Login failed for user. Server is in script upgrade mode. Only administrator can connect at this time".

    Can someone please let me know the reason and its solution?

    Regards.

  • this is normal behaviour and hopefully upgrade script mode has completed by now.

    the last phase of patching a SQL2008+ cluster node is to fail over to the node, at that point SQL comes up and completes the patch by going into script upgrade mode, no one is allowed to log on until this completes. How long this takes will vary depending on how many databases are on the server and anything that affects the speed of the server. Would normally complete in a few minutes.

    If you look at the SQL errorlog through notepad you will see SQL running scripts against the databases. When you see the message 'recovery is complete' you will be able to log on.

    ---------------------------------------------------------------------

  • It took around 8 hours to become normal. I dont think in a production environment, we can afford this much downtime. Is it a bug or anyway realted due to OS version? In my case its Windows Server 2008 r2.

    Regards.

  • 8 hours is way over the top, take a look through the errorlog to see which parts took so long. I am not aware of any OS dependencies or bugs that affect this so reporting to MS is probably worthwhile.

    If you have a lot of databases that definitely affects the time this takes to run (though I have a server with over 300 and the script upgrade phase was still just a few minutes).

    Only other thing I can think of is the database log files having large no of VLFs affecting database recovery time. How long does a node usually take to start up?

    ---------------------------------------------------------------------

  • That is WAY too long. Should take minutes. Look at the SQL Server log and see what happened and the Windows event log for clues as to what was going on at the time.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply