blog

Cada cierto tiempo, todo DBA que se precie recibirá por parte de sus usuarios la petición de “recuperar” unas pocas tablas (o una única tabla) de alguna de las BBDD que administre… y seguramente la mayor de todas ellas será la que se pida recuperar con más frecuencia 😉 Dependiendo del volumen de la BBDD, de si las copias se encuentran en appliances de backup o en cintas, de si podemos lanzar la recuperación en horario laboral o incluso de la versión de la BBDD (con una Enterprise Edition es posible “paralelizar” la recuperación, con una Standard Edition, no), el procedimiento puede llevar horas.

 

Para intentar encontrar solución a este problema usaré una combinación de funcionalidades de las BBDD Oracle y del sistema de almacenamiento. Estas  funcionalidades las encontramos en todos los appliances de storage modernos y en sistemas de ficheros avanzados (como ZFS o ACFS de Oracle) o incluso en los volúmenes de disco en la nube (como los que encontramos en el Cloud de Oracle). La idea consiste en mantener “fotos” de la BBDD en diferentes momentos en el tiempo y poder ponerlas en marcha en pocos minutos en caso necesario. Crearemos una copia de la BBDD productiva, y cada cierto tiempo vamos a recopilar los cambios que se hayan hecho en producción y los vamos a aplicar sobre la copia. En otras palabras: la copia en disco “avanzará” en el tiempo siguiendo la productiva de manera escalonada (en “saltos” de varios minutos u horas). Una vez aplicados cambios le haremos una “foto” que guardaremos y volveremos a empezar: aplicar cambios y foto, aplicar cambios y foto, etc. Guardaremos tantas “fotos” como creamos necesario. Cuando tengamos que recuperar iremos a la “foto” (punto en el tiempo) que más nos convenga y la activaremos para poder acceder a sus datos.

 

En palabras un poco mas técnicas, partiremos de un backup de nivel “cero” de la BBDD productiva de tipo “datafilecopy”, un backup en que los ficheros que componen la BBDD se copian totalmente, tal y como son (no hay optimización de espacio no usado, ni compresión ni similares): esta copia va a ocupar exactamente lo mismo que ocupa la BBDD. A continuación, con la periodicidad que decidamos, vamos a lanzar una copia incremental de nivel “uno”, es decir, una copia de todos los bloques que son diferentes de los copiados en el backup nivel cero anterior. El tercer paso consiste en aplicar esta copia incremental sobre el backup de nivel “cero” haciendo que este “avance en el tiempo”. Finalmente lanzaremos un “snapshot” mediante funcionalidades propias del sistema de almacenamiento que nos guardará la imagen actual de los ficheros en disco y nos permitirá volver a ellos si es necesario. Para usar esta técnica vamos a necesitar espacio en disco, de hecho tanto como el ocupado por la BBDD (recordemos que la copia base es completa, sin optimización alguna), más el espacio equivalente a los cambios que hagamos en la BBDD durante el tiempo que queramos mantener (el de la “foto” mas antigua a la queramos poder volver). Si vamos a hacer un “snaphot” cada día y queremos mantener siete de ellos, pues será el tamaño de la BBDD más los cambios a nivel de bloque de una semana.

 

A modo de ejemplo empezamos haciendo uso de la funcionalidad de incrementales de RMAN y lanzamos un backup incremental nivel cero con un comando similar al este:

 

BACKUP INCREMENTAL LEVEL 0 DATABASE TAG ‘BACKUP_BASE’;

 

Una vez tengamos este backup usaremos las funciones de “snapshot” del sistema de almacenamiento de que dispongamos. Por ejemplo para un appliance de storage NetApp o para ZFS serían comandos similares a:

 

cluster1::> volume snapshot create -vserver vs0 -volume datafiles -snapshot day_month_year_hour

 

zfs snapshot datapool/datafiles@day_month_year_hour

 

Ya tenemos la imagen base del backup, algo más tarde lanzamos un backup incremental con un comando parecido al siguiente:

 

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘BACKUP_BASE’ DATABASE;                            

                                                        

En el sistema de ficheros nos encontramos con los ficheros del backup de nivel cero (básicamente la copia binaria de la BBDD) y del incremental (con los cambios realizados desde la copia). El siguiente paso consiste en fusionarlos mediante la siguiente funcionalidad “RECOVER COPY OF DATABASE” de RMAN; el comando serÍa parecido a este:

 

RECOVER COPY OF DATABASE WITH TAG ‘BACKUP_BASE’;

 

La copia de la BBDD ya ha “avanzado” en el tiempo hasta el momento del backup incremental; es momento de lanzar otro “snapshot” igual que lo hemos hecho antes. Seguiremos realizando este procedimiento en los intervalos que creamos oportunos manteniendo los “snapshots” que creamos convenientes con lo que en todo momento disponemos de varios “snapshots” que nos mostrarán la BBDD en diferentes momentos del tiempo.

 

Supongamos que nos piden recuperar una tabla de la copia de la BBDD de hace unos días y que disponemos de un “snapshot” que nos encaja a nivel de fechas (recordemos que podemos recuperar la BBDD únicamente en los puntos en el tiempo que lanzamos las copias).

 

NOTA: Con un poco mas de trabajo, y si disponemos de los archivados pertinentes, podríamos incluso ir a puntos entre esas copias, pero no entraremos a ese nivel de detalle en este post.

 

Pedimos al sistema de storage que nos muestre los ficheros de un determinado “snapshot”, en algunos casos esto es “tan simple” como ir a una subcarpeta del sistema de ficheros principal (normalmente oculta). En otros casos será necesario montar un nuevo sistema de ficheros en la máquina. En la mayoría de casos podemos ver los ficheros del “snapshot” por defecto en modo sólo lectura, pero para abrir la BBDD los necesitamos en lectura/escritura; copiarlos a otro volumen de tipo lectura/escritura implica duplicar el espacio y puede tardar mucho tiempo por lo que optamos por hacer un “clon” (lo que vendría a ser un “snapshot del propio snapshot”) que nos permita modificar sus ficheros. Para cada sistema de almacenamiento tendremos que usar los comandos apropiados. Por ejemplo para un appliance de storage NetApp o para ZFS sería:

 

cluster1::> volume clone create -vserver vs0 -flexclone datafiles_clone -type RW -parent-volume  datafiles

 

zfs clone datapool/datafiles@day_month_year_hour datapool/datafiles_clone

 

La creación del clon es inmediata, ya que no se produce copia de datos. El “clon” tendrá como base el propio “snapshot”; esto implica que inicialmente el “clon” no va a ocupar espacio alguno, y a diferencia del “snapshot” del que se ha creado el clon se puede modificar. A medida que empecemos a modificar la BBDD recuperada (los ficheros en el sistema de ficheros clonando) este empezará a ocupar espacio correspondiente a los bloques modificados y por tanto diferentes entre el “clon” y el “snapshot”.

 

El siguiente paso consiste en hacerlo visible en la máquina en que queramos arrancar la BBDD usada para recuperar (caso que no lo sea ya).

 

NOTA: Usar la misma máquina en que tenemos la BBDD origen o una máquina que tenga acceso al sistema de ficheros de la BBDD origen no es recomendable en absoluto. Deberemos ser extremadamente cuidadosos para evitar que haya problemas de sobreescritura de ficheros.

 

En función de si recuperamos la BBDD en la misma máquina y diferentes directorios o en una máquina diferente con el mismo árbol de directorios o uno diferente deberemos realizar más o menos pasos. En un caso ideal de máquina diferente y mismo árbol de directorios, copiando o recreando los ficheros de inicialización y password, así como creando los directorios de auditoría, ya estaríamos en disposición de arrancar la BBDD.

 

Deberemos arrancar la BBDD en modo “mount” y lanzar el comando

 

SQL> ALTER DATABASE OPEN RESETLOGS;

 

Para recrear los ficheros de redo online, tardaremos unos pocos minutos para hacer todas estas operaciones, en especial si lo tenemos ya todo procedimentado. Si usamos la misma máquina que la BBDD origen (no lo recomiendo) deberemos preparar un fichero de inicialización apuntando a los ficheros de control clonados y añadir el parámetro “DB_UNIQUE_NAME”, indicando un nuevo SID para que las dos BBDD que se llaman igual no colisionen. Deberemos catalogar los nuevos ficheros en el controlfile clonado y realizar un “SWITCH DATABASE TO COPY;” Tenemos que modificar algunos ficheros más, por ejemplo los redo logs online (que siguen apuntando a los de la BBDD productiva), los renombramos con el comando “ALTER DATABASE RENAME FILE”.

 

Realizadas las tareas necesarias podremos abrir la BBDD igualmente que en el caso anterior mediante “ALTER DATABASE OPEN RESETLOGS”.

 

Listos, ya tenemos nuestra BBDD clonada operativa, y recordemos que el volumen ocupado en cabina prácticamente no ha variado, podremos crear un DBLINK entre las dos BBDD o usar expdp/impdp para trasladar los datos de una a otra.

 

BONUS: Esta operativa funciona tanto con BBDD Standard Edition como Enterprise Edition pero si sois los afortunados propietarios de  esta última existe una funcionalidad llamada “Block Change Traking” que va a aumentar de manera notable la velocidad de los backups incrementales.  Si activáis BTC la BBDD va a mantener una lista de los bloques modificados, de manera que el proceso de backup incremental no deberá recorrer todos los bloques de todos los ficheros buscando si han cambiado: irá “directo” a los modificados y esto, en caso de BBDD muy grandes, es un ahorro muy importante de tiempo.

 

BONUS 2: Quien dice una BBDD clonada para recuperar una o varias tablas dice toda la BBDD actuando como sistema de DR, siempre y cuando el entorno de storage y la máquina de recuperación sean remotos y nos podamos permitir “perder” el “gap” de datos entre copia y copia.