As soon as SQL 2008 and SQL 2008 R2 went out of support, few of my clients contacted me to help them in fixing an error occurred during the upgrade. In this blog, I would share one of the upgrade failures. The Upgrade Error messages shown in ERRORLOG was “The server principal “SQLAuthority\AuthOwner” is not able to access the database “msdb” under the current security context.” I have changed the error message to hide secure information.
The situation was that they initiated upgrade and it failed at the very end and then SQL Service was not getting started. This is what I call as upgrade script failure. There are a few situations I have seen earlier which we have encountered due to some change in system settings. Here are a few earlier blogs about similar failures.
- SQL SERVER – Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’
- SQL SERVER – Script level upgrade for database ‘master’ failed – There is already an object named ‘DatabaseMailUserRole’ in the database
- SQL SERVER – Script level upgrade for database master failed – Error: 4860, Severity: 16, State: 1 – Cannot bulk load. SqlTraceCollect.dtsx does not exist
- SQL SERVER – Error 15559 – Error 912 – Script Level Upgrade for Database ‘master’ Failed
This time it was a new error, so I am blogging it. As usual, I asked for ERRORLOG and was looking for the cause of failure. Here are the last few lines in ERRORLOG when SQL was trying to start.
Error: 916, Severity: 14, State: 1.
The server principal “SQLAuthority\AuthOwner” is not able to access the database “msdb” under the current security context.
The failed batch of t-sql statements :
disable the collector first
EXEC sp_syscollector_disable_collector
Error: 912, Severity: 21, State: 2.
Script level upgrade for database ‘master’ failed because upgrade step ‘msdb110_upgrade.sql’ encountered error 916, state 1, severity 14. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the ‘master’ database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 3417, Severity: 21, State: 3.
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
SQL Server shutdown has been initiated
SQL Trace was stopped due to server shutdown. Trace ID = ‘1’. This is an informational message only; no user action is required.
Whenever we have such upgrade script failure issue and SQL is not getting started, we need to use trace flag 902 to start SQL which would bypass script upgrade mode. This would allow us the find the cause and fix it. So, here are the steps I have done.
- Start SQL Server via Trace Flag 902. Based on default or named instance, run below command
NET START MSSQLSERVER /T902
or
NET START MSSQL$INSTANCE_NAME /T902
- At this point, SQL should be started, and you need to connect to SQL by any of the preferred methods. You can use SSMS or T-SQL.
- Based on the error message, the error was due to the database owner of the MSDB database. We executed the below script to change the owner of msdb database to “sa”. Even if it is disabled, it is fine.
USE msdb GO EXEC sp_changedbowner 'sa' GO
- Once the owner is changed, we need to stop SQL Service and start it again. You are free to use any method to stop and start the SQL service. I have used the command line to do the same.
NET STOP MSSQLSERVER /T902
or
NET STOP MSSQL$INSTANCE_NAME /T902
That’s it. You should be able to start SQL normally and come back in business. Have you encountered any such upgrade issues?
Reference: Pinal Dave (https://blog.sqlauthority.com)
First appeared on SQL SERVER – Upgrade Error: The Server Principal is Not Able to Access the Database “msdb” Under the Current Security Context