Hier noch ein paar Dinge, die man bei der Konfiguration des
SQL-Servers beachten sollte.
(Folgende Einstellungen findest du im Enterprise Manager > Rechtsklick auf dem
SQL-Server > Eigenschaften)
Tabsheet > "Memory"
Du hast 8 GB
RAM in der Maschine. Für den Windows, Tobit und die anderen Dienste sind 1-2GB mehr als genug.
Weise dem
SQL-Server fest 6GB
RAM zu.
- Option "Use fixed Memory Size" > auf 6 oder 7 GB
- Checkbox "Reserve physical memory for
SQL Server" setzen
Du beschreibst, das Abfragen oft sehr lange laufen. Das hört sich nach einem schlecht optimierten Nutzung der
DB an. Vermutlich zieht das Programm bei einigen Abfragen sehr viele Datensätze zum Client und verarbeitet diese dort. Besser wäre es, dem
SQL-Server die Arbeit zu überlassen, und nur die Ergebnisse zum Client zu liefern. Bei Abfragen sollte immer eine sinnvolle und möglichst kleine Datenmenge zurückgegeben werden. Das kannst du nicht beeinflussen, weil das Programm nicht von dir gewartet wird. Allerdings hast du die Möglichkeit dem
SQL-Server mehr Abfragespeicher pro Abfrage zuzuordnen.
- Option "Minimum
Query Memory"
Erhöhe die Werte mal schrittweise und beobachte das Verhalten der Applikation. Bei"weniger optimalen" Abfragen die oft verwendet werden kann man damit einer Menge erreichen.
Tabsheet > "Processor"
Die Änderungen der CPU Nutzung bringen nur was, wenn der
SQL-Server eine gewisse Last hat.
Wenn die CPU Last des
SQL-Server Prozesses während des "Normalbetriebs" deutlich unter 10% bleibt, dann kannst du hier nicht viel optimieren.
Dennoch ein paar Hinweise zu den Optionen ....
Du hast einem schnellen SMP fähigen Prozessor und ein Serverbetriebssystem.
Damit ist die
- Option "Use Windows NT fibers" (... instead of threads)
für dich interessant. Parallele Prozesse werden dann etwas optimaler verwaltet. Diese Option sollte nie auf Singel-CPU Systemen bzw. "nicht Server Betriebssystemen" aktiviert werden.
Mit etwas Vorsicht kannst du die
- Checkbox "Boost
SQL-Server priority"
aktivieren. Die ersten Tage nach dem Aktivieren der Option solltest du aber auf jeden Fall die Eventlogs des Servers kontrollieren. Wenn der
SQL-Server Kommunikationsprobleme mit den Clients loggt, dann musst du die Priority Boost Option wieder abschalten. Die Leistung der Prozessors reicht in diesem Fall nicht aus.
Kommen wir zu den Eigenschaften der Datenbank ...
(Folgende Einstellungen findest du im Enterprise Manager > Rechtsklick auf der "Speditionsdatenbank" > Eigenschaften)
Da ich die Struktur das Datenbank nicht kenne, kann ich dir nur ein paar "spekulative" Eckdaten geben.
Tabsheet > "Data Files"
Die Dateioptionen sind manchmal nicht sehr optimal.
Stelle sicher, das die
- Option "automatically Grow File"
aktiv ist und das Diese nicht auf dem standardmäßigen Wert "10%" steht. Wenn die
DB einen gewissen "Füllstand" überschreitet werden bei einer 6,5 GB großen
DB immerhin 650 MB große Änderungen auf die Platte geschrieben. Ein fester Auto-Grow-Wert zwischen 80 und 100 MB sollte hier mehr Sinn machen. Bitte mache nicht den Fehler und schraube den AutoGrow Wert auf 1MB runter. Der
SQL-Server würde sich dann zu sehr mit dem Warten seiner Datendatei beschäftigen.
Tabsheet > "Transaction Log"
Auch hier sind die Dateioptionen standardmäßig manchmal nicht optimal.
Stelle sicher, das die Option "automatically Grow File" aktiv ist. Der Default-Wert von 10% macht auch hier selten Sinn.
Empfehlung: Mach ein Backup der Datenbank (Recovery-Model "Simple") und merke dir die Größe des Transaktionsprotokolls (LDF). Lass den Kunden dann einen Tag lang mit der
DB arbeiten.
Sieh nach, wieviel MB die LDF zugelegt hat. Den Differenzwert trägst du als festen Autogrow Wert für das Auto-Grow des Transaction-Logs ein.
Wenn der Wert sehr hoch ist (500MB +), dann ist es auch hier besser, den Auto-Grow-Wert zu verkleinern.
Tabsheet > "Options"
Damit der
SQL-Server Zugriffsstatistiken führt und diese selbstständig aktualisiert, sollten die
- Checkboxen "Auto create statistics" und "Auto update statistics"
gesetzt sein. Mit Hilfe der Statistiken führt der
SQL-Server eine ständige Selbstoptomierung aus.
Daher sollten diese Checkboxen nie abgeklickt werden.
- Die Option "Torn page detection" frisst etwas Performance. Du solltest sie aber dennoch nicht deaktivieren. Der
SQL-Server sucht Transaktionen, die auf Grund von E/A Fehlern nicht vollständig abgeschlossen werden konnten. Dieser Haken kann bei fehlerhaften Platten bzw. Controllern irgendwann man wichtig werden
.
Über das Aktivieren der
- Autoshrink Option
kann man sich streiten. Wenn sich der Server "langweilt" kann man die Option ruhig aktivieren. Andernfalls würde ich das Verkleinern der
DB lieber über einen Wartungsplan nach Geschäftsschluss erledigen.
Damit das Transaktionsprotokoll nicht zu groß wird, setze ich das
- Recovery-Model auf "Simple".
Der
SQL-Server setzt so nach dem Sichern der
DB ein "Save-State" Flag und beginnt einen neuen Log-Zyklus. Das Transaktionsprotokoll wird nach dem Backup deutlich kleiner.
Wenn das Alles nichts bringt, nimm dir den Profiler und schau mal was der Server macht, während eine langsame Abfrage läuft. Wenn der Client damit beschäftigt ist 1-2 Millionen Datensätze abzusaugen, dann sprich mit deinem Kunden und reiche die "A"-Karte weiter an die Software-Bude. Ausserdem sollte möglichst viel Arbeit durch den
SQL-Server erledigt werden und nicht durch den Client. Eine große
DB ohne SP's und UDF's kann nur in wenigen Fällen optimal genutzt werden. Schlechte SP's und UDF's verursachen hingegen viel CPU-Last (und lange Lock-Zeiten) auf dem Server. Da kannst du u.U. auch mal einen Blick drauf werden.
Ich hoffe, das bringt dich schon mal ein Stück weiter.
Schöne Grüße,
Jens
