Freigeben über

Behandeln von Verbindungsproblemen in einem dedizierten SQL-Pool

Gilt für: Azure Synapse Analytics

Konnektivitätsprobleme, die in einem dedizierten SQL-Pool auftreten, können verschiedene Ursachen haben. Dieser Artikel enthält Tools und Methoden, mit denen Sie die am häufigsten auftretenden Konnektivitätsprobleme beheben können.

Prüfliste für die anfängliche Konnektivität

In der folgenden Liste werden häufig übersehene Gründe für Konnektivitätsprobleme in einem dedizierten SQL-Pool beschrieben. Überprüfen Sie die Liste, um zu sehen, wie Sie die Probleme umgehen können.

Taskbeschreibung Problemumgehung
Durchführen einer Prüfung auf Ausfälle von Azure-Diensten Überprüfen Sie das Microsoft Azure-Dienstdashboard , um festzustellen, ob bekannte Probleme auftreten.
Überprüfen der Verfügbarkeit des Diensts Wechseln Sie im Azure-Portal zum dedizierten SQL-Pool, mit dem Sie eine Verbindung herstellen möchten, und wählen Sie "Diagnostizieren und Lösen von Problemen" im linken Bereich aus, um die Dienstverfügbarkeit zu überprüfen.
Überprüfen auf angehaltene Vorgänge oder Skalierungen Überprüfen Sie, ob Ihr Dienst derzeit angehalten ist oder gerade skaliert wird. Gehen Sie im Azure-Portal zu dem dedizierten SQL-Pool, mit dem Sie eine Verbindung herstellen möchten. Weitere Informationen finden Sie in der Dokumentation zur Problembehandlung.
Überprüfen Sie das Blatt "Ressourcenintegrität" im Azure-Portal auf Statusaktualisierungen. Ein Nicht verfügbarer Status bedeutet, dass der Ressourcenstatus konsistente Anmeldefehler aufgrund eines Systemfehlers in Ihrer SQL-Datenbank erkannt hat. Der Status " Degraded " bedeutet, dass die Ressourcenintegrität meist erfolgreiche Anmeldungen erkannt hat, aber es gibt auch einige Fehler. Diese Anmeldefehler können durch vorübergehende Fehler verursacht werden.
Überprüfen der Firewalleinstellungen Der dedizierte SQL-Pool kommuniziert über Port 1433. Wenn Sie versuchen, eine Verbindung über ein Unternehmensnetzwerk herzustellen, wird ausgehender Datenverkehr über Port 1433 von der Firewall Ihres Netzwerks unter Umständen nicht zugelassen. In diesem Fall können Sie nur dann eine Verbindung mit Ihrem Azure SQL-Datenbank-Server herstellen, wenn Ihre IT-Abteilung Port 1433 öffnet. Weitere Informationen finden Sie unter IP-Firewallregeln für Azure SQL-Datenbank und Azure SQL Data Warehouse.
Überprüfen der Einstellungen Ihres VNets und Ihrer Dienstendpunkte. Wenn Fehler "40914" und "40615" angezeigt werden, lesen Sie die Fehlerbeschreibung und -lösung im Abschnitt "Allgemeine Fehlermeldungen".
Überprüfen der Treiber auf Aktualität Stellen Sie sicher, dass Sie die neueste Version des Tools und treibers verwenden, um eine Verbindung mit Ihrem dedizierten SQL-Pool herzustellen. Weitere Informationen finden Sie unter Nach den neuesten Treibern suchen.

Ressourcen:
* Schnellstart: Erstellen und Abfragen eines Synapse SQL-Pools mit dem Azure-Portal
* Verbinden und Verwalten Ihres dedizierten SQL-Pools mithilfe von PowerShell.
Überprüfen der Verbindungszeichenfolge Stellen Sie sicher, dass Ihre Verbindungszeichenfolge ordnungsgemäß festgelegt sind. Überprüfen Sie Ihre Verbindungszeichenfolge, um einige Beispiel-Verbindungszeichenfolge für ADO.NET, ODBC, PHP und SAMPLES anzuzeigen. Lesen Sie weitere Informationen zu Verbindungszeichenfolgen.

Beheben von Fehlern bei dauerhafter Konnektivität

Die Azure SQL-Konnektivitätsprüfung ist ein PowerShell-Skript, mit dem einige Überprüfungen auf die gängigsten Konfigurationsprobleme automatisiert werden. Die meisten probleme, die vom Skript erkannt wurden, werden von Empfehlungen zur Lösung begleitet.

Das folgende PowerShell-Skript lädt die neueste Version der Azure SQL-Konnektivitätsprüfung herunter und führt sie aus. Sie können es von jedem Clientcomputer aus ausführen, auf dem dauerhafte Verbindungsprobleme auftreten.

Notiz

  1. Öffnen Sie die Windows PowerShell ISE (nach Möglichkeit im Administratormodus).

    Notiz

    Um eine Netzwerkablaufverfolgung zusammen mit den Tests (CollectNetworkTrace Parameter) zu sammeln, müssen Sie PowerShell als Administrator ausführen.

  2. Öffnen Sie ein neues Skriptfenster.

  3. Kopieren Sie den folgenden Text, und fügen Sie ihn in das Skriptfenster ein:

    $parameters = @{
# Supports Single, Elastic Pools and Managed Instance (MI public endpoint is supported)
# Supports Azure Synapse / Azure SQL Data Warehouse (*.sql.azuresynapse.net / *.database.windows.net)
# Supports Public Cloud (*.database.windows.net), Azure China (*.database.chinacloudapi.cn), Azure Germany (*.database.cloudapi.de) and Azure Government (*.database.usgovcloudapi.net)
Server = '.database.windows.net' # or any other supported FQDN
Database = ''  # Set the name of the database you wish to test, 'master' will be used by default if nothing is set
User = ''  # Set the login username you wish to use, 'AzSQLConnCheckerUser' will be used by default if nothing is set
Password = ''  # Set the login password you wish to use, 'AzSQLConnCheckerPassword' will be used by default if nothing is set

# Optional parameters (default values will be used if omitted)
SendAnonymousUsageData = $true  # Set as $true (default) or $false
RunAdvancedConnectivityPolicyTests = $true  # Set as $true (default) or $false, this will load the library from Microsoft's GitHub repository needed for running advanced connectivity tests
ConnectionAttempts = 1 # Number of connection attempts while running advanced connectivity tests
DelayBetweenConnections = 1 # Number of seconds to wait between connection attempts while running advanced connectivity tests
CollectNetworkTrace = $true  # Set as $true (default) or $false
#EncryptionProtocol = '' # Supported values: 'Tls 1.0', 'Tls 1.1', 'Tls 1.2'; Without this parameter operating system will choose the best protocol to use
 }

$ProgressPreference = "SilentlyContinue";
if ("AzureKudu" -eq $env:DOTNET_CLI_TELEMETRY_PROFILE) {
$scriptFile = '/ReducedSQLConnectivityChecker.ps1'
} else {
$scriptFile = '/AzureSQLConnectivityChecker.ps1'
}
$scriptUrlBase = 'http://raw.githubusercontent.com/Azure/SQL-Connectivity-Checker/master'
cls
Write-Host 'Trying to download the script file from GitHub (https://github.com/Azure/SQL-Connectivity-Checker), please wait...'
try {
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls
Invoke-Command -ScriptBlock ([Scriptblock]::Create((Invoke-WebRequest ($scriptUrlBase + $scriptFile) -UseBasicParsing -TimeoutSec 60).Content)) -ArgumentList $parameters
}
catch {
Write-Host 'ERROR: The script file could not be downloaded:' -ForegroundColor Red
$_.Exception
Write-Host 'Confirm this machine can access https://github.com/Azure/SQL-Connectivity-Checker/' -ForegroundColor Yellow
Write-Host 'or use a machine with Internet access to see how to run this from machines without Internet. See how at https://github.com/Azure/SQL-Connectivity-Checker/' -ForegroundColor Yellow
}
#end

  4. Legen Sie die Parameter im Skript fest.

    • Geben Sie den Server- und den Datenbanknamen an.
    • Geben Sie die Benutzer- und Kennwortinformationen an.

      Notiz

      Dieser Schritt ist optional, ist aber eine bewährte Methode.

  5. Führen Sie das Skript aus. Die Ergebnisse werden im Ausgabefenster angezeigt. Wenn der Benutzer über Berechtigungen zum Erstellen von Ordnern verfügt, wird ein Ordner erstellt, der die resultierende Protokolldatei enthält, zusammen mit einer .zip Datei (AllFiles.zip). In Windows wird der Ordner automatisch geöffnet, nachdem das Skript ausgeführt wurde.

  6. Überprüfen Sie die Ausgabe auf erkannte Probleme, und führen Sie die empfohlenen Schritte aus, um das Problem zu beheben. Wenn das Problem nicht behoben werden kann, senden Sie die Datei mithilfe der AllFiles.zipOption "Dateiupload " im Schritt "Details " beim Erstellen Ihrer Supportanfrage an Microsoft.

Problembehandlung bei zeitweiligen Konnektivitätsfehlern

Stellen Sie sicher, dass alle Produktionsanwendungen über eine stabile Wiederholungslogik verfügen, damit getrennte Verbindungen und vorübergehende Fehler verarbeitet werden können.

Verbindungsrichtlinienkonfiguration für Gatewayprobleme

Das Azure SQL-Datenbank Gateway beendet Sitzungen, die länger als 30 Minuten im Leerlauf sind. Dieses Szenario wirkt sich häufig auf poolierte, leerlaufaktive Verbindungen aus. Für einen dedizierten SQL-Pool (früher SQL DW) können Sie die Verbindungsrichtlinie für Ihren Server von weiterleiten auf umleiten umstellen. Die Umleitungseinstellung umgeht das Gateway, nachdem es verbunden wurde. Dadurch wird das Problem beseitigt.

TCP KeepAlive in Microsoft JDBC-Treiber

Der Microsoft ASPX-Treiber und einige Drittanbietertreiber aktivieren tcp KeepAlive nicht. Dies bewirkt, dass die TCP-Netzwerkschicht die Verbindung nach einem bestimmten Leerlaufpunkt abhebt. Vergewissern Sie sich, dass Sie die neuesten Clienttreiber installiert haben und dass KeepAlive für den Treiber aktiviert ist.

Konfiguration von Timeouts

Alle Anwendungen, die eine Verbindung mit Synapse SQL-Pools herstellen, sollten mindestens 15 Sekunden ein Anmeldetimeout verwenden. Kürzere Zeiträume können während einer Datenbankkonfigurierung auf Timeouts stoßen.

Hohe Ressourcenauslastung

  • Überprüfen Sie, ob auf dem Server mit einer großen Anzahl von in die Warteschlange gestellten Anforderungen große Lasten aufgetreten sind. Möglicherweise müssen Sie Ihr Data Warehouse für weitere Ressourcen skalieren.
  • Versuchen Sie, die Wiederholungslogik in Ihrer Clientanwendung hinzuzufügen, um diese Situationen zu mindern und die Fehler für Benutzer transparent zu machen.
  • Azure Synapse Analytics bietet umfassende Überwachungsfunktionen im Azure-Portal, um Erkenntnisse zu Ihrer Data Warehouse-Workload zu gewinnen. Sie können die CPU, den Arbeitsspeicher und die lokale tempdb Nutzung in Bezug auf Ihre Workload in Azure Monitor des Azure-Portal überprüfen.

Allgemeine Fehlermeldungsreferenz

Verwenden Sie diese Tabelle, um Beschreibungen und Entschärfungen für die am häufigsten empfangenen Fehlermeldungen zu finden, wenn Sie versuchen, eine Verbindung mit einem dedizierten SQL-Pool herzustellen.

Fehlermeldung Beschreibung und Entschärfung
Fehler 18456: Fehler bei der Anmeldung für den Benutzer "NT AUTHORITY\ANONYMOUS LOGON". (Microsoft SQL Server, Fehler: 18456) Dieser Fehler tritt auf, wenn ein Microsoft Entra-Benutzer versucht, eine Verbindung mit der Masterdatenbank herzustellen, aber keinen Benutzer im Master-Shape hat. Um dieses Problem zu beheben, geben Sie entweder den dedizierten SQL-Pool an, mit dem Sie eine Verbindung herstellen möchten, oder fügen Sie den Benutzer zur Masterdatenbank hinzu. Weitere Informationen finden Sie in der Sicherheitsübersicht und [Anmeldefehler mit Status und Beschreibung](/sql/relational-databases/errors-events/ des SAS-Tokens. Ziehen Sie zum Zugreifen auf geschützten Speicher einen Wechsel zu Authentifizierung mit Verwalteter Identität oder Microsoft Entra-Passthrough in Betracht. Weitere Informationen finden Sie unter Gewähren des Zugriffs auf vertrauenswürdige Azure-Dienste und Steuern des Speicherkontozugriffs für serverlose SQL-Pools.
Fehler 916: Der Serverprinzipal "MyUserName" kann nicht unter dem aktuellen Sicherheitskontext auf den Datenbankmaster zugreifen. Die Standarddatenbank des Benutzers kann nicht geöffnet werden. Fehler bei der Anmeldung. Fehler bei der Anmeldung für den Benutzer 'MeinBenutzername'. (Microsoft SQL Server, Fehler: 916) Dieser Fehler tritt auf, wenn ein Microsoft Entra-Benutzer versucht, eine Verbindung mit der Masterdatenbank herzustellen, aber keinen Benutzer im Master-Shape hat. Um dieses Problem zu beheben, geben Sie entweder den dedizierten SQL-Pool an, mit dem Sie eine Verbindung herstellen möchten, oder fügen Sie den Benutzer zur Masterdatenbank hinzu. Weitere Informationen finden Sie unter Sicherheitsübersicht und Anmeldefehler mit Status und Beschreibung.
Fehler 40613: Die Datenbank „X“ auf dem Server „Y“ ist zurzeit nicht verfügbar. Fehler 40613 ist ein nicht spezifischer, vorübergehender Fehler, der von Azure zurückgegeben wird, wenn Ihre Datenbank nicht verfügbar ist. Sie sollten gelegentlich kurze Zeiträume (z. B. weniger als 60 Sekunden) erwarten, während der der Fehler "40613" angezeigt wird. Um dieses Szenario zu berücksichtigen, stellen Sie sicher, dass alle Produktionsanwendungen über eine robuste Wiederholungslogik verfügen.
Fehler 40615: Der vom Anmeldename angeforderte Server '{0}' kann nicht geöffnet werden. Client mit IP-Adresse '{1}' darf nicht auf den Server zugreifen Der Client versucht, eine Verbindung von einer IP-Adresse herzustellen, die nicht autorisiert ist, eine Verbindung mit dem Azure SQL-Datenbank-Server herzustellen. Die Serverfirewall enthält keine IP-Adressregel, die einem Client die Kommunikation mit der SQL-Datenbank über eine bestimmte IP-Adresse erlaubt. Geben Sie die IP-Adresse des Clients als neue IP-Regel in die Firewalleinstellungen der Ressource in Azure-Portal ein. Eine Liste verschiedener Fehlermeldungen der SQL-Datenbank ist hier dokumentiert.
Fehler 40914: Der vom Anmeldename angeforderte Servername <> kann nicht geöffnet werden. Dem Client ist der Zugriff auf den Server nicht gestattet. In diesem Szenario befindet sich der Client in einem Subnetz mit Endpunkten für virtuelle Netzwerkserver. Der Azure SQL-Datenbank Server verfügt jedoch über keine Virtuelle Netzwerkregel, die das Recht gewährt, mit dem SQL-Datenbank mit dem Subnetz zu kommunizieren. Verwenden Sie im Azure-Portal im Bereich Firewall die Steuerung von VNET-Regeln, um eine VNET-Regel für das Subnetz hinzuzufügen.
Fehler 9002: 'Das Transaktionsprotokoll für den Datenbankdatenbanknamen <> ist vollständig aufgrund von 'ACTIVE_TRANSACTION'. (Microsoft SQL Server, Fehler: 9002)' Dieser Fehler zeigt in der Regel eine lange ausgeführte Transaktion an, die noch nicht zugesichert ist oder dass eine nicht reaktionsfähige Sitzung vorhanden ist. Dadurch wird ein vollständiges Transaktionsprotokoll erstellt. Überprüfen Sie auf hängende Sitzungen, die protokolliert werden SELECT * FROM sys.dm_exec_sessions, and end them by using KILL <session_id>. Wenn keine hängenden Sitzungen vorhanden sind, müssen Sie möglicherweise die lange ausgeführte Abfrage abbrechen oder diese Sitzung beenden, um dieses Problem zu beheben.
Ein netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn konnte nicht zugegriffen werden. Stellen Sie sicher, dass der Instanzname richtig und SQL Server so konfiguriert ist, das Remoteverbindungen zulässig sind. Anmeldungen für SQL-Datenbank oder dedizierte SQL-Pools (früher SQL DW) in Azure Synapse können auf jedem beliebigen Gateway in einer Region landen. Um eine konsistente Konnektivität mit SQL-Datenbank oder dedizierten SQL-Pools (vormals SQL DW) in Azure Synapse zu ermöglichen, ermöglichen Sie netzwerkdatenverkehr zu und von allen Gateway-IP-Adressen und Subnetzen für die Region. Weitere Informationen finden Sie unter Gateway-IP-Adressen.
Die Datei kann nicht geöffnet werden, da sie nicht vorhanden ist oder von einem anderen Prozess verwendet wird. Wenn ihre Abfrage fehlschlägt und diese Fehlermeldung zurückgibt, und Sie überprüfen, ob die Datei vorhanden ist und von einem anderen Prozess nicht verwendet wird, kann der Serverless SQL-Pool nicht auf die Datei zugreifen. Wenn der Speicher durch eine Firewall geschützt ist, überprüfen Sie die Schritte, die beim Abfragen von firewallgeschütztem Speicher beschrieben werden.
Fehler beim Ausführen der Abfrage. Fehler: Auf den Tabellennamen> der externen Tabelle <kann nicht zugegriffen werden, da der Inhalt des Verzeichnisses nicht aufgeführt werden kann. Wenn der Speicher mithilfe einer Firewall geschützt ist, lesen Sie das Abfragen von firewallgeschütztem Speicher. Verwenden Sie das vorherige PowerShell-Skript, um zu überprüfen, ob die Netzwerkregeln des Speicherkontos ordnungsgemäß konfiguriert sind.

Ressourcen