SQL Server Patch – Server startet nicht mehr
This post might contain affiliate links. We may earn a commission if you click and make a purchase. Your support is appreciated!
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
This post might contain affiliate links. We may earn a commission if you click and make a purchase. Your support is appreciated!
Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.
Amazon.com Empfehlungen
Damit ich auch meine Kosten für den Blog ein wenig senken kann, verwende ich auf diese Seite das Amazon.com Affiliate Programm, so bekomme ich - falls ihr ein Produkt über meinen Link kauft, eine kleine Provision (ohne zusätzliche Kosten für euch!).
Auto Amazon Links: Keine Produkte gefunden.
Moin,
das Spannende an der Stelle ist jedoch, warum der Fehler überhaupt auftritt.
Guckt man sich das msdb110_upgrade.sql Skript an und sucht nach der Stelle, wo diese Rolle überhaupt angelegt wird, so gibt es nur diesen Codeblock:
————————————————————–
— SQL Agent roles and procs
————————————————————–
PRINT “
PRINT ‚Setting object permissions…‘
go
— Create the TargetServers role (for use by target servers when downloading jobs / uploading status)
IF (EXISTS (SELECT *
FROM msdb.dbo.sysusers
WHERE (name = N’TargetServersRole‘)
AND (issqlrole = 1)))
BEGIN
— If there are no members in the role, then drop and re-create it
IF ((SELECT COUNT(*)
FROM msdb.dbo.sysusers su,
msdb.dbo.sysmembers sm
WHERE (su.uid = sm.groupuid)
AND (su.name = N’TargetServersRole‘)
AND (su.issqlrole = 1)) = 0)
BEGIN
EXECUTE msdb.dbo.sp_droprole @rolename = N’TargetServersRole‘
EXECUTE msdb.dbo.sp_addrole @rolename = N’TargetServersRole‘
END
END
ELSE
EXECUTE msdb.dbo.sp_addrole @rolename = N’TargetServersRole‘
Warum es dann dennoch zu diesem Fehler kommt und man dann und wann manuell eingreifen muss, ist mir noch nicht so ganz klar geworden.
Aber zumindest ist es offiziell dokumentiert:
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/install/windows/sqlserver-patching-issues#targetserversrole-schema-and-security-role
Viele Grüße,
Dirk