LA IMPORTANCIA DE LA COPIA DE BASE DE DATOS EN TIEMPO REAL

  • Actualizado: 1 marzo 2023
  • Publicado por primera vez: 16 septiembre 2014

importancia respaldo base de datos

"Si algo puede salir mal, saldrá mal” este sencillo enunciado de la Ley de Murphy aplicado hoy al mundo de las tecnologías de la información y las comunicaciones (TIC) en la empresa, evidencia la necesidad del diseño de unos planes de contingencia o de continuidad de negocio con los que se pueda hacer frente a las caídas de los sistemas informáticos. Imagine que durante unas horas o varios días, alguna de sus aplicaciones críticas no está disponible, ¿cuántos pedidos dejaría de recibir o servir?, ¿cuál sería la pérdida de prestigio y confianza ante sus clientes?, ¿cuántos de ellos perdería para siempre?, en definitiva, ¿cuál sería el impacto en sus clientes y la cuantía de las pérdidas económicas propias?

En la actualidad todos los proveedores de bases de datos proporcionan sus utilidades para poder realizar cada ciertorespaldo de datos en tiempo real 1 tiempo (asíncronamente) copias de seguridad totales y/o incrementales. Este es el primer paso (mínimos) en la estrategia de recuperación ante desastres. Un paso más avanzado, lo constituye el disponer de un sistema de respaldo de datos en tiempo real, o de alta disponibilidad (High Availability) que replique los cambios en continuo (síncronamente) en el sistema remoto. Esto último nos permite minimizar en caso de desastre el tiempo de pérdida de datos, así como el tiempo que permanecemos sin servicio o el tiempo que tardamos en retornar a una situación estable.  Estos 3 parámetros son indicadores de la calidad de nuestro sistema de respaldo.

Además de sincronizar datos las aplicaciones de alta disponibilidad también permiten actualizar cambios en:

  • La estructura de los mismos (nuevas columnas de las tablas, nuevos índices o constraints, cambios de tipos de datos, creación de nuevas tablas, etc.).
  • La programación de la base de datos (paquetes, funciones, procedimientos, jobs, triggers, etc.) que da soporte a las aplicaciones informáticas que se ejecutan contra la misma.

Esta funcionalidad nos permite mantener igualadas las bases de datos origen y destino de la replicación, de manera que en el momento en que decidamos pasar a trabajar contra la base de datos de respaldo (en caso de desastre en el sistema principal), tengamos la garantía de que las aplicaciones van a continuar ejecutándose correctamente.

EBOOK GRATIS: 12 consejos para implantar un ERP con éxito


Las 7 preguntas que consideramos son claves para ayudarnos a diseñar adecuadamente nuestro sistema de respaldo de datos en tiempo real son:

 

  1.  ¿Qué datos necesitamos replicar y hacia dónde? Conviene replicar sólo lo estrictamente necesario para evitar así un costoso sobredimensionamiento de nuestro sistema. Las aplicaciones de replicación en tiempo real nos proporcionan funcionalidades de filtrado nativas sobre las estructuras de datos para limitar fácilmente el alcance de la replicación

  2. ¿Cuál sería el tiempo máximo de desfase temporal aceptable entre la base de datos origen y la/s de destino? (latencia). Notar que esta latencia determinará el tiempo de pérdida de datos mínimo, esto es, en caso de desastre en origen, el tiempo de actividad para el que puede resultar imposible recuperar los datos.

  3. ¿Dispongo de la suficiente velocidad de transmisión y fiabilidad en mi red y líneas de comunicación? El ancho de banda de nuestras comunicaciones debe ser capaz de garantizar la latencia deseada en los momentos de máximo volumen de operaciones en origen y tráfico de datos. Cualquier corte en las comunicaciones puede provocar la necesidad de retransmitir datos, empeorando esto la latencia de nuestro sistema, y en el peor caso, dejándolo inoperativo. En un entorno de alta disponibilidad, es siempre un requisito ineludible disponer de redundancia en las líneas de comunicaciones para evitar estos problemas.

  4. ¿Soporta mi sistema la heterogeneidad de bases de datos con la que quiero trabajar?  Por heterogeneidad nos referimos a que la tecnología o fabricante (Oracle, SQL Server, DB2, etc.) de la base de datos origen sea distinta del de la de destino. Por ejemplo, que la base de datos en origen sea Oracle, mientras que una de las bases de datos en destino sea SQL Server o DB2.

  5. ¿Qué mecanismo de carga inicial es el más adecuado?Previamente a activar el sistema de replicación es necesario ejecutar una única vez un procedimiento de carga inicial que vuelque en destino masivamente todos los datos que existen en origen. Dependiendo de la aplicación concreta de replicación que utilicemos y de la tecnología de base de datos el abanico disponible de mecanismos de carga inicial será más o menos amplio, aunque ésterespaldo de datos en tiempo real 3 también vendrá condicionado por la existencia o no de heterogeneidad entre origen y destino. Si no hay heterogeneidad, lo más sencillo y eficaz será utilizar el mecanismo nativo de copia masiva entre bases de datos (export-import) que nos proporcione el fabricante. En el caso de heterogeneidad lo más probable es que necesitemos realizar un volcado previo de los datos de origen a ficheros en formato ASCII, y a continuación, utilizando una funcionalidad nativa de la aplicación de replicación o de la base de datos, realizar la carga de los datos en destino leyendo esos ficheros.

  6. ¿Voy a necesitar realizar operaciones de mapeado? En el caso de que las estructuras de datos en destino no sean idénticas a las de origen, necesitaremos mapear explícitamente las correspondencias a nivel de esquema (usuario de base de datos), tabla e incluso columna. En el caso de que exista heterogeneidad (tecnologías de base de datos distintas entre origen y destino) también es muy probable que necesitemos realizar mapeado.

  7. ¿Voy a necesitar realizar operaciones de transformación? Las operaciones de transformación consisten en formular nuevas columnas en destino que no existen en origen, contra el valor de alguna/s columna/s de origen. Estas operaciones son típicas cuando el destino es una base de datos que actúa como servidor estadístico del que leen los datos las aplicaciones de Business Intelligence (BI) para generar informes y cuadros de mando.

Nuevo llamado a la acción