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 que ejecutan cargas de trabajo de bases de datos de Oracle críticas para la misión en un entorno de la solución Bare Metal.

En esta guía, se supone que ejecutas Oracle Enterprise Edition. Algunas de las funciones que se describen en esta guía tienen una licencia independiente fuera de la licencia de Enterprise Edition. Algunas de estas funciones incluyen, entre otras, las siguientes:

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

Consulta tus acuerdos de licencia de Oracle para determinar qué funciones puedes usar cuando planifiques 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 de 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 el RTO y el RPO, consulta Conceptos básicos de la planificación de DR.

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

A menos que se tengan 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 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, la recuperación ante desastres es parte de un plan general de continuidad empresarial y se aplica a fallas más grandes que pueden hacer que grupos enteros de sistemas no estén disponibles. La recuperación ante desastres abarca un alcance mayor debido a la cantidad de componentes integrados que se deben recuperar en caso de desastre.

La alta disponibilidad debe considerarse la "primera línea de defensa" cuando se diseña un sistema confiable. Una arquitectura de base de datos con alta disponibilidad debe poder soportar fallas individuales y seguir ejecutándose sin causar tiempo de inactividad para la aplicación. Los componentes de alta disponibilidad de un sistema deben incluir, entre otros, los siguientes:

• Alimentación redundante en el hardware del servidor, la red o el almacenamiento
• Múltiples interfaces de red, conmutadores y cables
• Estructuras, controladores y dispositivos de disco de almacenamiento redundantes
• Interconexiones de socio 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 hagan 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 incluyen algunas herramientas de alta disponibilidad y recuperación ante desastres 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 la base de datos y que varios servidores de bases de datos las atiendan. Las bases de datos que usan RAC permiten una configuración activa/activa entre servidores dentro de una extensión de región.

Por lo general, RAC se usa para proporcionar alta disponibilidad a los sistemas que necesitan protección contra la falla de un solo servidor. Debido al enfoque de "todo compartido" (almacenamiento y redes compartidos) para el clustering, debe existir un clúster de RAC que se ejecute en el entorno de la solución Bare Metal dentro de un solo pod de la 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 ante desastres.

Oracle Recovery Manager

Oracle Recovery Manager (RMAN) es la herramienta principal para la copia de seguridad y la recuperación de 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 se puede usar para realizar 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 están disponibles para 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 en espera en una configuración física o lógica.

Las bases de datos de reserva físicas son copias bloque por bloque que permiten que una copia de la base de datos esté abierta para escritura; 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 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 restablecimientos de bases de datos que consumen mucho tiempo.

En el contexto de la recuperación ante desastres, FLASHBACK DATABASE se usa comúnmente junto con Data Guard durante las operaciones de conmutación por error para restablecer la base de datos más rápido. La base de datos con errores se restablece a un momento específico que es coherente con los registros de la nueva instancia principal, y se envía la rehacer para que se pueda volver a sincronizar por completo.

Oracle GoldenGate

Oracle GoldenGate es una herramienta de replicación lógica que se usa comúnmente para habilitar implementaciones multisitio activas/activas 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 archivos de registro, 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 código SQL en la base de datos de destino.

Esta arquitectura convierte a GoldenGate en una herramienta potente para transferir 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 software independiente en los sistemas de origen y destino. GoldenGate no se puede usar para la replicación síncrona, ya que las transacciones se traducen y se aplican como SQL en la base de datos de destino. Si bien GoldenGate puede proporcionar un retraso mínimo para la replicación, no puede garantizar un RPO de cero por sí solo.

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

Oracle creó el marco de trabajo de la arquitectura de máxima disponibilidad (MAA) para proporcionarte 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 de plata
• Modelo de oro
• Modelo de platino

Los modelos se asignan a patrones de implementación específicos que cumplen con el RPO y el RTO en eventos de interrupciones planificadas y no planificadas. Cada carga de trabajo de la base de datos debe evaluarse según 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 Bronze 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 de los modelos de nivel inferior. Por ejemplo, el modelo Bronze usa conceptos de copia de seguridad y recuperación que se deben seguir incluso si se implementa una base de datos en espera.

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 locales y copiarlas en el almacenamiento que reside fuera de la extensión de la región. Esta implementación requiere un enfoque de dos etapas, pero se puede crear un script para usar el SDK de Google Cloud y automatizar la transmisión de copias de seguridad.

El uso de esta implementación también aumenta el RTO debido a la recuperación en dos etapas que se requiere. RMAN no puede acceder directamente a las copias de seguridad, por lo que se deben mover a una ubicación disponible para RMAN antes de que pueda comenzar la recuperación.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
Imprevisto	Error recuperable de nodo o 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, según el tamaño de la base de datos y el ancho de banda asignado a la interconexión de socio
	Desastres: Fallas en la extensión de la región	Última copia de seguridad de registro de archivo, incremental o completa que se transfirió fuera del RE	Días o semanas, según el tiempo necesario para volver a poner en línea la extensión de la región
Planificada	Parches de la base de datos y actualizaciones del SO o FW	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización principal de la base de datos	0	De 1 a 2 horas

Modelo de bronce

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

Implementación de nivel bronce 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 bucket de Cloud Storage como un sistema de archivos.

Las recomendaciones para usar Cloud Storage FUSE se encuentran en 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 la solución Bare Metal.

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

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
Imprevisto	Error recuperable de nodo o instancia	0	Tiempo necesario para reiniciar la instancia
	Desastres: Corrupciones	Última copia de seguridad de archivelog, incremental o completa	Horas, según el tamaño de la base de datos y el ancho de banda asignado a la interconexión de socio
	Desastres: Fallas en la extensión de la región	Última copia de seguridad de archivelog, incremental o completa	Días o semanas, según el tiempo necesario para volver a poner en línea la extensión de la región
Planificada	Parches de la base de datos y actualizaciones del SO o firmware	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización principal de la base de datos	0	De 1 a 2 horas

Implementación de nivel bronce 2: Copia de seguridad con Backup and DR

En esta implementación, el servicio Backup and DR se usa para almacenar copias de seguridad enGoogle Cloud. Backup and DR ofrece un enfoque de copias de seguridad incrementales permanentes, que se almacenan en medios de alto rendimiento respaldados por Cloud Storage para la retenció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 hacer que las imágenes de los archivos de la base de datos estén disponibles de inmediato para la instancia de Oracle. La función de montaje y migración pone 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 una implementación de ejemplo.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
Imprevisto	Error recuperable de nodo o instancia	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: Corrupciones	Última copia de seguridad de archivelog, incremental o completa	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 socio
	Desastres: Fallas en la extensión de la región	Última copia de seguridad de archivelog, incremental o completa	Días o semanas, según el tiempo necesario para volver a poner en línea la extensión regional o la capacidad del cliente para mudarse a otra extensión regional.
Planificada	Parches de la base de datos y actualizaciones del SO o FW	0	Tiempo necesario para actualizar y reiniciar la instancia
	Actualización principal de la base de datos	0	De 1 a 2 horas

Plata

El modelo Silver introduce 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 los cambios de la base de datos a medida que ocurren, el RPO puede ser casi nulo. El modelo Silver se basa en la replicación asíncrona. El uso de la replicación síncrona garantiza la pérdida cero de datos, pero el tiempo que se tarda en enviar datos entre regiones suele llevar el tiempo de respuesta de la aplicación más allá de los límites aceptables.

La función de conmutación por error de inicio rápido de Data Guard tiene la capacidad de realizar operaciones de conmutación por error automáticas si una base de datos principal deja de estar disponible durante un período definido por el usuario. La configuración se supervisa mediante un proceso de observador de Data Guard que se puede ejecutar.

El modelo Silver tiene el beneficio de garantizar que la base de datos esté disponible en caso de una falla regional total, pero las operaciones de conmutación por error y conmutación pueden afectar el rendimiento de la aplicación a medida que aumenta la latencia de la red entre los servidores de aplicaciones y la base de datos. Rara vez se recomienda ejecutar aplicaciones y bases de datos de asistencia 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 de minutos a horas antes de que los servicios funcionen por completo. En la mayoría de los casos, la ejecución de planes de conmutación por error de recuperación ante desastres en varias regiones suele implicar procesos manuales debido a la cantidad de componentes que se trasladan.

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

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

La configuración de ejemplo del diagrama muestra 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 Cloudpasa por una interconexión de socio, y el tráfico entre regiones viaja a través de 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	Tipo de interrupción	RPO	Regreso a la oficina
Imprevisto	Error recuperable de nodo o instancia	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	< 60 s	De 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 FW	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización principal de la base de datos	0	De 1 a 2 horas Minutos si usas DBMS_ROLLING para realizar la actualización

Modelo de oro

Si te preocupa la pérdida de datos en el modelo Silver, puedes optar por 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 la base de datos y un conjunto de registros de rehacer en 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. Luego, la instancia de sincronización lejana reenvía el 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 atender el tráfico de aplicaciones. La instancia de sincronización lejana se usa para proporcionar una ubicación tolerante a errores para que los cambios en 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 lejana, las transacciones no se confirman en la base de datos principal hasta que los cambios se reciben y se confirman en la instancia de sincronización lejana.

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 lejana en una zona de Compute Engine cerca de la base de datos principal agrega una latencia mínima (por lo general, menos de 1.5 ms) y protege contra fallas dentro de la extensión de la región.

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

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

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
Imprevisto	Error recuperable de nodo o instancia	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: Corrupciones	0	De minutos a horas, según la conmutación por error regional de la aplicación.
	Desastres: Fallas en la extensión de la región	0	De 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 FW	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización principal de la base de datos	0	De 1 a 2 horas Minutos si usas DBMS_ROLLING para realizar la actualización.

Modelo de Platino

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

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

La implementación de nivel platino 1 se basa en la implementación del modelo de nivel oro agregando una segunda base de datos en espera de Data Guard 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 base de datos en espera que se ejecuta en Compute Engine, lo que proporciona una garantía de cero pérdida de datos dentro de la región principal.

Crear una base de datos en espera en la misma región permite que las operaciones de conmutación por error y conmutación de bases de datos se realicen sin afectar las aplicaciones. Durante los cambios de rol de la base de datos, las aplicaciones configuradas de acuerdo con las consideraciones del cliente 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 un evento de conmutación por error.

Si bien la base de datos en espera en Compute Engine no ejecuta RAC, debe tener el tamaño adecuado para admitir el tráfico normal de la aplicación cuando se ejecuta como la base de datos principal. Esta instancia puede ejecutarse con una forma más pequeña mientras funciona como instancia de espera y se amplía 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 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 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 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 separada de las bases de datos principal y en espera. Esto proporciona la mejor protección contra fallas regionales y eventos de partición de red. Si no es posible una tercera región, el observador debe instalarse en la región principal y ejecutarse en una zona diferente de la región en espera cercana al 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 los siguientes elementos:

• Una base de datos principal que ejecuta RAC en un servidor de la solución Bare Metal en la región us-west2.
• Una base de datos en espera 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 un 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 está configurada para la base de datos en espera de la región que se ejecuta en la instancia de Compute Engine, y la replicación asíncrona está configurada para la región remota. En cada caso, el rehacer se envía desde la base de datos principal a la base de datos en espera; el 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 la región principal y se conectan 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 las operaciones de conmutación por error y conmutación). 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
Imprevisto	Error recuperable de nodo o instancia	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: Corrupciones	0	< 60 s
	Desastres: Fallas en la extensión de la región	0	< 60 s
Planificada	Parches de la base de datos y actualizaciones del SO o FW	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización principal de la base de datos	0	De 1 a 2 horas Minutos si usas DBMS_ROLLING para realizar la actualización

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

La implementación de Platinum 2 se basa en el uso de Oracle GoldenGate para la replicación. Dado que GoldenGate no replica a nivel de bloque. Permite que cada servicio de 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 minuciosamente antes de confirmar 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 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 pérdida de datos cero debido a la naturaleza asíncrona de la replicación lógica. Las bases de datos en 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 una implementación de ejemplo.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
Imprevisto	Error recuperable de nodo o 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: Fallas en la extensión de la región	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 FW	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización principal de la base de datos	0	0