Ein tiefgehendes SQL-Server-Tuning ist oftmals garnicht ohne ein entsprechendes Analyse-Audit möglich. Dennoch gibt es Basics, die erstmal erfüllt sein müssen, oder aber häufig gern falsch gemacht werden. Hier eine kleine Zusammenfassung die ich immer mal wieder erweitern und ergänzen werde.


Ihre Daten werden erst beim Abspielen des Youtube-Videos an den Dienst übermittelt. Your data will only be transmitted to the service when you play the Youtube video.

LDF- und MDF-Datei auf unterschiedliche Laufwerke verteilen

Es ist durchaus sinnvoll, die LDF- und die MDF-Dateien einer Datenbank auf verschiedene Laufwerke zu legen. Am besten auch auf Laufwerke abseits des eigentlichen Systemlaufwerks, unter dem z.B. das Betriebssystem arbeitet.

Jede Festplatte hat nur einen Schreibkopf, bzw. bei SSDs einen Controller. Ist der Schreibkopf, bzw. der Controller zum Beispiel gerade dabei die Logdatei (LDF) permanent fortzuschreiben, so muss er diesen Vorgang zum Auslesen der Datendatei (MDF) unterbrechen. Fortlaufende Logdateiinhalte müssen zwischengespeichert werden und dann bei Wiederaufnahme des Vorgangs auf die Platte gebracht werden. Das verzögert den ganzen Prozess ungemein und stellt gerade bei der Verwaltung von großen Datenmengen (meiner Definition nach MDF-Dateien > 20GB) ein ernsthaftes Problem dar. Gleiches gilt allerdings auch, wenn mehrere MDF- oder LDF-Dateien unterschiedlicher Datenbanken auf ein und demselben physischen Laufwerk liegen.

Zudem ist das Verteilen der Daten im Falle eines Laufwerkschadens wesentlich sicherer. Ist die MDF-Datei beschädigt oder verloren, gibt es noch die LDF-Datei und umgekehrt.

Sie sollten die Datenbankdateien, egal ob MDF- oder LDF-Dateien, aus o.G. Gründen nach Möglichkeit auch auf einem anderen Laufwerk lagern, als das Serverbetriebssystem.

Der SQL-Server gehört nicht auf einen Domaincontroller

Auf der einen Seite geht es hier um Performance. Unglücklicher als Active Directory (AD)  und SQL-Server kann man keine zwei Rollen und Dienste auf einem Windows-Server zusammenlegen. Beide Systeme ziehen Leistung und blockieren sich unter leicht zu erreichenden Bedingungen gegenseitig. Sie haben dann nicht nur ein Performanceproblem mit dem SQL-Server, sondern auch mit den AD-Funktionen. Wenn auch nicht sofort, aber irgendwann recht sich diese leichtsinnige Entscheidung: Entweder im laufenden Betrieb oder zu einem späteren Zeitpunkt, wenn Sie versuchen Einstellungen des SQL-Servers oder des ADs zu erweitern oder zu verändern.

In den neuesten Versionen des SQL-Servers bricht Microsoft die Installation des SQL-Servers ab, wenn es sich um einen Domaincontroller handelt. Sind Sie findig genug um diesen Mechanismus auszutricksen, nehmen Sie damit ernsthafte Probleme in Kauf.

Sie wollen, dass ich konkret werde? Die Funktion des schreibgeschützten ADs können Sie im Falle des gemeinsamen Hosts schon mal knicken. Genauso Fail-Over und Clustering beim SQL-Server. Sicherheitstechnisch ist der Betrieb eines SQL-Servers in unmittelbarer Nähe des Active Directory auch nicht schlau.

Außerdem gilt ganz besonders hier: Niemals alle Eier in einen Korb. Gerade weil es sich hier um die wirklich wichtigen Eier handelt. Die Haupt-Eier.

Tun Sie sich selbst einen Gefallen: Machen Sie das nicht.

Der SQL-Server gehört nicht auf einen Server mit Terminaldiensten oder Citrix-Terminaldiensten

Terminalservices oder Citrix-Terminaldienste sind Ressourcenfresser. Je nach gehosteter Anwendung kommen hier große Belastungen für CPU, Netzwerkhardware und Arbeitsspeicher zusammen. Sicherlich lassen sich große Teile dieser Problematiken mit der Aufstockung der Hardwarespezifikationen lösen, doch irgendwann ist auch an dieser Front Schluss mit Optimierungen. Tun Sie sich selbst einen Gefallen: Machen Sie das nicht.

Keinen Bildschirmschoner und keinen Energiesparplan

Man sollte meinen dieser Punkt wäre selbstverständlich. Nein, ist er anscheinend nicht. Fakt ist: Auf einem performanten SQL-Server-System haben diese Features nichts zu suchen. Gut gemeint, aber leider alles andere als hilfreich.

Der VM-Netzwerk-Overkill

Auch hier sollte man meinen, dass es sowas gar nicht gibt. Aber glauben Sie mir: Sowas gibt es im Produktiveinsatz.

Folgendes Szenario ist nicht sinnvoll: Ein physischer VM-Host beherbergt Domain Controller, Fileserver, Applikationsserver und natürlich SQL-Server als einzelne VMs. Ein anderer physischer Server im Netzwerk ist für das zeitgesteuerte Backup verantwortlich. Alle VMs des VM-Hosts laufen über eine Netzwerkkarte. Das funktioniert genau solange, bis das Backup anläuft. Die Netzwerkkarte glüht, laufende Applikationen geben den SQL-Server-Durchsatzraten den Rest.
Wenn Sie sich mit Ihrer Virtualisierungsumgebung auskennen, analysieren Sie solche Flaschenhälse und beheben Sie sie durch die Zuordnung von Prioritäten oder neuer Netzwerkhardware.

Netzwerkflaschenhälse lassen sich recht einfach analysieren, teilweise auch an den nachgeschalteten Switches, sollte es an Kenntnissen der VM-Verwaltung mangeln. Meistens hilft aber schon ein analytischer Denkansatz um solchen Problemen auf die Schliche zu kommen.