Portfolio Datenbanken

Der SQL Server von Microsoft hat sich über die Jahre und Versionen allmählich zu einem Datenbanksystem entwickelt, dass es auch mit Konkurrenten wir Oracle, DB2, oder ähnliche aufnehmen kann. Das in jeder Beziehung. Sowohl was die Geschwindigkeit anbelangt, als auch in der Grösse der Datenbanken. So unterstützt die aktuelle Version 2016 unteranderem:

• bis zu 24TB Memory
• bis zu 1280 logische Prozessoren
• 524'272 TB als maximale Datenbankgrösse

Auch neue Techniken wie zum Beispiel die In-Memory-Performance und die Analyse operativer Daten in Echtzeit bringen sehr grosse Verbesserungen in Punkto Geschwindigkeit.
Auch hinsichtlich der Sicherheit wurde ein grosser Schritt gemacht. Die Always Encrypted-Technologie bietet einen hohen Schutz der Daten. Sowohl bei der Übertragung, wie auch bei der Speicherung.

Planung ist immer Wichtig. Eine Weisheit, die für alles gilt. Bei der Installation eines SQL Servers umsomehr. Ohne eine vollständige Planung der zukünftigen Verwendung, können bei einem SQL Server sehr schnell gravierende Performance- und Sicherheitsprobleme auftreten.

Klären Sie darum unbedingt vor der Installation folgende Fragen ab:

• Wieviele Instanzen soll dieser SQL Server besitzen?
• Sind Instanzen wirklich notwendig?
• Welche Sicherheitsanforderungen werden gestellt?
• Wieviele Datenbanken wird dieser SQl Server bedienen?
• Mit welchen Datenmengen ist bei den einzelnen Datenbanken zu rechnen?
• Ist eine Ausfallsicherheit (Mirror, Cluster) (zukünftig) notwendig?
• Wo werden die Datenbankfiles physisch abgelegt?
• Wie soll die Struktur im Filesystem aussehen?
• Gibt es die Möglichkeit jeder Datenbank 4 eigenständige Laufwerke zur Verfügung zu stellen?
• Wie soll das Backup der Daten erfolgen?
• Welche weiteren Funktionen sollen verfügbar sein?

Erst wenn mindestens diese Fragen abschliessend geklärt sind, sollte mit der Installation begonnen werden.
Natürlich ist es fast immer möglich nachträglich (mit mehr, oder weniger grossem Aufwand ) Änderungen vorzunehmen. Dennoch macht es sich bezahlt, wenn gleich zu beginn, die Installation korrekt an die betrieblichen Bedürfnisse angepasst ist.

Generell kann von folgenden "Faustregeln" ausgegangen werden:

• Eine Instanz sollte angesehen werden wie eine Windows-Domain. Nur wenn eine administrative Trennung notwendig ist, sollte mit mehreren Instanzen gearbeitet werden.
• Abhängig von der Datenbankanzahl und den zu erwartenden Zugriffen wird die Systemausstattung erarbeitet. Wichtig dabei ist:
• Die Performance des SQL Server ist massiv von den Disk und dem Memory abhängig. Daher wann immer möglich, kein Raid 5 verwenden. Ideal wären Raid 1, Raid 10, oder Raid 60.
• Wann immer möglich, SSD, oder Flash Disks verwenden.

Einen ganz wichtigen Faktor beim Tuning spielen die VLF (Virtuellen Logfiles) innerhalb der .ldf Files. Wichtig dabei ist folgendes zu Wissen:

• Abhängig von der grösse der .lfd Datei werden unterschiedlich viele VLFs angelegt
• Bei einer .ldf-Grösse bis 64MB werden 4 VLFs angelegt
• Bei einer .ldf-Grösse von 64MB bis 1GB werden 8 VLFs angelegt
• Ab einer .ldf-Grösse von 1GB werden 16 VLF angelegt
• VLFs sind, soweit es möglich ist, immer gleich gross. Ist das nicht möglich, werden 3 VLF in gleicher Grösse angelegt und der verbleibende Platz wird dem 4. VLF zugeteilt.
• Erst wenn alle im VLF abgelegten Transaktionen abgeschlossen sind, wird dieses "formatiert" und wieder freigegeben.
• In der Zeit, in der das VLF "formatiert" wird, können keine Transaktionen ausgeführt werden.
• Je grösser ein VLF ist, um so länger dauert das "formatieren"
• Das Anlegen von VLFs erfolgt in der gleichen Grössendefinition auch bei der Vergrösserung des .ldf
• Vorhandene VLFs kann man sich mit DBCC LOGINFO ansehen
• Die automatische Vergrösserung sollte niemals Prozentual erfolgen, sondern immer in festen (durch 4, 8, oder 16 teilbaren Schritten) erfolgen.

Wird die Datenbank durch ein in Java geschriebenes Programm abgefragt, so sollte unbedingt darauf geachtet werden, dass keine Vermischung der Datentype VarChar und nVarChar erfolgt. Grund ist die Übergabe der Abfragen durch den JDBC. Dieser kapselt alle Statements in einer Prozedur. Darin können jedoch immer nur 8-, oder 16-Bit Datentypen enthalten sein. Anderfalls muss eine Typkonvertierung (Cast) vorgenommen werden. Je nach Abfragemenge kann es hier zu erheblichen Performancebeeinträchtigungen führen.

Der SQL Server "lebt" von schnellen Disk-Zugriffen. Darum sollte prinzipiell auf ein Raid 5 verzichtet werden. Weiterhin macht sich es sehr bezahlt, wenn die Datenbankdatei (.mdf) von den Logfiles (.ldf) auf getrennten Laufwerken abgelegt sind. Werden mehrere Logfiles verwendet, so sollten auch hier verschiedene Laufwerke verwendet werden. Wann immer möglich, sollten hier SSD, oder Flash Disks zum einsatz kommen.

Wenn es nicht zwingend erforderlich ist, sollten Logfiles niemals geshrinkt werden. Besser ist es, wenn die Grösse der Logfiles durch häufige Backups des Transaktionslog klein gehalten wird.

Anhand des Execution Plans kann sehr gut ermittelt werden, ob sowohl die verwendete Query, als auch die eingesetzten Indexe optimal ausgelegt sind. Die abgesetzten Querys können mittels dem Profiler abgefragt werden.

Zur Analyse von Fehlern stehen seitens SQL Server umfangreiche Tools zur Verfügung. Die erste Wahl sollte immer die Auswertung der SQL- und der Windows Event-Logs sein. Bereits hier sind in den meisten Fällen sehr viele Informationen vorhanden, wenn konkrete Fehler aufgetreten sind. Wenn die Fehler jedoch nicht direkt durch Einträge in Logs erkannt werden können - zum Beispiel, weil es sich um Fehler bei den Ergebnissen handelt, oder weil die Fehler in der Performance vermutet werden - dann bringt der Profiler sehr oft aufschlüsse. Worauf ebenfalls unbedingt geachtet werden sollte, ist ausreichend freier Disk-Platz, sowohl für .mdf als auch für .ldf. Dieser Platz sollte ca. 15% - 20% der jeweiligen .mdf bzw. .ldf betragen.

Treten sogenannte Page-Fehler auf, so deutet das in vielen Fällen auf Probleme mit der Hardware hin. Allerding kann auch hier ein Platzproblem auf der Disk den Fehler verursachen.