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 verschiedenen Versionsnummer 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
- Firewall-Port-Freigabe
- [[Zugriff_auf_SQL-Server_nicht_möglich#Protokolle_auf_dem_Server|TCP/IP-Protokoll auf Server aktivieren und einstellen]
- Port 1433 in der ODBC-Konfiguration festlegen (statt "Anschluss dynamisch bestimmen"-Option.
- Nach stundenlangen Versuche mit wachsender Begeisterung wurde die Firewall ausgeschaltet.
- Dabei stellte man fest, dass der Kontakt zum SQL-Server und zur Datenbank erfolgreich war, wenn
- die Firewall ausgeschaltet war und
- die Option "Anschluss dynamisch bestimmen" im ODBC-Treiber eingestellt war!
- Mit festem Port 1433 in der ODBC-Konfiguration wurde der SQL-Server nicht gefunden!
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 Nachinhein) einfach: Der SQL-Server antwortete gar nicht, sondern ein Überbleibsel einer früheren SQL-Server 2005 (!) Installation!
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
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 auf dynamischen Ports angesprochen werden konnte, nur auf dem 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 angegeben alte Verzeichnis zu löschen (vorher den Dienst zu zu beenden) und dann mit einem Tool die Registry aufzuräumen.
