Hallo Datev-Installateure und -Kontrolleure,
heute früh hat mich Outlook mit einer E-Mail mit dem 'unschönen' Betreff
"WARNUNG: Datenbankprüfung fehlerhaft abgeschlossen"
überrascht
Die anschließende nächtliche Offline-Sicherung (Client-Server) hat jedoch funktioniert und die Mitarbeiter können mitarbeiten.
... hier die Anzeige der Ergebnisdatei (sämtliche SQL-Datenbanken haben ein rotes Symbol
Wie sieht Ihr Script zur Steuerung von Prüfung und Sicherung aus? Insbesondere Start und Stop der SQL Dienste.
die Online-Prüfung und -Sicherung findet bei gestartetem SQL-Server statt, im laufenden Betrieb
die Offline-Sicherung stoppt den SQL-Server und startet ihn anschließend wieder, aber das kam erst 2 Stunden später in der Nacht und funktionierte ja
der Befehl zur Online-Prüfung und Sicherung wurde durch den Datev-Assistenten erstellt und steht in den "geplanten Aufgaben" (oder so ähnlich)
... muss ich nachsehen, wie der Befehl aussieht
bis gestern funktionierte die Online-Datenbankprüfung zuverlässig.
Ich selbst habe gestern nichts daran geändert
Vielleicht hilft ja ein neuer Boot des Fileservers (außerhalb der Bürozeit)
Vermutlich ist der SQL Server nach den DATEV Updates nicht wieder in den normalen Arbeitsmodus zurückgekehrt und nicht alle Dienste waren korrekt gestartet. Kommt häufiger vor als man denkt.
Mit dem Stop Script, angestoßen durch die Aufgabenplanung, wurden dann die restlichen Dienste gestoppt, die Datensicherung ausgeführt und mit dem Start Script gestartet. Das Start Script hat dann alle Dienste gestartet. In der Folge konnte dann wieder gearbeitet werden.
nocheinmal danke @einmalnoch ,
ich bin auch dafür, dass das so ist.
Ich werde nach Büroschluss die Online-Prüfung und -Sicherung einfach manuell starten und sehen, was passiert.
... ich hatte mich eigentlich gewundert, dass der Fileserver bei dem jetzigen Update nicht neu booten wollte. Bei den letzten paar Datev-Aktualisierungen war das eine seiner liebsten Aktionen 😄
Wir haben seit der Installation der Updates letzter Woche (17.4.) dasselbe Problem.
Haben bislang noch keine Lösung gefunden (Neustart der Server hat nichts geholfen), aber auch noch nicht intensiv gesucht.
... evtl. hat sich ja im Tool (in der EXE-Datei) zur SQL-Prüfung und -Sicherung 'heimlich' etwas geändert.
Wenn sich der Fehler nicht 'wie von selbst in Luft auflöst', werde ich den Assistenten zur Erstellung der "geplanten Aufgabe" (oder so ähnlich) einfach nochmal ausführen
Hier keine Fehler, alle Prüfungen mit grünen Häkchen versehen.
Was sagt der Installationsmanager? Hängt da noch ein Job? (Extras, erweiterte Einstellungen)
Klemmt ein Dienst? Dienste aufrufen und nachsehen.
Was sagt das Ereignisprotokoll? Sind da Fehler gemeldet?
Hallo in die Runde,
ich würde es mal mit neuen Prüf- und Sicherungsläufen versuchen.
Ich meine mich dunkel daran zu erinnern, dass bei einer der letzten Updates darauf hingewiesen wurde, dass die Steuerungsdateien für die Prüf- und Sicherungsläufe neu angelegt werden müssten.
Vielleicht lässt sich das Problem ja damit umschiffen🙄
@agmü ,
... umschiffen ?
... in einer Kanzlei natürlich am besten mit einer Barkasse 😎
... eigentlich müsste diese Änderung im SQL-Prüf- und Sicherungstool dann im letzen Update passiert sein. Denn bis gestern lag alles (in der Ergebnisdatei) im grünen Bereich
Für mich klingt die Fehlermeldung nach einer Inkompatibilität zwischen Script und ausführbarer Datei. Aber spekulieren hilft nicht. Ich muss mal direkt 'ran an den Speck' (an die Daten und Dateien)
irritiert hatte mich außerdem, dass die Fehlermeldung erst mit einiger Verzögerung nach dem Start des Prüflaufs kam.
... bin aber gerade unterwegs.
... der Fileserver reagiert leider nicht auf Telekinese, Präkognition und Telepathie.
Nachtrag:
Korrektur: es gab doch keine Zeitverzögerung nach dem Start des Tools
Vielleicht hatte ich beim Festlegen des Startzeitpunkts gerade an die Fastnacht oder an den Karneval gedacht 😉
aktueller Stand:
die Online SQL-Prüfung und -Sicherung funktioniert bei manuellem Start immer noch nicht
Laut Aufgabenplanung wird täglich um 1:11 Uhr
das Programm .../DVPCDBMSCheckConsole711.exe
mit dem Argument .../STDMSCHECK_LOCALHOST.xml
gestartet
In der XML-Datei stehen die individuellen Parameter und Pfade meines Fileservers und meines SQL-Servers.
Ich werde am besten mit dem Assistenten den SQL Prüf- und Sicherungslauf nochmal neu planen (anlegen)
Andere Idee:
Evtl. verhindert ja das aktuelles Windows-Update, das gestern ebenfalls installiert wurde, die Ausführung des Tools
Nachtrag:
... eine neue automatische SQL-Online--Prüfung und -Sicherung über die Aufgabenplanung brachte keine Lösung , sondern nur eine Auffrischung meines Gedächtnisses, wie man den Assistenten "Prüf- und Sicherungslauf planen" anwendet.
Ein manueller Start führte zwar zu einer längeren Aktion, aber zu keinem Ergebnis (keine *.bak-Dateien) und zu dem E-Mail-Betreff "WARNUNG: Datenbankprüfung fehlerhaft abgeschlossen"
... erst ein Reboot des File-Servers und ein anschließender manueller Start des Prüf- und Sicherungslaufs erzeugte die erwünschten BAK-Dateien der SQL-Datenbanken.
Heute Abend wird sich zeigen, ob die geplante Aufgabe (automatische SQL-Online--Prüfung und -Sicherung) ab sofort wieder zuverlässig erledigt wird.
... keine Ahnung, welches Sandkorn nach der Datev-Aktualisierung im Getriebe gesteckt hatte.
Hallo vogtsburger,
nach dem Hotfix-Rollout am 15.04. gab es bei einigen Kunden Probleme. Wir sind noch in der Analyse und haben seit
heute Morgen das Hilfedokument Prüf- und Sicherungslauf meldet "Methode nicht gefunden" am Start.
Ich bitte um Geduld, wir bleiben dran.
Mit freundlichen Grüßen aus Nürnberg
Christian Tölle
IT-Systemplattform
DATEV eG
Hallo Herr @Christian_Tölle ,
@Christian_Tölle schrieb:
... nach dem Hotfix-Rollout am 15.04. gab es bei einigen Kunden Probleme ...
dann haben einige oder gar viele 'early bird'-Datev-Installateure schon am 15.04. den 'Wurm' gefangen und haben seither keine Online-Sicherung ? 🤔😗
Nachtrag:
vermutlich geht es um den folgenden Hotfix:
Hotfix B0000457-06010GrundBereitstellungsdatum des Hotfixes: 15.04.2021
Funktionale Erweiterung für die Version 6.0 der SQL Verwaltungskomponente Client. Die Version 6.0 der SQL Verwaltungskomponente Client ist Bestandteil des SQL Server für DATEV (SE) 8.1 und SQL Server für DATEV Express 8.1 (DATEV-Programme 14.1, Januar 2021).
Nähere InformationenNach Installation des Hotfixes wird die Sicherheit bei der Datensicherung erhöht.
Hallo vogtsburger,
hallo Community,
wir haben neue Erkenntnisse: Bei einigen Kunden kam es bei der Installation zu einem Reihenfolgeproblem. Am Ende wurde ein Dienst (DATEV SqlBatch Service) nicht neu gestartet.
Morgen erscheint eine ergänzte Version des Hilfedokuments Prüf- und Sicherungslauf meldet "Methode nicht gefunden" mit Abhilfe. Hier die Kurzform:
services.msc erfassen und OK klicken.
Im Fenster Dienste in der Spalte Name nach DATEV SqlBatch Service suchen.
Im Kontextmenü (rechte Maustaste) des Diensts: Neu starten klicken.
Die Abhilfe kann im laufenden Betrieb durchgeführt werden.
Mit freundlichen Grüßen aus Nürnberg
Christian Tölle
IT-Systemplattform
DATEV eG
Hallo Herr @Christian_Tölle ,
direkt nach dem Reboot des Fileservers hatte ich den Prüf- und Sicherungslauf manuell (und erfolgreich) gestartet.
... kann man davon ausgehen, dass nach jedem Reboot des Fileservers auch die automatische Ausführung dieser "geplanten Aufgabe" funktionieren wird, also ohne vorherigen erstmaligen manuellen Start ?
... mich irritiert nämlich noch der Eintrag "manuell" für diesen Dienst
Hallo vogtsburger,
die geplante Aufgabe wird ebenfalls funktionieren.
Mit freundlichen Grüßen aus Nürnberg
Christian Tölle
IT-Systemplattform
DATEV eG
... ok, dann werde ich heute nach Büroschluss manuell einen Reboot des Fileservers machen und darauf vertrauen, dass die "geplante Aufgabe" automatisch ausgeführt wird 😊
... aber da wir gerade beim Thema "Online-Sicherungen" sind:
bei den BAK-Dateien sammeln sich im Lauf der Zeit Datei-Leichen an, weil sich offenbar einige Datenbank-Bezeichnungen ändern oder wegfallen.
Diese veralteten BAK-Dateien werden durch die automatische Bereinigung während dem "SQL Prüf- und Sicherungslauf" offenbar nicht mehr angefasst und bleiben somit in der Ordnerstruktur der SQL-Onlinesicherungen für die Nachwelt erhalten, bis man sie entdeckt und manuell entfernt.
Ist das so gewollt und muss man einfach gelegentlich in diversen Verzeichnissen nach solchen 'Altlasten' suchen, um sie zu entfernen ?
(es gibt ja auch noch weitere Verzeichnisse im Umfeld des SQL-Servers, in denen sich temporäre Dateien oder LOG-Dateien ansammeln können, die unnötig Speicherplatz verschwenden, z.B. wenn sie in der OFFLINE-Sicherung enthalten sind)
Hallo vogtsburger,
@vogtsburger schrieb:
... mich irritiert nämlich noch der Eintrag "manuell" für diesen Dienst
Der DATEV SqlBatch Service wird nur für die Datenanpassung und für den Prüf- und Sicherungslauf benötigt. Für diese "Tätigkeiten" wird der Dienst angefordert und gestartet, ansonsten hat er nichts zu tun und kann gestoppt sein.
@vogtsburger schrieb:
... ok, dann werde ich heute nach Büroschluss manuell einen Reboot des Fileservers machen und darauf vertrauen, dass die "geplante Aufgabe" automatisch ausgeführt wird 😊
Wie mein Kollege Christian Tölle schrieb, reicht es aus, den DATEV SqlBatch Service neu zu starten. Ein kompletter Reboot des Fileservers ist nicht notwendig.
@vogtsburger schrieb:
... aber da wir gerade beim Thema "Online-Sicherungen" sind:
bei den BAK-Dateien sammeln sich im Lauf der Zeit Datei-Leichen an, weil sich offenbar einige Datenbank-Bezeichnungen ändern oder wegfallen.
Diese veralteten BAK-Dateien werden durch die automatische Bereinigung während dem "SQL Prüf- und Sicherungslauf" offenbar nicht mehr angefasst und bleiben somit in der Ordnerstruktur der SQL-Onlinesicherungen für die Nachwelt erhalten, bis man sie entdeckt und manuell entfernt.
Ist das so gewollt und muss man einfach gelegentlich in diversen Verzeichnissen nach solchen 'Altlasten' suchen, um sie zu entfernen ?
(es gibt ja auch noch weitere Verzeichnisse im Umfeld des SQL-Servers, in denen sich temporäre Dateien oder LOG-Dateien ansammeln können, die unnötig Speicherplatz verschwenden, z.B. wenn sie in der OFFLINE-Sicherung enthalten sind)
Bei den BAK-Dateien handelt es sich um SQL-Onlinesicherungen der Datenbanken. Da können wir nicht einfach "aufräumen", selbst wenn die dazugehörende Anwendung abgekündigt oder in einer anderen Anwendung - und damit die Daten in einer anderen Datenbank - aufgegangen ist.
Das gleiche gilt für das / die Datenverzeichnis(se). Aufräumen wäre schön und wünschenswert, aber wer kann innerhalb der DATEV kundenübergreifend sagen, was noch - oder eben nicht mehr - gebraucht wird?
Für den Dateneigentümer gilt eine Datenvorhaltungspflicht von 10 Jahren (glaube ich). Wenn wir da etwas entfernen würden, gäbe es im Falle des Falles eine unschöne Diskussion.
Mir fällt da z.B. die KR-Datenbank ein. Wurden nicht alle Mandanten in die IRW-Datenbank übernommen und müsste man auf so einen Mandanten zugreifen, wäre dieser weg, wenn die KR-Datenbank gelöscht worden wäre.
Mit sonnigen Grüßen aus Nürnberg
Harald Sommer
IT-Systemplattform
DATEV eG
Danke für die Aufklärung, Herr @Harald_Sommer,
... mir waren bei der Bearbeitung des aktuellen Themas nur ein paar Gigabytes an alten BAK-Dateien über den Weg gelaufen, daher die Frage.
@Harald_Sommer schrieb:
... Wie mein Kollege Christian Tölle schrieb, reicht es aus, den DATEV SqlBatch Service neu zu starten. Ein kompletter Reboot des Fileservers ist nicht notwendig...
... daran hatte ich nicht gezweifelt, aber ich will ausdrücklich nochmal rebooten, um zu sehen, ob der "SQL-Prüf- und Sicherungslauf" nach jedem Reboot freiwillig und automatisch nachts startet, oder ob man diesen Dienst ein Mal manuell starten muss (was wiederum fehleranfällig wäre)
Den Dienst kann man doch auch auf Starttyp "automatisch" stellen, oder ?
Nachtrag:
... habe soeben den Fileserver neu gebootet und bin gespannt, ob das eintritt, was ich (eigentlich) erwarte 😉
aktueller Status der Datev-Dienste:
(überraschender) neuer Status der Datev-Dienste (nach der SQL Online-Prüfung und -Sicherung) :
Fazit:
der Dienst "Datev Sqlbatch Service" wird offenbar automatisch von der "geplanten Aufgabe" mitgestartet und die Online-Prüfung und -Sicherung wird korrekt ausgeführt.
Sehr gut !
Hat auch bei uns geholfen.
Sicherung läuft wieder.
Danke!
Das gleiche gilt für das / die Datenverzeichnis(se). Aufräumen wäre schön und wünschenswert, aber wer kann innerhalb der DATEV kundenübergreifend sagen, was noch - oder eben nicht mehr - gebraucht wird?
Für den Dateneigentümer gilt eine Datenvorhaltungspflicht von 10 Jahren (glaube ich). Wenn wir da etwas entfernen würden, gäbe es im Falle des Falles eine unschöne Diskussion.
Was hilft mir die Datenvorhaltepflicht und der Datenschrott, wenn die dazugehörige abgekündigte Anwendung längst nicht mehr installiert ist?
Konkret. Wenn z.B. das Programm DATEV- Briefkasten weg fällt und die Briefe längst weg sind, dann frage ich mich, wofür der Ordner "DBRIEFE" mit seinen mehr als 1.000 Einzel- Dateien vorgehalten wird.
Was soll der Ordner KR bzw. die 10.000 Unterordnern von RWDAT? Wird da alles benötigt?
DANUS, LV200#, usw. Wer bitte kann den Ballast der längst entsorgten Anwendungen oder Funktionen entsorgen?
Soll man jetzt wirklich durch alle Verzeichnisse gehen und testen, ob sich die Daten, wo die SQL- Daten seit Jahren nicht mehr aktualisiert wurden, zu löschen?
... ich vermute mal, dass die Rekonstruktion von mehrere Jahre alten SQL-Daten, deren zugehörige Anwendungen evtl sogar schon abgekündigt sind, noch nie wirklich getestet wurde.
... keine Ahnung, wie sowas technisch ablaufen könnte
... sogar geklonte Festplatten und komplette Offline-Datensicherungen sind keine Garantie für die Lauffähigkeit der alten Programmversionen und der Daten
klar, alte programmversionen in eine neue datevumgeung installieren (vlt auch winxp), lizenz und datenbanken rein und ab gehts..
gut, für abgekündigte müsste noch die lizenz vorhanden sein.. aber würde schätzen, die lässt datev im „bauch“
... (Fortsetzung des ursprünglichen Themas):
@vogtsburger schrieb:
Fazit:
der Dienst "Datev Sqlbatch Service" wird offenbar automatisch von der "geplanten Aufgabe" mitgestartet und die Online-Prüfung und -Sicherung wird korrekt ausgeführt.
...
... die SQL Online-Prüfung und -Sicherung hatte jetzt einige Tage einwandfrei geklappt, aber ...
... da gestern zur erwarteten Zeit gar keine E-Mail-Benachrichtigung kam, habe ich die "Aufgabenplanung" aus der Entfernung gecheckt, und siehe da, die geplante Aufgabe (der SQL-Prüfung und -Sicherung) wurde nicht ausgeführt
Daraufhin habe ich die "geplante Aufgabe" manuell beendet und manuell neu gestartet --> erfolgreich
Ich vermute, dass die Aufgabe standardmäßig nicht (immer) beendet wird und dann am nächsten Tag mit dem neuen automatischen Start dieser Aufgabe kollidiert.
... also werde ich die maximale Laufzeit dieser Aufgabe so begrenzen, dass die nächste Ausführung nicht verhindert wird.
Nachtrag:
... eine Verständnisfrage:
wer legt die folgende Einstellung "Aufgabe beenden, falls Ausführung länger als :" fest ?
... falls diese Einstellung vom Ersteller der geplanten Aufgabe festgelegt wird, erscheint sie mir als unsinnig
... habe jetzt mal den Wert von 3 Tagen auf 2 Stunden abgeändert
Wenn der SQL-Prüf- und Sicherungslauf nach 2 Stunden nicht beendet ist, dann ist sowieso etwas 'faul' 😄