Share via


Uso de Resource Health para solucionar problemas de conectividad para Azure SQL Database

Se aplica a:Azure SQL Database

Resource Health para Azure SQL Database le ayuda a diagnosticar si un problema de Azure afecta a los recursos de y, en su caso, a obtener soporte técnico. Le informa acerca del mantenimiento actual y pasado de los recursos y le ayuda a mitigar los problemas. En la página Resource Health se proporciona soporte técnico cuando necesita ayuda con problemas de los servicios de Azure.

Screenshot of the Azure portal showing the Resource Health page for an Azure SQL Database.

Comprobaciones de mantenimiento

Resource Health determina el estado de la base de datos de SQL mediante el examen del 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 los del usuario. El estado de Resource Health se actualiza cada 1 a 2 minutos.

Estados de mantenimiento

Disponible

Un estado Disponible significa que Resource Health no detectó errores de inicio de sesión debido a errores del sistema en la base de datos SQL, o que hubo algunos errores de inicio de sesión, pero no cumplen el umbral de alerta. En las secciones siguientes se proporcionan más detalles sobre el umbral de alerta.

Screenshot of the Azure portal showing the status message for the state of Available.

Degradado

Un estado Degradado significa que, en cualesquiera dos minutos de los últimos tres minutos, Resource Health detectó:

  • la mayoría de los inicios de sesión correctos, pero también hubo más de un error de inicio de sesión (debido a errores del sistema) o
  • más de un error de inicio de sesión (debido a errores del sistema), pero hubo menos de seis intentos de inicio de sesión totales.

Probablemente estos sean errores transitorios de inicio de sesión. Para reducir el efecto 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.

Screenshot of the Azure portal showing the status message for the state of Degraded.

No disponible

Un estado No disponible significa que Resource Health detectó que había más de cinco intentos de inicio de sesión en el último minuto, y más de una cuarta parte de ellos generaban errores por motivos del sistema. Si el recurso permanece en este estado durante un largo período, póngase en contacto con el Soporte técnico de Microsoft.

Screenshot of the Azure portal showing the status message for the state of Unavailable.

Unknown

El estado de mantenimiento Desconocido 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.

Screenshot of the Azure portal showing the status message for the state of Unknown.

Hora de la alerta

La hora que muestra la alerta de Resource Health no se alinea con las horas de los errores de inicio de sesión que provocaron la alerta. Esto se debe a que la telemetría tarda varios minutos en recopilarse y analizarse, para determinar que hay un problema de Resource Health. Por lo tanto, la hora indicada en la alerta de Resource Health será varios minutos después de los errores de inicio de sesión.

Además, el intervalo de tiempo en el que se produjeron errores de inicio de sesión a menudo puede ser menor que el intervalo de tiempo de la alerta de Resource health.

Información histórica

Puede acceder al historial de mantenimiento de hasta 30 días en la sección Historial de estado de Resource Health. La sección también contiene el motivo del tiempo de inactividad (si está disponible). 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.

Selección de una ventana de mantenimiento

Puede configurar la ventana de mantenimiento para hacer eventos de mantenimiento de alto impacto predecibles y menos perjudiciales para la carga de trabajo. La característica de ventana de mantenimiento le ayuda a planear actualizaciones predecibles o mantenimiento programado. Hay Notificaciones avanzadas disponibles para las bases de datos que se configuran para usar un valor no predeterminado de ventana de mantenimiento. Notificaciones anticipadas permite a los clientes configurar notificaciones para que se envíen hasta 24 horas antes de cualquier evento planeado.

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 para errores de red ocasionales ayuda a reducir el efecto. 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 para errores temporales, ya que podría ayudar a mitigar estas situaciones y, en general, hacer que los errores sean transparentes para el usuario final.