Verständnisfrage zu MS SQL Server : lässt sich der Speicherbedarf des 'log'-Ordners begrenzen ....

[#1]

Hallo Community,

eine Verständnisfrage zu MS SQL Server :

Lässt sich der Speicherbedarf des 'log'-Ordners (siehe Screenshot) irgendwie begrenzen und/oder verkleinern, damit die Systempartition nicht an dem enormen Speicherbedarf des MS SQL Servers 'erstickt', oder anders gesagt, damit man nicht gezwungen wird, größere Festplatten einzubauen ?

der Log-Ordner hat momentan eine Größe von ca 200 GB, was mir so gar nicht gefällt, da der verfügbare Speicherplatz auf der Systempartition knapp wird.

( Die eigentlichen Daten bzw. die Datev-Datenbanken befinden sich ja auf einer anderen Partition, im Ordner WINDVSW1 )

[#2]

Hi,

Frage: Leert sich der Ordner, wenn der Dienst neugestartet wird?

Grüße

Chr.Ockenfels

[#3]

ich würde mir keine Gedanken über den Speicherplatz der Log Files machen, sondern eher über den Zustand Datenbank oder des SQL Servers.

Eine Möglichkeit wodurch die Dump Files erzeugt werden ist ein Crash des SLQ Servers, dabei wird der Speicherinhalt in ein Dump File geschrieben.

Also eher mal ein Blick ins Ereignisprotokoll werfen um die Dateien zu verhindern.

Einen Fehler behebt man nicht dadurch, dass man die Meldung unterbindet 😉

[#4 · Accepted solution]

Hallo Herr Vogtsburger,

betreiben Sie umgehend Ursachenforschung!

Überprüfen Sie unbedingt zeitnah den Zustand der Datenbanken mittels eines individuellen Prüflaufs (hier Kapitel 3.3)

Kontrollieren Sie, ob Sie einen automatischen Prüf- und Sicherungslauf eingerichtet haben und steuern ggf. nach. Informationen dazu finden Sie in Leitfaden zur Datensicherung.

Mit Grüßen aus Nürnberg

Christian Tölle

Service Systemplattform/Basisdruck

[#5]

Danke für die Feedbacks,

ein automatischer Prüf- und Sicherungslauf (für die Datev-Datenbanken) ist eingerichtet.

Bisher gab es hier keine Auffälligkeiten oder Fehlermeldungen.

Im laufenden Betrieb gab es auch keine Störungen oder 'Abstürze'.

Ich wusste nicht, dass sich im genannten LOG-Ordner auf der Systempartition in letzter Zeit etwas ansammelt und dass das keine 'normalen' Dateien sind (Transaktionsprotokolle oder Ähnliches).

Danke, Herr @Christian_Tölle für die Links zu den InfoDB-Dokumenten.

[#6]

Nachtrag:

... falls sich tatsächlich eine Ursache finden und beheben lässt, werden dann diese Dateien im 'Log'-Ordner automatisch gelöscht oder muss/kann man manuell 'bereinigen' ?

[#7]

Hallo Herr Vogtsburger,

eine automatische Lösung erfolgt nicht. Löschen Sie die Dateien SQLDmpr*.* und SQLDump*.* nach der Fehleranalyse/-behebung manuell. 

Für detaillierte Unterstützung, nehmen Sie bitte Kontakt mit uns auf.

Mit sonnigen Grüßen aus Nürnberg

Christian Tölle

Service Systemplattform/Basisdruck

[#8]

Hier wurde der SQL- Server seit Ewigkeiten nicht angefaßt.

 

[#9]

Warum sollte er auch angefasst werden ?  Das Erstellungsdatum lässt ja keine Rückschlüsse auf 

autom. Sicherung usw. zu. 

Mein Erstellunsdatum ist vom 23.9.2016, autom. Datensicherung läuft immer durch. Daher sind auch im /data- ordner entsprechend aktuelle Dateien. 

[#10]

Hallo Herr Eberhardt vom wunderschönen @bodensee ,

die Info von @martinkolberg war nicht wg. dem Erstellungsdatum interessant, sondern wg. der Größe des Inhalts.

Bei dieser 'schnuckeligen' Mini-Größe von ca 100 MB muss man nichts 'anfassen'. Man könnte ja versehentlich etwas 'zerbrechen' 😁

Aber mein LOG-Ordner ist ein 'Riesenbaby' von ca 200 GB.

Ich muss unbedingt dem Fehler auf die Spur kommen oder kommen lassen.

[#11]

Hallo Herr Tölle ( @Christian_Tölle ),

kurzer 'Ursachenforschungs-Bericht' 😁:

sämtliche Datev-Datenbanken sind technisch ok (laut "Ergebnisdatei der Datenbankprüfung".

Allerdings hat leider die Systemdatenbank msdb ein rotes Symbol und in den Log-Dateien tauchen regelmäßig entsprechende Hinweise auf.

Fragen : 

1. wäre ein Reparaturversuch per "dsqlm" empfehlenswert und ein Versuch wert oder besteht die Gefahr, dass die msdb durch diesen Reparaturversuch 'zerschossen' wird ?
   (wie gesagt, alle Datev-Programme starten. Im laufenden Betrieb im Client-Server-Netz mit 1 Fileserver und z.Zt. 18 Clients gibt es keine Effekte, Fehlermeldungen oder Abstürze).
   
   
2. könnte man vielleicht mit Deinstallation/Installation des Microsoft SQL-Servers (DATEV_DBENGINE) (Vorgehen strikt nach InfoDB-Dokument Nr. 1013342) diesen Fehler in der MSDB besser beheben ?

[#12]

Die Systemdatenbanken lassen sich mit DATEV Mitteln nicht reparieren. Also würde die Deinstallation der DATEV Engine nichts bringen (außer Arbeit natürlich).

Es müsste schon Windows deinstalliert werden, da war aber noch was...😱

Es gibt aber einige Anleitungen im Netz, was zu einer erfolgreichen Reparatur führen kann. Z. B. hier gibt es einen Einstieg in das Thema

https://www.mssqltips.com/sqlservertip/3658/how-to-fix-a-corrupt-msdb-sql-server-database/ 

good luck

[#13]

Hallo Herr Vogtsburger,

haben Sie die Prüfung am Rechner durchgeführt haben, an dem der SQL-Server installiert ist? Wenn ja, dann ist das Ergebnis verlässlich und die Ursachenforschung hat gut geklappt!

Die msdb wird zur Installationszeit des SQL-Servers erstellt und kann nicht mit dem DATEV SQL-Manager repariert werden.

Planen Sie einen Wartungszeitraum, in dem niemand arbeitet und installieren den SQL Server für DATEV neu: Microsoft SQL Server und Microsoft SQL Client-Komponenten deinstallieren und installieren

Gutes Schaffen,

mit Grüßen aus Nürnberg

Christian Tölle

Service Systemplattform/Basisdruck

[#14]

Hallo einmalnoch,

ich habe mir die verlinkte Seite angesehen. Hier ist eine Lösung mittels SQL Management Studio beschrieben. Ich kenne den Lösungsversuch nicht und kann keine Aussage über sein Ergebnis oder die Nebenwirkungen machen.

Danke für den Hinweis und die Bereitschaft zu helfen.

DATEV bietet als Schritt-für-Schritt-Lösung bei defekten SQL-Verwaltungsdatenbanken:

Microsoft SQL Server und Microsoft SQL Client-Komponenten deinstallieren und installieren

Mit nebenwirkungsfreien Grüßen aus Nürnberg

Christian Tölle

Service Systemplattform/Basisdruck

[#15]

Wie sieht ihre Datensicherungsstrategie aus?

In dieser Situaton würde ich ein Bare- Recover auf einem freien PC durchführen um dann zu experimentieren. 

Vorteile:

1. Ein Rücksichern auf neue Hardware sollte jeder Admin ab und an einmal testen.

2. Sie können ohne die Kanzlei lahm zu legen experimentieren und die Reparatur- Strategie testen.
(Der Backup- System darf natürlich keine Daten, wie Emails oder DATEV- Kram aus dem Netz holen)

Mein Bauchgefühl ahnt, daß die Datenbank nicht wirklich defekt ist, denn sonst müßten Sie irgend etwas merken.
Natürlich kenne ich nicht die Fehlemeldungen, aber bei einer defekten Systemdatenbank wird der Server eher seine Arbeit verweigern. 
Möglicherweise ist es ledigleich eine defekte System- Anwendung, die querschießt.
-> Jugend forscht am Backup- Server...

Datum der Datei???
Läßt sich herausfinden, wann noch alles OK war?
Gibt es aus dieser Zeit noch ein System- Backup?

[#16]

@martinkolberg , 

ja, es ist zwar erfreulich, dass der laufende Datev-Betrieb wegen der vermeintlich defekten msdb nicht blockiert ist oder zusammenbricht, aber eine solche Fehlermeldung will man natürlich nicht ignorieren, vor allem, weil man keine konkreten Infos erhält, was genau fehlerhaft ist.

So ganz naiv hatte ich gedacht, man könne vielleicht einfach aus einer älteren Datensicherung die intakte msdb-Datei und ggfs. weitere Komponenten in den DATA-Ordner rücksichern., aber die von @einmalnoch verlinkte Webseite zeigt, dass man bei diesem Thema doch sehr tiiiiief in die Tasten greifen muss. Außerdem wüsste ich jetzt nicht auf Anhieb, wie weit ich zurückgreifen müsste/dürfte und woran ich eine intakte msdb erkenne.

.... da erscheint mir die von Datev ( @Christian_Tölle ) 'abgesegnete' Methode mit der Deinstallation/Installation des SQL-Servers für einen 'Normalsterblichen' machbarer und vom Zeitaufwand her kalkulierbarer.

@martinkolberg ,  ja, ein Testlauf auf einem (wiederhergestellen) Test-PC wäre auch 'charmant' (zum Spielen).

Letzten Endes soll aber die Fehlermeldung am 'Original'-Server irgendwie verschwinden und der log-Ordner soll sich nicht immer wieder und immer weiter mit Dump-und Fehler-Dateien füllen

Einen Erkenntnisgewinn wird man sowieso nicht haben, denn solche Lösungen sind wahrscheinlich singulär und eignen sich nicht für die Langzeitarchivierung im Gedächtnis.

[#17]

Die Frage "Wie weit zurück?" ergibt sich aus dem Datum des Dump, also der 21.04., wie immer gibt es natürlich ein Aber. Warum hat der SQL Server ein Dump geworfen?

Hier gilt es anzusetzen und die Ereignisanzeige zu prüfen ob dort Fehlermeldungen zu finden sind. Mag sein, dass es nur etwas Banales wie ein geändertes Schreibziel war oder ein Speicherfehler was dann Alarm auslösen sollte.

Kurzfristig reparieren, langfristig beobachten lautet die Devise.

[#18]

Nachtrag:

... ich könnte tatsächlich in den diversen Berichten nachsehen, wann die Fehlermeldung bezüglich der defekten msdb erstmals auftritt, aber ich vermute stark, dass ich die betreffende Datei nicht so einfach mit der zu Guttenberg-Methode (Copy&Paste) ersetzen kann. Jedes Service-Release oder auch MS-Updates, Hotfixe, Patches könnten hier 'die Suppe versalzen'.

Außerdem werden wohl alle Systemdatenbanken irgendwie miteinander verbunden sein.

Nachtrag 2:

ich versuche, so feinmotorisch wie möglich an die Sache heranzugehen 😉

danke an Alle für die 'moralische' und fachliche Unterstützung, auch nocheinmal @einmalnoch 

[#19]

In der Ereignis Anzeige des Servers würde ich unter Anwendungen auf die Ereignisse des MSSQL$DATEV_DBENGINE filtern und mir die Ereignisse ansehen. Bei einem Dump sollte ein Fehler erscheinen. In den Logs im Verzeichnis sollten weitere Hinweise auf die Ursache zu finden sein.

[#20]

Der sauberste Weg wäre ein Sichern der aktuellen Bewegungsdaten:
- DATEV
- Datenpfade
- Emails
- Nutzerdaten
und ein Rücksichern des Systems auf den Stand, als noch alles OK war. (Egal, wenn 1/4 Jahr alt)
Danach die Daten rückspielen, Updates nachholen und das System ist wieder komplett sauber.

Erst auf einen Testgerät probieren und wenn das läuft, den heißen Server reparieren.
Wenn der verunfallen sollte, dann das Testsystem als NotServer aktivieren.

Testsystem... Notfalls einfach neue Platten kaufen und diese in den Server einbauen.

[#21]

@einmalnoch 

… habe mir die log-Dateien näher angesehen und 'studiert'

hier ein beispielhafter Auszug aus den etwa viertelstündlich wiederkehrenden Einträgen:

----------------------

2020-04-25 06:38:50.79 spid51 Error: 8646, Severity: 21, State: 1.
2020-04-25 06:38:50.79 spid51 Unable to find index entry in index ID 1, of table 1077578877, in database 'msdb'. The indicated index is corrupt or there is a problem with the current update plan. Run DBCC CHECKDB or DBCC CHECKTABLE. If the problem persists, contact product support.
2020-04-25 06:52:39.37 spid51 **Dump thread - spid = 0, EC = 0x00000003AE1C4950
2020-04-25 06:52:39.37 spid51 ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.DATEV_DBENGINE\MSSQL\LOG\SQLDump10050.txt
2020-04-25 06:52:39.37 spid51 * *******************************************************************************
2020-04-25 06:52:39.37 spid51 *
2020-04-25 06:52:39.37 spid51 * BEGIN STACK DUMP:
2020-04-25 06:52:39.37 spid51 * 04/25/20 06:52:39 spid 51
2020-04-25 06:52:39.37 spid51 *
2020-04-25 06:52:39.37 spid51 * CPerIndexMetaQS::ErrorAbort - Index corruption
2020-04-25 06:52:39.37 spid51 *
2020-04-25 06:52:39.37 spid51 * Input Buffer 255 bytes -
2020-04-25 06:52:39.37 spid51 * 16 00 00 00 12 00 00 00 02 00 00 00 00 00 00 00 00 00
2020-04-25 06:52:39.37 spid51 * ÿÿ çÿÿ Ð 01 00 00 00 ff ff 0a 00 00 00 00 00 e7 ff ff 09 04 d0
2020-04-25 06:52:39.37 spid51 * 5þÿÿÿÿÿÿÿÖ E X 00 35 fe ff ff ff ff ff ff ff d6 02 00 00 45 00 58 00
2020-04-25 06:52:39.37 spid51 * E C U T E [ m s 45 00 43 00 55 00 54 00 45 00 20 00 5b 00 6d 00 73 00
2020-04-25 06:52:39.37 spid51 * d b ] . [ d b o ] 64 00 62 00 5d 00 2e 00 5b 00 64 00 62 00 6f 00 5d 00
2020-04-25 06:52:39.37 spid51 * . [ s p _ a g e n 2e 00 5b 00 73 00 70 00 5f 00 61 00 67 00 65 00 6e 00
2020-04-25 06:52:39.37 spid51 * t _ l o g _ j o b 74 00 5f 00 6c 00 6f 00 67 00 5f 00 6a 00 6f 00 62 00
...
...
...

----------------------------

Ich habe vor, ein 'Wartungsintervall' (zum Beispiel den prädestinierten 'Tag der Arbeit') zu nutzen, um die oben angegebenen Befehle DBCC CHECKDB und/oder DBCC CHECKTABLE zu testen und um bei Bedarf genug Zeit zu haben, um den MS SQL Server zu deinstallieren und neu zu installieren.

Schließlich möchte ich nicht meinen ganz persönlichen technischen "Lockdown" und eine gelangweilte Damen-Mannschaft erleben.

[#22]

Vorher den SQL Server auf das SP1 heben, siehe hier: https://support.microsoft.com/de-de/help/3035165/fix-error-8646-when-you-run-dml-statements-on-a-table-with-clustered-c 

MS sagt, dass der Fehler ab SP1 gefixt sei.

[#23]

wow, danke nocheinmal @einmalnoch .

Das liest sich ja so, als ob der Fehler schon bekannt sei und als ob man doch keinen auf SQL spezialisierten IT-ler mit übernatürlicher Intelligenz einfliegen lassen muss 

[#24]

.. ich kann es kaum erwarten, diesen Tipp von Ihnen ( @einmalnoch ) in einem günstigen Wartungsintervall auszuprobieren.

Den eigenen Fehlertext exakt so in einem Original-Microsoft-Support-Dokument zu sehen, mehr geht nicht 🙂

---------------

"Error: 8646, Severity: 21, State: 1.
Unable to find index entry in index ID 1, of table <id>, in database '<database>'. The indicated index is corrupt or there is a problem with the current update plan. Run DBCC CHECKDB or DBCC CHECKTABLE. If the problem persists, contact product support."

---------------

[#25]

---

@vogtsburger  schrieb:

.. ich kann es kaum erwarten, diesen Tipp von Ihnen ( @einmalnoch ) in einem günstigen Wartungsintervall auszuprobieren.

---

Aber nicht vergessen: Wer sichert, ist feige. 😋

[#26]

@einmalnoch ,

... was mich allerdings doch stark irritiert ist, dass SP1 inzwischen auch schon sehr alt ist.

aktuell wird SP3 (vom 30. Okt 2018) als "latest Service Pack" angeboten (siehe Screenshot).

Arbeitet der Datev-SQL-Server evtl. nur mit einer alten Version des MS SQL-Servers zusammen ? 🤔😮

-------------------

Microsoft SQL Server 2014 Service Pack 3 (the latest service pack)

---

Release date: October 30, 2018

[#27 · Accepted solution]

In welcher Version DATEV den SQL seinerzeit ausgeliefert hat kann ich nicht beantworten. Ist der SQL Server installiert liefert DATEV keine SPs aus, dafür ist dann der User oder sein Systempartner zuständig. Es finden sich hier auch gelegentlich Anfragen, wann denn ein SP für den SQL installiert werden darf ohne DATEV außer Betrieb zu setzen.

Mit einem WSUS im Netz wird, bei entsprechenden Einstellungen, das jeweilige SP mit den folgenden CUs zur Installation angeboten. Ist kein WSUS im Netz müssen die SPs und CUs in Handarbeit heruntergeladen und installiert werden.

[#28]

Danke nocheinmal @einmalnoch ,

.... wie immer sehr hilfreich, Ihre Beiträge , ***verneig***.

Inzwischen habe ich von anderer Quelle auch erfahren, dass man das letzte Service-Pack (also SP3) installiert und dass man den Befehl DBCC nicht so einfach ausführen kann/darf.

Also werde/muss ich 'den offiziellen St.-Jakobsweg' gehen per Deinstallation/Installation des MS SQL Servers, in der Hoffnung, dass sich hinterher alles in Wohlgefallen auflöst 

🙂

Nachtrag:

@einmalnoch schrieb:

...

Ist der SQL Server installiert, liefert DATEV keine SPs aus, dafür ist dann der User oder sein Systempartner zuständig.

...

... dann überrascht es mich doch 'ein wenig', dass man in den Service-Tool-Checks nicht wenigstens einen kleinen Hinweis findet, dass eine solch zentrale Komponente wie der "MS SQL Server" upgedatet werden sollte/müsste.

[#29]

    Hallo, das muss ich leider revidieren. Oben DVD 12.1 mit SQL 2014 SP2. Unten nach Update auf 13.1 SQL 2014 SP3.

[#30]

Hallo,

leider waren die Markierungen der Dateiversion in den Screenshots evtl. etwas Suboptimal. 

Über die dort auch angezeigte Dateiversion lässt sich der SP Stand auf dieser MS Seite ermitteln:

https://support.microsoft.com/de-de/help/2936603/sql-server-2014-build-versions

Da die Release Planung der Microsoft ServicePacks nicht immer in die Release Planung der DATEV DVDs passt,

und ein Service Pack des SQL Servers immer mit allen DATEV Anwendungen getestet werden muss, kann es aber einen DVD Zyklus dauern bis das Service Pack in die DATEV Installation eingebunden ist.

Viele Grüße

Martin Lederer