Cuando una base de datos está en estado Sospechoso (Suspect), no es posible acceder a la misma.
SQL Server marca una base de datos como sospechosa si alguno de los archivos de dispositivo para la base de datos no está disponible cuando intenta iniciarse. Al iniciarse, SQL Server intenta obtener un bloqueo exclusivo en el archivo de dispositivo (archivos físicos de base de datos). Si el dispositivo está siendo utilizado por otro proceso (por ejemplo, por software de copia de seguridad) o si no se encuentra el archivo, se encontrará con el escenario en donde marcará una base de datos como sospechosa. En estos casos, normalmente no hay ningún problema con los dispositivos ni con la base de datos. Para que la base de datos se recupere correctamente, el dispositivo debe estar disponible y se debe restablecer el servicio de la base de datos
Otra causa donde podemos encontrar una base de datos en estado Sospechosa (Suspect), es cuando SQL Server no es capaz de garantizar la integridad de sus datos, siendo este un error habitualmente relacionado con problemas de acceso a disco, y con caídas no ordenadas de SQL Server. Este comportamiento, de marcar la base de datos como sospechosa y prevenir que se pueda acceder a dicha base de datos, nos asegura que no se produce el acceso a una base de datos en dicho estado ya que sólo podría generar aún más problemas. En este caso (fichero o ficheros corruptos), será necesario restaurar una copia de la base de datos, aunque quizás nos pueda interesar previamente poner la base de datos en modo de emergencia para realizar una descarga de los datos de las tablas, y así poder recuperar cuanto nos sea posible.
Recuperar una Base de Datos Sospechosa (Suspect) mediante: sp_resetstatus y DBCC DBRECOVER
sp_resetstatus desactiva el indicador de sospechoso de una base de datos. Este procedimiento actualiza las columnas de modo y estado de la base de datos con nombre en sys.databases. Se debe consultar el registro de errores de SQL Server y resolver todos los problemas antes de ejecutar este procedimiento. Después de ejecutar sp_resetstatus, detenga y reinicie la instancia de SQL Server, ya que si tenemos realmente un problema de integridad, al reiniciar la instancia completa de SQL Server, el proceso de inicio comprueba el estado de integridad de la base de datos, y en caso de que se vuelvan a detectar problemas de integridad en dicha base de datos, se volveerá a establecer la base de datos en estado Sospechoso (Suspect).
USE master
GO
EXEC SP_CONFIGURE 'Allow updates',1
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_resetstatus 'BBDD_Suspect'
GO
-- “Reiniciar la instancia de SQL Server”
USE master
GO
EXEC SP_CONFIGURE 'Allow updates',0
GO
RECONFIGURE WITH OVERRIDE
GO
El anterior proceso tiene el inconveniente de que es necesario reiniciar la instancia de SQL, ya que si tenemos una Instancia con múltiples bases de datos de usuarios, esto producirá un corte de servicio para todas las bases de datos.
Como segunda opción:
Si no queremos reiniciar la instancia de SQL, tenemos el comando DBCC DBRECOVER, que podemos utilizar, tras la ejecución del comando sp_resetstatus. El comando DBCC DBRECOVER permitirá levantar y recuperar la base de datos de forma similar a como se hace durante el inicio de la instancia, de tal modo que no sea necesario reiniciar la instancia de SQL Server. El procedimiento a seguir sería el siguiente:
USE master
GO
EXEC SP_CONFIGURE 'Allow updates',1
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_resetstatus 'BBDD_Suspect'
GO
DBCC DBRECOVER('BBDD_Suspect')
GO
USE master
GO
EXEC SP_CONFIGURE 'Allow updates',0
GO
RECONFIGURE WITH OVERRIDE
GO
Se recomienda revisar la información de ERRORLOG de SQL Server, después de la anterior ejecución.
Si no conseguimos reparar una Base de Datos en estado Sospechoso (Suspect)
Si no conseguimos reparar una Base de Datos en estado Sospechoso (Suspect) que tenemos identificada con problemas de corrupción en sus ficheros, podras proceder a recuperar la copia de seguridad más reciente. Previamente, podes intentar poner la base de datos en modo de emergencia, de tal modo, que puedas intentar acceder a dicha base de datos para realizar una descarga del contenido de las tablas.
Establecer El Modo de Emergencia, en una base de datos, sólo nos deja realizarse accesos de sólo lectura, no permite realizar modificaciones, y no utiliza el Log de transacciones para las acciones que realicemos.
Establecer el Modo de Emergencia en una base de datos SQL Server 2000:
USE master
GO
EXEC SP_CONFIGURE 'Allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE sysdatabases
SET status = status | -32768
WHERE name='BBDD_Suspect'
GO
EXEC SP_CONFIGURE 'Allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Establecer el Modo de Emergencia en una base de datos SQL Server 2005:
USE master
GO
ALTER DATABASE BBDD_Suspect SET EMERGENCY
GO
Para realizar esta descarga, del contenido de las tablas, propongo usar la utilidad bcp.exe (http://msdn.microsoft.com/en-us/library/ms162802.aspx).
Pongo un ejemplo, desde el CMD:
Importar a fichero desde tabla, desde la BBDD_Suspect:
bcp BBDD_Suspect.dbo.tb out e: b.dat -U sa -P xxxxx -n -S instanciaSQL
Importar a tabla desde fichero, a una base de datos no suspect:
bcp BBDD.dbo.tb in e: b.dat -U U sa -P xxxxx -n -S instanciaSQL
Para SQL Server 2000, una vez en el Modo de Emergencia, si detectamos que el único problemas de nuestra base de datos esta relacionado con el fichero o ficheros del Log de transacciones, podríamos volver a regenerar los ficheros de Log con el comando: DBCC REBUILD_LOG, ejem.:
DBCC REBUILD_LOG (BBDD_Suspect,'D:SQLDataBBDD_Log.LDF')
El comando DBCC REBUILD_LOG no sólo no está soportado en SQL Server 2005, sino que además ni existe.
En SQL 2005/8 tenemos varias formas de poder regenerar el log de trasacciones.
- CREATE DATABASE FOR ATTACH_REBUILD_LOG:
USE [master]
GO
CREATE DATABASE [BBDD]
ON (FILENAME = N'D:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDataBBDD.mdf')
FOR ATTACH_REBUILD_LOG
- sp_attach_single_file_db:
sp_attach_single_file_db @dbname = 'BBDD' , @physname = 'D:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDataBBDD.mdf'
Como última opción, podemos lanzar DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS,
DBCC CHECKDB (BBDD, REPAIR_ALLOW_DATA_LOSS)
Os aconsejamos reviséis este link:
http://microsoftsqlsecret.fullblog.com.ar/integridad-y-corrupcion-en-las-bases-de-datos-dbcc-checkdb.html
Recordar que para ejecutar un DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS, es requisito poner en modo Single User la base de datos, si os da problemas por tener la base de datos en modo de emergencia, reiniciar la instancia de SQL y luego ejecutar ALTER DATABASE SET SINGLE_USER WITH ROLLBACK IMMEDIATE, antes de lanzar DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS.
Os muestro la secuencia de comando, cuando encontramos bases de datos en “suspect”, y realmente existen paginas de datos dañadas, y los métodos tradicionales o comunes no funcionan para recupera la bbdd. Lo que hay que hacer es: “Tener en cuenta que lo que os voy a pasar, en un primer lugar es para un SQL2000, no para versiones SQL2005 o superiores”:
USE master
GO
EXEC SP_CONFIGURE 'Allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
--Ponemos la bbdd en emergencia:
UPDATE sysdatabases
SET status = status | -32768
WHERE name='BBDDsuspect'
GO
--Forzamos a poner la bbdd ONLINE, aun con Paginas de datos en mal estado:
UPDATE SYSDATABASES SET STATUS=24 WHERE NAME= 'BBDDsuspect'
GO
EXEC SP_CONFIGURE 'Allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
--Chequeamos la integridad de la bbdd:
Use BBDDsuspect
GO
DBCC CHECKDB
--Subsanamos lo errors de integridad:
Use master
GO
ALTER DATABASE BBDDsuspect SET SINGLE_USER;
GO
DBCC CHECKDB (BBDDsuspect, REPAIR_ALLOW_DATA_LOSS)
GO
ALTER DATABASE BBDDsuspect SET MULTI_USER;
GO
--Verificamos que no existen errores de integridad:
Use BBDDsuspect
GO
DBCC CHECKDB
Para versiones SQL2005 o superiores:
ALTER DATABASE BBDDsuspect SET EMERGENCY;
GO
ALTER DATABASE BBDDsuspect SET SINGLE_USER;
GO
DBCC CHECKDB (BBDDsuspect, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
GO
ALTER DATABASE BBDDsuspect SET MULTI_USER;
GO
--Verificamos que no existen errores de integridad:
Use BBDDsuspect
GO
DBCC CHECKDB
