Restaurando hasta un punto en el tiempo

Los recoveries que hemos hecho a este punto han sido pensando que debiamos dejar la base de datos tal y como estaba en el momento del fallo, pero hay ocasiones que algunos errores u otro tipo de problemas, no nos es posible, o no queremos.

¿Qué significa esto? Pues lo vamos a explicar mediante un ejemplo que puede ser una de las situaciones más típicas con las que nos encontremos cuando trabajamos con bases de datos reales.

Pensemos en una tabla que tiene mil filas, y en algún punto uno de los usuarios elimina por error 500 filas, o las elimina todas. Después los usuarios siguen trabajando, hasta que uno de ellos se entera de lo que ha pasado, digamos varias horas después.

Para recuperar esa información, lo ideal es volver hasta el punto anterior al que se hizo la operación de borrado. Obviamente tendremos un problema, porque al recuperar la base de datos tal como estaba antes que se eliminaran todas las filas de la tabla, perderíamos el trabajo realizado desde ese momento hasta que nos enteramos del problema. Es decir, si se eliminaron los registros a las 9 am, y a las 3 pm me doy cuenta de lo que ha pasado, si recuperamos la base de datos tal y como estaba antes de que se eliminaran los registros, perderíamos todo el trabajo realizado desde las 9 am hasta las 3 pm.

En este punto es donde se debe evaluar qué es más importante, si perder todos los registros que se eliminaron, dejar la base de datos tal y como está, e intentar recuperar esos registros de forma manual, o volver a ese punto en el tiempo, con la consiguiente pérdida del trabajo realizado desde las 9 de la mañana hasta las 3 de la tarde.

Para esta situación no hay una respuesta definitiva, depende de cuán valioso y necesario sea una información u otra. Para nuestro ejemplo, pensemos que alguien decidió, que esas miles de filas no se pueden perder, y que el trabajo realizado después del borrado se puede rehacer de alguna manera, por lo que es necesario volver la base de datos al punto en el tiempo justo antes de que el usuario, por error, eliminó los registros de la tabla.

En este video vamos a recrear un ejemplo práctico de una situación similar a la hemos visto antes. Vamos a borrar una tabla, después vamos a hacer algo sobre esa tabla, y por último vamos a volver la base de datos a un instante anterior al cuando se borraron los datos. Esto es lo que se denomina una recuperación parcial de la base de datos, hasta ahora hemos hecho recoveries completos. En una recuperación POINT IN TIME RECOVERY, inevitablemente perdemos datos, pero de una manera consciente, antes de hacer la recuperación se evalúa hasta qué punto es mejor recuperar la base de datos hasta un determinado punto en el tiempo, que perder el trabajo realizado a partir de ese tiempo y hasta que nos disponemos a recuperar la base de datos.

Veamos esta consulta que ya he escrito de antes aquí. Nos devuelve el número de secuencia. En la segunda columna tenemos el SYSTEM CHANGE NUMBER (SCN), los SCN son los identificadores de los cambios consolidados dentro del redo. Podemos ver, por ejemplo, que la secuencia 53 comienza con el SCN con terminal 337, y la secuencia 54 lo hace con el SCN 365, lo que quiere decir, que los SCN de ese intervalo, están contenidos dentro de la secuencia 53.

También en la tercera columna, tenemos la hora de cuando se hace el primer cambio en cada secuencia, y de igual manera que con el SCN, podemos identificar los intervalos de tiempo en que se guardaron los cambios en determinado redo. En mi caso, el redo correspondiente a la secuencia 53, se ha hecho desde las QUINCE CATORCE CON 59 SEGUNDOS, hasta el instante anterior a las QUINCE QUINCE con 16 segundos.

Tener estas cuestiones en cuanta es muy importante a la hora de hacer un POINT IN TIME RECOVERY, porque quizá el usuario que haya eliminado las filas, pudiera saber a qué hora realizó esa operación, entonces sabríamos hasta qué hora debo retroceder, o, como es el caso del ejemplo que vamos a hacer, hasta qué secuencia debo recuperar.

Actualmente nos encontramos en la secuencia 54. En el video anterior trabajamos con la tabla DATOS1, pues vamos a utilizarla también para ilustrar este ejemplo. Primero hacemos un:

• SELECT * FROM DATOS1

Y vemos te la tabla tiene 11 registros. Imaginemos ahora que un usuario las elimina y se valida esa transacción.

Ahora tenemos una catástrofe, se han eliminado todos los registros de la tabla DATOS1 y se han validado incluso esos cambios. Otro de los comandos que podemos utilizar para identificar la secuencia en que nos encontramos es:

• ARCHIVE LOG LIST

Y vemos que el CURRENT LOG SEQUENCE es el número 54.

No podemos saber qué tiempo tendria que transcurrir hasta que haya un SWITCH de los redo files en el sistema, pero podemos provocarlo con el comando:

• ALTER SYSTEM SWITCH LOGFILE

Presionamos Intro, y tenemos el mensaje de que ha habido cambios en la base de datos. Para comprobar que se ha cambiado la secuencia de los redo log, vamos a subir un poco y copiar esta sentencia, y la vamos a pegar aquí, de esta forma no tenemos que escribirla de nuevo. Presionamos Intro, y observemos que la última secuencia que tenemos es la número 55.

Entonces pensemos que el usuario que ha borrado los registros nos diga que en el momento de borrarlos, eran las 15 con 19 horas, bueno, pues a esa hora la secuencia de redo que se estaba utilizando por el sistema era la número 54. En este caso, a partir de la información que tenemos aquí, además de la hora proporcionado por el usuario que eliminó los registros, concluimos que debemos recuperar hasta la secuencia número 54.

Si insertamos un valor dentro de la tabla DATOS1, podemos observar que tiene un solo registro.

Recordemos que la secuencia sobre la que se está trabajando es la número 55, y nosotros necesitamos recuperar hasta algún punto de la secuencia 54. Antes hablamos de que siempre se perdian datos en una recuperación parcial, pues en nuestro ejemplo, si queremos tener los datos que se eliminaron, entonces no vamos a tener este último registro que insertamos.

Una vez que identifiquemos el punto a donde queremos volver, lo primero es parar la base de datos. Esto es debido, a que este tipo de recuperación necesita de los redo, archivers, etc.

Una vez se haya cerrado, debemos arrancar la base de datos en modo MOUNT, donde vamos a tener el fichero de control abierto, no así los ficheros de datos, por lo tanto podemos hacer este tipo de operaciones.

Recordemos que vamos a ser la recuperación por secuencia, pero después podemos hacerla por tiempo, o sea, POINT IN TIME RECOVERY.

Para hacer nos vamos a RMAN. Como quiera que tenemos que ejecutar varios comandos para hacer este tipo de recovery, y cada uno depende de que se ejecute correctamente el anterior, vamos a utilizar el RUN.

Primero debemos especificar hasta dónde queremos que se haga el recovery. Para esto tenemos un comando que es:

• SET UNTIL

Y ahora como vamos a recuperar a partir de una secuencia, ponemos SEQUENCE, pero también pudiéramos poner un TIME, y recordemos que necesitamos recuperar hasta la secuencia 54.

Presionamos Intro y vamos escribir el siguiente comando, vemos que no se ejecuta nada aún, si recordamos los bloques run solo se van a ejecutar después que cerremos el bloque con llave.

Si ya hemos indicado hasta qué punto queremos recuperar, podemos pasar a restaurar la base de datos:

• RESTORE DATABASE Es por esto que dijimos antes que se pierde todo lo que se haya hecho desde el punto al que queremos volver, hasta el punto en que nos encontramos. Aquí le estamos indicando que re