jueves, 6 de mayo de 2010

[Caso de estudio] Oracle export -> import usando Netcat

Existen muchas razones para ejecutar un export, el principal, es hacer un respaldo de la base de datos a manera de "protección" en caso de que esta se pierda. En principio, este mecanismo de respaldo es el más básico y, por supuesto, no se recomienda para bases de datos productivas de varios gigas de tamaño; para eso hay otros métodos más sofisticados que van desde el uso de RMAN hasta los respaldos a nivel filesystem como Netbackup de Veritas, EMC, etc.

Otro uso común del export es trasladar un esquema o esquemas o incluso la base de datos completa de un ambiente a otro, como por ejemplo: "planchar"(hacer una copia de la base de datos) el ambiente UAT con una copia del ambiente productivo, es decir, ejecutas un export de la base de datos productiva, se genera el archivo dump(.dmp) y ejecutas un import en la base de datos UAT. ¿Suena sencillo no? y lo es si la base de datos es relativamente pequeña, las complicaciones vienen cuando la base de datos es relativamente grande y el espacio en los filesystems no es suficiente para crear el archivo dump.

Otro uso no tan común es usar export/import para migrar una base de datos ó solo los objetos(esquemas) que interesan cuando se trata de un cambio de plataforma(sistema operativo), es decir, que si la base de datos está montada en un servidor Linux 64 bits e interesa montarla en un servidor con Solaris(SPARC) no es posible hacerlo copiando solo los archivos de base de datos de un servidor a otro como generalmente se hace cuando los servidores son de la misma plataforma, el mismo caso aplica cuando se trata de migrar de Solaris(SPARC) a HP-UX(RISC o Itanium) o viceversa. No es posible hacerlo debido al ENDIAN que emplea cada plataforma.

Haciendo a un lado la discusión del por qué cambiar de una plataforma a otra y enfocando la atención en cuales son los puntos a considerar(para migrar la base de datos de un servidor a otro) y poder llevarla a cabo en el menor tiempo posible, poniendo el caso de que se trata de una base de datos productiva relativamente grande(mayor a 1 Tb) y que no puede estar fuera de línea por un periodo largo de tiempo, se vuelve un reto con muchas vertientes.

La solución ideal, revisas en la documentación de RMAN la matriz que te muestra las plataformas para las que puedes crear "tablespaces transportables" con la versión del motor de tu bd actual. Si aplica, generas los tablespaces transportables correspondientes, los cargas en la bd de la nueva plataforma, bajas la base de datos productiva, aplicas los archive logs generados en la bd productiva desde que inició la generación de los tablespaces transportables en la bd de la nueva plataforma, levantas la nueva bd, pides que hagan pruebas con la aplicación apuntando a la nueva bd para validar que funciona correctamente y es todo, no debería llevarte más de un par de horas desde que bajas la base de datos productiva hasta que las pruebas con la aplicación puedan ser dadas como satisfactorias y la bd en la nueva plataforma se convierta ahora en la bd productiva. Por supuesto que tiene que haber todo un proceso de validaciones previas para que el plan sea exitoso, y sobre todo haber ejecutado el plan tantas veces como hayan sido posibles para afinar todos los detalles, resolver los errores presentados, entre otros muchos puntos.

Los puntos en contra, qué pasa si no puedes crear "tablespaces transportables" entre las dos plataformas, qué pasa si la plataforma lo permite(crear tablespaces transportables) pero no tienes espacio en los filesystems, qué pasa si la plataforma no lo permite(crear tablespaces transportables) y además no cuentas con espacio en los filesystems. Qué pasa si cuentas con el espacio suficiente y se requiere comprimir el respaldo para transferirlo por la red, qué pasa si el ancho de banda en la red no es aceptable(100 Mbps), etc., etc., etc.

Las variables en este sentido hacen que el proceso se vuelva complejo y lo mejor en este caso es ponerlas sobre la mesa y consultar con la empresa la posibilidad de que adquiera estos medios(más espacio, red gigabit o mejor, etc.)

Que tal si la empresa no está en posibilidad de adquirir ninguno de estos medios(más espacio, red gigabit, etc.); no en este momento quizá más por cuestiones de presupuesto que de no querer adquirirlo.

La solución. Usando recursos de *nix en combinación con el export/import es posible hacer la migración directa de base de datos a base de datos sin tener que generar el archivo dump, en donde además ambos procesos corren paralelamente, es decir, que desde que el export es lanzado, la salida que genera es transferida de manera immediata vía red al servidor donde se lanzó el import aplicando los datos al instante. ¿Cool cierto?


¿Qué necesitas?

  • Galleta(Poder de procesamiento) en ambos servidores.
  • Que la red sea velóz(mínimo Gigabit).
  • Optimizar la base de datos para el import.


Ventajas

Si ambos servidores tienen dos o más procesadores o procesadores con cores, se pueden lanzar en paralelo dos, tres, cuatro o hasta cinco procesos export/import. De entre tantas, tienes una tabla particionada de 300 Gb la cual puedes transferir por ejemplo en tres procesos que se encarguen de 100 Gb cada uno.


Compresión. Mejor aún, ¿que tal si en lugar de transferir 300 Gb por la red, sólo se transfiriera un porcentaje relatívamente mínimo? Suponiendo que la tabla en cuestión contiene solo campos con tipos de datos comunes(no LOBs, ni LONGs) el nivel de compresión con gzip puede ser de hasta un 80% o mayor. Es decir, que en lugar de transferir los 300 Gb de punto a punto, se aplica compresión gzip estandar reduciendo la transferencia a 55 Gb. O todavía mejor, que tal si lo aplicas al ejemplo de los tres procesos, repartirías entonces la carga de transferencia en 18.3 Gb por cada uno. ¡Super cool! He aquí donde entra en juego la "galleta" de los servidores.


Es necesario optimizar la base de datos en donde vas a ejecutar el import, la nota en Metalink 93763.1 contiene justamente lo que debes hacer. Esta optimización SOLO es para el import, después de asegurarte de que todo ocurrió satisfactoriamente y antes de que hagas el cambio para que la nueva bd sea ahora la bd productiva, será necesario regresar los parámetros a sus valores originales.

En el ejemplo de la tabla con un tamaño de 300 Gb, no tomé en cuenta los índices, es decir, solo tomo en cuenta que el tamaño de la tabla es de 300 Gb incluyendo el índice de la llave primaria, la tabla podría tener otros índices lo cual aumentaría considerablemente el volumen de transferencia, por ejemplo, si la tabla tiene además 5 índices con un tamaño en conjunto de 100 Gb, el total de transferencia sería de 400 Gb. Puesto que el objetivo es transferir lo esencial en el menor tiempo posible, es aceptable sólo transferir datos y posteriormente crear los índices en la bd destino. Generando por supuesto un script de la base de datos productiva con las sentencias para crearlos.

Con dos bases de datos una en 9i(origen) y la otra en 10g(destino) montadas en servidores HP-UX y una red a 100 Mbps, los números obtenidos para transferir un esquema completo de 2.3 Gb son:

Datos + índices + bd destino sin optimizar:
Mb TotalesMétodo de compresiónTiempo de transferencia
2,336compress362 Mb16:16 Min
2,336gzip254 Mb15:33 min


Datos - índices + bd destino optimizada:
Mb TotalesMétodo de compresiónTiempo de transferencia
1,387compress361 Mb07:01 Min
1,387gzip254 Mb06:12 min

Como se puede observar, el volumen de bytes transferido es casi el mismo con o sin índices, sin embargo, la diferencia está en el tiempo de transferencia la cual se reduce en un poco más del 50%. El ejercicio incluye también la comparación empleando dos métodos de compresión, siendo el más eficiente gzip tanto en bytes como en tiempo.

De acuerdo con Oracle, un import dura aproximadamente entre 2 y 2.5 veces la duración del export. En el caso del ejemplo, el tiempo de transferencia mostrado en las tablas es el tiempo que dura el import, más bien ambos, tanto el export como el import, de ahí que el mejor escenario sea de 6 minutos con 12 segundos(export/import optimizado) y el peor escenario sea de 15 minutos con 33 segundos(export/import tradicional), lo cual si lo aplicas a un ambiente de base de datos real en el orden de los cientos de gigas vemos que la diferencia es bastante considerable sobre todo por el hecho de que la migración se hace en un solo paso y dependes solamente del poder de procesamiento de los servidores y la velocidad de la red, ¿y el espacio en disco? ya no es ningún problema.

Desventajas

  • Este método no funciona con Data Pump
  • Si la transferencia es interrumpida debido a problemas en la red, se tiene que reiniciar el proceso desde cero.

Continuar leyendo...