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 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.
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