1 comentario

Reparar Base de Datos Sospechosa (Suspect) SQL Server


Como reparar una base de datos sospechosa o en modo suspect?, que opciones tenemos? por que podria estar una base de datos en modo suspect? ,  a continuación dejo un post, donde podemos encontrar la solución de las preguntas anteriores,, no dejen de echarle un vistazo.

SQL Server pone 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 volverá 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

— “Raincoat 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 máster

GO

EXEC SP_CONFIGURE ‘Ello 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) que tenemos identificada con problemas de corrupción en sus ficheros, podrás 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 mas información sobre el mode EMERGENCY les dejo el siguiente link:

https://dbasqlserver.wordpress.com/2012/03/22/como-recuperarse-de-errores-en-bases-utilizando-emergency-mode/

 

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 transacciones.

– 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)

Les aconsejo revisar este link:

https://dbasqlserver.wordpress.com/2012/03/22/cuando-se-debe-reconstruir-el-transaction-log/

 

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.

Les 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

 

Espero les sirva

Saludos

 

 

fuente:

http://microsoftsqlsecret.fullblog.com.ar/base-de-datos-sospechosa-suspect.html

 

 

 

 

Anuncios

Un comentario el “Reparar Base de Datos Sospechosa (Suspect) SQL Server

Si te sirvio o te gusto el post, deja un comentario, o vota por el blog, esto nos ayuda a seguir creciendo, Gracias

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: