09.02.2018, aktualisiert um 08:57:37 Uhr

1627

Aussetzer bei SQL-Backup diagnostizieren

Moin Kollegen.

Ein SQL2016 hier macht täglich Backups. Etwa einmal alle 2 Monate (also ca. einmal von 60) unterbleibt das ohne offensichtlichen Grund (am nächsten Tag geht es dann wieder).
Das Backupziel (UNC-Pfad) ist zur Backupzeit verfügbar, das wurde schon geprüft.

Es gibt im Logging keinerlei für mich ersichtliche Hinweise auf die Ursache - es ist lediglich zu sehen, dass der Rechner es nicht einmal versucht hat (kein Eintrag, weder im Logfile des Maintenance Plans, noch im Log des SQL Server Agents). Dienste sind zu der Zeit keine abgestürzt, kein Hinweis.
Der SQL Agent hatte schon immer den Auftrag, ins Application Eventlog zu schreiben, wenn der Job fehlschlägt - er tut es aber nicht. Alles deutet darauf hin, das der Schedule schlicht nicht befolgt wird.

Kennt jemand solche Aussetzer oder hat eine Idee, wie man mehr Diagnoseinfos bekommt?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 364275

Url: https://administrator.de/forum/aussetzer-bei-sql-backup-diagnostizieren-364275.html

Ausgedruckt am: 16.04.2025 um 22:04 Uhr

29 Kommentare

Neuester Kommentar

Hallo.

Du meinst das Online-Backup im *.bak-Format?

Wenn das Backup-Ziel ein UNC-Pfad ist, braucht es dazu besondere Rechte, weder SA noch ein Windows--authentifizierter SQL-User können per SQL-Backup-Wartungsplan in ein UNC-Ziel schreiben. Wenn ich mich recht erinnere, muß hier mit Systemrechten bzw. Rechten des Systemkontos geschrieben werden.

Nun gehe ich davon aus, daß Du das schon bedacht und erledigt hast, sonst würde es ja nicht 59 von 60 mal funktionieren. Ich würde an dem einen Tag / der einen Nacht, wo das jeweils nicht funktioniert, mal nachsehen, was mit dem Konto los ist, welches den Backup-Job losläßt.

Viele Grüße

von

departure69

Hallo,
ich nehme mal an über die Aufgabenplanung.
Wie ist den der Trigger genau eingestellt?

Hi.

Was soll denn mit dem Konto los sein? Hast Du schonmal erlebt, das sich ein lokales Dienstekonto sperrt? Das geht nicht einmal.

@Tektronix
Das Backup macht der SQL-Server selbst - der hat den SQL-Serveragent, welcher Schedules regelt. Kennst Du das gar nicht?

Moin,

hast Du den bestehenden Job schon mal gelöscht und neu angelegt (sofern das eine Option ist)?
Fährst Du nur tägliche Vollbackups oder auch inkrementelle zwischendurch?

Gruß

Looser

Sag mal, wozu sollte ich das bitte machen? Er setzt nur alle Jubeljahre aus - da ist nichts am Job selbst defekt.

Scheinbar funktioniert das Logging aber nicht so, wie Du es willst. Vielleicht hat sich über ein Update eine Einstellung verändert, die nicht offensichtlich ist. Daher der Gedanke, den Job neu anzulegen und ggf. um inkrementelle Backups zu erweitern. Ist nur eine Vermutung, aber hast Du mal die Backups gezählt, die zwischen den Fehlern liegen?

Scheinbar funktioniert das Logging aber nicht so, wie Du es willst.

Der Task regelt nicht das Logging.

hast Du mal die Backups gezählt, die zwischen den Fehlern liegen?

Ja, wie gesagt, etwa 1 von 60 schlägt fehl (nur eine Schätzung - die Backups laufen ja erst seit Oktober [2 Fehlschläge])

Mir geht es nur darum, ob jemand weiß, wie man den beteiligten Komponenten etwas näher auf den Zahn fühlen kann. Wenn nicht, dann nicht, es ist ja kein Drama, wenn mal alle 60 Tage ein Backup fehlt.

Hallo,

ich bin jetzt nicht so der SQL Spezialist, aber gibt es nicht die Möglichkeit bei einem Job / Trigger das (erweiterte) Debugging zu aktivieren?
Gegebenenfalls mit einem Write Statement jeden Step in eine simple Textdatei schreiben?

Nur so ins Blaue geschossen, vielleicht hilft Dir dies weiter.

Gruss Penny

Ansonsten könnte man noch nen Syslog-Server bauen und reinhängen, aber das ist aufwändig nachher den Fehler zu finden, wenn alles geloggt wird.

Der Task läuft nicht an - da nützt auch kein SQL-Logging. Der SQL-Agent scheint schlicht alle Jubeljahre mal zu spinnen. Wie man dem näher kommen kann, weiß ich nicht.

Zitat von @DerWoWusste:

Der Task läuft nicht an - da nützt auch kein SQL-Logging. Der SQL-Agent scheint schlicht alle Jubeljahre mal zu spinnen. Wie man dem näher kommen kann, weiß ich nicht.

Was sagt den Microsoft dazu? kennst Du in Deinem Umfeld einen SQL Spezialisten evtl. Freelancer?

Das kann doch nicht sein, das ein Backupjob alle zwei Monate mal ausfällt.

Gruss Penny

Das kann doch nicht sein, das ein Backupjob alle zwei Monate mal ausfällt.

Doch, das kann schon passieren, wenn die DB einen Fehler hat. Bei uns läuft aber täglich ein Wartungsjob über die DB, so dass das nächste Backup dann wieder automatisch funktioniert.

Doch, das kann schon passieren, wenn die DB einen Fehler hat

? Das Backup läuft nicht an. Das hat mit der Datenbank herzlich wenig zu tun.

Eventuell liegt die Ursache im Zusammenhang mit anderen Ressourcen.

Beispiel: Die Maschine wird ab und an über einen VSS-Snapshot gesichert. Die Zeiten überschneiden sich.
Oder ein anderer Job des Agents verhindert die Ausführung des Backup Jobs.

Ich würde hier ansetzen, um zeitliche Überschneidungen ausschließen zu können (oder den Job auf eine andere Uhrzeit terminieren sofern möglich) .

Gruß
Grinskeks

@Grinskeks
Hi. Diese Idee finde ich sehr gut, leider trifft sie nicht zu. Selbst wenn, würde der Backupmechanismus vom Scheduler zumindest gestartet - nicht einmal das passiert.

Nochmal: es ist der SQL-Server-Agent, wo man graben muss, leider habe ich keine Idee, wie. Dessen Dienst läuft fehlerfrei.

Moin,

Wenn der Task von der Uhrzeit abhängt (wovon man ja ausgehen mag), wäre es vllt. denkbar,, dass der Server sich via ntp oder sonstwas eine aktuelle Zeit geholt hat, die Zeit angeglichen hat und so die Zeit, an dem der Job hatte starten müssen, "verpasst" hat?

Beispiel
Um 23:59:59.8888 holt sich das System eine neue Zeit, stellt fest, dass es ein Delta von 0,5 Sekunden den gibt und passt die Zeit dann auf 00:00:00.3888 an. Um 00:00:00.0000 hätte aber der Job starten sollen....

Ich muss gestehen, ich weiss nicht, ob der SQL/ Windows so penibel ist, wundern würde es mich aber nicht...

Gruß
em-pie

edit: Typo

Ha!

Das ist ja mal eine Theorie

Nee, die Logs zeigen keine Zeitanpassungsaktivitäten zu dieser Zeit.

Hi.
nee, kannte ich nicht, da wir immer nur Express haben. Habe ihn mir jetzt aber mal als Eval installiert.
Da sind die Trigger etwas anderst aufgebaut.
Nice WE

Zwei weitere Möglichkeiten:

1. Der Service Account für den Agent st aus irgendwelchen Gründen zum jeweiligen Zeitpunkt gelockt (Eventviewer - Security) und verliert den Boden unter den Füßen ohne sich dessen bewusst zu sein - klar wird dann auch nichts geloggt..

2. Benötigt ein Job länger, werden Wiederholungen erst ausgeführt, nachdem der Job beendet wurde. Ich würde prüfen, ob zum besagten Zeitraum eine ungewöhnliche Lange Dauer anliegt, die ein erneutes Starten des Jobs aussetzt.

1
2
3
4
5
6
7
8
9
10
11
select 
  j.name as 'JobName',   
  run_date, 
  run_time, 
  msdb.dbo.agent_datetime(run_date, run_time) as 'RunDateTime',   
  run_duration 
From msdb.dbo.sysjobs j 
INNER JOIN msdb.dbo.sysjobhistory h 
  ON j.job_id = h.job_id 
where j.enabled = 1  --Only Enabled Jobs 
order by JobName, RunDateTime desc 

Guten Morgen,

welche Backup-Software ist das denn?
Hast du die genauen Ausfalltage, immer der Monatsletzte oder so?
Ist es regelmäßig oder eher ungefähr alle 2 Monate?
Wie hoch ist das Zeitfenster des Backup-Agenten?

Ich denke da so an sichere am 31., aber es gibt nur 30 Tage.

Das es nichts offensichtliches ist, müssen wir im die Ecke denken

VG,
Deepsys

Moin.

Zuerst mal: Du bist nicht allein.

Ich hatte hier ein ähnliches Phänomen, allerdings zeitlich "flexibler", also absolut ohne erkennbares Muster sind Backup-Jobs ausgelassen worden (und die zeigten nicht mal auf UNC-Pfade, sondern auf ein lokales Laufwerk (wobei "lokal" hier ne gemountete ISCSI-LUN meint)). Und da lief mehr als nur ein Backup, daher auch größerer "Schwund".

Backup-Laufwerk war dabei unter Server 2016 mit ReFS formatiert. ReFS hat leider noch immer so seine Schwachstellen, ich hatte z.B. noch immer einen teils sehr hohen Speicherverbrauch, s. auch hier (das hat teilweise geholfen):
https://support.microsoft.com/en-us/help/4016173/fix-heavy-memory-usage- ...

Und der SQL-Agent startet u.U. keine Jobs, wenn der RAM ausgeschöpft ist - wie sich da die Zusammenhänge genau verhalten, konnte ich bisher aber auch nicht wirklich rausfinden. Letztlich hat ein Umzug des Backup-Pfads auf ein NTFS-formatiertes Ziel die Probleme gelöst. Ggf.war hier aber auch die ReFS-Logik selbst Teil des Problems.

Cheers,
jsysde

Moin,

mal eine Nachfrage:
Wenn der Job nicht lief, funktioniert er dann am nächsten Tag ohne das Du etwas unternommen hast oder startest Du ggfs. den Server oder Agent jeweils neu?

Gruss

@Grinskeks

1. Der Service Account für den Agent st aus irgendwelchen Gründen zum jeweiligen Zeitpunkt gelockt (Eventviewer - Security) und verliert den Boden unter den Füßen ohne sich dessen bewusst zu sein - klar wird dann auch nichts geloggt..

Ein Serviceaccount kann nicht gesperrt werden und nein, das passiert auch nicht.
2
Der Job dauert 90 Sekunden, an jedem Tag gleich, auch vor den Aussetzern.

@Deepsys
Wie beschrieben: es ist das SQL-eigene Backup, welches Du über das SQL-Managementstudio konfigurieren kannst und welches vom SQL-Agent ausgeführt wird. Es ist nicht regelmäßig, sondern im Zeitraum Oktober bis heute 2x aufgetreten, regellos. Zeitfenster sind 90 Sekunden.

@sabines
Moin. Ich muss nichts unternehmen, es läuft am nächsten Tag wieder.

Meine Frage sollte ganz simpel sein, ob jemand weiß, wo man hier noch Loggingmöglichkeiten hat, die das Backup betreffen, die nicht offensichtlich sind. Wenn es keine weiteren gibt, werde ich die Frage schließen - so wichtig ist es nun auch nicht.

Zitat von @DerWoWusste:

Meine Frage sollte ganz simpel sein, ob jemand weiß, wo man hier noch Loggingmöglichkeiten hat, die das Backup betreffen, die nicht offensichtlich sind. Wenn es keine weiteren gibt, werde ich die Frage schließen - so wichtig ist es nun auch nicht.

Hi

Ein Problem wie du hatte ich noch nicht allerdings viele andere mit nicht so gut gemachten selbstprogramierten Programmen.
Das Logging im SQL musst du erstmal Aktivieren ein Programierer sagte mir das braucht einiges an Ressorcen also aufpassen auf Festplattengrösse usw.

Du kannst es in Managenat studio aktivieren je nach SQL Server Version ! Der punkt heisst SQL Server Profiler.
Du verbindest dich mit der Datenbank und musst dann eine Ereignisauswahl treffen was geloggt werden soll.
Mit dem Spaltenfilter kannst du zb. Aktionen von einem Speziellen Benutzer loggen.
Wenn du das eingestellt hast was du willst musst du noch das Profil starten und schon wird mitgeloggt.

Profi bin ich aber auch keiner im SQL logging also am besten Googeln vieleicht findest du was.

Ich hoffe ich konnte ein bisschen helfen.

LG Andy