MSSQL: Datensicherung Meldung 3023
Hi,
einige Kunden von uns setzen auf Grund ihrer Firmengröße den MS SQL 2014 Express ein, der ja bekanntlich keinen SQL-Agent beinhaltet. Zur Datensicherung lasse ich dann täglich über die sqlcmd.exe eine Sicherung in ein Verzeichnis laufen, was eigentlich auch bei allen super Funktioniert, bis auf bei einem Kunden.
Als erstes der Aufruf des Backupskripts:
Dieses Skript wird über die Aufgabenplanung von einer BATCH-Datei mit folgendem Aufruf gestartet:
Das Skript funktioniert bisher problemlos bei den kleineren Kunden und wenn der SQL-Server bei diesem Problemkunden frisch gestartet wurde ebenfalls, aber schon am nächsten Tag bleibt der Aufruf erfolglos. Wenn ich das Skript dann manuell ausführe erhalten ich nach einem manuellen Abbruch die Meldung:
"Meldung 3023, Ebene 16, Status 2, Zeile 2
Sicherungs- und Dateibearbeitungsvorgänge (wie ALTER DATABASE ADD FILE) und Verschlüsselungsänderungen in einer Datenbank müssen serialisiert werden. Wiederholen Sie die Anweisung nach Abschluss des aktuellen Sicherungs- oder Dateibearbeitungsvorgangs."
Microsoft sagt dazu -> https://support.microsoft.com/de-de/kb/2979636
Sprich die letzte Sicherung hängt, obwohl ich im TaskManager keinerlei Prozess dazu habe. Aktuell bin ich ziemlich ratlos wieso bei diesem einen Kunden die Datensicherung sich nicht beendet und sollte ich keine Lösung finden muss ich der Kunde wohl in den sauren Apfel beißen und sich die teure Variante mit SQL-Agent zulegen (was grundsätzlich eh meine Meinung ist, wenn jemand seine Geschäftsdaten einer kostenlosen Variante anvertraut, aber das soll hier nicht das Thema sein).
Hat jemand eine Idee wieso der BackupJob hängen bleibt?
Gruß,
Lars
einige Kunden von uns setzen auf Grund ihrer Firmengröße den MS SQL 2014 Express ein, der ja bekanntlich keinen SQL-Agent beinhaltet. Zur Datensicherung lasse ich dann täglich über die sqlcmd.exe eine Sicherung in ein Verzeichnis laufen, was eigentlich auch bei allen super Funktioniert, bis auf bei einem Kunden.
Als erstes der Aufruf des Backupskripts:
BACKUP DATABASE [db_kunde] TO DISK = N'D:\MSSQL\Backup\db_kunde.bak' WITH NOFORMAT, INIT, NAME = N'Datenbank Sichern', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
Dieses Skript wird über die Aufgabenplanung von einer BATCH-Datei mit folgendem Aufruf gestartet:
@echo off
rem *** Das Skript erstellt eine Sicherung, komprimiert diese in einen entsprechenden Wochentag
rem ***
rem ***
rem *** ACHTUNG: Es muss das Prgramm 7-Zip installiert sein - Pfad der 7z.exe eintragen
rem *** Beispiel: SET ZIPEXE="C:\Program Files\7-zip\7z.exe"
SET ZIPEXE=<Pfad zur Installation von 7zip.exe>
rem *** Pfad SQL Express DB-Server eintragen und Pfad des SQL-Skripts eintragen
rem *** Beispiel: SET BACKUPPFAD=D:\MSSQL\Backup\
SET BACKUPPFAD=<Pfad inkl. \ zum Sicherungsverzeichnis>
rem *** Pfad für das SQL-Skript der Datensicherung eintragen
rem *** Beispiel: SET SQLSKRIPT=D:\DBTools\SQLBackup.sql
SET SQLSKRIPT=<Pfad + Daten zum SQL Backup Skript>
rem *** Datebankservername eintragen
rem *** Beispiel: SET SQLSRV=SQLEXPRESS
SET SQLSRV=<SQL Server Instanz>
rem *** Start der Datenbanksicherung
sqlcmd -E -S %SQLSRV% -i %SQLSKRIPT%
rem *** Ermitteln des Wochentags
FOR /F "tokens=1,2,3 delims=." %%a in ('echo %date%') do set yy=%%c & set mm=%%b & set dd=%%a
set /a "TwoDigitYearMax=2038%%1000"
if 1%yy% LSS 200 if 1%yy% LSS 1%TwoDigitYearMax% (set yy=20%yy%) else (set yy=19%yy%)
set /a dd=100%dd%%%100,mm=100%mm%%%100
set /a z=14-mm,z/=12,y=yy+4800-z,m=mm+12*z-3,dow=153*m+2
set /a dow=dow/5+dd+y*365+y/4-y/100+y/400-2472630,dow%%=7,dow+=1
If %dow% equ 1 set "WoTa=Montag"
If %dow% equ 2 set "WoTa=Dienstag"
If %dow% equ 3 set "WoTa=Mittwoch"
If %dow% equ 4 set "WoTa=Donnerstag"
If %dow% equ 5 set "WoTa=Freitag"
If %dow% equ 6 set "WoTa=Samstag"
If %dow% equ 7 set "WoTa=Sonntag"
rem *** Sicherungsdatei kompremieren mit 7-ZIP nach EXTERN
IF NOT EXIST %BACKUPPFAD%%WoTa% mkdir %BACKUPPFAD%%WoTa%
%ZIPEXE% a -y %BACKUPPFAD%%WoTa%\db_kunde.zip %BACKUPPFAD%db_kunde.bak
Das Skript funktioniert bisher problemlos bei den kleineren Kunden und wenn der SQL-Server bei diesem Problemkunden frisch gestartet wurde ebenfalls, aber schon am nächsten Tag bleibt der Aufruf erfolglos. Wenn ich das Skript dann manuell ausführe erhalten ich nach einem manuellen Abbruch die Meldung:
"Meldung 3023, Ebene 16, Status 2, Zeile 2
Sicherungs- und Dateibearbeitungsvorgänge (wie ALTER DATABASE ADD FILE) und Verschlüsselungsänderungen in einer Datenbank müssen serialisiert werden. Wiederholen Sie die Anweisung nach Abschluss des aktuellen Sicherungs- oder Dateibearbeitungsvorgangs."
Microsoft sagt dazu -> https://support.microsoft.com/de-de/kb/2979636
Sprich die letzte Sicherung hängt, obwohl ich im TaskManager keinerlei Prozess dazu habe. Aktuell bin ich ziemlich ratlos wieso bei diesem einen Kunden die Datensicherung sich nicht beendet und sollte ich keine Lösung finden muss ich der Kunde wohl in den sauren Apfel beißen und sich die teure Variante mit SQL-Agent zulegen (was grundsätzlich eh meine Meinung ist, wenn jemand seine Geschäftsdaten einer kostenlosen Variante anvertraut, aber das soll hier nicht das Thema sein).
Hat jemand eine Idee wieso der BackupJob hängen bleibt?
Gruß,
Lars
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 300843
Url: https://administrator.de/contentid/300843
Ausgedruckt am: 24.11.2024 um 08:11 Uhr
3 Kommentare
Neuester Kommentar
Wie wäre es, wenn man die Ausgabe von sqlcmd in Zeile 24 nicht einfach im Nirvane verschwinden lässt, sondern in eine Logdatei umleitet?
Dann könnte man schauen, ob es beim Backup ungewöhnliche Meldungen gibt.
Und was sagt die im MS Artikel angepsrochene Abfrage? Ist die erste Sicherung fertiggeworden?
Möglicherweise ist auch die lokale Datei im Zugriff von irgendjemand. Könnte man mit dem Sysinternals Process Explorer rauskriegen oder beim zweiten Versuch mal eine andere Datei angeben.
Dann könnte man schauen, ob es beim Backup ungewöhnliche Meldungen gibt.
Und was sagt die im MS Artikel angepsrochene Abfrage? Ist die erste Sicherung fertiggeworden?
Möglicherweise ist auch die lokale Datei im Zugriff von irgendjemand. Könnte man mit dem Sysinternals Process Explorer rauskriegen oder beim zweiten Versuch mal eine andere Datei angeben.
Hallo Lars,
daß die letzte Sicherung nicht durchgelaufen ist, ist erstmal nur eine Vermutung von Dir. Ob das stimmt, solltest Du prüfen. Das kannst Du feststellen im SQL-Server-Protokoll, da steht drin, ob die Sicherung erfolgreich war oder ein Fehler aufgetreten ist. Wenn nichts dergleichen darin zu finden ist, könnte das Backup wirklich noch laufen. Im Windows-Ereignisprotokoll wird der Erfolg oder Mißerfolg der Sicherung normalerweise auch verewigt.
Du könntest auch prüfen, ob Du die Sicherungsdatei verschieben kannst oder auch probieren, sie in die DB zurückzuspielen.
Wenn wirklich die erste Sicherung schon schiefläuft, dann solltest Du vielleicht mal die schon manuell ausführen und schauen, was passiert.
Ansonsten kannst Du auch mal im Aktivitätsmonitor nachschauen, was gerade für Prozesse aktiv sind. Im Falle einer hängenden Sicherung solltest Du die da drin finden. Falls die es nicht ist, erfährst Du aber vielleicht, welcher Prozess Deine Sicherung sonst noch sabotieren könnte.
Als mögliche Ursachen für fehlerhafte Sicherungen könnte ich mir vorstellen, daß eine andere SQL-Server-Version (SP?) als bei anderen Kunden installiert ist oder ein Rechteproblem besteht.
Gruß, Mad Max
daß die letzte Sicherung nicht durchgelaufen ist, ist erstmal nur eine Vermutung von Dir. Ob das stimmt, solltest Du prüfen. Das kannst Du feststellen im SQL-Server-Protokoll, da steht drin, ob die Sicherung erfolgreich war oder ein Fehler aufgetreten ist. Wenn nichts dergleichen darin zu finden ist, könnte das Backup wirklich noch laufen. Im Windows-Ereignisprotokoll wird der Erfolg oder Mißerfolg der Sicherung normalerweise auch verewigt.
Du könntest auch prüfen, ob Du die Sicherungsdatei verschieben kannst oder auch probieren, sie in die DB zurückzuspielen.
Wenn wirklich die erste Sicherung schon schiefläuft, dann solltest Du vielleicht mal die schon manuell ausführen und schauen, was passiert.
Ansonsten kannst Du auch mal im Aktivitätsmonitor nachschauen, was gerade für Prozesse aktiv sind. Im Falle einer hängenden Sicherung solltest Du die da drin finden. Falls die es nicht ist, erfährst Du aber vielleicht, welcher Prozess Deine Sicherung sonst noch sabotieren könnte.
Als mögliche Ursachen für fehlerhafte Sicherungen könnte ich mir vorstellen, daß eine andere SQL-Server-Version (SP?) als bei anderen Kunden installiert ist oder ein Rechteproblem besteht.
Gruß, Mad Max