Conexión a una base de datos de Azure SQL
En este artículo se describen los problemas que se producen al usar Microsoft JDBC Driver para SQL Server a fin de conectarse a una instancia de Azure SQL Database. Para obtener más información sobre cómo conectarse a una instancia de Azure SQL Database, consulte:
Detalles
Para conectarse a una instancia de Azure SQL Database, debe conectarse a la base de datos maestra para llamar a SQLServerDatabaseMetaData.getCatalogs.
Azure SQL Database no admite la devolución del conjunto entero de catálogos desde una base de datos de usuario. SQLServerDatabaseMetaData.getCatalogs usa la vista sys.databases para obtener los catálogos. Consulte la explicación de los permisos en sys.databases (Transact-SQL) para entender el comportamiento de SQLServerDatabaseMetaData.getCatalogs en una instancia de Azure SQL Database.
Tiempo de espera de inicio de sesión
Al conectarse a las bases de datos de Azure SQL, el valor loginTimeout predeterminado recomendado es de 30 segundos. Si se conecta a una instancia sin servidor, se recomienda usar un período de loginTimeout de 60 segundos o más. Si la instancia sin servidor ha estado inactiva, puede tardar algún tiempo en reactivarse en una conexión inicial. Para obtener más información sobre cómo establecer loginTimeout, consulte Establecimiento de las propiedades de conexión.
Conexiones eliminadas
Al conectar con una instancia de Azure SQL Database, un componente de red (como un firewall) puede terminar las conexiones inactivas tras un período de inactividad. Existen dos tipos de conexiones inactivas en este contexto:
Inactiva en la capa de TCP, donde cualquier número de dispositivos de red puede quitar las conexiones.
Inactiva por la puerta de enlace de Azure SQL, donde pueden darse mensajes keepalive de TCP (pasando a no ser una conexión inactiva desde una perspectiva de TCP) y no tener una consulta activa en 30 minutos. En este escenario, la puerta de enlace determinará si la conexión TDS está inactiva después de 30 minutos y la finalizará.
Para solucionar el segundo punto y evitar que la puerta de enlace termine las conexiones inactivas, puede:
Usar la directiva de conexión Redirect para configurar el origen de datos de Azure SQL.
Mantenga las conexiones activas a través de la actividad ligera. Este método no se recomienda y solo tiene que usarse si no hay otras opciones posibles.
Para abordar el primer punto y evitar que un componente de red elimine las conexiones inactivas, establezca la siguiente configuración del Registro (o su equivalente si no es Windows) en el sistema operativo donde esté cargado el controlador:
| Configuración del registro | Valor recomendado |
|---|---|
| HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ KeepAliveTime | 30000 |
| HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ KeepAliveInterval | 1000 |
| HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions | 10 |
Reinicie el equipo para que surta efecto la configuración del Registro.
Los valores KeepAliveTime y KeepAliveInterval se indican en milisegundos. Esta configuración hace que una conexión que no responde se desconecte en un plazo de entre 10 y 40 segundos. Si no se recibe ninguna respuesta después de enviar un paquete de mantenimiento de conexión, se volverá a intentar cada segundo hasta 10 veces. Si no se recibe ninguna respuesta durante ese tiempo, el socket del lado cliente se desconecta. En función del entorno, puede que desee aumentar el valor de KeepAliveInterval para adaptarse a interrupciones conocidas (por ejemplo, migraciones de máquinas virtuales) que podrían hacer que un servidor deje de responder durante más de 10 segundos.
Nota
TcpMaxDataRetransmissions no es controlable en Windows Vista ni Windows 2008 y versiones posteriores.
Para configurarlo en una VM de Azure, cree una tarea de inicio para agregar las claves del Registro. Por ejemplo, agregue la siguiente tarea de inicio al archivo de definición de servicios:
<Startup>
<Task commandLine="AddKeepAlive.cmd" executionContext="elevated" taskType="simple">
</Task>
</Startup>
A continuación, agrega un archivo AddKeepAlive.cmd al proyecto. Establezca la configuración "Copy to Output Directory" en Copy always. El siguiente script es un archivo AddKeepAlive.cmd de ejemplo:
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
Anexar el nombre de servidor al identificador de usuario en la cadena de conexión
Antes de la versión 4.0 de Microsoft JDBC Driver para SQL Server, para conectarse a una instancia de Azure SQL Database, se tenía que anexar el nombre de servidor al identificador de usuario en la cadena de conexión. Por ejemplo, usuario@nombreDeServidor. A partir de la versión 4.0 de Microsoft JDBC Driver para SQL Server, ya no es necesario anexar @servername al identificador de usuario en la cadena de conexión.
El empleo de cifrado exige establecer hostNameInCertificate
Antes de la versión 7.2 de Microsoft JDBC Driver para SQL Server, para conectarse a una instancia de Azure SQL Database, debe especificar hostNameInCertificate si especifica encrypt=true (si el nombre del servidor de la cadena de conexión es shortName.domainName, establezca la propiedad hostNameInCertificate en *.domainName.). Esta propiedad es opcional a partir de la versión 7.2 del controlador.
Por ejemplo:
jdbc:sqlserver://abcd.int.mscds.com;databaseName=myDatabase;user=myName;password=<password>;encrypt=true;hostNameInCertificate=*.int.mscds.com;