Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden Probleme behandelt, die bei der Verwendung des Microsoft JDBC-Treibers für SQL Server zum Herstellen einer Verbindung mit einer Azure SQL-Datenbank-Instanz auftreten. Weitere Informationen zum Herstellen einer Verbindung mit einer Azure SQL-Datenbank-Instanz finden Sie unter:
Details
Um eine Verbindung mit einer Azure SQL-Datenbank herzustellen, sollten Sie zum Aufrufen von SQLServerDatabaseMetaData.getCatalogs eine Verbindung mit der Masterdatenbank herstellen.
Die Rückgabe sämtlicher Kataloge aus einer Benutzerdatenbank wird von Azure SQL-Datenbank nicht unterstützt.
SQLServerDatabaseMetaData.getCatalogs verwendet die Ansicht sys.databases, um die Kataloge abzurufen. Um das Verhalten von SQLServerDatabaseMetaData.getCatalogs auf einer Azure SQL-Datenbank zu verstehen, siehe die Diskussion zu Berechtigungen in sys.databases.
Anmeldungstimeout
Wenn du dich mit Azure SQL-Datenbanken verbindest, ist der loginTimeout Standard von 30 Sekunden ein vernünftiger Ausgangspunkt. Erhöhen Sie den Wert für serverlose Azure SQL-Datenbanken mit aktiviertem AutoAnhalten, damit die Verbindungswiederholversuche des Treibers angehalten werden können, während die Datenbank wieder hochfährt. Weitere Informationen finden Sie unter Verbinden mit einer automatisch pausierten serverlosen Datenbank. Um festzulegen loginTimeout, siehe Einstellung der Verbindungseigenschaften.
Verbindungen unterbrochen
Wenn Sie sich mit einer Azure SQL-Datenbank verbinden, kann eine Netzwerkkomponente (wie eine Firewall) nach einer Phase der Inaktivität die Leerlaufverbindungen beenden. In diesem Zusammenhang gibt es zwei Arten von Leerlaufverbindungen:
Inaktive Verbindungen auf der TCP-Ebene, wobei Verbindungen von einer beliebigen Anzahl von Netzwerkgeräten gelöscht werden können.
Vom Azure SQL-Gateway als inaktiv eingestufte Verbindungen, bei denen möglicherweise TCP-Keepalive-Meldungen auftreten (wodurch die Verbindung aus TCP-Sicht nicht inaktiv ist), bei denen jedoch in den letzten 30 Minuten keine aktive Abfrage vorlag. In diesem Szenario ermittelt das Gateway, ob sich die TDS-Verbindung nach 30 Minuten im Leerlauf befindet, und die Verbindung wird beendet.
Um den zweiten Punkt zu behandeln und zu vermeiden, dass das Gateway Verbindungen im Leerlauf abbricht, können Sie wie folgt vorgehen:
Verwenden Sie die Redirect-Verbindungsrichtlinie, um Ihre Azure SQL-Datenquelle zu konfigurieren.
Halten Sie Verbindungen über eine einfache Aktivität aktiv. Diese Methode wird nicht empfohlen und sollte nur verwendet werden, wenn es keine anderen Möglichkeiten gibt.
Um auf den ersten Punkt einzugehen und zu vermeiden, dass inaktive Verbindungen von einer Netzwerkkomponente unterbrochen werden, legen Sie auf dem Betriebssystem, auf dem der Treiber geladen wird, die folgenden Registrierungseinstellungen oder die entsprechenden Nicht-Windows-Äquivalente fest:
Hinweis
Ab Version 10.2 des Microsoft JDBC-Treibers für SQL Server legt der Treiber automatisch die folgenden Keep-Alive-Werte für Sockets fest, die er während Datenbankverbindungen erstellt, wobei die in der folgenden Tabelle definierten Betriebssystemstandardwerte überschrieben werden. Diese automatische Einstellung wird nur für Versionen von Java ausgeführt, die das Festlegen der Socket-Keep-Alive-Optionen unterstützen. Unter Linux und macOS unterstützen die neuesten Updates von Java 8+ diese Einstellung. Unter Windows unterstützen die neuesten Updates von Java 17+ diese Einstellung.
| Registrierungseinstellung | Empfohlener Wert |
|---|---|
| HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ KeepAliveTime | 30.000 |
| HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ KeepAliveInterval | 1000 |
| HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions | 10 |
Starten Sie den Computer neu, damit die Registrierungseinstellungen wirksam werden.
Die KeepAliveTime- und KeepAliveInterval-Werte sind in Millisekunden angegeben. Diese Einstellungen bewirken, dass eine nicht reagierende Verbindung innerhalb von 10 bis 40 Sekunden getrennt wird. Wenn nach dem Senden eines Keepalive-Pakets keine Antwort empfangen wird, wird dies bis zu zehnmal sekündlich erneut versucht. Wenn in dieser Zeit keine Antwort empfangen wird, wird die Verbindung zum clientseitigen Socket getrennt. Abhängig von Ihrer Umgebung müssen Sie möglicherweise den „KeepAliveInterval“-Wert erhöhen, um bekannte Störungen (z. B. Migrationen virtueller Computer) auszugleichen, die dazu führen können, dass ein Server länger als zehn Sekunden nicht mehr antwortet.
Hinweis
„TcpMaxDataRetransmissions“ ist unter Windows Vista oder Windows 2008 und höher nicht steuerbar.
Um dieses Verhalten auf einer Azure-VM zu konfigurieren, erstellen Sie eine Startaufgabe zum Hinzufügen der Registrierungsschlüssel. Fügen Sie der Dienstdefinitionsdatei beispielsweise folgenden Starttask hinzu:
<Startup>
<Task commandLine="AddKeepAlive.cmd" executionContext="elevated" taskType="simple">
</Task>
</Startup>
Fügen Sie dem Projekt anschließend eine Datei „AddKeepAlive.cmd“ hinzu. Legen Sie die Einstellung „In Ausgabeordner kopieren“ auf „Immer kopieren“ fest. Das folgende Skript ist eine AddKeepAlive.cmd-Beispieldatei:
if exist keepalive.txt goto done
time /t > keepalive.txt
REM Workaround for JDBC keep alive on Azure SQL
REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime /t REG_DWORD /d 30000 >> keepalive.txt
REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveInterval /t REG_DWORD /d 1000 >> keepalive.txt
REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpMaxDataRetransmissions /t REG_DWORD /d 10 >> keepalive.txt
shutdown /r /t 1
:done
Fügen Sie den Servernamen an die userId in der Verbindungszeichenfolge an.
Vor Version 4.0 von Microsoft JDBC-Treiber für SQL Server war es zum Herstellen einer Verbindung mit einer Azure SQL-Datenbank erforderlich, den Servernamen an die UserID in der Verbindungszeichenfolge anzufügen. z. B. „Benutzer@Servername“. Ab Version 4.0 von Microsoft JDBC-Treiber für SQL Server muss @servername nicht mehr an die UserID in der Verbindungszeichenfolge angefügt werden.
Die Verwendung von Verschlüsselung erfordert die Einstellung „hostNameInCertificate“.
Falls Sie eine Vorgängerversion von Version 7.2 des Microsoft JDBC-Treibers für SQL Server verwenden, sollten Sie beim Herstellen einer Verbindung mit einer Azure SQL-Datenbank-Instanz hostNameInCertificate angeben, wenn Sie encrypt=true angeben. Wenn der Servername in der Verbindungszeichenfolge shortName.domainName lautet, legen Sie die hostNameInCertificate-Eigenschaft auf *.domainName fest. Diese Eigenschaft ist ab Version 7.2 des Treibers optional.
Beispiel:
jdbc:sqlserver://abcd.int.mscds.com;databaseName=myDatabase;user=myName;password=<password>;encrypt=true;hostNameInCertificate=*.int.mscds.com;