Entender Oracle Data Guard

En este artículo, escribiré sobre la solución de recuperación de desastres de Oracle (recuperación de desastres). Voy a dar la terminología básica en una breve información sobre el Data Guard. Como gestores de datos, estamos obligados a tomar las medidas necesarias antes de que ocurran estos desastres. También hay que considerar tomar las acciones necesarias que son muy importantes. Estos son;

• RPO (Recovery Point Objective) - ¿Cuántos datos puede permitirse perder?
• RTO (Recovery Time Objective) - Sin acceso a los datos, ¿Cuanto tiempo puedes soportar?

De acuerdo con las respuestas de estas preguntas debemos establecer el sistema de copia de seguridad. No estamos satisfechos con la instalación de nuestro sistema, y ​​debemos monitorear nuestro sistema.

Ahora, veamos la solución que Oracle propone:  Oracle Data Guard.

Oracle Data Guard es la solución de recuperación de desastres. Protege nuestra base de datos de producción de los desastres, reduciendo la carga de trabajo sobre ella y su uso más efectivo. Technology, introducida por primera vez mediante el establecimiento de la base de datos de reserva manualmente con Oracle 7. Apareció como un Data Guard con Oracle 8i. 

Evolución histórica de Oracle Data Guard

Si examinamos las características de un Data Guard desde el pasado hasta el presente;

• ORACLE 8i
• Base de datos en espera de sólo lectura
• Recuperación gestionada
• Archivo de registro de rehacer archivos remotos

• ORACLE 9i
• Integración "Pérdida de datos cero"
• Data Guard Broker y Data Guard Manager GUI
• Operaciones de Switcover y Failover
• Sincrónico automático
• Base de datos de espera lógica
• Protección máxima

• ORACLE 10g
• Aplicación en tiempo real
• Soporte forzado para Oracle RAC
• Failover de arranque rápido
• Transferencia asíncrona de rehacer
• Base de datos Flashback

• ORACLE 11g
• Base de datos de espera activa (Active Data Guard)
• Instantánea de la instantánea
• Soporte de plataforma heterogénea (Producción -Linux, Standby - Windows)

• ORACLE 12C
• Funciones comunes a Redo Apply y SQL Apply
• Funciones especificas a Redo Apply
• Funciones especificas a  SQL Apply

FLUJO DE DATOS: PHYSICAL STANDBY

Vamos a entender cómo los datos fluyen en la configuración de Oracle Data Guard mostrada arriba en ocho puntos:

• En la base de datos principal, se inician las transacciones. Todos los bloqueos de caché del búfer (bloqueos exclusivos) que se requieren para la transacción se obtienen.
• En la base de datos principal, los bloques de rehacer que describen los cambios (o los vectores de cambio) se generan y almacenan en el Área Global del Programa (PGA) de los procesos. Después de adquirir con éxito el bloqueo de rehacer asignación, el espacio se asigna en el búfer de registro de rehacer. El redo generado se copia de PGA de los procesos en el búfer de registro de rehacer.
• En la base de datos primaria, el proceso de primer plano de oracle le indica a LGWR que limpie los búferes de registro de rehacer en el disco. Recuerde que los bloques de base de datos de la base de datos aún no se han actualizado con los cambios DML. El LGWR descarga los buffers de redo al ORL y reconoce la finalización de la sesión. En este punto, la transacción es persistente en el disco. No se ha cometido hasta el momento.

En algún momento futuro, los buffers de base de datos que fueron cambiados previamente serán escritos en disco por el proceso de escritura de base de datos (DBWR) en el momento del punto de control. Este punto no está marcado en el diagrama anterior.

Tenga en cuenta que antes de que el proceso DBWR haya descargado los búferes de la base de datos a los discos, el proceso LGWR debe haber escrito ya los búferes de rehacer en el disco. Esta secuencia explícita es reforzada por el protocolo de registro anticipado.

También el proceso ARCH en la base de datos primaria archiva los ORL en archivos de registro de archivos. Este punto tampoco está marcado en el diagrama anterior.

• En la base de datos primaria, el proceso LNS lee el redo recientemente descargado del búfer de registro de redo y envía los datos de rehacer a la base de datos en espera utilizando el destino de transporte redo (LOG_ARCHIVE_DEST_n) que definimos durante la creación de la base de datos en espera. Estamos utilizando el método de transporte ASYNC, por lo que el LGWR no espera ningún reconocimiento de la LNS para esta operación de envío de red. No se comunica con el LNS excepto para iniciarlo en la etapa de inicio de la base de datos y después de un fallo de una conexión en espera.

• En la base de datos de espera, el RFS lee el flujo de rehacer desde el socket de red en los búferes de red y, a continuación, escribe este flujo de rehacer a la SRL.

• En la base de datos de espera, el proceso ARCH archiva las SRL en archivos de registro de archivo cuando se produce un cambio de registro en la base de datos primaria. El archivo de registro de archivo generado se registra con el archivo de control de espera.

• En la base de datos de espera, el proceso de recuperación real comienza en este paso. El proceso de recuperación administrado (MRP) leerá de forma asincrónica el rehacer de los SRL o de los registros de rehacer archivados (cuando la recuperación se reduce o no se aplica en tiempo real). Los bloques que requieren redo apply se analizan y se colocan en segmentos de mapa en memoria apropiados.

• En la base de datos en espera, el proceso MRP envía rehacer a los esclavos de recuperación utilizando el marco de comunicación entre procesos de consulta en paralelo (PQ). Medios paralelos

Recuperación (PMR) hace que los bloques de datos requeridos sean leídos en la caché del búfer, y posteriormente redo se aplicará a estos búferes del búfer del búfer.

PROCESOS RELACIONADOS CON BASE DE DATOS EN ESPERA FÍSICA

En la base de datos primaria:

• LGWR: El proceso de escritura de registros vacía los buffers de registro de los archivos SGA a Online Redo Log.
• LNS: El servicio de red de LogWriter (LNS) lee el redo que es descargado de los almacenadores intermediarios del redo por el LGWR y envía el redo sobre red a la base de datos espera. El propósito principal del proceso LNS es liberar el proceso LGWR de realizar el rol redo transport. 
• ARCH: El archivador procesa los archivos de ORL para archivar los archivos de registro. Pueden existir hasta 30 procesos ARCH, y estos procesos ARCH también se utilizan para satisfacer solicitudes de resolución de huecos. Tenga en cuenta que un proceso ARCH tiene un papel especial en que está dedicado al archivo de registro de redo local solo y nunca se comunica con una base de datos en espera.

En la base de datos de reserva:

• RFS: El objetivo principal del proceso de servidor de archivos remotos es realizar una red de recepción de redo transmitida desde el sitio principal y, a continuación, escribe el búfer de red (rehacer datos) a los archivos de redo registro (SRL) en espera.
• ARCH: Los procesos de archivo en el sitio en espera realizan las mismas funciones realizadas en el sitio principal, excepto que en el sitio en espera, un proceso ARCH genera archivos de registro archivados de las SRL.
• MRP: el proceso de recuperación administrado coordina la administración de recuperación de medios. Recuerde que un modo de espera físico está en modo de recuperación perpetua.

Básicamente, podemos categorizar la base de datos de espera física en tres componentes principales:

Data Guard Redo Servicios de Transporte

Para transferir el redo generado por la base de datos primaria a la base de datos en espera.

Data Guard Aplicar Servicios

Para recibir y aplicar el redo enviado por Redo Transport Services a la base de datos en espera.

Data Guard servicios de gestión de roles

Para ayudar en los cambios de rol de la base de datos en los escenarios de conmutación y conmutación por error- Este servicio funciona en segundo plano y se ocupa de los escenarios de conmutación / conmutación por error