Conceptos básicos de Data Guard de Oracle 12c

 

Data Guard es la verdadera tecnología de protección contra desastres de Oracle 12c. En él, tiene un mínimo de dos bases de datos, principal y en espera. Data Guard tiene opciones para múltiples sitios en espera, así como una configuración activo-activo.

Por activo-activo, significa que ambos / todos los sitios están en funcionamiento, en funcionamiento y accesibles. Esto se opone a los sitios que tienen una ubicación activa y las otras deben iniciarse cuando se necesitan. Este es un ejemplo del diseño arquitectónico general.

Arquitectura de Data Guard y Oracle 12c

Comenzar una descripción con la base de datos primaria es fácil porque se diferencia muy poco de cualquier otra base de datos que pueda tener. La única diferencia es lo que hace con sus registros de rehacer archivados.

La base de datos principal escribe un conjunto de registros de rehacer archivos en un área de recuperación de Flash o en un disco local. Sin embargo, puede configurar uno o más destinos en un entorno de Data Guard.

El parámetro LOG_ARCHIVE_DEST_n puede tener este aspecto para la configuración anterior:

LOG_ARCHIVE_DEST_10 = 'UBICACIÓN = USE_DB_RECOVERY_FILE_DEST' LOG_ARCHIVE_DEST_1 = 'SERVICIO = PHYSDBY1 ARCH' LOG_ARCHIVE_DEST_2 = 'SERVICIO = LOGSDBY1 LGWR'

 

·         LOG_ARCHIVE_DEST_10 está configurado para enviar registros de rehacer archivos al Área de recuperación de Flash local. Se requiere un destino local para todas las bases de datos en modo de registro de archivo.

·         LOG_ARCHIVE_DEST_1 está configurado para enviar los registros de archivo a través del proceso de archivado a un sitio remoto PHYSDBY1. El nombre del servicio para este sitio remoto tiene una entrada en el archivo tnsnames.ora en el servidor primario.

·         LOG_ARCHIVE_DEST_2 está configurado para enviar los registros de archivo a través del proceso LGWR a un sitio remoto llamado LOGSDBY1. El nombre del servicio para este sitio remoto también tiene una entrada en el archivo tnsnames.ora en el servidor primario.

 

¿Por qué la diferencia entre los métodos de envío ARCn y LGWR? Eso tiene algo que ver con los modos de protección. Un entorno de Data Guard tiene tres modos de protección.

Disponibilidad máxima

El modo de protección de máxima disponibilidad se compromete entre el rendimiento y la disponibilidad de datos. Funciona mediante el uso de LGWR para escribir simultáneamente para rehacer registros en los sitios principal y en espera. La degradación del rendimiento viene en forma de procesos que tienen que esperar a que las entradas del registro de rehacer se escriban en varias ubicaciones.

Las sesiones que emiten confirmaciones deben esperar hasta que se haya registrado toda la información necesaria en al menos un registro de rehacer de la base de datos en espera. Si una sesión se bloquea debido a su incapacidad para escribir información de rehacer, el resto de la base de datos sigue avanzando.

Protección máxima

El modo de protección máxima es similar a la disponibilidad máxima, excepto que si una sesión no puede verificar que rehacer está escrito en el sitio remoto, la base de datos principal se apaga.

Consejo:  Configure al menos dos sitios en espera para el modo de máxima protección. De esa manera, un sitio en espera que deje de estar disponible no interrumpirá el servicio para toda la aplicación.

 

Este modo verifica que no se producirá ninguna pérdida de datos en caso de desastre a costa del rendimiento.

Rendimiento máximo

El modo de protección de máximo rendimiento separa el proceso de trasvase de registros de la base de datos principal pasándolo al proceso de registro de archivo (ARCn). Al hacer esto, todas las operaciones en el sitio principal pueden continuar sin esperar a que se escriban las entradas de rehacer para rehacer los registros o rehacer el envío.

 

Esto se opone a los modos de trasvase de registros que utilizan el escritor de registros para transferir transacciones. El uso del escritor de registros puede ralentizar el procesamiento de la transacción porque puede verse afectado por la disponibilidad o el rendimiento de la red.

El rendimiento máximo proporciona el nivel más alto de rendimiento en el sitio principal a expensas de la divergencia de datos. La divergencia de datos se produce cuando los datos de los dos sitios comienzan a de sincronizarse. Los datos de rehacer del archivo no se envían hasta que se llena todo el registro de rehacer del archivo. En el peor de los casos, la pérdida de un sitio completo podría resultar en la pérdida de todos los datos de un registro de rehacer de archivo (archive redo log).

 

Realización de operaciones de conmutación y conmutación por error

Puede cambiar el procesamiento a su sitio en espera de dos maneras:

·         La conmutación (switchover) es un cambio planificado que puede ocurrir si desea realizar mantenimiento en el sitio principal que requiere que no esté disponible. Esta operación puede requerir unos minutos de inactividad en la aplicación, pero si tiene que realizar un mantenimiento que dure una hora o más, el tiempo de inactividad podría valer la pena. Esta operación se denomina cambio elegante porque convierte el sitio principal en su sitio en espera y su sitio en espera en el principal. Además, puede volver fácilmente al sitio principal original sin tener que volver a crearlo desde cero.

·         La conmutación por error (failover) ocurre cuando el sitio principal se ha visto comprometido de alguna manera. Quizás fue una pérdida total del sitio, o quizás descubrió daños físicos en un archivo de datos. No siempre, pero por lo general después de una conmutación por error, debe volver a crear completamente el sitio principal o recuperarlo de una copia de seguridad y reinstalarlo. Por lo general, realiza una conmutación por error solo cuando ha determinado que reparar el sitio principal llevará el tiempo suficiente para que prefiera no tener una interrupción de la aplicación durante todo el tiempo.

Para realizar un cambio, siga estos pasos:

1.        En el primario actual, inicie sesión en SQL * Plus y escriba lo siguiente:

<alter database commit to switchover to physical standby;>

 Deberías ver esto:

< Base de datos alterada >

.

2.       Apague la base de datos primaria:

 <shutdown immediate>

Deberías ver esto::

Database closed.

Database dismounted.

ORACLE instance shut down.

3.       Inicie la base de datos primaria en modo nomount:

  <startup nomount>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

4.       Monte la base de datos en espera:

<alter database mount standby database;>

Deberías ver esto:

Database altered.

5.       Iniciar la recuperación:

<recover managed standby database disconnect;>

Ves esto:

Media recovery complete.

6.       Inicie sesión en SQL * Plus en el modo de espera actual y escriba lo siguiente:

<alter database commit to switchover to physical primary;>

Deberías ver esto:

Database altered.

7.       Apague la base de datos en espera:

 <shutdown immediate>

Deberías ver esto:

Database closed.

Database dismounted.

ORACLE instance shut down.

8. Asegúrese de que todos los parámetros de inicialización apropiados estén configurados para que esta base de datos se comporte correctamente como primaria.

9.       Empiece normalmente:

<startup>

Debería ver algo como esto:

ORACLE instance started.

Total System Global Area 789172224 bytes

Fixed Size         2148552 bytes

Variable Size       578815800 bytes

Database Buffers     201326592 bytes

Redo Buffers        6881280 bytes

Database mounted.

Database opened.

Asegúrese de que los usuarios y las aplicaciones puedan conectarse y utilizar la nueva instancia principal.

Nuevas características en Oracle database 19c

Esta versión de la base de datos viene con algunas mejoras interesantes para hacer su trabajo más rápido y más fácil. Si bien el enfoque principal de este ciclo de desarrollo ha sido la estabilidad, hay algunas características nuevas enfocadas en la automatización y optimización para el cliente. Veamos algunas de estas mejoras.

• Redireccionamiento DML de Active Data Guard.
• Indexación automática.
• Tablas híbridas particionadas (Big Data).
• Compatibilidad con JSON.
• Más estabilidad y disponibilidad.

Redireccionamiento DML de Active Data Guard.

las bases de datos de respaldo en espera son una parte necesaria de muchos planes de recuperación de desastres, pero pueden ser costosas de llevar como potencia de procesamiento inactiva. Oracle ha trabajado para hacer que estas bases de datos sean más valiosas en su estrategia desde el lanzamiento de Active Data Guard en 11c. Esa característica, que le permite utilizar los recursos de la base de datos en espera para ejecutar informes y copias de seguridad, obtiene una actualización en 19c. Esta versión agrega la capacidad de ejecutar transacciones mediante la creación de un redireccionamiento inmediato a la base de datos principal. Las transacciones que se ejecutan en la copia de seguridad se envían y almacenan inmediatamente en las bases de datos primarias y luego en las de respaldo. No importa si sus bases de datos están en la nube o en la versión local, con Active Data Guard Redirect, ahora puede usar su base de datos en espera para obtener aún más ventajas.

Indexación automática.

La indexación de elementos lleva tiempo y puede significar una gran cantidad de trabajo para su equipo de TI. Con la indexación automática, el 19c de Oracle utiliza algoritmos de aprendizaje automático para identificar elementos, mapear y validar las opciones de indexación e indexar automáticamente para usted. Estos algoritmos aprenden sobre la marcha, por lo que solo se vuelven más eficientes y precisos en el tiempo. La automatización es la clave para mejorar el proceso. Con esta herramienta puede ahorrar tiempo y recursos al automatizar su indexación y enfocar sus energías en otros lugares.

Tablas híbridas particionadas.

Big Data significa almacenamiento grande, y con más y más información almacenada durante largos períodos de tiempo, es esencial encontrar las opciones más eficientes para manejar la creciente carga. Las tablas particionadas híbridas de Oracle se resienten al permitirle particionar los datos y luego seleccionar qué particiones deben almacenarse en la base de datos para acceder a las consultas y cuáles deben guardarse como archivos de solo lectura en ubicaciones externas. De esa manera, puede minimizar la carga en la base de datos en vivo mientras mantiene datos importantes para el almacenamiento y el acceso a largo plazo.

Cuarentena de consulta.

El desempeño general de un data mart o de un almacén de datos puede verse afectado cuando un usuario ejecuta una consulta que consume una cantidad excesiva de recursos de E/S y de computación. Oracle Database 19c “puede poner estas consultas en cuarentena automáticamente y garantizar que no se vuelvan a ejecutar”, esto da como resultado un desempeño uniforme para todos los usuarios de la base de datos. Se acabó ralentizar una instancia en Producción por ejecutar la "Query de la muerte".

Base de datos "JSON friendly".

Esta versión también incluye numerosas mejoras de JSON, así como funciones para optimizar inserciones de datos, estadísticas en tiempo real y más. Los servicios de base de datos de Oracle están diseñados teniendo en cuenta las necesidades del cliente. La compatibilidad de Oracle Database con JSON se incluyó a partir de Oracle Database 12c, con el almacenamiento nativo de documentos JSON y el acceso SQL, y continuó en 18c, con los análisis de alto desempeño para los documentos JSON, como si se hubiera realizado la ingesta de datos JSON en las filas y columnas de tabla de la base de datos.

Se ha mejorado y simplificado la sintaxis para nuestras funciones de JSON y se ha introducido la capacidad de realizar una actualización parcial de JSON, por lo que es posible actualizar un solo atributo de un gran documento JSON, en lugar de actualizar todo.

Más estabilidad y disponibilidad.

Las nuevas características son importantes en cada una de las versiones de Oracle Database. La estabilidad para las aplicaciones y las instalaciones de base de datos on-premises también es importante, y Oracle Database 19c también ofrece dicha estabilidad.

La estabilidad es uno de los principales objetivos de Oracle Database 19c; se trata de una versión con soporte a largo plazo hay clientes de productos "on-premises" cuentan con ciclos de actualización prolongados, y esta versión, Oracle Database 19c, es la que mucha gente estaba esperando para poder realizar la actualización a partir de Oracle Database 11g u Oracle Database 12c.

Para obtener más información sobre las bases de datos 19c de Oracle y una lista completa de las nuevas funciones, visite la página de Características de la base de datos de Oracle.

Entender Oracle Data Guard

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

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

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

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

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

Evolución histórica de Oracle Data Guard

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

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

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

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

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

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

FLUJO DE DATOS: PHYSICAL STANDBY

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

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

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

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

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

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

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

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

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

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

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

PROCESOS RELACIONADOS CON BASE DE DATOS EN ESPERA FÍSICA

En la base de datos primaria:

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

En la base de datos de reserva:

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

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

Data Guard Redo Servicios de Transporte

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

Data Guard Aplicar Servicios

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

Data Guard servicios de gestión de roles

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