como dsoluciono este error de checkdb

ok, entonces ni siquiera ocn la opcion de checkear el backup se puede estar
seguro?

"Eladio Rincón" wrote in message
news:%

corrupción del fichero de copia...

en SQL Server 2000, no hay forma de garantizar una copia de seguridad a
menos que la hayas restaurado...

en SQL Server 2005, la cosa cambia porque se introducen ckecksums, etc.


Creo que a alguien le leí decir que "no tienes backup hasta que no lo has
restaurado"; creo que lo dijo mi amigo Brian Moran :):)

Eladio Rincón,
http://www.siquelnet.com

Mentor, SQL Server MVP
Solid Quality Learning Iberoamericana
http://www.solidqualitylearning.com

"Mauro" wrote in message
news:
> era un a base de prueba por lo que no hay mayores complejidades, pero ,
> que
> causo esto?
>
> "Eladio Rincón" wrote in message
> news:%
>> si no hay otro backup, mal asunto :(
>>
>> Eladio Rincón,
>> http://www.siquelnet.com
>>
>> Mentor, SQL Server MVP
>> Solid Quality Learning Iberoamericana
>> http://www.solidqualitylearning.com
>>
>> "Mauro" wrote in message
>> news:
>> > no, ese error lo da al levantar el backup
>> > so, no way?
>> >
>> > "Eladio Rincón" wrote in message
>> > news:
>> >> tienes un problema serio...
>> >>
>> >> te está diciendo que esas páginas no saben de cual es el estado de

más

> de
>> >> 8000 páginas de datos... no dice que esas 8000 páginas sean

erroneas,

>> >> sino
>> >> que la página que las direcciona (gam, sgam, pfs) no conoce de su
>> > estado...
>> >>
>> >> supongo que tendrás backup, verdad?
>> >>
>> >>
>> >> Eladio Rincón,
>> >> http://www.siquelnet.com
>> >>
>> >> Mentor, SQL Server MVP
>> >> Solid Quality Learning Iberoamericana
>> >> http://www.solidqualitylearning.com
>> >>
>> >> "Mauro" wrote in message
>> >> news:%
>> >> > el comando ejecutado fue
>> >> > dbcc checkdb ('checkweb30bver7',repair_allow_data_loss)
>> >> > y me da este resultado:
>> >> >
>> >> > Server: Msg 8946, Level 16, State 2, Line 1
>> >> > Table error: Allocation page (1:323520) has invalid PFS_PAGE page
>> >> > header
>> >> > values. Type is 7. Check type, object ID and page ID on the page.
>> >> > Server: Msg 8998, Level 16, State 1, Line 1
>> >> > Page errors on the GAM, SGAM, or PFS pages do not allow CHECKALLOC
>> >> > to
>> >> > verify
>> >> > database ID 13 pages from (1:323520) to (1:331607). See other

errors

>> >> > for
>> >> > cause.
>> >> > DBCC results for 'checkweb30bver7'.
>> >> > The repair level on the DBCC statement caused this repair

to

> be
>> >> > bypassed.
>> >> > The repair level on the DBCC statement caused this repair

to

> be
>> >> > bypassed.
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Hola.

El chequeo del backup, las opciones restore verifyonly, restore
headeronly,... Son útiles para muchas cosas, pero no son suficiente garantía
como para decir que tienes un backup, sólo te informan que la cabecera del
backup es leíble. Hasta que no lo restauras, tienes un buen montón de ceros
y unos. Y cuando lo restaures, si has hecho el backup en una cinta, procura
restaurarlo usando otro lector de cintas (para asegurarte de que aunque tu
lector se rompa, otro dispositivo puede leer la cinta). Y si lo tienes en
disco, lo grabas a cinta y en ambos casos, sacas del edificio la cinta. Y
así hasta el límite de tu pesimismo.

Alberto López Grande (qwalgrande)
"Mauro" escribió en el mensaje
news:u6P0L%

ok, entonces ni siquiera ocn la opcion de checkear el backup se puede
estar
seguro?

"Eladio Rincón" wrote in message
news:%

corrupción del fichero de copia...

en SQL Server 2000, no hay forma de garantizar una copia de seguridad a
menos que la hayas restaurado...

en SQL Server 2005, la cosa cambia porque se introducen ckecksums, etc.


Creo que a alguien le leí decir que "no tienes backup hasta que no lo has
restaurado"; creo que lo dijo mi amigo Brian Moran :):)

Eladio Rincón,
http://www.siquelnet.com

Mentor, SQL Server MVP
Solid Quality Learning Iberoamericana
http://www.solidqualitylearning.com

"Mauro" wrote in message
news:
> era un a base de prueba por lo que no hay mayores complejidades, pero ,
> que
> causo esto?
>
> "Eladio Rincón" wrote in message
> news:%
>> si no hay otro backup, mal asunto :(
>>
>> Eladio Rincón,
>> http://www.siquelnet.com
>>
>> Mentor, SQL Server MVP
>> Solid Quality Learning Iberoamericana
>> http://www.solidqualitylearning.com
>>
>> "Mauro" wrote in message
>> news:
>> > no, ese error lo da al levantar el backup
>> > so, no way?
>> >
>> > "Eladio Rincón" wrote in message
>> > news:
>> >> tienes un problema serio...
>> >>
>> >> te está diciendo que esas páginas no saben de cual es el estado de

más

> de
>> >> 8000 páginas de datos... no dice que esas 8000 páginas sean

erroneas,

>> >> sino
>> >> que la página que las direcciona (gam, sgam, pfs) no conoce de su
>> > estado...
>> >>
>> >> supongo que tendrás backup, verdad?
>> >>
>> >>
>> >> Eladio Rincón,
>> >> http://www.siquelnet.com
>> >>
>> >> Mentor, SQL Server MVP
>> >> Solid Quality Learning Iberoamericana
>> >> http://www.solidqualitylearning.com
>> >>
>> >> "Mauro" wrote in message
>> >> news:%
>> >> > el comando ejecutado fue
>> >> > dbcc checkdb ('checkweb30bver7',repair_allow_data_loss)
>> >> > y me da este resultado:
>> >> >
>> >> > Server: Msg 8946, Level 16, State 2, Line 1
>> >> > Table error: Allocation page (1:323520) has invalid PFS_PAGE page
>> >> > header
>> >> > values. Type is 7. Check type, object ID and page ID on the page.
>> >> > Server: Msg 8998, Level 16, State 1, Line 1
>> >> > Page errors on the GAM, SGAM, or PFS pages do not allow
>> >> > CHECKALLOC
>> >> > to
>> >> > verify
>> >> > database ID 13 pages from (1:323520) to (1:331607). See other

errors

>> >> > for
>> >> > cause.
>> >> > DBCC results for 'checkweb30bver7'.
>> >> > The repair level on the DBCC statement caused this repair

to

> be
>> >> > bypassed.
>> >> > The repair level on the DBCC statement caused this repair

to

> be
>> >> > bypassed.
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

veo como viene la mano, ahora, el archivo se restauro ok. los errores los da
despues de restaurar la base, digamos que no bastaria con restaurar, aprte
habria que hacer un checkdb

"qwalgrande" wrote in message
news:

Hola.

El chequeo del backup, las opciones restore verifyonly, restore
headeronly,... Son útiles para muchas cosas, pero no son suficiente

garantía

como para decir que tienes un backup, sólo te informan que la cabecera del
backup es leíble. Hasta que no lo restauras, tienes un buen montón de

ceros

y unos. Y cuando lo restaures, si has hecho el backup en una cinta,

procura

restaurarlo usando otro lector de cintas (para asegurarte de que aunque tu
lector se rompa, otro dispositivo puede leer la cinta). Y si lo tienes en
disco, lo grabas a cinta y en ambos casos, sacas del edificio la cinta. Y
así hasta el límite de tu pesimismo.

Alberto López Grande (qwalgrande)
"Mauro" escribió en el mensaje
news:u6P0L%
> ok, entonces ni siquiera ocn la opcion de checkear el backup se puede
> estar
> seguro?
>
> "Eladio Rincón" wrote in message
> news:%
>> corrupción del fichero de copia...
>>
>> en SQL Server 2000, no hay forma de garantizar una copia de seguridad a
>> menos que la hayas restaurado...
>>
>> en SQL Server 2005, la cosa cambia porque se introducen ckecksums, etc.
>>
>>
>> Creo que a alguien le leí decir que "no tienes backup hasta que no lo

has

>> restaurado"; creo que lo dijo mi amigo Brian Moran :):)
>>
>> Eladio Rincón,
>> http://www.siquelnet.com
>>
>> Mentor, SQL Server MVP
>> Solid Quality Learning Iberoamericana
>> http://www.solidqualitylearning.com
>>
>> "Mauro" wrote in message
>> news:
>> > era un a base de prueba por lo que no hay mayores complejidades, pero

,

>> > que
>> > causo esto?
>> >
>> > "Eladio Rincón" wrote in message
>> > news:%
>> >> si no hay otro backup, mal asunto :(
>> >>
>> >> Eladio Rincón,
>> >> http://www.siquelnet.com
>> >>
>> >> Mentor, SQL Server MVP
>> >> Solid Quality Learning Iberoamericana
>> >> http://www.solidqualitylearning.com
>> >>
>> >> "Mauro" wrote in message
>> >> news:
>> >> > no, ese error lo da al levantar el backup
>> >> > so, no way?
>> >> >
>> >> > "Eladio Rincón" wrote in message
>> >> > news:
>> >> >> tienes un problema serio...
>> >> >>
>> >> >> te está diciendo que esas páginas no saben de cual es el estado

de

> más
>> > de
>> >> >> 8000 páginas de datos... no dice que esas 8000 páginas sean
> erroneas,
>> >> >> sino
>> >> >> que la página que las direcciona (gam, sgam, pfs) no conoce de su
>> >> > estado...
>> >> >>
>> >> >> supongo que tendrás backup, verdad?
>> >> >>
>> >> >>
>> >> >> Eladio Rincón,
>> >> >> http://www.siquelnet.com
>> >> >>
>> >> >> Mentor, SQL Server MVP
>> >> >> Solid Quality Learning Iberoamericana
>> >> >> http://www.solidqualitylearning.com
>> >> >>
>> >> >> "Mauro" wrote in message
>> >> >> news:%
>> >> >> > el comando ejecutado fue
>> >> >> > dbcc checkdb ('checkweb30bver7',repair_allow_data_loss)
>> >> >> > y me da este resultado:
>> >> >> >
>> >> >> > Server: Msg 8946, Level 16, State 2, Line 1
>> >> >> > Table error: Allocation page (1:323520) has invalid PFS_PAGE

page

>> >> >> > header
>> >> >> > values. Type is 7. Check type, object ID and page ID on the

page.

>> >> >> > Server: Msg 8998, Level 16, State 1, Line 1
>> >> >> > Page errors on the GAM, SGAM, or PFS pages do not allow
>> >> >> > CHECKALLOC
>> >> >> > to
>> >> >> > verify
>> >> >> > database ID 13 pages from (1:323520) to (1:331607). See other
> errors
>> >> >> > for
>> >> >> > cause.
>> >> >> > DBCC results for 'checkweb30bver7'.
>> >> >> > The repair level on the DBCC statement caused this

repair

> to
>> > be
>> >> >> > bypassed.
>> >> >> > The repair level on the DBCC statement caused this

repair

> to
>> > be
>> >> >> > bypassed.
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Hola.

Como diría Faemino, eso es otra fila...

El chequeo de integridad lo puedes hacer antes o después del backup. En
cierto modo es indiferente, mientras lo hagas. Realizarlo después tiene unas
ventajas que yo prefiero, ya que te evita realizar el chequeo de la parte de
producción, una operación que puede provocar bloqueos e indisponibilidad. Si
haces un backup, lo restauras, haces el chequeo de integridad y no encuentra
errores, nada invita a pensar que en la original haya algún problema.

El hecho de que te dé errores al realizar el checkdb, puede ser debido a que
en origen tienes páginas corruptas, lo cual es grave. Asegúrate en cuanto
puedas, pasando el checkdb en la base de datos original(repito, no es algo
que pueda hacerse en mitad de la mañana).

Este chequeo posterior es especialmente aconsejable en determinados backups,
que sean algo más importantes que los rutinarios, como los de fin de mes o
fin de año, para asegurarte de que lo que vas a guardar por un largo periodo
de tiempo está en perfecto estado.

Alberto López Grande (qwalgrande)
"Mauro" escribió en el mensaje
news:

veo como viene la mano, ahora, el archivo se restauro ok. los errores los
da
despues de restaurar la base, digamos que no bastaria con restaurar, aprte
habria que hacer un checkdb

"qwalgrande" wrote in message
news:

Hola.

El chequeo del backup, las opciones restore verifyonly, restore
headeronly,... Son útiles para muchas cosas, pero no son suficiente

garantía

como para decir que tienes un backup, sólo te informan que la cabecera
del
backup es leíble. Hasta que no lo restauras, tienes un buen montón de

ceros

y unos. Y cuando lo restaures, si has hecho el backup en una cinta,

procura

restaurarlo usando otro lector de cintas (para asegurarte de que aunque
tu
lector se rompa, otro dispositivo puede leer la cinta). Y si lo tienes en
disco, lo grabas a cinta y en ambos casos, sacas del edificio la cinta. Y
así hasta el límite de tu pesimismo.

Alberto López Grande (qwalgrande)
"Mauro" escribió en el mensaje
news:u6P0L%
> ok, entonces ni siquiera ocn la opcion de checkear el backup se puede
> estar
> seguro?
>
> "Eladio Rincón" wrote in message
> news:%
>> corrupción del fichero de copia...
>>
>> en SQL Server 2000, no hay forma de garantizar una copia de seguridad
>> a
>> menos que la hayas restaurado...
>>
>> en SQL Server 2005, la cosa cambia porque se introducen ckecksums,
>> etc.
>>
>>
>> Creo que a alguien le leí decir que "no tienes backup hasta que no lo

has

>> restaurado"; creo que lo dijo mi amigo Brian Moran :):)
>>
>> Eladio Rincón,
>> http://www.siquelnet.com
>>
>> Mentor, SQL Server MVP
>> Solid Quality Learning Iberoamericana
>> http://www.solidqualitylearning.com
>>
>> "Mauro" wrote in message
>> news:
>> > era un a base de prueba por lo que no hay mayores complejidades,
>> > pero

,

>> > que
>> > causo esto?
>> >
>> > "Eladio Rincón" wrote in message
>> > news:%
>> >> si no hay otro backup, mal asunto :(
>> >>
>> >> Eladio Rincón,
>> >> http://www.siquelnet.com
>> >>
>> >> Mentor, SQL Server MVP
>> >> Solid Quality Learning Iberoamericana
>> >> http://www.solidqualitylearning.com
>> >>
>> >> "Mauro" wrote in message
>> >> news:
>> >> > no, ese error lo da al levantar el backup
>> >> > so, no way?
>> >> >
>> >> > "Eladio Rincón" wrote in message
>> >> > news:
>> >> >> tienes un problema serio...
>> >> >>
>> >> >> te está diciendo que esas páginas no saben de cual es el estado

de

> más
>> > de
>> >> >> 8000 páginas de datos... no dice que esas 8000 páginas sean
> erroneas,
>> >> >> sino
>> >> >> que la página que las direcciona (gam, sgam, pfs) no conoce de
>> >> >> su
>> >> > estado...
>> >> >>
>> >> >> supongo que tendrás backup, verdad?
>> >> >>
>> >> >>
>> >> >> Eladio Rincón,
>> >> >> http://www.siquelnet.com
>> >> >>
>> >> >> Mentor, SQL Server MVP
>> >> >> Solid Quality Learning Iberoamericana
>> >> >> http://www.solidqualitylearning.com
>> >> >>
>> >> >> "Mauro" wrote in message
>> >> >> news:%
>> >> >> > el comando ejecutado fue
>> >> >> > dbcc checkdb ('checkweb30bver7',repair_allow_data_loss)
>> >> >> > y me da este resultado:
>> >> >> >
>> >> >> > Server: Msg 8946, Level 16, State 2, Line 1
>> >> >> > Table error: Allocation page (1:323520) has invalid PFS_PAGE

page

>> >> >> > header
>> >> >> > values. Type is 7. Check type, object ID and page ID on the

page.

>> >> >> > Server: Msg 8998, Level 16, State 1, Line 1
>> >> >> > Page errors on the GAM, SGAM, or PFS pages do not allow
>> >> >> > CHECKALLOC
>> >> >> > to
>> >> >> > verify
>> >> >> > database ID 13 pages from (1:323520) to (1:331607). See other
> errors
>> >> >> > for
>> >> >> > cause.
>> >> >> > DBCC results for 'checkweb30bver7'.
>> >> >> > The repair level on the DBCC statement caused this

repair

> to
>> > be
>> >> >> > bypassed.
>> >> >> > The repair level on the DBCC statement caused this

repair

> to
>> > be
>> >> >> > bypassed.
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

me queda claro, muchas gracias a todos.
Mauro

"qwalgrande" wrote in message
news:

Hola.

Como diría Faemino, eso es otra fila...

El chequeo de integridad lo puedes hacer antes o después del backup. En
cierto modo es indiferente, mientras lo hagas. Realizarlo después tiene

unas

ventajas que yo prefiero, ya que te evita realizar el chequeo de la parte

de

producción, una operación que puede provocar bloqueos e indisponibilidad.

Si

haces un backup, lo restauras, haces el chequeo de integridad y no

encuentra

errores, nada invita a pensar que en la original haya algún problema.

El hecho de que te dé errores al realizar el checkdb, puede ser debido a

que

en origen tienes páginas corruptas, lo cual es grave. Asegúrate en cuanto
puedas, pasando el checkdb en la base de datos original(repito, no es algo
que pueda hacerse en mitad de la mañana).

Este chequeo posterior es especialmente aconsejable en determinados

backups,

que sean algo más importantes que los rutinarios, como los de fin de mes o
fin de año, para asegurarte de que lo que vas a guardar por un largo

periodo

de tiempo está en perfecto estado.

Alberto López Grande (qwalgrande)
"Mauro" escribió en el mensaje
news:
> veo como viene la mano, ahora, el archivo se restauro ok. los errores

los

> da
> despues de restaurar la base, digamos que no bastaria con restaurar,

aprte

> habria que hacer un checkdb
>
> "qwalgrande" wrote in message
> news:
>> Hola.
>>
>> El chequeo del backup, las opciones restore verifyonly, restore
>> headeronly,... Son útiles para muchas cosas, pero no son suficiente
> garantía
>> como para decir que tienes un backup, sólo te informan que la cabecera
>> del
>> backup es leíble. Hasta que no lo restauras, tienes un buen montón de
> ceros
>> y unos. Y cuando lo restaures, si has hecho el backup en una cinta,
> procura
>> restaurarlo usando otro lector de cintas (para asegurarte de que aunque
>> tu
>> lector se rompa, otro dispositivo puede leer la cinta). Y si lo tienes

en

>> disco, lo grabas a cinta y en ambos casos, sacas del edificio la cinta.

Y

>> así hasta el límite de tu pesimismo.
>>
>> Alberto López Grande (qwalgrande)
>> "Mauro" escribió en el mensaje
>> news:u6P0L%
>> > ok, entonces ni siquiera ocn la opcion de checkear el backup se puede
>> > estar
>> > seguro?
>> >
>> > "Eladio Rincón" wrote in message
>> > news:%
>> >> corrupción del fichero de copia...
>> >>
>> >> en SQL Server 2000, no hay forma de garantizar una copia de

seguridad

>> >> a
>> >> menos que la hayas restaurado...
>> >>
>> >> en SQL Server 2005, la cosa cambia porque se introducen ckecksums,
>> >> etc.
>> >>
>> >>
>> >> Creo que a alguien le leí decir que "no tienes backup hasta que no

lo

> has
>> >> restaurado"; creo que lo dijo mi amigo Brian Moran :):)
>> >>
>> >> Eladio Rincón,
>> >> http://www.siquelnet.com
>> >>
>> >> Mentor, SQL Server MVP
>> >> Solid Quality Learning Iberoamericana
>> >> http://www.solidqualitylearning.com
>> >>
>> >> "Mauro" wrote in message
>> >> news:
>> >> > era un a base de prueba por lo que no hay mayores complejidades,
>> >> > pero
> ,
>> >> > que
>> >> > causo esto?
>> >> >
>> >> > "Eladio Rincón" wrote in message
>> >> > news:%
>> >> >> si no hay otro backup, mal asunto :(
>> >> >>
>> >> >> Eladio Rincón,
>> >> >> http://www.siquelnet.com
>> >> >>
>> >> >> Mentor, SQL Server MVP
>> >> >> Solid Quality Learning Iberoamericana
>> >> >> http://www.solidqualitylearning.com
>> >> >>
>> >> >> "Mauro" wrote in message
>> >> >> news:
>> >> >> > no, ese error lo da al levantar el backup
>> >> >> > so, no way?
>> >> >> >
>> >> >> > "Eladio Rincón" wrote in message
>> >> >> > news:
>> >> >> >> tienes un problema serio...
>> >> >> >>
>> >> >> >> te está diciendo que esas páginas no saben de cual es el

estado

> de
>> > más
>> >> > de
>> >> >> >> 8000 páginas de datos... no dice que esas 8000 páginas sean
>> > erroneas,
>> >> >> >> sino
>> >> >> >> que la página que las direcciona (gam, sgam, pfs) no conoce de
>> >> >> >> su
>> >> >> > estado...
>> >> >> >>
>> >> >> >> supongo que tendrás backup, verdad?
>> >> >> >>
>> >> >> >>
>> >> >> >> Eladio Rincón,
>> >> >> >> http://www.siquelnet.com
>> >> >> >>
>> >> >> >> Mentor, SQL Server MVP
>> >> >> >> Solid Quality Learning Iberoamericana
>> >> >> >> http://www.solidqualitylearning.com
>> >> >> >>
>> >> >> >> "Mauro" wrote in message
>> >> >> >> news:%
>> >> >> >> > el comando ejecutado fue
>> >> >> >> > dbcc checkdb ('checkweb30bver7',repair_allow_data_loss)
>> >> >> >> > y me da este resultado:
>> >> >> >> >
>> >> >> >> > Server: Msg 8946, Level 16, State 2, Line 1
>> >> >> >> > Table error: Allocation page (1:323520) has invalid PFS_PAGE
> page
>> >> >> >> > header
>> >> >> >> > values. Type is 7. Check type, object ID and page ID on the
> page.
>> >> >> >> > Server: Msg 8998, Level 16, State 1, Line 1
>> >> >> >> > Page errors on the GAM, SGAM, or PFS pages do not allow
>> >> >> >> > CHECKALLOC
>> >> >> >> > to
>> >> >> >> > verify
>> >> >> >> > database ID 13 pages from (1:323520) to (1:331607). See

other

>> > errors
>> >> >> >> > for
>> >> >> >> > cause.
>> >> >> >> > DBCC results for 'checkweb30bver7'.
>> >> >> >> > The repair level on the DBCC statement caused this
> repair
>> > to
>> >> > be
>> >> >> >> > bypassed.
>> >> >> >> > The repair level on the DBCC statement caused this
> repair
>> > to
>> >> > be
>> >> >> >> > bypassed.
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>