News zu Microsoft SQL Server

Häufige Fehler beim Einsatz von SQL Server Datenbanken: Teil 1 – Instanzkonfiguration

Dieser DBA-Tipp ist der erste Teil einer kleinen Serie, welche sich detail­liert 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.

  • Teil 1: Instanzkonfiguration
  • Teil 2: Datenbankkonfiguration
  • Teil 3: Sicherheit von Instanzen

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:

1. PERFORMANCE – Probleme durch starre Prozessorzuordnung

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 virtua­li­sierten Umgebungen spielt das eine erheb­liche 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:

  1. Ein Prozessor oder Kern sollte niemals für Abfragen und I/O‑Aufgaben gleicher­maßen genutzt werden.
  2. Die manuelle Zuordnung deakti­viert ebenfalls den dynami­schen Wechsel eines SQL-Threads (Scheduler) von einem Prozessor zum anderen.

Werden diese beiden Tatsachen nunmehr in der manuellen CPU-Zuweisung nicht berück­sichtigt, kann es schnell zu folgenden Problemen kommen:

  • Die Überschätzung der benötigten CPU-Ressourcen führt zu einer Verschwendung von zum Teil kosten­in­ten­siven IT-Ressourcen (Host Power, Investitionen, IT Betrieb, etc.)
  • Die Unterschätzung der benötigten CPU-Ressourcen führt früher oder später zwangs­läufig zu Performanceproblemen und den damit verbun­denen nicht unerheb­lichen versteckten Kosten.

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 ausrei­chend 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 entspre­chende Algorithmen mit, die diese Arbeit selbst­ständig und zuver­lässig übernehmen. Und genau das ist auch unsere klare Empfehlung für diesen Punkt.

2. STABILITÄT – unnütze Trace Flags

Trace Flags verändern die Funktionsweise des SQL Servers an entschei­denden Stellen. Daher sind sie ab Werk (also durch Microsofts Installer) niemals automa­tisch 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 grund­le­genden Funktionen zu steuern, die teilweise tief in der Engine verborgen sind. Ein händi­sches 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:

  1. Verstehen: Vor dem Aktivieren sollte man sich die Zeit nehmen und die Beschreibung zumindest grund­legend studieren. Erst wenn man darin einen guten Grund erkennt, sollte man das Trace Flag auch setzen.
  2. Dokumentieren: Die Aktivierung des Trace Flag sollte auf eine solide Art und Weise vermerkt werden, idealer­weise mit einer Begründung, warum es aktiviert wird. Das beugt dem Vergessen vor und ist um so wichtiger, wenn man sich die Verantwortung für einen SQL Server mit anderen Personen teilt.

Ausgewählte Beispiele für überholte Trace Flags sind:

  • 1117 – all file grow
  • 3023 – backup checksum default
  • 4136 – no parameter sniffing
  • 6545 – CLR strict security
  • 8079 – soft-NUMA

Einige Beispiele für gefähr­liche Trace Flags sind:

  • 3042 – no pre-allocation for compressed backups
  • 3459 – no parallel redo
  • 8020 – working set unawareness

Ein beson­deres Beispiel für ein nicht existentes Trace Flag ist:

  • 2861 – zero cost plan capture

Diese Auflistung soll selbst­ver­ständlich die Trace Flags nicht pauschal verun­glimpfen. Sie soll vielmehr eine Empfehlung sein, die jewei­ligen Einstellungen nicht leicht­fertig zu setzen und sich außerdem über Sinn und Zweck eines Trace Flags absolut im Klaren zu sein.

3. NETZWERK – dynamische TCP/IP-Ports

Eine der unschönsten Konfigurationen eines SQL Servers entsteht bereits während der Installation. Und zwar die Verwendung dynami­scher 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 stati­schen Ports, ergeben sich zwei Vorteile:

  1. Der SQL-Datenverkehr zwischen der Instanz (oder dem Host) und den Clients kann nun auch durch eine Firewall geleitet werden, was zu grund­sätzlich zu einer erhöhten Sicherheit im Datenverkehr beiträgt. In einem unserer früheren Beiträge mit dem Titel “TCP/IP-Konfiguration und Probleme mit Firewalls im SQL-Server-Alltag” geben wir noch weitere Tipps und Informationen zu dieser Thematik.
  2. Man kann nun auch bei einer benannten Instanz auf den SQL Browser verzichten, da sich die Verbindungszeichenfolge nicht mehr ändert.

Folglich empfehlen wir bei diesem Punkt die Umstellung auf feste (statische) Ports. Das dürften sicherlich auch die Netzwerk-Admins begrüßen.

4. SICHERHEIT – Berechtigungs-Wildwuchs

Das folgende Thema ist simpel, aber wertvoll. Unter Windows-Admins ist eine Regel wohlbe­kannt: 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 jewei­ligen 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:

  • Was im Windows (oder Active Directory) die Benutzer sind, wird im SQL Server als “Login” (in der deutschen Ausführung: Anmeldung) bezeichnet
  • Was im Windows eine Gruppe ist, wird im SQL Server eine Server-Rolle genannt

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 bereit­ge­stellt hat. Server-Rollen können diffe­ren­ziert mit Berechtigungen ausge­stattet werden. Sicherlich macht das hier am Anfang ein wenig mehr Arbeit, sich entspre­chende 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 entspre­chende Aufgaben optimieren. Eine konse­quente Verwendung von Server-Rollen und deren sinnvolle Benennung trägt entscheidend zur Transparenz in den Systemen bei und erleichtert somit auch eine Systemdokumentation. 

5. EFFIZIENZ – ungenutzte Komponenten

Ein bereits bekannter Umstand ist, dass beim Setup eines SQL Servers diverse Komponenten für die Installation auch einzeln ausge­wählt werden können. Die wichtigsten Komponenten sind:

  • SQL Server Engine
  • Analysis Services
  • Integration Services

Vermutlich aus Gründen der “Einfachheit” werden bei vielen Installationen grund­sätzlich erstmal alle Komponenten instal­liert – 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 instal­liert werden. Weiterhin verur­sacht 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 entspre­chende 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 instal­lation der Komponente PolyBase. PolyBase selbst ist ein sehr inter­es­santes 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: instal­liert werden sollte nur das, was tatsächlich benötigt wird. Das 

  • reduziert Aufwand und Verantwortung beim DBA 
  • schont kosten­in­tensive Hardware-Ressourcen
  • minimiert das Sicherheitsrisiko

Zugegeben: Es klingt schon fast zu simpel für einen Tipp, doch gerade diese Empfehlung ist an Hand von Einblicken in dutzende produk­tiver 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 instal­lieren, genügt ein kurzer Abstecher in das MS Download Center.

Fazit

Im ersten Teil unserer dreitei­ligen 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 heraus­zu­holen. 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.

icon-arrow_right_medium-violet-blue.svg

Share this article

Share on facebook
Facebook 
Share on twitter
Twitter 
Share on linkedin
LinkedIn 
Share on xing
XING 
Share on whatsapp
WhatsApp 
Share on email
Email