Uso de Resource Health para solucionar problemas de conectividad para Azure SQL Database e Instancia administrada de Azure SQL

  • Artículo
  • Tiempo de lectura: 3 minutos

SE APLICA A: Azure SQL Database Azure SQL Managed Instance

Resource Health para Azure SQL Database e Instancia administrada de Azure SQL ayuda a diagnosticar problemas y obtener soporte técnico cuando un problema de Azure afecte a los recursos de SQL. Le informa acerca del mantenimiento actual y pasado de los recursos y le ayuda a mitigar los problemas. Resource Health le proporciona soporte técnico si necesita ayuda con los problemas de los servicios de Azure.

Información general

Comprobaciones de mantenimiento

Resource Health determina el estado del recurso de SQL al examinar el estado correcto o erróneo de los inicios de sesión para el recurso. Actualmente, Resource Health para el recurso de SQL Database solo examina los errores de inicio de sesión debido a errores del sistema y no a errores del usuario. El estado de Resource Health se actualiza cada 1 a 2 minutos.

Estados de mantenimiento

Disponible

Un estado de Disponible significa que Resource Health no ha detectado errores de inicio de sesión debido a errores del sistema en el recurso de SQL.

Disponible

Degradado

Un estado de Degradado significa que Resource Health ha detectado una mayoría de inicios de sesión correctos, pero también algunos errores. Probablemente estos sean errores transitorios de inicio de sesión. Para reducir el impacto de los problemas de conexión provocados por errores transitorios de inicio de sesión, implemente la lógica de reintento en el código.

Degradado

No disponible

Un estado de No disponible significa que Resource Health ha detectado errores constantes de inicio de sesión al recurso de SQL. Si el recurso permanece en este estado durante un largo período, póngase en contacto con soporte técnico.

No disponible

Desconocido

Este estado de mantenimiento indica que Resource Health no ha recibido información sobre este recurso durante más de 10 minutos. Si bien este estado no es una indicación definitiva del estado del recurso, es un punto de datos importante en el proceso de solución de problemas. Si el recurso se ejecuta según lo esperado, el estado del recurso cambia a Disponible al cabo de unos minutos. Si tiene problemas con el recurso, el estado de mantenimiento Desconocido podría sugerir que un evento de la plataforma afecta al recurso.

Desconocido

Información histórica

Puede obtener acceso al historial de mantenimiento de hasta 14 días en la sección Historial de estado de Resource Health. La sección también contendrá el motivo del tiempo de inactividad (si está disponible) para los tiempos de inactividad notificados por Resource Health. Actualmente, Azure muestra el tiempo de inactividad para el recurso de base de datos con una granularidad de dos minutos. Es probable que el tiempo de inactividad real sea de menos de un minuto. El promedio es de 8 segundos.

Motivos del tiempo de inactividad

Cuando la base de datos experimenta un tiempo de inactividad, se realizan análisis para determinar un motivo. Cuando esté disponible, el motivo del tiempo de inactividad se notifica en la sección Historial de estado de Resource Health. Los motivos de tiempo de inactividad se publican normalmente en un plazo de 45 minutos después de un evento.

Mantenimiento planeado

La infraestructura de Azure realiza periódicamente un mantenimiento planeado: actualización de componentes de hardware o software en el centro de datos. Mientras la base de datos se somete a mantenimiento, Azure SQL puede terminar algunas conexiones existentes y rechazar otras nuevas. Los errores de inicio de sesión sufridos durante un mantenimiento planeado suelen ser transitorios y la lógica de reintento ayuda a reducir el impacto. Si sigue experimentando errores de inicio de sesión, póngase en contacto con soporte técnico.

Reconfiguración

Las reconfiguraciones se consideran condiciones transitorias y se espera que se produzcan de vez en cuando. Estos eventos pueden desencadenarse por errores de software y hardware o de equilibrio de carga. Cualquier aplicación de producción cliente que se conecte a un servicio de base de datos en la nube debe implementar una lógica de reintento de conexión sólida, ya que podría ayudar a mitigar estas situaciones y, en general, debería hacer que los errores sean transparentes para el usuario final.

Pasos siguientes