locked
AYUDA Problema con la recuperación de datos debido a un fichero de indices NDF corrupto...

    Question

  • Hola a todos, necesito la ayuda de algun dba con mas experiencia de la mia, ya que me he encontrado con un problema en cuanto a la recuperación de datos de una tabla en mi BDD.

    Os situo, tengo una BDD en SQL Server 2000 con una serie de tablas e indices separadas por diferentes ficheros NDF, el caso es que el fichero que guarda los indices esta corrupto, por lo tanto puedo hacer operaciones de inserción pero no de select, delete o update.

    He probado hacer un drop de la PK pero nada, no hay manera de que lo lleve a termino, siempre me sale el mismo error

    "mensaje 823, nivel 24, estado 2, línea 1"

    Tambien he probado sustituir el fichero de NDF por otro para que no tenga datos, pero sea el que sea el que hago, no hay forma de que cuele, siempre se queda en un estado "sospechoso" que no hay manera de quitar, siempre obtengo el mismo texto:

    "Antes de actualizar la entrada sysdatabases de la base de datos 'XXXXXX', modo = 0 y estado = 1073741848 (estado de suspect_bit = 0).
    No se actualizó ninguna fila de sysdatabases porque el modo y el estado ya estaban restablecidos correctamente. No hubo errores y no se realizaron cambios."

    He probado varias cosas pero ya no hay manera de obtener resultados validos.

    Realmente, con obtener la información contenida en el NDF seria mas que suficiente, pero tampoco puedo acceder a ella.

    Alguien sabe de alguna manera para recuperar esta información, alguna herramienta, o como hacer un drop de la constraint que me da problemas?

    Muchas gracias por vuestra ayuda..

    un saludo
    Tuesday, June 16, 2009 3:37 PM

Answers

  • Hola.

    Por lo que comentas, tienes páginas corruptas que, por suerte para ti, parece ser índices no clustered.

    Debes buscar el backup más reciente que sea restaurable. Aparte, necesitas localizar qué índices están rotos. Si están sólo en una tabla, realiza un dbcc checktable ('MiTabla') with ALL_ERRORMSGS. Eso te dirá qué páginas están rotas y qué índices están afectados.

    Si son índices nonclustered, entonces, lo puedes eliminar el índice y volver a crearlo, sin mayor problema,  se creará de cero y correctamente. 

    Si es el índice clustered de la tabla, entonces, debes asumir que es posible que pierdas datos porque hay páginas corruptas (y el índice clustered son los datos), no leíbles. Para recuperar el acceso al resto de las páginas, las que no están rotas, puedes realizar el dbcc checktable, pero con la opción REPAIR_ALLOW_DATA_LOSS. Luego, con ese backup bueno y restaurable, podrás recuparar parte de lo perdido. También es posible que no se pierda nada.

    Suerte.

    Alberto López Grande.
    Wednesday, June 17, 2009 9:29 AM
  • Bueno, finalmente gracias a todos, al lanzar el proceso con el REPAIR_ALLOW_DATA_LOSS se corrigio correctamente al menos es lo que parece, ahora he eliminado la pk y los indices que me daban problemas, y si que puedo por fin hacer selects, updates y demas...

    La perdida de datos parece ser que ha sido menor de lo esperada, por lo tanto el proceso es valido y funcionando.

    Gracias a todos por vuestra ayuda.
    Wednesday, June 17, 2009 3:13 PM

All replies

  • Jose,

    > el caso es que el fichero que guarda los indices esta corrupto,

    - Que tipo de indices, clustered o nonclustered?


    AMB


    Tuesday, June 16, 2009 5:36 PM
  • Hola has hecho un dbcc checkdb para reparar la base de datos?
    Maxi Accotto Consultoria en SQL Server Buenos Aires - Argentina http://blog.maxiaccotto.com
    Tuesday, June 16, 2009 8:38 PM
  • Antes de hacer algo haria una copia de seguridad.

    Si como dice maxi DBCC CHECKDB no lo resuelve empezaria viendo cuales indices estan corruptos y si no son los clustered los eliminaria para reconstruirlos luego.

    Que quiere decir con "el fichero que guarda los indices" ?

    Puede hacer un select forzando otro indice?

    Saludos



    Ing. Jose Mariano Alvarez http://blog.josemarianoalvarez.com/ Microsoft MVP SQLTotal Consulting Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0 (Cambia los ceros por O y saca lo que sobra) Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase
    Tuesday, June 16, 2009 11:24 PM
  • Hola, gracias por tu pronta respuesta, te puedo comentar que el tipo de indices es nonclustered, si eso te puede ser de ayuda, perfecto, si necesitas saber algo mas, hazmelo saber y te daré toda la información que esté en mi mano.

    GRACIAS
    Wednesday, June 17, 2009 7:53 AM
  • Hola, Gracias por contestar, si que he hecho el checkdb con la sintaxis DBCC CHECKDB (<DATABASE>,REPAIR_REBUILD) pero no ha provocado el resultado esperado, de hecho en la tabla que nos da el problema, la que no nos deja ni hacer un select, nos devolvia el texto "El nivel de reparación de la instrucción DBCC hace que se omita esta reparación"

    Si te vale de algo genial, de todos modos si necesitas mas información avisame por favor.

    Gracias de nuevo

    Wednesday, June 17, 2009 8:02 AM
  • Hola Jose, de nuevo gracias por tu respuesta, te comento los puntos que me preguntas.

    1. Antes de hacer algo haria una copia de seguridad.

    La copia de seguridad ya esta hecha, es lo que tenemos como base para hacer estas pruebas de corrección. El problema es que cuando la restauro ya tengo el fichero fisico corrupto, no se si se puede hacer un restore de un bak en sin usar esos ficheros fisicos que lleva y de este modo, evitar que se replique el error, de hecho tampoco sabria como hacerlo :(

    2. Si como dice maxi DBCC CHECKDB no lo resuelve empezaria viendo cuales indices estan corruptos y si no son los clustered los eliminaria para reconstruirlos luego.

    Ya hice el DBCC CHECKDB (<DATABASE>,REPAIR_REBUILD) y nada, fue poca o nula la solución que me aportó, intento quitar la pk pero nada, no hay manera. Siempre me sale por el mismo error. Ademas cuando hago una select me devuelve solo 6% o menos de los registros que deberia tener. Luego sale por el fallo arriba indicado.

    3. Que quiere decir con "el fichero que guarda los indices" ?

    Con esto me refiero a que tengo los datos en un fichero xxxxxx.ndf y la información de los indices en otro llamado ind_xxxxxx.ndf

    Muchas gracias por todo, a ver si al final consigo aunque sea recuperar datos de esta tabla.

    Gracias
    Wednesday, June 17, 2009 8:16 AM
  • Hola.

    Por lo que comentas, tienes páginas corruptas que, por suerte para ti, parece ser índices no clustered.

    Debes buscar el backup más reciente que sea restaurable. Aparte, necesitas localizar qué índices están rotos. Si están sólo en una tabla, realiza un dbcc checktable ('MiTabla') with ALL_ERRORMSGS. Eso te dirá qué páginas están rotas y qué índices están afectados.

    Si son índices nonclustered, entonces, lo puedes eliminar el índice y volver a crearlo, sin mayor problema,  se creará de cero y correctamente. 

    Si es el índice clustered de la tabla, entonces, debes asumir que es posible que pierdas datos porque hay páginas corruptas (y el índice clustered son los datos), no leíbles. Para recuperar el acceso al resto de las páginas, las que no están rotas, puedes realizar el dbcc checktable, pero con la opción REPAIR_ALLOW_DATA_LOSS. Luego, con ese backup bueno y restaurable, podrás recuparar parte de lo perdido. También es posible que no se pierda nada.

    Suerte.

    Alberto López Grande.
    Wednesday, June 17, 2009 9:29 AM
  • Hola, he eliminado el indice pero me temo que el problema esté en la PK de esa tabla, ya que no puedo eliminarla, ahora he lanzado de nuevo el proceso con REPAIR_ALLOW_DATA_LOSS a ver si tengo resultados validos, aunque tuviera una minima perdida de datos, seria asumbile.

    Gracias por tu ayuda Alberto
    Wednesday, June 17, 2009 10:38 AM
  • Hola.

    Dado que ya lo has lanzado, puede que dé igual, a las malas ya tienes unos pocos backups por ahí, pero la pérdida de datos puede no ser mínima, con esa opción le dices a SQL Server que elimine todas aquellas páginas que estén corruptas. A 8Kb por página, en función del número de registros que te quepan en cada página, pueden ser bastantes. Nos dices lo que sea.

    Alberto López Grande.
    Wednesday, June 17, 2009 11:55 AM
  • Hola, he eliminado el indice pero me temo que el problema esté en la PK de esa tabla, ya que no puedo eliminarla, ahora he lanzado de nuevo el proceso con REPAIR_ALLOW_DATA_LOSS a ver si tengo resultados validos, aunque tuviera una minima perdida de datos, seria asumbile.

    Gracias por tu ayuda Alberto

    Jose,

    Esa clave primaria fue creada con un indice clustered o uno nonclustered?


    Por que no nos muestra el script de creacion de esa tabla y sus indices, pues quiciera saber donde esta la data (o clustered index si es que hay) y donde estan los indices?

    Algo que quiero que entiendas es que no podemos asignar la creacion de un indice a un archivo secundario en especifico, sino a un grupo de archivos, y que SQL Server se encargara de hacer la carga balanceada en todos los archivos de el grupo.

    > Os situo, tengo una BDD en SQL Server 2000 con una serie de tablas e indices separadas por diferentes ficheros NDF, el caso es que el fichero que
    > guarda los indices esta corrupto, por lo tanto puedo hacer operaciones de inserción pero no de select, delete o update.

    Este comentario tiende a confundir, pues como mencione antes, no podemos asignar la creacion de un indice a un archivo en especifico.

    Trata de hacer un analizis mas profundo de ese grupo.

    USE tu_db;
    GO

    SELECT * FROM sysfilegroups;
    GO

    DBCC CHECKFILEGROUP (1) WITH ALL_ERRORMSGS;
    GO

    En vez de (1), pon el numero de el grupo de archivos que esta dando problemas.


    AMB
    Wednesday, June 17, 2009 12:57 PM
  • Bueno, finalmente gracias a todos, al lanzar el proceso con el REPAIR_ALLOW_DATA_LOSS se corrigio correctamente al menos es lo que parece, ahora he eliminado la pk y los indices que me daban problemas, y si que puedo por fin hacer selects, updates y demas...

    La perdida de datos parece ser que ha sido menor de lo esperada, por lo tanto el proceso es valido y funcionando.

    Gracias a todos por vuestra ayuda.
    Wednesday, June 17, 2009 3:13 PM