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.
Im Fenster Installationstyp wählt man zwischen einer Neuinstallation und dem Hinzufügen einer weiteren Instanz zu einer bereits bestehenden Installation (vgl. Abbildung 6).
Im Fenster Produkt Key wird der Lizenzschlüssel eingegeben (vgl. Abbildung 7), im darauffolgenden Fenster werden die Lizenzbedingungen akzeptiert (vgl. Abbildung 8).
Ü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).
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.
Instanzkonfiguration
Ab diesem Schritt wird etwas detaillierter auf die Einstellungen eingegangen und Empfehlungen/Best Practices abgegeben:
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.
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.
Weiterführende Informationen:
- http://sql-articles.com/articles/general/sql-server-service-accounts/
- http://blogs.technet.com/b/canitpro/archive/2012/02/08/the-sql-guy-post-15-best-practices-for-using-sql-server-service-accounts.aspx
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
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:
- https://msdn.microsoft.com/de-de/library/ms180175(v=sql.120).aspx
- http://www.databasejournal.com/features/mssql/article.php/3302341/SQL-Server-and-Collation.htm
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.
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.
Authentifizierung
Serverkonfiguration
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
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.