SQL Server 2014 (12.0.4439.1) to SP2 (12.5000) service start failure

Question

In what seems to be eerily familiar to the oh-so-famous SSISDB SP1 fiasco, I've hit a snag while upgrading our DEV server to SQL 2014 SP2.

The base version was SP1+CU5 (12.0.4439.1). We have SSISDB installed and it's in an AG. I ran the upgrade package on the secondary and received an error that SQL Agent was unable to start.

I went and checked the services via config manager and saw that none of the services came back up. Here's what the log file has given me:

2016-07-25 15:02:44.76 spid5s      Database 'master' is upgrading script 'SSIS_hotfix_install.sql' from level 201331031 to level 201331592.
2016-07-25 15:02:45.89 spid5s      Error: 945, Severity: 14, State: 2.
2016-07-25 15:02:45.89 spid5s      Database 'SSISDB' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.
2016-07-25 15:02:45.95 spid5s      Error: 912, Severity: 21, State: 2.
2016-07-25 15:02:45.95 spid5s      Script level upgrade for database 'master' failed because upgrade step 'SSIS_hotfix_install.sql' encountered error 945, state 2, 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.
2016-07-25 15:02:45.95 spid5s      Error: 3417, Severity: 21, State: 3.
2016-07-25 15:02:45.95 spid5s      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.
2016-07-25 15:02:45.95 spid5s      SQL Server shutdown has been initiated
2016-07-25 15:02:45.95 spid5s      SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.

Anyone else experience this? How do I go about bringing this thing back up? Do I actually need to restore the master DB?

If there's any additional information you need, just let me know. This is a non-production secondary that this happened to so we're not dealing with downtime or breaking any SLAs. If this is the same issue we ran into with SP1, I'd definitely like to get the word out.

Answer 1

We have SSISDB installed and it's in an AG. I ran the upgrade package on the secondary and received an error

Secondary user databases in an availability group are not available to be written to (readable at best). Thus the upgrade failed as the database is part of the AG and not able to be written to.

How do I go about bringing this thing back up? Do I actually need to restore the master DB?

I haven't tested it but you should be able to recover using -m, remove the SSISDB from the AG, then restart as normal.

Going forward you'll want to remove the SSISDB from the AG before running the upgrade and bringing it back in after the upgrade. Is it a pain? Yep. Will it stop you from having issues? Yep.