CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

SQL Server installieren ist nicht gleich SQL Server installieren

Set-up-Routinen schenkt man oftmals nicht die nötige Aufmerksamkeit, die Ihnen gebührt. Unter Zeitdruck oder wegen zu viel Abstimmungsaufwand werden immer wieder Softwaresysteme installiert, ohne sich über die Folgen im Klaren zu sein. Der Weiter-Button ist schnell gedrückt und man folgt der Annahme, die Standardoptionen, die das System vorschlägt, müssten doch eigentlich passen. Dadurch werden Sicherheit, Performance und Stabilität nicht in dem Maße eingehalten, wie es die Praxis verlangt.

Bei welchen Schritten man bei der Standardinstallation von SQL Server einfach weiterklicken kann und wo es sich lohnt, benutzerdefinierte Einstellungen vorzunehmen, soll dieser Blogbeitrag im Folgenden beschreiben.

Installationsdialog

Abbildung 1 – 5 zeigen die grundlegenden Schritte für die Installation des SQL Servers. Hier müssen noch keine spezifischen Eingaben erfolgen.

Abbildung 1 SQL Server Installationsdialog

Abbildung 1: SQL Server Installationsdialog

Abbildung 2 SQL Server InstallationscenterAbbildung 2: SQL Server Installationscenter

Abbildung 3 Globale Regeln

Abbildung 3: Globale Regeln

Abbildung 4 Setupdateien installieren

Abbildung 4: Setupdateien installieren

Abbildung 5 Installationsregeln

Abbildung 5: Installationsregeln

Im Fenster Installationstyp wählt man zwischen einer Neuinstallation und dem Hinzufügen einer weiteren Instanz zu einer bereits bestehenden Installation (vgl. Abbildung 6).

Abbildung 6 Installationstyp

Abbildung 6: Installationstyp

Im Fenster Produkt Key wird der Lizenzschlüssel eingegeben (vgl. Abbildung 7), im darauffolgenden Fenster werden die Lizenzbedingungen akzeptiert (vgl. Abbildung 8).

Abbildung 7 Eingabe Produktschlüssel

Abbildung 7: Eingabe Produktschlüssel

Abbildung 8 Lizenzbedingungen

Abbildung 8: Lizenzbedingungen

Üblicherweise um die Database Engine Services (SQL), Analysis Services (SSAS) und Integration Services (SSIS) zu installieren, wird die SQL Server Funktionsinstallation ausgewählt (siehe Abbildung 9).

Abbildung 9: Setuprolle

Bei der Funktionsauswahl sollten (für Bissantz-spezifische Projekte) mindestens folgende Funktionen aktiviert werden (vgl. Abbildung 11):

  • Datenbank Engine: Enthält das Datenbankmodul (SQL), den Kerndienst zum Speichern, Verarbeiten und Sichern von Daten. Das Datenbankmodul ermöglicht den kontrollierten Zugriff auf Daten und eine schnelle Transaktionsverarbeitung sowie eine umfassende Unterstützung zur Beibehaltung einer hohen Verfügbarkeit.
  • Analysis Services: Enthält Analysis Services und Tools zur Unterstützung der analytischen Onlineverarbeitung (OLAP, Online Analytical Processing) und von Data Mining.
  • Integration Services: Enthält den Designer, die Laufzeit und Hilfsprogramme, mit denen Integration Services das Verschieben, Integrieren und Transformieren (ETL) von Daten zwischen Datenspeichern ermöglicht wird.
  • Verwaltungstools – Einfach: Enthält Management Studio-Unterstützung für das Datenbankmodul und SQL Server Express, das SQL Server-Befehlszeilenprogramm (SQLCMD), SQL Server PowerShell Provider und das Distributed Replay Administration Tool.
  • Verwaltungstools – Vollständig: Fügt der Standardinstallation der Verwaltungstools die folgenden Komponenten hinzu: Management Studio-Unterstützung für die Technologien Reporting Services, Analysis Services und Integration Services, SQL Server Profiler, Datenbankoptimierungsratgeber und SQL Server-Hilfsprogramm.

Abbildung 10 Funktionsauswahl

Abbildung 10: Funktionsauswahl

Instanzkonfiguration

Ab diesem Schritt wird etwas detaillierter auf die Einstellungen eingegangen und Empfehlungen/Best Practices abgegeben:

Abbildung 11 Konfiguration Instanz während des Setups

Abbildung 11: Konfiguration Instanz während des Setups

Wenn kein Name für die Instanz vergeben wird, „lauscht“ der SQL Server über den TCP Port 1433. Einer benannten Instanz wird beim Setup kein fester, sondern ein dynamischer Port zugewiesen, d. h. beim Start des Dienstes wird ein beliebiger verfügbarer Port verwendet. Wenn eine Verbindung zu einer benannten Instanz über eine Firewall geregelt ist, muss dort der entsprechende Port freigeschaltet werden. Daher empfiehlt es sich, einen festen Port zuzuweisen. Weitere Informationen zu verwendeten Ports und Konfigurieren der Windows-Firewall für den SQL Server-Zugriff sind nach folgendem Link zu finden: https://msdn.microsoft.com/de-de/library/cc646023.aspx

Zuweisen eines festen Ports

Die Zuweisung eines festen Ports für eine benannte Instanz kann durch den SQL Server Configuration Manager (SQLServerManager10.msc) vorgenommen werden. Wenn in der Dialogbox bei TCP Dynamic Ports eine 0 steht, „lauscht“ die Instanz über einen dynamischen Port. Die 0 kann gelöscht werden und im Feld TCP-Port ein fixer Port eingetragen werden (vgl. Abb. 12). Sollte dies nachträglich gemacht werden, muss der SQL-Serverdienst neu gestartet werden.

Abbildung 12: SQL Server Configuration Manager

Abbildung 12: SQL Server Configuration Manager

Weitere Informationen dazu sind zu finden unter:
https://msdn.microsoft.com/de-de/library/ms177440(v=sql.130).aspx

Dienstkonten

Währen der Installation wird man gefragt, unter welchem Dienstkonto das SQL Server-Datenbankmodul ausgeführt werden soll. Folgende Accounts sind nicht zu empfehlen:

  • Lokales System (Local System Account): Dieser Account hat Zugang (Administratorrechte) zu allen Ressourcen des Servers. Vor einigen Jahren gab es einen SQL-Wurm, welcher unter dieser Dienstkonteneinstellung dem Server hohen Schaden zufügen konnte. Der lokale
    Systemaccount sollte nach Möglichkeit vermieden werden.
  • Lokaler Dienst (Local User Account): Dieser Account hat keinen Zugang zu Netzwerkressourcen. Ein Zugriff auf den Server über das Netzwerk ist somit nicht möglich.
  • Lokales Konto (Local System Account): Ein lokales Konto hat den Nachteil, dass der SQL Server im Active Directory keine User auflösen kann.
  • Von MS bei der Installation vorgeschlagene Accounts: Diese können in der Regel verwendet werden. Allerdings kann es bei Spezialanforderungen (Kerberos-Authentifizierung, Clustering) zu Problemen kommen.

Die beste Empfehlung ist ein Domänen-Serviceaccount. Dieser kann dann individuell mit Rechten ausgestattet und verwaltet werden.

Abbildung 13 Auswahl Dienstkonten während des Setups

Abbildung 13: Auswahl Dienstkonten während des Setups

Weiterführende Informationen:

Wenn nachträglich ein anderer Kontoname für den Dienst vergeben werden soll, empfiehlt es sich das im Configuration Manager zu tun und nicht in den Diensten. Somit werden nicht nur Benutzername und Passwort, sondern auch Dienstprinzipalnamen (Service Principal Name, SPN) etc. geändert.

Sortierung/Collation

Abbildung 14 Installationsfenster Serverkonfiguration (Sortierung)

Abbildung 14: Installationsfenster Serverkonfiguration (Sortierung)

Die Sortierung verweist auf ein Regelwerk, welches definiert wie Daten sortiert und verglichen werden.
Dabei gibt es verschiedene Sortierungen, die am SQL Server eingestellt werden können:

  • Casesensitiv (AS): CI gibt keine Unterscheidung nach Groß-/Kleinschreibung an, bei CS erfolgt eine Unterscheidung.
  • Akzentsensitiv (AS): AI gibt keine Unterscheidung nach Akzent an. Bei AS erfolgt eine Unterscheidung.

Siehe auch:

Eine Empfehlung ist, die Sortierung caseinsensitiv und akzentsensitiv (Latin1_CI_AS) zu wählen, da dies einen guten Kompromiss zwischen Performance und Usability darstellt. Werden z. B. beim Datenabzug aus einer anderen Datenbank verschiedene Sortierungen verwendet, hat dies (negativen) Einfluss auf die Performance, da bei jedem Zugriff erst auf die richtige Sortierung „konvertiert“ werden muss.
Bei der in Abb. 15 stattfindenden Abfrage soll der Buchstabe ‚ß‘ gefiltert werden. Durch die Sortierung Latin1_General_CI_AI wird aber zusätzlich ‚ss‘ gefunden. Dadurch können Abfrageergebnisse verfälscht werden.

Abbildung 15 Verfälschung des Abfrageergebnisses durch Sortierung

Abbildung 15: Verfälschung des Abfrageergebnisses durch Sortierung

Neben der Verfälschung durch die Sortierung kann es auch zu Abfragen/Anweisungen kommen, die nicht vollständig ausgeführt werden können (vgl. Abb. 16). Hier soll ein Einfügevorgang in eine Spalte mit einer Datenbreite von eins ausgeführt werden. Dies führt zu einem Fehler, da durch die Sortierung neben dem ‚ß‘ auch ‚ss‘ gefunden wird und eingefügt werden soll.

Abbildung 16 Einfügeanweisung und Fehlermeldung

Abbildung 16: Einfügeanweisung und Fehlermeldung

Authentifizierung

Serverkonfiguration

Abbildung 17 Wahl der Authentifizierung während der Installation

Abbildung 17: Wahl der Authentifizierung während der Installation

In der Regel wird der Windows-Authentifizierungsmodus verwendet. Soll von einem Server außerhalb der Domäne oder z. B. von einem UNIX-Rechner aus zugegriffen werden, dann wird die SQL Server Authentifizierung benötigt. Der gemischte Modus ist aus sicherheitstechnischer Sicht etwas schwächer als der Windows-Authentifizierungsmodus, daher ist dieser Modus nur dann zu empfehlen, wenn beide oben beschriebenen Fälle benötigt werden.

Datenverzeichnisse

Abbildung 18 Reiter Datenverzeichnisse während des Installationdialogs

Abbildung 18: Reiter Datenverzeichnisse während des Installationdialogs

Es wird empfohlen, User-, Log-, Temp- und Backupdatenbanken auf jeweils separaten Volumes/Laufwerken zu verteilen. Im Verzeichnis des Benutzerdatenbankprotokolls werden z.B. die Transaktionen bis zum Abschluss gepuffert, um diese ggf. zurückzurollen. Hier finden in der Regel sequentielle Zugriffe statt. Das Zugriffsmuster im Datenbankverzeichnis unterscheidet sich meistens von dem des Benutzerdatenbankprotokolls, daher lohnt sich die Trennung.

Abbildung 19 Zusammenfassung

Abbildung 19: Zusammenfassung