Preguntas frecuentes sobre Oracle GoldenGate

Obtén respuestas a las preguntas más frecuentes sobre la implementación de IA de Oracle GoldenGate.

¿Por qué es importante Oracle GoldenGate para la IA empresarial?

Oracle GoldenGate es importante para la IA empresarial porque la IA depende de los datos empresariales actuales y de confianza. Los modelos, los sistemas RAG y los agentes de IA no pueden razonar ni actuar de forma fiable al trabajar a partir de instantáneas de lotes obsoletas o copias incompletas de datos operativos. GoldenGate transmite eventos empresariales a medida que ocurren, lo que brinda a los sistemas de IA acceso a una nueva realidad operativa, al tiempo que preserva la gobernanza, la coherencia y la auditabilidad.

¿Cómo admite Oracle GoldenGate los agentes de RAG e IA?

Oracle GoldenGate admite agentes de RAG e IA al entregar continuamente datos operativos en bases de datos vectoriales, pipelines de RAG, bases de conocimientos de IA, lakehouses y sistemas basados en eventos. Con las capacidades de IA de GoldenGate, los registros cambiados se pueden enriquecer, integrar, resumir, clasificar o enrutar como parte del pipeline, de modo que los sistemas de IA funcionen en el contexto empresarial actual en lugar de instantáneas obsoletas.

¿Cómo soporta GoldenGate los datos vectoriales?

Puede replicar vectores existentes, mover vectores a Oracle AI Database, transmitir cambios de vectores y generar incrustaciones durante la replicación.

¿Cuándo debo utilizar @AISERVICE?

Utilice @AISERVICE cuando la integración o el enriquecimiento se deban ejecutar en un servicio de IA externo, como un punto final gestionado o respaldado por GPU. Consulte Incrustación de IA externa con @AISERVICE

¿Cuándo debo utilizar @DBFUNCTION?

Utilice @DBFUNCTION al embeber la lógica que se debe ejecutar en la base de datos de destino como parte del procesamiento de aplicación. Consulte Incrustación de base de datos nativa con @DBFUNCTION

¿Cómo se deben manejar las cargas vectoriales históricas?

Utilice la instanciación masiva o la carga nativa de la base de datos para los datos históricos y, a continuación, deje que GoldenGate procese los cambios incrementales.

¿Cuáles son los principales casos de uso de Oracle GoldenGate?

Oracle GoldenGate se utiliza para una alta disponibilidad y recuperación ante desastres esenciales, migraciones sin tiempo de inactividad, análisis en tiempo real, ingestión de lakehouse, arquitecturas controladas por eventos, pipelines de IA y RAG, arquitecturas de tejido de datos y sincronización de datos controlada en entornos híbridos y multinube.

¿Soporta Oracle GoldenGate la migración de bases de datos de Oracle E-Business Suite (EBS) y la información de certificación de Oracle para EBS sigue siendo válida?

Oracle EBS no certifica ningún producto de replicación lógica para migraciones, sino que se centra en los métodos tradicionales de base de datos (importación/exportación, pump de datos de Oracle).

Aunque GoldenGate se puede utilizar para sustituir parte del trabajo realizado por estos métodos de base de datos tradicionales para reducir el tiempo de inactividad general asociado a una migración, no se debe utilizar en todos los objetos.

Los objetos que no son compatibles con GoldenGate o están relacionados con el trabajo temporal se deben migrar mediante métodos tradicionales durante una ventana de tiempo de inactividad.

¿La arquitectura de referencia de AWS para GoldenGate con EFS admite escenarios de DR entre regiones?

Consulte el blog de AWS Alta disponibilidad para la arquitectura de microservicios de Oracle GoldenGate en AWS, que describe un diseño de alta disponibilidad en la región.

En este contexto:

Para los escenarios de DR entre regiones, el comportamiento difiere significativamente:

Debido a estos factores, los patrones de diseño en la región descritos en el blog de AWS no se extienden directamente a la DR entre regiones sin consideraciones adicionales.

Recomendación:

Para arquitecturas entre regiones, utilice el movimiento de datos activo (por ejemplo, la ruta de distribución GoldenGate) en lugar de depender del almacenamiento compartido replicado de forma asíncrona para los archivos de pista.

¿Qué soportan las versiones GoldenGate de Oracle Database?

Para obtener más información, consulte https://www.oracle.com/integration/goldengate/certifications/.

¿Cuáles son los diferentes tipos de configuraciones y casos de uso de GoldenGate?

¿Cuáles son los componentes clave de GoldenGate?

¿Qué es Oracle GoldenGate y cuáles son sus principales casos de uso?

Oracle GoldenGate es una solución de integración y replicación de datos que captura, transforma y ofrece cambios transaccionales en varios sistemas heterogéneos en tiempo real.

Los casos de uso principales de Oracle GoldenGate son los siguientes:

¿Qué bases de datos y plataformas soporta Oracle GoldenGate?

Oracle GoldenGate soporta una amplia gama de bases de datos y destinos, incluidos:

Oracle GoldenGate puede capturar desde las aplicaciones SaaS y SaaS de Oracle Fusion que se ejecutan en OCI.

Oracle GoldenGate no se puede capturar desde Salesforce.com/SFDC.

Oracle GoldenGate puede replicar los cambios en Teradata y TimesTen, pero no puede capturar ninguno de los dos.

Se recomienda revisar las métricas de certificación GoldenGate para obtener soporte específico de base de datos y destino. Para obtener más información, consulte https://www.oracle.com/integration/goldengate/certifications/.

¿Cuáles son las diferencias entre la arquitectura clásica de Oracle GoldenGate y la arquitectura de microservicios?

Para obtener más información sobre MA, consulte Arquitectura de microservicios de Oracle GoldenGate.

¿Cómo se compara Oracle GoldenGate con otras herramientas de replicación?

Oracle GoldenGate es ideal para la integración de datos, la replicación de bases de datos, el movimiento de datos, las migraciones de bases de datos, la ingestión de datos en tiempo real debido a los siguientes motivos:

¿Cuáles son los requisitos para instalar Oracle GoldenGate en la base de datos XYZ?

Plataforma y compatibilidad

Modelo de despliegue

Configuración de la Base de Datos

Recursos de infraestructura y sistema

Almacenamiento

Red y puertos

Configuración de SO y usuario

Conectividad de Base de Datos

Requisitos específicos de los microservicios

Seguridad

Alta disponibilidad (opcional)

Disposición operativa

Para obtener más información sobre la preparación de bases de datos para Oracle GoldenGate, consulte Preparación de bases de datos.

¿Cuáles son las diferencias entre despliegues seguros y no seguros?

¿Cómo configuro los microservicios de Oracle GoldenGate mediante OGGCA?

Para obtener más información, consulte Agregar un despliegue y Agregar un despliegue en modo silencioso mediante OGGCA.

¿Cuáles son las mejores prácticas para optimizar el rendimiento de Oracle GoldenGate?

En el caso de los despliegues modernos de Oracle GoldenGate, el enfoque recomendado es utilizar Integrated Extract junto con Parallel Replicat, ya que Parallel Replicat es ahora el método de replicación estratégico y preferido para las operaciones de aplicación de destino de alto rendimiento.

Integrated Replicat se está eliminando gradualmente en favor de Parallel Replicat porque Parallel Replicat proporciona una mejor escalabilidad, un mejor rendimiento de aplicación de transacciones y un procesamiento paralelo más eficiente para cargas de trabajo empresariales de gran volumen.

Una arquitectura GoldenGate bien optimizada debe separar las etapas de captura, transporte y aplicación mediante el uso de archivos de pista locales y remotos, lo que mejora la resiliencia y aísla la replicación de las interrupciones de red. El rendimiento también depende en gran medida de la infraestructura subyacente, incluido el almacenamiento rápido, la memoria de la base de datos con el tamaño adecuado, la configuración eficaz de redo log y la conectividad de red estable.

La supervisión continua de la demora de Extract, la demora de Replicat, el rendimiento y la actividad de punto de control es esencial para identificar de forma proactiva los cuellos de botella antes de que afecten a la latencia de replicación.

En general, el mejor rendimiento de GoldenGate se logra mediante una combinación de diseño de arquitectura escalable, distribución adecuada de la carga de trabajo, ajuste de la base de datos y paralelismo cuidadosamente gestionado, lo que permite a las organizaciones mantener una latencia baja y una replicación fiable incluso en grandes cargas de trabajo transaccionales.

¿Cómo puedo supervisar la demora y solucionar los problemas de rendimiento?

¿Qué herramientas o comandos puedo utilizar para supervisar los procesos de Oracle GoldenGate?

En la arquitectura de microservicios de Oracle GoldenGate, la supervisión se realiza principalmente a través del servicio de administración basado en web, las API de REST y el servicio de métricas de rendimiento en lugar de las herramientas de arquitectura clásicas tradicionales como GGSCI. El servicio de administración proporciona paneles de control centralizados que permiten a los administradores supervisar el estado y el estado de los procesos de extracción, distribución, receptor y replicación paralela en tiempo real. A través de la interfaz web, los usuarios pueden realizar un seguimiento de la demora de replicación, el progreso del punto de control, las tasas de rendimiento, el estado de la ruta y el rendimiento del proceso en todo el despliegue. Las API de REST también proporcionan acceso programático a la supervisión de datos, lo que permite la integración con marcos de automatización y plataformas de observación empresarial.

Un componente clave de supervisión en la arquitectura de microservicios es el servicio de métricas de rendimiento (PMSRVR), que recopila y expone métricas operativas para procesos de replicación y rutas de distribución. Estas métricas se pueden integrar con soluciones de supervisión como Oracle Enterprise Manager, OCI Monitoring, Prometheus y Grafana para proporcionar paneles de control centralizados, alertas y análisis de rendimiento a largo plazo. Los administradores también confían en los logs de despliegue, los archivos de informe y la información de diagnóstico disponibles a través de las interfaces de Service Manager y Administration Service para solucionar errores, supervisar el comportamiento del proceso e investigar los problemas de latencia.

Para los despliegues de OCI GoldenGate, hay disponibles capacidades de supervisión adicionales a través de la consola de OCI, OCI Logging, OCI Monitoring y OCI Alarms, lo que proporciona visibilidad nativa de la nube sobre el estado del despliegue, el comportamiento de escalado, el retraso de replicación y los eventos operativos. En general, la supervisión en GoldenGate Microservices Architecture se centra en la observabilidad centralizada, la gestión basada en API y la integración con plataformas de supervisión empresarial para proporcionar estadísticas en tiempo real sobre el rendimiento de la replicación y el estado del sistema.

Los usuarios pueden crear sus propios paneles de control y supervisar la aplicación accediendo a las exportaciones de StatsD y a las llamadas de API.

¿Qué son los archivos de pista y cómo los utiliza Oracle GoldenGate en la replicación?

Los archivos de pista almacenan los cambios de datos capturados por el proceso de extracción en un formato independiente de la plataforma.

¿Cuál es el mejor tipo de Replicat recomendado?

Comience con Parallel Replicat: para la mayoría de los casos de uso, especialmente los que implican cargas de trabajo transaccionales de gran volumen, Parallel Non-Integrated Replicat ofrece el mejor rendimiento y flexibilidad.

GoldenGate Las aplicaciones distribuidas y los análisis soportan Classic y Coordinated Replicat.

Para GoldenGate para aplicaciones distribuidas y análisis, según el destino, Coordinated Replicat proporcionará un mejor rendimiento.

¿Cómo puedo configurar TLS/SSL para la replicación de datos segura?

¿Cuáles son las opciones para cifrar archivos de pista?

Para obtener más información sobre la protección de datos, consulte Secure Data at Rest en la documentación de microservicios de Oracle GoldenGate.

¿Cómo puedo integrar Oracle GoldenGate con proveedores de identidad externos (por ejemplo, IAM, OAM) para la propia autenticación de GoldenGate?

¿Cómo puedo migrar bases de datos sin tiempo de inactividad mediante Oracle GoldenGate?

Oracle GoldenGate permite migraciones de bases de datos casi sin tiempo de inactividad replicando continuamente los cambios transaccionales de la base de datos origen a la base de datos destino mientras ambos sistemas permanecen en línea. En lugar de requerir una larga ventana de interrupción para las actividades de exportación, importación y migración total, GoldenGate permite a las organizaciones sincronizar datos en tiempo real para que la migración total final se pueda completar con una interrupción mínima de la aplicación.

En una arquitectura de migración sin tiempo de inactividad típica, GoldenGate captura los cambios de la base de datos origen mediante Integrated Extract y los escribe en archivos de pista. A continuación, los cambios se transmiten a través de Distribution Services y se aplican a la base de datos de destino mediante Parallel Replicat. Mientras la carga de datos inicial se migra mediante la copia de seguridad/restauración, el pump de datos, la duplicación de RMAN u otros métodos de carga masiva, GoldenGate replica continuamente las transacciones en curso para que el destino permanezca sincronizado con el origen durante todo el proceso de migración.

El flujo de trabajo de migración suele seguir varias fases:

Durante la fase de carga inicial, se transfiere una copia completa de la base de datos al entorno de destino. Una vez cargados los datos de línea base, GoldenGate aplica todos los cambios transaccionales en curso capturados de la base de datos de origen. Esta replicación continua reduce significativamente la ventana de interrupción porque la base de datos de destino ya está casi sincronizada antes de que comience la migración total.

La validación de datos es una parte fundamental de las migraciones sin tiempo de inactividad. Oracle GoldenGate Veridata se suele utilizar para comparar las bases de datos de origen y destino durante la replicación a fin de garantizar la consistencia de los datos antes del switchover de producción. La validación continua ayuda a identificar las discrepancias con antelación y reduce el riesgo de migración.

En el momento de la migración total, la actividad de la aplicación se pausa brevemente, las transacciones restantes se pueden replicar y los administradores verifican que el retraso de replicación alcance cero. Una vez que se confirma la sincronización, las aplicaciones se redirigen a la base de datos de destino y el entorno de destino se convierte en el nuevo sistema de producción. Debido a que la mayoría de los movimientos de datos se produjeron mientras los sistemas estaban en línea, la ventana de interrupción real generalmente se reduce a solo el proceso final de sincronización y redirección de aplicaciones.

GoldenGate soporta migraciones sin tiempo de inactividad en:

En la moderna arquitectura de microservicios GoldenGate y los despliegues de OCI GoldenGate, la gestión de la migración se simplifica aún más a través de interfaces web centralizadas, API de REST, servicios de despliegue automatizados y capacidades de supervisión integradas. Los servicios de replicación paralela, captura integrada y distribución escalable ayudan a manejar grandes cargas de trabajo transaccionales de manera eficiente durante las actividades de migración.

En general, Oracle GoldenGate permite migraciones sin tiempo de inactividad al combinar la replicación continua en tiempo real, el procesamiento paralelo escalable, la validación continua y los procedimientos de migración total controlada, lo que permite a las organizaciones migrar bases de datos críticas con una interrupción mínima del negocio y un riesgo operativo reducido.

¿Cuáles son las mejores prácticas para configurar la replicación bidireccional?

Las mejores prácticas para configurar la replicación bidireccional con Oracle GoldenGate incluyen:

Los entornos de replicación bidireccional requieren una planificación cuidadosa porque son más complejos que la replicación unidireccional y pueden presentar desafíos como:

¿Qué significa cuando Replicat muestra transacciones "atascadas" y cómo puedo solucionarlas?

Cuando Replicat muestra transacciones "paradas", normalmente significa que el proceso de Replicat no puede aplicar una o más transacciones en la base de datos de destino y el progreso de replicación se detiene o se retrasa.

Las causas comunes incluyen:

Los pasos típicos de resolución de problemas incluyen:

En algunos casos, los administradores pueden necesitar:

según el caso, la gravedad y los requisitos de negocio.

¿Cómo gestiono el espacio en disco y depuro los archivos de pista antiguos en microservicios?

En la arquitectura de microservicios de Oracle GoldenGate, la gestión del espacio en disco y la depuración de archivos de pista son importantes para evitar el agotamiento del almacenamiento y mantener entornos de replicación en buen estado.

Los archivos de pista se gestionan normalmente mediante políticas de depuración automatizadas que eliminan archivos de pista antiguos una vez que los procesos descendentes ya no los necesitan.

Las prácticas comunes incluyen:

Normalmente, los archivos de pista se pueden depurar cuando:

En los microservicios, la gestión de pistas se suele gestionar mediante:

Las recomendaciones adicionales incluyen:

La gestión adecuada de la pista ayuda a evitar:

¿Cómo puedo configurar el inicio y el reinicio automáticos en microservicios?

En la arquitectura de microservicios de Oracle GoldenGate, el inicio automático y el reinicio automático se pueden configurar para iniciar y recuperar automáticamente servicios de despliegue y procesos de replicación después de fallos o reinicios del servidor.

Normalmente se configura mediante:

La configuración de reinicio automático ayuda a garantizar una alta disponibilidad mediante el reinicio automático de los procesos fallidos sin intervención manual.

Las opciones comunes de configuración incluyen:

Esta configuración se puede gestionar normalmente mediante:

El inicio y el reinicio automáticos se suelen utilizar en:

¿Cuáles son los pasos de solución de problemas para la demora de replicación?

Entre los pasos comunes de solución de problemas para la demora de replicación de Oracle GoldenGate se incluyen:

El análisis de demora de replicación generalmente se centra en identificar si el cuello de botella es causado por:

¿Cómo puedo utilizar GoldenGate para flujos de datos distribuidos y dualidad relacional JSON?

¿Cuáles son las opciones avanzadas para la transformación de datos en GoldenGate?

¿Se puede ejecutar GoldenGate en z/OS para capturar cambios desde o entregar cambios a Db2 para zOS?

Si solo ejecuta Replicat en Db2 z/OS, este paquete no es necesario.

¿Tiene GoldenGate para Db2 para i y Db2 LUW arquitectura de microservicios?

¿Proporciona GoldenGate controladores ODBC en Db2 para i/Db2 para la instalación de compilación de z/OS de LUW/Db2?

No, el usuario final tendrá que instalar los controladores ODBC adecuados mediante su propio acuerdo de licencia con IBM para esos controladores ODBC si aún no están instalados en el servidor donde se está instalando GoldenGate. Consulte la guía del usuario del controlador ODBC de IBM sobre cómo descargar los controladores ODBC adecuados.

¿Cómo puedo ejecutar GoldenGate en Docker Container?

Oracle GoldenGate se puede ejecutar en contenedores de Docker mediante el despliegue del software GoldenGate como un servicio en contenedores. Oracle proporciona imágenes de contenedor GoldenGate a través de Oracle Container Registry (OCR), lo que permite a los usuarios extraer y desplegar imágenes predefinidas para una configuración más rápida y entornos estandarizados.

La ejecución de GoldenGate en contenedores proporciona ventajas como:

GoldenGate La arquitectura de microservicios suele ser preferida para despliegues de contenedores porque está diseñada para entornos distribuidos modernos y funciona bien con las plataformas de orquestación de Docker y Kubernetes.

Los despliegues de GoldenGate en contenedores se suelen utilizar en:

El almacenamiento persistente se suele configurar de forma externa para retener las pistas, los puntos de control y los datos de configuración fuera del ciclo de vida del contenedor.

¿Qué es OCI GoldenGate?

Oracle Cloud Infrastructure (OCI) GoldenGate es una plataforma Data Fabric totalmente gestionada y nativa de la nube que permite el movimiento, la integración y la transmisión de datos en tiempo real en entornos heterogéneos a escala empresarial. Captura y ofrece cambios transaccionales en los datos con baja latencia entre bases de datos, almacenes de datos, plataformas de análisis, sistemas de mensajería y servicios en la nube.

Como componente central de una estrategia moderna de Data Fabric, OCI GoldenGate ayuda a las organizaciones a conectar, sincronizar y poner en funcionamiento datos distribuidos en entornos locales, híbridos y multinube. Admite una amplia gama de casos de uso que incluyen replicación de datos en tiempo real, migraciones sin tiempo de inactividad, informes operativos, arquitecturas controladas por eventos, análisis de transmisión, pipelines de datos de IA/ML y sincronización de datos.

OCI GoldenGate también proporciona capacidades integradas para diseñar, orquestar, supervisar, transformar, validar y comparar pipelines de datos a través de una experiencia de usuario unificada e intuitiva.

¿En qué regiones está disponible OCI GoldenGate?

Consulte aquí las regiones actuales en las que OCI GoldenGate está desplegado: https://www.oracle.com/cloud/data-regions/

¿Dónde puedo encontrar la documentación de OCI GoldenGate?

La documentación de OCI GoldenGate está disponible en: https://docs.oracle.com/en/cloud/paas/goldengate-service/index.html

¿Cuáles son los casos de uso clave para OCI GoldenGate?

Entre los casos de uso clave para OCI GoldenGate se incluyen:

¿Cuáles son las diferencias entre OCI GoldenGate y GoldenGate en OCI Marketplace?

Aquí hay un par de diferencias entre las dos ofertas:

¿Dónde puedo encontrar los objetivos de nivel de servicio (SLO) y los acuerdos de nivel de servicio (SLA)?

Utilice el documento actual del pilar del servicio en la nube pública PaaS y IaaS de Oracle y la página actual del SLA de Oracle Cloud:

https://www.oracle.com/cloud/sla/.

¿Cuál es el costo de OCI GoldenGate?

OCI GoldenGate se tarifica por las OCPU que consume el host GoldenGate de OCI. La métrica de OCPU por hora sigue la definición estándar:

También puede consultar Cloud Estimator, que incluye OCI GoldenGate en la categoría Data Integration: https://www.oracle.com/cloud/costestimator.html

¿Cómo funciona la licencia BYOL?

Relaciones de conversión:

Cualquiera de las siguientes licencias de Programa con soporte puede agregarse para cumplir el ratio de conversión anterior:

¿Puedo migrar mi GoldenGate Marketplace a OCI GoldenGate?

¿Cómo puedo ajustar el tamaño adecuado de OCI GoldenGate?

OCI GoldenGate utiliza una arquitectura de hub.

Nota:

¿Qué orígenes y destinos están soportados en OCI GoldenGate?

Para obtener información sobre los sistemas de origen y destino soportados, consulte Explore Connections.

¿Puede OCI GoldenGate conectarse a IP privadas o sistemas locales de Oracle?

Sí. Para obtener más información sobre la conectividad, consulte Conectividad GoldenGate de OCI.

La conectividad de OCI GoldenGate al origen y al destino está activada con la captura remota y la entrega remota.

¿Cómo puedo configurar una ruta de distribución entre OCI GoldenGate y GoldenGate que se ejecute en OCI Marketplace o localmente?

En la siguiente LiveLabs se describe cómo crear rutas de distribución entre OCI-GG y una instalación de microservicios de GG:

¿OCI GoldenGate soporta bases de datos Oracle de instancia única?

Sí, tanto las instancias conectables (multiinquilino) como las únicas están soportadas.

¿Se admiten bases de datos autónomas dedicadas?

Sí, los entornos de Autonomous AI Database on Dedicated Infrastructure están totalmente soportados.

Consulte la documentación actual de Autonomous AI Database y OCI GoldenGate para conocer los requisitos exactos: Oracle Autonomous AI Database

¿Puedo acceder a OCI GoldenGate y controlarlo con Oracle Management Cloud y Oracle Enterprise Manager (OEM)?

Management Pack para GoldenGate ahora soporta OCI GoldenGate.

¿Qué es Oracle GoldenGate Foundation Suite?

Oracle GoldenGate Foundation Suite es un paquete de tres productos. Incluye:

¿Qué es Oracle GoldenGate Veridata?

Oracle GoldenGate Veridata es una solución de reparación y comparación de datos de alta velocidad que identifica, informa y corrige discrepancias de datos entre bases de datos heterogéneas sin interrumpir automáticamente los procesos de negocio en curso. Proporciona una solución fácil de usar pero potente para identificar datos no sincronizados antes de que afecte negativamente a la empresa.

¿Cuáles son los distintos componentes de Oracle GoldenGate Veridata?

Los distintos componentes de Oracle GoldenGate Veridata son:

¿Cómo se realiza la comparación de datos en tiempo real con Oracle GoldenGate Veridata?

Oracle GoldenGate Veridata realiza una comparación de datos en tiempo real comparando las bases de datos de origen y destino mientras se ejecuta la replicación de Oracle GoldenGate.

Este es el proceso general:

  1. GoldenGate replica los cambios transaccionales de la base de datos origen a la base de datos destino casi en tiempo real.

  2. Veridata se conecta de forma independiente a las bases de datos de origen y destino.

  3. Compara los datos en fragmentos configurables o rangos de filas mediante:

    • claves primarias
    • hashes/checksums
    • validación fila por fila cuando se detectan discrepancias

  4. Veridata identifica:

    • filas faltantes
    • filas adicionales
    • valores de columna cambiados
    • transacciones no sincronizadas

  5. Los trabajos de comparación se pueden ejecutar de forma repetida o continua mientras la replicación permanece activa, lo que permite una validación continua con un impacto mínimo en los sistemas de producción.

Para evitar el bloqueo de tablas o la interrupción de la replicación, Veridata utiliza técnicas de comparación optimizadas, como:

Esto permite a las organizaciones validar que los datos replicados permanecen sincronizados durante:

Veridata no replica datos, valida la precisión de la replicación GoldenGate casi en tiempo real.

Para obtener información sobre la comparación de datos en tiempo real mediante Oracle GoldenGate Veridata, consulte Oracle GoldenGate Veridata 26c: ¿Cómo funciona?

¿Cómo puedo cambiar el tamaño de Oracle GoldenGate Veridata?

Para obtener información sobre el tamaño de Oracle GoldenGate Veridata, consulte Cómo cambiar el tamaño de Oracle GoldenGate Veridata.

¿Para qué se utiliza la base de datos del repositorio de Veridata?

Toda la información de metadatos (es decir, todas las configuraciones de Veridata) se almacenará en la base de datos del repositorio de Veridata.

Veridata 26c incluye una base de datos MySQL incorporada como repositorio.

Sin embargo, el cliente tiene la opción de utilizar esta base de datos MySQL incorporada o su propia base de datos MySQL para el repositorio.

¿Cuál sería el tamaño de la base de datos del repositorio de Veridata?

Toda la información de metadatos de Veridata se almacenará en esta base de datos del repositorio.

Por lo tanto, no sería de gran tamaño. Un máximo de 5 GB sería el tamaño del repositorio.

¿Se puede utilizar Oracle GoldenGate Veridata para comparar datos entre bases de datos heterogéneas?

Sí, Oracle GoldenGate Veridata es una solución heterogénea de comparación y reparación de datos.

Compruebe la siguiente matriz de certificación enlazada:

https://www.oracle.com/in/a/ocom/docs/ogg-veridata-23c-cert-matrix.xlsx

¿Podemos comparar las DDL de la tabla mediante Oracle GoldenGate Veridata?

No, Oracle GoldenGate Veridata es una herramienta de comparación de datos y solo puede comparar datos entre tablas. Sin embargo, lo tenemos en nuestra hoja de ruta.

¿Puede Oracle GoldenGate Veridata supervisar la replicación de datos entre orígenes y destinos en tiempo real?

Sí, Oracle GoldenGate Veridata puede supervisar y validar la replicación de datos entre las bases de datos de origen y destino casi en tiempo real. Compara continuamente los datos mientras se ejecuta la replicación de GoldenGate e identifica discrepancias, como filas faltantes, filas adicionales o discrepancias de datos.

Esto garantiza que las bases de datos replicadas permanezcan sincronizadas durante las migraciones, las actualizaciones y las operaciones de replicación en curso, con un impacto mínimo en los sistemas de producción.

¿Necesitamos instalar Veridata Server para cada base de datos de origen y destino?

No, una instalación de Veridata es suficiente para comparar datos entre varios orígenes y destinos.

No es necesario instalar servidores Veridata dedicados a cada base de datos de origen y destino.

¿Qué es Veridata Agent? ¿Cómo se debe configurar?

Veridata Agent es un programa Java ligero que se encarga de recuperar datos de las tablas de la base de datos de origen y destino.

Debe configurar un agente dedicado para cada base de datos.

Por ejemplo, si tiene 5 orígenes y destinos, debe configurar 5 agentes de Veridata para 5 orígenes y 5 agentes de Veridata para 5 destinos.

¿Dónde necesitamos instalar y desplegar los agentes de Veridata?

Los agentes de Veridata se pueden desplegar tanto nativos como remotos en los servidores de base de datos. Cuando configura agentes de Veridata de forma remota, debe asegurarse de tener una buena red entre los agentes de Veridata y las bases de datos de origen/destino.

¿Dónde se encuentra el archivo Veridata Agent Properties?

Se puede encontrar en la ruta de acceso < AGENT_HOME > con el nombre "agent.properties".

¿Dónde está presente el archivo de configuración del servidor Veridata?

El archivo de configuración del servidor Veridata está presente en la siguiente ruta:

/config/veridata/veridata.cfg

¿Dónde está presente el archivo oggvdt_cainput.properties?

El archivo oggvdt_cainput.properties está presente en la siguiente ruta:

/config/oggvdt_cainput.properties

¿Dónde puedo encontrar los informes de Veridata?

Los informes de Oracle GoldenGate Veridata normalmente se generan y almacenan en el host del servidor de Veridata en el directorio de instalación de Veridata.

Las ubicaciones predeterminadas suelen ser:

También puede acceder a informes desde la interfaz de usuario web de Veridata:

  1. Inicie sesión en la consola de Veridata.
  2. Abra el trabajo de comparación.
  3. Vaya a Informes o Detalles del trabajo → Informes.
  4. Descargue salidas HTML, XML o PDF, según la configuración.

Los tipos de informe comunes incluyen:

Si utiliza Veridata con microservicios de OGG o despliegues de OCI, los informes se pueden escribir en:

Puede verificar la ruta exacta del informe en:

<VERIDATA_HOME>/cfg/veridata.cfg

o las propiedades de inicio/configuración del servidor.

¿Podemos tener varios agentes de Veridata para una base de datos?

Sí, pero recomendamos 1 agente para 1 base de datos.

¿Cuántos pares de comparación puedo crear en un grupo?

No hay ninguna restricción en el número de pares de comparación que se pueden crear. Cualquier número está bien.

¿Cuántos pares de comparación puedo ejecutar en paralelo en Veridata?

El valor por defecto máximo es 100.

Pero se puede actualizar desde el archivo veridata.cfg cambiando el valor de maxconcurrentjobs.

¿Solo se pueden comparar datos incrementales o modificados a diario en Veridata?

Sí, Veridata tiene una función llamada Comparación Delta.

Una vez habilitada esta función, solo se compararán los datos modificados.

¿Qué es la comparación Delta en Veridata?

Los pares de comparación se pueden configurar para utilizar el procesamiento delta, una función de rendimiento que compara solo los bloques de datos que han cambiado desde la última ejecución, en lugar de explorar toda la tabla.

Esto evita la comparación de todos los datos históricos una y otra vez y sólo compara los datos modificados.

¿Cómo habilito la comparación Delta en Veridata?

En Oracle GoldenGate Veridata 26c, Delta Comparison está más alineada con el moderno modelo de "validación continua de datos" en lugar de con las explicaciones de procesamiento delta de estilo clásico más antiguas de la documentación heredada. La función está diseñada para reducir la sobrecarga de comparación centrándose solo en los datos modificados entre ciclos de comparación, lo que es especialmente importante para la validación continua en entornos de replicación activa-activa, híbrida y a gran escala.

En Veridata 26c, la comparación delta se activa mediante la interfaz de usuario web de Veridata modernizada al configurar pares de comparación y trabajos. En lugar de depender en gran medida de los flujos de trabajo de línea de comandos heredados, los administradores configuran el comportamiento de comparación directamente en la interfaz de usuario o mediante las API de REST. El proceso suele implicar la activación de la validación basada en delta dentro de la configuración de pares de comparación, por lo que Veridata realiza un seguimiento de los cambios entre ejecuciones y limita las comparaciones futuras con los juegos de datos modificados. Esto reduce el impacto de la base de datos y mejora el rendimiento de comparación para casos de uso de validación continua.

La arquitectura 26c también hace hincapié en:

en lugar de modelos de ejecución de comparación independientes más antiguos.

Además, Veridata 26c presenta capacidades nativas de programación y automatización mejorada directamente en la interfaz de usuario y las API, lo que hace que Delta Comparison esté más integrada operativamente en la validación continua del estado de la replicación en lugar de tratarse como una función de optimización manual.

¿Qué versión del plugin de Oracle Enterprise Manager está certificada para supervisar los despliegues de Oracle GoldenGate 26ai Microservices?

La supervisión y detección de Oracle GoldenGate 26ai Microservices en Enterprise Manager 24ai está certificada con Oracle GoldenGate EM Plugin versión 13.5.2.0.6.

¿Por qué los niveles de parches recomendados de Oracle AI Database y GoldenGate son importantes para la estabilidad y la compatibilidad?

Oracle recomienda ejecutar Oracle GoldenGate con las actualizaciones de versión (RU) de Oracle Database recomendadas actualmente y los paquetes de parches GoldenGate.

Los niveles de parches de bases de datos más antiguos pueden exponer a los clientes a:

Práctica recomendada:

Siga las últimas novedades:

Valide las correcciones antes de asumir defectos de productos en los niveles de parches anteriores.

Nota principal para juegos de parches de productos principales de Oracle GoldenGate (KB159960)

¿Admite Oracle GoldenGate y OCI GoldenGate la captura de datos de cambios desde MongoDB?

Oracle GoldenGate y OCI GoldenGate soportan la captura de datos de cambios desde MongoDB y MongoDB Atlas. Soporta la replicación bidireccional entre diferentes bases de datos MongoDB.

¿Puedo utilizar Oracle GoldenGate y OCI GoldenGate para migraciones de MongoDB a Oracle AI Database?

Sí, Oracle GoldenGate no admite migraciones de tiempo de inactividad de MongoDB a Oracle AI Database. Puede consultar la documentación de Oracle GoldenGate para obtener más información.

¿Cómo puedo configurar las migraciones de Oracle GoldenGate para migrar de MongoDB a Oracle AI Database?

Asegúrese de cumplir los siguientes requisitos previos:

Siga estos pasos para migrar MongoDB a Oracle AI Database for Oracle GoldenGate:

  1. Ejecute la utilidad de volcado MongoDB. Ejecute el comando mongodump con la opción --oplog para crear una instantánea de la base de datos MongoDB de origen:

    $ ./bin/mongodump --uri="mongodb://localhost:27021" --oplog -v

  2. Ejecute el script OplogLSN.sh para extraer el primer y el último registro de hora de la operación del archivo oplog.bson proporcionando la ruta al archivo oplog.bson como argumento de la siguiente manera:

    $./oplogLSN.sh /path/to/dump/oplog.bson

    La salida proporciona los registros de hora de la primera y última operación (o el primer noop si no se ha producido ninguna operación durante el proceso de volcado).

    Salida:

    2025-02-27T13:53:00.885+0000 1 objects found First LSN: 1740663867.1 Last LSN: 1740663946.211 3

  3. Inspeccionar entradas de carga: si hubo alguna operación entrante durante el volcado, el archivo oplog.bson contiene entradas para esas operaciones, cada una con un registro de hora. Puede utilizar OplogLSN.sh para capturar el primer y el último registro de hora de la operación o convertirlo en un archivo JSON para inspección manual, como se muestra en el paso anterior.

  4. Ejecute la utilidad de restauración MongoDB: después de tener los registros de hora necesarios, utilice la utilidad mongorestore para restaurar las recopilaciones seleccionadas del volcado a la instancia de destino MongoDB:

    $ ./mongorestore --uri="mongodb://localhost:27021" --nsInclude=testDB.coll1 --nsInclude=testDB.coll2 /path/to/dump -v

  5. Inicie el Extract CDC MongoDB: inicie el proceso Extracción CDC MongoDB desde el primer registro de hora de operación (posición LSN) extraído del archivo oplog.bson. Esto asegurará que la extracción de CDC comience a capturar las operaciones que se producen después de que se inició el proceso de volcado.

  6. Configure MongoDB Replicat con el archivo de pista CDC generado y defina la propiedad oplogReplayLastLsn en el último registro de hora de la operación desde el archivo oplog.bson. Esto garantiza que Replicat se ejecute en modo oplog-replay, evitando cualquier colisión. Una vez procesado el último registro de hora, continúa en modo normal. Esta configuración garantiza un inicio preciso, sin pérdida ni duplicación de datos, y elimina la necesidad de un manejo costoso de colisiones en el Replicat.

¿Cómo puedo ejecutar cargas iniciales de Snowflake a Oracle AI Database?

  1. Cree una extracción de captura de datos de cambio (desde el origen de Oracle AI Database).

  2. Obtener SCN de la base de datos origen.

  3. Cree una extracción de carga inicial (a partir de Oracle AI Database de origen).

  4. Cree una ruta de distribución para el extracto de CDC.

  5. Cree una ruta de distribución para la extracción de carga inicial.

  6. Cree un Replicat para la carga inicial (destino de Snowflake).

  7. Cree un Replicat para la replicación de captura de datos de cambio (destino de Snowflake).

Qué debo hacer para corregir "Excepción: net.snowflake.client.jdbc.SnowflakeReauthenticationRequest: El token de autenticación ha caducado. El usuario debe volver a autenticarse". ¿Error en la replicación de Snowflake de Oracle GoldenGate?

Este error se produce cuando hay períodos prolongados de inactividad. Para resolver este problema, puede definir el parámetro JDBC CLIENT_SESSION_KEEP_ALIVE para forzar al usuario de la base de datos a conectarse después de un período de inactividad.

snowflakecomputing.com/?warehouse=<warehouse-name>&db=<database-name>&CLIENT_SESSION_KEEP_ALIVE=true

¿Soporta Oracle GoldenGate y OCI GoldenGate la replicación DDL en Snowflake?

Oracle GoldenGate se puede configurar para propagar los cambios de DDL de origen a las tablas de Snowflake de destino. La evolución automática de esquemas es la capacidad de detectar, gestionar y aplicar cambios a un esquema de base de datos, como tablas, columnas, índices o relaciones, sin necesidad de intervención manual. La evolución automática de esquemas soporta la detección de nuevos objetos y cambios de metadatos y, a continuación, la generación automática de DDL de destino para la evolución del esquema.

Para la carga inicial, puede crear o sustituir tablas de destino.

Para CDC Replicat, puede crear o modificar tablas de destino durante la aplicación continua. Para obtener más información, consulte la documentación de Oracle GoldenGate.

¿Puedo utilizar Oracle GoldenGate y OCI GoldenGate para la replicación de Apache Iceberg?

Sí, Oracle GoldenGate admite la replicación de datos en tiempo real en Apache Iceberg. Oracle GoldenGate utiliza la API de Java de Apache Iceberg para los lakehouses de Apache Iceberg abiertos. Oracle GoldenGate admite catálogos de Oracle AI Data Catalog, Amazon Glue, Polaris, Nesti, Hadoop y REST.

¿Puedo utilizar Oracle GoldenGate y OCI GoldenGate para la replicación de datos en tiempo real en tablas de Apache Iceberg en OCI Object Storage?

Sí, Oracle GoldenGate y OCI GoldenGate se pueden configurar para la replicación de datos en tiempo real en tablas de Apache Iceberg almacenadas en OCI Object Storage mediante el punto final de API S3 de OCI Object Storage. Consulte Creación de un lakehouse de Apache Iceberg en tiempo real en OCI Object Storage con OCI GoldenGate para obtener más información.

¿Admite la replicación Apache Iceberg de Oracle GoldenGate y OCI GoldenGate tanto la fusión durante la escritura?

Sí, Oracle GoldenGate y OCI GoldenGate soportan la fusión en escritura para tablas Iceberg gestionadas por Snowflake, Google BigQuery y Databricks. En estas plataformas, GoldenGate utiliza los recursos informáticos de la plataforma de destino para la compactación.

¿Cómo pueden Oracle GoldenGate y OCI GoldenGate manejar actualizaciones de clave primaria en tablas de parquet en OCI Object Storage?

Oracle GoldenGate y OCI GoldenGate manejan actualizaciones de clave primaria en tres modos. Este comportamiento se controla agregando gg.handler.name.format.pkUpdateHandling al archivo de propiedades de Replicat. Los valores admitidos incluyen fin anormal, actualización e inserción de supresión. El fin anormal es el comportamiento predeterminado. El Replicat falla cuando se detecta una actualización de clave primaria y registra el error en el archivo de informe. La actualización trata la actualización de clave primaria como cualquier otra operación de actualización. Utilice este valor sólo si puede garantizar que la clave primaria no se utiliza como criterio de selección.

Delete-insert replica la actualización de clave primaria como dos registros: uno con la imagen anterior, marcado como supresión y otro con la imagen posterior, marcado como inserción.

Para utilizar delete-insert, el proceso Extract debe capturar registros de datos de cambio sin comprimir, lo que significa que todas las columnas se escriben en el archivo de pista.

Para generar registros sin comprimir, utilice LOGALLSUPCOLS para orígenes de Oracle AI Database y COMPRESSUPDATES | NOCOMPRESSUPDATES para bases de datos que no sean de Oracle.

Por ejemplo, al replicar en OCI Object Storage, defina gg.handler.<gg.target value>.format.pkUpdateHandling=delete-insert para replicar las actualizaciones de clave primaria como un registro de supresión con la imagen anterior y un registro de inserción con la imagen posterior.

¿Cómo puedo replicar las columnas DATE y TIMESTAMP de Oracle en tablas de parquet almacenadas en OCI Object Storage con Oracle GoldenGate?

Las columnas DATE y TIMESTAMP de Oracle se replican como cadenas por defecto cuando no se configura ninguna asignación explícita. Sin una asignación adecuada, los motores descendentes no reconocerán estas columnas como tipos date/time, lo que hace que la fecha sea aritmética, el filtrado de rangos y la partición basada en tiempo imposible sin una conversión explícita. La propiedad enableTimestampLogicalType permite la asignación de columnas DATE y TIMESTAMP de Oracle al tipo lógico Avro timestamp-micros, que representa valores en microsegundos desde la época, la representación correcta para cargas de trabajo analíticas y de lago de datos.

En la replicación de Oracle GoldenGate Cloud Object Storage, los tipos de origen DATE y TIMESTAMP se asignan a archivos Avro (incluidos Parquet, Iceberg y Delta) como STRING por defecto.

Para replicar los tipos de origen DATE y TIMESTAMP como tipo lógico timestamp-micros en archivos Avro (incluidos Parquet, Iceberg y Delta), defina gg.handler.<gg.target value>.format.enableTimestampLogicalType en true.

Cuando el tipo lógico de registro de hora está activado, gg.format.timestamp también es necesario. Por ejemplo: gg.handler.oci.format.enableTimestampLogicalType= truegg.format.timestamp=yyyy-MM-dd HH:mm:ss.SSSSSS

¿Cómo puedo mejorar el rendimiento de replicación de Oracle GoldenGate OCI Object Storage?

El rendimiento de la replicación de Oracle GoldenGate Cloud Object Storage se puede ajustar mediante dos funciones clave: el tipo de replicación y el parámetro GROUPTRANSOPS. Además del tipo de Replicat y la agrupación de transacciones, el tamaño de los archivos producidos por el Replicat afecta directamente al rendimiento y se debe ajustar junto con el resto de la configuración. Oracle GoldenGate Distributed Applications and Analytics proporciona dos modos de replicación diferentes: Classic Replicat y Coordinated Replicat.

Classic Replicat es un proceso de un solo thread que aplica los mensajes a los servicios de almacenamiento en la nube de destino. Coordinated Replicat es un proceso multithread en el que varios threads leen el archivo de pista de OGG de forma independiente y aplican transacciones en paralelo. El proceso de replicación de Oracle GoldenGate Cloud Object Storage optimiza el procesamiento con la agrupación de transacciones. El parámetro GROUPTRANSOPS agrupa varias transacciones pequeñas en una única transacción más grande aplicada a destinos de almacenamiento en la nube. GROUPTRANSOPS está configurado en el archivo de parámetros. Por defecto, GROUPTRANSOPS se define en 1000. Puede aumentar hasta 20000 para obtener un mejor rendimiento.

Por ejemplo: GROUPTRANSOPS 20000

¿Cómo puedo definir el tamaño de archivo en la replicación de Google Cloud Storage de Oracle GoldenGate y OCI GoldenGate?

La réplica de Oracle GoldenGate crea un archivo en el sistema de archivos local y lo mantiene abierto hasta que se cumpla o se dispare una condición de renovación por un evento de cambio de metadatos del origen (como el cambio DDL). Los usuarios pueden controlar la renovación de archivos mediante las propiedades de replicación. El tamaño máximo de archivo controla los tamaños de archivo. Por defecto, los tamaños de archivo se configuran en 1 GB, pero se pueden configurar según sea necesario. Cuando se alcanza el tamaño máximo, el archivo se cierra y se genera un nuevo archivo. Para obtener más información, consulte Configuración del manejador del escritor de archivos en la documentación de Oracle GoldenGate for DAA.

¿Soporta Oracle GoldenGate y OCI GoldenGate la partición con replicación de archivos de parquet en Google Cloud Storage?

Oracle GoldenGate y OCI GoldenGate soportan la creación de archivos particionados en cubos de almacenamiento de objetos de destino. La partición mejora la depuración descendente y el rendimiento de las consultas, pero la partición en exceso aumenta el recuento de directorios/archivos y amplifica el problema de los archivos pequeños.

Para utilizar la partición, la tabla debe particionar los datos en el nivel más alto. Para ello, se utiliza la propiedad pathMappingTemplate y se debe definir en el nombre de tabla totalmente cualificado.

Creará directorios dentro del contenedor o bloque en función del nombre completo de la tabla de origen. Por ejemplo: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}

Para crear particiones, se utiliza gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name>. Esta propiedad se puede utilizar con la palabra clave de plantilla, como ${columnValue[column_name]} o valores de cadena constante, para definir la estructura de ruta de partición.

¿Oracle GoldenGate y OCI GoldenGate admiten la replicación DDL en archivos de parquet en Azure Data Lake Storage (ADLS)?

La replicación de ADLS de Oracle GoldenGate y OCI GoldenGate propaga los cambios de DDL de origen automáticamente a los archivos generados. También se puede utilizar EVENTACTIONS para controlar el comportamiento de Extract/Replicat en caso de una operación DDL en la base de datos de origen.

Si la extracción de Oracle GoldenGate captura un evento Crear tabla de la base de datos origen, Replicat creará un nuevo archivo con el nombre de tabla del evento Crear tabla en el contenedor o cubo de almacenamiento de objetos en la nube de destino.

Si la extracción de Oracle GoldenGate captura un evento Alter Column/Drop Column de la base de datos origen, Replicat creará un nuevo archivo que refleje la definición de tabla de origen actualizada.

Si la extracción de Oracle GoldenGate captura un evento Truncar de la base de datos origen, puede configurar Replicat para que realice un rollback del archivo de datos en el evento Truncar definiendo:

gg.eventhandler.<gg.target value>.rollOnTruncate=true

Esta propiedad se define en false por defecto y Replicat no arrastra el archivo en el evento Truncate. La extracción de Oracle GoldenGate captura un evento de borrado de tabla de la base de datos origen, lo que no afecta al sistema de archivos de destino.

¿Cómo manejan Oracle GoldenGate y OCI GoldenGate el tipo de datos NÚMERO de Oracle de origen mientras se replican en archivos de parquet en Azure Data Lake Storage (ADLS)?

Oracle NUMBER es un tipo de dato decimal de precisión variable que puede representar números enteros y valores decimales de punto fijo con hasta 38 dígitos de precisión.

Si una columna se define sin una precisión y una escala explícitas (por ejemplo, NUMBER), Oracle puede almacenar valores con una escala variable entre filas y, en algunos escenarios de replicación/generación de esquema, puede que el formateador no pueda derivar de forma determinista una única precisión/escala para el esquema de destino. Como resultado, las asignaciones a Avro/Parquet suelen utilizar una representación decimal conservadora a menos que configure explícitamente la precisión y la escala para que coincidan con las definiciones de columna de origen.

gg.handler.<gg.target value>.enableDecimalLogicalType es el conmutador maestro para la asignación de tipo lógico decimal. Cuando se define en true, indica al formateador de Avro que asigne columnas NUMBER de Oracle al tipo lógico decimal de Avro (bytes con logicalType: decimal) en lugar de la asignación predeterminada que escribe números como primitivos numéricos o cadenas simples de Avro.

Cuando la precisión/escala no se puede inferir determinísticamente, el formateador generalmente elige una definición decimal de Avro conservadora (alta precisión y escala) para evitar la pérdida de precisión. Esto puede llevar a que los consumidores intermedios vean valores expresados con una escala innecesariamente grande (por ejemplo, dígitos fraccionarios finales aparentes).

Para alinear el esquema de destino con las definiciones de origen conocidas y coherentes, especialmente para los datos financieros (balances, precios, importes):

set gg.handler.<gg.target value>.maxPrecision y gg.handler.<gg.target value>.oracleNumberScale.

¿Qué métodos de autenticación ADLS soportan Oracle GoldenGate y OCI GoldenGate?

Oracle GoldenGate y OCI GoldenGate soportan claves de acceso, firma de acceso compartido e ID de Azure Entra.

¿Oracle GoldenGate admite tablas de Amazon S3?

Sí, Oracle GoldenGate admite la replicación en tiempo real de Apache Iceberg en tablas de Amazon S3 mediante catálogos REST de tablas de Amazon S3.

¿Admite Oracle GoldenGate y OCI GoldenGate cargas de varias partes en Amazon S3?

Sí, habilitar la función de carga en varias partes de Amazon S3 permite cargar los archivos grandes en Amazon S3 dividiéndolos en partes pequeñas que se pueden cargar de forma independiente y en paralelo. Esta función resuelve las limitaciones ya conocidas de Amazon S3, como la carga única de objetos de tamaño superior a 5 GB. Una vez que todas las partes del archivo se han cargado correctamente, se realiza una solicitud a Amazon S3 para ensamblarlas en un solo objeto. Para utilizar esta función, debe habilitar gg.eventhandler.s3.multipartEnabled=true en la réplica de Amazon S3.

¿Soporta Oracle GoldenGate y OCI GoldenGate la partición con replicación de archivos de parquet en Google Cloud Storage?

Oracle GoldenGate y OCI GoldenGate soportan la creación de archivos particionados en cubos de almacenamiento de objetos de destino. La partición mejora la depuración descendente y el rendimiento de las consultas, pero la partición en exceso aumenta el recuento de directorios/archivos y amplifica el problema de los archivos pequeños.

Para utilizar la partición, la tabla debe particionar los datos en el nivel más alto. Para ello, se utiliza la propiedad pathMappingTemplate y se debe definir en el nombre de tabla totalmente cualificado. Creará directorios dentro del contenedor o bloque en función del nombre completo de la tabla de origen. Por ejemplo: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}. Para crear particiones, se utiliza gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name>.

Esta propiedad se puede utilizar con la palabra clave de plantilla, como ${columnValue[column_name]} o valores de cadena constante, para definir la estructura de ruta de partición.

¿Cómo se tarifica el servicio OCI Database Migration? (Factual)

Los primeros 183 días (6 meses) de una migración se proporcionan sin cargo alguno, excepto en los casos en que la migración se ejecute durante más de 60 días sin ninguna transferencia de datos.

¿Qué orígenes y destinos soporta OCI Database Migration Service? (Factual)

Actualmente, se admiten migraciones homogéneas de Oracle y MySQL. Los orígenes pueden ser locales, en otras nubes o en OCI. Los destinos deben estar en OCI. Oracle recibe soporte de 11g (11.2.0.4), 12c (12.1.0.2,12.2.0.1),19c,21c y todas las versiones posteriores de Oracle Database. MySQL: versiones 5.7 y 8. Puede encontrar más detalles en la siguiente URL.

¿Cuáles son los tipos de migración soportados por OCI Database Migration Service?

Migración lógica fuera de línea: una copia única de la base de datos requiere que las aplicaciones estén fuera de línea durante el proceso de migración. Migración lógica en línea: copia inicial de la base de datos seguida de captura de cambios de datos durante la migración. Las solicitudes pueden permanecer en línea durante el proceso de migración.

Durante una migración de oracle, ¿qué objetos y esquemas se excluyen por defecto?

Siempre se excluyen los siguientes tipos de objetos:

Los siguientes esquemas se excluyen por defecto:

¿Qué recursos de OCI se necesitan para una migración?

¿Dónde está disponible OCI GoldenGate?