SQL Server Patch – Server startet nicht mehr

Manchmal kommen bestimmte Themen gleichzeitig zusammen. In diesem Fall wurden mehrere E-Mails von der Data Platform MVP-Verteilerliste empfangen, und es wurden verschiedene Kundenberichte und passende Beiträge in anderen Blogs zum Thema „wie DatabaseMailUserRole Ihr Patching stoppt“ gefunden, so dass ein deutscher Beitrag dazu entstanden ist. Es geht um einen Fehler, der seit mehreren Jahren in allen SQL Server Versionen und Editionen in verschiedenen Konstellationen auftritt. Die meisten DBAs werden nie mit diesem Problem konfrontiert werden, und sie werden wahrscheinlich auch nie vorher an dieses Problem denken. Wenn dies der Fall ist, finden Sie im Folgenden eine Erklärung.

Wann tritt der Fehler auf? – Ausgangslage

Der Fehler tritt während des Rollouts von Patches auf Windows-Servern (einschließlich kumulativer SQL Server-Updates) auf, und der SQL Server-Datenbankdienst wird nicht sauber neu gestartet. Die Fehlersuche beginnt, und irgendwann wird festgestellt, dass der SQL Server den Patch erhalten hat und dann sauber gebootet wurde. Der SQL Server-Datenbankdienst wurde jedoch nicht ordnungsgemäß neu gestartet. Die entsprechenden Meldungen im SQL Server-Fehlerprotokoll werden gefunden und es wird festgestellt, dass der SQL Server im Rahmen eines Patches auch die Datenbankstrukturen der Systemdatenbanken ändert. Diese Änderungen werden in der Regel mit T-SQL-Anweisungen über eine SQL-Datei durchgeführt. Diese Skripte sollten auf ALLEN (!) SQL-Servern für alle Kunden in allen Formen funktionieren, denn genau hier liegt das Problem. Es wird immer ein (oder zwei) Systeme geben, die „aus Versehen“ oder aufgrund einer administrativen Anpassung vom „Standard“ abweichen, wenn der Kunde es Ihnen sagt:

Übrigens, wir spielen gerade ein Backup ein, weil nach dem Windows-Update (inkl. SQL-Server-Updates) der Dienst für den Server (und einige andere Dienste) nicht mehr startet…

Die entsprechenden Meldungen finden Sie im Fehlerprotokoll des SQL Servers:

Error: 2714, Severity: 16, State: 6.
There is already an object named 'TargetServersRole' in the database.
Error: 2759, Severity: 16, State: 0.
CREATE SCHEMA failed due to previous errors.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 2714, state 6, 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.

Error: 2714, Severity: 16, State: 25.
There is already an object named 'DatabaseMailUserRole' in the database.
Error: 2759, Severity: 16, State: 0.
CREATE SCHEMA failed due to previous errors.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’ encountered error 2714, state 6, 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.

Wie lässt sich das Problem mit der DatabaseMailUserRole lösen?

Bei „TargetServersRole“ genügt es, den SQL-Dienst manuell mit dem Trace-Flag 902 zu starten und das Schema in der „msdb => Sicherheit => Schema“ zu löschen. Bei der „DatabaseMailUserRole“ wird es etwas komplizierter. Hier muss etwas mehr T-SQL Code ausgeführt werden, da diese Rolle nicht über das SQL Server Management Studio gefunden werden kann, da es sich um einen verwaisten Benutzer handelt. Eine gute Erklärung und Lösung hierfür wurde von Pinal Dave zur Verfügung gestellt, die wie folgt lautet:

USE [msdb]
GO
CREATE ROLE [DatabaseMailUserRole] AUTHORIZATION [dbo]
GO
USE [msdb]
GO
ALTER AUTHORIZATION ON SCHEMA::[DatabaseMailUserRole] TO [DatabaseMailUserRole]
GO

Bei der letzten Korrektur trat der Fehler mit der TargetServersRole erstmals auf. Die SQL Server Engine wurde ohne Trace-Flag neu gestartet und stieß erneut auf eine Fehlersituation, diesmal mit der DatabaseMailUserRole. Dieser Fehler/diese Fehler können also auch nacheinander auftreten. In beiden Fällen konnten die Kunden mit Hilfe der Blogbeiträge schnell bereinigt werden, und der SQL Server lief schnell wieder.

Vielen Dank an Tim Wappat für das Lösen und Bereinigen der TargetServersRole https://timwappat.info/post/2019/02/15/SQLUpgradeFailMsdb110_upgradesql (lässt sich leider nicht so schön einbetten 🙁 )

Dank an Pinal Dave für das Lösen und Bereinigen der DatabaseMailUserRole