Freigeben über

Base de datos en estado SUSPECT ¿A qué se debe?

  • Artikel

Por Daniel Torres Garrido

Una parte significativa del volumen de casos que recibimos en el equipo de escalación de SQL Server LATAM está relacionada con bases de datos en estado suspect o sospechoso. Generalmente cuando esto ocurre la percepción de los administradores de bases de datos o responsables de la información es que ha ocurrido un fallo en el producto de SQL Server que puede ser reparado.

En este escenario debemos entender claramente qué significa el estado SUSPECT en una base de datos. Para poder entenderlo debemos remontar a un nivel más granular que es la corrupción en una página de datos. Lo ideal sería que nunca tuviéramos que lidiar con la corrupción en una base de datos sin embargo los componentes del hardware fallan, existen interrupciones en el suministro de energía eléctrica, los controladores de los discos o los discos en sí, son propensos a fallos y pueden corromper las páginas de datos mediante escrituras incompletas. Desde la versión 2005 se introdujo al producto de SQL Server la habilidad de colocar en cuarentena las páginas corruptas y se da la oportunidad de que la base de datos siga en línea. Usted puede detectar corrupción utilizando la opción PAGE_VERIFY CHECKSUM en su base de datos a través del siguiente comando:

 ALTER DATABASE <dbname> SET PAGE_VERIFY CHECKSUM

Cuando SQL Server escribe a disco se calcula un checksum para la página. Cuando se habilita la opción previamente mencionada cada vez que la página se lee de disco SQL Server calcula un nuevo checksum y lo compara con el ckecksum almacenado en el encabezado de la página. Si los checksum no coinciden SQL Server regresa un error 824 que a su vez se registra en el log de errores y en el log de aplicación del servidor, adicionalmente el ID de la página dañada se registra en la tabla suspect_pages dentro de la base de datos MSDB.

A pesar de que las páginas pueden ser colocadas en cuarentena SQL Server tiene un mecanismo de autoprotección que evita a su vez la ocurrencia de una corrupción masiva en la base de datos. En este sentido estamos limitados a tener un total de hasta 1000 páginas corruptas en una base de datos. Cuando se alcanza este límite SQL Server pone la base de datos fuera de línea y coloca el estatus SUSPECT para protegerla de un daño mayor. Es así como llegamos al escenario en que una base de datos está en modo SUSPECT. Hasta el momento podemos concluir:

1. ¿Qué origina que una base de datos pase a modo SUSPECT?

  • Fallas a nivel de hardware en los discos del equipo.
  • Fallas en los controladores drivers de los discos.
  • Falla en el suministro de energía hacia el servidor y/o storage que provocan un shutdown inesperado.
  • Las causas anteriores generan escrituras incompletas que derivan en páginas de datos corruptas.
  • Cuando se alcanza el umbral de 1000 páginas corruptas la base de datos se coloca en modo SUSPECT como mecanismo de autoprotección.
  • Una eventual falla que también puede generar escrituras incompletas es cuando no se realiza el proceso cleanly shut down de una base de datos. Básicamente cuando detenemos el servicio de SQL desde la consola de servicios, Configuration Manager o Cluster Manager, SQL realiza un proceso interno para dar de baja las bases de datos, identificando las transacciones completas e incompletas para dejarlas en un estado consistente. Este proceso generalmente no se lleva a cabo cuando el servidor se apaga inesperadamente ya sea por fallas de energía o un server crash (bluescreen). En este caso se puede generar una corrupción.
  • Otra causa común que provoca corrupción en las páginas de datos es cuando SQL Server deja de tener acceso exclusivo a los archivos de datos y otros procesos los utilizan. Un escenario muy común es cuando no se configuran las excepciones en los antivirus para excluir los archivos de las bases de datos, es entonces que se lanza un proceso de verificación de virus cuando se atrapan los archivos de las bases de datos y se analizan, esto eventualmente corrompe los archivos.

2. ¿Cómo podemos evitar que las bases de datos cambien al estado SUSPECT?

  • Cuando una página se coloca en cuarentena se guarda un registro en la base MSDB. Consulte la tabla suspect_pages para validar la existencia de corrupción:

    Understanding and Managing the suspect_pages Table

    https://msdn.microsoft.com/en-us/library/ms191301(v=sql.105).aspx

  • Revise periódicamente el log de errores de SQL Server y ponga atención a los errores y su severidad.

  • Ejecute periódicamente un DBCC CHECKDB para verificar la integridad de la base de datos. Esta instrucción ejecuta el análisis más completo que hay para detectar corrupción:

    https://msdn.microsoft.com/en-us/library/ms176064(v=sql.105).aspx

  • Involucre a su proveedor de storage para que realice una validación o health check de su sistema de IO y descarte cualquier problema. Adicionalmente verifique que los controladores de sus discos estén actualizados.

  • La mejor forma de estar preparados es tener un adecuado esquema de respaldos que permita restaurar su base de datos a un punto antes de la falla en base al SLA Service Level Agreement definido con el usuario final.

  • Algo importante. Si su base de datos se corrompe frecuentemente o varias de sus bases de datos cambian a estado SUSPECT es muy probable que exista una falla severa en el hardware. Involucre de inmediato a su proveedor.

  • Configure las excepciones en los antivirus para que los archivos de las bases de datos no sean escaneados utilizando el siguiente KB:
    How to choose antivirus software to run on computers that are running SQL Server

    https://support.microsoft.com/kb/309422/en-us

Hasta este punto todas las acciones que podamos tomar son preventivas sin embargo existe un margen de acciones correctivas que pueden ayudar a solucionar el problema.

  1. Si usted detecta corrupción en las páginas de datos verifique en dónde se encuentra. Si esta pertenece a un índice es posible que al regenerar el índice el problema desaparezca sin embargo, si la corrupción se encuentra en una página de datos de la tabla o de la llave primaria necesitará restaurar la página de un respaldo. Lea el siguiente documento que le ayudará a hacerlo.
    RESTORE (Transact-SQL)

    https://msdn.microsoft.com/en-us/library/ms186858.aspx

  2. Utilice el comando DBCC CHECKDB con la opción de reparación de errores sin pérdida de datos. En casos críticos es posible reparar errores CON pérdidas de datos o incluso reconstruir el log de transacciones pero este proceso NO es recomendado ni soportado por Microsoft ya que puede derivar en la pérdida de datos e inconsistencia de la información.

  3. Si la corrupción es severa deberá restaurar la base de datos por completo de los respaldos en base a la estrategia que definió.

En términos generales las bases de datos cambian a estado SUSPECT por corrupción en las páginas de datos generados en muchos de los casos por fallas en el hardware a nivel de discos o por un crash del equipo. Es importante tomar las providencias que tenemos al alcance para evitar caer en este escenario sin embargo una buena estrategia de respaldos le permitirá restaurar sus bases de datos de pérdidas irreparables.