Rechnungswesen irw Datenbank doppelt?

[#1]

Hallo,

gleich eine Frage an alle oder den absoluten Fachmann hier @metalposaunist . Kann es sein, dass beim Update der Dump der IRW SQL nicht aufgelöst wurde oder hat jemand eine andere Idee warum die DB jetzt doppelt Speicher braucht?

[#2]

Da bin ich auch überfragt; auch als Allwissender 😜. Bei uns liegt nur eine MDF und LDF Datei vor. Bin beim Googlen aber auf DBCC (Transact-SQL) gestoßen. Komisch ist, dass die eigentlich in Gebrauch befindliche IRW.MDF vom 01.01.21 ist und die DBCC von heute 🤔. Zumal die LDF, in der wichtige Dinge für die MDF stehen, auch vom 01.01.21 ist, welche auf meinem Server gleich dem Datum der MDF ist und auch so sein sollte. 

Was sagt denn der DATEV SQL-Manager dazu? Tauchen da auch zwei Datenbanken auf?

Sieht für mich als SQL-Laie so aus, als ob die IRW.MDF aktuell nicht genutzt wird (aus welchen Gründen auch immer) und man aktuell mit der DBCC MDF arbeitet, weil die IRW.MDF vielleicht bei der DVD 14.1 nicht angepasst werden konnte?! Und es zur DBCC MDF keine passende LDF gibt und es bei einer Datenbankwiederherstellung "interessant" werden könnte. 

Noch was zum Nachlesen: What is .mdf_MSSQL_DBCC15 file

---

If the operating system encounters an unexpected shutdown while the DBCC CHECKDB command is in progress, then these files will not be cleaned up. They will accumulate space, and potentially will prevent future DBCC CHECKDB executions from completing correctly. In that case, you can delete these new files after you confirm that there is no DBCC CHECKDB command currently being executed.

---

So hatte ich mir das auch schon ähnlich gedacht. Was sagt die Datenbankprüfung der DATEV? Wie wird gesichert? Was sagt die letzte Sicherung? Ist der Server tatsächlich mal abgestürzt? 

Auf alle Fälle müssen alle geänderten Daten aus der DBCC MDF zurück in die IRW.MDF Datenbank geschrieben, damit die DBCC MDF entfallen kann. Ähnlich, wie es bei VMware und HyperV auch mit einem Snapshot gemacht wird. So würde ich's Stand jetzt lesen / einschätzen. Wie man das ohne Datenverlust mit DATEV SQL 2017 erreicht: keine Ahnung. Wäre mir aber auch zu heikel und ich würde da einen SK absetzen und immer schauen, dass täglich eine Sicherung des Servers zu 100% abgeschlossen wird. 

Da muss DATEV ran, wenn hier sonst niemand einen Tipp hat. 

[#3]

Das Problem dürfte erheblich tiefer gehen.

Nach Aussagen von MS soll diese Datei nur nach einem Herunterfahren der Maschine während der Ausführung des DBCC CHECKDB Befehls im Dateisystem verbleiben. Die 2. Variante schließe ich einmal aus da dazu ReFS und SQL Server <2014 im Spiel sein müssen, DATEV nutzt aber seit geraumer Zeit MS SQL >= 2014 und ReFS ist nun auch noch nicht so weit verbreitet.

Das die IRW.mdf und IRW.ldf im Explorer das Datum 1.01.2021 haben bedeutet schlicht, dass diese Dateien am 1.01.2021 vom SQL Server geööfnet wurden und seitdem mit dem SQL Server verbunden sind. Dieser hat die volle Kontrolle und wird die Datumsangaben erst in der Dateisystemdatenbank bei beenden des Dienstes aktualisieren. Im Umkehrschluss bedeutet dies aber, dass der DATEV SQL Dienst ununterbrochen läuft und ein Stoppen des Servers nicht stattgefunden hat. Wer hat also auf Ebene des DATEV SQL Dienstes den DBCC CHECKDB Job abgeschossen? Dürfte, wenn überhaupt, entweder nur mit den Rechten des SQL Superusers SA gehen, welche DATEV natürlich und verständlich nicht herausgibt, oder den "normalen" DATEV Rechten (das sind die Dinger mit den täglich wechselnden Passwörtern) klappen.

Der Job sollte aber andererseits auf dem SQL Server im Ereignisprotokoll eingetragen sein, der Eintrag kann schon einmal einen Hinweis auf den Grund geben.

Bei der Datei, die der Job DBCC CHECKDB anlegt handelt es sich um eine Kopie, die als Stream temporär angelegt wird, d. h. die echte IRW.mdf bleibt das Hauptmedium für Veränderungen, Veränderungen während der Laufzeit werden also nicht in der .mdf_MSSQL... angelegt. M. a. W. kein zurückschreiben aus der .mdf_MSSQL... in die IRW.mdf notwendig. Das ist auch logisch da die IRW.ldf ja auch nachgeführt werden müsste.

MS sagt, die überzählige Datei kann gelöscht werden. Ja, aber wie kommt die Datei dahin? Wenn der Check bewusst ausgelöst wurde, könnte die Datei ja gefahrlos gelöscht werden.

Spekulation:

1. Der Backup-Job zur Erstellung der *.bak Datei ist nicht sauber durchgelaufen. Also prüfen ob die Datei vorhanden ist. Die Datensicherung muss auf Basis des DATEV Scripts zur Sicherung im laufenden Betrieb arbeiten, wenn nicht würde ja ohne Datensicherung gearbeitet.
2. Der DATEV Job zur Überprüfung der DATEV Datenbanken ist genau bei der IRW abgestürzt. Das kann im DATEV Protokoll erkannt werden.
3. Es gibt noch den DATEV "Wochenend" Job zur Optimierung der Datenbanken, evtl. ist hier etwas schiefgegangen.

Ohne die Ursache zu kennen hätte ich jetzt Bauchschmerzen und ein Wochenende mit Ursachenforschung. Hoffentlich gibt es eine Datensicherung mit einem Recoveryplan.

[#4]

Hey erstmal vielen Dank für die ausführlichen Antworten!

Ihr macht mir ja schön Angst 🙂 Naja wir haben natürlich Snapshots alle zwei Stunden, von daher glaub ich krieg ich erstmal keine Schnappatmung. Aber ich denke ich werde mich am Montag mal in Nürnberg informieren, was es sein könnte. Ich hatte das Update genau zu dem Zeitpunkt am 1.1. installiert, weil ich bei diesem Sylvester nicht betrunken war 🙂

Ich geb bescheid was die SQL Profis von der DATEV dazu sagen werden!

Danke für die Hilfe schon mal im Voraus!

[#5]

Hallo nochmal!

Jetzt ist sie verschwunden...

Es lief definitiv kein SQL Check in der Zeit! Seit dem Update von dem SQL passieren echt seltsame dinge, lustig nur wenn man eh an Speicher gerade knapp ist und einfach mal so 90 gig draufkriegt, ich geh der Sache nach und kläre es auf auch für euch und die tollen Antworten!

[#6]

Also Kommando zurück. Schande über mein Haupt. 

Es ist wohl tatsächlich so gewesen, dass zu der Zeit eine SQL Prüfung lief (schön, dass man alles noch weis wie man es damals eingerichtet hatte... nochmal Schande...

Zur Verteidigung:

Ok -  Es war spät, ich war sagen wir mal in "administrativer Grundlaune", kurz vom Bett... und naja anscheinend hab ich mich da voll vergaloppiert.

Ich lass gerade zum Testen eine SQL Prüfung laufen und siehe da, da ist die doppelte Datenbank wieder. Aber sie braucht auch keinen Platz obwohl im Explorer so angezeigt.

Vielleicht ist ja der Beitrag trotzdem dafür gut, jemanden in ähnlicher Panik das mal näher zu bringen. Es ist die SQL Prüfung die sich den Platz reserviert und aber nicht belegt. Wenn diese vorbei ist, ist das "echo" wieder weg... 

Mea culpa!