Timeout tritt auf, wenn Sie in einer Umgebung mit mehreren Subnetzen eine Verbindung mit einem Always On Listener herstellen.
Dieser Artikel hilft Ihnen, das Problem zu beheben, das auftritt, wenn Sie eine Verbindung mit einem SQL Server Always On Verfügbarkeitsgruppenlistener in einer Umgebung mit mehreren Subnetzen herstellen.
Ursprüngliche Produktversion: SQL Server 2012 Developer, SQL Server 2012 Enterprise, SQL Server 2012 Express, SQL Server 2012 Standard, SQL Server 2012 Web, SQL Server 2012 Enterprise Core
Ursprüngliche KB-Nummer: 2792139
Symptome
Nachdem Sie den Verfügbarkeitsgruppenlistener für eine Always On Verfügbarkeitsgruppe in Microsoft SQL Server 2012 konfiguriert haben, können Sie den Listener möglicherweise nicht pingen oder von einer Anwendung aus eine Verbindung damit herstellen.
Wenn Sie beispielsweise versuchen, mithilfe von eine Verbindung mit einem Listener von SQL Server SQLCMD
herzustellen, tritt für die Verbindung ein Zeitüberschreitung auf. Darüber hinaus erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:
Sqlcmd: Fehler: Microsoft SQL Native Client: Anmeldetimeout abgelaufen.
Hinweis
Diese Symptome treten in der Regel zeitweilig auf oder beziehen sich auf ein Failover der Verfügbarkeitsgruppenressource.
Der folgende Screenshot zeigt ein Beispiel dafür, was geschieht, wenn Sie versuchen, den Listener für die Verfügbarkeit von zu pingen aglisten
. Der Screenshot zeigt auch eine erfolgreiche Verbindung mit SQL Server mithilfe des SQLCMD
Befehls, wenn Sie den Multisubnetzfailoverparameter -M
einschließen.
Hinweis
Sie können den SQLCMD
Befehl zusammen mit dem -M
Parameter verwenden, wie im Screenshot gezeigt, um eine Verbindung mit dem Listener herzustellen.
Ursache
Dieses Problem tritt auf, weil Ihre Anwendung entweder einen Legacydatenanbieter verwendet, der den neuen MultiSubnetFailover
Parameter nicht unterstützt, oder nicht für die Verwendung dieses Parameters konfiguriert ist.
Dieser Parameter wird in neueren Versionen des SQLClient-Treibers unterstützt, der im .NET Framework 4 und in höheren Versionen des .NET Framework enthalten ist, und wird wieder auf die .NET Framework 3.5 portiert.
Hinweis
Der PING
Befehl ist ein einfaches Konnektivitätstesttool, das den neuen Parameter nicht unterstützt.
Lösung
Sie können eine der folgenden Lösungen für Ihren Fall verwenden:
Um diese Situation zu beheben, wenn die Datenanbieter den
MultiSubNetFailover
Parameter unterstützen, fügen Sie denMultiSubNetFailover
Parameter ihrem Verbindungszeichenfolge hinzu, und legen Sie ihn auf true fest.Um diese Situation zu beheben, wenn Ihre Legacyclients die
MultiSubnetFailover
Eigenschaft nicht verwenden können, können Sie den Wert desRegisterAllProvidersIP
Listeners in 0 ändern. Führen Sie hierzu den folgenden Befehl über die Windows PowerShell Befehlszeilenschnittstelle aus:Import-Module FailoverClusters Get-ClusterResource <*Your listener name*>|Set-ClusterParameter RegisterAllProvidersIP 0
Hinweis
Nachdem Sie den RegisterAllProvidersIP
Wert auf 0 festgelegt haben, muss die aktuelle Online-IP-Adresse beim DNS-Server und die Offline-IP-Adresse beim DNS-Server registriert werden, wenn ein Failover auftritt. Dies kann zu einer Verbindungsverzögerung für das nächste Failover führen.
Weitere Informationen
Wenn Sie versuchen, eine Verbindung mit einem Listener herzustellen, der für mehr als ein Subnetz definiert ist, schlägt der Vorgang möglicherweise fehl, wenn der Clienttreiber versucht, eine Verbindung mithilfe einer der Offline-IP-Adressen des Listeners herzustellen.
Wenn ein Listener erstellt wird, wird für jedes eindeutige Subnetz, in dem ein Verfügbarkeitsgruppenreplikat gehostet wird, eine IP-Adresse festgelegt. Wenn beispielsweise ein Listener für eine Verfügbarkeitsgruppe mit Replikaten erstellt wird, die in zwei Subnetzen vorhanden sind, werden im Listener zwei IP-Adressen definiert. Eine Adresse wird von einer Anwendung verwendet, die eine Verbindung mit einer instance SQL Server in Subnetz 1 herstellen kann, und die andere Adresse wird verwendet, wenn eine Anwendung eine Verbindung mit einer instance SQL Server in Subnetz 2 herstellt.
Im Hintergrund erstellt der Listener eine Windows-Cluster-Clientzugriffspunktressource. Eine seiner Eigenschaften ist RegisterAllProvidersIP
. Wenn ein Listener erstellt wird, wird dieser wert auf 1 festgelegt, und alle IP-Adressen des Listeners werden im DNS-Server registriert. Diese Konfiguration verkürzt die Verbindungsdauer für Clients.
Da der DNS-Eintrag alle IP-Adressen enthält, muss ein Client, der versucht, eine Verbindung mit dem Listener herzustellen, wissen, wie er mit dieser Situation umgeht. Der MultiSubnetFailover
Parameter ermöglicht es dem Clienttreiber, Verbindungen parallel zu allen IP-Adressen des Listeners zu testen. Ohne den MultiSubnetFailover
Parameter versucht der Clienttreiber, sequenziell eine Verbindung mit allen IP-Adressen für den Listener herzustellen. Sequenzielle Verbindungen können zu langen Anmelde- oder Anmeldetimeouts führen.
Hinweis
Das in diesem Artikel erwähnte Problem betrifft auch SharePoint-Umgebungen, die für die Verwendung eines Always On sekundären schreibgeschützten Replikats der Verfügbarkeitsgruppe konfiguriert sind. Um dieses Problem zu beheben, führen Sie die folgenden Aktionen aus, die für Ihre Version von SharePoint gelten:
Für SharePoint 2007: Dies wird als Legacyanwendung klassifiziert. Daher kann SharePoint 2007 nicht für die Verwendung des
MultiSubnetFailover
Parameters konfiguriert werden. Stattdessen müssen Sie den befehl Windows PowerShell verwenden, der im Abschnitt Auflösung beschrieben wird.Für SharePoint 2010: Kumulative Updatepakete sind jetzt verfügbar, die Unterstützung für den
MultiSubnetFailover
Parameter hinzufügen. Weitere Informationen zu den Updatepaketen finden Sie im folgenden Artikel: