RAC, Data Guard y Stream son tres herramientas en el sistema de alta disponibilidad de Oracle. Cada herramienta se puede utilizar de forma independiente o en combinación. Tienen diferentes enfoques y son aplicables en diferentes escenarios.
RAC destaca en abordar el punto único de fallo y el equilibrio de carga. Por lo tanto, RAC se utiliza comúnmente en sistemas críticos de 24/7. Sin embargo, en la solución RAC, los datos existen en una sola copia. Aunque se pueden evitar fallos en el almacenamiento mediante mecanismos como RAID, los propios datos carecen de redundancia, lo que los hace vulnerables a puntos únicos de fallo.
Data Guard proporciona protección de datos mediante datos redundantes. Al utilizar mecanismos de sincronización de registros, Data Guard garantiza la sincronización entre los datos redundantes y los datos principales. Esta sincronización se puede lograr de varias formas, como en tiempo real, con retraso, síncrona o asincrónica. Data Guard se utiliza comúnmente en soluciones de recuperación ante desastres remotos y alta disponibilidad para pequeñas empresas. Aunque permite realizar consultas de solo lectura en la máquina de standby para aliviar la presión de rendimiento en la base de datos principal, Data Guard no está diseñada principalmente como una solución de rendimiento.
Streams, construido sobre Oracle Advanced Queue, permite la sincronización de datos y ofrece configuraciones flexibles en múltiples niveles. Dado que Oracle proporciona un amplio soporte para el desarrollo, incluidas APIs completas, Streams es más adecuado para el intercambio de datos a nivel de aplicación.
¿Qué es Data Guard?
En un entorno de Data Guard, hay al menos dos bases de datos: una en estado abierto proporcionando servicios externamente, conocida como la Base de Datos Primaria, y la otra en un estado de recuperación, conocida como la Base de Datos de Respuesta. Durante el tiempo de ejecución, la Base de Datos Primaria atiende a los clientes y las operaciones de usuario se registran en registros en línea y archivados, que luego se transmiten a la Base de Datos de Respuesta a través de la red. Estos registros se reproducen en la Base de Datos de Respuesta para lograr la sincronización de datos entre las dos.
Oracle Data Guard optimiza aún más este proceso, automatizando y simplificando las tareas de transmisión de registros y recuperación, al mismo tiempo que proporciona una variedad de parámetros y comandos para facilitar el trabajo de los administradores de bases de datos (DBAs).
Si hay factores previstos que requieren que la Base de Datos Principal sea apagada, como actualizaciones de software o hardware, la Base de Datos de Respuesta puede ser conmutada para convertirse en la Base de Datos Principal y continuar sirviendo a los clientes. Esto minimiza el tiempo de inactividad del servicio y asegura la integridad de los datos. En caso de problemas inesperados que hagan que la Base de Datos Principal no esté disponible, la Base de Datos de Respuesta puede ser conmutada forzosamente para convertirse en la Base de Datos Principal y continuar sirviendo a los clientes. El nivel de pérdida de datos en estos casos depende del nivel de protección de datos configurado. Por lo tanto, las bases de datos Principal y de Respuesta son roles conceptuales que no están fijados a bases de datos específicas.
Arquitectura de Data Guard
La arquitectura de Data Guard se puede dividir en tres partes funcionales:
1) Reenvío de Redo:
Durante la ejecución de la Base de Datos Principal, se generan continuamente registros de redo y deben enviarse a la Base de Datos de Respuesta. Esta acción de envío puede realizarse mediante los procesos LGWR o ARCH de la Base de Datos Principal. Los destinos diferentes para el archivado pueden utilizar métodos distintos, pero para un destino específico, solo se puede seleccionar un método. La elección del proceso tiene un impacto significativo en las capacidades de protección de datos y la disponibilidad del sistema.
2) Recepción de Registros:
El proceso RFS (Remote File Server) en la Base de Datos de Espera recibe los registros y los escribe en los archivos del Registro de Redo de Espera o en los archivos de Registro Archivado, dependiendo del método de transporte de registros de la Base de Datos Principal y de la ubicación de la Base de Datos de Espera. Si los registros se escriben en los archivos del Registro de Redo de Espera, entonces cuando ocurre un cambio de registro en la Base de Datos Principal, desencadena un cambio de registro en el Registro de Redo de Espera de la Base de Datos de Espera y archiva ese Registro de Redo de Espera. Si los registros se escriben en Registros Archivados, esta acción puede considerarse como una operación de archivado en sí misma.
3) Reaplicación:
El servicio de reaplicación es responsable de reproducir los registros de la Base de Datos Principal en la Base de Datos de Respuesta, logrando así la sincronización de datos entre las dos bases de datos.
Dependiendo de cómo la Base de Datos en Espera replique los registros, hay dos tipos: Base de Datos Física en Espera y Base de Datos Lógica en Espera.
Según cuándo ocurra Redo Apply, también hay dos tipos:
a) Aplicación en Tiempo Real: Este método requiere el uso del Registro Redo de Standby. Cada vez que un registro se escribe en el Registro Redo de Standby, esto desencadena la recuperación. El beneficio de este método es que reduce el tiempo necesario para el cambio de base de datos, ya que los registros restantes ya se han recuperado en tiempo real.
b) Aplicar en Archivo: Este método aplica los registros cuando se produce un cambio de registro en la Base de Datos Principal y desencadena el archivo en la Base de Datos Secundaria. La recuperación se inicia después de que se complete el proceso de archivado. Este también es el modo de recuperación predeterminado.
Standby Físico vs. Standby Lógico
Existen dos tipos de Bases de Datos de Standby: Standby Físico y Standby Lógico.
1. Base de datos Física de Repuesto:
Una base de datos Física de Repuesto es igual que una base de datos Primaria. Data Guard mantiene la base de datos Física de Repuesto a través de la aplicación de REDO. En general, cuando la Física de Repuesto no está aplicando REDO, se puede abrir en modo READ ONLY. Si se especifica un Área de Flashback en la base de datos, incluso se puede cambiar temporalmente al modo READ WRITE para realizar operaciones. Después de completar las operaciones necesarias, la base de datos se puede restaurar a su estado anterior al modo READ WRITE utilizando la característica de Flashback Database, permitiendo que continúe la aplicación de datos REDO desde la base de datos Primaria.
Nota: La funcionalidad de la aplicación de Physical Standby ha sido mejorada en Oracle 11g. En esta versión, Physical Standby puede continuar aplicando datos REDO mientras está en modo OPEN READ ONLY. Esto mejora considerablemente la utilidad de las bases de datos Physical Standby.
Características de la copia de seguridad física:
1) Recuperación ante desastres y alta disponibilidad: Physical Standby proporciona una solución robusta y eficiente para la recuperación ante desastres y la alta disponibilidad. Simplifica la gestión del cambio de rol/fallo y reduce el tiempo de inactividad planificado o no planificado.
2) Protección de datos: Con una base de datos Standby Física, Data Guard garantiza que la pérdida de datos se minimiza, incluso ante desastres inesperados.
3) Transferir carga de trabajo de la base de datos principal: Al transferir ciertas tareas, como las copias de seguridad y las consultas de solo lectura, a la base de datos de respaldo físico, se pueden conservar los recursos de CPU y E/S en la base de datos principal.
4) Mejora del rendimiento: El mecanismo de aplicación REDO utilizado en las bases de datos de Standby Físico opera al nivel más bajo de recuperación, evitando la ejecución del código SQL. Esto da como resultado la mayor eficiencia y rendimiento.
2. Base de datos Lógica Secundaria:
Una base de datos Lógica Secundaria también se crea basándose en la base de datos Primaria (o en sus copias de seguridad o réplicas, como una Física Secundaria). Por lo tanto, inicialmente, es similar a una base de datos Física Secundaria al principio. Sin embargo, dado que una Lógica Secundaria aplica datos REDO mediante la ejecución de SQL, su estructura física de archivos e incluso la estructura lógica de los datos pueden ser diferentes a los de la base de datos Primaria.
A diferencia de la Instancia Física de Respuesta, una Instancia Lógica de Respuesta normalmente se abre en modo READ WRITE, permitiendo a los usuarios acceder a ella en cualquier momento. En otras palabras, la ejecución de SQL ocurre mientras la Instancia Lógica de Respuesta está en estado ABIERTO. Esto tiene ventajas e inconvenientes. Debido a la naturaleza de la ejecución de SQL, existen limitaciones operativas en ciertos tipos de datos y algunas instrucciones DDL/DML en una Instancia Lógica de Respuesta. Puedes verificar los tipos de datos no soportados en la vista DBA_LOGSTDBY_UNSUPPORTED. Si se utilizan tales tipos de datos, no se puede garantizar una completa consistencia en la base de datos.
La apertura en modo READ WRITE de un Standby Lógico lo hace adecuado para su uso como sistema de informes, aliviando la carga de trabajo del sistema.
Características de la Instancia Lógica:
Además de las características mencionadas anteriormente para la Base de Datos Física de Repuesto, como recuperación ante desastres, alta disponibilidad y protección de datos, la Base de Datos Lógica de Repuesto tiene las siguientes características:
1) Utilización eficiente de los recursos de hardware en el servidor de respaldo: Una base de datos Logical Standby se puede utilizar para crear índices adicionales, vistas materializadas y satisfacer necesidades empresariales específicas. También puede crear nuevos esquemas (que no existen en la base de datos Primaria) y ejecutar operaciones DDL o DML que no son apropiadas en la base de datos Primaria.
2) Descargar la carga de trabajo de la base de datos principal: Al mantener la base de datos Logical Standby abierta mientras permanece sincronizada con la base de datos principal, puede atender tanto las operaciones de protección de datos como las de informes. Esto libera a la base de datos principal de las tareas de generación de informes y consultas, ahorrando valiosos recursos de CPU y E/S.
3) Mejoras suaves: La reserva lógica se puede utilizar para operaciones como actualizaciones entre versiones y aplicación de parches en la base de datos.
Modos de Protección de Datos
Guardia de Datos permite tres modos de protección de datos: Máxima Protección, Máxima Disponibilidad y Máximo Rendimiento.
1. Protección Máxima:
Este modo garantiza la pérdida cero de datos. Para lograrlo, todas las transacciones no solo deben escribirse en los registros de redo locales antes del commit, sino que también deben escribirse simultáneamente en los registros de redo de la base de datos de standby. Los datos REDO deben estar accesibles en al menos una base de datos de standby (si existen múltiples) antes de poder realizarse el commit en la base de datos principal. En caso de que la base de datos de standby no esté disponible debido a un fallo (por ejemplo, una interrupción de red), la base de datos principal se apagará para evitar la pérdida de datos.
Habilitar este modo requiere que la Base de Datos en Espera esté configurada con Registros de Redo en Espera, y que la Base de Datos Primaria utilice el modo LGWR, SYNC, AFFIRM para archivar en la Base de Datos en Espera.
2. Disponibilidad Máxima:
Este modo proporciona el nivel más alto de estrategia de protección de datos sin afectar la disponibilidad de la base de datos Principal. Sigue una implementación similar al modo de Protección Máxima, donde las transacciones locales deben escribirse en los Registros de Redo de Respuesta de al menos una base de datos de Respuesta antes del compromiso. Sin embargo, la diferencia es que si ocurre un error que hace que la base de datos de Respuesta no esté accesible, la base de datos Principal cambiará automáticamente al modo de Rendimiento Máximo en lugar de cerrarse. Una vez que la base de datos de Respuesta se recupera, la base de datos Principal volverá automáticamente al modo de Disponibilidad Máxima.
Aunque este modo tiene como objetivo minimizar la pérdida de datos, no puede garantizar una consistencia absoluta de los datos. Al igual que el Modo Máxima Protección, este modo requiere que la Base de Datos de Espera esté configurada con Registros de Redo de Espera, y que la Base de Datos Principal utilice el modo LGWR, SYNC, AFFIRM para archivar en la Base de Datos de Espera.
3. Rendimiento Máximo:
Este modo proporciona el nivel más alto de estrategia de protección de datos sin afectar el rendimiento de la base de datos Principal. Las transacciones pueden confirmarse en cualquier momento, y los datos REDO de la base de datos Principal actual deben escribirse en al menos una base de datos de Respuesta, aunque esto se puede hacer de forma asincrónica. En condiciones de red ideales, este modo puede ofrecer una protección de datos similar a la de Disponibilidad Máxima mientras tiene solo un impacto mínimo en el rendimiento de la base de datos Principal. Este es el modo de protección predeterminado al crear una base de datos de Respuesta. Se puede lograr utilizando tanto los procesos LGWR ASYNC como ARCH, y no se requieren Registros REDO de Respuesta para la base de datos de Respuesta.
Pasos para modificar el modo de protección de datos:
1. Apaga la base de datos y reiníciala en estado de Montaje. Si es una configuración RAC, apaga todas las instancias y arranca solo una instancia en estado de Montaje.
2. Modifique el modo utilizando la siguiente sintaxis:
ALTER DATABASE SET BASE DE DATOS EN ESPERA PARA MAXIMIZAR {PROTECTION | AVAILABILITY | PERFORMANCE};
Por ejemplo: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. Abre la base de datos: ALTER DATABASE OPEN;
4. Confirma el modo de protección de datos modificado:
SQL>select protection_mode,protection_level from v$database;
Servicios de Aplicación de Registros
Data Guard asegura la coherencia entre la base de datos Primaria y las bases de datos de Standby aplicando REDO. En segundo plano, respaldando silenciosamente este proceso, están los reconocidos Servicios de Aplicación de Registros. Existен dos tipos de Servicios de Aplicación de Registros:
1. Aplicación de REDO: Exclusivo para bases de datos Standby físicas, las mantiene sincronizadas con la base de datos Primaria a través de la recuperación por medios.
2. Aplicación SQL: Exclusivo para bases de datos de Standby lógico, su funcionalidad principal consiste en analizar sentencias SQL a través de LogMiner y ejecutarlas en el lado de Standby.
Por lo tanto, al aplicar los datos REDO, la base de datos Standby física debe estar en un estado MOUNT, mientras que la base de datos Standby lógica se abre en modo READ WRITE para la aplicación de datos REDO. Sin embargo, los objetos que se están mantener están configurados como de solo lectura de forma predeterminada y no se pueden modificar directamente en el lado de la Standby lógica.
Protege la base de datos Oracle con una solución profesional
Oracle Data Guard es una solución robusta para alta disponibilidad, protección de datos y recuperación ante desastres. Es una herramienta crítica para empresas que no pueden permitirse tiempos de inactividad significativos o pérdida de datos. Sin embargo, para proteger aún más tu entorno de base de datos, se recomienda respaldar tu base de datos Oracle con una solución profesional de copia de seguridad y recuperación ante desastres.
Vinchin Backup & Recovery ofrece una funcionalidad poderosa para proteger tus bases de datos en máquinas virtuales y servidores físicos, siendo bastante automática, flexible y eficiente. Proporciona protección de múltiples tipos de bases de datos como Oracle DB, MySQL, SQL Server, Postgres Pro y MariaDB, con soporte para compresión de bases de datos, gestión centralizada de trabajos, estrategias inteligentes de copia de seguridad, copia de seguridad de bases de datos en caliente y soporte avanzado para SQL Server/Oracle. Además, también ofrece una función potente de protección contra ransomware y migración V2V entre más de 10 plataformas virtuales.
Vinchin Backup & Recovery ha sido seleccionado por miles de empresas y tú también puedes comenzar a usar este poderoso sistema con una prueba completa de 60 días¡Sin límites! Además, contáctenos y comparte tus necesidades, y recibirás una solución acorde a tu entorno de TI.
Conclusión
Oracle Data Guard es un componente crítico para cualquier implementación de bases de datos Oracle a nivel empresarial, proporcionando una solución integral para la recuperación ante desastres, alta disponibilidad, protección de datos y equilibrio de carga de trabajo. Su arquitectura flexible y diversos modos de operación lo hacen adaptable a una amplia gama de necesidades empresariales y requisitos operativos.
Puedes elegir Vinchin Backup & Recovery para hacer copias de seguridad y recuperar tus bases de datos Oracle de manera fácil. ¡No te pierdas la prueba gratuita!
