Als Developer ist es oft praktisch oder sogar notwendig, dass man lokal auf seiner Entwicklungsumgebung nebst allen Entwickler-Tools auch eine SQL Server Instanz hat. Man macht sich aber nicht gross Gedanken zu Konfiguration, Ablage auf dem Filesystem und dergleichen – das Ding muss einfach laufen. So ging es zumindest mir bisher. Das Programm wurde standardmässig unter C:/Programme/… installiert, und auch die Pfade zu den Datenbanken und Logs liess ich auf den Standardwerten. Natürlich hatte ich (etwas ahnungslos) auch Features wie bspw. Analysis Services einfach mitinstalliert, ohne diese dann später jemals zu gebrauchen.
Upgraden oder nicht?
Da ich in einem neuen Projekt nun in die Situation kam, dass mein bisher installierter SQL Server 2012 nicht mehr ausreichte, stand ich vor folgender Entscheidung: ein Upgrade der bestehenden 2012-er Version oder eine weitere Instanz mit der 2014-er Version. Ich entschied mich für letzteres, was eigentlich auch problemlos funktionierte. Meine 2012-er Version war die “default instance” und die 2014-er einfach eine “named instance”. Dummerweise war das Projekt so konfiguriert, dass jeweils auf die Default Instanz verbunden wurde. Dies lässt sich bekanntlich im Nachhinein nicht mehr ändern, und so stand ich vor einer weiteren Entscheidung: das Projekt umkonfigurieren oder alle bestehenden SQL Server Instanzen deinstallieren und die gewünschte 2014-er Version als Default Instanz installieren. Da mir das Umkonfigurieren zu umständlich erschien und ich eigentlich keinen Bedarf mehr sah, die ältere Version vom SQL Server auf meinem Rechner zu behalten, entschied ich mich auch hier wieder für letzteres.
Beim Löschen ging ich nach der offiziellen Microsoft-Anleitung vor, d.h. Backups der wichtigen DBs gemacht, alle SQL Services gestoppt und die lokalen SQL Security Groups gelöscht. Die 2014-er Version liess sich auch problemlos deinstallieren. Bei der 2012-er Version hingegen bekam ich eine – aus meiner Sicht recht unlogische – Fehlermeldung:
“Hallo Microsoft, ich arbeite auf Windows 10 und konnte das Ding schliesslich auch installieren, also lasst es mich gefälligst auch wieder deinstallieren.” Doch egal was ich auch versuchte, ich erhielt immer dieselbe Fehlermeldung. Ich wurde also meine alte, unerwünschte Version nicht los.
Da auch unser DBA mit diesem Fehler nicht viel anfangen konnte, entschieden wir uns schlussendlich dazu, ein Upgrade der bestehenden 2012-er Version auf SQL Server 2014 zu machen, obwohl wir ehrlich gesagt lieber eine saubere Neuinstallation gemacht hätten. Als erstes musste gleich mal das neuste Service Pack (SP3) installiert werden. Danach sah es lange Zeit danach aus, dass das Upgrade erfolgreich durchgeführt wird, bis er dann irgendwann die anfangs gelöschten Security Groups verwenden wollte, diese aber logischerweise nicht fand. Mist, die hatte ich nach erfolgloser Deinstallation vergessen wieder anzulegen. Das Ergebnis war dann eine nur teilweise erfolgreich installierte neue Version, die nun in einem mehr oder weniger unbrauchbaren Zustand war.
Gut hatte ich ca. 2 Tage zuvor einen System-Wiederherstellungspunkt erstellt. Ich setzte also mein ganzes System zurück, führte obige Schritte nochmals durch (natürlich ohne das Löschen der SQL Security Groups) und konnte nun das Upgrade tatsächlich erfolgreich durchführen. Als ich allerdings eine Datenbank auf die neue Instanz deployen wollte, erhielt ich wieder einmal eine Fehlermeldung. Beim Upgrade wurden scheinbar die Berechtigungen auf das neu angelegte Verzeichnis mit den DB’s und Logs nicht richtig gesetzt. Nach einigem Probieren änderte ich schlussendlich das Standardverzeichnis für die DB’s und Logs auf ein anderes Verzeichnis (ausserhalb der SQL Server Installation!), und so konnte ich die Datenbank tatsächlich erfolgreich deployen. Nach einem Neustart des Computers konnten dann allerdings die SQL Services nicht mehr gestartet werden. So wie’s aussah, suchte er nun auch die Systemtabellen im neu angelegten Standardverzeichnis, fand sie aber natürlich nicht. Schlussendlich führte ich mithilfe der Installationsdatei nochmals ein Repair durch, wodurch die Systemtabellen nun im neuen Standardverzeichnis neu angelegt wurden. Oh Wunder, nun kann ich tatsächlich wieder normal mit meiner lokal installierten SQL Server Instanz arbeiten.
Fazit
Nebst einigen Stunden (unnötigem) Aufwand und erhöhtem Ausfall meiner ohnehin schon spärlich vorhandenen Kopfhaare habe ich zumindest auch ein paar neue Erkenntnisse gesammelt. Bei einem so mächtigen Tool wie dem SQL Server, das so tief im System verankert ist, macht es eben durchaus Sinn, bei der Installation ein paar Punkte zu beachten. Es lohnt sich auf jeden Fall, den SQL Server in einem eigenen Verzeichnis zu installieren (nicht unter C:/Programme/…), die Standardverzeichnisse für die DB’s und Logs auf ein Verzeichnis ausserhalb der Installation zu setzen und nur Features zu installieren, die man wirklich braucht. Die Datenbank-Spezialisten könnten hier bestimmt noch 1000 weitere Punkte aufzählen, doch für mich als Entwickler reicht dies erstmal aus… bis zum Upgrade auf SQL Server 2016 
.
