Precalentamiento de una base de datos Amazon RDS Oracle para reducir el impacto de la carga diferida

Las Causas y el impacto de la carga diferida.

La carga diferida puede ocurrir en varios escenarios que requieren una restauración desde las instantáneas:

• Recuperación en un punto en el tiempo (PITR)
• Convertir la instacia RDS de Single-AZ to Multi-AZ
• Restaurar desde un snapshot
• Crear una nueva replica de lectura

La creación de una instancia RDS desde una instantánea típicamente toma unos pocos minutos, mientras PITR (Point-in-Time-Recovery) puede tomar mayor tiempo dependiendo de la cantidad de datos generados en el Log de transacciones. Después de la creación de la instancia RDS, los bloques de datos se empiezan a cargar desde Amazon S3 hacia Amazon EBS en un proceso conocido como la carga diferida. El proceso toma mas tiempo dependiendo del tamaño de la base de datos, pero no afecta la disponibilidad de la Base de datos durante la carga diferida.

Una vez la instancia RDS es restaurada y está disponible, los clientes pueden conectarse ya que está abierta para actividades de lectura y escritura. Durante una consulta o procesamiento de transacciones, si hay una petición de un bloque de datos que ya está en Amazon EBS, no hay ninguna latencia para buscarlo. Cuando el bloque de datos requerido no está en Amazon EBS, eso es inmediatamente cargado desde Amazon S3 dentro del volumen EBS, la cual puede causar latencia adicional de E/S. Las peticiones a posteriori que se hacen a los bloques previamente accedidos no generan latencia adicional de E/S.

Es posible que esta latencia no afecte a todas las aplicaciones, pero para minimizarla, se recomienda leer todos los bloques de datos tan pronto como se complete el proceso de restauración de la instancia.

Sin embargo, en los casos donde determinadas aplicaciones deben cumplir unos SLA de rendimiento antes de poner la base de datos a disposición de los usuarios, surge una disyuntiva entre la disponibilidad inmediata y un rendimiento inferior al óptimo hasta que finalice la carga diferida.

Dependiendo de los casos de uso específicos, usted puede adoptar las estrategias descritas en esta publicación para acelerar el proceso de carga diferida, asegurando que el sistema se lance con un rendimiento óptimo o equilibrando la disponibilidad inmediata con los niveles de tolerancia del rendimiento.

Enfoques para disminuir el tiempo de carga diferida

La siguiente tabla enumera enfoques para disminuir la duración de la carga diferida en una instancia de Amazon RDS para Oracle y la situación en la que este enfoque es aplicable. Cada enfoque tiene sus propias ventajas y desventajas.

Tenga en cuenta que la E/S de lectura se produce únicamente desde el host principal en el caso de escenarios Multi-AZ. Si la carga diferida se debió a la habilitación de Multi-AZ, entonces solo se requiere precalentamiento en el host secundario. Es posible que deba reiniciar en modo failover y repetir el proceso de precalentamiento en el nuevo primario para precalentar ambos hosts subyacentes.

Al comparar el impacto en el rendimiento entre los enfoques anteriores, considere lo siguiente:

• Validación de RMAN:

o La validación RMAN opera a nivel de bloque y no requiere exportación de datos.

o Comprueba la integridad del bloque de datos directamente dentro de los archivos de la base de datos.

o Para el método más optimizado, se recomienda utilizar los parámetros p_parallel y p_validation_type establecidos en FÍSICO.

o Normalmente, es más eficiente y requiere menos recursos en comparación con Data Pump.

o Ofrece un menor impacto en el rendimiento.

o Se prefiere para comprobaciones de integridad de datos en tablas grandes debido a sus operaciones optimizadas a nivel de bloque.

• SELECT explícito en todas las tablas grandes:

o La instrucción SELECT recupera solo bloques de tabla. Sin embargo, debe incluir sugerencias adicionales o verificación de que se está realizando un análisis completo y que los bloques no se omiten según ninguna optimización implementada.

o El impacto en el rendimiento depende del tamaño de la tabla y de la complejidad de la consulta.

o Puede consumir muchos recursos, especialmente para tablas grandes, lo que resulta en un mayor uso de E/S y CPU.

• Recopilación de estadísticas con DBMS:

o DBMS_STATS puede ayudar a escanear tanto tablas como índices.

o Puede utilizar los siguientes parámetros para la optimización.

• porcentaje_estimado => 100
• cascada => VERDADERO
• grado => 4 –> Puede especificar aquí el grado de paralelismo deseado
• stattab => ‘YourStatsTable’ -> Reemplace ‘YourStatsTable’ con el nombre de la tabla de estadísticas donde desea almacenar las estadísticas recopiladas. Esto es opcional y, si no se especifica, las estadísticas se almacenan en el diccionario de datos.

• Usando Oracle Data pump:

o Implica movimiento de datos (exportación), lo que hace que requiera muchos recursos.

o Es posible que se produzca un mayor uso de E/S y CPU durante la exportación.

o El impacto en el rendimiento puede ser mayor en comparación con otros enfoques.

o Puede esperar un impacto sustancial en el rendimiento y el espacio, según el tamaño de la tabla y el volumen de datos al utilizar Oracle Data Pump.

En resumen, la validación RMAN, que opera a nivel de bloque, es generalmente más eficiente y tiene un menor impacto en el rendimiento en comparación con Data Pump para verificaciones de integridad de datos en tablas grandes. La ejecución de consultas SELECT explícitas para recuperar datos de tablas grandes y exportar usando Oracle Data Pump tienen impactos significativos en el rendimiento, especialmente para tablas grandes. La elección debe alinearse con sus requisitos específicos y consideraciones de rendimiento para su base de datos Oracle.

Tenga en cuenta que, junto con los enfoques anteriores, el uso del tipo de instancia RDS y el volumen de EBS con mayor rendimiento de IOPS ayudará a completar la carga diferida más rápido; puede degradar el tipo de clase de instancia y disminuir el valor de IOPS/rendimiento una vez que se complete la carga diferida.

El enfoque de réplica de lectura al convertir de Single-AZ a Multi-AZ

Al convertir de Single-AZ a Multi-AZ, la carga diferida ocurre únicamente en el host secundario. Sin embargo, la carga diferida aún afecta la latencia de E/S de escritura porque las IOPS de escritura se escriben sincrónicamente en el host secundario. Después de habilitar la opción Multi-AZ, puede reiniciar en modo failover para que el host secundario se convierta en el principal y luego realizar uno de los escenarios de precalentamiento que se analizan en esta publicación.

Para evitar el impacto de la carga diferida durante una conversión Multi-AZ directa, una solución alternativa es emplear un enfoque de réplica de lectura. Esto implica crear una réplica con una configuración Multi-AZ, permitiendo tiempo suficiente para completar la carga diferida y, posteriormente, promover una réplica de lectura. Con este método, puede mitigar eficazmente los posibles efectos negativos causados ​​por la carga diferida en un escenario de conversión directa Multi-AZ.

Tenga en cuenta que esta solución solo es posible con las ediciones Oracle Enterprise y las licencias Active Data Guard en caso de abrir la instancia de réplica de lectura en modo de solo lectura.

Disminución del impacto de la carga diferida con la validación RMAN

El siguiente es un escenario de prueba para evaluar el impacto de la carga diferida en instancias de RDS para Oracle. También muestra cómo el precalentamiento de una instancia de RDS para Oracle mediante la validación RMAN puede mejorar significativamente el rendimiento de la base de datos después de restaurar desde una instantánea de RDS para Oracle.

Este ejemplo incluye dos instancias de RDS para Oracle. Una instancia fue precalentada mediante validación RMAN justo después de la restauración a partir de una instantánea, y la segunda instancia se mantuvo ejecutándose sin precalentamiento. Las instancias tenían la misma configuración, con una base de datos de 1000 GiB. La instantánea se restauró en ambas instancias y la validación de RMAN se ejecutó solo en una instancia.

Durante el precalentamiento con la validación RMAN, la métrica ReadLatency fue alta debido a la carga diferida. El proceso de validación de RMAN se completó en 60 minutos en la instancia precalentada (1000 GiB). El siguiente gráfico ilustra la ReadLatency y WriteLatency observadas durante el proceso de validación de RMAN en la instancia precalentada.

Una vez completada la validación de RMAN, se ejecutó una consulta SELECT en ambas instancias. En la instancia precalentada, la consulta SELECT se completó en 40 segundos. Por el contrario, la misma consulta SELECT, con la misma cantidad de IOPS físicas, se completó en 740 segundos en la instancia no precalentada.

Como se muestra en el siguiente gráfico de ReadLatency, la instancia no precalentada alcanzó hasta 75 milisegundos, mientras que la instancia precalentada solo tardó 2 milisegundos.

Conclusión

En esta publicación, describimos los diversos enfoques para minimizar la duración de la carga diferida dentro de su instancia de RDS para Oracle. También profundizamos en los pros y los contras de cada enfoque. Confiamos en que esta información haya ofrecido información valiosa sobre sus consultas sobre la carga diferida.

Su opinión es muy apreciada. Si tiene alguna pregunta o recomendación, compártala en la sección de comentarios.

Acerca de los autores

Vetrivel es un DBA de soporte en la nube en Amazon Web Services, especializado en cargas de trabajo de Amazon RDS, Amazon EBS y Oracle en la nube de AWS. Con más de 12 años de experiencia en TI, aprovecha su experiencia para ofrecer orientación y soporte técnico a los clientes, capacitándolos para crear soluciones resilientes, confiables y seguras dentro de la nube de AWS. Más allá de su vida profesional, las pasiones de Vetrivel incluyen viajar, descubrir nuevos destinos, saborear diversas cocinas y participar en actividades de aventura.

Anas es un DBA de soporte en la nube en Amazon Web Services. Está especializado en bases de datos relacionales, especialmente en arquitectura de bases de datos Oracle y ajuste de rendimiento. Anas tiene una amplia experiencia en diseño, implementación, optimización y automatización de bases de datos. Fuera del trabajo, a Anas le gusta hacer senderismo, montar en bicicleta y jugar al squash.

Traductor

Elkin es un Arquitecto senior de soluciones especialista en bases de datos en AWS localizado en Bogotá-COL, con una gran experiencia trabajando en compañías de alta tecnología, actualmente está ayudando a socios y organizaciones en Latinoamérica a diseñar, modernizar y adoptar servicios de la nube AWS.