SQL Server 2016 auf Windows Server 2016 Core

Die Installation und der Betrieb von SQL Server auf einem Server System ohne grafische Benutzeroberfläche ist für viele Administratoren sehr ungewohnt und deshalb schrecken sie davor zurück. In der Praxis habe ich bisher nur sehr wenige Systeme gesehen, die als Server Core betrieben werden – was ich persönlich sehr schade finde, da Sie dadurch eine Reihe von Vorteilen haben:

  • Reduzieren der erforderlichen Softwarewartung (weniger Updates erforderlich)
  • Reduzieren der erforderlichen Verwaltung (weniger Komponenten erfordern weniger Pflegeaufwand)
  • Reduzieren der Angriffsfläche (jede Komponente bietet potentielle Angriffsfläche für Hacker –> umso weniger Komponenten, umso kleiner ist die Angriffsfläche)
  • Weniger Speicherplatz erforderlich. Bei einer Server Core-Installation sind 6579 MB Speicherplatz für die Installation ohne lokale Administrationstools und 8038 MB mit Administrationstools erforderlich. Die Angaben zum benötigten Speicherplatz beziehen sich auf die aktuelle Betaversion (Technical Preview 2, englisch) von Windows Server 2016.

Um Ihnen zu zeigen, wie einfach die Installation und der Betrieb eines solchen Systems ist, habe ich diesen Artikel geschrieben. Als Grundlage verwende ich die aktuellen Betaversionen von Windows Server 2016 (Technical Preview 2) und SQL Server 2016 (CTP2.1). Doch der Ablauf ist weitestgehend identisch auch mit älteren Versionen von Windows Server (ab 2008 R2) und SQL Server (ab 2012). Zu diesem Thema gibt es zwar bereits einige Artikel im Internet (wie z. B. https://sylvioh.wordpress.com/2015/05/05/windows-server-technical-preview-2-build-10074/), doch ich hoffe, dass ich Ihnen mit diesem Beitrag noch zusätzliche Informationen und Anleitung liefern kann. Vielleicht entschließen Sie sich ja künftig doch den einen oder anderen Server als Windows Server Core zu installieren. Hinweis: Als Grundlage für diesen Artikel habe ich SQL Server 2016 CTP 2.1 verwendet. Gerade habe ich gesehen, dass vor wenigen Stunden eine Version 2.2 mit einigen Verbesserungen und Optimierungen veröffentlicht wurde. Da ich nicht davon ausgehe, dass diese Änderungen Einfluss auf diesen Blogbeitrag haben werden, habe ich mich trotzdem zu einer Veröffentlichung entschlossen. Sollten Ihnen bei Ihren Tests Abweichungen zwischen der im meinem Betrag verwendeten Version 2.1 zu einer späteren Version auffallen, würde ich mich sehr über Feedback freuen.

Windows Server Core Konfiguration

Worin unterscheiden sich eigentlich die verschiedenen Ausprägungen eines Windows Server? Die Antwort darauf ist sehr einfach: Sie unterscheiden sich durch die Features, die für das entsprechende System aktiviert/deaktiviert sind. Die folgende Liste soll Ihnen eine kurze Übersicht dieser Konfigurationsoptionen/Features liefern. Die jeweils in runden Klammern angegebenen Features sind die für die entsprechende Ausprägung erforderlichen Features:

  • Server Core: Eingabeaufforderung, Windows PowerShell/Microsoft .NET
  • Server with local admin tools (Server-Gui-Mgmt-Infra): zusätzlich Server-Manager und Microsoft Management Console
  • Server Graphical Shell (Server-Gui-Mgmt-Infra, Server-Gui-Shell): zusätzlich Systemsteuerung, Systemsteuerungs-Applets, Windows-Explorer, Taskleiste, Infobereich, Internet Explorer, Integriertes Hilfesystem
  • Desktop User Experience (Server-Gui-Mgmt-Infra, Server-Gui-Shell, Desktop-Experience): zusätzliche Tools, die normalerweise nur auf dem Desktop zur Verfügung stehen, wie z. B. MediaPlayer, Audiorecorder, Zeichentabelle, Snipping Tool (vollständige Liste der Tools unter https://technet.microsoft.com/de-de/library/Dn609826.aspx) Diese Tools sind auf einem Server normalerweise nicht sinnvoll – Ausnahme könnte hier beispielsweise ein Terminalserver sein.

Hinweis: Der Texteditor (notepad), Registry Editor (Regedit) und einige andere Tools mit Benutzeroberfläche stehen Ihnen immer zur Verfügung, egal wie Sie den Server installiert haben. Für alle die ohne Benutzeroberfläche oder bestimmte Komponenten nicht leben können oder die SQL Server-Features nutzen wollen, die eine GUI benötigen, können diese natürlich auch auf einem Windows Server 2016 Core aktivieren. Dazu haben Sie mehrere Möglichkeiten:

  1. Vor der Installation: Anpassen des Images z. B. mit Hilfe des Windows Assessment and Deployment Kit (Windows ADK). In diesem Kit befindet sich der Windows System Image Manager (Windows SIM), mit dem Sie sich ein eigenes Installations-Image (ISO) entsprechend Ihren Anforderungen erstellen können.
  2. Nach der Installation (siehe)
    • PowerShell: Install-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell -Restart
    • Server Manager

Genauso wie Sie Features installieren können, lassen sie sich auch wieder deinstallieren:

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell -Restart

Die Basiskonfiguration eines Windows Server Core gestaltet sich für einen Administrator, der eine Benutzeroberfläche gewohnt ist, unter Umständen schwierig, da ihm die gewohnten Tools nicht mehr zur Verfügung stehen. Folgende Möglichkeiten der Konfiguration eines Windows Server Core stehen Ihnen zur Verfügung:

  • Kommandofenster (CMD.EXE): Wenn man die entsprechenden Befehle kennt, lässt sich auch ein Windows Server Core System mit Hilfe des Kommandofensters konfigurieren. Jedoch ist das doch sehr aufwendig, mit diesen, teilweise doch sehr unhandlichen Befehlen zu arbeiten. Eine kleine Übersicht solch wichtiger Befehle und deren Verwendung stellt Ihnen Microsoft in Books Online zur Verfügung: https://technet.microsoft.com/de-de/library/ee441257(v=ws.10).aspx Einige Änderungen am System, wie z. B. die Konfiguration von Updates lassen sich nur über Befehle des Kommandoprozessors nicht durchführen. Hierzu müssen Sie eine der weiteren Möglichkeiten nutzen.
  • PowerShell: Wer mit der Verwendung von PowerShell-Cmdlets vertraut ist, wird auch die Konfiguration eines Windows Server Core primär damit durchführen. Für eine Basiskonfiguration sind ca. zehn PowerShell-Cmdlets erforderlich, die auch für einen ungeübten Administrator leicht verwendet werden können. Doch auch für komplexere Aufgaben können Sie die PowerShell verwenden und wiederkehrende Tätigkeiten zu kleinen Skripten (*.ps1) zusammenfassen. Auf einem minimal installierten Windows Server 2016 Core (alle nicht benötigten Features deinstalliert) stehen Ihnen 487 Cmdlets (ohne zusätzliche Module zu nutzen) zur Verfügung: image
  • Server Konfiguration Tool (sconfig.cmd): Das von Microsoft auf jedem Windows Server zur Verfügung stehende Tool zur Basiskonfiguration erfüllt seinen Zweck und stellt viele für die Konfiguration eines Servers erforderlichen Funktionen zur Verfügung. Die Bedienung ist einfach und wird über die Eingabe der jeweiligen Zahl von dem Menüpunkt gesteuert. image
  • Corefig: Viel schöner geht es natürlich mit einer grafischen Benutzeroberfläche, wie z. B. dieses Tool es bereitstellt. Hiermit lassen sich alle wichtigen Einstellungen an einem Windows Server Core vornehmen und es funktioniert, wie Sie an dem folgenden Bild sehen, auch auf einem Windows Server 2016 Technical Preview 2. Da es sich aber um eine Version für Windows Server 2012 handelt, kann ich Ihnen nicht versprechen, dass auch alle Funktionen funktionieren. image
  • Server Manager (Remote): Einige betriebssystemnahe Aktionen lassen sich auch remote über einen Server Manager ausführen, der auf einem Windows Server standardmäßig immer zur Verfügung steht (sobald das Feature Server-Gui-Mgmt-Infra installiert ist). Diese Tools lassen sich jedoch auch auf einer Windows Workstation nachinstallieren – Voraussetzung dafür ist das Remote Server Administration Tool (RSAT), dass Microsoft kostenlos zum Download zur Verfügung stellt. Die aktuell zum Windows Server 2016 Technical Preview 2 erforderliche RSAT-Version steht bisher (bis zum Zeitpunkt des Erscheinens dieses Blog-Beitrags) nicht zur Verfügung. Wird aber bestimmt bis zur Veröffentlichung von Windows Server 2016 bereitgestellt werden. image

Eine Remote-Desktop-Verbindung ist zwar auch zu einem Windows Server Core möglich, jedoch sieht das genauso aus, als ob Sie sich direkt mit dem Server verbinden würden: image

Voraussetzungen für SQL Server-Installation auf Windows Server Core

Als wichtige Voraussetzung für die einen Windows Server Core ist natürlich die Installation von Windows Server als Core System. Bei Windows Server 2016 sollte dies eigentlich kein Problem darstellen, da standardmäßig der Server immer als Windows Server Core installiert wird. Der einzige Unterschied bei der Auswahl der Optionen für die Installation ist, dass Sie bestimmen können, ob Sie auch die administrativen Tools gleich mit installieren wollen. image Hinweis: 512 MB Arbeitsspeicher für einen solchen Server sind übrigens nicht ausreichend. Damit lässt sich der Server nicht installieren. Laut Dokumentation von Microsoft sind folgende Komponenten für die Installation von SQL Server auf einem Windows Server Core System erforderlich.

  • Windows PowerShell 2.0
  • Windows .NET Framework 3.5 oder höher
  • Windows .NET Framework 4.0 oder höher

Nachdem Windows Server 2016 bereits das Windows .NET Framework 4.6 standardmäßig installiert hat, sind nur die beiden anderen Features noch zu installieren. Sollten Sie dies vor dem Aufruf des SQL Server-Setup-Programms vergessen haben, werden Sie ungefähr in der Mitte der Installation durch den Assistenten mit einer entsprechenden Fehlermeldung darauf hingewiesen. image Zur Installation der o. g. Komponenten können Sie entweder den Server Manager (steht nur zur Verfügung, wenn Sie die Installation mit administrativen Tools ausgewählt haben): image Das folgende Bild habe ich leicht angepasst, so dass beide noch zu installierende Komponenten sichtbar werden. image Da das .NET Framework 3.5 von einer Standardinstallation von Windows Server ab 2012 komplett entfernt wurde, müssen Sie bei der Installation zusätzlich noch den Pfad angeben, auf dem sich das Windows Server-Installationsmedium befindet. image oder PowerShell verwenden: Install-WindowsFeature -Name NET-Framework-Features, NET-Framework-Core, PowerShell-V2 -source „d:\sources\sxs“ image Sicherlich der einfachere Weg! Wenn der Server ausschließlich als SQL Server verwendet werden soll, müssen somit folgende Windows Features aktiv sein: Get-WindowsFeature | Where-Object {$PSItem.installstate -eq ‚installed‘ } image Hinweis: In der Liste auf dem vorherigen Bild sind nun einige Features aufgeführt, die nicht als Voraussetzung für die SQL Server-Installation angegeben waren. Das hängt somit zusammen, dass sich die „File and Storage Services“ als Feature nicht deaktivieren lassen und der „WoW64 Support“ eine zwingende Voraussetzung ist (ohne dieses Feature lässt sich das Setup-Programm nicht startet). Für den Betrieb von SQL Server-Datenbankmodul ist der WoW64 Support nicht erforderlich. Trotzdem würde ich Ihnen empfehlen dieses Feature nicht zu entfernen, da es auch bei SQL Server Updates benötigt wird. Alle anderen Features können Sie deinstallieren und sogar aus der Installation entfernen: Get-WindowsFeature | Where-Object {$PSItem.installstate -ne ‚installed‘ } | Uninstall-WindowsFeature –Remove image Hinweis: Das Entfernen der Features spart im ersten Moment Speicherplatz. Langfristig erhöht dieses Vorgehen jedoch auch die Sicherheit des Systems, denn Features die nicht verfügbar sind, können auch durch einen potentiellen Hacker nicht verwendet werden. Außerdem werden auch Features durch Windows Update aktualisiert, wenn sie verfügbar sind. Sind sie jedoch aus dem System entfernt, findet auch keine Aktualisierung mehr statt.

SQL Server Installation

Bevor Sie mit dem SQL Server 2016 herumexperimentieren können, müssen Sie ihn erst einmal haben: Registrieren und Download von SQL Server 2016 CTP-2 (Evaluation Version, 180 days) bzw. direkten Download: – SQLServer2016CTP2-x64-ENU.boxSQLServer2016CTP2-x64-ENU.exe Nachdem auf einem Windows Server Core-System keine Benutzeroberfläche zur Verfügung steht, können Sie diese entweder vor der Installation aktivieren oder Sie müssen sich andere Wege für die Installation suchen. Zur SQL Server-Installation stehen Ihnen auch bei einer Installation auf einem Windows Server Core drei unterschiedliche Wege zur Verfügung. Jeder dieser Wege hat Vor- und Nachteile:

  • Configuration file: einfach zu verwenden und automatisierbar.
  • Kommandozeile: die Verwendung ist komplex und oft entstehen sehr lange Befehlszeilen. Zur Vereinfachung sollten Sie die Befehlszeile in eine Textdatei kopieren (sqlinstall.cmd) und dort mit dem Texteditor (Notepad) bearbeiten.
  • Setup Assistent: einfach zu verwenden, jedoch keine Möglichkeit der Automatisierung. Außerdem können Sie den Setup Assistenten auf einem Windows Server Core-System nur verwenden, wenn Sie spezielle Parameter beim Aufruf verwenden.

Diese Wege sind miteinander kombinierbar – so können Sie beispielsweise eine Standardkonfiguration mit dem Configuration file festlegen, Passwörter zusätzlich über die Kommandozeile übergeben und schlussendlich den Setup-Assistenten verwenden, um die Feineinstellung für die jeweilige Installation vorzunehmen. Die Möglichkeit der Verwendung der Kommandozeile und die Konfigurationsdatei können Sie zusätzlich noch durch den Einsatz von PowerShell optimieren.

Ich persönlich versuche in Kundenumgebungen ausschließlich mit Konfigurationsdatei und Kommandozeile in Verbindung mit PowerShell zu arbeiten. Dies ermöglich mir eine SQL Server-Installation/-Konfiguration vollautomatisch (ohne Eingriff durch den Benutzer) durchzuführen. Entsprechend der Anforderungen des Kunden können das mehr als fünfzig Einstellungen und Optimierungen bei der Konfiguration an einem SQL Server sein. Möchten Sie mehr darüber erfahren, sprechen Sie mich bitte direkt an.

Nachdem Ihnen jedoch kein File Explorer zum Doppelklick auf das Setup-Programm zur Verfügung steht, müssen Sie das Setup über die Kommandozeile aufrufen.

SQL Server Funktionen

Schwerpunkt dieses Beitrags ist das SQL Server-Datenbankmodul. Jedoch auch andere Features des SQL Server lassen sich auf einem Windows Server Core-System installieren:

  • Datenbank Engine
    • SQL Server Replikation
    • Volltextsuche
  • Analysis Services
  • Integration Services
  • Client Tools Connectivity
  • SQL Client Connectivity SDK

Wer andere als die genannten Features bei der Installation aktiviert, wird mit einer entsprechenden Fehlermeldung darauf hingewiesen: image Die einzige Funktion, die sich trotzdem installieren lässt, obwohl sie nicht in der Fehlermeldung mit aufgelistet ist, ist „Polybase Query Service for External Data“. Dieser in SQL Server 2016 neue Service erfordert jedoch noch eine zusätzliche Komponente „Oracle JRE“. image image Der in der Fehlermeldung angegebene Microsoft-Link leitet automatisch auf eine Oracle-Seite http://www.oracle.com/technetwork/java/javase/downloads/index.html zum Download der Komponente weiter. image Ich habe diese Komponente auf meinen Testsystem nicht aktiviert, so dass ich auch nicht weiß, ob sie sich so einfach installieren lassen wird.

Konfigurationsdatei

Mit einer Konfigurationsdatei haben Sie einerseits die höchste Flexibilität und andererseits haben Sie automatisch auch eine Dokumentation der Installation. Ich habe mir beispielsweise in Kundenumgebungen angewöhnt, die bei der SQL Server-Installation verwendete Konfigurationsdatei auf einem zentralen Verzeichnis abzulegen. Dies hat den Vorteil, dass Sie auch nachträglich noch feststellen können, was wie auf dem Server installiert wurde. Der Aufbau der Konfigurationsdatei entspricht einer Windows INI-Datei und ist dadurch leicht z. B. mit einem Texteditor zu editieren. Um eine solche Datei zu erstellen, können Sie entweder das Beispiel aus diesem Blog verwenden oder sich durch den Setup-Assistenten (beispielsweise auf einem anderen System) eine Konfigurationsdatei generieren lassen. Dazu führen Sie das Setup mit dem Assistenten wie bereits vorher beschrieben durch, bis Sie zu folgenden Dialog kommen.

image

In diesem Dialog wird die für die Installation verwendete Konfigurationsdatei angegeben. Den Pfad können Sie nun direkt aus dem Dialog kopieren, die Datei mit einem Editor öffnen und die Installation mit „Cancel“ abbrechen. Der Aufbau der Datei ist ganz einfach. Es gibt nur einen Hauptbereich (Options) und die Parameter werden darunter zeilenweise angeordnet:

[OPTIONS]
ACTION="Install"
FEATURES=SQLENGINE
INSTANCENAME="MSSQLSERVER"
INSTANCEID="MSSQLSERVER"
SQLSVCACCOUNT="<DomainName\UserName>"
SQLSYSADMINACCOUNTS="<DomainName\UserName>"
IAcceptSQLServerLicenseTerms="True"

Wenn Sie versuchen die Datei manuell aufgrund der Hilfe aufzubauen, sollten Sie beachten, dass es Parameter gibt, die zwingend erforderlich sind, und optionale Parameter. Für nicht angegebene optionale Parameter wird durch das Setup-Programm ein Standardwert verwendet. Welche Parameter erforderlich sind, ist abhängig von den ausgewählten Features. Fehlt ein erforderlicher Parameter, so wird eine entsprechende Fehlermeldung ausgegeben und das Setup-Programm beendet. image Leider wird immer nur darauf hingewiesen, welcher als nächster erforderliche Parameter fehlt. Fehlen also mehrere erforderliche Parameter, müssen Sie das Programm so oft aufrufen, bis Sie alle Parameter zusammen haben –> lästig. Die Fehlermeldung bei älteren SQL Server-Versionen war meiner Meinung nach auch etwas besser lesbar. Einfacher ist es da schon, wenn Sie die Konfigurationsdatei erst mit dem Setup-Assistenten erstellen und anschließend diese zur Installation von mehreren Systemen verwenden. Den Aufwand, dieses Verfahren für ein einzelnes System zu verwenden, ist sicherlich zu hoch. Doch wenn Sie mehrere SQL Server in Ihrem Unternehmen betreiben, macht sich dieses Vorgehen schnell bezahlt.

Der Aufruf des Setup-Programms unter Verwendung einer Konfigurationsdatei sieht dann wie folgt aus:

Setup.exe /QS /SQLSVCPASSWORD=“<StrongPassword>“ /ConfigurationFile=MyConfigurationFile.INI

Kommandozeile

Die Installation mit Hilfe einer Kommandozeile ist schwierig und fehleranfällig. Da eine SQL Server-Installation aus sehr vielen Optionen bestehen kann, würde ich Ihnen eher davon abraten, ausschließlich mit der Kommandozeile zu arbeiten. Als Ergänzung zu anderen Installationsmöglichkeiten z. B. zur Übergabe von Passworten ist sie natürlich sehr gut geeignet.

Setup.exe /qs /ACTION=Install /FEATURES=SQLEngine /INSTANCENAME=MSSQLSERVER /SQLSVCACCOUNT="<DomainName\UserName>" /SQLSVCPASSWORD="<StrongPassword>" /SQLSYSADMINACCOUNTS="<DomainName\UserName>" /AGTSVCACCOUNT="NT AUTHORITY\Network Service" /IACCEPTSQLSERVERLICENSETERMS

Eine Beschreibung aller Parameter finden Sie unter https://msdn.microsoft.com/en-us/library/ms144259.aspx.

Setup-Assistent

Der SQL Server Setup-Assistent ist sicherlich für einen Administrator, der vorher nur wenig ohne Benutzerfläche gearbeitet hat, der leichteste Weg. Jedoch müssen Sie auch hier zwei Parameter angeben, damit das Setup gestartet werden kann:

  • /UIMODE=EnableUIOnServerCore : Aktiviert den Assistenten auf einem Windows Server Core
  • /Action=Install : Dieser Parameter schaltet den Install-Modus im Assistenten frei. (Ich bin mir nicht ganz sicher, ob der auch bereits bei früheren Versionen von SQL Server erforderlich war.)

Ohne diese Parameter ist eine Installation mit dem Setup-Assistenten auf einem Windows Server Core-System nicht möglich. Somit sieht der Aufruf im Kommandofenster so aus: setup /UIMODE=EnableUIOnServerCore /Action=Install image Die Warnung dürfen Sie ignorieren und, nachdem der Assistent gestartet wurde, die Installation ganz wie gewohnt Schritt für Schritt durchführen. Einige Dialoge habe ich besonders hervorgehoben. Dabei handelt es sich um solche Schritte, bei denen sich die Installation auf einem Windows Server ohne Benutzeroberfläche zu einem mit Benutzeroberfläche unterscheidet. Die meisten Dialoge sind mit denen des Setup-Assistenten von SQL Server 2012/2014 auch identisch. Nur ganz wenige Dialoge unterscheiden sich. image image image image image image image Die Option „All Features with Defaults“ funktioniert bei einer Installation auf Windows Server Core nicht. image Bitte beachten Sie den Hinweis weiter oben in diesem Beitrag, welche Features auf einem Windows Server Core-System unterstützt werden. image image image image image Microsoft hat es endlich verstanden, dass sie nicht nur dokumentierte Best Practices an ihre Kunden weitergeben, sondern eine diese Empfehlungen hat nun auch endlich Einzug in den Setup-Assistenten gehalten, wie Sie am folgenden Dialog sehen („Number of Temp DB files“). image image image image image image image image

Betrieb/Administration

Der Betrieb eines Windows Server Core-Systems ist bereits in Books Online von Microsoft erklärt und dies ist ja auch nicht der Inhalt dieses Beitrags. Sondern ich möchte Ihnen hier zeigen, wie Sie einen SQL Server auf einem solchen System administrieren können. Die bisher gewohnte Administration über Remote Desktop oder dem SQL Server Management Studio direkt auf dem Server steht Ihnen nun nicht mehr zur Verfügung. Ich möchte die Administration auch in zwei getrennten Anwendungsfällen heraus betrachten:

  1. tägliche Wartungsarbeiten
  2. kritische Systemzustände beheben
Tägliche Wartungsarbeiten

Aufgaben wie Konfiguration der SQL Server Instanz oder Einrichten/Konfigurieren von Datenbanken können Sie wie gewohnt mit dem SQL Server Management Studio durchführen. Dazu ist es jedoch erforderlich, dass Sie dieses Programm auf einer Workstation oder auf einem Server mit Benutzeroberfläche installieren. Nach dem Start von SQL Server Management Studio können Sie sich wie gewohnt mit dem SQL Server verbinden. Sie müssen jedoch den DNS-Namen[\Instanznamen] verwenden („.“ oder „localhost“ gehen natürlich nicht mehr). image Vorteil ist natürlich, dass Sie nicht zum Server laufen müssen, um sich über die Konsole anzumelden oder erst eine Remote Desktop-Verbindung aufbauen müssen. Ich empfehle Ihnen immer die neueste Version von SQL Server Management Studio zu verwenden (wenn Sie mehrere verschiedene Versionen von SQL Server im Einsatz haben) bzw. die zu Ihrem SQL Server passende Version des SQL Server Management Studio. Außerdem würde ich davon abraten das Management Studio der SQL Server Express-Edition zu verwenden. Diese ist limitiert und stellt somit nicht den erforderlichen Funktionsumfang zum Betrieb von SQL Server zur Verfügung. Lizenzrechtlich sieht es folgendermaßen aus:

Management tools and other software identified as additional or supplemental software—such as product documentation, client connectivity tools, software add-ins, and Software Development Kits (SDKs)—can generally be distributed and run on any number of devices for use with a licensed instance of SQL Server software. Refer to the Volume Licensing PUR for a list of additional software components provided with SQL Server 2014. (Quelle: http://go.microsoft.com/fwlink/?LinkId=230678)

Wer auf einem Windows Server Core trotzdem nicht auf eine Oberfläche zum Ausführen von SQL Befehlen verzichten möchte, kann sich so etwas immer noch selbst basteln z. B. mit einer WinForms-Anwendung, die auch auf einem Windows Server Core ausführbar ist, wenn Sie bei der Softwareentwicklung ein paar Punkt beachten (z. B. nur solche Komponenten verwenden, die auf einem solchen Server auch unterstützt werden.

Kritische Systemzustände

Beim Auftreten von Systemzuständen am SQL Server, die Sie remote mit dem SQL Server Management Studio nicht beheben können (was sehr selten ist), ist es erforderlich, dass Sie sich lokal am Server anmelden und dann sind Sie gezwungen Kommandozeilen-Tools zu verwenden. Folgende Werkzeuge stehen Ihnen für die Administration zur Verfügung:

SQLCMD

SQLCMD ist ein altbekanntes Tool, dass bereits schon mit SQL Server 2005 zur Verfügung stand und sich seitdem auch nicht wirklich weiterentwickelt hat. Doch das Tool ist ausreichend, um Befehle und Abfragen an den SQL Server zu senden. Seit SQL Server 2014 hat sich jedoch der Pfad geändert, auf dem dieses Tool installiert ist: C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn Hinweis: Dieses Tool ist natürlich nur dann verfügbar, wenn Sie das SQL Server-Feature „Client Tools Connectivity“ bei der Installation mit auswählen. Vor SQL Server 2014 befand sich das Tool im Verzeichnis C:\Program Files\Microsoft SQL Server\110\Tools\Binn. und war ein Standardprogramm bei jeder Installation des SQL Server-Datenbankmoduls. Da es für das Tool keine Oberfläche gibt, empfehle ich Ihnen den Umgang mit dem Tool und den Parametern erst auf einem Testsystem zu probieren, bevor Sie dies in einem Produktionssystem verwenden. Eine Übersicht der umfangreichen Parameter erhalten Sie, wenn Sie das Tool mit dem Parameter –? aufrufen: image Ein Standardaufruf sieht beispielsweise folgendermaßen auf: SQLCMD.EXE -S win2016sql02 -E -d master -Q „Select name from sys.databases“ image Meine Empfehlung auch hier ist, sich mit dem Notepad eine entsprechende Kommandodatei anzulegen und die im Windows-Verzeichnis zu speichern. Dann lassen sich auch komplexe Befehle ohne große Suche nach dem entsprechenden Tool und den erforderlichen Parametern ausführen. image

PowerShell

Zum Zugriff mit PowerShell auf einen SQL Server habe ich bereits vor einiger Zeit einen anderen Artikel geschrieben. Viele der darin aufgezeigten Möglichkeiten sind auch auf einem Windows Server Core einsetzbar. Im Folgenden werde ich nur auf einige dieser in dem vorherigen Beitrag beschriebenen Möglichkeiten eingehen und Unterschiede explizit hervorheben. Beginnen möchte ich mit der Verwendung des SQL Server-PowerShell-Modul (SQLPS).

SQLPS

Aus irgendeinem mir unbekannten Grund, wird der Pfad für das SQL Server-PowerShell-Modul bei der Installation nicht in die dafür vorgesehene Umgebungsvariable PSModulePath mit eingetragen (vielleicht ist das auch nur ein Bug in der CTP 2.0). Dadurch ist das entsprechende Modul in der PowerShell nicht direkt verfügbar und Sie müssen den Pfad zur Hand haben, um das Modul aufzurufen: import-module „C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell\Modules\SQLPS\sqlps.psd1“ -DisableNameChecking image Das ist natürlich sehr umständlich. Leichter wird es, wenn Sie das Verzeichnis zur Umgebungsvariable PSModulePath mit hinzufügen. Die einfache Möglichkeit besteht darin den Pfad an die Umgebungsvariable einfach anzufügen $env:PSModulePath += „;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell\Modules\“ Dies ist natürlich nur temporär und steht nach einem Neustart der PowerShell nicht mehr zur Verfügung. Wenn Sie die Variable permanent ändern wollen, müssen Sie wie folgt vorgehen:

$p = [Environment]::GetEnvironmentVariable("PSModulePath")
$p += ";C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell\Modules\"
[Environment]::SetEnvironmentVariable("PSModulePath", $p, [EnvironmentvariableTarget]::User)

Sobald Sie das Module geladen haben, steht Ihnen der SQL Server-PSDrive (SQLServer:\) zur Verfügung, den Sie wie einen Verzeichnisbaum durch-browsen können image Mit den zur Verfügung stehenden Eigenschaften und Methoden der Objekte von SQL Server-PSDrive lässt sich jedoch noch viel mehr anfangen. Im folgenden Beispiel führe ich eine Abfrage über die Master-Datenbank aus: image oder lege eine neue Datenbank an: image Eine vollständige Übersicht aller Eigenschaften und Methoden eines Objekts erhalten Sie, wenn Sie sich die Member eines Objekts (auf dem folgende Bild der vorher angelegten Datenbank) ausgeben: image Damit lässt sich nun schon eine ganze Menge anfangen. Zusätzlich stellt das SQL Server-PowerShell-Modul jedoch auch noch eigene CmdLets zur Arbeit mit dem SQL Server 2016 bereit: image Hierbei fällt nun auf, dass nur ein neues CmdLets in SQL Server 2016 hinzugekommen ist: Save-SQLMigrationReport Auch wenn viele dieser CmdLets für die Arbeit mit SQL Server während eines kritischen Betriebszustandes sicherlich von Bedeutung sein könnten, gibt es ein CmdLet, das besonders wichtig ist: Invoke-Sqlcmd. Mit diesem CmdLet können Sie, wie bereits mit dem SQLCMD-Befehl TSQL-Abfragen  ausführen und somit kritische Betriebszustände beseitigen. Ein Beispiel dafür:

Invoke-Sqlcmd -Query "Select database_id,Name from sys.databases;" –ServerInstance "win2016sql02"

Übrigens, die in diesem Kapitel vorgestellten Tools können Sie natürlich nicht nur auf einem Server Core verwenden, sondern sie arbeiten genauso auf Systemen mit Benutzeroberfläche!

Schlussfolgerung

Die Installation und der Betrieb von SQL Server 2016 (Community Preview 2) auf einem Windows Server Core-System unterscheidet sich nur geringfügig von vorherigen Versionen. Ich hoffe dieser Artikel hilft Ihnen die Scheu vor einem Core-System abzulegen und einfach selbst damit zu experimentieren. Insofern Sie Remote Tools von einem anderen System aus verwenden, ist die Umgewöhnung nicht allzu groß. Für sehr selten auftretende kritische Betriebszustände, für die es zwingend erforderlich ist, direkt am System zu arbeiten, bietet Ihnen dieser Blogbeitrag hoffentlich eine Hilfestellung, um die Probleme auf dem System zu beseitigen. Sollten Sie wirklich nicht mehr weiterkommen, dürfen Sie mich natürlich gerne ansprechen.

Advertisements
Über

Die IT-Welt wird immer komplexer und zwischen den einzelnen Komponenten gibt es immer mehr Abhängigkeiten. Nachdem ich durch meine tägliche Arbeit immer wieder vor der Herausforderung stehe, komplexe Probleme zu lösen, möchte ich diese Seite dafür verwenden, Euch den einen oder anderen Tipp zu geben, wenn Ihr vor ähnlichen Aufgabenstellungen steht.

Veröffentlicht in Core, PowerShell, SQL Server, Windows Server

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: