Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Requisitos previos para la integración sin ETL en Oracle Database@AWS
Antes de configurar la integración sin ETL, asegúrese de cumplir los siguientes requisitos previos.
Requisitos previos generales
AWS Configuración de Oracle Database@: asegúrese de tener al menos un clúster de máquinas virtuales aprovisionado y en ejecución.
-
Integración con cero ETL activado: asegúrese de que su clúster de máquinas virtuales o clúster de máquinas virtuales autónomas esté asociado a una red ODB que tenga activado cero ETL.
Versiones de Oracle Database compatibles: debe utilizar Oracle Database 19c (Oracle Exadata) o Oracle Database 19c/23ai (base de datos autónoma en infraestructura dedicada).
Misma AWS región: la base de datos Oracle de origen y el clúster de Amazon Redshift de destino deben estar en la misma AWS región.
Requisitos previos de la base de datos Oracle
Debe configurar su base de datos Oracle con los siguientes parámetros.
Configuración del usuario de replicación
Cree un usuario de replicación dedicado en cada base de datos conectable (PDB) que desee replicar:
Para Oracle Exadata: cree un usuario
ODBZEROETLADMINcon una contraseña segura.Para una base de datos autónoma en una infraestructura dedicada: utilice el usuario existente
GGADMIN.
Otorgue los siguientes permisos al usuario de replicación.
-- For Autonomous Database on Dedicated Infrastructure only ALTER USER GGADMIN ACCOUNT UNLOCK; ALTER USER GGADMIN IDENTIFIED BYggadmin-password; -- For Oracle Exadata only GRANT SELECT ONany-replicated-tableTO "ODBZEROETLADMIN"; GRANT LOGMINING to "ODBZEROETLADMIN"; -- Grant the following permissions to all services. -- For Oracle Exadata, use the ODBZEROETLADMIN user. For Autonomous Database on Dedicated Infrastructure, -- use the GGADMIN user. GRANT CREATE SESSION TO "ODBZEROETLADMIN"; GRANT SELECT ANY TRANSACTION TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$ARCHIVED_LOG TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$LOG TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$LOGFILE TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$LOGMNR_LOGS TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$LOGMNR_CONTENTS TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$DATABASE TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$THREAD TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$PARAMETER TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$NLS_PARAMETERS TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$TIMEZONE_NAMES TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$TRANSACTION TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$CONTAINERS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_INDEXES TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_OBJECTS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_TABLES TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_USERS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_CATALOG TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_CONSTRAINTS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_CONS_COLUMNS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_TAB_COLS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_IND_COLUMNS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_LOG_GROUPS TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_TAB_PARTITIONS TO "ODBZEROETLADMIN"; GRANT SELECT ON SYS.DBA_REGISTRY TO "ODBZEROETLADMIN"; GRANT SELECT ON SYS.OBJ$ TO "ODBZEROETLADMIN"; GRANT SELECT ON DBA_TABLESPACES TO "ODBZEROETLADMIN"; GRANT SELECT ON DBA_OBJECTS TO "ODBZEROETLADMIN"; GRANT SELECT ON SYS.ENC$ TO "ODBZEROETLADMIN"; GRANT SELECT ON GV_$TRANSACTION TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$DATAGUARD_STATS TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$DATABASE_INCARNATION TO "ODBZEROETLADMIN"; GRANT EXECUTE ON SYS.DBMS_CRYPTO TO "ODBZEROETLADMIN"; GRANT SELECT ON SYS.DBA_DIRECTORIES TO "ODBZEROETLADMIN"; GRANT SELECT ON ALL_VIEWS TO "ODBZEROETLADMIN"; GRANT SELECT ON DBA_SEGMENTS TO "ODBZEROETLADMIN"; GRANT SELECT ON V_$TRANSPORTABLE_PLATFORM TO "ODBZEROETLADMIN"; GRANT CREATE ANY DIRECTORY TO "ODBZEROETLADMIN"; GRANT EXECUTE ON DBMS_FILE_TRANSFER TO "ODBZEROETLADMIN"; GRANT EXECUTE ON DBMS_FILE_GROUP TO "ODBZEROETLADMIN"; GRANT EXECUTE on DBMSLOGMNR to "ODBZEROETLADMIN"; GRANT SELECT on V_$LOGMNRLOGS to "ODBZEROETLADMIN"; GRANT SELECT on V_$LOGMNRCONTENTS to "ODBZEROETLADMIN"; GRANT LOGMINING to "ODBZEROETLADMIN"; GRANT SELECT ON GV_$CELL_STATE TO "ODBZEROETLADMIN";
Registro suplementario
Habilite el registro adicional en su base de datos Oracle para capturar los datos de los cambios.
-- Check if supplemental logging is enabled SELECT supplemental_log_data_min FROM v$database; -- Enable supplemental logging if not already enabled. -- For Oracle Exadata, enable supplemental logging on both the CDB and PDB. -- For Autonomous Database on Dedicated Infrastructure, enable supplemental logging on the PDB only. ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- For Autonomous Database on Dedicated Infrastructure only ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; -- Archive current online redo log ALTER SYSTEM ARCHIVE LOG CURRENT;
Para configurar una integración sin ETL entre Oracle Database@ y Amazon AWS Redshift, debe configurar SSL.
- Para las bases de datos Oracle Exadata
-
Debe configurar manualmente el SSL en el puerto 2484. Esta tarea implica lo siguiente:
-
Configurando
(PROTOCOL=tcps)(PORT=2484)enlistener.ora -
Configuración de la cartera mediante
sqlnet.ora -
Generación y configuración de certificados SSL (consulte Cómo configurar SSL/TCPS Exadata Cloud Database (ExACC/EXACS) (ID de documento 2947301.1)
en la documentación de My Oracle Support)
-
- Para bases de datos autónomas
-
El SSL en el puerto 2484 está activado de forma predeterminada. No se necesita configuración adicional.
importante
El puerto SSL está fijado en 2484.
AWS requisitos previos del servicio
Antes de configurar la integración sin ETL, configure AWS Secrets Manager y configure los permisos de IAM.
Configurar AWS Secrets Manager
Guarde las credenciales de su base de datos Oracle en AWS Secrets Manager de la siguiente manera:
Cree una clave gestionada por el cliente (CMK) en AWS Key Management Service.
Guarde las credenciales de la base de datos en AWS Secrets Manager mediante la CMK.
Configure las políticas de recursos para permitir el acceso a Oracle Database@AWS .
Para obtener el identificador de clave y la contraseña de TDE, utilice la técnica descrita en Métodos de cifrado compatibles para utilizar Oracle como fuente de AWS Database Migration Service. El siguiente comando genera la cartera base64.
base64 -i cwallet.sso > wallet.b64
El siguiente ejemplo muestra un secreto de Oracle Exadata. Paraasm_service_name, 111.11.11.11 representa la IP virtual del nodo de máquina virtual. También puede registrar el listener de ASM con SCAN.
{ "database_info": [ { "name": "ODBDB_ZETLPDB", "service_name": "ODBDB_ZETLPDB.paas.oracle.com", "username": "ODBZEROETLADMIN", "password": "secure_password", "tde_key_id": "ORACLE.SECURITY.DB.ENCRYPTION.key_id", "tde_password": "tde_password", "certificateWallet": "base64_encoded_wallet_content" } ], "asm_info": { "asm_user": "odbzeroetlasm", "asm_password": "secure_password", "asm_service_name": "111.11.11.11:2484/+ASM" } }
El siguiente ejemplo muestra el secreto de una base de datos autónoma en una infraestructura dedicada.
{ "database_info": [ { "database_name": "ZETLACD_ZETLADBMORECPU", "service_name": "ZETLADBMORECPU_high.adw.oraclecloud.com", "username": "ggadmin", "password": "secure_password", "certificateWallet": "base64_encoded_wallet_content" } ] }
Configurar los permisos de IAM
Cree políticas de IAM que permitan operaciones de integración sin ETL. El siguiente ejemplo de política permite describir, crear, actualizar y eliminar operaciones para un clúster de máquinas virtuales de Exadata. Para un clúster de máquinas virtuales autónomas, utilice el valor cloud-autonomous-vm-cluster en lugar del cloud-vm-cluster ARN del recurso.