Zugriff auf SQL-Server nicht möglich wegen Überbleibsel
Inhaltsverzeichnis
1 Überbleibsel von alten Installationen
Besonders perfide können Fragmente von früheren SQL-Server-Installationen sein! Im konkreten Fall stellte sich die Situation wie folgt dar:
2 Vorgeschichte
Es wurde ein virtueller Server aus einem anderen, lauffähigen Server "geklont", also das Image des Servers für den neuen Server kopiert. Auf diesem Server war SQL-Server 2008© (=Version 10.0) installiert. Dieser wurde de-installiert, der Rechner mehrmals neu gestartet.
Dann wurde SQL-Server 2014 Express Edition© (=Version 12.0) installiert, und zwar nicht in der Standard-Instanz sondern in einer benannten Instanz.
Es wurde versucht, eine neue Datenbank durch Wiederherstellen eines Backups anzulegen. Dies scheiterte, weil die Backup-Datei nicht als solche erkannt wurde. Zudem gab es mehrere unerklärliche Fehlermeldung auf den Server. Da man annahm, dass die Backup-Datei (aus SQL-Server 2012) nicht kompatibel zu SQL-Server 2014 war, wurde SQL-Server 2014 wieder de-installiert.
- Diese Annahme stellte sich als falsch heraus, s.u.
Dann wurde SQL-Server 2012 Express Edition© (=Version 11.0) installiert, und zwar nicht in der Standard-Instanz sondern auch in einer benannten Instanz.
Es wurde wieder versucht, eine neue Datenbank durch wiederherstellen des Backups anzulegen. Dies scheiterte aber auch, weil:
- die Backup-Datei nicht ausgewählt werden konnte, der Pfad zu der Datei wurde im Wiederherstellungs-Dialog nicht angezeigt.
- die Backup-Datei nicht als solche erkannt wurde, genau wie zuvor! Nach Kopieren der Datei nach "C:\" konnte die Datei ausgewählt werden und die Wiederherstellung funktionierte!
Die oben angenommene Inkompatibilität war also keine, sondern ein Server-Problem: Dem angemeldeten User musste das volle Zugriffsrecht auf das Verzeichnis gegeben werden, in dem die Backup-Datei lag.
(Ob die oben angegebene Reihenfolge und die angegebenen Versionsnummern entscheidend sind, ist nicht bekannt)
So weit die Vorgeschichte, nun zum eigentlichen Problem:
3 Eigentliches Problem
Nachdem nun ein funktionsfähiger SQL-Server mit Datenbank zur Verfügung stand, wurde die Software auf einem Client-Rechner installiert und der ODBC-Eintrag dazu gemacht.
Beim Versuch zu dem SQL-Server Kontakt aufzunehmen, wurde nach einigen Sekunden angezeigt
Server existiert nicht oder Zugriff verweigert.
Nun folgten die üblichen Maßnahmen, also
- Port 1433 in der ODBC-Konfiguration festlegen (statt "Anschluss dynamisch bestimmen"-Option.
Nach stundenlangen Versuchen mit wachsender Begeisterung wurde die Firewall ausgeschaltet.
Dabei stellte man fest,
- Kontakt erfolgreich
- Der Kontakt zum SQL-Server und zur Datenbank erfolgreich war erfolgreich, wenn
- die Firewall ausgeschaltet war und
- die Option "Anschluss dynamisch bestimmen" im ODBC-Treiber eingestellt war!
- Kontakt nicht erfolgreich
- Mit festem Port 1433 in der ODBC-Konfiguration wurde der SQL-Server nicht gefunden!
Der Admin des Kunden wollte aber unbedingt mit festen Ports arbeiten, damit er die Firewall entsprechend auf diese Ports freischalten konnte.
Ein TCP-Protocol-Analyzer bewies, dass auf Port 1433 eine Anfrage vom Client gesendet wurde und vom Server mit "Reset" (also abweisen) beantwortet wurde! Warum machte der SQL-Server das?
Nun, die Antwort ist (im Nachhinein) einfach: Der SQL-Server antwortete gar nicht, sondern ein Überbleibsel einer früheren SQL-Server 2005 (!) Installation!
- Wie hat man das herausgefunden?
- Im Task-Manager gab es einen Task (SQL-Server Browser). Beim Klicken mit der rechten Maustaste und "Dateipfad öffnen" öffnete sich
C:\Program Files\Microsoft SQL Server\90
Es war also noch ein Programm (bzw. ein Dienst) aktiv,der den Port 1433 abhörte und die Anfrage dann ablehnte.
4 Ursache
Das bedeutete, dass eine frühere Installation nicht vollständig de-installiert wurde!
Dieses Programm und nicht der neu-installierte SQL-Server reagierte auf die Anfrage auf Port 1433 und versuchte, die Anfrage zu seiner SQL-Server-Instanz weiterzureichen. Die gab es aber gar nicht mehr, die Anfrage wurde also abgelehnt!
Das war auch die Erklärung dafür, dass der SQL-Server mit der Einstellung "Dynamische Ports" angesprochen werden konnte, aber auf dem fest eingestellten Port 1433 nicht.
5 Lösung
Die sauberste Lösung in diesem Fall war es, einen komplett neuen Server aufzubauen, ohne auf ein bestehendes Image zurückzugreifen.
Eine andere Möglichkeit wäre es, das angegebe alte Verzeichnis zu löschen (vorher den Prozess beenden!) und dann mit einem Tool die Registry aufzuräumen.
