Datenbank Optimierung

Was wir erwarten

Von Datenbankanwendungen erwartet man eine minimale Antwortzeit und eine maximale Skalierbarkeit in Bezug auf die Datenmengen und die Benutzerzahlen. Häufig werden Versäumnisse in der Entwicklung oder beim Testen erst nach der Inbetriebnahme sichtbar, wenn in der Produktionsumgebung der Datenbankserver der vollen Belastung ausgesetzt ist. Und dann muss es meist schnell gehen...

In vielen Fällen wird durch eine ungünstige Konfiguration und fehlende Indexwartung einiges an Leistung verschenkt. Oftmals ist es gar nicht soo viel, was man tun muss, um die Performance zu steigern.

Schon alleine die Auswahl des "richtigen" Servers ist eine kleine Wissenschaft für sich. Wer hier nicht gehörig aufpasst, tappt schnell in die "Lizenzfalle". Glenn Berry postet regelmäßig sehr gute Artikel zum Thema Hardware und Prozessoren für SQL Server.
Als Beispiel sei folgender Artikel Recommended Intel Xeon E5-2600 v4 Processors for SQL Server genannt:

Dell PowerEdge R730

Xeon E5-2667 v4

8 Cores | 3.2 GHz 25 MB L3 Cache

If your workload can be split across multiple, two-socket database servers, you would be much better off with two or even three database servers, with lower core count, "frequency-optimized" processors (especially the Xeon E5-2643 v4 and the Xeon E5-2667 v4) rather than a single two-socket database server with a much higher core count processor model.

Glenn Berry, Principal Consultant with SQLskills

Dell PowerEdge R730

Xeon E5-2683 v4

16 Cores | 2.1 GHz 40 MB L3 Cache

Two servers with the eight-core Xeon E5-2667 v4 would be far superior to one server with the sixteen-core Xeon E5-2683 v4 processor. You would have much faster processor cores, more total L3 cache, twice the memory capacity, and twice the number of PCIe 3.0 slots, for the same SQL Server 2014/2016 licensing cost.

Glenn Berry, Principal Consultant with SQLskills

Bei der Auswahl der Hardware sollte man sich also Zeit nehmen, um die passende Konfiguration für den Workload (und das Budget) zu finden. Und man sollte das Augenmerk legen auf folgende Punkte:

Was wir tun können

Installation und Konfiguration

Der SQL Server wird oft mit den Standardeinstellungen installiert und die Datenbanken sich selbst überlassen. Er macht ja alles automatisch. Nun, ganz so ist es nicht. Schon alleine die Auswahl der "richtigen" Hardware ist eine kleine Wissenschaft für sich. Neben der Wahl der richtigen Edition sollte die SQL Server Instanz an die Hardware und den Workload angepasst werden.

Index- und Statistikwartung

Auch ein SQL Server braucht Pflege. Die Datenbanken wollen auf Konsistenz überprüft werden und ohne Index- und Statistikwartung kommt schon bald das Thema Performance auf den Tisch. Hier stellt Ola Hallengren mit seiner Maintenance Solution eine hervorragende Lösung bereit.

Baseline und Monitoring

Selbst wenn keine Probleme auftreten, sollte die Leistung eines SQL Server Systems in regelmäßigen Abständen gemessen werden, um eine "Baseline" für die Serverleistung zu erstellen. Damit haben Sie eine Basis zum Vergleich wenn Leistungsprobleme auftreten. Denn dann ist es für eine Baseline zu spät.

Performance Tuning

Nachträgliche Änderungen am Design der Datenbank oder dem Code der Anwendung sind zeitkritisch und generieren einen großen Programmieraufwand. Doch wie geht man strukturiert an ein Performanceproblem heran? Eine gute Tuning Methodik ist wichtig, um schnell und zuverlässig Verbesserungspotential erkennen und die Möglichkeiten von SQL Server besser nutzen zu können. Einen guten Einstieg stellt Brent Ozar mit seinem First Responder Kit zur Verfügung.

Hochverfügbarkeit

Geschäftskritische Daten müssen nicht nur geschützt werden. Sie müssen auch immer zur Verfügung stehen, rund um die Uhr. Die Themen Hochverfügbarkeit und Notfall-Wiederherstellung werden gerne überhört. Man hat ja gute Hardware. Solange bis der Ernstfall eintritt. Man muss nicht gleich mit einem Failover Cluster aufwarten. Es gibt auch andere Möglichkeiten, um seine Daten hochverfügbar zu gestalten.

Sicherung und Notfall-Wiederherstellung

Auch ein hochverfügbar ausgelegtes System entbindet nicht von der Notwendigkeit die Daten zu sichern. Wieviele Daten dürfen im Ernstfall verlorgengehen und wie lange darf das System maximal "down" sein? Habe ich eine gute Restore Strategie, sind die Sicherungen aktuell und werden meine Backups auch getestet?