Hace unos días alguien preguntó en el foro de MSDN de SQL Server en español cómo podía simular un escenario de Disaster Recovery, más concretamente cómo corromper de forma intencionada una base de datos. Aunque en su momento le respondí con los pasos a seguir para hacerlo, me pareció suficientemente interesante como para hacer un post donde lo detallara más, así que empecemos.
Como siempre con este tipo de cosas, lo primero es hacerlo sobre una instancia que no sea producción (parece obvio, pero nunca está de más advertirlo) y en una base de datos de nueva creación o sobre una que no nos importe trastear. Una vez sobre esa base de datos, crearemos una copia de la tabla Sales.SalesTerritory de AdventureWorks2012 que es la que hará de conejillo de india para nuestra prueba:
USE AdventureWorks2012_copy
GO
SELECT * INTO [Sales].[SalesTerritory] FROM AdventureWorks2012.[Sales].[SalesTerritory]
Después de comporobar que tenemos los datos correctamente insertados, el siguiente paso es desadjuntar la base de datos y abrir su archivo mdf con un editor hexadecimal. En nuestro caso hemos usado uno de los más conocidos, HxD. La siguiente imagen muestra el fichero de datos abierto en esta herramienta:
A continuación buscaremos un texto que sabemos debe existir, por ejemplo, «Northwest». Hay que marcar la opción «Unicode string» porque el campo «Name» es de este tipo de datos:
Una vez encontrado, el siguiente paso es escribir algo en esa parte. En nuestro caso hemos sobreescrito el texto encontrado con unas cuantas «X»:
Y ya está. Salvamos y hemos conseguido corromper una base de datos de SQL Server. La forma de comprobarlo es fácil: volvemos a adjuntar a nuestra instancia los ficheros y probamos una SELECT contra la tabla que contenía el valor que hemos editado. Al tratar de ejecutar la instrucción, el motor nos devolverá el siguiente mensaje de error:
Si ejecutamos un DBCC CHECKDB, tal como nos está indicando el mensaje, obtendremos un error similar un poco más detallado:
La información de la página corrupta la encontraremos también en la tabla [suspect_pages] de [msdb]:
Para arreglar esta situación tenemos dos opciones: o ejecutamos DBCC CHECKB con la opción REPAIR_ALLOW_DATA_LOSS, con lo que en este caso vamos a perder el contenido de la tabla porque es la única forma de corregir los problemas encontrados en esa página (la parte «allow_data_loss» está para algo…), o bien restauramos la base de datos desde el último backup válido que tengamos (y si esto nos ocurre en producción, nos serviría para aprender de la importancia de tener una buena y probada política de backups)
