{"id":2540,"date":"2014-09-25T12:20:36","date_gmt":"2014-09-25T15:20:36","guid":{"rendered":"https:\/\/alfagestion.com.ar\/faq\/?p=2540"},"modified":"2016-05-02T16:39:24","modified_gmt":"2016-05-02T19:39:24","slug":"sql-server-2000-base-en-estado-suspect","status":"publish","type":"post","link":"https:\/\/www.alfagestion.com.ar\/ag\/sql-server-2000-base-en-estado-suspect\/","title":{"rendered":"SQL Server 2000 \u2013 Base en estado Suspect"},"content":{"rendered":"

Base de Datos Sospechosa (Suspect), recuperaci\u00f3n con sp_resetstatus y DBCC DBRECOVER, y el Modo de Emergencia
\n<\/strong><\/span><\/p>\n

Volver a: [SQL Server FAQ :: Preguntas y Respuestas Frecuentes de SQL Server :: Manual SQL Server]<\/strong><\/span><\/a>
\n\t\t\t<\/strong><\/span><\/p>\n

<\/p>\n\n\n\n<\/colgroup>\n\n\n
\u00a0<\/td>\n\n

Un problema t\u00edpico en Administraci\u00f3n de Bases de Datos SQL Server, es encontrar una Base de Datos Sospechosa (Suspect). Una base de datos est\u00e1 en estado Sospechosa (Suspect)\u00a0cuando SQL Server no es capaz de garantizar la integridad de sus datos<\/strong>, siendo este un error habitualmente relacionado con problemas de acceso a disco, y con ca\u00eddas no ordenadas de SQL Server (ej: p\u00e9rdida del suministro el\u00e9ctrico que pueda provocar corrupci\u00f3n o p\u00e9rdida de informaci\u00f3n de los discos). Cuando una base de datos est\u00e1 en estado Sospechoso (Suspect), no es posible acceder a la misma\u00a0\u00bfC\u00f3mo reparar una Base de Datos Sospechosa (Suspect)?<\/strong>\u00a0\u00bfQu\u00e9 hace sp_resetstatus?\u00a0\u00bfC\u00f3mo ejecutar sp_resetstatus y DBCC DBRECOVER? \u00bfEs necesario reiniciar la instancia? \u00bfC\u00f3mo establecer el Modo de Emergencia para extraer datos?<\/strong><\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\n\u00a0<\/p>\n\n\n<\/colgroup>\n\n\n
\n

Este art\u00edculo est\u00e1 orientado al problema de\u00a0Base de Datos Sospechosa (Suspect) en SQL Server 2000<\/strong>, quedando fuera de alcance el problema de\u00a0Base de Datos Sospechosa (Suspect) en SQL Server 2005<\/strong><\/span><\/a>, al existir diferencias en el procedimiento de recuperaci\u00f3n.
\n<\/span><\/p>\n

Bases de Datos en Estado Sospechoso (Suspect) \u00bfQu\u00e9 es eso de “Sospechoso”? \u00bfA qu\u00e9 se debe?
\n<\/strong><\/span><\/p>\n

Cuando SQL Server detecta\u00a0problemas de integridad en los ficheros<\/strong>\u00a0de en una base de datos, marca dicha base de datos como Sospechosa (Suspect), de tal modo, que a partir de dicho momento no ser\u00e1 posible acceder a dicha\u00a0base de datos<\/strong><\/span><\/a>\u00a0(digamos que es un m\u00e9todo de autodefensa ;-).
\n<\/span><\/p>\n

Este comportamiento (marcar la base de datos como sospechosa y prevenir que se pueda acceder a dicha base de datos), tiene car\u00e1cter preventivo, debido a que habitualmente este tipo de problemas de integridad suelen venir motivados por problemas o errores de acceso a disco, y en estos escenarios lo mejor es parar los motores (madrecita, que me quede como estoy ;-), ya que mantener el acceso a una base de datos en dicho estado s\u00f3lo podr\u00eda generar a\u00fan m\u00e1s problemas.\u00a0En este caso (fichero o ficheros corruptos), ser\u00e1 necesario restaurar una copia de la base de datos, aunque quiz\u00e1s pueda interesar previamente poner la base de datos en modo de emergencia para realizar una descarga de los datos de las tablas<\/strong>\u00a0(con la esperanza de poder salvar todo aquello susceptible de ser salvado, por si en un futuro, es necesario).
\n<\/span><\/p>\n

Este no es el \u00fanico escenario posible, existiendo otros escenarios como que\u00a0durante el arranque de la instancia no se consigue acceso exclusivo a los ficheros de base de datos<\/strong>\u00a0(ej: por la realizaci\u00f3n de un backup, por la eliminaci\u00f3n de los ficheros, etc.).
\n<\/span><\/p>\n

Otra raz\u00f3n por la que se puede poner una base de datos sospechosa, es\u00a0por problemas de lectura de los ficheros<\/strong>\u00a0(ej: problemas con drivers). En este caso, SQL Server puede pensar que realmente tiene alg\u00fan fichero corrupto (poniendo la base de datos en estado sospechoso), cuando realmente no existe tal problema. En este caso,\u00a0se deber\u00e1 solucionar el problema de lectura de ficheros (ej: actualizar drivers de acceso a disco) y quitar la marca de sospechosa (suspect)<\/strong>\u00a0de la base de datos (tuve un caso con un SQL Server 2000 con discos\u00a0iSCSI<\/strong><\/span><\/a>\u00a0por un Target Cisco que montaba discos de un Storage de HP, una EVA 5000).
\n<\/span><\/p>\n

El aspecto que muestra una base de datos en estado Sospechoso (Suspect) en el Enterprise Manager (EM) es el siguiente:
\n<\/span><\/p>\n

\"\"
\n\t\t\t\t\t\t\t\t<\/span><\/p>\n

A continuaci\u00f3n se muestra un ejemplo del ERRORLOG, durante el inicio de una Instancia de SQL Server con una Base de Datos Sospechosa (Suspect):
\n<\/span><\/p>\n

\n\n\n<\/colgroup>\n\n\n
\n

2008-04-02 17:50:26.54 server Microsoft SQL Server 2000 – 8.00.2039 (Intel X86)\u00a0
May 3 2005 23:18:38\u00a0
Copyright (c) 1988-2003 Microsoft Corporation\u00a0
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)\u00a0<\/p>\n

2008-04-02 17:50:26.54 server Copyright (C) 1988-2002 Microsoft Corporation.
2008-04-02 17:50:26.54 server All rights reserved.
2008-04-02 17:50:26.54 server Server Process ID is 1680.
2008-04-02 17:50:26.54 server Logging SQL Server messages in file ‘D:\\ MSSQL\\log\\ERRORLOG’.
2008-04-02 17:50:26.59 server SQL Server is starting at priority class ‘high'(4 CPUs detected).
2008-04-02 17:50:26.67 server SQL Server configured for thread mode processing.
2008-04-02 17:50:26.68 server Using dynamic lock allocation. [2500] Lock Blocks, [5000] Lock Owner Blocks.
2008-04-02 17:50:26.74 server Attempting to initialize Distributed Transaction Coordinator.
2008-04-02 17:50:39.25 spid3 Starting up database ‘master’.
2008-04-02 17:50:40.65 server Using ‘SSNETLIB.DLL’ version ‘8.0.2039’.
2008-04-02 17:50:40.65 spid5 Starting up database ‘model’.
2008-04-02 17:50:40.70 spid3 Server name is ‘VSQL01’.
2008-04-02 17:50:40.70 spid8 Starting up database ‘msdb’.
2008-04-02 17:50:40.70 spid9 Starting up database ‘GuilleSQL’.<\/strong>
2008-04-02 17:50:40.74 server SQL server listening on 192.168.69.61: 1433.
2008-04-02 17:50:40.74 server SQL server listening on 127.0.0.1: 1433.
2008-04-02 17:50:40.79 server SQL server listening on TCP, Shared Memory, Named Pipes.
2008-04-02 17:50:40.81 server SQL Server is ready for client connections
2008-04-02 17:50:41.42 spid5 Clearing tempdb database.
2008-04-02 17:50:42.01 spid5 Starting up database ‘tempdb’.
2008-04-02 17:50:46.14 spid9 Bypassing recovery for database ‘GuilleSQL’ because it is marked SUSPECT.<\/strong>
2008-04-02 17:50:46.76 spid3 Recovery complete.<\/strong>
2008-04-02 17:50:46.76 spid3 SQL global counter collection task is created.
2008-04-02 17:50:53.70 logon Login failed for user ‘NT AUTHORITY\\SYSTEM’.
2008-04-02 17:50:54.23 spid51 Using ‘xpsqlbot.dll’ version ‘2000.80.2039’ to execute extended stored procedure ‘xp_qv’.
2008-04-02 17:50:55.54 logon Login failed for user ‘NT AUTHORITY\\SYSTEM’.<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

En cualquier caso, si detectamos una base de datos en estado Sospechoso (Suspect) \u00bfQu\u00e9 podemos hacer? \u00bfC\u00f3mo debemos actuar? \u00bfC\u00f3mo recuperar una base de datos en estado Sospechosa (Suspect)?
\n<\/span><\/p>\n

Base de Datos en Modo de Emergencia, extracci\u00f3n masiva de datos como \u00faltimo recurso ante corrupci\u00f3n de datos
\n<\/strong><\/span><\/p>\n

Antes de nada, evidentemente deberemos verificar si tenemos o no problemas de acceso disco, tanto comprobando la existencia de errores en el Visor de Sucesos del Sistema, como asegurarnos si se ha subido de versi\u00f3n de Firmware o Drivers (ya sea el servidor, o alguno de los elementos de Almacenamiento, como ocurre con entornos de\u00a0redes de almacenamiento SAN e iSCSI<\/strong><\/span><\/a>). Es importante, determinar:
\n<\/span><\/p>\n