Para eso necesitamos que el backup de la base de datos esté en el nas y que los logs esten en el nas. El log file contiene la última transacción, y si el server se va completamente, con el backup y el log file podemos restaurarlo. Necesitamos backup consistentes y es muy bueno usar backup devices porque nos da el historial de los backup. El backup de los logs es necesario para descargar el log file y no dejar que crezca, y si lo usamos tendremos que tenerlo en cuenta para el restore.Para este ejemplo vamos a usar db1 con la database SmartCenturyUSA. Dado que tenemos una tabla “elder” que ya esta en el backup.
select * from elder;
id name
1 Elderito
2 Ernestico
update elder set name='Elder' where name='Elderito';
--este cambio no esta en el backup, pero si en el log file (el cual esta en el nas).
select * from elder;
1 Elder
2 Ernestico
Ahora apagamos db1. Ojo, ha habido un checkpoint y por ende un flush de los buffers de la database hacia el fichero mdf, pero no me interesa ese mdf, porque ese server lo doy por perdido. Tambien me esta quedando el log file cerrado correctamente. Dios quiera que ante un evento, el log file no nos quede dañado! Solo nos queda hacer backup del log con más frecuencia. He leído de hacerlo cada 15 minutos pero nos daría 96 backup al dia y complicaria la recuperación, que por cierto no es automática (Oracle si). Hay que seleccionar backup por backup que participará en en el restore y si el dba se equivoca seleccionando los backup, va mal la cosa. Es decision de Intradata la frecuencia que quiera de los backup de los logs.
Encendemos db4 que sera el server que vendrá al rescate de db1 (que supuestamente se jodio completo).
Ante todo renombramos el log file y lo terminamos en -old para evitar ser reescrito.
Creamos un base de datos vacia con el mismo nombre de la que queremos recuperar e inmediatamente la ponemos offline. Esto es solo para poder backear el log file.
create database SmartCenturyUSA;
alter database SmartCenturyUSA set offline;
Tomamos nota del nombre del ldf creado. IMPORTANTE.
Borramos el mdf y el ldf creado.
Copiamos el ldf que termina en -old como el nombre del ldf que espera la database dummy.
Ahora intentamos ponerla online y nos dará error, pero es necesario para poder hacer el backup. Offline impide el backup! El backup quedará en la raiz del disco C:. Acto seguido la ponemos offline y la borramos. Si no la borramos, no conseguí hacer el restore nunca.
USE master;
GO
ALTER DATABASE SmartCenturyUSA SET ONLINE;
GO
backup log SmartCenturyUSA to disk = 'c:\tail.bak' with init, no_truncate;
GO
ALTER DATABASE SmartCenturyUSA SET OFFLINE;
GO
DROP DATABASE SmartCenturyUSA;
GO
A pesar de los errores que da el sql, tendremos un backup tail.bak en la raiz del disco duro y la database dummy borrada. Ya podemos borrar el ldf que se uso en la dummy. Nos queda restaurar el backup.
En databases hacemos click derecho y cogemos restore database.
From device, click en “...”
Backup media, cogemos backup device y click en add.
Seleccionamos db1backup.
Seleccionamos los backup a restaurar.
Mirando arriba, seleccionamos la database SmartCenturyUSA.
Por la izquierda, opciones. Ajustamos los nombres de los ficheros mdf y ldf.
Marcamos Overwrite the existing database(WITH REPLACE)
Recovery state= segunda opcion (RESTORE WITH NORECOVERY) Esto me permite agregar el tail.bak después.
Aparece la database con un mensaje (Restoring…) que significa que esta esperando mas restore.
Encima de ella hacemos restore.
From device y click “...”
File, Add, C:, tail.bak
Seleccionamos, el cuadrito del restore de ese file.
select * from elder;
id name
1 Elder
2 Ernestico
Tenemos la ultima transacion en db4
