No que parece ser estranhamente familiar ao tão famoso fiasco do SSISDB SP1, encontrei um obstáculo ao atualizar nosso servidor DEV para o SQL 2014 SP2.
A versão base era SP1+CU5 (12.0.4439.1). Temos o SSISDB instalado e está em um AG. Executei o pacote de atualização no secundário e recebi um erro informando que o SQL Agent não pôde iniciar.
Eu fui e verifiquei os serviços via gerenciador de configuração e vi que nenhum dos serviços voltou. Aqui está o que o arquivo de log me deu:
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.
Alguém mais experimentou isso? Como faço para trazer essa coisa de volta? Eu realmente preciso restaurar o banco de dados mestre?
Se precisar de alguma informação adicional, é só me avisar. Este é um secundário de não produção com o qual isso aconteceu, então não estamos lidando com tempo de inatividade ou quebra de SLAs. Se este é o mesmo problema que encontramos com o SP1, eu definitivamente gostaria de divulgar.
Os bancos de dados de usuário secundário em um grupo de disponibilidade não estão disponíveis para gravação (na melhor das hipóteses, legíveis). Portanto, a atualização falhou porque o banco de dados faz parte do AG e não pode ser gravado.
Eu não testei, mas você deve conseguir recuperar usando -m, remover o SSISDB do AG e reiniciar normalmente.
No futuro, você desejará remover o SSISDB do AG antes de executar a atualização e trazê-lo de volta após a atualização. É uma dor? Sim. Isso o impedirá de ter problemas? Sim.