Protección de datos de Oracle: Oracle Data Guard
El software que Oracle Corporation comercializa como Oracle Data Guard forma una extensión del sistema de gestión de bases de datos relacionales de Oracle (RDBMS). Ayuda a establecer y mantener bases de datos secundarias en espera como repositorios alternativos / complementarios a las bases de datos primarias de producción.
Oracle proporciona herramientas de interfaz gráfica de usuario (GUI) y de línea de comandos (CLI) para administrar las configuraciones de Data Guard.
Data Guard admite sitios en espera físicos y lógicos . Oracle Corporation hace que Data Guard esté disponible solo como una función integrada incluida en su "Enterprise Edition" de Oracle RDBMS .
Con las operaciones de Data Guard configuradas adecuadamente, los DBA pueden facilitar las conmutaciones por error o los cambios a hosts alternativos en la misma ubicación o en ubicaciones alternativas.
Configuraciones
Para los propósitos de Data Guard, cada base de datos de Oracle funciona en un rol de base de datos principal o en un rol de base de datos en espera, con la capacidad de pasar de un rol a otro.
Espera física (Rehacer Aplicar)
Una base de datos física en espera replica el contenido exacto de su base de datos principal en la capa de red de Oracle Net . Si bien las ubicaciones de almacenamiento físico relativas pueden diferir, los datos de la base de datos serán exactamente los mismos que los de la base de datos principal. Las bases de datos físicas en espera pueden funcionar en modo de recuperación administrada o en modo de solo lectura, pero no en ambos modos al mismo tiempo (a menos que las bases de datos estén en Oracle Database 11.1 o superior y la opción Active Data Guard tenga licencia; consulte a continuación) . El modo de espera hace uso de la tecnología "Rehacer Apply".
Las bases de datos físicas en espera tienen los mismos identificadores DBID que sus equivalentes principales.
Espera lógica (SQL Apply)
Las bases de datos lógicas en espera convierten el rehacer generado en la base de datos primaria en datos y SQL y luego vuelven a aplicar esas transacciones SQL en la lógica en espera. Por lo tanto, las estructuras físicas y la organización serán diferentes de la base de datos primaria. Los usuarios pueden leer desde las bases de datos lógicas en espera mientras se aplican los cambios y, si GUARD está configurado en STANDBY (ALTER DATABASE GUARD STANDBY;), escribir en tablas de la base de datos lógica en espera que no están siendo mantenidas por SQL Apply.
Desafortunadamente, hay una serie de objetos no admitidos (por ejemplo, tablas o secuencias propiedad de SYS, tablas que usan compresión de tablas, tablas que subyacen a una vista materializada o tablas temporales globales (GTT)) y tipos de datos no admitidos (es decir, tipos de datos BFILE, ROWID y UROWID, TIPOS definidos por el usuario, tipos de datos multimedia como Oracle Spatial, ORDDICOM y Oracle Text Collections (por ejemplo, tablas anidadas, VARRAY), SecureFile LOB, OBJECT RELATIONAL XMLTypes y BINARY XML). El modo de espera lógico puede no ser apropiado en tal caso.
Guardia de datos activa
La opción "Oracle Active Data Guard", una instalación con costo adicional, amplía la funcionalidad de Oracle Data Guard en configuraciones de Oracle 11g. Permite el acceso de solo lectura en el nodo físico en espera al mismo tiempo que se aplican transacciones archivadas desde el nodo principal. También cuenta con reparación automática de bloques y copia de seguridad incremental rápida en modo de espera físico,
Operación
Funcionalidad del lado del servidor
Los procesos LNS (servidor de red de escritura de registro) y ARCH (archivador) que se ejecutan en la base de datos primaria, seleccione los registros de rehacer archivados y envíelos al host de la base de datos en espera, donde el proceso en segundo plano de RFS (servidor de archivos remoto) dentro de la instancia de Oracle tarea de recibir registros de rehacer archivados que se originan en la base de datos primaria y escribirlos en un registro de rehacer en espera (SRL).
Alternativamente, un mecanismo complementario puede transferir los registros de rehacer archivados. En la base de datos en espera, un cliente de Fetch Archive Log ( FAL ) supervisa los huecos en la secuencia de los registros recibidos. Si encuentra una brecha, puede invocar uno o más servidores Fetch Archive Log (FAL) para que se ejecuten en la base de datos primaria y reenviar los elementos faltantes.
Una vez que los registros de rehacer archivados han llegado al host en espera, otros procesos, como un ARCH (proceso de archivado), un MRP (Proceso de recuperación administrado) y / o un LSP (Proceso lógico en espera), pueden comenzar a aplicar el contenido del registro. a la base de datos en espera.
El uso de registros de rehacer en espera puede acelerar la aplicación de cambios a una base de datos en espera con aplicación en tiempo real.
El proceso de conexión de Data Guard ( DRCX ) juega un papel en la transferencia de datos entre bases de datos.
Acceso del lado del cliente
El subsistema Data Guard Broker puede ayudar en la configuración, administración y monitoreo de las configuraciones de Data Guard.
Ventajas
Data Guard proporciona alta disponibilidad para un sistema de base de datos. También puede reducir la intervención humana necesaria para cambiar entre bases de datos durante la recuperación ante desastres ("conmutación por error") o la actualización / mantenimiento ("conmutación").
Mediante el uso de archivos de registro de rehacer en espera, Data Guard puede minimizar la pérdida de datos.
Admite configuraciones heterogéneas en las que los sistemas primario y en espera pueden tener diferentes arquitecturas de CPU, sistemas operativos (por ejemplo, Microsoft Windows y Linux), binarios del sistema operativo (32 bits / 64 bits) o binarios de bases de datos Oracle (32 bits). bit / 64 bits).
Desventajas
Si el enlace de red que conecta el primario y el modo de espera está suscrito en exceso, los registros de rehacer no se envían en orden cronológico, lo que puede provocar que aparezcan grandes espacios en el rehacer disponible en el modo de espera. Tal condición da como resultado que el modo de espera esté detrás del primario. Esto puede superarse utilizando la tecnología Active Data Guard Farsync de Oracle.
Se debe instalar la misma versión de Oracle Database Enterprise Edition en la base de datos principal y en todas las bases de datos en espera, excepto durante las actualizaciones continuas de la base de datos que utilizan bases de datos lógicas en espera.
Oracle Data Guard está disponible solo como una función de Oracle Database Enterprise Edition.