Hallo Community,
mich irritiert, dass Datev in der InfoDB unterschiedliche Aussagen zur Optimierung der SQL-Datenbanken kommuniziert.
Einerseits die Aussage:
"Der Microsoft SQL Server optimiert sich während der Laufzeit automatisch. Dabei aktualisiert er Statistiken und defragmentiert Daten sowie Indizes."
Andererseits wird im gleichen Dokument (Dok.-Nr.: 1071153) empfohlen .... :
"... die SQL-Datenbanken regelmäßig zu optimieren"
Zu diesem Zweck der Optimierung werden ein Paar Scripte im Verzeichnis "%DATEVPP%\PROGRAMM\B0000454\Maintenance" angeboten.
Beim Aufruf von z.B. "RunMaintenanceWE.cmd" wird zwar das Script gestartet, läuft eine ganze Weile, beendet sich 'wortlos', bleibt aber leider 'stumm'.
Die Ergebnisse kann man anscheinend irgendwie mit Hilfe von "Geiergriffen" anzeigen lassen, z.B. mit Strg+Shift+F4. in der "SQL-Server Management-Info".
Gibt es keine komfortablere Möglichkeit, z.B. den Zustand und die Fragmentierung VOR und NACH der Optimierung, die Dauer der Wartung, andere statistische Daten usw. in einer Übersicht, z.B. in einer Text-Datei anzuzeigen ?
Außerdem wäre es interessant und hilfreich, wenn die Funktion und die Ergebnisse der diversen Scripte dokumentiert wären.
... habe bisher die Nadeln im Heuhaufen noch nicht gefunden 😉
Ist mir ein Rätsel, wie erreichte 8GB von möglichen 12 GB zu viel sein sollen.
Weiterhin rätselhaft, warum keinerlei Reduzierung erfolgte, wenn man nach Anleitung diverse Mandanten (SchulungsmandantenNrn) gelöscht hat.
Insoweit 14.01 trotzdem „durchgelaufen“.
Nachtrag:
... vor allem würde mich interessieren, ob diese regelmäßigen SQL-Wartungs-/Optimierungsläufe per Script tatsächlich eine messbare Verbesserung bringen bzw. ob sie überhaupt sinnvoll oder notwendig sind ...
@vogtsburger schrieb:Nachtrag:
... vor allem würde mich interessieren, ob diese regelmäßigen SQL-Wartungs-/Optimierungsläufe per Script tatsächlich eine messbare Verbesserung bringen bzw. ob sie überhaupt sinnvoll oder notwendig sind ...
Beim Admin-Workshop wird über dieses Thema immer regelmäßig berichtet. Vielleicht hilft Ihnen das ja weiter?
@vogtsburger schrieb:Nachtrag:
... vor allem würde mich interessieren, ob diese regelmäßigen SQL-Wartungs-/Optimierungsläufe per Script tatsächlich eine messbare Verbesserung bringen bzw. ob sie überhaupt sinnvoll oder notwendig sind ...
Messbar bestimmt. Gefühlt eher nicht.. der SQL läuft einfach "runder". Wenn Indexe sauber sind (machen die Scripte9, hat es der SQL einfach leichter.
Wichtig ist, dass man bei solchen Scripten dann auch nicht den SQL zur Datensicherung stoppen sollte. Sonst ist der SQL-Chache wieder komplett bei Null und die Kiste genauso langsam wie vorher.
D.h. Sicherungen via VSS, damit die DB's immer schön geladen bleiben.
***meine Meinung!***
Grüße
Chr.Ockenfels
Danke, @chrisocki ,
... freue mich, dass es eine Stellungnahme eines Admin-Workshoppers bis hierher in die Community geschafft hat.
Der Hinweis auf eine geschlossene Gruppe oder auf eine von vielen kosten- und anmeldepflichtigen Veranstaltungen führt nämlich keinen Millimeter weiter.
Ich werde einfach mal ein bestimmtes Script wöchentlich starten und mit dem erwähnten Geiergriff ein paar protokollierte statistische Daten kontrollieren und auswerten.
Vielleicht kann ich auch selbst eine Verbesserung messen oder 'spüren', z.B. beim Aufruf zeitaufwändiger Aktionen.
@vogtsburger schrieb:
Ich werde einfach mal ein bestimmtes Script wöchentlich starten und mit dem erwähnten Geiergriff ein paar protokollierte statistische Daten kontrollieren und auswerten.
Vielleicht kann ich auch selbst eine Verbesserung messen oder 'spüren', z.B. beim Aufruf zeitaufwändiger Aktionen.
Dann kommunizieren Sie doch mal, welche Skripte Sie mit welchem (hoffentlich) messbaren Effekten Sie so gestartet haben.
Ich werde einfach mal ein bestimmtes Script wöchentlich starten und mit dem erwähnten Geiergriff ein paar protokollierte statistische Daten kontrollieren und auswerten.
Vielleicht kann ich auch selbst eine Verbesserung messen oder 'spüren', z.B. beim Aufruf zeitaufwändiger Aktionen.
Da mach ich doch mal mit... hab doch tatsächlich einen Kunden gefunden, bei dem ich die Scripte noch nicht am Start habe...
Script "RunMaintenanceWE.cmd" für die tägliche Ausführung auf 23:30 Uhr gesetzt. Da die Datensicherung stündlich läuft und ca. 14 Minuten braucht, kommen die sich nicht ins Gehege. Die SQL-DB-Prüfung läuft schon um 22:00 Uhr und benötigt aktuell ca. 14:57 Minuten.
Als weitere Referenz ziehe ich mal einen Rewe-Leistungsindex. Drei Tests ergeben ein Gesamtmittel von ca. 7.9 Sekunden (7.984 / 7,855 / 7.906). Hier könnten wir ggf. eine Referenz bilden, wenn das Script durchgelaufen ist.
Wobei der Datenzugriffswert für einen Menschen nicht mehr greifbar ist... (0,718 / 0,703 / 0,609) Hier ist aber schon schön zu sehen, wie der SQL seinen Cache bei gleichen Abfragen in einem kurzen Zeitraum befüllt und nutzt.
DATEV-FS und TS sind auf einem Hyper-V
- Xeon Gold 6128 3,40GHz
- 128 GB RAM
- RAID 1 (2x 800GB SSD SAS3) --> TS
- RAID 10 (4x 960 SSD SATA3) --> DATEV-FS
Ja, der DATEV-FS ist auf einem langsameren RAID/SSD-Verbund, da hab ich auf den SQL-Cache gesetzt. Und bei 10 Usern, ist die Maschine schon fast "Overkill".
- Windows Server 2019 (durchgängig).
Sobald die Werte nach dem durchgelaufenen Script vorliegen, melde ich mich.
Grüße
Chr.Ockenfels
Guten Morgen!
Das Wartungsscript ist durchgelaufen.
Mit einer Laufzeit von ca. 3-4 Minuten auch ziemlich schnell. Aus der Erinnerung heraus hatte ich bei einer anderen Kanzlei (deutlich grösser), erhebliche längere Laufzeiten bei dem ersten Lauf. Die nachfolgenden Läufe waren ebenfalls sehr schnell erledigt.
Nun die Testergebnisse auf dem Terminalserver...
Gesamtmittel 8,166 (8,139 / 8,469 / 7,891)
Datenzugriffsmittel 0,656 (06,25 / 0,734 / 0,609)
Also deutlich schlechtere Werte wie gestern... bsi auf den Datenzugriff. Hier sind fast keine messbare bessere Ergebnisse. Ich werde den Test kommende Woche nochmal wiederholen. Das Script lasse ich täglich laufen.
@DATEV: Vielleicht kann an dieser Stelle mal ein DB-Entwickler Stellung nehmen?
Beste Grüße
Christian Ockenfels
... mich überrascht, dass Ihr Optimierungslauf so schnell beendet ist.
Mein erster manueller Lauf dauerte 35 Minuten.
Und da man während der Ausführung des Scripts keinerlei Rückmeldungen erhält, fragt man sich, ob das 'Wartungsfenster' überhaupt ausreicht. (Der Defaultwert für die maximale Dauer der Reorganisation ist immerhin 180 Minuten).
Vielleicht sind die nächsten Läufe bei mir ja auch viel schneller beendet.
Falls Sie bei dem betreffenden System auch SQL-Prüf- und Sicherungsläufe (SQL Online-Sicherungen) machen, wäre interessant zu erfahren, wie lange die Online-Sicherung dauert (bei mir zur Zeit ca 50 Minuten, bei Ihnen vermutlich nur ein Bruchteil davon)
Hi,
@vogtsburger schrieb:
... mich überrascht, dass Ihr Optimierungslauf so schnell beendet ist.
Mein erster manueller Lauf dauerte 35 Minuten.
Und da man während der Ausführung des Scripts keinerlei Rückmeldungen erhält, fragt man sich, ob das 'Wartungsfenster' überhaupt ausreicht. (Der Defaultwert für die maximale Dauer der Reorganisation ist immerhin 180 Minuten).
Vielleicht sind die nächsten Läufe bei mir ja auch viel schneller beendet.
für irgendwas muss ein SSD-RAID doch gut sein, oder? 😉
Und ja, die folgenden Wartungsläufe sollten bei Ihnen auch schneller bzw. kürzer werden.
@vogtsburger schrieb:
Falls Sie bei dem betreffenden System auch SQL-Prüf- und Sicherungsläufe (SQL Online-Sicherungen) machen, wäre interessant zu erfahren, wie lange die Online-Sicherung dauert (bei mir zur Zeit ca 50 Minuten, bei Ihnen vermutlich nur ein Bruchteil davon)
Müsste ich beizeiten mal zusätzlich einrichten. Ich nutze die Onlinesicherung überhaupt nicht.
Grüße
Chr.Ockenfels
Hallo zusammen,
wie versprochen noch die Ergebnisse nach mehreren Tagen Laufzeit.
1. Das Wartungsscript braucht lt. DATEV SQL-Manager ca. 56 bis 80 Sekunden für einen kompletten Lauf. Es gibt also gar nicht so viel zu warten...
2. Das Datenzugriffsmittel im Leistungsindex liegt unverändert bei ca. 0,640 Sekunden. Da hat sich also nichts verändert. Die Gesamtzeit liegt bei ca. 7-8 Sekunden, je nach Belastung des Terminalserver.
Beste Grüße
Christian Ockenfels
Hallo Zusammen,
ich beschäftige mich auch gerade mit der Einplanung dieser Skripte, da diese bei uns bisher noch nicht gelaufen sind. Lediglich die Aktualisierung der Suchstatistiken sind in der Aufgabenplanung eingetragen.
Da habe ich eine Frage:
Im Dokument https://apps.datev.de/help-center/documents/1071153 wird gesagt, dass für die Rechnungswesen DB täglich zwischen 20 Uhr und 22 Uhr eine eigene Wartung läuft.
Von welchem Prozess wird diese Wartung denn gestartet? In der Aufgabenplanung finde ich auf dem File/SQL-Server keinen Task.
Wenn ich mir über den SQL-Administrator die Details zu den letzten Wartungsläufen ansehe, dann sehe ich dort auch nur die Aktualisierungen der Suchstatistiken. Von einer Optimierung der REWE-DB ist da nichts zu sehen.
Wenn ich nun das Skript RunMaintenance.cmd oder RunMaintenanceWE.cmd laufen lasse, dann wird hiermit im Standard die REWE-Datenbank auch außen vor gelassen.
Gruß
Eine kleine Ergänzung:
Die Standard Konfig-Datei für die Pläne hat folgenden Inhalt:
; zu wartenden Datenbanken - NULL = ALLE, außer den Ausnahmen
include_databases=NULL
; % ersetzen wildcards
;include_databases = %\DATEV\DATEN%
;include_databases = %\DOKORG%
;include_databases = %\IRW%
; Ausnahmen - NUR sofern database_id = NULL
; % ersetzen wildcards
;exclude_databases = NULL
exclude_databases = %ARCHIV%,%sicherung%,%backup%,%\TRAFO\%,%EOAUSWE\ASLOKAL,%EODA\ASTEMP,%EODA\ASKONS,%DATADISC,%ASPOOL
;exclude_databases = %ARCHIV%,%sicherung%,%backup%,%\TRAFO\%,%EOAUSWE\ASLOKAL,%EODA\ASTEMP,%EODA\ASKONS,%DATADISC,%ASPOOL,%\RWDAT\%IRW
;exclude_databases = %test%
Demnach werden alle Datenbanken angefasst, außer die in den Ausnahmen. In der Ausnahme-Liste ist die IRW nur im Kommentar gelistet und sollte demnach auch optimiert werden.
Sehe ich das richtig?