During a routine SQL Server patching process on SQL Server some error messages appeared in the SQL Server Error Logs. As a result SQL Server was not able to start up
Configuration option 'show advanced options' changed from 1 to 1. Run the RECONFIGURE statement to install.
Error: 574, Severity: 16, State: 0.
CONFIG statement cannot be used inside a user transaction.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 574, state 0, severity 16. 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.
I attempted to restart the SQL Server service a few time , but all that happened was an attempt to rerun the script upgrade process with the same ultimate conclusion. A serious issue for a database server!
Using the trace flag 902 , I was able to add it to the start up parameters and this allowed the SQL Server to start and bypass the upgrade process. Although the SQL Server was running - I would consider this situation to be unstable and needed immediate remediation .
I've seen this problem before in previous patching cycles where SQL Server was Unable to start services after patching , but I'm adding some extra information to assist in any other trobleshoot scenarions
When executing this query I was no able to see the trace flag 902 - bypassing the script upgrade
SELECT
DSR.registry_key,
DSR.value_name,
DSR.value_data
FROM sys.dm_server_registry AS DSR
WHERE
DSR.registry_key LIKE N'%MSSQLServer\Parameters';
A closer inspection the error logs revealed some reasons why the script upgrade was failing -
A problem was encountered granting access to MSDB database for login '(null)'. Make sure this login is provisioned with SQLServer and rerun sqlagent_msdb_upgrade.sql
This was caused as a number of SQL Server Agent Jobs had no owners attached to the SQL Agent job .
Adding valid owners to the SQL Server Agent Jobs allowed fixed the issue. i.e I was able to take off the trace flag and the script upgrade process was able to complete successfully.
Read more on SQL Server trace flags
How to enable SQL Server trace flags at startup
How to trace SQL Server Backup
Help command in sql for undocumented commands