Utilizar um banco de dados Oracle como origem do AWS DMS - AWS Database Migration Service
Usando Oracle LogMiner ou AWS DMS Binary Reader para CDCFluxos de trabalho para configurar um banco de dados de origem Oracle autogerenciado ou AWS gerenciado para AWS DMSConfigurar um banco de dados de origem OracleTrabalhar com um banco de dados Oracle autogerenciado como origemTrabalhando com uma AWS fonte Oracle gerenciadaLimitações do Oracle como origemSuporte de SSL para um endpoint do OracleMétodos de criptografia no Oracle como origemMétodos de compactação no Oracle como origemReplicar tabelas aninhadas utilizando Oracle como origemArmazenar REDO no Oracle ASMConfigurações de endpointTipos de dados de origem do Oracle

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Utilizar um banco de dados Oracle como origem do AWS DMS

Você pode migrar dados de um ou vários bancos de dados Oracle usando o. AWS DMS Com um banco de dados Oracle como origem, é possível migrar dados para qualquer um dos destinos compatíveis com o AWS DMS.

AWS DMS suporta as seguintes edições do banco de dados Oracle:

  • Oracle Enterprise Edition

  • Oracle Standard Edition

  • Oracle Express Edition

  • Oracle Personal Edition

Para obter informações sobre versões de bancos de dados Oracle que oferecem AWS DMS suporte como fonte, consulteFontes para AWS DMS.

É possível utilizar Secure Sockets Layer (SSL) para criptografar conexões entre o endpoint do Oracle e a instância de replicação. Para obter mais informações sobre a utilização de SSL com um endpoint do Oracle, consulte Suporte de SSL para um endpoint do Oracle.

AWS DMS suporta o uso da criptografia transparente de dados (TDE) da Oracle para criptografar dados em repouso no banco de dados de origem. Para obter mais informações sobre como utilizar a TDE do Oracle com um endpoint do Oracle de origem, consulte Métodos de criptografia suportados para usar o Oracle como fonte para AWS DMS.

AWS suporta o uso do TLS versão 1.2 e posterior com endpoints Oracle (e todos os outros tipos de endpoints) e recomenda o uso do TLS versão 1.3 ou posterior.

Siga estas etapas para configurar um banco de dados Oracle como um endpoint AWS DMS de origem:

  1. Crie um usuário Oracle com as permissões apropriadas AWS DMS para acessar seu banco de dados de origem Oracle.

  2. Crie um endpoint de origem do Oracle que esteja em conformidade com a configuração de banco de dados Oracle escolhida. Para criar uma full-load-only tarefa, nenhuma configuração adicional é necessária.

  3. Para criar uma tarefa que gerencie a captura de dados de alteração (uma tarefa somente de CDC ou de carga completa e CDC), escolha Oracle LogMiner ou AWS DMS Binary Reader para capturar as alterações nos dados. A escolha LogMiner do Binary Reader determina algumas das permissões e opções de configuração posteriores. Para uma comparação entre o Binary Reader LogMiner e o Binary Reader, consulte a seção a seguir.

nota

Para obter mais informações sobre tarefas de carga máxima, tarefas somente CDC e tarefas de carga máxima e CDC, consulte Criar uma tarefa

Para obter detalhes adicionais sobre como trabalhar com bancos de dados de origem Oracle AWS DMS, consulte as seções a seguir.

Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC

Em AWS DMS, há dois métodos para ler os redo logs ao fazer a captura de dados de alteração (CDC) para Oracle como fonte: Oracle LogMiner e AWS DMS Binary Reader. LogMiner é uma API da Oracle para ler os redo logs on-line e os arquivos de redo log arquivados. O Binary Reader é um AWS DMS método que lê e analisa diretamente os arquivos brutos de redo log. Esses métodos têm os recursos a seguir.

Atributo LogMiner Binary Reader
Fácil de configurar Sim Não
Menor impacto na E/S e na CPU do sistema de origem Não Sim
Melhor performance da CDC Não Sim
Compatível com clusters de tabelas do Oracle Sim Não
Compatível com todos os tipos de Oracle Hybrid Columnar Compression (HCC) Sim

Parcialmente

O Binary Reader não é compatível com QUERY LOW para tarefas com CDC. Todos os outros tipos de HCC são totalmente compatíveis.
Compatível com a coluna LOB no Oracle 12c somente Não (o LOB Support não está disponível LogMiner no Oracle 12c.) Sim
Compatível com instruções UPDATE que afetam somente colunas LOB Não Sim
Compatível com a criptografia de dados transparente (TDE) do Oracle

Parcialmente

Ao usar o Oracle LogMiner, AWS DMS não oferece suporte à criptografia TDE em nível de coluna para Amazon RDS for Oracle.

Parcialmente

O Binary Reader é compatível com TDE somente em bancos de dados Oracle autogerenciados.
Compatível com todos os métodos de compactação do Oracle Sim Não
Compatível com transações XA Não Sim
RAC

Sim

Não recomendado por motivos de desempenho e por algumas limitações internas do DMS.

Sim

Altamente recomendado
nota

Por padrão, AWS DMS usa Oracle LogMiner for (CDC).

AWS DMS suporta métodos transparentes de criptografia de dados (TDE) ao trabalhar com um banco de dados de origem Oracle. Se as credenciais do TDE que você especificar estiverem incorretas, a tarefa de AWS DMS migração não falhará, o que pode afetar a replicação contínua de tabelas criptografadas. Para obter mais informações sobre como especificar as credenciais da TDE, consulte Métodos de criptografia suportados para usar o Oracle como fonte para AWS DMS.

As principais vantagens de usar LogMiner com AWS DMS incluem o seguinte:

  • LogMiner suporta a maioria das opções do Oracle, como opções de criptografia e opções de compactação. O Binary Reader não é compatível com todas as opções do Oracle, especialmente a compactação e a maioria das opções de criptografia.

  • LogMiner oferece uma configuração mais simples, especialmente em comparação com a configuração de acesso direto do Binary Reader ou quando os redo logs são gerenciados usando o Oracle Automatic Storage Management (ASM).

  • LogMiner suporta clusters de tabelas para uso por AWS DMS. O Binary Reader não oferece.

As principais vantagens de usar o Binary Reader com AWS DMS incluem o seguinte:

  • Para migrações com um alto volume de alterações, LogMiner pode ter algum impacto de E/S ou CPU no computador que hospeda o banco de dados de origem Oracle. O Binary Reader tem menos chance de causar impacto na E/S ou na CPU porque os logs são minerados diretamente, em vez da execução de várias consultas ao banco de dados.

  • Para migrações com um alto volume de alterações, o desempenho do CDC geralmente é muito melhor quando se usa o Binary Reader em comparação com o uso do Oracle. LogMiner

  • O Binary Reader suporta CDC para LOBs na versão 12c do Oracle. LogMinernão.

Em geral, use o Oracle LogMiner para migrar seu banco de dados Oracle, a menos que você tenha uma das seguintes situações:

  • Você precisa executar várias tarefas de migração no banco de dados Oracle de origem.

  • O volume de alterações ou o volume de redo logs no banco de dados Oracle de origem é alto ou você tem alterações e também está utilizando o Oracle ASM.

nota

Se você alternar entre o uso do Oracle LogMiner e do AWS DMS Binary Reader, certifique-se de reiniciar a tarefa do CDC.

Configuração da CDC em um banco de dados Oracle de origem

Para que um endpoint de origem Oracle se conecte ao banco de dados para uma tarefa de captura de dados de alteração (CDC), talvez seja necessário especificar atributos de conexão adicionais. Isso pode ser verdade tanto para uma tarefa de carga máxima e CDC quanto para uma tarefa somente de CDC. Os atributos extras de conexão que você especifica dependem do método usado para acessar os redo logs: Oracle LogMiner ou AWS DMS Binary Reader.

Você especifica atributos de conexão adicionais ao criar o endpoint de origem. Se você tiver várias configurações de atributos de conexão, separe-as umas das outras por ponto e vírgula e sem espaços em branco adicionais (por exemplo, oneSetting;thenAnother).

AWS DMS usa LogMiner por padrão. Não é necessário especificar atributos de conexão adicionais para utilizá-lo.

Para utilizar o Binary Reader para acessar os redo logs, inclua os seguintes atributos de conexão adicionais.

useLogMinerReader=N;useBfile=Y;

Utilize o seguinte formato para os atributos de conexão adicionais para acessar um servidor que utiliza o ASM com o Binary Reader.

useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;

Defina o parâmetro de solicitação Password do endpoint de origem para a senha do usuário do Oracle e a senha do ASM, separadas por uma vírgula da seguinte forma.

oracle_user_password,asm_user_password

Quando a origem Oracle utiliza o ASM, é possível trabalhar com opções de alto desempenho no Binary Reader para o processamento de transações em escala. Essas opções incluem atributos de conexão adicionais para especificar o número de threads paralelos (parallelASMReadThreads) e o número de buffers de leitura antecipada (readAheadBlocks). A configuração conjunta desses atributos pode melhorar significativamente o desempenho da tarefa de CDC. As configurações a seguir fornecem bons resultados para a maioria das configurações do ASM.

useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM;
    parallelASMReadThreads=6;readAheadBlocks=150000;

Para obter mais informações sobre os valores compatíveis com atributos de conexão adicionais, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS.

Além disso, o desempenho de uma tarefa de CDC com uma origem Oracle que utiliza o ASM depende das outras configurações escolhidas. Essas configurações incluem os atributos de conexão adicionais do AWS DMS e as configurações do SQL para configurar a origem Oracle. Para obter mais informações sobre atributos de conexão adicionais para uma origem Oracle que utiliza o ASM, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS

Você também precisa escolher um ponto de partida apropriado da CDC. Normalmente, ao fazer isso, você deseja identificar o ponto de processamento da transação que captura a primeira transação aberta a partir da qual a CDC é iniciada. Caso contrário, a tarefa de CDC pode perder transações abertas anteriores. Para um banco de dados de origem Oracle, é possível escolher um ponto inicial nativo da CDC com base no número da alteração do sistema (SCN) do Oracle para identificar essa primeira transação aberta. Para ter mais informações, consulte Executar a replicação a partir de um ponto de início de CDC.

Para obter mais informações sobre como configurar a CDC para um banco de dados Oracle autogerenciado como origem, consulte Privilégios de conta necessários ao usar o Oracle LogMiner para acessar os redo logs, Privilégios de conta necessários ao usar o AWS DMS Binary Reader para acessar os redo logs e Privilégios adicionais de conta necessários ao utilizar o Binary Reader com o Oracle ASM.

Para obter mais informações sobre como configurar o CDC para um banco AWS de dados Oracle gerenciado como fonte, consulte e. Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS

Fluxos de trabalho para configurar um banco de dados de origem Oracle autogerenciado ou AWS gerenciado para AWS DMS

Configurar um banco de dados de origem Oracle

Para configurar uma instância de banco de dados de origem autogerenciado, utilize as seguintes etapas, dependendo de como você executa a CDC.

Para esta etapa do fluxo de trabalho Se você executar o CDC usando LogMiner, faça isso Se você executar a CDC utilizando o Binary Reader, faça isso
Conceda privilégios à conta Oracle. Consulte Privilégios de conta de usuário necessários em uma fonte Oracle autogerenciada para AWS DMS. Consulte Privilégios de conta de usuário necessários em uma fonte Oracle autogerenciada para AWS DMS.
Prepare o banco de dados de origem para replicação utilizando a CDC. Consulte Preparando um banco de dados de origem autogerenciado Oracle para CDC usando AWS DMS. Consulte Preparando um banco de dados de origem autogerenciado Oracle para CDC usando AWS DMS.
Conceda privilégios adicionais ao usuário do Oracle necessários para a CDC. Consulte Privilégios de conta necessários ao usar o Oracle LogMiner para acessar os redo logs. Consulte Privilégios de conta necessários ao usar o AWS DMS Binary Reader para acessar os redo logs.
Para uma instância Oracle com ASM, conceda privilégios adicionais de conta de usuário necessários para acessar o ASM para CDC. Nenhuma ação adicional. AWS DMS oferece suporte ao Oracle ASM sem privilégios adicionais de conta. Consulte Privilégios adicionais de conta necessários ao utilizar o Binary Reader com o Oracle ASM.
Se você ainda não tiver feito isso, configure a tarefa para usar LogMiner o Binary Reader for CDC. Consulte Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC. Consulte Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC.
Configure o Oracle Standby como origem para a CDC. AWS DMS não oferece suporte ao Oracle Standby como fonte. Consulte Utilizar um Oracle Standby autogerenciado como origem com o Binary Reader para CDC no AWS DMS.

Use as seguintes etapas do fluxo de trabalho para configurar uma instância de banco AWS de dados de origem Oracle gerenciada.

Para esta etapa do fluxo de trabalho Se você executar o CDC usando LogMiner, faça isso Se você executar a CDC utilizando o Binary Reader, faça isso
Conceda privilégios à conta Oracle. Para ter mais informações, consulte Privilégios de conta de usuário necessários em uma fonte Oracle AWS gerenciada para AWS DMS. Para ter mais informações, consulte Privilégios de conta de usuário necessários em uma fonte Oracle AWS gerenciada para AWS DMS.
Prepare o banco de dados de origem para replicação utilizando a CDC. Para ter mais informações, consulte Configurando uma fonte Oracle AWS gerenciada para AWS DMS. Para ter mais informações, consulte Configurando uma fonte Oracle AWS gerenciada para AWS DMS.
Conceda privilégios adicionais ao usuário do Oracle necessários para a CDC. Nenhum privilégio adicional de conta é necessário. Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.
Se você ainda não tiver feito isso, configure a tarefa para usar LogMiner o Binary Reader for CDC. Para ter mais informações, consulte Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC. Para ter mais informações, consulte Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC.
Configure o Oracle Standby como origem para a CDC. AWS DMS não oferece suporte ao Oracle Standby como fonte. Para ter mais informações, consulte Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS.

Trabalhando com um banco de dados Oracle autogerenciado como fonte para AWS DMS

Um banco de dados autogerenciado é um banco de dados que você configura e controla, em uma instância de banco de dados on-premises ou em um banco de dados no Amazon EC2. A seguir, você pode descobrir os privilégios e as configurações de que precisa ao usar um banco de dados Oracle autogerenciado com o. AWS DMS

Privilégios de conta de usuário necessários em uma fonte Oracle autogerenciada para AWS DMS

Para usar um banco de dados Oracle como origem em AWS DMS, conceda os seguintes privilégios ao usuário Oracle especificado nas configurações de conexão do endpoint Oracle.

nota

Ao conceder privilégios, utilize o nome real dos objetos, não o sinônimo de cada objeto. Por exemplo, utilize V_$OBJECT incluindo o sublinhado, não V$OBJECT sem o sublinhado.

GRANT CREATE SESSION TO db_user;
GRANT SELECT ANY TRANSACTION TO db_user;
GRANT SELECT ON V_$ARCHIVED_LOG TO db_user;
GRANT SELECT ON V_$LOG TO db_user;
GRANT SELECT ON V_$LOGFILE TO db_user;
GRANT SELECT ON V_$LOGMNR_LOGS TO db_user;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO db_user;
GRANT SELECT ON V_$DATABASE TO db_user;
GRANT SELECT ON V_$THREAD TO db_user;
GRANT SELECT ON V_$PARAMETER TO db_user;
GRANT SELECT ON V_$NLS_PARAMETERS TO db_user;
GRANT SELECT ON V_$TIMEZONE_NAMES TO db_user;
GRANT SELECT ON V_$TRANSACTION TO db_user;
GRANT SELECT ON V_$CONTAINERS TO db_user;                   
GRANT SELECT ON ALL_INDEXES TO db_user;
GRANT SELECT ON ALL_OBJECTS TO db_user;
GRANT SELECT ON ALL_TABLES TO db_user;
GRANT SELECT ON ALL_USERS TO db_user;
GRANT SELECT ON ALL_CATALOG TO db_user;
GRANT SELECT ON ALL_CONSTRAINTS TO db_user;
GRANT SELECT ON ALL_CONS_COLUMNS TO db_user;
GRANT SELECT ON ALL_TAB_COLS TO db_user;
GRANT SELECT ON ALL_IND_COLUMNS TO db_user;
GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO db_user;
GRANT SELECT ON ALL_LOG_GROUPS TO db_user;
GRANT SELECT ON ALL_TAB_PARTITIONS TO db_user;
GRANT SELECT ON SYS.DBA_REGISTRY TO db_user;
GRANT SELECT ON SYS.OBJ$ TO db_user;
GRANT SELECT ON DBA_TABLESPACES TO db_user;
GRANT SELECT ON DBA_OBJECTS TO db_user; -– Required if the Oracle version is earlier than 11.2.0.3.
GRANT SELECT ON SYS.ENC$ TO db_user; -– Required if transparent data encryption (TDE) is enabled. For more information on using Oracle TDE with AWS DMS, see Métodos de criptografia suportados para usar o Oracle como fonte para AWS DMS.
GRANT SELECT ON GV_$TRANSACTION TO db_user; -– Required if the source database is Oracle RAC in AWS DMS versions 3.4.6 and higher.
GRANT SELECT ON V_$DATAGUARD_STATS TO db_user; -- Required if the source database is Oracle Data Guard and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.
GRANT SELECT ON V$DATABASE_INCARNATION TO db_user;

Conceda o privilégio adicional a seguir para cada tabela replicada ao utilizar uma lista de tabelas específica.

GRANT SELECT on any-replicated-table to db_user;

Conceda o seguinte privilégio adicional para validar colunas LOB com o recurso de validação.

GRANT EXECUTE ON SYS.DBMS_CRYPTO TO db_user;

Conceda o seguinte privilégio adicional se você usar o leitor binário em vez de LogMiner.

GRANT SELECT ON SYS.DBA_DIRECTORIES TO db_user;

Conceda o seguinte privilégio adicional para expor visualizações.

GRANT SELECT on ALL_VIEWS to dms_user;

Para expor visualizações, adicione também o atributo de conexão adicional do exposeViews=true ao endpoint de origem.

Conceda o seguinte privilégio adicional ao utilizar replicações com tecnologia sem servidor.

GRANT SELECT on dba_segments to db_user;

Para obter informações sobre as replicações com tecnologia sem servidor, consulte Trabalhando com AWS DMS Serverless.

Conceda os seguintes privilégios adicionais ao utilizar avaliações de pré-migração específicas do Oracle.

GRANT SELECT on gv_$parameter  to dms_user;
GRANT SELECT on v_$instance to dms_user;
GRANT SELECT on v_$version to dms_user;
GRANT SELECT on gv_$ASM_DISKGROUP to dms_user;
GRANT SELECT on gv_$database to dms_user;
GRANT SELECT on dba_db_links to dms_user;
GRANT SELECT on gv_$log_History to dms_user;
GRANT SELECT on gv_$log to dms_user;
GRANT SELECT ON DBA_TYPES TO db_user;
GRANT SELECT ON DBA_USERS to dms_user;
GRANT SELECT ON DBA_DIRECTORIES to dms_user;

Para obter informações sobre avaliações de pré-migração específicas do Oracle, consulte. Avaliações da Oracle

Pré-requisitos para tratar transações abertas do Oracle Standby

Ao usar AWS DMS as versões 3.4.6 e superiores, execute as etapas a seguir para lidar com transações abertas para o Oracle Standby.

  1. Crie um link de banco de dados nomeado AWSDMS_DBLINK no banco de dados primário. O DMS_USER utilizará o link de banco de dados para conectar-se ao banco de dados primário. Observe que o link de banco de dados é executado na instância em espera para consultar as transações abertas em execução no banco de dados primário. Veja o exemplo a seguir. 

    CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
   CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
   USING '(DESCRIPTION=
            (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
            (CONNECT_DATA=(SERVICE_NAME=SID))
          )';

  2. Verifique se a conexão ao link de banco de dados que utiliza o DMS_USER está estabelecida conforme mostrado no exemplo a seguir.

    select 1 from dual@AWSDMS_DBLINK

Preparando um banco de dados de origem autogerenciado Oracle para CDC usando AWS DMS

Prepare seu banco de dados Oracle autogerenciado como origem para executar uma tarefa de CDC fazendo o seguinte:

Verificando se é AWS DMS compatível com a versão do banco de dados de origem

Execute uma consulta, como a seguinte, para verificar se a versão atual do banco de dados Oracle é compatível com o AWS DMS.

SELECT name, value, description FROM v$parameter WHERE name = 'compatible';

Aqui, name, value e description são colunas em algum local no banco de dados que estão sendo consultadas com base no valor de name. Se essa consulta for executada sem erros, AWS DMS será compatível com a versão atual do banco de dados e você poderá continuar com a migração. Se a consulta gerar um erro, AWS DMS isso não é compatível com a versão atual do banco de dados. Para continuar com a migração, primeiro converta o banco de dados Oracle em uma versão suportada pelo AWS DMS.

Verificar se o modo ARCHIVELOG está ativado

É possível executar o Oracle em dois modos diferentes: o modo ARCHIVELOG e o modo NOARCHIVELOG. Para executar uma tarefa de CDC, execute o banco de dados no modo ARCHIVELOG. Para saber se o banco de dados está no modo ARCHIVELOG, execute a consulta a seguir.

SQL> SELECT log_mode FROM v$database;

Se for retornado o modo NOARCHIVELOG, defina o banco de dados como ARCHIVELOG de acordo com as instruções do Oracle.

Configuração de registro em log suplementar

Para capturar as mudanças em andamento, é AWS DMS necessário que você habilite o mínimo de registro suplementar em seu banco de dados de origem Oracle. Além disso, você precisa ativar o registro em log suplementar em cada tabela replicada no banco de dados.

Por padrão, AWS DMS adiciona registro PRIMARY KEY suplementar em todas as tabelas replicadas. Para permitir AWS DMS a adição de registros PRIMARY KEY complementares, conceda o seguinte privilégio para cada tabela replicada.

ALTER on any-replicated-table;

Você pode desativar o registro PRIMARY KEY suplementar padrão adicionado AWS DMS usando o atributo de conexão extra. addSupplementalLogging Para ter mais informações, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS.

Ative o registro em log suplementar se a tarefa de replicação atualizar uma tabela utilizando uma cláusula WHERE que não faz referência a uma coluna de chave primária.

Como configurar o registro em log suplementar manualmente

  1. Execute a consulta a seguir para verificar se o registro em log suplementar está ativado para o banco de dados.

    SELECT supplemental_log_data_min FROM v$database;

    Se o resultado retornado for YES ou IMPLICIT, o registro em log suplementar estará ativado para o banco de dados.

    Se necessário, ative o registro em log suplementar para o banco de dados executando o comando a seguir.

    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

  2. Verifique se o registro em log suplementar necessário está adicionado a cada tabela replicada.

    Considere o seguinte:

    • Se o registro em log suplementar ALL COLUMNS estiver adicionado à tabela, não será necessário adicionar mais registros em log.

    • Se houver uma chave primária, adicione o registro em log suplementar à chave primária. É possível fazer isso utilizando o formato para adicionar registro em log suplementar à chave primária ou adicionando o registro em log suplementar às colunas de chave primária no banco de dados.

      ALTER TABLE Tablename ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

    • Se não houver uma chave primária e a tabela possuir um único índice exclusivo, adicione todas as colunas do índice exclusivo ao log suplementar.

      ALTER TABLE TableName ADD SUPPLEMENTAL LOG GROUP LogGroupName (UniqueIndexColumn1[, UniqueIndexColumn2] ...) ALWAYS;

      Usar SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS não faz com que as colunas do índice exclusivo sejam adicionadas ao log.

    • Se não existir uma chave primária e a tabela tiver vários índices exclusivos, AWS DMS seleciona o primeiro índice exclusivo em uma lista ascendente ordenada alfabeticamente. Você precisa adicionar registro em log suplementar nas colunas do índice selecionado, como no item anterior.

      Usar SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS não faz com que as colunas do índice exclusivo sejam adicionadas ao log.

    • Se não houver uma chave primária e não houver um índice exclusivo, adicione o registro em log suplementar em todas as colunas.

      ALTER TABLE TableName ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

      Em alguns casos, a chave primária da tabela de destino ou índice exclusivo são diferentes da chave primária da tabela de origem ou índice exclusivo. Nesses casos, adicione o registro em log suplementar manualmente nas colunas da tabela de origem que compõem a chave primária da tabela ou o índice exclusivo de destino.

      Além disso, se você alterar a chave primária da tabela de destino, adicione o registro complementar às colunas do índice exclusivo de destino, em vez das colunas do índice exclusivo ou da chave primária de origem.

Se um filtro ou uma transformação for definida para uma tabela, talvez seja necessário habilitar o registro em log adicional.

Considere o seguinte:

  • Se o registro em log suplementar ALL COLUMNS estiver adicionado à tabela, não será necessário adicionar mais registros em log.

  • Se a tabela tiver um índice exclusivo ou uma chave primária, adicione registro em log suplementar a cada coluna envolvida em um filtro ou transformação. No entanto, faça isso somente se essas colunas forem diferentes da chave primária ou das colunas do índice exclusivo.

  • Se uma transformação incluir apenas uma coluna, não adicione essa coluna a um grupo de registro em log suplementar. Por exemplo, para uma transformação A+B, adicione registro em log suplementar em ambas as colunas A e B. No entanto, para uma transformação substring(A,10), não adicione registro em log suplementar à coluna A.

  • Para configurar o registro em log suplementar em colunas de índice exclusivo ou de chave primária e outras colunas específicas filtradas ou transformadas, é possível adicionar o registro em log suplementar USER_LOG_GROUP. Adicione esse registro em log suplementar às colunas de chave primária ou ao índice exclusivo e às outras colunas específicas filtradas ou transformadas.

    Por exemplo, para replicar uma tabela nomeada TEST.LOGGING com chave primária ID e um filtro pela coluna NAME, é possível executar um comando semelhante ao seguinte para criar o registro em log suplementar do grupo de logs.

    ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;

Privilégios de conta necessários ao usar o Oracle LogMiner para acessar os redo logs

Para acessar os redo logs usando o Oracle LogMiner, conceda os seguintes privilégios ao usuário Oracle especificado nas configurações de conexão do endpoint Oracle.

GRANT EXECUTE on DBMS_LOGMNR to db_user;
GRANT SELECT on V_$LOGMNR_LOGS to db_user;
GRANT SELECT on V_$LOGMNR_CONTENTS to db_user;
GRANT LOGMINING to db_user; -– Required only if the Oracle version is 12c or higher.

Privilégios de conta necessários ao usar o AWS DMS Binary Reader para acessar os redo logs

Para acessar os redo logs usando o AWS DMS Binary Reader, conceda os seguintes privilégios ao usuário Oracle especificado nas configurações de conexão do endpoint Oracle.

GRANT SELECT on v_$transportable_platform to db_user;   -– Grant this privilege if the redo logs are stored in Oracle Automatic Storage Management (ASM) and AWS DMS accesses them from ASM.
GRANT CREATE ANY DIRECTORY to db_user;                  -– Grant this privilege to allow AWS DMS to use Oracle BFILE read file access in certain cases. This access is required when the replication instance doesn't have file-level access to the redo logs and the redo logs are on non-ASM storage.
GRANT EXECUTE on DBMS_FILE_TRANSFER to db_user;         -– Grant this privilege to copy the redo log files to a temporary folder using the CopyToTempFolder method.
GRANT EXECUTE on DBMS_FILE_GROUP to db_user;

O Binary Reader funciona com recursos de arquivo Oracle que incluem diretórios do Oracle. Cada objeto no diretório do Oracle inclui o nome da pasta que contém os arquivos de logs redo a serem processados. Esses diretórios do Oracle não são representados no nível do sistema de arquivos. Eles são diretórios lógicos criados no nível do banco de dados Oracle. É possível exibi-los na visualização ALL_DIRECTORIES do Oracle.

Se você quiser AWS DMS criar esses diretórios Oracle, conceda o CREATE ANY DIRECTORY privilégio especificado anteriormente. AWS DMS cria os nomes dos diretórios com o DMS_ prefixo. Se você não conceder o privilégio CREATE ANY DIRECTORY, crie os diretórios correspondentes manualmente. Em alguns casos, ao criar os diretórios do Oracle manualmente, o usuário do Oracle especificado no endpoint de origem Oracle não é o usuário que criou esses diretórios. Nesses casos, também conceda o privilégio READ on DIRECTORY.

Se o endpoint de origem da Oracle estiver no Active Dataguard Standby (ADG), consulte a publicação Como usar o Binary Reader com o ADG no Database Blog. AWS

nota

AWS DMS O CDC não oferece suporte ao Active Dataguard Standby, que não está configurado para usar o serviço de transporte automático de redo.

Em alguns casos, é possível utilizar o Oracle Managed Files (OMF) para armazenar os logs. Ou endpoint de origem está no ADG e, portanto, o privilégio CREATE ANY DIRECTORY não pode ser concedido. Nesses casos, crie manualmente os diretórios com todos os locais de log possíveis antes de iniciar a tarefa de AWS DMS replicação. Se o AWS DMS não encontrar um diretório pré-criado que é esperado, a tarefa será interrompida. Além disso, o AWS DMS não exclui as entradas que criou na visualização ALL_DIRECTORIES, portanto, exclua-as manualmente.

Privilégios adicionais de conta necessários ao utilizar o Binary Reader com o Oracle ASM

Para acessar os redo logs no Automatic Storage Management (ASM) utilizando o Binary Reader, conceda os seguintes privilégios ao usuário do Oracle especificado nas configurações de conexão de endpoint do Oracle:

SELECT ON v_$transportable_platform
SYSASM -– To access the ASM account with Oracle 11g Release 2 (version 11.2.0.2) and higher, grant the Oracle endpoint user the SYSASM privilege. For older supported Oracle versions, it's typically sufficient to grant the Oracle endpoint user the SYSDBA privilege.

É possível validar o acesso à conta do ASM abrindo um prompt de comando e invocando uma das instruções a seguir, dependendo da versão do Oracle, conforme especificado anteriormente.

Se o privilégio SYSDBA for necessário, use o seguinte.

sqlplus asmuser/asmpassword@+asmserver as sysdba

Se o privilégio SYSASM for necessário, use o seguinte. 

sqlplus asmuser/asmpassword@+asmserver as sysasm

Utilizar um Oracle Standby autogerenciado como origem com o Binary Reader para CDC no AWS DMS

Para configurar uma instância do Oracle Standby como origem ao utilizar o Binary Reader para CDC, comece com os seguintes pré-requisitos:

  • AWS DMS atualmente suporta somente o Oracle Active Data Guard Standby.

  • Verifique se a configuração do Oracle Data Guard utiliza:

    • Serviços de transporte de refazer para transferências automatizadas de dados de refazer.

    • Aplique serviços para aplicar automaticamente refazer banco de dados em espera.

Para confirmar se esses requisitos foram atendidos, execute a consulta a seguir.

SQL> select open_mode, database_role from v$database;

Na saída dessa consulta, confirme se o banco de dados em espera está aberto no modo SOMENTE LEITURA e se refazer está sendo aplicado automaticamente. Por exemplo: .

OPEN_MODE             DATABASE_ROLE
--------------------  ----------------
READ ONLY WITH APPLY  PHYSICAL STANDBY
Como configurar uma instância do Oracle Standby como origem ao utilizar o Binary Reader para CDC

  1. Conceda privilégios adicionais necessários para acessar arquivos de log em espera.

    GRANT SELECT ON v_$standby_log TO db_user;

  2. Crie um endpoint de origem para o Oracle Standby utilizando o AWS Management Console ou a AWS CLI. Ao criar o endpoint, especifique os seguintes atributos de conexão adicionais.

    useLogminerReader=N;useBfile=Y;
    nota

    Em AWS DMS, você pode usar atributos de conexão extras para especificar se deseja migrar dos registros de arquivamento em vez dos redo logs. Para ter mais informações, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS.

  3. Configure o destino do log arquivado.

    O Binary Reader do DMS da origem do Oracle sem ASM utiliza diretórios do Oracle para acessar os redo logs arquivados. Se o banco de dados estiver configurado para utilizar Fast Recovery Area (FRA) como destino do log de arquivamento, a localização dos arquivos de refazer de arquivamento não é constante. Cada dia em que redo logs arquivados são gerados resulta em um novo diretório criado no FRA, utilizando o formato de nome de diretório AAAA_MM_DD. Por exemplo: . 

    DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD

    Quando o DMS precisa acessar arquivos de refazer arquivados no diretório FRA recém-criado, e o banco de dados primário de leitura e gravação está sendo utilizado como origem, o DMS cria um novo diretório Oracle ou substitui um existente, da seguinte forma. 

    CREATE OR REPLACE DIRECTORY dmsrep_taskid AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/YYYY_MM_DD’;

    Quando o banco de dados em espera está sendo utilizado como origem, o DMS não pode criar ou substituir o diretório Oracle porque o banco de dados está no modo somente leitura. Porém, é possível optar por executar uma dessas etapas adicionais:

    1. Modificar log_archive_dest_id_1 para utilizar um caminho real em vez do FRA em uma configuração que o Oracle não crie subdiretórios diariamente:

      ALTER SYSTEM SET log_archive_dest_1=’LOCATION=full directory path’

      Criar um objeto no diretório Oracle para ser utilizado pelo DMS:

      CREATE OR REPLACE DIRECTORY dms_archived_logs AS ‘full directory path’;

    2. Criar um destino adicional de log de arquivamento e um objeto no diretório Oracle apontando para esse destino. Por exemplo: .

      ALTER SYSTEM SET log_archive_dest_3=’LOCATION=full directory path’; 
CREATE DIRECTORY dms_archived_log AS ‘full directory path’;

      Adicionar um atributo de conexão adicional ao endpoint da origem da tarefa:

      archivedLogDestId=3

    3. Pré-crie manualmente objetos no diretório Oracle para serem utilizados pelo DMS.

      CREATE DIRECTORY dms_archived_log_20210301 AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/2021_03_01’;
CREATE DIRECTORY dms_archived_log_20210302 AS ‘DB_RECOVERY_FILE_DEST>/SID>/archivelog/2021_03_02’; 
...

    4. Criar uma tarefa do programador do Oracle que seja executada diariamente e criar o diretório necessário.

Utilizar um banco de dados gerenciado pelo usuário no Oracle Cloud Infrastructure (OCI) como origem da CDC no AWS DMS

Um banco de dados gerenciado pelo usuário é um banco de dados que você configura e controla, como um banco de dados Oracle criado em uma máquina virtual (VM), bare metal ou servidor Exadata. Ou bancos de dados que você configura e controla que são executados em uma infraestrutura dedicada, como o Oracle Cloud Infrastructure (OCI). As informações a seguir descrevem os privilégios e as configurações necessárias ao utilizar um banco de dados Oracle gerenciado pelo usuário no OCI como origem para a captura de dados de alteração (CDC) no AWS DMS.

Para configurar um banco de dados Oracle gerenciado pelo usuário hospedado pelo OCI como origem para a captura de dados de alteração

  1. Conceda os privilégios da conta de usuário necessários para utilizar um banco de dados de origem do Oracle gerenciado pelo usuário no OCI. Para obter mais informações, consulte Privilégios de conta para um endpoint de origem do Oracle autogerenciado.

  2. Conceda os privilégios da conta necessários ao utilizar o Binary Reader para acessar os redo logs. Para obter mais informações, consulte Privilégios da conta necessários ao utilizar o Binary Reader.

  3. Adicione os privilégios da conta necessários ao utilizar o Binary Reader com o Oracle Automatic Storage Management (ASM). Para obter mais informações, consulte Privilégios adicionais da conta necessários ao utilizar o Binary Reader com o Oracle ASM.

  4. Configure o registro em log suplementar. Para obter mais informações, consulte Configuração do registro em log suplementar.

  5. Configure a criptografia de TDE. Para obter mais informações, consulte Métodos de criptografia ao utilizar um banco de dados Oracle como um endpoint de origem.

As limitações a seguir se aplicam ao replicar dados de um banco de dados de origem do Oracle no Oracle Cloud Infrastructure (OCI).

Limitações

  • O DMS não suporta o uso do Oracle LogMiner para acessar os redo logs.

  • O DMS não é compatível com o banco de dados autônomo.

Trabalhando com um banco AWS de dados Oracle gerenciado como fonte para AWS DMS

Um banco de dados AWS gerenciado é um banco de dados que está em um serviço da Amazon, como Amazon RDS, Amazon Aurora ou Amazon S3. A seguir, você pode encontrar os privilégios e configurações que você precisa definir ao usar um banco de dados Oracle AWS gerenciado com o. AWS DMS

Privilégios de conta de usuário necessários em uma fonte Oracle AWS gerenciada para AWS DMS

Conceda os seguintes privilégios à conta de usuário do Oracle especificada na definição do endpoint de origem do Oracle.

Importante

Para todos os valores de parâmetros, como db_user e any-replicated-table, o Oracle pressupõe que o valor está todo em letras maiúsculas, a menos que você especifique o valor com um identificador que diferencia letras maiúsculas de minúsculas. Por exemplo, suponha que você crie um valor de db_user sem utilizar aspas, como em CREATE USER myuser ou CREATE USER MYUSER. Nesse caso, o Oracle identifica e armazena o valor como todo em maiúsculas (MYUSER). Se você utilizar aspas, como em CREATE USER "MyUser" ouCREATE USER 'MyUser', o Oracle identificará e armazenará o valor com distinção entre maiúsculas e minúsculas que você especificar (MyUser).

GRANT CREATE SESSION to db_user;
GRANT SELECT ANY TRANSACTION to db_user;
GRANT SELECT on DBA_TABLESPACES to db_user;
GRANT SELECT ON any-replicated-table to db_user;
GRANT EXECUTE on rdsadmin.rdsadmin_util to db_user;
 -- For Oracle 12c or higher:
GRANT LOGMINING to db_user; – Required only if the Oracle version is 12c or higher.

Além disso, conceda as permissões SELECT e EXECUTE em objetos SYS utilizando o procedimento do Amazon RDS rdsadmin.rdsadmin_util.grant_sys_object conforme mostrado. Para obter mais informações, consulte Conceder privilégios SELECT ou EXECUTE a objetos SYS.

exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_VIEWS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_PARTITIONS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_INDEXES', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TABLES', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_USERS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CATALOG', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONSTRAINTS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONS_COLUMNS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_IND_COLUMNS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_LOG_GROUPS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$CONTAINERS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS', 'db_user', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','db_user','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR', 'db_user', 'EXECUTE');

-- (as of Oracle versions 12.1 and higher)
exec rdsadmin.rdsadmin_util.grant_sys_object('REGISTRY$SQLPATCH', 'db_user', 'SELECT');

-- (for Amazon RDS Active Dataguard Standby (ADG))
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STANDBY_LOG', 'db_user', 'SELECT'); 

-- (for transparent data encryption (TDE))

exec rdsadmin.rdsadmin_util.grant_sys_object('ENC$', 'db_user', 'SELECT'); 
               
-- (for validation with LOB columns)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_CRYPTO', 'db_user', 'EXECUTE');
                    
-- (for binary reader)
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DIRECTORIES','db_user','SELECT'); 
                    
-- Required when the source database is Oracle Data guard, and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher.

exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATAGUARD_STATS', 'db_user', 'SELECT');

Para obter mais informações sobre como utilizar o Amazon RDS Active Dataguard Standby (ADG) com o AWS DMS , consulte Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS.

Para obter mais informações sobre como usar o Oracle TDE com AWS DMS, consulteMétodos de criptografia suportados para usar o Oracle como fonte para AWS DMS.

Pré-requisitos para tratar transações abertas do Oracle Standby

Ao usar AWS DMS as versões 3.4.6 e superiores, execute as etapas a seguir para lidar com transações abertas para o Oracle Standby.

  1. Crie um link de banco de dados nomeado AWSDMS_DBLINK no banco de dados primário. O DMS_USER utilizará o link de banco de dados para conectar-se ao banco de dados primário. Observe que o link de banco de dados é executado na instância em espera para consultar as transações abertas em execução no banco de dados primário. Veja o exemplo a seguir. 

    CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK 
   CONNECT TO DMS_USER IDENTIFIED BY DMS_USER_PASSWORD
   USING '(DESCRIPTION=
            (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP)(PORT=PORT))
            (CONNECT_DATA=(SERVICE_NAME=SID))
          )';

  2. Verifique se a conexão ao link de banco de dados que utiliza o DMS_USER está estabelecida conforme mostrado no exemplo a seguir.

    select 1 from dual@AWSDMS_DBLINK

Configurando uma fonte Oracle AWS gerenciada para AWS DMS

Antes de usar um banco AWS de dados Oracle gerenciado como fonte para AWS DMS, execute as seguintes tarefas para o banco de dados Oracle:

  • Ative backups automáticos. Para obter mais informações sobre como ativar backups automáticos, consulte Ativar backups automáticos no Guia do usuário do Amazon RDS.

  • Configure o registro em log suplementar.

  • Configure o arquivamento. O arquivamento dos redo logs da sua instância de banco de dados Amazon RDS for Oracle AWS DMS permite recuperar as informações de log usando o LogMiner Oracle ou o Binary Reader.

Como configurar o arquivamento

  1. Execute o comando rdsadmin.rdsadmin_util.set_configuration para configurar o arquivamento.

    Por exemplo, para reter os redo logs arquivados por 24 horas, execute o comando a seguir.

    exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
commit;
    nota

    A confirmação é necessária para que uma alteração entre em vigor.

  2. Verifique se o armazenamento tem espaço suficiente para os redo logs arquivados durante o período de retenção especificado. Por exemplo, se o período de retenção for de 24 horas, calcule o tamanho total dos redo logs arquivados acumulados em uma hora típica de processamento de transações e multiplique esse total por 24. Compare esse total calculado de 24 horas com o espaço de armazenamento disponível e decida se você tem espaço de armazenamento suficiente para tratar o processamento de transações de um total 24 horas.

Como configurar o registro em log suplementar

  1. Execute o comando a seguir para ativar o registro em log suplementar no nível de banco de dados.

    exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

  2. O exemplo a seguir ativa o registro em log suplementar de chave primária.

    exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

  3. (Opcional) Ative o registro em log suplementar em nível de chave no nível da tabela.

    O banco de dados de origem incorre em pequenos custos quando o registro em log suplementar em nível de chave está ativado. Portanto, se estiver migrando apenas um subconjunto das tabelas, ative o registro em log suplementar de nível de chave no nível da tabela. Para ativar o registro em log suplementar de nível de chave no nível da tabela, execute o seguinte comando.

    alter table table_name add supplemental log data (PRIMARY KEY) columns;

Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS

Você pode configurar AWS DMS para acessar os redo logs de origem da instância Amazon RDS for Oracle usando o Binary Reader for CDC.

nota

Para usar o Oracle LogMiner, os privilégios mínimos de conta de usuário necessários são suficientes. Para ter mais informações, consulte Privilégios de conta de usuário necessários em uma fonte Oracle AWS gerenciada para AWS DMS.

Para usar o AWS DMS Binary Reader, especifique configurações adicionais e atributos de conexão extras para o endpoint de origem Oracle, dependendo da sua AWS DMS versão.

A compatibilidade com o Binary Reader está disponível nas seguintes versões do Amazon RDS para Oracle:

  • Oracle 11.2, versões 11.2.0.4V11 e superior

  • Oracle 12.1, versões 12.1.0.2.V7 e superior

  • Oracle 12.2, todas as versões

  • Oracle 18.0, todas as versões

  • Oracle 19.0, todas as versões

Como configurar a CDC utilizando o Binary Reader

  1. Faça login no banco de dados de origem do Amazon RDS para Oracle como o usuário mestre e execute os seguintes procedimentos armazenados para criar os diretórios em nível de servidor.

    exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;

  2. Conceda os seguintes privilégios à conta de usuário do Oracle utilizada para acessar o endpoint de origem do Oracle:

    GRANT READ ON DIRECTORY ONLINELOG_DIR TO db_user;
GRANT READ ON DIRECTORY ARCHIVELOG_DIR TO db_user;

  3. Defina os atributos de conexão adicionais a seguir no endpoint de origem Amazon RDS Oracle.

    • Para as versões 11.2 e 12.1 do RDS Oracle, defina o seguinte.

      useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false;useAlternateFolderForOnline=true;
oraclePathPrefix=/rdsdbdata/db/{$DATABASE_NAME}_A/;usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true;

    • Para as versões 12.2, 18.0 e 19.0 do RDS Oracle, defina o seguinte.

      useLogminerReader=N;useBfile=Y;
nota

Verifique se não há nenhum espaço em branco após o separador de ponto e vírgula (;) em várias configurações de atributo, por exemplo, oneSetting;thenAnother.

Para obter mais informações para configurar uma tarefa de CDC, consulte Configuração da CDC em um banco de dados Oracle de origem.

Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS

Verifique os seguintes pré-requisitos para utilizar o Amazon RDS para Oracle Standby como origem ao utilizar o Binary Reader para CDC no AWS DMS:

  • Utilize o usuário mestre do Oracle para configurar o Binary Reader.

  • Certifique-se de que AWS DMS atualmente suporta o uso somente do Oracle Active Data Guard Standby.

Depois de fazer isso, utilize o procedimento a seguir para utilizar o RDS para Oracle Standby como origem ao utilizar o Binary Reader para CDC.

Como configurar um RDS para Oracle Standby como origem ao utilizar o Binary Reader para CDC

  1. Faça login na instância primária do RDS para Oracle como usuário mestre.

  2. Execute os seguintes procedimentos armazenados conforme documentado no Guia do usuário do Amazon RDS para criar os diretórios no nível do servidor.

    exec rdsadmin.rdsadmin_master_util.create_archivelog_dir;
exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;

  3. Identifique os diretórios criados na etapa 2.

    SELECT directory_name, directory_path FROM all_directories
WHERE directory_name LIKE ( 'ARCHIVELOG_DIR_%' )
        OR directory_name LIKE ( 'ONLINELOG_DIR_%' )

    Por exemplo, o código anterior exibe uma lista de diretórios como a seguinte.

    Table showing directory names and their corresponding paths for archive and online logs.

  4. Conceda o privilégio Read nos diretórios anteriores à conta de usuário Oracle utilizada para acessar o Oracle Standby.

    GRANT READ ON DIRECTORY ARCHIVELOG_DIR_A TO db_user;
GRANT READ ON DIRECTORY ARCHIVELOG_DIR_B TO db_user;
GRANT READ ON DIRECTORY ONLINELOG_DIR_A TO db_user;
GRANT READ ON DIRECTORY ONLINELOG_DIR_B TO db_user;

  5. Execute uma troca de log de arquivamento na instância primária. Isso garante que as alterações de ALL_DIRECTORIES também sejam transferidas para o Oracle Standby.

  6. Execute uma consulta ALL_DIRECTORIES no Oracle Standby para confirmar se as alterações foram aplicadas.

  7. Crie um endpoint de origem para o Oracle Standby usando o AWS DMS Management Console ou AWS Command Line Interface ()AWS CLI. Ao criar o endpoint, especifique os seguintes atributos de conexão adicionais.

    useLogminerReader=N;useBfile=Y;archivedLogDestId=1;additionalArchivedLogDestId=2

  8. Depois de criar o endpoint, use Testar conexão de endpoint na página Criar endpoint do console ou o AWS CLI test-connection comando para verificar se a conectividade foi estabelecida.

Limitações no uso da Oracle como fonte para AWS DMS

As seguintes limitações se aplicam quando um banco de dados Oracle é utilizado como origem do AWS DMS:

  • AWS DMS oferece suporte aos tipos de dados Oracle Extended na AWS DMS versão 3.5.0 e superior.

  • AWS DMS não suporta nomes de objetos longos (mais de 30 bytes).

  • AWS DMS não oferece suporte a índices baseados em funções.

  • Se você gerenciar o registro em log suplementar e realizar transformações em qualquer uma das colunas, verifique se o registro em log suplementar está ativado para todos os campos e colunas. Para obter mais informações sobre como configurar o registro em log suplementar, consulte os seguintes tópicos.

  • AWS DMS não oferece suporte ao banco de dados raiz de contêineres multilocatários (CDB$ROOT). Ele é compatível com um PDB utilizando o Binary Reader.

  • AWS DMS não suporta restrições diferidas.

  • Na AWS DMS versão 3.5.1 e superior, os LOBs seguros são suportados somente por meio da realização de uma pesquisa de LOB.

  • AWS DMS suporta a rename table table-name to new-table-name sintaxe de todas as versões 11 e superiores do Oracle suportadas. Essa sintaxe não é compatível para nenhum banco de dados de origem Oracle versão 10.

  • AWS DMS não replica os resultados da instrução DDL. ALTER TABLE ADD column data_type DEFAULT default_value Em vez de replicar default_value para o destino, ele define a nova coluna como NULL.

  • Ao usar a AWS DMS versão 3.4.7 ou superior, para replicar as alterações resultantes das operações de partição ou subpartição, faça o seguinte antes de iniciar uma tarefa do DMS.

    • Crie manualmente a estrutura da tabela particionada (DDL);

    • Verifique se a DDL é a mesma na origem e no destino do Oracle;

    • Defina o atributo de conexão adicional enableHomogenousPartitionOps=true.

    Para obter mais informações sobre enableHomogenousPartitionOps, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS. Além disso, observe que em tarefas FULL+CDC, o DMS não replica as alterações de dados capturadas como parte das alterações em cache. Nesse caso de uso, recrie a estrutura da tabela no destino do Oracle e recarregue as tabelas em questão.

    Antes da AWS DMS versão 3.4.7:

    O DMS não replica alterações de dados resultantes de operações de partição ou subpartição (ADD, DROP, EXCHANGE e TRUNCATE). Essas atualizações podem causar os seguintes erros durante a replicação:

    • Para operações ADD, atualizações e exclusões nos dados adicionados podem gerar um aviso de “0 linhas afetadas”.

    • Para operações DROP e TRUNCATE, novas inserções podem gerar erros de “duplicatas”.

    • Operações EXCHANGE podem gerar um aviso de “0 linhas afetadas” e erros de “duplicatas”.

    Para replicar alterações resultantes de operações de partição ou subpartição, recarregue as tabelas em questão. Depois de adicionar uma nova partição vazia, as operações na partição adicionada são replicadas para o destino como normais.

  • AWS DMS versões anteriores à 3.4 não suportam alterações de dados no destino que resultam da execução da CREATE TABLE AS instrução na fonte. No entanto, a nova tabela é criada no destino.

  • AWS DMS não captura as alterações feitas pelo DBMS_REDEFINITION pacote Oracle, por exemplo, os metadados da tabela e o OBJECT_ID campo.

  • AWS DMS mapeia colunas BLOB e CLOB vazias para o NULL alvo.

  • Ao capturar alterações com o Oracle 11 LogMiner, uma atualização em uma coluna CLOB com um comprimento de string maior que 1982 é perdida e o destino não é atualizado.

  • Durante a captura de dados de alteração (CDC), AWS DMS não oferece suporte a atualizações em lote em colunas numéricas definidas como chave primária.

  • AWS DMS não suporta determinados UPDATE comandos. O exemplo a seguir é um comando UPDATE não compatível.

    UPDATE TEST_TABLE SET KEY=KEY+1;

    Aqui, TEST_TABLE é o nome da tabela e KEY é uma coluna numérica definida como chave primária.

  • AWS DMS não suporta o modo LOB completo para carregar colunas LONG e LONG RAW. Em vez disso, é possível utilizar o modo LOB limitado para migrar esses tipos de dados para um destino do Oracle. No modo LOB limitado, AWS DMS trunca todos os dados de 64 KB definidos como colunas LONG ou LONG RAW com mais de 64 KB.

  • AWS DMS não suporta o modo LOB completo para carregar colunas XMLTYPE. Em vez disso, é possível utilizar o modo LOB limitado para migrar colunas XMLTYPE para um destino do Oracle. No modo LOB limitado, o DMS trunca todos os dados maiores que a variável “Tamanho máximo de LOB” definida pelo usuário. O valor máximo recomendado para “Tamanho máximo de LOB” é 100 MB.

  • AWS DMS não replica tabelas cujos nomes contêm apóstrofos.

  • AWS DMS suporta CDC a partir de visualizações materializadas. Mas o DMS não é compatível com a CDC de nenhuma outra visualização.

  • AWS DMS não oferece suporte ao CDC para tabelas organizadas por índice com um segmento de estouro.

  • AWS DMS não suporta a Drop Partition operação para tabelas particionadas por referência com enableHomogenousPartitionOps definido como. true

  • Quando você usa o Oracle LogMiner para acessar os redo logs, AWS DMS tem as seguintes limitações:

    • Somente para o Oracle 12, AWS DMS não replica nenhuma alteração nas colunas LOB.

    • Para todas as versões do Oracle, AWS DMS não replica o resultado das UPDATE operações em colunas XMLTYPE LOB.

    • AWS DMS não suporta transações XA na replicação ao usar o Oracle LogMiner.

    • O Oracle LogMiner não suporta conexões com um banco de dados conectável (PDB). Para conectar-se a um PDB, acesse os redo logs utilizando o Binary Reader.

    • As operações SHRINK SPACE não são compatíveis.

  • Quando você usa o Binary Reader, AWS DMS tem as seguintes limitações:

    • Ele não é compatível com clusters de tabela.

    • Ele é compatível somente com operações SHRINK SPACE em nível da tabela. Esse nível inclui a tabela completa, as partições e as subpartições.

    • Ele não é compatível com alterações em tabelas organizadas por índice com compactação de chaves.

    • Ele não é compatível com a implementação de redo logs on-line em dispositivos brutos.

    • O Binary Reader é compatível com a TDE somente para bancos de dados Oracle autogerenciados, uma vez que o RDS para Oracle não é compatível com a recuperação de senha de carteira para chaves de criptografia da TDE.

  • AWS DMS não suporta conexões com uma fonte Oracle do Amazon RDS usando um proxy Oracle Automatic Storage Management (ASM).

  • AWS DMS não oferece suporte a colunas virtuais.

  • AWS DMS não suporta o tipo de ROWID dados ou visualizações materializadas com base em uma coluna ROWID.

    AWS DMS tem suporte parcial para Oracle Materialized Views. Para cargas máximas, o DMS pode fazer uma cópia da carga máxima de uma visão materializada do Oracle. O DMS copia a visão materializada como uma tabela base para o sistema de destino e ignora todas as colunas ROWID na visão materializada. Para a replicação contínua (CDC), o DMS tenta replicar as alterações nos dados da visão materializada, mas os resultados podem não ser ideais. Especificamente, se a visão materializada estiver completamente atualizada, o DMS replica exclusões individuais de todas as linhas, seguidas por inserções individuais em todas as linhas. Esse é um exercício que consome muitos recursos e pode ter um desempenho inadequado em visões materializadas com um grande número de linhas. Para a replicação contínua em que as visões materializadas fazem uma atualização rápida, o DMS tenta processar e replicar as alterações de dados de atualização rápida. Em ambos os casos, o DMS ignora qualquer coluna ROWID na visão materializada.

  • AWS DMS não carrega nem captura tabelas temporárias globais.

  • Para destinos do S3 que utilizam a replicação, ative o registro em log suplementar em cada coluna para que as atualizações da linha de origem possam capturar cada valor da coluna. Veja a seguir um exemplo: alter table yourtablename add supplemental log data (all) columns;.

  • Uma atualização de uma linha com uma chave exclusiva composta que contém null não pode ser replicada no destino.

  • AWS DMS não suporta o uso de várias chaves de criptografia Oracle TDE no mesmo endpoint de origem. Cada endpoint pode ter somente um atributo para o nome da chave de criptografia da TDE "securityDbEncryptionName" e uma senha da TDE para essa chave.

  • Ao replicar do Amazon RDS for Oracle, o TDE é suportado somente com tablespace criptografado e usando Oracle. LogMiner

  • AWS DMS não suporta várias operações de renomeação de tabelas em rápida sucessão.

  • Ao usar o Oracle 19.0 como fonte, AWS DMS não oferece suporte aos seguintes recursos:

    • Redirecionamento de DML do Data-guard

    • Tabelas particionadas híbridas

    • Contas Oracle somente de esquemas

  • AWS DMS não suporta a migração de tabelas ou visualizações do tipo BIN$ ouDR$.

  • A partir do Oracle 18.x, AWS DMS não oferece suporte à captura de dados de alteração (CDC) do Oracle Express Edition (Oracle Database XE).

  • Ao migrar dados de uma coluna CHAR, o DMS trunca todos os espaços à direita.

  • AWS DMS não oferece suporte à replicação a partir de contêineres de aplicativos.

  • AWS DMS não suporta a execução do Oracle Flashback Database e dos pontos de restauração, pois essas operações afetam a consistência dos arquivos Oracle Redo Log.

  • O procedimento de carga direta INSERT com a opção de execução paralela não é compatível nos seguintes casos:

    • Tabelas não compactadas com mais de 255 colunas

    • O tamanho da linha excede 8K

    • Tabelas do Exadata HCC

    • Banco de dados em execução na plataforma Big Endian

  • Uma tabela de origem sem chave primária ou exclusiva exige que o registro em log suplementar ALL COLUMN esteja ativado. Ele cria mais atividades no redo log e pode aumentar a latência da CDC do DMS.

  • AWS DMS não migra dados de colunas invisíveis em seu banco de dados de origem. Para incluir essas colunas no escopo da migração, utilize a instrução ALTER TABLE para tornar essas colunas visíveis.

Suporte de SSL para um endpoint do Oracle

AWS DMS Os endpoints Oracle oferecem suporte a SSL V3 para os modos none e verify-ca SSL. Para utilizar SSL com um endpoint do Oracle, carregue o Oracle Wallet para o endpoint, em vez de nos arquivos de certificado .pem.

Utilizar um certificado existente para SSL no Oracle

Para utilizar uma instalação cliente existente do Oracle e criar o arquivo Oracle Wallet a partir de um arquivo de certificado CA, siga as seguintes etapas.

Como utilizar uma instalação cliente existente do Oracle para SSL no Oracle com o AWS DMS

  1. Defina a variável do sistema ORACLE_HOME como local do seu diretório dbhome_1, executando o comando a seguir.

    
prompt>export ORACLE_HOME=/home/user/app/user/product/12.1.0/dbhome_1

  2. Anexe $ORACLE_HOME/lib ao sistema variável LD_LIBRARY_PATH.

    
prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib

  3. Crie um diretório para o Oracle Wallet em $ORACLE_HOME/ssl_wallet.

    
prompt>mkdir $ORACLE_HOME/ssl_wallet

  4. Coloque o arquivo .pem de certificado da CA no diretório ssl_wallet. Se você utilizar o Amazon RDS, poderá baixar o arquivo raiz do certificado a CA rds-ca-2015-root.pem hospedado pelo Amazon RDS. Para obter mais informações sobre como baixar esse arquivo, consulte Utilizar o SSL/TLS para criptografar uma conexão com uma instância de banco de dados no Guia do usuário do Amazon RDS.

  5. Execute os seguintes comandos para criar o Oracle Wallet.

    
prompt>orapki wallet create -wallet $ORACLE_HOME/ssl_wallet -auto_login_only
prompt>orapki wallet add -wallet $ORACLE_HOME/ssl_wallet -trusted_cert -cert 
   $ORACLE_HOME/ssl_wallet/ca-cert.pem -auto_login_only

Ao concluir as etapas anteriores, é possível importar o arquivo wallet com a chamada de API ImportCertificate, especificando o parâmetro certificate-wallet. Utilize o certificado wallet importado ao selecionar verify-ca como modo SSL ao criar ou modificar o seu endpoint do Oracle.

nota

As carteiras Oracle são arquivos binários. AWS O DMS aceita esses arquivos no estado em que se encontram.

Utilizar um certificado autoassinado para SSL no Oracle

Para utilizar um certificado autoassinado para SSL no Oracle, siga as etapas a seguir, pressupondo uma senha de carteira Oracle de oracle123.

Para usar um certificado autoassinado para Oracle SSL com AWS DMS

  1. Crie um diretório que será utilizado para trabalhar com o certificado autoassinado.

    mkdir -p /u01/app/oracle/self_signed_cert

  2. Altere para o diretório que você criou na etapa anterior.

    cd /u01/app/oracle/self_signed_cert

  3. Crie uma chave raiz.

    openssl genrsa -out self-rootCA.key 2048

  4. Autoassine um certificado raiz utilizando a chave criada na etapa anterior.

    openssl req -x509 -new -nodes -key self-rootCA.key 
        -sha256 -days 3650 -out self-rootCA.pem

    Utilize os parâmetros de entrada, como os seguintes:

    • Country Name (2 letter code) [XX], por exemplo: AU

    • State or Province Name (full name) [], por exemplo: NSW

    • Locality Name (e.g., city) [Default City], por exemplo: Sydney

    • Organization Name (e.g., company) [Default Company Ltd], por exemplo: AmazonWebService

    • Organizational Unit Name (e.g., section) [], por exemplo: DBeng

    • Common Name (e.g., your name or your server's hostname) [], por exemplo: aws

    • Email Address [], por exemplo: abcd.efgh@amazonwebservice.com

  5. Crie um diretório do Oracle Wallet para o banco de dados Oracle.

    mkdir -p /u01/app/oracle/wallet

  6. Crie um novo Oracle Wallet.

    orapki wallet create -wallet "/u01/app/oracle/wallet" -pwd oracle123 -auto_login_local

  7. Adicione o certificado raiz ao Oracle Wallet.

    orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 -trusted_cert 
-cert /u01/app/oracle/self_signed_cert/self-rootCA.pem

  8. Liste os conteúdos do Oracle Wallet. A lista deve incluir o certificado raiz. 

    orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123

    Por exemplo, isso pode ser exibido de forma semelhante à seguinte.

    Requested Certificates:
User Certificates:
Trusted Certificates:
Subject:        CN=aws,OU=DBeng,O= AmazonWebService,L=Sydney,ST=NSW,C=AU

  9. Gere o Certificate Signing Request (CSR - Solicitação de assinatura de certificado) utilizando o utilitário ORAPKI.

    orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 
-dn "CN=aws" -keysize 2048 -sign_alg sha256

  10. Execute o seguinte comando .

    openssl pkcs12 -in /u01/app/oracle/wallet/ewallet.p12 -nodes -out /u01/app/oracle/wallet/nonoracle_wallet.pem

    Isso produz uma saída semelhante à seguinte.

    Enter Import Password:
MAC verified OK
Warning unsupported bag type: secretBag

  11. Coloque "dms" como o nome comum.

    openssl req -new -key /u01/app/oracle/wallet/nonoracle_wallet.pem -out certdms.csr

    Utilize os parâmetros de entrada, como os seguintes:

    • Country Name (2 letter code) [XX], por exemplo: AU

    • State or Province Name (full name) [], por exemplo: NSW

    • Locality Name (e.g., city) [Default City], por exemplo: Sydney

    • Organization Name (e.g., company) [Default Company Ltd], por exemplo: AmazonWebService

    • Organizational Unit Name (e.g., section) [], por exemplo: aws

    • Common Name (e.g., your name or your server's hostname) [], por exemplo: aws

    • Email Address [], por exemplo: abcd.efgh@amazonwebservice.com

    Verifique se isso não é o mesmo que a etapa 4. É possível fazer isso, por exemplo, alterando o nome da unidade organizacional para um nome diferente, conforme mostrado.

    Insira os atributos adicionais a seguir para serem enviados com a solicitação de certificado.

    • A challenge password [], por exemplo: oracle123

    • An optional company name [], por exemplo: aws

  12. Obtenha a assinatura do certificado.

    openssl req -noout -text -in certdms.csr | grep -i signature

    A chave de assinatura desta postagem é sha256WithRSAEncryption.

  13. Utilize o seguinte comando para gerar o arquivo de certificado (.crt):

    openssl x509 -req -in certdms.csr -CA self-rootCA.pem -CAkey self-rootCA.key 
-CAcreateserial -out certdms.crt -days 365 -sha256

    Isso exibe uma saída semelhante à seguinte.

    Signature ok
subject=/C=AU/ST=NSW/L=Sydney/O=awsweb/OU=DBeng/CN=aws
Getting CA Private Key

  14. Adicione o certificado à carteira.

    orapki wallet add -wallet /u01/app/oracle/wallet -pwd oracle123 -user_cert -cert certdms.crt

  15. Visualize a carteira. Deve haver duas entradas. Consulte o seguinte código:

    orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123

  16. Configure o arquivo sqlnet.ora ($ORACLE_HOME/network/admin/sqlnet.ora).

    WALLET_LOCATION =
   (SOURCE =
     (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/wallet/)
     )
   ) 

SQLNET.AUTHENTICATION_SERVICES = (NONE)
SSL_VERSION = 1.0
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_256_CBC_SHA)

  17. Interrompa o receptor do Oracle.

    lsnrctl stop

  18. Adicione entradas para SSL no arquivo listener.ora ($ORACLE_HOME/network/admin/listener.ora).

    SSL_CLIENT_AUTHENTICATION = FALSE
WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/app/oracle/wallet/)
    )
  )

SID_LIST_LISTENER =
 (SID_LIST =
  (SID_DESC =
   (GLOBAL_DBNAME = SID)
   (ORACLE_HOME = ORACLE_HOME)
   (SID_NAME = SID)
  )
 )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

  19. Configure o arquivo tnsnames.ora ($ORACLE_HOME/network/admin/tnsnames.ora).

    <SID>=
(DESCRIPTION=
        (ADDRESS_LIST = 
                (ADDRESS=(PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
        )
        (CONNECT_DATA =
                (SERVER = DEDICATED)
                (SERVICE_NAME = <SID>)
        )
)

<SID>_ssl=
(DESCRIPTION=
        (ADDRESS_LIST = 
                (ADDRESS=(PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522))
        )
        (CONNECT_DATA =
                (SERVER = DEDICATED)
                (SERVICE_NAME = <SID>)
        )
)

  20. Reinicie o receptor do Oracle.

    lsnrctl start

  21. Mostre o status do receptor do Oracle.

    lsnrctl status

  22. Teste a conexão SSL ao banco de dados no host local, utilizando sqlplus e a a entrada SSL tnsnames.

    sqlplus -L ORACLE_USER@SID_ssl

  23. Verifique se você se conectou com êxito utilizando SSL.

    SELECT SYS_CONTEXT('USERENV', 'network_protocol') FROM DUAL;

SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
--------------------------------------------------------------------------------
tcps

  24. Altere o diretório para o diretório com o certificado autoassinado.

    cd /u01/app/oracle/self_signed_cert

  25. Crie uma nova carteira Oracle de cliente AWS DMS para usar.

    orapki wallet create -wallet ./ -auto_login_only

  26. Adicione o certificado raiz autoassinado ao Oracle Wallet.

    orapki wallet add -wallet ./ -trusted_cert -cert self-rootCA.pem -auto_login_only

  27. Liste o conteúdo da carteira Oracle AWS DMS para uso. A lista deve incluir o certificado raiz autoassinado.

    orapki wallet display -wallet ./

    Isso produz uma saída semelhante à seguinte.

    Trusted Certificates:
Subject:        CN=aws,OU=DBeng,O=AmazonWebService,L=Sydney,ST=NSW,C=AU

  28. Faça upload da carteira Oracle que você acabou de criar AWS DMS.

Métodos de criptografia suportados para usar o Oracle como fonte para AWS DMS

Na tabela a seguir, você pode encontrar os métodos de criptografia de dados transparente (TDE) que são AWS DMS compatíveis ao trabalhar com um banco de dados de origem Oracle.

Método de acesso de logs redo Espaço de tabela de TDE Coluna de TDE
Oráculo LogMiner Sim Sim
Binary Reader Sim Sim

AWS DMS oferece suporte ao Oracle TDE ao usar o Binary Reader, tanto no nível da coluna quanto no nível do espaço de tabela. Para usar a criptografia TDE AWS DMS, primeiro identifique o local da carteira Oracle em que a chave de criptografia e a senha do TDE estão armazenadas. Identifique a chave de criptografia e a senha corretas da TDE para o endpoint de origem do Oracle.

Para identificar e especificar a chave de criptografia e a senha para a criptografia da TDE

  1. Execute a consulta a seguir para encontrar a carteira de criptografia do Oracle no host do banco de dados Oracle.

    SQL> SELECT WRL_PARAMETER FROM V$ENCRYPTION_WALLET;

WRL_PARAMETER
--------------------------------------------------------------------------------
/u01/oracle/product/12.2.0/dbhome_1/data/wallet/

    Aqui, /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ é a localização da carteira.

  2. Obtenha o ID da chave mestra utilizando uma das seguintes opções de criptografia, dependendo de qual delas retorna esse valor.

    1. Para a criptografia em nível de tabela ou de coluna, execute as consultas a seguir.

      SQL> SELECT OBJECT_ID FROM ALL_OBJECTS 
WHERE OWNER='DMS_USER' AND OBJECT_NAME='TEST_TDE_COLUMN' AND OBJECT_TYPE='TABLE';

OBJECT_ID
---------------
81046
SQL> SELECT MKEYID FROM SYS.ENC$ WHERE OBJ#=81046;

MKEYID
------------
AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

      Aqui, AWGDC9glSk8Xv+3bVveiVSg é o ID da chave mestra (MKEYID). Se você obtiver um valor para MKEYID, poderá continuar com a Etapa 3. Caso contrário, continue na Etapa 2.2.

      nota

      Os caracteres à direita da string 'A' (AAA...) não fazem parte do valor.

    2. Para a criptografia em nível de espaço para tabela, execute as consultas a seguir.

      SQL> SELECT TABLESPACE_NAME, ENCRYPTED FROM dba_tablespaces;
TABLESPACE_NAME                ENC
------------------------------ ---
SYSTEM                         NO
SYSAUX                         NO
UNDOTBS1                       NO
TEMP                           NO
USERS                          NO
TEST_ENCRYT                    YES
SQL> SELECT name,utl_raw.cast_to_varchar2( utl_encode.base64_encode('01'||substr(mkeyid,1,4))) || utl_raw.cast_to_varchar2( utl_encode.base64_encode(substr(mkeyid,5,length(mkeyid)))) masterkeyid_base64
FROM (SELECT t.name, RAWTOHEX(x.mkid) mkeyid FROM v$tablespace t, x$kcbtek x WHERE t.ts#=x.ts#)
WHERE name = 'TEST_ENCRYT';

NAME                           MASTERKEYID_BASE64
------------------------------ ----------------------------------
TEST_ENCRYT                    AWGDC9glSk8Xv+3bVveiVSg=

      Aqui, AWGDC9glSk8Xv+3bVveiVSg é o ID da chave mestra (TEST_ENCRYT). Se as etapas 2.1 e 2.2 retornarem um valor, elas serão sempre idênticas.

      O caractere à direita de '=' não faz parte do valor.

  3. Na linha de comando, liste as entradas da carteira de criptografia no host do banco de dados Oracle de origem.

    $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -list
Oracle Secret Store entries:
ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ORACLE.SECURITY.DB.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY
ORACLE.SECURITY.ID.ENCRYPTION.
ORACLE.SECURITY.KB.ENCRYPTION.
ORACLE.SECURITY.KM.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA

    Encontre a entrada que contém o ID da chave mestra que você encontrou na etapa 2 (AWGDC9glSk8Xv+3bVveiVSg). Essa entrada é o nome da chave de criptografia da TDE.

  4. Visualize os detalhes da entrada que você localizou na etapa anterior.

    $ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -viewEntry ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Oracle Secret Store Tool : Version 12.2.0.1.0
Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved.
Enter wallet password:
ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA = AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==

    Digite a senha da carteira para ver o resultado.

    Aqui, o valor à direita de '=' é a senha da TDE.

  5. Especifique o nome da chave de criptografia da TDE para o endpoint de origem do Oracle definindo o atributo de conexão adicional securityDbEncryptionName.

    securityDbEncryptionName=ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

  6. Forneça a senha da TDE associada para essa chave no console como parte do valor da Senha da origem do Oracle. Utilize a ordem a seguir para formatar os valores de senha separados por vírgula, finalizados pelo valor da senha da TDE.

    Oracle_db_password,ASM_Password,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==

    Especifique os valores de senha nessa ordem, independentemente da configuração do banco de dados Oracle. Por exemplo, se estiver utilizando a TDE, mas o banco de dados Oracle não estiver utilizando o ASM, especifique os valores de senha relevantes na ordem separada por vírgulas a seguir.

    Oracle_db_password,,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==

Se as credenciais do TDE que você especificar estiverem incorretas, a tarefa de AWS DMS migração não falhará. No entanto, a tarefa também não lê nem aplica alterações contínuas de replicação ao banco de dados de destino. Depois de iniciar a tarefa, monitore as Estatísticas da tabela na página de tarefas de migração no console para garantir que as alterações sejam replicadas.

Se um DBA alterar os valores das credenciais da TDE para o banco de dados Oracle enquanto a tarefa estiver em execução, a tarefa falhará. A mensagem de erro contém o novo nome da chave de criptografia da TDE. Para especificar novos valores e reiniciar a tarefa, utilize o procedimento anterior.

Importante

Não é possível manipular uma carteira da TDE criada em um local do Oracle Automatic Storage Management (ASM) porque comandos em nível do sistema operacional, como cp, mv, orapki e mkstore, corrompem os arquivos da carteira armazenados em um local do ASM. Essa restrição é específica de arquivos de carteira da TDE armazenados somente em um local do ASM, mas não para arquivos de carteira da TDE armazenados em um diretório local do sistema operacional.

Para manipular uma carteira da TDE armazenada no ASM com comandos em nível do sistema operacional, crie um keystore local e mescle o keystore do ASM no keystore local da seguinte forma:

  1. Crie um keystore local.

    ADMINISTER KEY MANAGEMENT create keystore file system wallet location identified by wallet password;

  2. Mescle o keystore do ASM com o keystore local.

    ADMINISTER KEY MANAGEMENT merge keystore ASM wallet location identified by wallet password into existing keystore file system wallet location identified by wallet password with backup;

Para listar as entradas da carteira de criptografia e a senha da TDE, execute as etapas 3 e 4 no keystore local.

Métodos de compactação suportados para usar o Oracle como fonte para AWS DMS

Na tabela a seguir, você pode descobrir quais métodos de compactação são AWS DMS compatíveis ao trabalhar com um banco de dados de origem Oracle. Como mostra a tabela, o suporte à compactação depende da versão do seu banco de dados Oracle e se o DMS está configurado para usar o Oracle LogMiner para acessar os redo logs.

Version (Versão) Basic OLTP

HCC (do Oracle 11g R2 ou mais recente)

 Outros
Oracle 10 Não N/D N/D Não
Oracle 11 ou mais recente — Oracle LogMiner Sim Sim Sim Sim — Qualquer método de compactação suportado pela Oracle LogMiner.
Oracle 11 ou mais recente: Binary Reader Sim Sim Sim, para obter mais informações, consulte a observação a seguir. Sim
nota

Quando o endpoint de origem Oracle é configurado para utilizar o Binary Reader, o nível Query Low do método de compactação HCC tem suporte somente para tarefas de carga máxima.

Replicando tabelas aninhadas usando o Oracle como fonte para AWS DMS

AWS DMS suporta a replicação de tabelas Oracle contendo colunas que são tabelas aninhadas ou tipos definidos. Para ativar essa funcionalidade, adicione a seguinte configuração do atributo de conexão adicional ao endpoint de origem Oracle.

allowSelectNestedTables=true;

AWS DMS cria as tabelas de destino a partir de tabelas aninhadas da Oracle como tabelas pai e filho regulares no destino sem uma restrição exclusiva. Para acessar os dados corretos no destino, junte as tabelas pai e filho. Para fazer isso, primeiro crie manualmente um índice não exclusivo na coluna NESTED_TABLE_ID na tabela filho de destino. É possível utilizar a coluna NESTED_TABLE_ID na cláusula de junção ON juntamente com a coluna pai que corresponde ao nome da tabela filho. Além disso, a criação desse índice melhora o desempenho quando os dados da tabela secundária de destino são atualizados ou excluídos pelo AWS DMS. Para ver um exemplo, consulte Exemplo de junção para tabelas pai e filho no destino.

É recomendável configurar a tarefa para ser interrompida após a conclusão de uma carga máxima. Crie esses índices não exclusivos para todas as tabelas filho replicadas no destino e retome a tarefa.

Se uma tabela aninhada capturada for adicionada a uma tabela principal existente (capturada ou não capturada), ela AWS DMS será tratada corretamente. No entanto, o índice não exclusivo para a tabela de destino correspondente não é criado. Nesse caso, se a tabela filho de destino se tornar extremamente grande, o desempenho pode ser afetado. Nesse caso, é recomendável interromper a tarefa, criar o índice e retomar a tarefa.

Depois que as tabelas aninhadas forem replicadas para o destino, solicite que o administrador de banco de dados execute uma junção nas tabelas pai e filho correspondentes para nivelar os dados.

Pré-requisitos para replicação de tabelas aninhadas Oracle como origem

Replique tabelas pai para todas as tabelas aninhadas replicadas. Inclua as tabelas principais (as tabelas que contêm a coluna da tabela aninhada) e as tabelas secundárias (ou seja, aninhadas) nos mapeamentos da AWS DMS tabela.

Tipos de tabela aninhada Oracle com suporte como origem

AWS DMS suporta os seguintes tipos de tabela aninhada Oracle como fonte:

  • Tipo de dados

  • Objeto definido pelo usuário

Limitações de suporte do AWS DMS para tabelas aninhadas Oracle como origem

AWS DMS tem as seguintes limitações em seu suporte às tabelas aninhadas da Oracle como fonte:

  • AWS DMS suporta somente um nível de aninhamento de tabelas.

  • AWS DMS o mapeamento de tabelas não verifica se a tabela ou tabelas principal e secundária estão selecionadas para replicação. Ou seja, é possível selecionar uma tabela pai sem uma tabela filho ou uma tabela filho sem pai.

Como o AWS DMS replica tabelas aninhadas Oracle como origem

AWS DMS replica tabelas principais e aninhadas para o destino da seguinte forma:

  • AWS DMS cria a tabela principal idêntica à fonte. Ele define a coluna aninhada no pai como RAW(16) e inclui uma referência às tabelas aninhadas do pai em sua coluna NESTED_TABLE_ID.

  • AWS DMS cria a tabela secundária idêntica à fonte aninhada, mas com uma coluna adicional chamadaNESTED_TABLE_ID. Essa coluna tem o mesmo tipo e valor que a coluna aninhada pai correspondente e tem o mesmo significado.

Exemplo de junção para tabelas pai e filho no destino

Para nivelar a tabela pai, execute uma junção entre as tabelas pai e filho, conforme mostrado no exemplo a seguir:

  1. Crie a tabela de Type.

    CREATE OR REPLACE TYPE NESTED_TEST_T AS TABLE OF VARCHAR(50);

  2. Crie a tabela pai com uma coluna do tipo NESTED_TEST_T, conforme definido anteriormente.

    CREATE TABLE NESTED_PARENT_TEST (ID NUMBER(10,0) PRIMARY KEY, NAME NESTED_TEST_T) NESTED TABLE NAME STORE AS NAME_KEY;

  3. Nivele a tabela NESTED_PARENT_TEST utilizando uma junção com a tabela filho NAME_KEY em que CHILD.NESTED_TABLE_ID corresponde a PARENT.NAME.

    SELECT … FROM NESTED_PARENT_TEST PARENT, NAME_KEY CHILD WHERE CHILD.NESTED_
TABLE_ID = PARENT.NAME;

Armazenando REDO no Oracle ASM ao usar o Oracle como fonte para AWS DMS

Para origens Oracle com alta geração de REDO, o armazenamento de REDO no Oracle ASM pode beneficiar o desempenho, especialmente em uma configuração RAC, pois é possível configurar o DMS para distribuir leituras de REDO do ASM em todos os nós do ASM.

Para utilizar essa configuração, utilize o atributo de conexão asmServer. Por exemplo, a seguinte string de conexão distribui leituras de REDO do DMS em três nós do ASM:

asmServer=(DESCRIPTION=(CONNECT_TIMEOUT=8)(ENABLE=BROKEN)(LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node1_ip_address)(PORT=asm_node1_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node2_ip_address)(PORT=asm_node2_port_number))
(ADDRESS=(PROTOCOL=tcp)(HOST=asm_node3_ip_address)(PORT=asm_node3_port_number)))
(CONNECT_DATA=(SERVICE_NAME=+ASM)))

Ao utilizar o NFS para armazenar o REDO do Oracle, é importante garantir que os patches de cliente DNFS (Direct NFS) aplicáveis sejam aplicados, especificamente qualquer patch que resolva o erro 25224242 do Oracle. Para obter informações adicionais, analise a seguinte publicação do Oracle sobre os patches relacionados ao cliente Direct NFS, Patches recomendados para o cliente Direct NFS.

Além disso, para melhorar o desempenho de leitura do NFS, é recomendável aumentar o valor de rsize e wsize em fstab para o volume NFS, conforme mostrado no exemplo a seguir. 

NAS_name_here:/ora_DATA1_archive /u09/oradata/DATA1 nfs rw,bg,hard,nointr,tcp,nfsvers=3,_netdev,
timeo=600,rsize=262144,wsize=262144

Além disso, ajuste o valor de tcp-max-xfer-size da seguinte forma:

vserver nfs modify -vserver vserver -tcp-max-xfer-size 262144

Configurações de endpoint ao usar o Oracle como fonte para AWS DMS

É possível utilizar as configurações de endpoint para configurar o banco de dados de origem Oracle de forma semelhante à utilização de atributos de conexão adicionais. Você especifica as configurações ao criar o endpoint de origem usando o AWS DMS console ou usando o create-endpoint comando no AWS CLI, com a sintaxe --oracle-settings '{"EndpointSetting": "value", ...}' JSON.

A tabela a seguir mostra as configurações de endpoint que podem ser utilizadas com o Oracle como origem.

Nome Descrição
AccessAlternateDirectly

Defina esse atributo como falso para utilizar o Binary Reader para a captura de dados de alteração para um Amazon RDS para Oracle como origem. Isso informa a instância do DMS para não acessar logs de redo por meio de qualquer substituição de prefixo de caminho especificado utilizando o acesso direto a arquivos. Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.

Valor padrão: verdadeiro

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"AccessAlternateDirectly": false}'

AdditionalArchivedLogDestId

Defina esse atributo com ArchivedLogDestId em uma configuração primária em espera. Essa configuração é útil em uma transição quando o banco de dados Oracle Data Guard é utilizado como origem. Nesse caso, AWS DMS precisa saber de qual destino obter os redo logs de arquivamento para ler as alterações. Isso é porque a primária anterior agora é uma instância em espera depois da transição.

Embora AWS DMS ofereça suporte ao uso da RESETLOGS opção Oracle para abrir o banco de dados, nunca use RESETLOGS a menos que seja necessário. Para obter informações adicionais sobre RESETLOGS, consulte Conceitos de reparo do RMAN no Guia do usuário de backup e recuperação do banco de dados Oracle®.

Valores válidos: Ids de destino de arquivamento

Exemplo: --oracle-settings '{"AdditionalArchivedLogDestId": 2}'

AddSupplementalLogging

Defina este atributo para configurar a criação de logs complementares no nível da tabela para o banco de dados Oracle. Esse atributo habilita uma das seguintes opções em todas as tabelas selecionadas para uma tarefa de migração, dependendo dos respectivos metadados:

  • Registro em log suplementar de COLUNAS DE CHAVE PRIMÁRIA

  • Registro em log suplementar de COLUNAS DE CHAVE EXCLUSIVA

  • Registro em log suplementar de TODAS AS COLUNAS

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"AddSupplementalLogging": false}'

nota

Se você utilizar essa opção, ainda precisará ativar a criação de registro em log suplementar no nível do banco de dados, conforme discutido anteriormente.

AllowSelectNestedTables

Defina esse atributo como true para permitir a replicação de tabelas Oracle com colunas que são tabelas aninhadas ou tipos definidos. Para ter mais informações, consulte Replicando tabelas aninhadas usando o Oracle como fonte para AWS DMS.

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"AllowSelectNestedTables": true}'

ArchivedLogDestId

Especifica o ID do destino para os logs redo de restauração arquivados. Esse valor deve ser o mesmo que um número na coluna dest_id da visualização v$archived_log. Se você trabalhar com um destino de redo log adicional, é recomendável utilizar o atributo AdditionalArchivedLogDestId para especificar o ID de destino adicional. Fazer isso aprimora o desempenho ao garantir que os logs corretos sejam acessados no início.

Valor padrão: 1

Valores válidos: número

Exemplo: --oracle-settings '{"ArchivedLogDestId": 1}'

ArchivedLogsOnly

Quando esse campo é definido como Y, AWS DMS só acessa os redo logs arquivados. Se os redo logs arquivados forem armazenados somente no Oracle ASM, a conta do AWS DMS usuário precisará receber privilégios de ASM.

Valor padrão: N

Valores válidos: Y/N

Exemplo: --oracle-settings '{"ArchivedLogsOnly": Y}'

asmUsePLSQLArray (Somente ECA)

Use esse atributo de conexão extra (ECA) ao capturar alterações na fonte com BinaryReader. Essa configuração permite que o DMS armazene 50 leituras em nível do ASM por thread de leitura único ao controlar o número de threads utilizando o atributo parallelASMReadThread. Quando você define esse atributo, o leitor AWS DMS binário usa um bloco PL/SQL anônimo para capturar dados de redo e enviá-los de volta para a instância de replicação como um grande buffer. Isso reduz o número de viagens de ida e volta até a origem. Isso pode melhorar significativamente o desempenho da captura de origem, mas resulta em consumo de memória mais alto de PGA na instância do ASM. Poderão surgir problemas de estabilidade se o destino da memória não for suficiente. É possível utilizar a fórmula a seguir para estimar a utilização total da memória PGA da instância do ASM por uma única tarefa do DMS: number_of_redo_threads * parallelASMReadThreads * 7 MB

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo de ECA: asmUsePLSQLArray=true;

ConvertTimestampWithZoneToUTC

Defina esse atributo como true para converter o valor do timestamp das colunas 'TIMESTAMP WITH TIME ZONE' e 'TIMESTAMP WITH LOCAL TIME ZONE' em UTC. Por padrão, o valor desse atributo é "falso" e os dados serão replicados utilizando o fuso horário do banco de dados de origem.

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"ConvertTimestampWithZoneToUTC": true}'

EnableHomogenousPartitionOps

Defina esse atributo como true ativar a replicação das operações DDL de partição e subpartição do Oracle para migração homogênea do Oracle.

Observe que esse recurso e aprimoramento foram introduzidos na AWS DMS versão 3.4.7.

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"EnableHomogenousPartitionOps": true}'

EnableHomogenousTablespace

Defina esse atributo para habilitar a replicação homogênea de tablespace e criar tabelas ou índices existentes no mesmo tablespace no destino.

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"EnableHomogenousTablespace": true}'

EscapeCharacter

Defina esse atributo como um caractere de escape. Esse caractere de escape permite que um único caractere curinga se comporte como um caractere normal em expressões de mapeamento de tabela. Para ter mais informações, consulte Curingas no mapeamento de tabela.

Valor padrão: nulo

Valores válidos: qualquer caractere que não seja um caractere curinga

Exemplo: --oracle-settings '{"EscapeCharacter": "#"}'

nota

É possível utilizar escapeCharacter somente em nomes de tabelas. Ele não escapa caracteres dos nomes dos esquemas ou dos nomes das colunas.

ExposeViews

É possível extrair dados uma vez de uma visualização, mas não é possível utilizá-los para replicação contínua. Ao extrair dados de uma visualização, a visualização aparece como uma tabela no esquema de destino.

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"ExposeViews": true}'

ExtraArchivedLogDestIds

Especifica os IDs de mais um destino para um ou mais logs redo arquivados. Esses IDs são os valores da coluna dest_id na visualização v$archived_log. Use essa configuração com o atributo de conexão ArchivedLogDestId extra em uma primary-to-single configuração ou primary-to-multiple-standby configuração.

Essa configuração é útil em uma transição quando você utiliza um banco de dados Oracle Data Guard como origem. Nesse caso, AWS DMS precisa de informações sobre de qual destino obter os redo logs arquivados para ler as alterações. AWS DMS precisa disso porque, após a transição, a primária anterior é uma instância em espera.

Valores válidos: Ids de destino de arquivamento

Exemplo: --oracle-settings '{"ExtraArchivedLogDestIds": 1}'

FailTasksOnLobTruncation

Quando definido como true, esse atributo faz com que a tarefa falhe, caso o tamanho real de uma coluna LOB seja superior ao LobMaxSize especificado.

Se a tarefa for definida como modo LOB limitado e essa opção estiver definida como true, a tarefa falhará em vez de truncar os dados de LOB.

Valor padrão: falso

Valores válidos: booleano

Exemplo: --oracle-settings '{"FailTasksOnLobTruncation": true}'

filterTransactionsOfUser (Somente ECA)

Use esse atributo de conexão extra (ECA) para permitir que o DMS ignore transações de um usuário especificado ao replicar dados do Oracle durante o uso. LogMiner É possível passar valores de nome de usuário separados por vírgula, mas eles devem estar em letras MAIÚSCULAS.

Exemplo de ECA: filterTransactionsOfUser=USERNAME;

NumberDataTypeScale

Especifica a escala de números. É possível selecionar um aumento da escala verticalmente para 38 ou selecionar -1 para FLOAT ou -2 para VARCHAR. Por padrão, o tipo de dados NUMBER é convertido para um valor com precisão 38 e escala 10.

Valor padrão: 10

Valores válidos: de -2 a 38 (–2 para VARCHAR, -1 para FLOAT)

Exemplo: --oracle-settings '{"NumberDataTypeScale": 12}'

nota

Selecione uma combinação de escala de precisão, -1 (FLOAT) ou -2 (VARCHAR). O DMS é compatível com qualquer combinação de escala de precisão compatível com o Oracle. Se a precisão for 39 ou superior, selecione -2 (VARCHAR). A NumberDataTypeScale configuração do banco de dados Oracle é usada somente para o tipo de dados NUMBER (sem a precisão explícita e a definição de escala).

OpenTransactionWindow

Fornece o período em minutos para verificar se há transações abertas apenas para tarefas da CDC.

nota

Quando você define como OpenTransactionWindow 1 ou superior, o DMS usa SCN_TO_TIMESTAMP para converter valores de SCN em valores de timestamp. Devido às limitações do banco de dados Oracle, se você especificar um SCN muito antigo como ponto inicial do CDC, o SCN_TO_TIMESTAMP falhará com um ORA-08181 erro e você não poderá iniciar tarefas somente do CDC.

Valor padrão: 0

Valores válidos: um número inteiro de 0 a 240

Exemplo: openTransactionWindow=15;
OraclePathPrefix Defina esse atributo de string como o valor exigido para usar o Binary Reader para capturar dados de alteração para um Amazon RDS for Oracle como origem. Esse valor especifica a raiz padrão do Oracle utilizada para acessar os logs redo. Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.

Valor padrão: nenhum

Valor válido: /rdsdbdata/db/ORCL_A/

Exemplo: --oracle-settings '{"OraclePathPrefix": "/rdsdbdata/db/ORCL_A/"}'
ParallelASMReadThreads

Defina esse atributo para alterar o número de threads que o DMS configura para executar uma captura de dados de alteração (CDC) utilizando o Oracle Automatic Storage Management (ASM). É possível especificar um valor inteiro entre 2 (o padrão) e 8 (o máximo). Use esse atributo junto com o atributo ReadAheadBlocks. Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.

Valor padrão: 2

Valores válidos: um número inteiro de 2 a 8

Exemplo: --oracle-settings '{"ParallelASMReadThreads": 6;}'
ReadAheadBlocks

Defina esse atributo para alterar o número de blocos de leitura antecipada que o DMS configura para executar a CDC utilizando o Oracle Automatic Storage Management (ASM) o armazenamento não ASM NAS. É possível especificar um valor inteiro entre 1000 (o padrão) e 200.000 (o máximo). Use esse atributo junto com o atributo ParallelASMReadThreads. Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.

Valor padrão: 1000

Valores válidos: um número inteiro de 1.000 a 200.000

Exemplo: --oracle-settings '{"ReadAheadBlocks": 150000}'

ReadTableSpaceName

Quando definido como true, esse atributo é compatível com a replicação de espaço para tabela.

Valor padrão: falso

Valores válidos: booleano

Exemplo: --oracle-settings '{"ReadTableSpaceName": true}'
ReplacePathPrefix Defina esse atributo como true para usar o Binary Reader para capturar dados de alteração em um Amazon RDS for Oracle como a origem. Essa configuração informa a instância do DMS para substituir raiz padrão do Oracle pela configuração UsePathPrefix especificada para acessar os logs redo. Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"ReplacePathPrefix": true}'

RetryInterval

Especifica o número de segundos que o sistema espera antes de enviar novamente uma consulta.

Valor padrão: 5

Valores válidos: número a partir de 1

Exemplo: --oracle-settings '{"RetryInterval": 6}'

SecurityDbEncryptionName

Especifica o nome de uma chave utilizada para a criptografia de dados transparente (TDE) das colunas e do espaço para tabela no banco de dados de origem Oracle. Para obter mais informações sobre como definir esse atributo e sua senha associada no endpoint de origem Oracle, consulte Métodos de criptografia suportados para usar o Oracle como fonte para AWS DMS.

Valor padrão: ""

Valores válidos: string

Exemplo: --oracle-settings '{"SecurityDbEncryptionName": "ORACLE.SECURITY.DB.ENCRYPTION.Adg8m2dhkU/0v/m5QUaaNJEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"}'

SpatialSdo2GeoJsonFunctionName

Para origens Oracle versão 12.1 ou anterior migrando para destinos PostgreSQL, utilize esse atributo para converter SDO_GEOMETRY para o formato GEOJSON.

Por padrão, AWS DMS chama a função SDO2GEOJSON personalizada que deve estar presente e acessível ao AWS DMS usuário. Ou é possível criar seu próprio perfil personalizado que imite a operação SDOGEOJSON e definir SpatialSdo2GeoJsonFunctionName para chamá-la.

Valor padrão: SDO2GEOJSON

Valores válidos: string

Exemplo: --oracle-settings '{"SpatialSdo2GeoJsonFunctionName": "myCustomSDO2GEOJSONFunction"}'

StandbyDelayTime

Utilize esse atributo para especificar um tempo em minutos para o atraso na sincronização de espera. Se a origem for um banco de dados em espera do Active Data Guard, utilize esse atributo para especificar o atraso de tempo entre os bancos de dados primário e em espera.

Em AWS DMS, você pode criar uma tarefa do Oracle CDC que usa uma instância standby do Active Data Guard como fonte para replicar as alterações em andamento. Isso elimina a necessidade de se conectar a um banco de dados ativo que pode estar em produção.

Valor padrão: 0

Valores válidos: número

Exemplo: --oracle-settings '{"StandbyDelayTime": 1}'

Observação: ao utilizar o DMS 3.4.6, 3.4.7 e superior, a utilização dessa configuração de conexão é opcional. Na versão mais recente do DMS 3.4.6 e na versão 3.4.7, dms_user deve ter a permissão select ativada em V_$DATAGUARD_STATS, permitindo que o DMS calcule o tempo de atraso em espera.
UseAlternateFolderForOnline Defina esse atributo como true para usar o Binary Reader para capturar dados de alteração em um Amazon RDS for Oracle como a origem. Isso informa a instância do DMS para utilizar qualquer substituição do prefixo especificado para acessar todos os logs redo online, Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.

Valor padrão: falso

Valores válidos: verdadeiro/falso

Exemplo: --oracle-settings '{"UseAlternateFolderForOnline": true}'
UseBfile

Defina esse atributo como Y para capturar dados de alterações utilizando o utilitário Binary Reader. Defina UseLogminerReader como N para definir esse atributo como Y. Para utilizar o Binary Reader com o Amazon RDS para Oracle como a origem, defina atributos adicionais. Para obter mais informações sobre essa configuração e sobre como utilizar o Oracle Automatic Storage Management (ASM), consulte Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC.

Observação: ao definir esse valor como um atributo de conexão adicional (ECA), os valores válidos são "S" e "N". Ao definir esse valor como uma configuração de endpoint, os valores válidos são true e false.

Valor padrão: N

Valores válidos: S/N (ao definir esse valor como ECA); verdadeiro/falso (ao definir esse valor como uma configuração de endpoint).

Exemplo: --oracle-settings '{"UseBfile": Y}'

UseLogminerReader

Defina esse atributo como Y para capturar dados de alteração usando o LogMiner utilitário (o padrão). Defina essa opção como N para que o AWS DMS acesse os logs redo como arquivos binários. Ao definir essa opção como N, adicione também a configuração useBfile=Y. Para obter mais informações sobre essa configuração e sobre a utilização do Oracle Automatic Storage Management (ASM), consulte Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC.

Observação: ao definir esse valor como um atributo de conexão adicional (ECA), os valores válidos são "S" e "N". Ao definir esse valor como uma configuração de endpoint, os valores válidos são true e false.

Valor padrão: Y

Valores válidos: S/N (ao definir esse valor como ECA); verdadeiro/falso (ao definir esse valor como uma configuração de endpoint).

Exemplo: --oracle-settings '{"UseLogminerReader": Y}'
UsePathPrefix Defina esse atributo de string como o valor exigido para usar o Binary Reader para capturar dados de alteração para um Amazon RDS for Oracle como origem. Esse valor especifica o prefixo do caminho utilizado para substituir a raiz padrão do Oracle para acessar os redo logs. Para ter mais informações, consulte Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS.

Valor padrão: nenhum

Valor válido: /rdsdbdata/log/

Exemplo: --oracle-settings '{"UsePathPrefix": "/rdsdbdata/log/"}'

Tipos de dados de origem do Oracle

O endpoint Oracle para AWS DMS suporta a maioria dos tipos de dados Oracle. A tabela a seguir mostra os tipos de dados de origem Oracle que são suportados durante o uso AWS DMS e o mapeamento padrão para AWS DMS os tipos de dados.

nota

Com exceção dos tipos de dados LONG e LONG RAW, ao replicar de uma origem Oracle para um destino Oracle (uma replicação homogênea), todos os tipos de dados de origem e de destino serão idênticos. Mas o tipo de dados LONG será mapeado para CLOB e o tipo de dados LONG RAW será mapeado para BLOB.

Para obter informações sobre como visualizar o tipo de dados mapeado no destino, consulte a seção relativa ao endpoint de destino que você está usando.

Para obter informações adicionais sobre AWS DMS os tipos de dados, consulteTipos de dados do AWS Database Migration Service.

Tipo de dados do Oracle

AWS DMS tipo de dados

BINARY_FLOAT

REAL4

BINARY_DOUBLE

REAL8

BINARY

BYTES

FLOAT (P)

Se a precisão é menor ou igual a 24, utilize REAL4.

Se a precisão for maior que 24, utilize REAL8.

NUMBER (P,S)

Quando a escala for maior que 0, utilize NUMERIC.

Quando a escala for 0:

  • E a precisão for menor ou igual a 2, utilize INT1.

  • E a precisão for maior do que 2 e menor ou igual a 4, utilize INT2.

  • E a precisão for maior do que 4 e menor ou igual a 9, utilize INT4.

  • E a precisão for maior do que 9, utilize NUMERIC.

  • E a precisão for maior ou igual à escala, utilize NUMERIC.

Quando a escala for menor que 0, utilize REAL8.

DATA

DATETIME

INTERVAL YEAR TO MONTH

STRING (com indicação de intervalo de tempo em anos e meses)

INTERVAL DAY TO SECOND

STRING (com indicação de intervalo de tempo em dias e segundos)

TIMESTAMP

DATETIME

TIMESTAMP WITH TIME ZONE

STRING (com indicação de time stamp com fuso horário)

TIMESTAMP WITH LOCAL TIME ZONE

STRING (com indicação de time stamp com fuso horário local)

CHAR

STRING

VARCHAR2

  • CLOB quando o comprimento é maior que 4.000 bytes

  • STRING quando o comprimento é de 4.000 bytes ou menos

NCHAR

WSTRING

NVARCHAR2

  • NCLOB quando o comprimento é maior que 4.000 bytes

  • WSTRING quando o comprimento é de 4.000 bytes ou menos

RAW

BYTES

REAL

REAL8

BLOB

BLOB

Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso de tipos de dados BLOB para uma tarefa específica. AWS DMS suporta tipos de dados BLOB somente em tabelas que incluem uma chave primária.

CLOB

CLOB

Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso de tipos de dados CLOB para uma tarefa específica. Durante o CDC, AWS DMS suporta tipos de dados CLOB somente em tabelas que incluem uma chave primária.

NCLOB

NCLOB

Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso dos tipos de dados NCLOB para uma tarefa específica. Durante o CDC, AWS DMS suporta tipos de dados NCLOB somente em tabelas que incluem uma chave primária.

LONG

CLOB

O tipo de dados LONG não é suportado no modo de aplicação otimizado em lote (modo TurboStream CDC).

Para usar esse tipo de dados com AWS DMS, habilite o uso de LOBs para uma tarefa específica.

Durante o CDC ou com carga total, AWS DMS suporta tipos de dados LOB somente em tabelas que tenham uma chave primária.

Além disso, AWS DMS não suporta o modo LOB completo para carregar colunas LONG. Em vez disso, é possível utilizar o modo LOB limitado para migrar colunas LONG para um destino Oracle. No modo LOB limitado, AWS DMS trunca todos os dados de 64 KB definidos como colunas LONG maiores que 64 KB. Para obter mais informações sobre o suporte a LOB em AWS DMS, consulte Configurando LOB suporte para bancos de dados de origem em uma AWS DMS tarefa

LONG RAW

BLOB

O tipo de dados LONG RAW não é suportado no modo de aplicação otimizado em lote (modo TurboStream CDC).

Para usar esse tipo de dados com AWS DMS, habilite o uso de LOBs para uma tarefa específica.

Durante o CDC ou com carga total, AWS DMS suporta tipos de dados LOB somente em tabelas que tenham uma chave primária.

Além disso, AWS DMS não suporta o modo LOB completo para carregar colunas LONG RAW. Em vez disso, é possível utilizar o modo LOB limitado para migrar colunas LONG RAW para um destino Oracle. No modo LOB limitado, AWS DMS trunca todos os dados de 64 KB definidos como colunas LONG RAW com mais de 64 KB. Para obter mais informações sobre o suporte a LOB em AWS DMS, consulte Configurando LOB suporte para bancos de dados de origem em uma AWS DMS tarefa

XMLTYPE

CLOB

SDO_GEOMETRY

BLOB (quando é uma migração de Oracle para Oracle)

CLOB (quando é uma migração de Oracle para PostgreSQL)

As tabelas do Oracle utilizado como origem com colunas dos tipos de dados a seguir não são compatíveis e não podem ser replicadas. A replicação de colunas com esses tipos de dados resultará em colunas nulas.

  • BFILE

  • ROWID

  • REF

  • UROWID

  • Tipos de dados definidos pelo usuário

  • ANYDATA

  • VARRAY

nota

Colunas virtuais não são compatíveis.

Migrar tipos de dados espaciais do Oracle

Dados espaciais identificam as informações de geometria de um objeto ou local no espaço. Em um banco de dados Oracle, a descrição geométrica de um objeto geográfico é armazenada em um objeto do tipo SDO_GEOMETRY. Dentro desse objeto, a descrição geométrica é armazenada em uma única linha em uma única coluna de uma tabela definida pelo usuário.

AWS DMS suporta a migração do tipo Oracle SDO_GEOMETRY de uma fonte Oracle para um destino Oracle ou PostgreSQL.

Ao migrar tipos de dados espaciais Oracle usando AWS DMS, esteja ciente destas considerações:

  • Ao migrar para um destino Oracle, transfira manualmente as entradas USER_SDO_GEOM_METADATA que incluem informações de tipo.

  • Ao migrar de um endpoint de origem Oracle para um endpoint de destino do PostgreSQL, cria colunas de destino. AWS DMS Essas colunas têm geometria padrão e informações de tipo geográfico com uma dimensão 2D e um identificador de referência espacial (SRID) igual a zero (0). Um exemplo é GEOMETRY, 2, 0.

  • Para origens Oracle versão 12.1 ou anterior migrando para destinos PostgreSQL, converta os objetos SDO_GEOMETRY para o formato GEOJSON utilizando o perfil SDO2GEOJSON ou o atributo de conexão adicional spatialSdo2GeoJsonFunctionName. Para ter mais informações, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS.

  • AWS DMS suporta migrações de colunas espaciais da Oracle somente para o modo LOB completo. AWS DMS não suporta os modos LOB limitado ou LOB embutido. Para obter mais informações sobre o modo LOB, consulte Configurando LOB suporte para bancos de dados de origem em uma AWS DMS tarefa.

  • Como AWS DMS só oferece suporte ao modo LOB completo para migrar colunas espaciais do Oracle, a tabela das colunas precisa de uma chave primária e uma chave exclusiva. Se a tabela não tiver uma chave primária e uma chave exclusiva, a tabela será ignorada na migração.