Debido a múltiples circunstancias como cortes eléctricos inesperados, problemas de espacio en disco, fallos de hardware, que hayas borrado el archivo de log (.ldf), etc. Una bbdd puede corromperse, normalmente la mejor manera de solucionar esto es recurrir a la última copia de seguridad pero como puede ocurrir en estos casos no hay copia o la que tenemos disponible es ya algo vieja. En esos casos quizá aún podamos recuperar la información.
Una bbdd puede tener estos estados (LINK):
- ONLINE: La base de datos está disponible para su acceso. El grupo de archivos principal está en línea, aunque la fase de deshacer de la recuperación puede no haberse completado.
- OFFLINE: La base de datos no está disponible. Una base de datos pasa a estar sin conexión por la acción explícita del usuario y permanece sin conexión hasta que el usuario toma otra acción. Por ejemplo, la base de datos puede desconectarse para mover un archivo a un nuevo disco. La base de datos se vuelve a poner en línea una vez completado el traslado.
- RESTORING: Uno o varios archivos del grupo de archivos principal se está restaurando, o uno o varios archivos secundarios se están restaurando sin conexión. La base de datos no está disponible.
- RECOVERING: Se está recuperando la base de datos. El proceso de recuperación es un estado transitorio, la base de datos se pone automáticamente en línea si la recuperación tiene éxito. Si la recuperación no tiene éxito, la base de datos pasa a ser sospechosa. La base de datos no está disponible.
- RECOVERY PENDING: SQL Server ha encontrado un error relacionado con un recurso durante la recuperación. La base de datos no está dañada pero pueden faltar archivos o bien limitaciones de recursos del sistema pueden estar impidiendo que se inicie. La base de datos no está disponible. Se necesita una acción adicional por parte del usuario para resolver el error y permitir que se complete el proceso de recuperación.
- SUSPECT: Como mínimo un grupo de archivos principal es sospechoso y puede estar dañado. La base de datos no se puede recuperar durante el inicio de SQL Server. La base de datos no está disponible. Se requiere una acción adicional por parte del usuario para resolver el problema.
-
EMERGENCY: El usuario ha cambiado la base de datos y ha establecido el estado en EMERGENCY. La base de datos está en modo de usuario único y se puede reparar o restaurar. La base de datos está marcada como READ_ONLY, el registro está deshabilitado y el acceso está limitado a miembros de la función fija de servidor sysadmin. EMERGENCY se utiliza principalmente para solucionar problemas. Por ejemplo, una base de datos marcada como sospechosa se puede establecer en el estado EMERGENCY. Esto puede permitir al administrador del sistema acceso de sólo lectura a la base de datos. Sólo los miembros de la función fija de servidor sysadmin pueden establecer una base de datos en el estado EMERGENCY.
Cuando se corrompe la tendremos seguramente en Online, Recovery pending o Suspect.
Puedes ver el estado de la BD utilizando esta consulta (sustituye sergiodb por la bbdd a consultar):
SELECT state_desc FROM sys.databases WHERE name = 'sergiodb';
Si la bbdd está en estado ONLINE, lo más fácil es intentar un checkdb con la opción REPAIR_ALLOW_DATA_LOSS.
DBCC CHECKDB (MAGIC, REPAIR_ALLOW_DATA_LOSS)WITH NO_INFOMSGS
Más info en http://technet.microsoft.com/es-es/library/ms188422.aspx
Mañana publicaré como reparar si la bbdd se encuentra en alguno de los otros 2 modos o no se puede adjuntar.
Entradas (RSS)
TENGO UNA BASE DE DATOS CON ESTADO SUSPECT, COMO PUEDES AYUDARME A CORREGIR ESTO
Buenos días,
me ha sido muy util el manual para reparar bases de datos SQL.
En mi caso, tengo una base de datos SQL 2008 SP1 que esta funcionando correctamente. hace unos dias ejecutamos un proceso de mantenimiento para regenerar indices y previamente un proceso de comprobacion de coherencia de la BBDD. Cual fue nuestra sorpresa cuando aparecieron un monton de errores de coherencia. (Nunca habiamos tenido errores en este proceso).
He visto que ha dos posibles acciones de reparacion con CHECKDB, una de ella indica que puede haber perdida de datos , la otra no pierde datos pero al ejecutarla no ha podido resolver los problemas.
¿Podrias aconsejarme sobre lo que hacer?
un saludo y muchas gracias
Renombra la base de datos para que el agente no la utilice, utiliza el programa force atackch algo asi jeje abre sobre el programa la base de datos dañada y le pones en la opcion de recuperar y ya dejas que trabaje
Hola:
Em primer lugar gracias por lo apuntes que pones, necesito ayuda urgente porque mi cuello pende de un hilo, tengo una base de datos en estado RESTORING, intente hacer un restore y lo pare porque me di cuenta que estaba mal, ahora tengo ese estado en la base de datos y no puedo hacer nada, en el blog en concreto en esta seccion pones que se puede recuperar de ese estado, solo necesitaria poder acceder a las tablas y hacer el backup en concreto de algunas.
¿me podeis ayudar? es muy importante
Un saludo y muchas gracias
tengo una base de datos que cuando la recupero ya me da que esta sin conexion, luego le hago un check catalog y me da error “Mens. 3858, Nivel 16, Estado 1, Línea 1
El atributo (type=) de la fila (object_id=239496082) de sys.objects tiene un valor no válido.”
les pase un DBCC CHECKALLOC (armengol,REPAIR_ALLOW_DATA_LOSS) pero me devuelve :
Resultados de DBCC para ‘ARMENGOL’.
CHECKALLOC detectó 0 errores de asignación y 0 errores de coherencia en la base de datos ‘ARMENGOL’.
Mens. 0, Nivel 11, Estado 0, Línea 0
Error grave en el comando actual. Los resultados, si los hay, se deben descartar.
Mens. 0, Nivel 20, Estado 0, Línea 0
Error grave en el comando actual. Los resultados, si los hay, se deben descartar.
que puedo hacer ?, tengo un monton de copias pero la unica que me restaura correctamente es del 22 de julio.
gracias de antemano