Opciones de recuperación ante 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. ejecutar cargas de trabajo de bases de datos de Oracle esenciales en una solución Bare Metal en un entorno de nube.

En esta guía, se supone que ejecutas Oracle Enterprise Edition. Algunas de las funciones que se describen en esta guía tienen licencias independientes fuera de una licencia de la edición empresarial. Entre algunas de estas funciones, se incluyen las siguientes:

• Oracle Real Application Clusters
• Protección de datos activa de Oracle
• Compresión avanzada de Oracle
• Oracle GoldenGate

Consulta los contratos de licencia de Oracle para determinar qué características eres para la recuperación ante desastres y la alta disponibilidad.

RTO y RPO de la aplicación

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

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

A menos que se tenga en cuenta de forma adecuada durante la fase de diseño, la implementación de una arquitectura de pérdida de datos cero puede tener efectos adversos en el rendimiento general de la aplicación.

Alta disponibilidad en comparación con la recuperación ante desastres

La alta disponibilidad y la recuperación ante desastres son conceptos complementarios cuando se diseñan arquitecturas de bases de datos confiables. En el contexto de esta guía, la alta disponibilidad se refiere a la capacidad de un sistema para recuperarse automáticamente de fallas individuales o en cascada. Por otro lado, los desastres recuperación es parte de un plan general de continuidad empresarial y se aplica a que pueden hacer que grupos enteros de sistemas no estén disponibles. La recuperación ante desastres abarca un alcance más amplio debido a la cantidad de componentes integrados que se deben recuperar en caso de un desastre.

La alta disponibilidad debe considerarse como la "primera línea de defensa" para diseñar un sistema confiable. Una arquitectura de base de datos con alta disponibilidad debe poder sostener las fallas individuales y seguir funcionando sin causar tiempo de inactividad la aplicación. Los componentes de alta disponibilidad de un sistema deben incluir no se limitan a lo siguiente:

• Alimentación redundante en el hardware del servidor, la red o el almacenamiento
• Varias interfaces de red, interruptores y cables
• Tejidos de almacenamiento, controladores y dispositivos de disco redundantes
• Interconexiones de socios tolerantes a fallas entre Google Cloud y la extensión de región de la solución Bare Metal
• Oracle RAC para evitar que las fallas del servidor inhabiliten una base de datos

Un diseño de recuperación ante desastres debe incluir procesos para recuperarse de múltiples fallas en cascada que hacen que los componentes no estén disponibles. La planificación de la recuperación ante desastres debe tener en cuenta lo siguiente:

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

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

A continuación, se muestran algunas herramientas de recuperación ante desastres y alta disponibilidad de Oracle:

• Clústeres de aplicación reales de Oracle
• Oracle Recovery Manager
• Oracle Data Guard
• Base de datos flashback
• Oracle GoldenGate

Oracle Real Application Clusters

Los clústeres de aplicación real (RAC) de Oracle se utilizan para escalar de forma horizontal la base de datos de cargas de trabajo de varios servidores de bases de datos sean atendidas. Bases de datos que usan RAC permiten una configuración activa/activa entre servidores dentro de una región .

Por lo general, los RAC se usan para proporcionar alta disponibilidad a los sistemas necesitas protegerte contra una sola falla del servidor. Debido a la "compartió todo" (almacenamiento compartido y redes compartidas) para el agrupamiento en clústeres, debe existir un clúster de RAC que se ejecute en un entorno de la solución Bare Metal dentro único Pod de la solución Bare Metal. Esto convierte a RAC en una solución para la alta disponibilidad. pero no resuelve el requisito de recuperación ante desastres.

Si quieres obtener información para configurar RAC para la solución Bare Metal, consulta Instala RAC de Oracle en la solución Bare Metal.

Administrador de recuperación de Oracle

El administrador de recuperación de Oracle (RMAN) es la herramienta principal para crear copias de seguridad y recuperar bases de datos de Oracle debido a su capacidad para leer el formato de archivo de datos propietario de Oracle. Se puede usar para realizar clonaciones de bases de datos, recuperación de un momento determinado o incluso la recuperación de una sola tabla dentro de una base de datos de Oracle.

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

Oracle Data Guard

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

Las bases de datos de reserva físicas son copias de bloque por bloque que permiten que una copia de la base de datos esté abierta para la escritura. Todas las demás se activan (pero no se abren) para aplicar cambios o se abren de solo lectura para admitir aplicaciones de informes.

Para obtener información sobre cómo configurar Data Guard en la solución Bare Metal, consulta Implementa Oracle Data Guard en la solución Bare Metal.

FLASHBACK DATABASE

La función FLASHBACK DATABASE de Oracle Enterprise Edition permite a los administradores rebobinar rápidamente una base de datos a un punto específico en el tiempo sin necesidad de realizar restauraciones de bases de datos que consumen mucho tiempo.

En el contexto de la recuperación ante desastres, FLASHBACK DATABASE se usa con frecuencia en en conjunto con Data Guard durante las operaciones de conmutación por error para una base de datos más rápida el restablecimiento del proyecto. La base de datos con errores se vuelve a escribir en la memoria flash de un momento específico. que es coherente con los registros en la nueva instancia principal, y la rehacer se envía puedan volver a sincronizarse por completo.

Oracle GoldenGate

Oracle GoldenGate es una herramienta de replicación lógica que se usa comúnmente para habilitar implementaciones activas/activas de varios sitios o 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 de rehacer en línea y los escribe en los cambios de los archivos de registro, que se transportan a la base de datos de destino. Un proceso replicat en la de destino convierte las transacciones de los archivos de cola en SQL y ejecuta la SQL en la base de datos de destino.

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

Modelos de implementación de recuperación ante desastres (solo base de datos)

Oracle creó el framework de arquitectura de máxima disponibilidad (MAA) para brindarte los modelos de recuperación ante desastres recomendados para implementar tus aplicaciones y bases de datos.

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

• Modelo de cobre
• Modelo de bronce
• Modelo plateado
• Modelo Oro
• Modelo Platino

Los modelos se asignan a patrones de implementación específicos que cumplen con los RPO y RTO. ante 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 común que las bases de datos de desarrollo usen un modelo con un nivel de protección más bajo que sus contrapartes de producción y QA.

El modelo Bronce está diseñado para bases de datos que no necesitan un RTO medido en minutos. Los modelos Silver y de nivel superior incluyen bases de datos en espera que se ejecutan en un sitio remoto. Cada modelo incorpora la funcionalidad del modelo de e implementar modelos automáticamente. Por ejemplo, el modelo Bronce usa conceptos de copia de seguridad y recuperación que se deben seguir incluso si se implementa una base de datos de resguardo.

Modelo de cobre

El modelo Copper ofrece una implementación mínima para crear copias de seguridad de las bases de datos en el almacenamiento local en el contenido multimedia y copiarlo al almacenamiento que esté fuera de la extensión. Esta implementación requiere un enfoque de dos etapas, pero se puede crear una secuencia de comandos para usar el SDK de Google Cloud y automatizar la transmisión de copias de seguridad.

Usar esta implementación también aumenta el RTO debido a la recuperación en dos etapas como en los productos necesarios. El RMAN no puede acceder directamente a las copias de seguridad, por lo que deben moverse a un disponible para el RMAN antes de que comience la recuperación.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificada	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupción	La última copia de seguridad incremental, completa o de registro de archivo que se transfirió fuera del RE	Horas, según el tamaño de la base de datos y el ancho de banda asignado a la interconexión de socios
	Desastres: Fallas en la extensión de la región	La última copia de seguridad completa, incremental o de archivo que se transfirió fuera del RE	Días o semanas, según el tiempo necesario para que la extensión de la región vuelva a estar en línea
Planificada	Parches de la base de datos y actualizaciones del SO o el firmware	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización importante de la base de datos	0	De 1 a 2 horas

Modelo Bronce

El modelo Bronce ofrece dos opciones de implementación. Ambas usan Almacenamiento nativo de Google Cloud para retener copias de seguridad de bases de datos.

Implementación de Bronce 1: Copia de seguridad en el 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 bucket de Cloud Storage como un sistema de archivos.

Las recomendaciones para usar Cloud Storage FUSE se pueden encontrar en Copias de seguridad de Oracle con NFS y Cloud Storage. Google Cloud Filestore, que presenta recursos compartidos de NFS a las instancias de la solución Bare Metal, también se puede usar.

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

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificada	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia
	Desastres: Corrupciones	Última copia de seguridad completa, incremental o de registro de archivo	Horas, según el tamaño de la base de datos y el ancho de banda asignado a Interconexión de socio
	Desastres: Fallas de extensión de región	Último registro de archivo, incremental o copia de seguridad completa	Días o semanas, según el tiempo necesario para que la extensión de región vuelva a estar en línea
Planificada	Parches de bases de datos, actualizaciones de SO/FW	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización importante de la base de datos	0	De 1 a 2 horas

Implementación de bronce 2: Crea una copia de seguridad con Backup and DR

En esta implementación, se usa el servicio de copia de seguridad y DR para almacenar copias de seguridad en Google Cloud. El servicio de copia de seguridad y DR ofrece a las copias de seguridad, que se almacenan en medios de alto rendimiento respaldados por Cloud Storage para una retención a largo plazo

La copia de seguridad y la DR también ofrecen un RTO más rápido que el almacenamiento de copias de seguridad en Filestore o Cloud Storage, ya que pueden poner de inmediato las imágenes de los archivos de base de datos a disposición de la instancia de Oracle. La función de activación y migración pone una base de datos en línea rápidamente mientras se vuelve a copiar en el medio de almacenamiento de producción, lo que reduce drásticamente el RTO.

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

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificada	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: Corrupciones	Última copia de seguridad completa, incremental o de registro de archivo	De minutos a horas, según los requisitos de rendimiento, el tamaño de la base de datos y el ancho de banda asignado a la interconexión de socios
	Desastres: Fallas de extensión de región	Última copia de seguridad completa, incremental o de registro de archivo	Días o semanas, según el tiempo necesario para que la extensión de región vuelva a estar en línea o la capacidad del cliente para cambiarse a otra extensión de región
Planificada	Parches de la base de datos y actualizaciones del SO o el firmware	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización importante de la base de datos	0	De 1 a 2 horas

Plateado

El modelo Plata presenta la replicación de bases de datos con Oracle Data Guard. Data Guard proporciona replicación de bases de datos en tiempo real con una o más bases de datos que actúan como bases de datos en espera. Dado que Data Guard se basa en el transporte y la aplicación de cambios en la base de datos a medida que ocurren, el RPO puede ser cercano a cero. La Plata modelo se basa en la replicación asíncrona; con la replicación síncrona garantiza cero pérdida de datos, pero el tiempo necesario para enviar datos entre regiones, por lo general, aumenta el tiempo de respuesta de la aplicación más allá de los límites aceptables.

La función de inicio rápido de conmutación por error de Data Guard realiza acciones de conmutación por error si una base de datos principal deja de estar disponible para una y el período definido por el usuario. La configuración está supervisada por un proceso de observador de Data Guard, que puede ejecutarse.

El modelo de plata tiene el beneficio de garantizar que la base de datos esté disponible en el caso de una falla regional total, pero las operaciones de conmutación por error y de cambio podrían afectar el rendimiento de la aplicación a medida que aumenta la latencia de red entre los servidores de la aplicación y la base de datos. Raramente se recomienda ejecutar aplicaciones y bases de datos de respaldo en diferentes regiones. Si bien el RTO de la base de datos puede ser inferior a 1 minuto, los casos de conmutación por error de la aplicación pueden tardar entre minutos y horas en que los servicios estén completamente operativos. En la mayoría de los casos, ejecutar planes de conmutación por error de recuperación ante desastres entre regiones suele implicar procesos manuales debido a la cantidad de componentes que se mueven.

En el modelo Plata, es posible que aún se produzcan tiempos de inactividad o períodos de mantenimiento durante las actividades de parches trimestrales. La introducción de Oracle RAC puede reducir el tiempo de inactividad en caso de que se apliquen parches o fallas del servidor.

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

En la configuración de ejemplo del diagrama, se muestran bases de datos de RAC que se ejecutan en las regiones us-west2 y us-east4. La replicación se configura con Data Guard asíncrono. Todo el tráfico entre la solución Bare Metal y Google Cloud pasa por una interconexión de socio, y el tráfico entre regiones viaja por la red troncal de Google. Los servidores de la aplicación se configuran en cada pero, por lo general, se cierran en la región de recuperación ante desastres de conmutación por error.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificada	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: Corrupciones	< 60 s	De minutos a horas, según la conmutación por error de la aplicación
	Desastres: Fallas en la extensión de la región	&lt; Década de 1960	Minutos a horas, según la conmutación por error de la aplicación.
Planificada	Parches de la base de datos y actualizaciones del SO o el firmware	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	De 1 a 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 Plata, puedes Opta por el modelo Oro, que usa una instancia de sincronización remota. para proporcionar replicación síncrona a una instancia que se ejecuta en Google Cloud Compute Engine.

Una instancia de sincronización lejana incluye un archivo de control de base de datos y un conjunto de rehacer en espera que se ejecutan geográficamente cerca de la base de datos principal. Esta instancia es para recibir rehacer de forma síncrona con baja latencia, lo que permite cambios que se registrarán fuera de la extensión de región de la base de datos principal. Luego, la instancia de sincronización remota reenvía la acción de rehacer a la base de datos en espera en la región remota para que se aplique 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 usarse del tráfico de las aplicaciones. La instancia de sincronización remota se usa para proporcionar una ubicación tolerante a errores para que los cambios de la base de datos se escriban de forma síncrona, lo que permite una solución sin pérdida de datos. Cuando se realiza la replicación síncrona en la instancia de sincronización remota, las transacciones no se confirman en la base de datos principal hasta que se reciben y confirman los cambios en la instancia de sincronización remota.

Por lo general, las instancias de Compute Engine se seleccionan como candidatas para alojar una instancia de sincronización lejana. Colocar la instancia de sincronización remota en una zona de Compute Engine cerca de la base de datos principal agrega una latencia mínima (por lo general, inferior a 1.5 ms) y protege contra fallas dentro de la extensión de región.

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

La configuración de ejemplo en el 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 dentro de us-west2 ejecuta una instancia de sincronización remota y recibe una repetición síncrona. La instancia de sincronización lejana está configurada para enviar rehacer de forma asíncrona a un RAC. base de datos 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 controlar el tráfico de la aplicación en caso de desastre.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificada	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: Corrupciones	0	Minutos a horas, según la conmutación por error regional de la aplicación.
	Desastres: Fallas de extensión de región	0	Minutos a horas, según la conmutación por error regional de la aplicación.
Planificada	Parches de la base de datos y actualizaciones del SO o el firmware	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	De 1 a 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 ofrece con una tecnología diferente y conlleva distintos RTO y RPO del usuario.

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

La implementación Platino 1 se basa en la implementación del modelo de oro, ya que agrega una segunda base de datos de Data Guard en espera en la región local que se ejecuta en una instancia de Compute Engine. Esta configuración usa la replicación síncrona entre la base de datos principal y la instancia en espera que se ejecuta en Compute Engine lo que proporciona una garantía sin pérdida de datos en la región principal.

Crear una base de datos en espera en la región permite la conmutación por error y el cambio de la base de datos las operaciones sin que esto afecte a las aplicaciones. Durante el rol de la base de datos cambios, las aplicaciones que se configuran de acuerdo con Las consideraciones de clientes de Oracle se reconectan automáticamente a la nueva base de datos principal sin que requieran intervención manual. Las aplicaciones configuradas correctamente experimentan menos de 2 minutos de tiempo de inactividad durante un evento de conmutación por error.

Si bien la base de datos en espera en Compute Engine no ejecuta RAC, debe estar para soportar el tráfico normal de la aplicación cuando se ejecuta como el en la base de datos. Esta instancia puede ejecutarse con una forma más pequeña mientras funciona como una instancia en espera y aumentar su escala 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 un evento de conmutación por error afecta negativamente el RTO, ya que la instancia se debe reiniciar 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 Agente de Data Guard con un observador. El observador ejecuta un cliente básico de Oracle. con conexiones a todas las bases de datos principales y en espera. Si el observador detecta una falla en la base de datos principal, inicia una conmutación por error a una de las bases de datos en espera. La base de datos en espera que se ejecuta en Compute Engine debe ser que se configura como el destino preferido de conmutación por error cuando se usa la implementación de nivel Oro.

Oracle recomienda que el observador se coloque en una región separada de las bases de datos principal y en espera. Esto brinda la mejor protección contra fallas regionales y eventos de partición de red. Si una tercera región no es posible, el observador debe estar instalado en la región principal, ejecutándose en un distinta de la del sitio en espera cerca del sitio.

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

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

• Una base de datos principal que ejecuta RAC en el servidor de la solución Bare Metal en us-west2 región.
• Una base de datos de resguardo cercana al sitio que se ejecuta en una instancia de Compute Engine en la región us-west2
• Una base de datos en espera remota que se ejecuta en el servidor de la solución Bare Metal en la región us-east4.
• El observador de Data Guard que se ejecuta en la instancia de Compute Engine en la región us-central1

La replicación síncrona se configura para la base de datos de resguardo en 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, el rehacer se envía desde la base de datos principal al en espera; rehacer no se reenvía de una base de datos en espera a la 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 la aplicación se configuran en el región principal y conectarse a la base de datos principal en el servidor de la solución Bare Metal (o la base de datos en la instancia de Compute Engine durante la conmutación por error y el cambio operaciones). Las instancias de la aplicación se configuran en la región us-east4 en Compute Engine para controlar el tráfico de la aplicación en caso de desastre.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificada	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: Corrupciones	0	< Década de 1960
	Desastres: Fallas en la extensión de la región	0	< Década de 1960
Planificada	Parches de la base de datos y actualizaciones del SO o el firmware	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	De 1 a 2 horas Minutos si usas DBMS_ROLLING para realizar la actualización.

Implementación platino 2: GoldenGate para la replicación

La implementación Platinum 2 se basa en el uso de Oracle GoldenGate para la replicación. Desde GoldenGate no se replica a nivel del bloque. Permite que cada base de datos servicio lee y escribe las sesiones de la aplicación de forma independiente. Replica los cambios de forma bidireccional, lo que permite una configuración de base de datos activa/activa.

Las solicitudes se deben validar meticulosamente. antes de comprometerse con un estado del objeto Deployment, y debes tener en cuenta la 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 la base de datos de Oracle. Implementaciones activas/activas suelen requerir un diseño sofisticado de esquemas y aplicaciones para aprovechar de una implementación de base de datos multisitio. Muchas aplicaciones empaquetadas previamente no admiten este tipo de arquitectura.

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

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

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificada	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupción	De segundos a minutos 0 si se usa Data Guard en cada ubicación	0
	Desastres: Fallas de extensión de región	De segundos a minutos 0 si se usa Data Guard en cada ubicación	0
Planificada	Parches de la base de datos y actualizaciones del SO o el 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