Manchmal treffen gewisse Themen zeitnah zusammen, in diesem Fall waren es mehrere Mails aus der Data-Platform-MVP-Distributionlist, mehreren Kunden-Meldungen und dazu noch passsende Beiträge in anderen Blogs, daher möchte ich dazu einen deutschen Beitrag leisten. 😉
Es geht um einen Fehler der anscheinend schon seit mehreren Jahren in allen SQL Server Versionen und Editionen in unterschiedlichen Konstellationen auftritt, die meisten DBAs werden sehr wahrscheinlich nie mit diesem Problem zusammentreffen, wahrscheinlich auch nie vorher an dieses Problem denken. Falls doch, kommt hier eine Erläuterung…
Wann tritt der Fehler auf? – Ausgangslage
Wer kennt es nicht? Man stößt das Rollout von Patchen auf seine Windows Server (inkl SQL Server Cumulative Updates) an und wartet auf die Fertigmeldung…. nach einiger Zeit meldet sich die WSUS Konsole und meldet alle Patches als “erfolgreich” ausgerollt… man meldet an die beteiligten Abteilungen, dass man den Rollout-Vorgang erfolgriech abgeschlossen hat… dann kommt aber die Fertigung und meldet, dass die Produktion nicht wieder anläuft…
Oder ein Kunde meldet sich mit den Worten:
Übrigens spielen wir gerade ein Backup ein, weil nach dem Windows Update (inkl. SQL Server Updates) der Service für den Server (und ein paar andere Services) nicht mehr startet…
Jetzt geht die Fehlersuche los und irgendwann stellt man fest, dass der SQL Server zwar das Patch erhalten hat, danach auch sauber gebootet hat aber der SQL Server Datenbank-Dienst nicht wieder sauber gestartet wurde… noch weiter in das Trouble-Shooting einsteigen und dann im Errorlog des SQL Servers entsprechende Meldungen finden:
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.
Es sollte allen DBAs bekannt sein, dass der SQL Server im Rahmen eines Patches auch Änderungen an den Datenbank-Strukturen der System-Datenbanken durchführt, diese Änderungen werden in der Regel mithilfe von T-SQL-Statements über ein SQL-File mitgeführt. Diese Skripte sollten eigentlich in der Regel auf ALLEN (!) SQL-Servern bei allen Kunden in allen Ausprägungen funktioneren, genau hier ist das Problem… es wird immer ein (oder zwei) Systeme gehen, die vom “Standard” abweichen… sei es “per accident” oder aufgrund einer administrativen Anpassung.
Bezogen auf “TargetServersRole” – hier reicht es den SQL Dienst mit dem Traceflag 902 manuell zu starten und das Schema in der “msdb => Security => Schema” zu löschen.
Bei “DatabaseMailUserRole” wird es etwas schwieriger, hier muss ein wenig mehr T-SQL Code ausgeführt werden, denn über das SQL Server Management Studio findet man diese Rolle nicht, da es sich hier um einen Oprhaned User handelt. Pinal Dave hat hierzu eine gute Erläuterung mit Lösung geschrieben:
USE [msdb]
GO
CREATE ROLE [DatabaseMailUserRole] AUTHORIZATION [dbo]
GO
USE [msdb]
GO
ALTER AUTHORIZATION ON SCHEMA::[DatabaseMailUserRole] TO [DatabaseMailUserRole]
GO
Bei meiner letzten Korrektur trat erst der Fehler mit der TargetServersRole als erstes auf, dann die SQL Server Engine ohne Traceflag neu gestartet und wieder in eine Fehlersituation gelaufen, diesmal mit der DatabaseMailUserRole, also dieser Fehler/diese Fehler können auch hintereinander auftreten. Meine Kunden konnte ich in beiden Situationen mit der Hilfe der Blogbeiträge doch recht schnell wieder bereinigen und innerhalb kürzester Zeit den SQL Server wieder lauffähig zur Verfügung stellen.
Danke an Tim Wappat für die Lösung und die Bereinigung der TargetServersRole
https://timwappat.info/post/2019/02/15/SQLUpgradeFailMsdb110_upgradesql (lässt sich leider nicht so schön einbetten 🙁 )
Danke an Pinal Dave für die Lösung und die Bereinigung der DatabaseMailUserRole
Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.