News zu Microsoft SQL Server
Dieser DBA-Tipp ist der erste Teil einer kleinen Serie, welche sich detailliert mit der Fehlervermeidung beim Einsatz von Microsoft SQL Server Datenbanken beschäftigt. Um die Vielzahl von Punkte übersichtlich zu halten, haben wir die Serie in 3 Themenbereiche untergliedert.
Wir beginnen ganz oben – sprich: auf Ebene der Instanz. Dazu stellen wir aus jedem Teil verschiedene Punkte vor, welche unserer Erfahrung nach am häufigsten auftreten. Gleichzeitig benötigt man dafür nicht zwingend fachliches Tiefenwissen, um diese Empfehlungen umzusetzen.
Wir beginnen gleich mit einem Klassiker:
Die Zuordnung einzelner Prozessoren oder Kerne zu einer bestimmten SQL Server Instanz entsteht mehrheitlich aus dem Wunsch heraus, die Ressourcen eines von mehreren Instanzen gemeinsam genutzten Windows Hosts optimal zu verteilen. Insbesondere auch in virtualisierten Umgebungen spielt das eine erhebliche Rolle. Hier kann man sich jedoch schnell bei der korrekten Zuweisung der CPU-Ressourcen verschätzen. Man läuft hier schnell Gefahr, die zwei folgenden Tatsachen außer Acht zu lassen:
Werden diese beiden Tatsachen nunmehr in der manuellen CPU-Zuweisung nicht berücksichtigt, kann es schnell zu folgenden Problemen kommen:
In beiden Fällen läuft es also nicht optimal. Klar, wenn man das weiß, kann man die CPU-Zuweisung auch schnell wieder anpassen. Doch macht eine ständige manuelle Anpassung wirklich Sinn? Und vor Allem: Hat der DBA heute für so etwas überhaupt noch ausreichend Zeit? Das muss jeder für sich selbst bewerten, aber wir meinen, genau diese Arbeit sollte man dem SQL Server selbst überlassen. Dazu bringt das SQL Server OS bereits entsprechende Algorithmen mit, die diese Arbeit selbstständig und zuverlässig übernehmen. Und genau das ist auch unsere klare Empfehlung für diesen Punkt.
Trace Flags verändern die Funktionsweise des SQL Servers an entscheidenden Stellen. Daher sind sie ab Werk (also durch Microsofts Installer) niemals automatisch aktiviert. Das manuelle Setzen an sich ist jedoch nicht komplett falsch, sondern vielmehr das unnötige Setzen. Denn einmal aktivierte Trace Flags tendieren dazu, im Arbeitsalltag sehr schnell in Vergessenheit zu geraten. Nicht zuletzt auch dadurch, dass das SQL Server Management Studio bis heute keinerlei Oberfläche zur Anzeige oder Kontrolle von Trace Flags anbietet.
Der Sinn eines Trace Flags liegt darin einige der grundlegenden Funktionen zu steuern, die teilweise tief in der Engine verborgen sind. Ein händisches Aktivieren ist jedoch nicht mit dem Zünden des Turbos zu verwechseln. Viel eher ist es vergleichbar mit dem Ausschalten des ABS. Hier muss man genau wissen, was man tut.
Mit Trace Flags sollte man im Alltag also äußerst sparsam umgehen. Unsere Empfehlung stützt sich hierbei auf zwei Dinge:
Ausgewählte Beispiele für überholte Trace Flags sind:
Einige Beispiele für gefährliche Trace Flags sind:
Ein besonderes Beispiel für ein nicht existentes Trace Flag ist:
Diese Auflistung soll selbstverständlich die Trace Flags nicht pauschal verunglimpfen. Sie soll vielmehr eine Empfehlung sein, die jeweiligen Einstellungen nicht leichtfertig zu setzen und sich außerdem über Sinn und Zweck eines Trace Flags absolut im Klaren zu sein.
Eine der unschönsten Konfigurationen eines SQL Servers entsteht bereits während der Installation. Und zwar die Verwendung dynamischer Ports des TCP/IP-Protokolls. Denn benannte SQL-Server-Instanzen verwenden von Haus aus bei jedem Hochfahren der Instanz (Dienststart) einen anderen Port.
Ändert man das auf die Verwendung von statischen Ports, ergeben sich zwei Vorteile:
Folglich empfehlen wir bei diesem Punkt die Umstellung auf feste (statische) Ports. Das dürften sicherlich auch die Netzwerk-Admins begrüßen.
Das folgende Thema ist simpel, aber wertvoll. Unter Windows-Admins ist eine Regel wohlbekannt: keine Berechtigungen für Benutzer, sondern für Gruppen. Anstatt also eine Reihe von einzelnen Logins mit vielen Einzelberechtigungen zu versehen, ist es ratsam, die jeweiligen Logins einer Rolle zuzuordnen. Und damit ist auch schon die Lösung genannt.
Dieses aus dem Windows-Bereich bekannte Prinzip lässt sich auch im SQL Server anwenden. Lediglich das Wording ist ein klein wenig unterschiedlich:
Leider noch immer wenig bekannt ist die Tatsache, dass Microsoft mit Einführung der SQL Server Version 2012 die Option für selbst definierte Server-Rollen bereitgestellt hat. Server-Rollen können differenziert mit Berechtigungen ausgestattet werden. Sicherlich macht das hier am Anfang ein wenig mehr Arbeit, sich entsprechende Gedanken zu machen und dies auch so umzusetzen. Aber der Aufwand lohnt sich.
Erfahrungsgemäß zahlt sich das saubere Vorgehen bei der Umsetzung der oben genannten Punkte aus. Insbesondere bei der Umsetzung von Migrationen oder Konsolidierungen von SQL Server Instanzen lassen sich somit entsprechende Aufgaben optimieren. Eine konsequente Verwendung von Server-Rollen und deren sinnvolle Benennung trägt entscheidend zur Transparenz in den Systemen bei und erleichtert somit auch eine Systemdokumentation.
Ein bereits bekannter Umstand ist, dass beim Setup eines SQL Servers diverse Komponenten für die Installation auch einzeln ausgewählt werden können. Die wichtigsten Komponenten sind:
Vermutlich aus Gründen der “Einfachheit” werden bei vielen Installationen grundsätzlich erstmal alle Komponenten installiert – unabhängig davon, ob sie zum Einsatz kommen oder nicht. Besser wäre es jedoch, sich im Vorfeld darüber Gedanken zu machen, welche Komponenten tatsächlich gebraucht werden. Nicht zuletzt aus Sicherheitsgründen sollten nicht benötigte Komponenten von den Systemen entfernt werden – oder gar nicht erst installiert werden. Weiterhin verursacht auch die Administration (Wartung, Patchen, Rechtevergabe, …) einen erhöhten Arbeitsaufwand beim Administrator und stellt zudem eine zusätzlich Fehlerquelle dar. Nicht außen vor gelassen werden soll der Umstand, dass die Komponenten natürlich auch entsprechende Ressourcen auf der Hardware unnötig in Anspruch nehmen. Wie zuvor bereits erwähnt, lassen sich die Komponenten im Bedarfsfall auch problemlos nachinstallieren.
Als kleines Beispiel aus der Praxis heraus gegriffen, ist die installation der Komponente PolyBase. PolyBase selbst ist ein sehr interessantes Werkzeug, um auf externe Datenquellen zuzugreifen – aber die wenigsten Administratoren nutzen dieses Tool auch tatsächlich. Trotzdem findet sich diese Komponente heute bei einer Vielzahl von SQL Server Installationen wieder.
Zusammenfassend lässt sich sagen: installiert werden sollte nur das, was tatsächlich benötigt wird. Das
Zugegeben: Es klingt schon fast zu simpel für einen Tipp, doch gerade diese Empfehlung ist an Hand von Einblicken in dutzende produktiver Systeme entstanden.
Übrigens: Microsoft geht hier selbst mit gutem Beispiel voran und bietet die bekannten Reporting Services im SQL Server Setup gar nicht mehr an. Möchte man ganz bewusst eine SSRS-Instanz installieren, genügt ein kurzer Abstecher in das MS Download Center.
Im ersten Teil unserer dreiteiligen Serie zu den Häufige Fehler beim Einsatz von SQL Server Datenbanken, haben wir Euch wiederum fünf konkrete Ansatzpunkte an die Hand gegeben, um allein bei der Instanzkonfiguration schon einiges mehr an Performance, Stabilität und Sicherheit herauszuholen. Zum Teil sind es wirklich banale Themen, über die man doch gern mal wieder stolpert. Zum anderen kann man sich bereits mit kleinen Handgriffen die Arbeit respektive den Betrieb der SQL Server Datenbanken wesentlich erleichtern.
Share this article