Opciones de recuperación tras desastres para cargas de trabajo de bases de datos de Oracle

En esta guía se describen las opciones de recuperación ante desastres disponibles para los usuarios que ejecutan cargas de trabajo de bases de datos de Oracle esenciales para su misión en un entorno de Solución Bare Metal.

En esta guía se presupone que estás usando Oracle Enterprise Edition. Algunas de las funciones descritas en esta guía se licencian por separado fuera de una licencia de Enterprise Edition. Estas son algunas de esas funciones:

• Oracle Real Application Clusters
• Oracle Active Data Guard
• Oracle Advanced Compression
• Oracle GoldenGate

Consulta tus contratos de licencia de Oracle para determinar qué funciones puedes usar al planificar la recuperación tras desastres y la alta disponibilidad.

RTO y RPO de la aplicación

La recuperación tras fallos de las tecnologías de bases de datos Oracle debe determinarse en función del objetivo de tiempo de recuperación (RTO) y del objetivo de punto de recuperación (RPO) de una aplicación. En general, el tiempo de recuperación describe el tiempo de inactividad aceptable de un sistema, mientras que el punto de recuperación describe la cantidad de pérdida de datos aceptable. El coste y la complejidad de un sistema aumentan a medida que disminuye cada uno de estos valores. Para obtener más información sobre el RTO y el RPO, consulta Aspectos básicos de la planificación de recuperación ante desastres.

Las arquitecturas etiquetadas como "RPO = 0" o "pérdida de datos cero" requieren que los datos se escriban en varias ubicaciones antes de considerarse "confirmados" en la base de datos. La latencia se convierte en un problema a medida que el RPO se acerca a cero.

Si no se tienen en cuenta correctamente durante la fase de diseño, la implementación de una arquitectura sin pérdida de datos puede tener efectos adversos en el rendimiento general de la aplicación.

Alta disponibilidad frente a recuperación tras desastres

La alta disponibilidad y la recuperación tras fallos son conceptos complementarios a la hora de diseñar arquitecturas de bases de datos fiables. En el contexto de esta guía, la alta disponibilidad se refiere a la capacidad de un sistema para recuperarse automáticamente de fallos individuales o en cascada en el sistema. Por otro lado, la recuperación tras fallos forma parte de un plan de continuidad de la actividad general y se aplica a fallos de mayor envergadura que pueden provocar que grupos enteros de sistemas no estén disponibles. La recuperación tras desastres abarca un ámbito más amplio debido al número de componentes integrados que deben recuperarse en caso de desastre.

La alta disponibilidad debe considerarse la "primera línea de defensa" al diseñar un sistema fiable. Una arquitectura de base de datos de alta disponibilidad debe poder resistir fallos individuales y seguir funcionando sin provocar tiempos de inactividad en la aplicación. Los componentes de alta disponibilidad de un sistema deben incluir, entre otros, los siguientes:

• Alimentación redundante en hardware de servidores, redes o almacenamiento
• Varias interfaces de red, conmutadores y cables
• Tejidos de almacenamiento, controladores y dispositivos de disco redundantes
• Interconexiones de partner tolerantes a fallos entre Google Cloud y la extensión de la región de Solución Bare Metal
• Oracle RAC para evitar que los fallos del servidor inhabiliten una base de datos

Un diseño de recuperación tras desastres debe incluir procesos para recuperarse de varios fallos en cascada que hagan que los componentes no estén disponibles. La planificación de la recuperación tras fallos debe tener en cuenta lo siguiente:

• Interrupciones regionales
• Desastres naturales
• Incidentes que provocan la interrupción total de uno o varios componentes de una aplicación

Herramientas de recuperación tras desastres y alta disponibilidad de Oracle

A continuación, se indican algunas herramientas de recuperación tras fallos y alta disponibilidad de Oracle:

• Oracle Real Application Clusters
• Oracle Recovery Manager
• Oracle Data Guard
• Base de datos Flashback
• Oracle GoldenGate

Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) se usa para escalar horizontalmente las cargas de trabajo de bases de datos de forma que puedan ser atendidas por varios servidores de bases de datos. Las bases de datos que usan RAC permiten una configuración activa/activa entre servidores de una extensión de región.

RAC se suele usar para proporcionar alta disponibilidad a los sistemas que necesitan protegerse frente a un fallo de un solo servidor. Debido al enfoque de "compartir todo" (almacenamiento y redes compartidos) para la creación de clústeres, debe haber un clúster RAC que se ejecute en un entorno de Solución Bare Metal dentro de un único pod de Solución Bare Metal. Esto convierte a RAC en una solución para los problemas de alta disponibilidad, pero no resuelve el requisito de recuperación tras desastres.

Para saber cómo configurar RAC en Solución Bare Metal, consulta el artículo Instalar Oracle RAC en Solución Bare Metal.

Oracle Recovery Manager

Oracle Recovery Manager (RMAN) es la herramienta principal para crear copias de seguridad y recuperar bases de datos de Oracle, ya que puede leer el formato de archivo de datos propietario de Oracle. Se puede usar para realizar clones de bases de datos, recuperaciones a un momento dado o incluso recuperaciones de una sola tabla en una base de datos Oracle.

RMAN es la única herramienta que se puede usar para crear copias de seguridad mientras la base de datos está abierta. También se usa para mantener el catálogo de archivos de copia de seguridad que se pueden usar para la recuperación.

Oracle Data Guard

Oracle Data Guard realiza la replicación de bases de datos en clústeres RAC remotos u otras instalaciones de bases de datos. Data Guard admite bases de datos en espera en una configuración física o lógica.

Las bases de datos de espera físicas son copias bloque a bloque que permiten que se abra una copia de la base de datos para escribir en ella. Todas las demás se montan (pero no se abren) para aplicar cambios o se abren en modo de solo lectura para admitir aplicaciones de informes.

Para saber cómo configurar Data Guard en Solución Bare Metal, consulta el artículo Implementar Oracle Data Guard en Solución Bare Metal.

FLASHBACK DATABASE

La función FLASHBACK DATABASE de Oracle Enterprise Edition permite a los administradores restaurar rápidamente una base de datos a un momento específico sin tener que realizar restauraciones de bases de datos que requieren mucho tiempo.

En el contexto de la recuperación tras desastres, FLASHBACK DATABASE se suele usar junto con Data Guard durante las operaciones de conmutación por error para restaurar las bases de datos más rápido. La base de datos con errores se restaura a un momento específico que coincide con los registros de la nueva principal y se envía la rehacer para que pueda resincronizarse por completo.

Oracle GoldenGate

Oracle GoldenGate es una herramienta de replicación lógica que se usa habitualmente para habilitar implementaciones multisitio activas o para mover datos entre plataformas de hardware. Cuando se usa GoldenGate, un proceso extract en la base de datos de origen captura los cambios en los registros para rehacer online y los escribe en archivos de registro de seguimiento, que se transportan a la base de datos de destino. Un proceso replicat en la base de datos de destino convierte las transacciones de los archivos de cola en SQL y ejecuta el SQL en la base de datos de destino.

Esta arquitectura convierte a GoldenGate en una potente herramienta para mover datos entre plataformas de bases de datos o transformar datos a medida que se replican. A diferencia de Data Guard, GoldenGate requiere que se instale y mantenga un software independiente en los sistemas de origen y de destino. GoldenGate no se puede usar para la replicación síncrona porque las transacciones se traducen y se aplican como SQL en la base de datos de destino. Aunque GoldenGate puede proporcionar un retraso mínimo para la replicación, por sí solo no puede garantizar un RPO de cero.

Modelos de implementación de recuperación tras desastres (solo bases de datos)

Oracle ha creado el marco de Maximum Availability Architecture (MAA) para ofrecerte modelos de recuperación tras desastres recomendados para desplegar tus aplicaciones y bases de datos.

Cada uno de los siguientes modelos proporciona objetivos de RTO y RPO específicos:

• Modelo Copper
• Modelo Bronze
• Modelo Silver
• Modelo Gold
• Modelo Platino

Los modelos se asignan a patrones de implementación específicos que cumplen los objetivos de punto de recuperación (RPO) y de tiempo de recuperación (RTO) en caso de interrupciones planificadas y no planificadas. Cada carga de trabajo de la base de datos debe evaluarse en función de sus requisitos de disponibilidad y diseñarse con un modelo correspondiente. Es habitual que las bases de datos de desarrollo usen un modelo con un nivel de protección inferior al de sus equivalentes de producción y control de calidad.

El modelo Bronze está pensado para bases de datos que no necesitan un RTO medido en minutos. Los modelos Silver y de nivel superior incluyen bases de datos de reserva que se ejecutan en un sitio remoto. Cada modelo incorpora la funcionalidad de los modelos de nivel inferior. Por ejemplo, el modelo Bronze usa conceptos de copia de seguridad y recuperación que se deben seguir aunque se haya implementado una base de datos de reserva.

Modelo de Copper

El modelo Copper proporciona una implementación mínima para crear copias de seguridad de bases de datos en medios de almacenamiento local y copiarla en un almacenamiento que se encuentre fuera de la extensión de la región. Esta implementación requiere un enfoque de dos fases, pero se puede crear un script para usar el SDK de Google Cloud y automatizar la transmisión de copias de seguridad.

Si usas este tipo de implementación, también aumenta el tiempo de recuperación debido a la recuperación en dos fases que se requiere. RMAN no puede acceder directamente a las copias de seguridad, por lo que deben trasladarse a una ubicación disponible para RMAN antes de que pueda empezar la recuperación.

interrupción | interrupción del servicio (depending on context)	Tipo de interrupción	RPO	RTO
No planeadas	Fallo recuperable de un nodo o una instancia	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupciones	Última copia de seguridad completa, incremental o de registro de archivo que se transfirió fuera del RE	Horas, en función del tamaño de la base de datos y del ancho de banda asignado a Partner Interconnect
	Desastres: errores de extensión de regiones	Última copia de seguridad de registro de archivo, incremental o completa que se transfirió fuera del RE	Días o semanas, en función del tiempo necesario para volver a poner en línea la extensión de la región
Planeada	Parches de bases de datos y actualizaciones del SO o del firmware	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización importante de la base de datos	0	Entre 1 y 2 horas

Modelo de bronce

El modelo Bronze ofrece dos opciones de implementación. Ambos usan el almacenamiento nativo deGoogle Cloudpara conservar las copias de seguridad de las bases de datos.

Implementación de nivel Bronze 1: copia de seguridad en almacenamiento regional

En esta implementación, las copias de seguridad se escriben directamente en medios externos. En la mayoría de los casos, el destino de copia de seguridad preferido es Cloud Storage con Cloud Storage FUSE, que presenta un segmento de Cloud Storage como un sistema de archivos.

Las recomendaciones para usar Cloud Storage FUSE se pueden encontrar en el artículo sobre copias de seguridad de Oracle con NFS y Cloud Storage. Google Cloud También se puede usar Filestore, que presenta recursos compartidos de NFS a las instancias de Solución Bare Metal.

En el siguiente diagrama se muestra un ejemplo de implementación.

interrupción | interrupción del servicio (depending on context)	Tipo de interrupción	RPO	RTO
No planeadas	Fallo recuperable de un nodo o una instancia	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupciones	Última copia de seguridad de registro de archivo, incremental o completa	Horas, en función del tamaño de la base de datos y del ancho de banda asignado a Partner Interconnect
	Desastres: errores de extensión de regiones	Última copia de seguridad de registro de archivo, incremental o completa	Días o semanas, en función del tiempo necesario para volver a poner en línea la extensión de la región
Planeada	Parches de bases de datos y actualizaciones del SO o del firmware	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización importante de la base de datos	0	Entre 1 y 2 horas

Implementación de nivel Bronze 2: copia de seguridad con Backup y DR

En esta implementación, el servicio de copia de seguridad y recuperación tras fallos se usa para almacenar copias de seguridad enGoogle Cloud. Backup and DR ofrece un enfoque de copia de seguridad incremental para siempre, que se almacena en medios de alto rendimiento respaldados por Cloud Storage para la conservación a largo plazo.

Backup and DR también ofrece un RTO más rápido que el almacenamiento de copias de seguridad en Filestore o Cloud Storage, ya que puede poner inmediatamente a disposición de la instancia de Oracle imágenes de los archivos de la base de datos. La función de montaje y migración permite poner en línea una base de datos rápidamente mientras se copia en el medio de almacenamiento de producción, lo que reduce drásticamente el RTO.

En el siguiente diagrama se muestra un ejemplo de implementación.

interrupción | interrupción del servicio (depending on context)	Tipo de interrupción	RPO	RTO
No planeadas	Fallo recuperable de un nodo o una instancia	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupciones	Última copia de seguridad de registro de archivo, incremental o completa	De minutos a horas, en función de los requisitos de rendimiento, el tamaño de la base de datos y el ancho de banda asignado a la interconexión de partner
	Desastres: errores de extensión de regiones	Última copia de seguridad de registro de archivo, incremental o completa	Días o semanas, en función del tiempo necesario para volver a poner en línea la extensión de la región o de la capacidad del cliente para cambiar a otra extensión de la región.
Planeada	Parches de bases de datos y actualizaciones del SO o del firmware	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización importante de la base de datos	0	Entre 1 y 2 horas

Plata

El modelo Silver introduce la replicación de bases de datos mediante Oracle Data Guard. Data Guard proporciona replicación de bases de datos en tiempo real con una o varias bases de datos que actúan como bases de datos de reserva. Como Data Guard se basa en el transporte y la aplicación de los cambios de la base de datos a medida que se producen, el RPO puede ser casi nulo. El modelo Silver se basa en la replicación asíncrona. Si se usa la replicación síncrona, no se pierden datos, pero el tiempo necesario para enviar datos entre regiones suele superar los límites aceptables del tiempo de respuesta de las aplicaciones.

La función de conmutación por error de inicio rápido de Data Guard puede realizar operaciones de conmutación por error automáticas si una base de datos principal deja de estar disponible durante un periodo definido por el usuario. La configuración la monitoriza un proceso observador de Data Guard, que puede ejecutarse.

El modelo Silver tiene la ventaja de asegurar que la base de datos esté disponible en caso de que se produzca un fallo regional total, pero las operaciones de conmutación por error y de cambio pueden afectar al rendimiento de la aplicación, ya que aumenta la latencia de la red entre los servidores de la aplicación y la base de datos. No se recomienda ejecutar aplicaciones y bases de datos de asistencia en regiones diferentes. Aunque el tiempo de recuperación ante desastres de la base de datos puede ser inferior a 1 minuto, en los casos de conmutación por error de la aplicación, los servicios pueden tardar entre minutos y horas en funcionar por completo. En la mayoría de los casos, la ejecución de planes de conmutación por error de recuperación tras desastres entre regiones suele implicar procesos manuales debido al número de componentes que se mueven.

En el modelo Silver, es posible que sigas teniendo periodos de inactividad o ventanas de mantenimiento durante las actividades de aplicación de parches trimestrales. La introducción de Oracle RAC puede reducir el tiempo de inactividad para aplicar parches o en caso de fallos del servidor.

En el siguiente diagrama se muestra un ejemplo de configuración.

La configuración de ejemplo del diagrama muestra bases de datos RAC que se ejecutan en las regiones us-west2 y us-east4. La replicación se configura mediante Data Guard asíncrono. Todo el tráfico entre Bare Metal Solution y Google Cloud transita por una interconexión de partner, y el tráfico entre regiones se desplaza por la red troncal de Google. Los servidores de aplicaciones se configuran en cada región, pero suelen cerrarse en la región de recuperación ante desastres hasta que se declara un evento de conmutación por error.

interrupción | interrupción del servicio (depending on context)	Tipo de interrupción	RPO	RTO
No planeadas	Fallo recuperable de un nodo o una instancia	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupciones	< 60 s	De minutos a horas, en función de la conmutación por error de la aplicación.
	Desastres: errores de extensión de regiones	< 60 s	De minutos a horas, en función de la conmutación por error de la aplicación.
Planeada	Parches de bases de datos y actualizaciones del SO o del firmware	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	Entre 1 y 2 horas Minutos si usas DBMS_ROLLING para realizar la actualización.

Modelo Gold

Si te preocupa la pérdida de datos en el modelo Silver, puedes elegir el modelo Gold, que usa una instancia de sincronización lejana para proporcionar replicación síncrona a una instancia que se ejecuta en Google CloudCompute Engine.

Una instancia de sincronización lejana incluye un archivo de control de base de datos y un conjunto de registros redo de espera que se ejecutan geográficamente cerca de la base de datos principal. Esta instancia está configurada para recibir rehacer de forma síncrona con baja latencia, lo que permite que todos los cambios se registren fuera de la extensión de la región de la base de datos principal. La instancia de sincronización lejana reenvía la rehacer a la base de datos de espera de la región remota para aplicarla de forma asíncrona.

Una instancia de sincronización lejana no es una copia completa de la base de datos y, por lo tanto, no puede atender el tráfico de aplicaciones. La instancia de sincronización lejana se usa para proporcionar una ubicación tolerante a fallos en la que se escriben los cambios de la base de datos de forma síncrona, lo que permite una solución sin pérdida de datos. Cuando se realiza una replicación síncrona en la instancia de sincronización lejana, las transacciones no se confirman en la base de datos principal hasta que los cambios se hayan recibido y confirmado en la instancia de sincronización lejana.

Las instancias de Compute Engine suelen seleccionarse como candidatas para alojar una instancia de sincronización lejana. Si colocas la instancia de sincronización lejana en una zona de Compute Engine cerca de la base de datos principal, se añade una latencia mínima (normalmente, menos de 1,5 ms) y se protege frente a los fallos en la extensión de la región.

En el siguiente diagrama se muestra un ejemplo de implementación.

La configuración de ejemplo del diagrama muestra una base de datos RAC principal que se ejecuta en us-west2 con aplicaciones que se ejecutan en Compute Engine. Una instancia de Compute Engine de us-west2 está ejecutando una instancia de sincronización lejana y recibiendo rehacer síncrono. La instancia de sincronización lejana está configurada para enviar rehacer de forma asíncrona a una base de datos RAC que se ejecuta en la región us-east4. Las instancias de la aplicación se configuran en la región us-east4 de Compute Engine para gestionar el tráfico de la aplicación en caso de desastre.

interrupción | interrupción del servicio (depending on context)	Tipo de interrupción	RPO	RTO
No planeadas	Fallo recuperable de un nodo o una instancia	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupciones	0	De minutos a horas, en función de la conmutación por error regional de la aplicación.
	Desastres: errores de extensión de regiones	0	De minutos a horas, en función de la conmutación por error regional de la aplicación.
Planeada	Parches de bases de datos y actualizaciones del SO o del firmware	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	Entre 1 y 2 horas Minutos si usas DBMS_ROLLING para realizar la actualización.

Modelo Platino

El modelo Platinum ofrece dos opciones de implementación. Cada opción de implementación proporciona protección mediante una tecnología diferente y tiene características de RTO y RPO distintas.

Despliegue Platinum 1: Data Guard con conmutación por error de inicio rápido

La implementación de Platino 1 se basa en la implementación del modelo Oro y añade una segunda base de datos de espera de Data Guard en la región local que se ejecuta en una instancia de Compute Engine. Esta configuración usa la réplica síncrona entre la base de datos principal y la de reserva que se ejecuta en Compute Engine, lo que garantiza que no se pierdan datos en la región principal.

Si creas una base de datos de espera en la misma región, las operaciones de conmutación por error y de cambio de base de datos se pueden llevar a cabo sin que afecten a las aplicaciones. Durante los cambios de rol de la base de datos, las aplicaciones configuradas de acuerdo con las consideraciones de los clientes de Oracle se vuelven a conectar automáticamente a la nueva base de datos principal sin necesidad de intervención manual. Las aplicaciones configuradas correctamente experimentan menos de 2 minutos de inactividad durante una conmutación por error.

Aunque la base de datos de reserva de Compute Engine no ejecuta RAC, debe tener el tamaño adecuado para admitir el tráfico normal de la aplicación cuando se ejecute como base de datos principal. Esta instancia puede ejecutarse con un perfil más pequeño mientras funciona como instancia de reserva y aumentar su tamaño durante los eventos de conmutación por error, o bien ejecutarse a plena capacidad en todo momento. Cambiar el tamaño de la instancia durante una conmutación por error afecta negativamente al tiempo de recuperación, ya que la instancia debe reiniciarse durante la operación de cambio de tamaño.

La conmutación por error de inicio rápido se configura en una instancia de Compute Engine que ejecuta el broker de Data Guard con un observador. El observador ejecuta un cliente de Oracle básico con conexiones a todas las bases de datos principales y de espera. Si el observador detecta un error en la base de datos principal, inicia una conmutación por error a una de las bases de datos de reserva. La base de datos de reserva que se ejecuta en Compute Engine debe configurarse como el destino de conmutación por error preferido cuando se usa la implementación de nivel Gold.

Oracle recomienda que el observador se coloque en una región independiente de las bases de datos principal y de espera. De esta forma, se ofrece la mejor protección frente a fallos regionales y eventos de partición de red. Si no es posible usar una tercera región, el observador debe instalarse en la región principal y ejecutarse en una zona diferente de la de la réplica de espera cercana.

En el siguiente diagrama se muestra un ejemplo de implementación.

La implementación de ejemplo que se muestra en el diagrama consta de lo siguiente:

• Una base de datos principal que ejecuta RAC en un servidor de Bare Metal Solution en la región us-west2.
• Una base de datos de espera casi in situ que se ejecuta en una instancia de Compute Engine en la región us-west2.
• Una base de datos de espera remota que se ejecuta en un servidor de Bare Metal Solution en la región us-east4.
• El observador de Data Guard que se ejecuta en la instancia de Compute Engine de la región us-central1.

La replicación síncrona se configura para la base de datos de espera de la región que se ejecuta en la instancia de Compute Engine, y la replicación asíncrona se configura para la región remota. En cada caso, la rehacer se envía de la base de datos principal a la secundaria. La rehacer no se reenvía de una base de datos secundaria a otra. El observador se configura en una tercera región y mantiene la conectividad con todas las bases de datos de la configuración. Las instancias de aplicación se configuran en la región principal y se conectan a la base de datos principal del servidor de Bare Metal Solution (o a la base de datos de la instancia de Compute Engine durante las operaciones de conmutación por error y de cambio). Las instancias de la aplicación se configuran en la región us-east4 de Compute Engine para gestionar el tráfico de la aplicación en caso de desastre.

interrupción | interrupción del servicio (depending on context)	Tipo de interrupción	RPO	RTO
No planeadas	Fallo recuperable de un nodo o una instancia	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupciones	0	< 60 s
	Desastres: errores de extensión de regiones	0	< 60 s
Planeada	Parches de bases de datos y actualizaciones del SO o del firmware	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	Entre 1 y 2 horas Minutos si usas DBMS_ROLLING para realizar la actualización.

Implementación de Platino 2: GoldenGate para la replicación

La implementación de Platino 2 se basa en el uso de Oracle GoldenGate para la replicación. Como GoldenGate no replica a nivel de bloque. Permite que cada base de datos lea y escriba sesiones de aplicaciones de forma independiente. Replica los cambios de forma bidireccional, lo que permite una configuración de base de datos activa/activa.

Las aplicaciones deben validarse a fondo antes de comprometerse con una implementación activa/activa, y debes tener en cuenta la detección y resolución de conflictos.

A diferencia de Data Guard, GoldenGate requiere la instalación y el mantenimiento de software adicional en los servidores de bases de datos de Oracle. Las implementaciones activo-activo suelen requerir un diseño sofisticado de esquemas y aplicaciones para aprovechar las ventajas de una implementación de base de datos en varios sitios. Muchas aplicaciones preempaquetadas no admiten este tipo de arquitectura.

Las implementaciones que dependen de GoldenGate para toda la replicación no pueden admitir un RPO de cero pérdida de datos debido a la naturaleza asíncrona de la replicación lógica. Las bases de datos de espera locales que se ejecutan en Compute Engine con Data Guard se pueden implementar para proporcionar un RPO de cero con replicación síncrona.

En el siguiente diagrama se muestra un ejemplo de implementación.

interrupción | interrupción del servicio (depending on context)	Tipo de interrupción	RPO	RTO
No planeadas	Fallo recuperable de un nodo o una instancia	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupciones	Segundos a minutos 0 si se usa Data Guard en cada ubicación	0
	Desastres: errores de extensión de regiones	Segundos a minutos 0 si se usa Data Guard en cada ubicación	0
Planeada	Parches de bases de datos y actualizaciones del SO o del firmware	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	0