Skip to main content
Sistema de replicación de bases de datos Oracle basado en scripting

Sistema de replicación de bases de datos Oracle basado en scripting

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (Ninguna valoración todavía)
Cargando…

En este post describiremos una solución de replicación de BBDD (bases de datos) Oracle basado en scripting que cumple con las siguientes funciones principales u objetivos:

  • Servir de origen de datos para cualquier tipo de consulta/informe solicitado ad-hoc o publicado a través de los sistemas BI o Explotación Estadística (EE) que disponga la empresa (OBIE, Pentaho, Qlickview, MicroStrategy, B.O.etc). Ver post anterior sobre origen de datos “ETL Source” para la explotación a través de Pentaho.
  • Servir de sistema de Respaldo ante fallos generalizados de los sistemas de BBDD de Producción, entre los fallos generalizados se pueden encontrar: fallos de los sistemas hardware de producción, corrupción de ficheros en origen, borrado accidental de ficheros en origen, etc.

Para cumplir con ambas funciones se ha diseñado un sistema de replicación apoyado en scripting de SO (Sistema Operativo), que no requiere de software o hardware adicional para implementar las especificaciones requeridas.

En el caso de trabajar con la capa ASM de Oracle, se requiere de una BBDD auxiliar para la gestión de las copias de ficheros entre los grupos de discos ASM, que no tiene que ser exclusiva para este propósito, puede estar dando servicio a otras tareas o aplicaciones.

Pasaremos a estudiar las características que debe tener el sistema para poder atender a las dos funciones anteriormente descritas y su funcionamiento a alto nivel.

Características del Sistema de Replicación

Soportado

El sistema de replicación se basa en los mecanismos de recuperación “en caliente” de BBDD Oracle, consistente en partir de una copia “en caliente” (copia física completa), de la BBDD e ir aplicando ficheros de redo log archivados hasta el momento que se necesite. Este mecanismo es un mecanismo “soportado” por Oracle, que lo llama “user-managed” backups (para más información http://docs.oracle.com/cd/E11882_01/backup.112/e10642/osbackup.htm).

No invasivo

El sistema no es invasivo respecto a los sistemas de BBDD de producción, no se ha de aplicar ningún tipo de parametrización adicional en dichos sistemas, el mantenimiento recae mayoritariamente en el servidor encargado de las réplicas.

Consolidación

El servidor encargado de las réplicas no tiene que ser dedicado, es decir, el sistema de replicación se puede implantar conjuntamente a otro entorno, como DESARROLLO, IMPLANTACIÓN, …

ASM/RAC

El sistema de replicación se ha diseñado para su funcionamiento con sistemas de ficheros tradicionales y con el subsistema de almacenamiento Oracle ASM (Automatic Storage Management) y RAC (Real Application Clusters).

Independencia

El sistema de replicación está basado en scripting de SO, no depende de opciones software adicionales u otro tipo de tecnología como las opciones de replicación que suelen presentar las cabinas de almacenamiento.

Funcionamiento del Sistema de Replicación

Funcionamiento con Sistemas de ficheros tradicionales JFS2

Funcionamiento con Sistemas de ficheros tradicionales JFS2

  1. Traspaso en caliente de los ficheros de la BBDD sobre alguno de los volúmenes del sistema de réplica (/u03, /u04, …)
  2. Traspaso continuo de ficheros de redolog archivados, cada 30 minutos o el tiempo que se considere apropiado.
  3. Generación de snapshots jfs2.
  4. Recuperación en caliente de la BBDD. [“Explotación y Análisis de datos” en color verde el gráfico]
  5. Recuperación snapshots.
  6. Recuperación en caliente de la BBDD a partir del snapshot y aplicación de todos los archs hasta el momento necesario. (desfase máximo: 30min o el tiempo que se hubiera marcado) [“Respaldo de los Sistemas de Producción” en color rojo en el gráfico]

Funcionamiento con ASM Oracle y RAC

Funcionamiento con ASM Oracle y RAC

  1. Traspaso en caliente de los ficheros de la BBDD sobre uno de los grupos de discos ASM (+DATA, …), se requiere de la instancia auxiliar SIDAUX.
  2. Traspaso continuo de ficheros de redolog archivados, cada 30 minutos o el tiempo que se considere apropiado.
  3. Generación de backups de ficheros ASM (+DATA/…/backup).
  4. Recuperación en caliente de la BBDD en modo RAC. [“Explotación y Análisis de datos” en color verde en el gráfico]
  5. Recuperación de backups de ficheros ASM.
  6. Recuperación en caliente de la BBDD a partir del backup de ficheros ASM y aplicación de todos los archs hasta el momento necesario. (desfase máximo: 30min) [“Respaldo de los Sistemas de Producción” en color rojo en el gráfico]

A partir del punto 4, las BBDD están disponibles para servir de origen de datos para cualquier tipo de explotación, como consultas ad-hoc o sistemas BI o Explotación Estadística (EE)

En caso de error en los sistemas originales de producción, que requieran una recuperación basada en el sistema de réplica, pasaríamos por los puntos 5 y 6, quedando la BBDD original de producción recuperada hasta el momento que se requiera (como máximo puede existir una pérdida de información de 30 minutos o el tiempo que se hubiera marcado).

Esta BBDD recuperada es una copia física de la BBDD de producción, no existiendo ningún cambio lógico en la misma, los únicos cambios son relativos a la estructura física y parametrización (ubicación de los ficheros de datos, fichero de arranque tipo “init”, parametrización genérica).

De esta forma lo único que se requiere para que el servidor de réplica y la BBDD recuperada adquieran el “roll” temporal de producción es la asignación de la IP de servicio del servidor original de producción.

Una vez cambiada la ip de servicio, las aplicaciones podrán conectar directamente con la nueva BBDD de producción (ubicada en el servidor de replica), dando continuidad a los servicios afectados.

Resultados

La implantación de nuestro sistema de replicación Oracle basado en scripting de SO puede provocar la reducción de costes de las empresas ya que no serían necesarias otras soluciones software para implantar una replicación de BBDD efectiva u otras soluciones hardware como las que encontramos en las cabinas de almacenamiento de medio/alto nivel.

Si necesita más información sobre el diseño de esta solución de replicación de BBDD Oracle , póngase en contacto con nosotros.

 

 

Francisco Javier Pardillo Martín

Francisco Javier Pardillo Martín

Consultor Senior Base de Datos que con más de 12 años de experiencia como DBA y con más de 10 certificaciones, destacando: Oracle RAC 11g Release 2 and Grid Infrastructure Administration, Oracle Database 11g:New Features for Oracle10g OCP, Oracle Database 11g Data Warehousing y Oracle GoldenGate 10 Certified Impl Specialist

Francisco Javier Pardillo Martín ha escrito 5 entradas


Francisco Javier Pardillo Martín

Francisco Javier Pardillo Martín

Consultor Senior Base de Datos que con más de 12 años de experiencia como DBA y con más de 10 certificaciones, destacando: Oracle RAC 11g Release 2 and Grid Infrastructure Administration, Oracle Database 11g:New Features for Oracle10g OCP, Oracle Database 11g Data Warehousing y Oracle GoldenGate 10 Certified Impl Specialist

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *