I have helped many clients in upgrade failures via my On-Demand consulting and I am amazed to see various ways which can break SQL Server upgrade. In this blog we would learn about fixing error Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’
Below are few earlier blogs which have other causes of same error:
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.
2018-01-13 02:23:59.43 spid9s Checking the size of MSDB…
2018-01-13 02:24:19.68 spid9s Error: 5041, Severity: 16, State: 1.
2018-01-13 02:24:19.68 spid9s MODIFY FILE failed. File ‘MSDBLog’ does not exist.
2018-01-13 02:24:20.16 spid9s Error: 912, Severity: 21, State: 2.
2018-01-13 02:24:20.16 spid9s Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’ encountered error 598, state 1, severity 25. 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.
2018-01-13 02:24:20.18 spid9s Error: 3417, Severity: 21, State: 3.
2018-01-13 02:24:20.18 spid9s 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.
If we look at error just before the generic error of “script upgrade”, we see it gives an error about MSDB database. Now we need to figure out what is wrong with MSDB, which is a system database.
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.
- As I mentioned earlier, first we started SQL with trace flag 902. I started SQL using trace flag 902 as below via command prompt.
NET START MSSQLSERVER /T902
For named instance, we need to use below (replace instance name based on you environment)
NET START MSSQL$INSTANCENAME /T902
As soon as SQL was started, we were able to connect because upgrade didn’t run.
- Executed below command to look at MSDB database files.
SELECT name ,physical_name FROM sys.master_files WHERE database_id = DB_ID('msdb')
When I compared with my system the logical names were MSDBData and MSDBLog instead of MSDBData_1 and MSDBLog_1
- Executed following command to fix the file names
ALTER DATABASE msdb MODIFY FILE (name = 'MSDBData_1', newname = 'MSDBData'); GO; ALTER DATABASE msdb MODIFY FILE (name = 'MSDBLog_1', newname = 'MSDBLog'); GO;
- After modifying, we stopped SQL Service and started normally (without trace flag)
With above steps, SQL services got started successfully. My client was wondering how it happened. I asked if they have been any disaster due to which they might have restored MSDB database and they recalled a situation. SQL Server doesn’t change logical file names of system databases by itself.
Have you encountered any other upgrade issues?
Reference: Pinal Dave (https://blog.sqlauthority.com)