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 blackslotdb por la bd a consultar):
SELECT state_desc FROM sys.databases WHERE name = ‘blackslotdb’;
Si la bd 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
En la segunda parte de este post comentaremos como reparar si la bd se encuentra en alguno de los otros 2 modos o no se puede adjuntar.
Comentarios desactivados | Archivado como Sistemas TI | 25/04/2012





