La gran mayoría de las veces que nos enfrentemos a un problema en nuestra base de datos la solución que nos ofrece el comando DBCC CHECKDB será que usemos la opción REPAIR_ALLOW_DATA_LOSS, pues bien, antes de lanzarnos de cabeza debemos tener en cuenta los riesgos que podemos sufrir.
REPAIR_ALLOW_DATA_LOSS es un recurso rápido para poner en funcionamiento nuestra base de datos, el propósito no es guardar los datos de los usuarios, sino recuperar la consistencia estructural de la BD, tan rápido como sea posible de una manera correcta. Pero en este proceso para conseguir la consistencia borrará tanto datos como páginas corruptas.
Imaginemos el siguiente escenario, el DBA de nuestra entidad bancaria no realiza los backups necesarios para preservar la información y recuperarse de un desastre. El servidor sufre un apagón y resulta dañado un disco duro no pudiendo guardar correctamente una página, causando un TORN PAGE. Desafortunadamente en esa página está nuestra cuenta corriente. Como el DBA no dispone de copias de seguridad realiza una reparación con REPAIR_ALLOW_DATA_LOSS. Como resultado de esta reparación la página dañada resulta borrada!!! Y con ella nuestra cuenta corriente y la muchos otros clientes!!! xDDD
Suscribirse a:
Enviar comentarios (Atom)
Entradas
2 comentarios:
conoces alguna otra forma mas segura de reparar una base en estado sospechoso, tengo ese problema y no se como resolverlo. Gracias
Lo primero pondría la BD en modo emergencia, y le haría un DBCC CHECKDB con las opciones que especifico en otro post
http://frvsoft.blogspot.com/2009/02/ejecutando-dbcc-checkdb-de-manera.html
Así sabrás que tipo de error tiene tu BD y podrás actuar de una forma u otra.
Publicar un comentario