blog

El titulo de este post parece una panacea: imaginaros poder disponer de entornos de desarrollo “bajo demanda”, creándolos muy rápidamente y sin preocuparnos del espacio que ocupan (independientemente del tamaño de la BBDD origen)…

Existe la posibilidad de poder hacer algo parecido a esto si disponemos de un sistema de storage que nos permita replicar producción y realizar “snapshots” de esa replica o bien podemos aprovechar la funcionalidad de snapshot clone que nos proporciona Oracle Database desde la versión 11.2.

Las BBDD de tipo snapshot clone de Oracle prácticamente no ocupan espacio, ya que la BBDD clonada usa un backup de la BBDD origen para acceder a los datos (realmente no dispone de copia de los datos) y es cuando modificamos algún bloque que se realiza una copia con los nuevos datos modificados en los ficheros de la BBDD clonada (por lo que a medida que modifiquemos la BBDD clonada el espacio que ocupa irá creciendo).

El hecho de que los datos “base” de nuestro clon sean los de un backup nos permite desacoplar totalmente el entorno clonado del productivo (no interfiere uno con otro, pueden estar en servidores, cabinas e incluso CPD’s separados), y podemos crear tantos clones como queramos basados en el mismo backup (que habremos trasladado de producción al entorno de desarrollo o test). La copia debe ser de tipo “datafilecopy” y la podemos realizar en caliente mediante RMAN, en caliente manualmente con “begin/end backup” o en frío, y puede proceder de la BBDD origen o de una physical standby de ésta.

Notar que estos clones no están pensados para pruebas de rendimiento ya que el hecho de ir a buscar los bloques originales en el backup y los modificados en sus ficheros penaliza ese aspecto y por lo general los sistemas de storage de los entornos de desarrollo o test tampoco acostumbran a prestarse a este tipo de pruebas.

NOVEDAD: Indicar que a partir de la versión 12.1.0.2 se han relajado mucho los requisitos necesarios para poder usar esta funcionalidad, en esta versión podemos realizar clones sobre sistemas de ficheros locales. En versiones anteriores era necesario disponer de un sistema de ficheros NFS montado mediante el driver especifico de Oracle “dNFS” en el que crear la BBDD clon (notar que el backup no sufre esta restricción).

A continuación realizaremos una pequeña demostración de esta funcionalidad. En primer lugar lanzamos un backup de nuestra BBDD “origen”, realizamos un backup online con RMAN:

Otro componente necesario es una copia del SPFILE de la BBDD origen en formato PFILE (formato texto), lo generamos con este comando:

Ya tenemos la copia de la BBDD y el PFILE, en este punto ya los podriamos trasladar al entorno de desarrollo

Para nuestra demostración y por simplicidad crearemos el clon en el mismo servidor, de manera que creamos un directorio para la BBDD clonada (en un sistema de ficheros local de tipo ext4):

Llegados a este punto tenemos que definir unas variables de entorno (con los datos de la BBDD a clonar) y llamar a un script PERL que nos generará el fichero de inicialización y los scripts necesarios para crear la BBDD clon:

En primer lugar indicamos el directorio en que hemos dejado la copia de producción (MASTER_COPY_DIR), la carpeta en la que vamos a dejar los ficheros de nuestra BBDD clonada (CLONE_FILE_CREATE_DEST) y en tercer lugar el nombre de la BBDD clonada (CLONEDB_NAME).

Al script PERL, que ya viene con los binarios de la 12.1.0.2, le pasamos la ubicación del fichero pfile de producción y opcionalmente el nombre que queremos dar a los dos scripts de generación de la BBDD clon. Como resultado, nos dejará en la carpeta destino de la BBDD clon el fichero de inicialización modificado así como los dos citados scripts de creación en las ubicaciones que le hayamos indicado.

Deberemos “repasar” tanto el fichero de inicialización como los dos scripts, para asegurar que fucionan correctamente. A continuación os muestro la versión original y la modificada de todos ellos:

Fichero de inicialización:

Hemos realizado “limpieza” de parametros no necesarios, sustituido el SID de la BBDD origen (que seguia presente en algunos puntos) y eliminado los parametros que empiezan por “_”.

En el script de creación de la BBDD deberemos eliminar toda referencia a ficheros de no sean realmente de datos, ya que el script perl intenta añadir a la BBDD todos los ficheros que encuentra en la carpeta donde tenemos el backup (por lo que en esa carpeta deberiamos tener solo el backup, nada mas):

Finalmente para el segundo script tendremos que eliminar igualmente las referencias a ficheros que no sean de datos así como la parte final (de apertura de la BBDD y recreación de temporales):

El motivo de eliminar la parte de “open resetlogs” es a causa de que la copia que tenemos no es consistente (no todos los ficheros son del mismo punto en el tiempo) ya que es una copia en caliente (con la BBDD origen trabajando).

Para solucionar esto podemos o bien “aplicar” redo a la copia mediante un pequeño backup incremental posterior (con lo que quedaría consistente y ya la podríamos usar) o podemos aplicar el redo de producción directamente a la BBDD clonada.

En nuestro caso usaremos esta ultima aproximación, aplicaremos el fichero de redo archivado productivo generado durante el momento que hemos realizado la copia. Si pensáramos crear múltiples clones la mejor sería la primera, evitando tener que hacer recover en cada una de ellas.

Otra opción seria poner la BBDD origen en modo “begin backup” antes de la copia con RMAN o hacer la copia offline, pero eso no siempre es posible y menos con BBDD muy grandes.

Así pues lanzamos los scripts:

La ejecución de estos scripts ha sido prácticamente “instantánea”. Ahora aplicamos el redo a los ficheros de la BBDD clonada (y por tanto la dejamos en estado consistente) y abrimos con resetlogs:

Ya tenemos nuestra base de datos casi a punto, faltaría recrear el tablespace temporal y si queremos crear un spfile.

Vamos a realizar lo primero:

Bien, ¿realmente esta BBDD “no ocupa espacio”?

Aqui tenemos el espacio ocupado por los ficheros de la BBDD original:

Y éste es el espacio ocupado por los ficheros de la clonada (recordemos que ya hay algunos bloques modificados y que ocupan espacio, en concreto los que hemos alterado al hacer el recover para poder abrir la BBDD):

En la primera columna tenemos el espacio ocupado “realmente” (el que aparece si hacemos un “du” del fichero), en la sexta el “tamaño teórico” (mucho mayor).

Veamos que pasa si “modificamos” más datos en la BBDD clonada:

Como podemos ver, el fichero correspondiente al tablespace de users de la BBDD clonada ha pasado de ocupar 16K a 85Mb al contener la información que hemos actualizado y que difiere de la existente en el backup.