Blog gratis
Reportar
Editar
¡Crea tu blog!
Compartir
¡Sorpréndeme!
img
img

 

 

SQL Server
Blog. (Apuntes y Recopilaciones) por Norman M. Pardell

img
img
15 de Junio, 2011 · Suspect

Base de Datos Sospechosa (Suspect)

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

 

publicado por normanmpardell a las 06:02 · Sin comentarios  ·  Recomendar
Comentarios (0) ·  Enviar comentario
Esta entrada no admite comentarios.
img
.Sobre mí
FOTO

Norman M. Pardell

MCITP: Database Administrator & Database Developer, SQL Server 2008. MCC Award Certificate. Consultor Senior de bases de datos en Capgemini España, S.L. Asesoramiento en implementación, desarrollo y gestión de bases de datos en grandes compañías. Actualmente, asignado a proyecto en compañía líder en el sector energético global. Más de 10 años trabajando con SQL Server (y otros gestores de BBDD)

» Ver perfil

img
.Secciones
» Inicio
img
.Enlaces
» Microsoft MSDN Foros
» Windows Server 2012
img
.Más leídos
» Asignar la cantidad correcta de Memoria para SQL Server
» Base de Datos Sospechosa (Suspect)
» Como modificar la Intercalación (Collation) en SQL Server
» Conectar a SQL Server con Native Client. Y problemas relacionados.
» Detectar bloqueos. SQL Server V.2005 y superiores
» Funciones SQL Server. Funciones escalares y funciones con valores de tabla.
» Integridad y corrupción en las bases de datos: DBCC CHECKDB
» Log de transacciones ( .ldf ). SQL Server.
» Tomo I. Memoria RAM. Optimización de sistemas de 32 y 64 bits. SQL Server 2008.
» Transacciones activas. SQL server 2008
img
.Nube de tags [?]
                                                           
img img
FULLServices Network | Crear blog | Privacidad