Neu SQL-Server für JTL-Wawi optimal einrichten

[jendris]

Hallo,

es gibt diesen bekannten SQL Server Guide
https://guide.jtl-software.de/jtl-wawi/installation/sql-server-optimal-einrichten/
in dem empfohlen wird, bestimmte Dateien auf 4 Festplatten zu verteilen.
Leider gibt es keinen Guide, der beschreibt, wie man das exakt einrichtet, so dass mir das eine und andere nicht ganz klar ist.
Auch andere Threads zu dem Thema haben mich nicht weitergebracht.

Die Wawi läuft bei uns auf einem Windows 10 Rechner, (i5 der von 2 Clients genutzt wird.)
Auf c: liegen Windows und der SQL Server (Standard Edition)
Nun wurden 3 weitere SSD Platten integriert.
Laut Guide sollen hier jeweils die *.mdf-Datei, *. log-Datei, Temp-DB abgelegt werden.

Bei mir sieht das so aus:



Die Aussage mdf Datei irritiert mich insofern, da die Eazybusiness.mdf auch eine mdf Datei ist.
Diese liegt weiter auf c: im MSSQL Verzeichnis und wird vermutlich auch dort bleiben, oder muß diese auch auf eine separate Platte?
Ist die eazybusiness_log.ldf eine der Logdateien, die auf eine separate Platte muß, und wie kann ich die dorthin verschieben?





Bei den Tempdaten stellt sich dieselbe Frage, ob die auf C: liegenden Dateien auf P: müssen, bzw. die templog auf die Platte mit den *.log Dateien gehört.

Dann wäre noch interessant zu wissen, ob die *.mdf-Datei, *.log-Datei, Temp-DB neben dem stündlich stattfindenden Datenbank Backup, auch noch separat gesichert werden müssen?
Oder werden diese bei einem Datenbank Restore immer neu angelegt?

Vielleicht kann mir jemand weiterhelfen.

 

[SebastianB]

Hi,

also bei SSDs weiß ich nicht ob man den Aufwand betreiben sollte, die Dateien wirklich auf getrennte Laufwerke zu legen. Vor allem nicht bei nur 2 Clients. Ich würde überlegen, zwei SSDs im RAID zu betreiben und dort die Dateien vom SQL-Server hinzuschieben und die dritte SSD dann als Backup-Medium für die Backups.

 

[Shopworker.de]

Hallo Sebastian,

ist es denn sinnvoll bei SSDs das Betriebssystem und die Datenbank auf die gleiche Festplatte ( SSD im Raid ) zu packen oder Betriebssystem und Datenbank auf jeden Fall getrennt?
Für Backups reichen in aller Regel ja normale HDD-Festplatten.

 

[chris42]

Einfach eine gute NVME SSD für alles und gut ist, ist schnell genug für diese kleinen Datenmengen.

1. Backup über das interne Netz auf anderen Rechner / Server / NAS etc,, von Backup Server dann Backup Spiegelung auf wechselnde USB Platten oder an anderen Standort.
Backup Rechner wenn es geht nicht Windows (aus Sicherheitsgründen). Neben dem SQL Dump mache ich noch bei jedem Update der Wawi ein Diskimage des Servers auf den Backup Server. Als Hardware Backup haben wir eine Virtuelle Maschine um
Standby die nur das SQL Datenbank Backup und die aktuelle Wawi Version braucht und den Server (dann halt langsamer) ersetzen kann. Backup und Failover werden meist zu wenig bedacht.

Als Datei und Backup Server und für Virtuelle Maschinen verwenden wir Proxmox mit einem ZFS Dateisystem (auf mehrere Platten mit einer Spare Platte) mit automatischen Snapshots.
Wenn man davon aber keine Ahnung hat soll man das besser lassen, ist doch etwas kompliziert. Durch die Snapshots sind die Daten auch vor Verschlüsselungs Trojanern auf den Clients geschützt.

cu chris

 

[SebastianB]

Hallo Sebastian,

ist es denn sinnvoll bei SSDs das Betriebssystem und die Datenbank auf die gleiche Festplatte ( SSD im Raid ) zu packen oder Betriebssystem und Datenbank auf jeden Fall getrennt?
Für Backups reichen in aller Regel ja normale HDD-Festplatten.

Servus,

na ja - es ist die Frage weshalb man etwas macht

Also: Wir haben ja das OS, die SQL-Server Programmdateien und dann die Datenbankdateien. Bei den Datendateien gibt es die Datenbankdatei (mdf), die Logdatei (ldf) - und das selbe dann nochmal für die TempDB.

Viele Punkte der Diskussion stammen noch aus Zeiten, in denen es Festplatten gab. Also diese komischen Dinger die drehende Teile drinnehaben usw - da gab es sowas wie Zugriffszeiten. Heute gibt es keine Festplatten mehr in Datenbankservern. Wirklich nicht. Also niemand sollte sowas machen. Deshalb sind die Seek-Zeiten heute vernachlässigbar (was wiederum für den SQL-Server bei der Schätzung der Ausführungspläne zu anderen Effekten führt - der denkt nämlich immernoch, er würde mit Festplatten aus den 90er Jahren arbeiten) - und damit fällt auch ein Grund für die Trennung der Dateien weg.
Dann gibt es noch die Idee, dass man mit mehreren Laufwerken ja mehrere Dinge gleichzeitig tun kann - sprich: Ich kann von zwei Festplatten doppelt so schnell lesen wie von einer. Und auch doppelt so schnell schreiben. Das ist auch an sich richtig und wahr - aber in Zeiten von SSDs und NCQ ist das auch eher nebensächlich - bei den Schreib- und Leseraten einer SSD ist es glaub ich für die Wawi egal, ob ich die jetzt noch in einigen Randsituationen verdoppeln kann oder nicht. Noch dazu kommt dieser Effekt nur zum tragen, wenn ich viele parallele Zugriffe habe und wenig im Cache halte - was beides im Falle der Wawi eher selten der Fall ist (wenn wir ehrlich sind kann der SQL Server die meisten Datenbanken der Händler mehr oder weniger vollständig im RAM halten wenn er denn mag)
Insofern: Der Grund fällt auch bei SSDs heute weg.
Dann haben wir das Thema Datensicherheit. Sozusagen das "Totschlagargument". Da muss man ehrlicherweise sagen: Das einzig Sinnvolle hier ist eine vernünftige Backup-Strategie. Und viel wichtiger noch eine Restore-Strategie. Und eine Strategie für die Zwischenzeit zwischen Ausfall und Restore. Wirklich. Macht Euch darüber Gedanken. Ich habe im Laufe der letzten 10 Jahre (ja, ich bin jetzt in diesem Jahr 10 Jahre bei JTL) so ziemlich alles gesehen - SQL Server mit Standard-sa-Passwort frei im Netz, SQL Server auf Routern - aber eben auch sehr häufig SQL Server mit "das letzte Backup wurde durchgeführt vor 3 Jahren". Macht bitte regelmäßig Backups und prüft, ob die wieder eingespielt werden können. Und DBCC ist wichtig dabei. Ich hatte wirklich schon Händler, denen ich echt sagen musste - sorry, wir können nicht helfen. Nicht, weil wir es nicht wollten (wir lehnen uns da im Ernstfall wirklich weit aus dem Fenster und helfen wo wir können) sondern weil es schlicht nicht mehr geht.
Okay, davon abgesehen: Wenn die mdf beschädigt ist, hilft mir auch eine intakte ldf nicht. Und anders rum. Sprich: Die Trennung der Daten bringt mir diesbezüglich keinen Vorteil.
Unterm Strich sehe ich persönlich(!) keinen wesentlichen Vorteil darin, die Datendateien vom Betriebssystem zu trennen, sofern wir über moderne SSD-Systeme sprechen und es ein vernünftiges Backups gibt. In keinem mir bekannten Fall hat uns das über die Zielline von einer Optimierung gebracht. Da gibt es andere Punkte die wichtiger sind - ich weiß nicht, ob ich es schonmal erwähnt hatte - die Backup und Restore-Strategie z.B..

Also meine persönliche Empfehlung:
SSD so flott wie es geht, RAID drauf wenn man mag - dann Backup auf andere SSD (hier würde ich auch eine SSD nutzen, weil dann das Backup zügig geht) und von dort aus via Netzwerk auf eine sichere Stelle kopieren. Und regelmäßig prüfen, ob das Backup in Ordnung ist und auch wieder eingespielt werden kann. Regelmäßig (also mindestens einmal am Tag) DBCC CHECKDB ausführen (wenn die DB kaputt ist, läuft der SQL Server einfach weiter). Virenscanner so einstellen, dass er den SQL Server in Ruhe lässt. (Wirklich! Das ist wichtig! Durch das ServiceDesk ist es nicht die Frage ob, sondern wann man sich eine Virus- oder Spammail in die DB holt. Wenn dann der Virenscanner den Zugriff auf die ganze DB blockt ist das wenig lustig. Braucht ihr nicht mehr ausprobieren, haben schon andere Händler für Euch getestet - und ist doof!)

Was nicht sein sollte:
Worker und SQL Server auf einem PC. Die fressen sich gegenseitig die Ressourcen weg. SQL Server auf einem virtualisierten Dateisystem - das ist zu langsam. SQL Server in einer VM - da kann man zu viel falsch machen, so dass es zu langsam wird.

Wenn man sich daran hält, ist man in meinen Augen gut dabei.

Und ja - das sind jetzt allgemeine Aussagen für Leute, die sich die Frage stellen ob ihr SQL Server gut eingerichtet ist. Es gibt für alles Ausnahmen. Wenn ich jemand habe, der professionell mit Ahnung VMs aufsetzen kann - dann kann der auch eine gute VM für einen SQL Server aufsetzen. Wenn ein "Allrounder" Virtualbox auspackt, weil "man das so macht", dann ist das Ergebnis eher weniger lustig - deshalb rate ich davon ab. Schlicht, weil ich schon sehr viele Systeme gesehen habe, die in die obigen Probleme gelaufen sind.

Ab einer gewissen Firmengröße gehört die Betreuung des SQL Servers in erfahrene Hände.

 

[Shopworker.de]

Hallo Sebastian,

danke für die ausführliche Antwort, das sind vor allem Infos, die sich auf aktuelle Hardware beziehen.

Das mit dem Worker auf dem Server hatte ich so gar nicht auf dem Schirm; ich lasse den eigentlich immer mit auf dem DB-Server-Rechner laufen.

Eine Frage noch: Gibt es ( auch für die MSSQL-Server Express-Version ) ein Tool, welches automatisch den DBCC CheckDB regelmäßig laufen lassen kann? Idealerweise mit eMail-Feedback, falls Fehler auftauchen?
Für automatische Backups nutze ich, wie vermutlich ganz viele andere Nutzer auch das Tool SQL Backup and FTP ( für 1 Instanz kostenlos ). Du schreibst, dass man auch Restores überprüfen sollte; auch hier die Frage kennst du da Tools, welche das automatisiert machen? Selbst die in der Wawi eingebaute Backupmethode nutzt ja meines Wissens keine Überprüfung des Backups ... und wer macht schon ohne Not ein Restore der Datenbank

 

[_simone_]

Unsere DB ist über 12 Jahre alt und läuft noch wie vor auf einer SSD. 6x am Tag wird gibt es ein Backup und 1x im Monat ein Clon von der SSD auf ein Image. Das wird dann nach 1-2 Jahren auf eine neue SSD gespielt und die alte SSD arbeitet weiter in irgendeinen Clientrechner.

Zeitgleiche Zugriffe gibt es von mindestens:
3x Büro
2x Produktion
1x Warenkontrolle
2x Packtisch
1x WMS

Trotz Express rennt das JTL-System unglaublich schnell und stabil, dass ich auch einen Mailserver mit div. Filterfuntionen noch mit auf dem Server habe. (Info s. Signatur)

 

[jendris]

Hi,

also bei SSDs weiß ich nicht ob man den Aufwand betreiben sollte, die Dateien wirklich auf getrennte Laufwerke zu legen. Vor allem nicht bei nur 2 Clients. Ich würde überlegen, zwei SSDs im RAID zu betreiben und dort die Dateien vom SQL-Server hinzuschieben und die dritte SSD dann als Backup-Medium für die Backups.

Moin zusammen,

vielen Dank für die Antworten.
Ich habe schon die Idee, die Performance mit der mir zur Verfügung stehenden Hardware, auszureizen.
Hintergrund sind nicht die 2 Clienst, das wäre ja auch unsinnig, sondern vielmehr die hohe Artikelanzahl (ca. 700.000 ohne Bilder)
und eine hohe Ameisennutzung. Die Ameise muß täglich Artikel ( auch im 5 stelligen Bereich) neu importieren, Preise und Bestände korrigieren, und das stündlich. Das was ich bisher mit der Aufteilung auf mehrere Platten erreicht habe ist schon sichtbar, da pro Minute
einfach mehr Import - Export möglich ist.

SSD´s im Raid war auch schonmal gedanklich ein Thema, aber es wird oft davon abgeraten. Performanceeinbußen und mangelnde Langlebigkeit wird da als Gründen genannt.

Das Thema Backup habe ich mit Interesse aufgenommen, dies soll aber hier nicht das Prio Thema sein, da ich mit Backup und Restore "SQL Backup and FTP", wie ich finde, gut aufgestellt bin, auch ohne Raid.

Wie muß ich mir Dein Vorschlag in der Umsetzung vorstellen?

Ich würde überlegen, zwei SSDs im RAID zu betreiben und dort die Dateien vom SQL-Server hinzuschieben und die dritte SSD dann als Backup-Medium für die Backups.

Ich habe auf einer M2 das OS und den SQL Server installiert.
Sollen jetzt die Dateien vom SQL Server auf eine weitere Platte verschoben werden?
Welche Dateien wären das? Ich hätte die Möglichkeit, dafür eine weitere M2 zu nutzen.
Das wäre dann eine Auslagerung auf eine statt drei weitere Platten, verstehe ich das richtig?

Zum Thema Backup würde mich dann aber doch noch interessieren, ob die *.mdf-Datei, *. log-Datei, Temp-DB neben dem stündlich stattfindenden Datenbank Backup, auch noch separat gesichert werden müssen?
Oder werden die mit dem "SQL Backup and FTP" mit gesichert?

VG Olli

 

[SebastianB]

Servus,

na ja, der Worker startet im Grunde bis zu 10 Wawis gleichzeitig. Die ziehen sich alle bis zu 1GB RAM - und das im 5 Minuten Abstand. Dagegen kämpft dann ein SQL-Server der am liebsten den ganzen RAM vom OS abzieht. Das kann gutgehen (wenn der Worker nicht zu viele Instanzen spawnen muss und ein Express-SQL-Server daneben sitzt)

Beim Backup muss man sich halt folgende Fragen beantworten:
1. Wie lange darf der Zeitraum sein, in dem die Daten verloren sind?
2. Wie lange darf der Zeitraum sein, in der das System offline ist, bis das System wieder läuft.
Man kann beide Zeiträume auf nahezu 0 drücken - allerdings steigen dann auf der anderen Seite die Kosten auch sehr steil an.

Es gibt viele SQL Monitoring- und Backuplösungen die all das machen, was man sich vorstellt. Ich kenne mich auf dem Markt aber nicht genug aus, um da eine Lösung empfehlen zu können. Ich bin ja immer nur der, der am Ende, wenn alles schief gelaufen ist an der Reihe ist

Das Wawi-Backup prüft all das, was der SQL-Server prüfen kann (DBCC CHECKDB, WITH CHECKSUM usw.) - aber tatsächlich nicht, ob das Backup eingespielt werden kann.

Aber: Im Grunde kann man das mit einer BAT-Datei hinbekommen oder ein Programm scheiben oder (in der Standard-Version) den Agent machen lassen - aber: Es geht im Grunde um die Existenz der Firma. Ich weiß nicht, ob man unbedingt an der Stelle sparen und basteln sollte, oder ob man sich da nicht auf eine etablierte Lösung verlassen sollte.

 

[SebastianB]

Das Thema Backup habe ich mit Interesse aufgenommen, dies soll aber hier nicht das Prio Thema sein, da ich mit Backup und Restore "SQL Backup and FTP", wie ich finde, gut aufgestellt bin, auch ohne Raid.

Ein RAID hat nichts mit Backup zu tun. Ein RAID baut man, um einen Performance-Gewinn zu bekommen oder um eine Redundanz der Daten zu bekommen. Die Redundanz kann(!) einen im Fall eines Festplattendefekts retten - allerdings passieren über 90% der tatsächlichen Datenverluste nicht durch einen Festplattendefekt. Deshalb ist ein RAID völlig unabhängig von einem Backups.
Meine (ganz persönlichen und subjektiven) Top-10:
1. Festplatte ist vollgelaufen
2. Händisch falsche SQL Befehle abgesetzt
3. Fehler in der Software
4. Fehler im Betriebssystem / Treiber
5. Fehler im SQL-Server (deshalb immer aktuelle ServicePacks bzw. CUs nutzen)
6. Virenscanner die den Zugriff auf die MDF-Datei blockieren
7. SQL Server wird nicht sauber runtergefahren / Stromausfall
8. Probleme mit der Hardware / Festplatte

Das wäre dann eine Auslagerung auf eine statt drei weitere Platten, verstehe ich das richtig?

Die Dateien können auch auf der Hauptplatte bleiben in meinen Augen - du wirst keinen Performance-Unterschied merken.

Zum Thema Backup würde mich dann aber doch noch interessieren, ob die *.mdf-Datei, *.log-Datei, Temp-DB neben dem stündlich stattfindenden Datenbank Backup, auch noch separat gesichert werden müssen?

Nein, in der BAK-Datei ist alles drinne.

 

[jendris]

Was nicht sein sollte:
Worker und SQL Server auf einem PC. Die fressen sich gegenseitig die Ressourcen weg.

Das verstehe ich nicht. Wie sollen Worker und SQL Server getrennt werden?
Ich meine, der Worker ist doch Bestandteil der Wawi, und die Wawi sollte doch auf dem PC laufen, auf dem der SQL Server läuft.
Oder stehe ich jetzt komplett auf der Leitung?

 

[SebastianB]

HI,

nein, die Wawi sollte nicht auf dem PC laufen auf dem der SQL Server läuft. Der SQL Server läuft im Idealfall alleine auf einem Rechner, auf dem nix anderes passiert.
Im "Idealfall":
1. Rechner: Worker
2. Rechner: SQL Server
3.-x. Rechner: Arbeitsstationen mit der JTL-Wawi drauf.

Ja, man kann das alles auf einem Rechner laufen lassen, aber es ist halt aus verschiedenen Gründen nicht "optimal" - und bei größerer Last nicht mehr sinnvoll.

LG,