SqlServer is in script upgrade mode

Question

Vista just finished one of its many updates. After restarting my computer I try connecting to SqlServer2008 instance with Sql Server Management Studio and I get this error:

Error connecting to '...\MSSQLSERVER2008'. Additional information: Login failed for user '...'. Reason: Server is in script upgrade mode. Only administrator can connect at this time. (Microsoft SQL Server, Error: 18401).

Pressing help gets me to an internet page saying there's no additional information.

Thx Vista & Updates. Anyone an idea because on the internet I can't find anything about this issue.

Spoke

Even in 2012 an update can cause this. There should be a message warning or something from the app. Due to you question I just waited for it to complete. – Anticlerical

support.microsoft.com/kb/2163980 This worked for me – Burner

Answer 1

It appears This Guy was having the same problems as you and his only suggestion was to wait a few minutes before trying to log in again.

I have yet to see any type of Microsoft documentation about this, nor have I seen any forum posts which came to any sort of resolution concerning the same problem.

Readymix

This worked for me too. I had only just started the service. Looking at the event log, after 4 seconds it prints a message saying SQL Server is now ready for client connections. However it takes a further minute from the service starting until the Database Engine declares Recovery is complete.. I couldn't really find what it was trying to recover. – Pierro

For me this was immediately following application of SP3 to a new instance 2008 Express R2 – Karren

my case, sql 2008 R2 express, need to wait for 5 min. Perhaps it came from Windows Auto Update (no backup information, just a hunch)., – Hedvah

Answer 2

Check your event viewer. I had the same problem and found that (in my case) it was looking for a directory that didn't exist to perform an upgrade script. NO hint that there was any sort of problem in the dialog, but the event viewer showed clearly what the problem was.

jim

Sadness

I had the same problem (well, close enough) and it was because I moved drives around and the SQL Default Data directory still pointed at the old non existant drive letter. This MS blog entry showed me which registry keys to change to fix it so the script upgrade would run: blogs.msdn.com/b/sqlserverfaq/archive/2010/10/27/… – Awed

Answer 3

I had the same problem. Waiting until update was done did not help. Solution was, (after checking Windows eventlog) to set the folder rights. SQL-Express had no rights on the database folder, why ever. Something has mixed up the rights during the upgrade from WinXP to Win 7. That was it.

Overcurious

Answer 4

Adding a comment to this page since this is the top Google result for "script upgrade mode". It seems that a number of things can cause a SQL Server DB to go into this mode. In our shop we've run into these two cases in the past months:

1. Log shipping - Can't recall at what point of the process exactly the DB went into this mode, iirc it was when bringing it back up. The solution was just to wait it out.

2. Hard drive full - The DB went into this mode when it ran out of space. We're currently clearing up the drive, will come back with an update if waking it up turns out to be challenging. Update: After freeing up disk space, it was a simple matter of setting the DB "Offline" and then "Online" to bring it back up.

Experiential

Answer 5

We had the same issue, but needed to know what was going on in the background.

The db's were put into recovery mode, hence they had to recover. To assist we went to the SQL Server error log located where the system files (normally master, model, msdb...) are located, but under the log folder. In the ERRORLOG, we did a find on the word recovery and could watch the db's percentage recovered. Everything recovered normally, but it was much longer than expected.

Data

Answer 6

The Reason for this is that the system reboot happens with important\necesssary softwares loaded and does all other operation later so that the booting happens faster.

Here in your case, the sql booting is happening as the start of SQL is not needed for system to start. I hope you are aware of DAC account(Dedicated Administrator Connection, Link) who has seperate connectivity and has ability to resolve issues even the whole SQL server is not responing. The SQL server is asking you either to wait or open the SQL with DAC account and stop the SQL update.

Solutions:

1) Wait until backround update completes

2) Open SQL using DAC account and kill all running processes

Chondrite

Answer 7

This just happened to me, on SQL Server 2022 on Windows Server 2022.

I'd applied this month's (2024-July) updates to Windows and SQL onto my passive SQL instance, but not my active SQL instance. In order to test whether the updates are good, I rebooted the active instance, to force it to fail over to the passive instance, that way I could fail it back to the unpatched instance if necessary.

What happened was, the failover worked and SQL server came right up on the passive instance (i.e. it became the active instance), but it refused all connection attempts with the message: "Login failed for user 'so-and-so'. Reason: Server is in script upgrade mode. Only administrator can connect at this time."

I checked task manager and saw that the SQL server process was consuming 8%, i.e. one of its 12 allocated CPUs was running full-tilt, and its memory usage was gradually climbing... sort of like you'd see when compiling a lot of sprocs.

We do have a ton of sprocs, and we do run trace flag -t8032 to increase the size of the procedure cache from ~8GB to ~32GB, so possibly that is related... but in previous failovers I've never seen it take so long to come back up.

It took a grand total of 8 minutes to finish, and return to normal. I probably aged 8 months during that time. But now everything is fine. :/

Gambado