Beschreibung des virtuellen SQL Server-Clientverbindungen

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 273673 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dieser Artikel beschreibt einige Grundlagen zu Microsoft SQL Virtual Server-Verbindungen.

Weitere Informationen

wichtig In diesem Abschnitt, Methode oder Aufgabe enthält Hinweise zum Ändern der Registrierung. Allerdings können schwerwiegende Probleme auftreten, wenn Sie die Registrierung falsch ändern. Stellen Sie daher sicher, dass Sie diese Schritte sorgfältig ausführen. Für zusätzlichen Schutz sichern Sie der Registrierung, bevor Sie ihn ändern. Anschließend können Sie die Registrierung wiederherstellen, wenn ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie im folgenden Artikel der Microsoft Knowledge Base:
322756Zum Sichern und Wiederherstellen der Registrierung in Windows


Virtuelle SQL Server-Clientverhalten

Microsoft Cluster Server (MSCS) bietet eine zuverlässige und stabile Plattform, die auf der Sie unternehmenswichtige SQL Server-Anwendungen erstellen können. Sie müssen nicht die meisten Serveranwendungen mit MSCS verwenden ändern. Allerdings Transaktion-basierte Anwendungen (z. B. Datenbank Server, wie z. B. Microsoft SQL Server) erfordern gewöhnlich zusätzliche Änderungen, wenn der Server ausfällt, Failover-Unterstützung ordnungsgemäß Verlust den Transaktionsintegrität verhindert. Entwickeln einer Clientanwendung zum Arbeiten mit MSCS ist relativ einfach. Sie müssen Anwendungen mit Wiederherstellung der Datenbank und Fehlerüberprüfung Bedenken entwerfen.

Auch ohne Verwendung von einem SQL Server-Cluster Server wird automatisch alle Datenbanken wiederhergestellt, beim Neustart des Servers. Um sicherzustellen, dass eine Datenbank in einem konsistenten Anwendungszustand Datenbanktransaktionen verwenden wiederhergestellt wird, so, dass in der Datenbank korrekt und in einem konsistenten Zustand Failover. Transaktionen, die bei einem Failover, unvollständig sind sollte ein Rollback, ausgeführt werden, während die Auswirkungen von alle Transaktionen beibehalten werden soll.

Bei einem Failover Clientanwendungen verlieren Ihre Verbindung zum SQL Server-Server und müssen Verbindung wiederherstellen, um die Verarbeitung fortzusetzen. Wenn die Clientverbindung an den Server statusfrei, ist (beispielsweise Anwendungen, die mithilfe von Microsoft Internetinformationsdienste [IIS] entwickelt werden sind statusfrei) der Client auf dem Server verbindet und fortgesetzt. Wenn dem Client und Server eine allgemeine Status (z. B. offene Cursor, Sitzungsvariablen, Transact­SQL-globale Variablen oder Daten in Tempdb) haben, ist Failover nicht an den Client transparent. In diesen Fällen können Sie die Clientanwendung den Benutzer informieren sollten entwerfen, dass die Verbindung entweder wurde verloren, zurücksetzen oder die Anwendung automatisch die Verbindung zum Server wiederherzustellen. Jede Transaktion, die nicht zugesichert wurde bei einem Failover wird Rollback ausgeführt.

Die Beschreibung der wie Clients mit Serverausfällen umzugehen ist standard für alle SQL Server-Client-Anwendung auch ohne Verwendung von Clustern und virtuellen Server. Das Prozess für die Fehlerüberprüfung ist eine Clientanwendung der Datenbank für einen Cluster recht ähnlich. Wenn der Cluster Failover beginnt, empfängt das Clientprogramm eine Fehlermeldung für die Datenbankverbindung. Die Fehlermeldungen aufgetreten hängen was versucht das Clientprogramm zu diesem Zeitpunkt tun.

Wenn eine Server mit SQL Server von Cluster- Administrator fehlgeschlagen ist, werden TCP Reset-Pakete nicht gesendet. Wenn der SQL Server-Prozess vom Betriebssystem (durch Kill.exe) beendet wird, werden die Reset-Pakete gesendet.

Dies kann die Client-Anwendung auswirken, wenn die Anwendung keinen Abfrage-Timeout-Parameter oder ein Abfragetimeout 0 (null) angegeben ist.

Wenn die Anwendung keinen Abfrage-Timeoutwert öffnen Verbindungen im Status ESTABLISHED bleibt nach ein Failover. Die Tatsache, dass die offenen Verbindungen nicht geschlossen werden und, dass keine weiteren TCP-Pakete von diesen Verbindungen gesendet werden bedeutet, dass diese Verbindungen vollständig im Leerlauf sind. Da das Failover keine TCP-Pakete an die Clientanwendung zurücksetzen gesendet haben, diese offenen Verbindungen warten die Ergebnisse der Abfrage unendlich (sofern eine unendliche Abfragetimeout), und verursachen möglicherweise die Verbindung reagiert (hängt).

Ändern Sie das Abfragetimeout zur Behebung dieses Problems aus Sicht einer Client-Anwendung in eine endliche Anzahl.

Virtuelle Datenbank Fehler Verhalten

Fällt ein virtueller Datenbankserver aus, wird eine Verbindung Verknüpfung schlug fehl Fehlermeldung an den wartenden Client zurückgegeben. Die Datenbank auf dem ausgefallenen Knoten des Clusters ist heruntergefahren und neu gestartet, auf demselben Knoten pro die Parameter in eingerichtet:

Start\Programs\Administrative Tools (Common)\Cluster Administrator\Group\Failover\Properties
				
Der Standardschwellenwert von Failover ist 10 Neustarts in einem Zeitraum von 6 Stunden vor ein Failover auf den verbleibenden Knoten. Jedoch starten Sie den SQL Server Schwellenwert ist, kann über die SQL Server-Eigenschaften auf der SQL Server-Cluster-Ressource überprüft, verfügt über einen Standardschwellenwert drei Neustarts auf die SQL Server in 900 Sekunden und wird standardmäßig die Gruppe wirkt neu. Wenn ein Client versucht, die Verbindung zum Server, während eine Datenbank wiederhergestellt werden, wird der Client erhält eine warten Datenbank Wiederherstellung Fehlermeldung und sollten nach einer kurzen Pause wiederholen.

Überlegungen zu SQL Server 6.5 und SQL Server 7.0

SQL Server 6.5 und SQL Server 7.0 fungieren genau wie im Abschnitt "Virtual Datenbank Fehler Verhalten" vorherige beschrieben.

Als virtueller Server SQL Server 7.0 führt SQL Server 7.0 unterstützt nur eine IP-Adresse aber möglicherweise Abhören zusätzliche Ports wie vom Kunden konfiguriert. Dies wird in dem Thema "Mehrere Listen auf TCP/IP Ports" in der folgenden Microsoft Knowledge Base beschrieben:
254321Info: Gruppierte SQL Server-Richtlinien, Kennwörter und Basic Warnungen

Microsoft SQL Server 2000-Überlegungen

SQL Server 2000 weist einige Unterschiede im Verhalten von SQL Server 6.5 und SQL Server 7.0-Versionen.

SQL Server 2000 Anschlussverwendung

Standardmäßig überwacht eine benannte Instanz auf einem dynamischen Port. Der Server mit einem Port startet auf Null (0) gesetzt zum ersten Mal der Server fordert eine freie Portnummer aus dem Betriebssystem und anschließend der Server über diesen Port überwacht. Der Server zeichnet diese in die Registrierung und verwendet dann jedes Mal denselben Anschluss.

Wenn ein Server für einen dynamischen Port Abhören konfiguriert ist und der Server zum Abhören dynamische Ports Programmstart ausfällt, wählt der Server einen anderen Anschluss.

Wenn Sie einen statischen Port entweder Setup oder nach der Installation konfiguriert mithilfe des Server-Netzwerk-Dienstprogramms wird zum Abhören von TCP/IP Wenn dieser Port verwendet wird.

Clients erkennen die Anschlussnummer Verbindung im Fall von einer benannten Instanz oder eine mit einer nicht standardmäßigen Portnummer.

Die Informationen über die Verbindung wird in den Cache "LastConnect" in diesem Registrierungsschlüssel geschrieben:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\supersocketnetlib\lastConnect
Finden Sie Einträge für jeden Server und die Methode, die Sie in der Registrierung Verbindung verwendet wurde.

Der Client versucht, die Verbindungsinformationen für jede Verbindung wiederverwenden, wenn es fehlschlägt und re-negotiates die neue Informationen. Dieser Fall kann sein, wenn die Anschlussnummer geändert hat, da jemand Sie geändert oder wenn war ein dynamischer Port, der aufgrund an einen Anschluss verwendet wird neu zugeordnet wurde.

Unterbrochene Verbindungen

Es gibt drei Möglichkeiten, die eine Verbindung unterbrochen werden kann:
  1. Der Server ausfällt, Beendigung des Prozesses durch abgebrochen (System-Serverprozess-ID [ Spid ] kill) oder eine Zugriffsverletzung () oder etwas bewirkt, dass das Betriebssystem oder der erforderliche Dienst nicht.
  2. Computer-Hardwarefehler oder Stromausfall.
  3. Herunterfahren des Servers.
Jedes dieser unterbrochen Verbindungen weisen unterschiedliche Verhaltensweisen, die auf dem Clientcomputer angezeigt.
  1. Im Fall eines Serverfehlers empfängt der Client eine Verbindung Fehlermeldung sofort unterbrochen. Sie können dieses Verhalten durch das Verbinden mit OSQL, eine lange Abfrage ausführen, simulieren und anschließend KILL zum Beenden von SQL Server-Prozess. Der Client mit einer ODBC-Fehlermeldung wird beendet.
  2. Ein Computer-Fehler ist komplizierter. Das Verhalten kann ändern, etwas basierend auf wie der Verlust der Verbindung erkannt wird.

    Wenn der Client ist in der Mitte des Informationen lesen, kann der Verlust der Verbindung da die Daten hält sofort erkannt.

    Wenn der Client nur Ergebnisse wartet, ist das Verhalten geringfügig. Das Verhalten hängt die Keep Alive-Konfiguration des Clientcomputers.

    Auf Microsoft Windows 2000-Keep-Alive wird von der Clientcode auf Verbindungsbasis festgelegt. Standardmäßig wird Keep Alive auf 30 Sekunden festgelegt. Dies bedeutet, das Wenn der Socket dies, innerhalb von 30 Sekunden und der Client erkannt wird erhält ein Fehlermeldung. Für Microsoft Windows NT 4.0 kann keine Keep Alive Grundlage pro Verbindung festgelegt werden. Keep Alive für den gesamten Computer beeinflussen daher alle Anwendungen auf dem Server festgelegt werden muss.

    Die Registrierungsschlüssel, auf die verwiesen wird sind, sind:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters KeepAliveTime\REG_DWORD 30000

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters KeepAliveInterval\REG_DWORD 1000
  3. Wenn Sie ein Herunterfahren des Servers initiieren, wartet der Server eine Weile für die Clients um fertig zu stellen. Wenn der Client noch den Server läuft bricht jedoch die Threads innerhalb des Servers ab. Die Threads gelöscht kann ebenfalls verschiedene Fehlermeldungen auf dem Client führen. Fehlermeldungen können eine Verbindung ist unterbrochen Fehler; in den meisten Fällen sehen Sie jedoch dieses Fehlermeldung:
    "Ein unbekannter Fehler ist aufgetreten, Verbindung möglicherweise wurden, beendet der Server".
    Der systemeigener Fehlercode von ODBC auf in diesem Fall Null (0) festgelegt ist, aber es als eine Fehlermeldung an dem Client zurückgegeben.

Informationsquellen

Weitere Informationen zum Verhalten des virtuellen SQL Server-Clients in SQL Server 2005 den folgenden Microsoft Developer Network (MSDN)-Website:
http://msdn2.microsoft.com/en-us/library/ms189585.aspx

Eigenschaften

Artikel-ID: 273673 - Geändert am: Dienstag, 4. Dezember 2007 - Version: 7.3
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 6.5 Enterprise Edition
  • Microsoft SQL Server 7.0 Enterprise Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Keywords: 
kbmt kbhowto kbsql2005cluster kbclientserver kbinfo KB273673 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 273673
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com