SQL SERVER – Login Failed – Server is in Script Upgrade Mode – Deleting Collection Set “Utility Information”

SQL SERVER - Login Failed - Server is in Script Upgrade Mode - Deleting Collection Set "Utility Information" browser I must confess that consulting has taught me much more than what I have learned in my regular job. Freelancing comes with advantages and disadvantages. For me, I am looking at advantages and I am happy with my decision. Let us see how to fix an error related to Login Failed and Deleting Collection.

Whenever there is an upgrade of SQL version, it is expected that the server would go to the script upgrade mode and would finish it as a part of database recovery. There are many situations where I have seen server getting stuck to script upgrade mode. This is the blog which I have written long ago to troubleshoot such issues.

SQL SERVER – Login Failed For User – Reason Server is in Script Upgrade Mode

One of the client followed above article and shared information about their SQL script upgrade mode.

2017-05-16 01:29:18.66 spid7s Creating [dbo].[fn_sysutility_mi_get_batch_manifest] function
2017-05-16 01:29:18.78 spid7s Deleting collection set “Utility Information”…
2017-05-16 01:29:42.21 Logon Error: 18401, Severity: 14, State: 1.
2017-05-16 01:29:42.21 Logon Login failed for user ‘India\SQLSvc’. Reason: Server is in script upgrade mode. Only administrator can connect at this time. [CLIENT: ]

I have asked to share information about below tables as they were found in the script

use msdb
select COUNT(*) from sysssislog(nolock)
select COUNT(*) from syscollector_execution_log_internal(nolock)

There were having a huge number of records 400K+


To allow connections to SQL, we need to start SQL services with trace flag 902. Here are the steps which helped my client.

  • Keep the SQL Server Service running with the T902 startup parameter
  • Backup MSDB database and remove the data of the above two tables.
  • Remove the -T902 parameter.
  • Restart the SQL Server service to allow the upgrade script to finish.

I was not able to spend much time to identify why those tables had a huge amount of records. It may be due to a lot of SSIS packages? May be due to excessive logging? Since the issue was resolved by manually cleaning the tables, they never wanted to spend more time and money to find the cause of the error.

Reference: Pinal Dave (http://blog.SQLAuthority.com)

Exit mobile version