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 descritas en esta guía tienen licencia separada fuera de una Licencia de Enterprise Edition. Algunas de estas funciones incluyen, entre otras, a:

• Clústeres de aplicación real de Oracle
• Oracle Active Data Guard
• 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 base de datos de Oracle se debe determinar en función de lo siguiente: el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación de una aplicación (RPO). 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 aceptable. El costo y la complejidad de un sistema aumentan a medida que disminuye cada uno de estos valores. Para ver más para obtener 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 vuelve un problema a medida que el RPO se acerca a cero.

A menos que se lo haya explicado correctamente en la fase de diseño, implementar el modelo de 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 el diseño de 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. Recuperación ante desastres abarca un alcance mayor debido a la cantidad de componentes integrados que deben en caso de 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 servidor, la red o el hardware de almacenamiento
• Interfaces de red múltiples, conmutadores y cables
• Telas de almacenamiento, controladores y dispositivos de disco redundantes
• Las interconexiones de socio tolerantes a errores entre Google Cloud y 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. Recuperación ante desastres la planificación debe considerar 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:

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

Clústeres de aplicación real de Oracle

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

Oracle Recovery Manager (RMAN) es la herramienta principal para crear copias de seguridad y recuperar Bases de datos de Oracle debido a su capacidad de leer el archivo de datos de propiedad de Oracle de un conjunto de datos tengan un formato común. 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 disponibles que se usará para la recuperación.

Oracle Data Guard

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

Las bases de datos en espera física son copias bloque por bloque que permiten una copia de que la base de datos esté abierta para la escritura; todos los demás están montados (pero no está abierto) para aplicar cambios o abrir el modo de solo lectura para admitir informes aplicaciones.

Si quieres obtener información para configurar Data Guard en la solución Bare Metal, consulta Implementa Data Guard de Oracle en la solución Bare Metal.

FLASHBACK DATABASE

La función FLASHBACK DATABASE de Oracle Enterprise Edition les permite a los administradores retroceder rápidamente una base de datos a un punto específico en el tiempo sin necesidad de y realizar restablecimientos 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 para rastrear 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 a SQL y ejecuta 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 al hecho de que las transacciones se traducen y aplican como SQL en el 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 disponibilidad máxima (MAA) para proporcionan modelos recomendados de recuperación ante desastres para implementar aplicaciones y bases de datos.

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

• Modelo cobre
• Modelo Bronce
• Modelo plateado
• Modelo Oro
• Modelo 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 ser evaluar según sus requisitos de disponibilidad y diseñarse según un un modelo de responsabilidad compartida. Es común que las bases de datos de desarrollo usen un modelo con menor protección que sus contrapartes de producción y control de calidad.

El modelo Bronce está diseñado para bases de datos que no necesitan un RTO medido en minutos. Los modelos Plata y de nivel superior incluyen bases de datos en espera que se ejecutan en 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 copias de seguridad y recuperación que deben de todos modos, incluso si se implementa una base de datos en espera.

Modelo Copper

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 de la implementación requiere un enfoque de dos etapas, pero se puede usar la secuencia de comandos para SDK de Google Cloud para 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 deben trasladarse 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
No planificadas	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupción	Última copia de seguridad de registro de archivo, incremental o completa que se se transfieran desde el entorno de ejecución	Horas, según el tamaño de la base de datos y el ancho de banda asignado a 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 entorno de ejecución	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

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 almacenamiento regional

En esta implementación, las copias de seguridad se escriben directamente en medios fuera del sitio. En la mayoría en varios casos, el destino preferido para las copias de seguridad 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 planificadas	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupción	Último registro de archivo, incremental o copia de seguridad completa	Horas, según el tamaño de la base de datos y el ancho de banda asignado a Interconexión de socio
	Desastres: Fallas en la extensión de la 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: Copia de seguridad con copia de seguridad y DR

En esta implementación, el servicio de Copia de seguridad y DR se usa para almacenar copias de seguridad en 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

Copia de seguridad y DR también ofrece un RTO más rápido que almacenar las copias de seguridad en Filestore o Cloud Storage, ya que puede tomar fotos imágenes de archivos de base de datos disponibles para la instancia de Oracle. La activación y migración Esta función permite que una base de datos esté en línea rápidamente mientras se copia a la producción de almacenamiento, lo que reduce el RTO de forma drástica.

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

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificadas	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupción	Último registro de archivo, incremental o copia de seguridad completa	Minutos a horas, según los requisitos de rendimiento, el tamaño de la base de datos y el ancho de banda asignado a Interconexión de socio
	Desastres: Fallas en la extensión de la 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 o la capacidad del cliente de cambiarse a otra extensión de región
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

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úa como base de datos en espera. Dado que Data Guard depende del transporte y aplicar los cambios de la base de datos a medida que ocurren, el RPO puede ser casi 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 y el período definido por el usuario. Data Guard supervisa la configuración observador, que puede ejecutarse.

El modelo Plata tiene el beneficio de garantizar que la base de datos esté disponible en la de una falla regional total, pero las operaciones de conmutación por error y cambio podrían afectan el rendimiento de la aplicación como la latencia de red entre la aumentar los servidores y las bases de datos. Rara vez se recomienda ejecutar aplicaciones y y admitir bases de datos en diferentes regiones. Si bien el RTO de la base de datos puede ser menos de 1 minuto, la conmutación por error de una aplicación podría demorar de minutos a horas servicios sean completamente funcionales. En la mayoría de los casos, la ejecución de desastres interregionales los planes de recuperación y conmutación por error suelen involucrar procesos manuales componentes que se mueven.

En el modelo Silver, es posible que debas tener períodos de inactividad o mantenimiento durante las actividades de aplicación de parches trimestrales. La introducción de Oracle RAC puede reducir el tiempo de inactividad en caso de que la aplicación de 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 las bases de datos RAC que se ejecutan en us-west2 y us-east4 regiones. La replicación se configura mediante los Data Guard Todo el tráfico entre la solución Bare Metal y Google Cloud transita una interconexión de socio y el tráfico entre regiones viaja a través de 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 planificadas	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupción	< Década de 1960	Minutos a horas, según la conmutación por error de la aplicación.
	Desastres: Fallas de extensión de región	< Década de 1960	De minutos a horas, según la conmutación por error de la aplicación
Planificada	Parches de bases de datos, actualizaciones de SO / FW	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 oro

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 se configura para recibir la acción de rehacer de forma síncrona con baja latencia, lo que permite que todos los cambios se registren fuera de la extensión de región de la base de datos principal. El lejano sincronizada, luego reenvía el rehacer a la base de datos en espera en la región aplicable 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 a la sincronización remota las transacciones no se confirman en la base de datos principal hasta que se recibieron y se confirmaron cambios 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. Ubicar la instancia de lejanía en una zona de Compute Engine en La proximidad a la base de datos principal agrega una latencia mínima (por lo general, inferior a 1.5 ms). y protege contra fallas en 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 Compute Engine dentro de us-west2 está ejecutando una instancia de sincronización lejana, que recibe notificaciones rehacer. 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. Se configuran las instancias de aplicación en la región us-east4 de Compute Engine para controlar el tráfico de las aplicaciones en de un desastre.

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificadas	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupción	0	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 bases de datos, actualizaciones de SO / FW	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 Platino 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 Platinum 1 se basa en la implementación del modelo Oro mediante agregar una segunda base de datos en espera de Data Guard en la región local que se ejecute en un 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 más 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 un en espera y escalado verticalmente durante eventos de conmutación por error, o ejecutar a la máxima capacidad. veces. 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 un en la base de datos principal, inicia una conmutación por error a una de las instancias bases de datos. 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 independiente de bases de datos primarias 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 en espera cercana al sitio que se ejecuta en una instancia de Compute Engine en us-west2 región.
• Una base de datos en espera remota que se ejecuta en el servidor de la solución Bare Metal en us-east4 región.
• El observador de Data Guard que se ejecuta en la instancia de Compute Engine en us-central1 región.

La replicación síncrona está configurada para la base de datos en espera en 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 al en espera; rehacer no se reenvía de una base de datos en espera a la otra. El de configuración en una tercera región y mantiene la conectividad a todos bases de datos en 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 aplicación se configuran en la región us-east4 el Compute Engine para controlar el tráfico de las aplicaciones en caso de que ocurra un desastre

Interrupción	Tipo de interrupción	RPO	Regreso a la oficina
No planificadas	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia Segundos si se usa RAC
	Desastres: corrupción	0	< Década de 1960
	Desastres: Fallas en la extensión de la región	0	< Década de 1960
Planificada	Parches de bases de datos, actualizaciones de SO / FW	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 el 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 RPO de pérdida de datos cero debido a la naturaleza asíncrona de la replicación lógica. Locales Se pueden implementar bases de datos en espera 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 planificadas	Falla recuperable de nodos o instancias	0	Tiempo necesario para reiniciar la instancia
	Desastres: corrupción	De segundos a minutos 0 si usas Data Guard en cada ubicación	0
	Desastres: Fallas en la extensión de la región	De segundos a minutos 0 si usas Data Guard en cada ubicación	0
Planificada	Parches de bases de datos, actualizaciones de SO / FW	0	Tiempo necesario para actualizar y reiniciar la instancia. Segundos si se usa RAC
	Actualización importante de la base de datos	0	0