Solucionar problemas de conectividad y otros errores

Se aplica a:Azure SQL DatabaseAzure SQL Managed InstanceBase de datos SQL en Fabric

Recibirá mensajes de error cuando se produce un error en la conexión a Azure SQL Database, SQL Database en Microsoft Fabric o Instancia administrada de Azure SQL.

Como siempre, aplique los procedimientos recomendados y las directrices de diseño durante el proceso de diseño de aplicaciones.

Pasos para solucionar problemas de conexión comunes

1. Asegúrese de que TCP/IP esté habilitado como protocolo de cliente en el servidor de aplicaciones. En los servidores de aplicaciones en los que no tiene instaladas herramientas de SQL, compruebe que TCP/IP esté habilitado mediante la ejecución de cliconfg.exe (utilidad de red de cliente de SQL Server).

2. Compruebe la cadena de conexión de la aplicación para asegurarse de que está configurada correctamente. Por ejemplo, asegúrese de que la cadena de conexión especifica el puerto correcto (1433) y el nombre completo del servidor. Consulte Obtención de información de conexión mediante SQL Server Management Studio.

3. Intente aumentar el valor de tiempo de espera de la conexión. Se recomienda el uso de un tiempo de espera de conexión de al menos 30 segundos.

4. Pruebe la conectividad entre el servidor de aplicaciones y Azure SQL Database mediante Inicio rápido: Use SSMS para conectarse a Azure SQL Database o Azure SQL Managed Instance, un archivo UDL, ping o telnet. Para más información, consulte Solución de problemas de conectividad y Diagnóstico de problemas de conexión.

   Nota:

   Como paso de solución de problemas, también puede probar la conectividad en otro equipo cliente.

5. Como procedimiento recomendado, las aplicaciones conectadas a la nube deben usar lógica de reintento.

Si con los pasos anteriores no se resuelve el problema, intente recopilar más datos y luego póngase en contacto con el soporte técnico. Si la aplicación es un servicio en la nube, habilite el registro. Este paso devuelve una marca de tiempo UTC del error. Para más información sobre cómo habilitar el registro, consulte Habilitar el registro de diagnósticos para las aplicaciones de Azure App Service. Además, SQL Database devuelve el identificador de seguimiento. Los servicios de soporte técnico de Microsoft pueden usar esta información.

Errores de conectividad causados por invalidaciones de archivos DNS o hosts personalizados

Si la aplicación tiene errores de inicio de sesión persistentes (errores 18456, 40532 o 40615) que están aislados en redes cliente específicas mientras el servicio Azure SQL es correcto, la causa podría ser una configuración DNS personalizada que ancla el FQDN del servidor a una dirección IP de puerta de enlace de Azure SQL obsoleta.

¿Por qué sucede esto?

Azure SQL Database usa una flota de puertas de enlace regionales. Azure retira y reemplaza periódicamente las puertas de enlace como parte de las operaciones normales, incluida la actualización de hardware, el escalado y la migración impulsada por el estado de salud. El DNS autoritativo Azure para <server>.database.windows.net se actualiza automáticamente para reflejar las puertas de enlace activas actuales.

Cuando el entorno invalida esta resolución DNS (a través de una entrada de archivo de hosts, un registro CNAME estático o una zona DNS privada que asigna el FQDN del servidor a una dirección IP específica), el cliente se ancla a esa dirección IP. Si la puerta de enlace de esa dirección IP se retira o se reasigna más adelante, las conexiones van al punto de conexión incorrecto. La puerta de enlace de Azure SQL valida el FQDN entrante en el servidor de destino y una falta de coincidencia provoca errores de inicio de sesión.

Detectar una anulación de DNS

Ejecute las siguientes comprobaciones desde el cliente afectado.

1. Compruebe si hay invalidaciones en el archivo de hosts locales:

   :: Windows
   type C:\Windows\System32\drivers\etc\hosts | findstr /i "database.windows.net"
   

   # Linux or macOS
   grep -i "database.windows.net" /etc/hosts
   

2. Comparar la resolución DNS del cliente con el DNS autoritativo de Azure.

   :: Client or recursive resolver
   nslookup <server>.database.windows.net
   
   :: Authoritative public DNS
   nslookup <server>.database.windows.net 208.67.222.222
   

   # PowerShell
   Resolve-DnsName -Name "<server>.database.windows.net" -DnsOnly
   

   Si el solucionador del cliente devuelve una dirección IP diferente al DNS autoritativo, se activa una anulación de DNS.

3. Compruebe si hay sobrescrituras de CNAME o zona DNS privada.

   nslookup -type=CNAME <server>.database.windows.net
   

   az network private-dns record-set list \
     --resource-group <ResourceGroup> \
     --zone-name database.windows.net \
     --output table
   

Repara la invalidación

1. Retire la sobrescritura. Elimine la entrada del archivo hosts, quite el registro CNAME estático o elimine el registro de zona DNS privado que ancla el FQDN del servidor a una dirección IP específica.

2. Vaciar las cachés DNS en el cliente y en las resoluciones intermedias:

   :: Windows
   ipconfig /flushdns
   

   # Linux (systemd-resolved)
   sudo systemd-resolve --flush-caches
   
   # macOS
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   

3. Compruebe que DNS ahora se resuelve en la puerta de enlace de Azure actual:

   nslookup <server>.database.windows.net
   

   Confirme que la dirección IP devuelta se encuentra dentro de los intervalos IP de puerta de enlace publicados para la región del servidor. Para obtener la lista, consulte la sección Direcciones IP de puerta de enlace en Arquitectura de conectividad.

4. Vuelva a probar la conectividad mediante el comprobador de conectividad Azure SQL o SQL Server Management Studio (SSMS).

Evitar este problema

• Nunca ancles los FQDN de servidores de Azure SQL a direcciones IP específicas en los archivos hosts, registros CNAME estáticos o zonas DNS privadas. Las puertas de enlace de Azure SQL son dinámicas y cambian con el tiempo.
• Si utiliza listas de permisos de firewall basadas en IP de puerta de enlace, permita todos los intervalos de IP de puerta de enlace de su región en lugar de direcciones IP individuales. Siempre que sea posible, use la etiqueta de Sql.<region> servicio.
• Para la conectividad privada, use Azure Private Link o puntos de conexión privados en lugar de desvíos de DNS. Los puntos de conexión privados proporcionan direcciones IP privadas estables dentro de la red virtual y enrutan directamente a la puerta de enlace.
• Suscríbase a las alertas de Service Health para Azure SQL Database y reciba notificaciones sobre las migraciones de puerta de enlace en su región.

Referencia rápida

Implementación de la lógica de reintento

Se recomienda encarecidamente que las aplicaciones cliente tengan lógica de reintento para poder tratar de restablecer una conexión después de dar tiempo a que se corrijan los errores transitorios. Se recomienda un retraso de 5 segundos antes del primer reintento. Si se vuelve a intentar después de un retraso de menos de 5 segundos, se correrá el riesgo de sobrecargar el servicio en la nube. Para cada intento siguiente, el retraso debería aumentar exponencialmente, hasta un máximo de 60 segundos.

Para obtener ejemplos de lógica de reintento, vea:

• Conectar de forma resiliente a SQL con ADO.NET
• Paso 4: Conectar de forma resistente a SQL con PHP

Para obtener más información sobre el control de errores transitorios en la aplicación, consulte Solución de errores de conexión transitorios.

Una explicación del período de bloqueo para clientes que usan ADO.NET está disponible en Grupos de conexión (ADO.NET).

Mensajes de error transitorios (40197, 40613 y otros)

La infraestructura de Azure ofrece la posibilidad de volver a configurar dinámicamente servidores cuando surgen cargas de trabajo pesadas en el servicio de SQL Database. Este comportamiento dinámico podría dar lugar a que el programa cliente perdiera su conexión a la base de datos o la instancia. Este tipo de condición de error se conoce como error transitorio. Los eventos de reconfiguración de la base de datos se producen debido a un evento planeado (por ejemplo, una actualización de software) o a un evento no planeado (por ejemplo, el bloqueo de un proceso o un equilibrio de carga). La mayoría de los eventos de reconfiguración son de corta duración y se completarán en menos de 60 segundos. Sin embargo, ocasionalmente estos eventos pueden tardar más tiempo de finalizar, por ejemplo, cuando una transacción grande produce una recuperación de larga duración. En la tabla siguiente se enumeran varios errores transitorios que las aplicaciones pueden recibir al conectarse a Azure SQL Database.

Lista de códigos de error transitorios

Pasos para resolver los problemas de conectividad transitorios

1. Compruebe el panel de servicios de Microsoft Azure para comprobar si se produjeron interrupciones durante el tiempo en el que la aplicación informó de los errores.
2. Para las aplicaciones que se conectan a un servicio en la nube, como base de datos de Azure SQL, se deben prever eventos periódicos de reconfiguración e implementar la lógica de reintento para gestionar estos errores en lugar de mostrar los errores de la aplicación a los usuarios.
3. Conforme una base de datos se acerca a sus límites de recursos, puede parecer un problema de conectividad transitorio. Consulte Límites de los recursos.
4. Si los problemas de conectividad continúan, si el tiempo de detección del error por parte de la aplicación supera los 60 segundos o si el error se repite varias veces en un día determinado, realice una solicitud de soporte técnico a Azure; para ello, seleccione Obtener soporte en el sitio Soporte técnico de Azure .

Se ha producido un error relacionado con la red o específico de la instancia al establecer una conexión con el servidor.

El problema se produce si la aplicación no se puede conectar al servidor.

Para resolver este problema, pruebe los pasos (en orden) de la sección Pasos para solucionar problemas de conexión comunes.

No se detectó el servidor/instancia o no estaba accesible (errores 26, 40, 10053)

Error 26: Error al buscar el servidor especificado

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.(provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Error 40: No se pudo abrir una conexión al servidor

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Error 10053: Error de nivel de transporte al recibir datos del servidor.

10053: A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine)

Estos problemas se producen si la aplicación no se puede conectar al servidor.

Para resolver estos problemas, pruebe los pasos (en orden) de la sección Pasos para solucionar problemas de conexión comunes.

No se puede conectar al servidor por problemas de firewall

Error 40615: No se puede conectar a <nombredelservidor>

Para resolver este problema, configure un firewall en SQL Database con Azure Portal.

Error 5: No se puede conectar a <nombredelservidor>

Para resolver este problema, asegúrese de que el puerto 1433 está abierto para las conexiones salientes en todos los firewalls entre el cliente e Internet.

No se puede iniciar sesión en el servidor (errores 18456, 40531)

Error de inicio de sesión del usuario "<nombre de usuario>".

Login failed for user '<User name>'.This session has been assigned a tracing ID of '<Tracing ID>'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 18456)

Para resolver este problema, póngase en contacto con el administrador de servicios para que le proporcione un nombre de usuario y una contraseña válidos.

Normalmente, el administrador de servicio puede usar los siguientes pasos para agregar las credenciales de inicio de sesión:

1. Inicie sesión en el servidor mediante SQL Server Management Studio (SSMS).

2. Para comprobar si el nombre de inicio de sesión está deshabilitado, ejecute la siguiente consulta SQL en la base de datos master:

   SELECT name, is_disabled FROM sys.sql_logins;
   

3. Si el nombre correspondiente está deshabilitado, puede decidir habilitar el nombre mediante la instrucción siguiente:

   ALTER LOGIN <User name> ENABLE;
   

4. Si el nombre de usuario de inicio de sesión SQL no existe, edite y ejecute la siguiente consulta SQL para crear un inicio de sesión SQL:

   CREATE LOGIN <SQL_login_name, sysname, login_name>
   WITH PASSWORD = '<password, sysname, Change_Password>';
   GO
   

5. En el Explorador de objetos de SSMS, expanda Bases de datos.

6. Seleccione la base de datos para la que desea conceder permiso al usuario.

7. Haga clic con el botón derecho en Seguridad y, después, seleccione Nuevo, Ususario.

8. En el script generado con marcadores de posición, siga los pasos para sustituir los parámetros de la plantilla SSMS y ejecutarlo, por ejemplo:

   CREATE USER [<user_name, sysname, user_name>]
   FOR LOGIN [<login_name, sysname, login_name>]
   WITH DEFAULT_SCHEMA = [<default_schema, sysname, dbo>];
   GO
   
   -- Add user to the database owner role
   EXEC sp_addrolemember N'db_owner', N'<user_name, sysname, user_name>';
   GO
   

   también puede utilizar sp_addrolemember para asignar usuarios específicos a roles de base de datos específicos.

   Nota:

   En Azure SQL Database, considere la sintaxis ALTER ROLE más reciente para administrar la pertenencia al rol de la base de datos.

Para obtener más información, consulte Autorización para el acceso a bases de datos.

Errores debido a tiempo de espera de conexión agotado

System.Data.SqlClient.SqlException (0x80131904): Tiempo de espera de conexión agotado

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=29995;

System.Data.SqlClient.SqlException (0x80131904): Tiempo de espera agotado

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.Entity.Core.EntityException: El proveedor subyacente falló al abrir

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. -> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. -> System.ComponentModel.Win32Exception: The wait operation timed out

No se puede conectar a <nombre del servidor>.

Cannot connect to <server name>.ADDITIONAL INFORMATION:Connection Timeout Expired. The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=231; handshake=983; [Login] initialization=0; authentication=0; [Post-Login] complete=13000; (Microsoft SQL Server, Error: -2) For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2&LinkId=20476 The wait operation timed out

Estas excepciones pueden producirse por problemas de conexión o de consulta. Para confirmar que este error se debe a problemas de conectividad, consulte Confirmación de si un error se debe a un problema de conectividad.

Los tiempos de espera de conexión se producen porque la aplicación no se puede conectar al servidor. Para resolver este problema, pruebe los pasos (en orden) de la sección Pasos para solucionar problemas de conexión comunes.

Resolución de fallos de conectividad en puntos de conexión privados

Las conexiones a Azure SQL Database a través de un punto de conexión privado pueden producir errores de tiempo de espera de conexión o errores de protocolo de enlace previos al inicio de sesión. Siga estos pasos en orden. Cada paso resuelve un modo de error distinto.

Paso 1: Comprobar el punto de conexión privado y la resolución DNS

Confirme que el punto de conexión privado está aprovisionado y que DNS resuelve a la dirección IP privada.

Paso 2: Agregar una regla de firewall de nivel de servidor para la dirección IP de salida

Incluso con un punto de conexión privado, Base de Datos SQL de Azure sigue aplicando las reglas de firewall de IP a nivel de servidor contra la dirección IP de origen que detecta la puerta de enlace.

1. Identifique la dirección IP de salida. En el caso del tráfico local enrutado a través de una puerta de enlace de VPN o ExpressRoute, la dirección IP de salida suele ser la puerta de enlace o la dirección IP privada NAT dentro de la red virtual. Desde dentro de Azure, se trata de la dirección IP privada de la máquina virtual o una dirección IP de front-end del equilibrador de carga.

2. Agregue una regla de firewall de nivel de servidor para esa dirección IP o subred:

   EXECUTE sp_set_firewall_rule
       @name = N'AllowPrivateEndpointSubnet',
       @start_ip_address = '10.0.1.0',
       @end_ip_address = '10.0.1.255';
   

Paso 3: Abrir los puertos correctos en firewalls perimetrales o locales

Los puertos necesarios dependen de la directiva de conexión:

Si una conexión se realiza correctamente desde dentro de la red virtual, pero se produce un error desde el entorno local, es probable que el firewall local bloquee los puertos más altos del 1433-65535 intervalo. Abra ese intervalo de puertos o cambie la directiva de conexión del servidor a Proxy. Para obtener más información, consulte Utilizar la directiva de conexión de redirección con puntos de conexión privados.

Paso 4: Comprobación del enrutamiento simétrico para escenarios udR, NVA y NAT

Si el tráfico al punto de conexión privado de SQL pasa a través de una aplicación virtual de red (NVA), Azure Firewall o puerta de enlace NAT, el tráfico devuelto debe seguir la misma ruta de acceso. El enrutamiento asimétrico provoca restablecimientos tcp o caídas silenciosas.

Hechos clave:

• Azure crea una ruta del sistema /32 para cada dirección IP de punto de conexión privado (por ejemplo, 10.0.1.4/32 con el tipo de próximo salto InterfaceEndpoints). Una ruta definida por el usuario (UDR) solo puede invalidar esta ruta del sistema con un prefijo igual o más específico (otro /32).

• Si enruta el tráfico saliente a una NVA, la NVA debe aplicar la traducción de dirección de red de origen (SNAT) para que los paquetes de retorno vuelvan a la NVA en lugar de ir directamente al cliente. Sin SNAT, la ruta de retorno es asimétrica.

• Las directivas de red de punto de conexión privado (compatibilidad con NSG y UDR en la subred del punto de conexión privado) están deshabilitadas de forma predeterminada. Para aplicar reglas de NSG o UDR al tráfico de punto de conexión privado, habilite las directivas de red en la subred:

  az network vnet subnet update \
    --name <SubnetName> \
    --vnet-name <VNetName> \
    --resource-group <ResourceGroup> \
    --private-endpoint-network-policies Enabled
  

Si una conexión funciona sin un dispositivo virtual de red, pero agota el tiempo de espera cuando se enruta a través de uno, la ruta del sistema /32 envía el tráfico de retorno directamente al cliente, evitando la tabla de estado del NVA. Agregue una /32 UDR para la dirección IP del punto de conexión privado que apunte a la aplicación virtual de red y habilite SNAT en la aplicación virtual de red.

Paso 5: Usar Network Watcher para confirmar la conectividad de un extremo a otro

Si los pasos anteriores parecen correctos, pero las conexiones siguen fallando, use Azure Network Watcher para aislar el error:

Referencia rápida

Errores de terminación de la conexión de red

Las bibliotecas cliente SQL se conectan a Azure SQL Database y Azure SQL Managed Instance mediante el protocolo de red TCP. Una biblioteca cliente usa un componente de nivel inferior denominado proveedor TCP para administrar conexiones TCP. Cuando el proveedor TCP detecta que un host remoto ha finalizado inesperadamente una conexión TCP existente, la biblioteca cliente genera un error. Dado que el error es un error de cliente y no un error de SQL Server, no se incluye ningún número de error de SQL. En su lugar, el número de error es 0 y se usa el mensaje de error del proveedor TCP.

Entre los ejemplos de errores de terminación de la conexión de red se incluyen:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) An existing connection was forcibly closed by the remote host

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

Los errores de terminación de la conexión pueden deberse a que la base de datos o el grupo elástico no están disponibles temporalmente. También pueden producirse debido a varios problemas en la infraestructura de red entre el servidor de bases de datos y la aplicación cliente, incluidos firewalls, dispositivos de red, etc. Estos problemas pueden ser transitorios o permanentes. Como guía general, las aplicaciones deben usar un número fijo de reintentos para estos errores antes de considerarlos errores permanentes.

Errores de gobernanza de recursos

Azure SQL Database usa una implementación de gobierno de recursos basada en Resource Governor para imponer límites de recursos. Obtenga más información sobre la administración de recursos en Azure SQL Database.

La mayoría de los errores de gobierno de recursos se muestran primero con detalles, seguidos de una tabla de los mensajes de error de gobierno de recursos.

Errores 10928 y 10936: Id. de recurso: 1. El límite de solicitudes para la [base de datos o el grupo elástico] es %d y se ha alcanzado.

Si se alcanza el límite de nivel de base de datos, el mensaje de error detallado en este caso dice lo siguiente: Resource ID : 1. The request limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

Si se alcanza el límite del grupo elástico, el mensaje de error detallado en este caso lee: Resource ID : 1. The request limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. Los límites del grupo elástico son mayores que los límites de la base de datos, para obtener más información, consulte Administración de recursos en Azure SQL Database. Se pueden encontrar límites cuando varias bases de datos del conjunto usan un recurso (por ejemplo, trabajadores) simultáneamente.

Este mensaje de error indica que se ha alcanzado el límite de trabajos para la base de datos o el grupo elástico. El valor máximo de trabajadores concurrentes del objetivo de servicio de la base de datos o del grupo elástico se mostrará en reemplazo del marcador de posición %d.

Conexión con la conexión de administrador dedicada (DAC) si es necesario

Si un incidente activo está en curso en el que se alcanza el límite de trabajo, es posible que reciba el error 10928 al conectarse mediante SQL Server Management Studio (SSMS). Una sesión puede conectarse con la conexión de diagnóstico para administradores de bases de datos (DAC) incluso cuando se ha alcanzado el umbral máximo de trabajo.

Para establecer una conexión con la DAC desde SSMS:

• En el menú, seleccione Archivo > Nuevo > Consulta del motor de base de datos.
• En el cuadro de diálogo conexión del campo Nombre del servidor, escriba admin:<fully_qualified_server_name> (por ejemplo, admin:servername.database.windows.net).
• Seleccione Opciones >>.
• Seleccione la pestaña Propiedades de la conexión.
• En el cuadro Conectar a base de datos: escriba el nombre de la base de datos.
• Seleccione Conectar.

Si recibe el error 40613, Database '%.*ls' on server '%.*ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.*ls', esto puede indicar que ya hay otra sesión conectada a la DAC. Solo puede conectarse una sesión a la DAC para una sola base de datos o un grupo elástico de forma simultánea.

Si aparece el error "Error al conectarse al servidor" después de seleccionar Conectar, es posible que la sesión de DAC se haya establecido correctamente si usa una versión de SSMS anterior a la 18.9. Las versiones anteriores de SSMS intentaron proporcionar Intellisense para las conexiones a la DAC. No fue posible, ya que la DAC solo admite un solo trabajador e Intellisense requiere un trabajador independiente.

No puede usar una conexión DAC con el Explorador de objetos en SSMS.

Revise el uso de max_worker_percent

Para obtener estadísticas de consumo de recursos para la base de datos de los últimos 14 días, realice una consulta a la vista de catálogo del sistema sys.resource_stats. En la columna max_worker_percent se muestra el porcentaje de trabajadores utilizados en relación con el límite de trabajadores de la base de datos. Conéctese a la base de datos master del servidor lógico para realizar la consulta a sys.resource_stats.

SELECT start_time, end_time, database_name, sku, avg_cpu_percent, max_worker_percent, max_session_percent 
FROM sys.resource_stats;

También puede realizar una consulta de las estadísticas de consumo de recursos de la última hora desde la vista de administración dinámica sys.dm_db_resource_stats. Conéctese directamente a la base de datos para realizar una consulta a sys.dm_db_resource_stats.

SELECT end_time, avg_cpu_percent, max_worker_percent, max_session_percent
FROM sys.dm_db_resource_stats;

Reducir el uso de los trabajadores cuando sea posible

El bloqueo de cadenas de bloques puede causar un aumento súbito en el número de trabajadores en una base de datos. Un gran volumen de consultas paralelas simultáneas puede causar un número elevado de trabajos. Si aumenta el grado máximo de paralelismo (MAXDOP) o establece MAXDOP en cero puede aumentar el número de trabajos activos.

Para evitar un incidente con trabajos insuficientes, siga estos pasos:

1. Investigue si se está produciendo un bloqueo o si puede identificar un gran volumen de trabajos simultáneos. Ejecute la consulta siguiente para examinar las solicitudes actuales y comprobar si hay un bloqueo cuando la base de datos devuelva el error 10928. Es posible que tenga que conectarse con la conexión de administrador dedicada (DAC) para ejecutar la consulta.

   SELECT
       r.session_id, r.request_id, r.blocking_session_id, r.start_time, 
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       (SELECT COUNT(*) 
           FROM sys.dm_os_tasks AS t 
           WHERE t.session_id=r.session_id and t.request_id=r.request_id) AS worker_count,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1;
   GO
   

   1. Busque filas con blocking_session_id para identificar las sesiones bloqueadas. Busque cada blocking_session_id en la lista para determinar si esa sesión también está bloqueada. Al seguir los valores blocking_session_id y session_id, finalmente, se le dirigirá al bloqueador principal: una sesión que no está bloqueada, pero que bloquea. Optimice la consulta del bloqueador de encabezado.

      Sugerencia

      Para obtener más información sobre cómo solucionar problemas de consultas de larga duración o bloqueo, consulte Descripción y resolución de problemas de bloqueo.

   2. Para identificar un gran volumen de trabajos simultáneos, revise el número de solicitudes en general y la columna worker_count de cada solicitud. Worker_count es el número de trabajadores en el momento de la muestra tomada y puede cambiar a lo largo del tiempo a medida que se ejecuta la solicitud. Ajuste las consultas para reducir el uso de recursos si el aumento de los trabajadores se debe a consultas concurrentes que se ejecutan en su grado óptimo de paralelismo. Para información adicional, consulte Ajuste de consultas/Indicación.

2. Evalúe el grado máximo de paralelismo (MAXDOP) de la base de datos.

Aumento de los límites de trabajadores

Si la base de datos o el grupo elástico alcanzan su límite de trabajo de manera constante a pesar de haber solucionado el bloqueo, optimizado consultas y validado la configuración de MAXDOP, debería considerar escalar la base de datos o el grupo elástico para aumentar el límite de trabajadores.

Encuentre límites de recursos Azure SQL Database por nivel de servicio y tamaño de proceso a continuación:

• Límites de recursos para bases de datos únicas que utilizan el modelo de compra vCore
• Límites de recursos para grupos elásticos que usan el modelo de compra de núcleo virtual
• Límites de recursos para bases de datos únicas que usan el modelo de compra de DTU
• Límites de recursos para grupos elásticos que utilizan el modelo de compra de DTU

Obtenga más información sobre el gobierno de trabajos de recursos de Azure SQL Database.

Error 10929: Identificador de recurso: 1

10929: Resource ID: 1. The %s minimum guarantee is %d, maximum limit is %d and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. See http://go.microsoft.com/fwlink/?LinkId=267637 for assistance. Otherwise, please try again later.

Error 40501: El servicio está ocupado actualmente

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

El error 40501 es un error de limitación del motor, que indica que se superan los límites de los recursos.

Para obtener más información sobre los límites de recursos, consulte Administración de recursos de Azure SQL Database.

Error 40544: La base de datos ha alcanzado su cuota de tamaño

40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: <ID>. Code: <code>.

Este error se produce cuando la base de datos ha alcanzado su cuota de tamaño.

Los pasos siguientes pueden ayudarle a solucionar el problema o proporcionarle más opciones:

1. Compruebe el tamaño actual de la base de datos mediante el panel en Azure Portal.

   Nota:

   Para identificar qué tablas consumen más espacio y, por lo tanto, son posibles candidatos para la limpieza, ejecute la siguiente consulta SQL:

   SELECT o.name,
    SUM(p.row_count) AS 'Row Count',
    SUM(p.reserved_page_count) * 8.0 / 1024 AS 'Table Size (MB)'
   FROM sys.objects o
   JOIN sys.dm_db_partition_stats p on p.object_id = o.object_id
   GROUP BY o.name
   ORDER BY [Table Size (MB)] DESC;
   GO
   

2. Si el tamaño actual no supera el tamaño máximo admitido para la versión, puede usar ALTER DATABASE para aumentar el valor de MAXSIZE.

3. Si la base de datos ya supera el tamaño máximo admitido para la edición, pruebe uno o varios de los pasos siguientes:

   • Realice actividades normales de limpieza de la base de datos. Por ejemplo, limpie los datos no deseados utilizando truncar/eliminar, o bien mueva los datos utilizando SQL Server Integration Services (SSIS) o la utilidad de copia masiva (bcp).
   • Cree particiones o elimine datos, quite índices o consulte la documentación para obtener soluciones posibles.
   • Para el escalado de la base de datos, consulte Escalar recursos de base de datos única y Escalar recursos de grupos elásticos.

Error 40549: La sesión se ha terminado debido a una transacción de larga duración.

40549: Session is terminated because you have a long-running transaction. Try shortening your transaction.

Si se encuentra con frecuencia este mensaje de error, siga estos pasos para intentar resolver el problema:

1. Ejecute la consulta siguiente para ver las sesiones abiertas que tengan un valor elevado en la columna duration_ms:

   SELECT
       r.start_time, DATEDIFF(ms,start_time, SYSDATETIME()) as duration_ms, 
       r.session_id, r.request_id, r.blocking_session_id,  
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1
   ORDER BY start_time ASC;
   GO
   

   Puede ignorar las filas en las que la columna input_buffer muestra una consulta que lee desde sys.fn_MSxe_read_event_stream: estas solicitudes están relacionadas con sesiones de Eventos Extendidos.

2. Revise la columna blocking_session_id para ver si el bloqueo contribuye a transacciones de larga duración.

   Nota:

   Para más información sobre cómo solucionar problemas de bloqueo en Azure SQL Database, consulte Descripción y resolución de problemas de bloqueo.

3. Le recomendamos que procese por lotes las consultas. Para obtener más información sobre el procesamiento por lotes, consulte Cómo usar el procesamiento por lotes para mejorar el rendimiento de las aplicaciones de Azure SQL Database y Azure SQL Managed Instance.

Error 40551: La sesión se ha terminado debido al uso excesivo de tempdb

40551: The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage.

Para resolver el problema, siga estos pasos:

1. Modifique las consultas para reducir el uso de espacio en tablas temporales.
2. Quite los objetos temporales cuando ya no se necesiten.
3. Trunque las tablas o quite las que no se usen.

Error 40552: La sesión ha terminado debido al uso excesivo del espacio de registro de transacciones

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Para resolver este problema, pruebe los métodos siguientes:

• El problema puede producirse debido a operaciones de inserción, actualización o eliminación. Intente reducir el número de filas que en las que se trabaja inmediatamente al implementar el procesamiento por lotes o al dividir las transacciones en varias más pequeñas.
• El problema puede producirse debido a operaciones de recompilación de índices. Para solucionar este problema, asegúrese de que el número de filas afectadas de la tabla * (tamaño medio del campo que se actualiza en bytes + 80) < 2 gigabytes (GB).
• Para la recompilación del índice, el tamaño medio del campo que se actualiza debe sustituirse por el tamaño medio del índice.
• Para más información, vea Solución de errores de un registro de transacciones completo en Azure SQL Database y Solución de errores de un registro de transacciones completo en Azure SQL Managed Instance.

Error 40553: La sesión ha terminado debido al uso excesivo de la memoria

40553: The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

Para solucionar este problema, intente optimizar la consulta.

Para un procedimiento de solución de problemas detallado, consulte ¿Se ejecuta correctamente mi consulta en la nube?

Para más información sobre otros errores de memoria insuficiente y consultas de ejemplo, vea Solución de problemas de errores de memoria insuficiente con Azure SQL Database.

Tabla de mensajes de error de gobierno de recursos

Errores de grupos elásticos

Los errores siguientes están relacionados con la creación y el uso de grupos elásticos:

No se puede abrir la base de datos maestra solicitada por el inicio de sesión. Error de inicio de sesión

Este problema se produce porque la cuenta no tiene permiso de acceso a la base de datos master. Por defecto, SQL Server Management Studio (SSMS) intenta conectarse a la base de datos master.

Para resolver el problema, siga estos pasos:

1. En la pantalla de inicio de sesión de SSMS, seleccione Opciones y, luego, Propiedades de la conexión.

2. En el campo Conectar con base de datos, escriba el nombre de la base de datos predeterminada del usuario como la base de datos de inicio de sesión predeterminada y seleccione Conectar.

   

Errores de solo lectura

Si intenta escribir en una base de datos de solo lectura, recibirá un error. En algunos escenarios, es posible que la causa del estado de solo lectura de la base de datos no esté clara inmediatamente.

Error 3906: No se pudo actualizar la base de datos "databaseName" porque es de solo lectura.

Al intentar modificar una base de datos de solo lectura, se producirá el siguiente error.

Msg 3906, Level 16, State 2, Line 1
Failed to update database "%d" because the database is read-only.

Hay varias explicaciones posibles de por qué una base de datos es de solo lectura.

Después de una conmutación por error manual, las aplicaciones todavía se conectan a la réplica antigua

En Azure SQL Database, después de una conmutación por error a otra réplica, puede que tu aplicación aún se conecte a la réplica principal anterior debido al DNS. El enrutamiento de conexiones de grupo de conmutación por error se implementa mediante DNS.

Posible causa principal:

1. Durante la conmutación por error, los puntos de conexión del grupo de conmutación por error se actualizan para que apunten a los nuevos servidores principales y secundarios adecuados cambiando el destino de la entrada DNS adecuada. De forma predeterminada, las entradas DNS se crean con un TTL de 30 segundos, lo que significa que los clientes DNS almacenan en caché estas entradas durante 30 segundos. Como resultado, las actualizaciones de los registros DNS no se propagan inmediatamente; las entradas estarán obsoletas hasta que todos los clientes y nodos intermedios hayan actualizado sus memorias caché. Por lo tanto, después de una conmutación por error, puede tardar entre 0 y aproximadamente 10 minutos (dependiendo de la topología de red) para que los inicios de sesión se enruten a los nuevos destinos a través de los endpoints del grupo de conmutación. El vaciado de cachés DNS podría o no ayudar al problema, ya que los nodos de red intermedios que responden a las solicitudes DNS también almacenan en caché los resultados de DNS durante un tiempo.

   La solución alternativa recomendada para este problema es simplemente esperar hasta que las entradas DNS se actualicen en el cliente. Actualmente, esta solución alternativa provocaría que el problema se resuelva dentro de 10 minutos.

2. Algunas bibliotecas de cliente SQL usan una característica denominada "agrupación de conexiones" que reutiliza las conexiones al mismo origen de datos en lugar de cerrarlas y volver a abrirlas siempre que se necesite una nueva conexión de base de datos. En particular, la agrupación de conexiones está activada en ADO.NET de manera predeterminada. Cuando se combina con el problema descrito en 1), la agrupación de conexiones puede provocar que las conexiones recién abiertas reutilicen una conexión a la base de datos antigua, lo que impide que la aplicación se conecte a la nueva base de datos principal indefinidamente.

Soluciones:

Hay tres posibles soluciones alternativas a este problema de DNS después de una conmutación de un grupo de failover:

1. Modifique la aplicación para llamar a SQLConnection.ClearAllPools o SQLConnection.ClearPool(conn) cada vez que se encuentre un error de solo lectura.
2. En la aplicación cadena de conexión, especifique Pooling=False para deshabilitar la agrupación de conexiones. Esto se debe probar, ya que podría afectar significativamente al rendimiento si la aplicación se abre y cierra las conexiones con frecuencia.
3. Otra opción para evitar los retrasos de replicación o de caché DNS es conectarse directamente mediante el nombre del servidor lógico de base de datos de Azure SQL (del servidor secundario original, ahora el nuevo principal) durante un período de tiempo después de que se encuentre 3906.

Es posible que esté conectado a una réplica de solo lectura

Tanto para Azure SQL Database como para Azure SQL Managed Instance, es posible que esté conectado a una base de datos en una réplica de solo lectura. En este caso, la consulta siguiente que usa la función DATABASEPROPERTYEX() devolverá READ_ONLY:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
GO

Si va a conectarse mediante SQL Server Management Studio, compruebe si ha especificado ApplicationIntent=ReadOnly en la pestaña Parámetros de conexión adicionalesen las opciones de conexión.

Si la conexión procede de una aplicación o un cliente que usa una cadena de conexión, valide si la cadena de conexión ha especificado ApplicationIntent=ReadOnly. Obtenga más información en Conexión a una réplica de solo lectura.

La base de datos podría estar en solo lectura

Si está usando la base de datos de Azure SQL, es posible que la propia base de datos se haya configurado en modo de solo lectura. Puede comprobar el estado de la base de datos con la siguiente consulta:

SELECT name, is_read_only
FROM sys.databases
WHERE database_id = DB_ID();

Puede modificar el estado de solo lectura de una base de datos en Azure SQL Database mediante ALTER DATABASE Transact-SQL. Actualmente no se puede establecer una base de datos de una instancia administrada en solo lectura.

Confirmación de si un error se debe a un problema de conectividad

Para confirmar si un error se debe a un problema de conectividad, revise el seguimiento de la pila de los marcos que muestran llamadas para abrir una conexión como las siguientes (observe la referencia a la clase SqlConnection):

System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
 at System.Data.SqlClient.SqlConnection.Open()
 at AzureConnectionTest.Program.Main(String[] args)
ClientConnectionId:<Client connection ID>

Cuando se produce la excepción por problemas de consulta, observará una pila de llamadas similar a la siguiente (observe la referencia a la clase SqlCommand). En esta situación, optimice las consultas .

  at System.Data.SqlClient.SqlCommand.ExecuteReader()
  at AzureConnectionTest.Program.Main(String[] args)
  ClientConnectionId:<Client ID>

Para obtener más información sobre el ajuste fino del rendimiento, consulte lo siguiente:

• Mantenimiento de índices y estadísticas de Azure SQL
• Ajustar el rendimiento de aplicaciones de base de datos y bases de datos en Azure SQL Database
• Supervisión del rendimiento mediante vistas de administración dinámica
• Funcionamiento del almacén de consultas de Azure SQL Database

Contenido relacionado

• Arquitectura de conectividad
• Controles de acceso a la red de Azure SQL Database y Azure Synapse Analytics
• Solución de problemas de un registro de transacciones lleno en Azure SQL Database
• Solución de problemas de un registro de transacciones lleno en Azure SQL Managed Instance
• Solución de problemas de errores de conexión transitorios
• Análisis y prevención de interbloqueos en Azure SQL Database y Fabric SQL Database