Nawiązywanie połączenia z bazą danych Azure SQL Database

pobierz sterownik JDBC

W tym artykule omówiono problemy występujące podczas używania sterownika JDBC firmy Microsoft dla programu SQL Server do nawiązywania połączenia z usługą Azure SQL Database. Aby uzyskać więcej informacji na temat nawiązywania połączenia z usługą Azure SQL Database, zobacz:

• Azure SQL Database

• Instrukcje: nawiązywanie połączenia z usługą Azure SQL przy użyciu JDBC

• Nawiązywanie połączenia przy użyciu uwierzytelniania przy użyciu identyfikatora Entra firmy Microsoft (dawniej Azure Active Directory)

Szczegóły

Aby nawiązać połączenie z usługą Azure SQL Database, połącz się z bazą danych master, aby wywołać metodę SQLServerDatabaseMetaData.getCatalogs.
Usługa Azure SQL Database nie obsługuje zwracania całego zestawu wykazów z bazy danych użytkownika. SQLServerDatabaseMetaData.getCatalogs używa tego widoku sys.databases do pobierania katalogów. Aby zrozumieć zachowanie SQLServerDatabaseMetaData.getCatalogs na Azure SQL Database, zobacz omówienie uprawnień w sys.databases.

Limit czasu logowania

Gdy łączysz się z bazami danych Azure SQL, loginTimeout domyślne 30 sekund to rozsądny punkt wyjścia. W przypadku Azure SQL Database serverless z włączoną funkcją automatycznej pauzy zwiększ ten limit, aby uwzględnić ponawiane przez sterownik próby połączenia podczas wznawiania działania bazy danych. Więcej informacji można znaleźć w artykule Łączenie z automatycznie wstrzymywaną bezserwerową bazą danych. Aby ustawić loginTimeout, zobacz Ustawianie właściwości połączenia.

Porzucone połączenia

Gdy nawiązujesz połączenie z usługą Azure SQL Database, składnik sieciowy (taki jak zapora sieciowa) może zakończyć bezczynne połączenia po okresie braku aktywności. W tym kontekście istnieją dwa typy połączeń bezczynnych:

• Bezczynność w warstwie TCP, gdzie połączenia mogą być porzucane przez dowolną liczbę urządzeń sieciowych.

• Bezczynny przez bramę Azure SQL Gateway, w której mogą występować komunikaty keepalive protokołu TCP (co sprawia, że połączenie nie jest uważane za bezczynne z perspektywy TCP), ale nie było żadnego aktywnego zapytania w ciągu 30 minut. W tym scenariuszu brama ustali, że połączenie TDS jest bezczynne po 30 minutach i przerywa połączenie.

Aby rozwiązać drugi problem i uniknąć sytuacji, w której gateway kończy bezczynne połączenia, możesz:

• Użyj polityki przekierowaniapołączeń, aby skonfigurować źródło danych usługi Azure SQL.

• Zachowaj aktywne połączenia za pośrednictwem uproszczonej aktywności. Ta metoda nie jest zalecana i powinna być używana tylko wtedy, gdy nie ma innych możliwych opcji.

Aby rozwiązać pierwszy problem i uniknąć usuwania bezczynnych połączeń przez składnik sieciowy, ustaw następujące ustawienia rejestru lub ich odpowiedniki innych niż Windows w systemie operacyjnym, w którym jest ładowany sterownik:

Uruchom ponownie komputer, aby ustawienia rejestru zaczęły obowiązywać.

Wartości KeepAliveTime i KeepAliveInterval są w milisekundach. Te ustawienia powodują rozłączenie połączenia nieodpowiadanego w ciągu 10 do 40 sekund. Jeśli po wysłaniu pakietu keep-alive odpowiedź nie zostanie odebrana, zostanie ponowiona co sekundę maksymalnie 10 razy. Jeśli w tym czasie nie zostanie odebrana żadna odpowiedź, gniazdo po stronie klienta zostanie rozłączone. W zależności od środowiska warto zwiększyć wartość KeepAliveInterval w celu uwzględnienia znanych zakłóceń (na przykład migracji maszyn wirtualnych), co może spowodować, że serwer nie odpowiada dłużej niż 10 sekund.

Aby to skonfigurować na maszynie wirtualnej platformy Azure, utwórz zadanie uruchamiania, aby dodać klucze rejestru. Dodaj na przykład następujące zadanie uruchamiania do pliku definicji usługi:

<Startup>  
    <Task commandLine="AddKeepAlive.cmd" executionContext="elevated" taskType="simple">  
    </Task>  
</Startup>  

Następnie dodaj plik AddKeepAlive.cmd do projektu. Ustaw ustawienie "Kopiuj do katalogu wyjściowego" na Wartość Kopiuj zawsze. Poniższy skrypt to przykładowy plik AddKeepAlive.cmd:

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  

Dołącz nazwę serwera do identyfikatora userId w parametrach połączenia

Przed wersją 4.0 sterownika JDBC firmy Microsoft dla programu SQL Server w celu nawiązania połączenia z usługą Azure SQL Database wymagane było dołączenie nazwy serwera do identyfikatora UserId w parametrach połączenia. Na przykład user@servername. Począwszy od wersji 4.0 sterownika JDBC firmy Microsoft dla programu SQL Server, nie jest już konieczne dołączenie @servername do identyfikatora UserId w parametrach połączenia.

Korzystanie z szyfrowania wymaga ustawienia hostNameInCertificate

Przed wersją 7.2 sterownika JDBC firmy Microsoft dla programu SQL Server, aby nawiązać połączenie z usługą Azure SQL Database, należy określić hostNameInCertificate, gdy określisz encrypt=true (jeśli nazwa serwera w parametrach połączenia to shortName.domainName, ustaw właściwość hostNameInCertificate na *.domainName.). Ta właściwość jest opcjonalna w wersji 7.2 sterownika.

Przykład:

jdbc:sqlserver://abcd.int.mscds.com;databaseName=myDatabase;user=myName;password=<password>;encrypt=true;hostNameInCertificate=*.int.mscds.com;

Treści powiązane

• nawiązywanie połączenia z programem SQL Server za pomocą sterownika JDBC