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á. # Origens para a migração de dados AWS Database Migration Service (AWS DMS) pode usar muitos dos mecanismos de dados mais populares como fonte para replicação de dados. A origem do banco de dados pode ser um mecanismo autogerenciado em execução em uma instância do Amazon EC2 ou em um banco de dados on-premises. Ou pode ser uma fonte de dados em um AWS serviço como o Amazon RDS ou o Amazon S3. Para obter uma lista abrangente de origens válidas, consulte [Origens do AWS DMS](CHAP_Introduction.Sources.md#CHAP_Introduction.Sources.title). **Topics** + [Usando um banco de dados Oracle como fonte para AWS DMS](CHAP_Source.Oracle.md) + [Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS](CHAP_Source.SQLServer.md) + [Usando o banco de dados SQL do Microsoft Azure como fonte para AWS DMS](CHAP_Source.AzureSQL.md) + [Usando a Instância Gerenciada SQL do Microsoft Azure como fonte para AWS DMS](CHAP_Source.AzureMgd.md) + [Usando o servidor flexível do Banco de Dados Microsoft Azure para PostgreSQL como fonte para AWS DMS](CHAP_Source.AzureDBPostgreSQL.md) + [Usando o servidor flexível do Banco de Dados do Microsoft Azure para MySQL como fonte para AWS DMS](CHAP_Source.AzureDBMySQL.md) + [Usando o OCI MySQL Heatwave como fonte para AWS DMS](CHAP_Source.heatwave.md) + [Usando o Google Cloud para MySQL como fonte para AWS DMS](CHAP_Source.GC.md) + [Usando o Google Cloud para PostgreSQL como fonte para AWS DMS](CHAP_Source.GCPostgres.md) + [Usando um banco de dados PostgreSQL como fonte AWS DMS](CHAP_Source.PostgreSQL.md) + [Usando um banco de dados compatível com MySQL como fonte para AWS DMS](CHAP_Source.MySQL.md) + [Usando um banco de dados SAP ASE como fonte para AWS DMS](CHAP_Source.SAP.md) + [Usando o MongoDB como fonte para AWS DMS](CHAP_Source.MongoDB.md) + [Usando o Amazon DocumentDB (com compatibilidade com o MongoDB) como fonte para AWS DMS](CHAP_Source.DocumentDB.md) + [Usando o Amazon S3 como fonte para AWS DMS](CHAP_Source.S3.md) + [Usando o banco de dados IBM Db2 para Linux, Unix, Windows e Amazon RDS (Db2 LUW) como fonte para AWS DMS](CHAP_Source.DB2.md) + [Usando o IBM Db2 para z/OS bancos de dados como fonte para AWS DMS](CHAP_Source.DB2zOS.md) # Usando um banco de dados Oracle como fonte para 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, consulte[Fontes para AWS DMS](CHAP_Introduction.Sources.md). É 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](#CHAP_Security.SSL.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](#CHAP_Source.Oracle.Encryption). 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. 1. 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. 1. 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](CHAP_Tasks.Creating.md) Para obter detalhes adicionais sobre como trabalhar com bancos de dados de origem Oracle AWS DMS, consulte as seções a seguir. **Topics** + [Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC](#CHAP_Source.Oracle.CDC) + [Fluxos de trabalho para configurar um banco de dados de origem Oracle autogerenciado ou AWS gerenciado para AWS DMSConfigurar um banco de dados de origem Oracle](#CHAP_Source.Oracle.Workflows) + [Trabalhando com um banco de dados Oracle autogerenciado como fonte para AWS DMS](#CHAP_Source.Oracle.Self-Managed) + [Trabalhando com um banco AWS de dados Oracle gerenciado como fonte para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed) + [Limitações no uso da Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.Limitations) + [Suporte de SSL para um endpoint do Oracle](#CHAP_Security.SSL.Oracle) + [Métodos de criptografia suportados para usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.Encryption) + [Métodos de compactação suportados para usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.Compression) + [Replicando tabelas aninhadas usando o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.NestedTables) + [Armazenando REDO no Oracle ASM ao usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.REDOonASM) + [Configurações de endpoint ao usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib) + [Tipos de dados de origem do Oracle](#CHAP_Source.Oracle.DataTypes) ## 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. | Recurso | LogMiner | Binary Reader | | --- | --- | --- | | Fácil de configurar | Sim | Não | | Menor impacto no sistema de origem I/O e na CPU | 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 de TDE especificadas estiverem incorretas, a tarefa de migração do AWS DMS 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](#CHAP_Source.Oracle.Encryption). 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. Binary Reader não. As principais vantagens de usar o Binary Reader com AWS DMS incluem o seguinte: + Para migrações com um grande volume de alterações, LogMiner pode ter algum I/O impacto sobre a CPU no computador que hospeda o banco de dados de origem Oracle. O Binary Reader tem menos chance de causar impacto na CPU porque os registros são extraídos diretamente, em vez de fazer várias consultas ao banco de dados. I/O + 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 LOBs na versão 12c do Oracle. LogMiner não faz. 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](#CHAP_Source.Oracle.ConnectionAttrib). 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](#CHAP_Source.Oracle.ConnectionAttrib) 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 obter mais informações, consulte [Executar a replicação a partir de um ponto de início de CDC](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint). 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](#CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges), [Privilégios de conta necessários ao usar o AWS DMS Binary Reader para acessar os redo logs](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges) e [Privilégios adicionais de conta necessários ao utilizar o Binary Reader com o Oracle ASM](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges). 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](#CHAP_Source.Oracle.Amazon-Managed.CDC) [Usando um Amazon RDS Oracle Standby (réplica de leitura) como fonte com o Binary Reader for CDC em AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy) ## 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](#CHAP_Source.Oracle.Self-Managed.Privileges). | Consulte [Privilégios de conta de usuário necessários em uma fonte Oracle autogerenciada para AWS DMS](#CHAP_Source.Oracle.Self-Managed.Privileges). | | 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](#CHAP_Source.Oracle.Self-Managed.Configuration). | Consulte [Preparando um banco de dados de origem autogerenciado Oracle para CDC usando AWS DMS](#CHAP_Source.Oracle.Self-Managed.Configuration). | | 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](#CHAP_Source.Oracle.Self-Managed.LogMinerPrivileges). | Consulte [Privilégios de conta necessários ao usar o AWS DMS Binary Reader para acessar os redo logs](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges). | | 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](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges). | | Se você ainda não tiver feito isso, configure a tarefa a ser usada LogMiner ou o Binary Reader for CDC. | Consulte [Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC](#CHAP_Source.Oracle.CDC). | Consulte [Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC](#CHAP_Source.Oracle.CDC). | | Configure o Oracle Standby como origem para a CDC. | AWS DMS não oferece suporte ao Oracle Standby como fonte. | Consulte [Usando um Oracle Standby autogerenciado como fonte com o Binary Reader for CDC em AWS DMS](#CHAP_Source.Oracle.Self-Managed.BinaryStandby). | 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 obter mais informações, consulte [Privilégios de conta de usuário necessários em uma fonte Oracle AWS gerenciada para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges). | Para obter mais informações, consulte [Privilégios de conta de usuário necessários em uma fonte Oracle AWS gerenciada para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges). | | Prepare o banco de dados de origem para replicação utilizando a CDC. | Para obter mais informações, consulte [Configurando uma fonte Oracle AWS gerenciada para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration). | Para obter mais informações, consulte [Configurando uma fonte Oracle AWS gerenciada para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration). | | Conceda privilégios adicionais ao usuário do Oracle necessários para a CDC. | Nenhum privilégio adicional de conta é necessário. | Para obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). | | Se você ainda não tiver feito isso, configure a tarefa a ser usada LogMiner ou o Binary Reader for CDC. | Para obter mais informações, consulte [Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC](#CHAP_Source.Oracle.CDC). | Para obter mais informações, consulte [Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC](#CHAP_Source.Oracle.CDC). | | Configure o Oracle Standby como origem para a CDC. | AWS DMS não oferece suporte ao Oracle Standby como fonte. | Para obter mais informações, consulte [Usando um Amazon RDS Oracle Standby (réplica de leitura) como fonte com o Binary Reader for CDC em AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy). | ## 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 dms_user; GRANT SELECT ANY TRANSACTION TO dms_user; GRANT SELECT ON V_$ARCHIVED_LOG TO dms_user; GRANT SELECT ON V_$LOG TO dms_user; GRANT SELECT ON V_$LOGFILE TO dms_user; GRANT SELECT ON V_$LOGMNR_LOGS TO dms_user; GRANT SELECT ON V_$LOGMNR_CONTENTS TO dms_user; GRANT SELECT ON V_$DATABASE TO dms_user; GRANT SELECT ON V_$THREAD TO dms_user; GRANT SELECT ON V_$PARAMETER TO dms_user; GRANT SELECT ON V_$NLS_PARAMETERS TO dms_user; GRANT SELECT ON V_$TIMEZONE_NAMES TO dms_user; GRANT SELECT ON V_$TRANSACTION TO dms_user; GRANT SELECT ON V_$CONTAINERS TO dms_user; GRANT SELECT ON ALL_INDEXES TO dms_user; GRANT SELECT ON ALL_OBJECTS TO dms_user; GRANT SELECT ON ALL_TABLES TO dms_user; GRANT SELECT ON ALL_USERS TO dms_user; GRANT SELECT ON ALL_CATALOG TO dms_user; GRANT SELECT ON ALL_CONSTRAINTS TO dms_user; GRANT SELECT ON ALL_CONS_COLUMNS TO dms_user; GRANT SELECT ON ALL_TAB_COLS TO dms_user; GRANT SELECT ON ALL_IND_COLUMNS TO dms_user; GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TO dms_user; GRANT SELECT ON ALL_LOG_GROUPS TO dms_user; GRANT SELECT ON ALL_TAB_PARTITIONS TO dms_user; GRANT SELECT ON SYS.DBA_REGISTRY TO dms_user; GRANT SELECT ON SYS.OBJ$ TO dms_user; GRANT SELECT ON DBA_TABLESPACES TO dms_user; GRANT SELECT ON DBA_OBJECTS TO dms_user; -– Required if the Oracle version is earlier than 11.2.0.3. GRANT SELECT ON SYS.ENC$ TO dms_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 dms_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 dms_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 dms_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 dms_user; ``` Conceda o privilégio adicional a seguir para utilizar o recurso de validação. ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_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 dms_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 dms_user; GRANT SELECT on v_$tablespace to dms_user; GRANT SELECT on dba_tab_subpartitions to dms_user; GRANT SELECT on dba_extents to dms_user; ``` Para obter informações sobre as replicações com tecnologia sem servidor, consulte [Trabalhando com AWS DMS Serverless](CHAP_Serverless.md). 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 dms_user; GRANT SELECT ON DBA_USERS to dms_user; GRANT SELECT ON DBA_DIRECTORIES to dms_user; GRANT EXECUTE ON SYS.DBMS_XMLGEN TO dms_user; ``` Para obter informações sobre avaliações de pré-migração específicas do Oracle, consulte. [Avaliações do Oracle](CHAP_Tasks.AssessmentReport.Oracle.md) #### 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)) )'; ``` 1. 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](#CHAP_Source.Oracle.Self-Managed.Configuration.DbVersion). + [Verificar se o modo ARCHIVELOG está ativado](#CHAP_Source.Oracle.Self-Managed.Configuration.ArchiveLogMode). + [Configuração de registro em log suplementar](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging). #### 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 obter mais informações, consulte [Configurações de endpoint ao usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib). 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; ``` 1. 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 dms_user; GRANT SELECT on V_$LOGMNR_LOGS to dms_user; GRANT SELECT on V_$LOGMNR_CONTENTS to dms_user; GRANT LOGMINING to dms_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 dms_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 dms_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 does not have file-level access to the redo logs and the redo logs are on non-ASM storage. GRANT EXECUTE on DBMS_FILE_TRANSFER to dms_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 dms_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 em nível de 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`. **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 AWS DMS não encontrar o diretório pré-criado esperado, a tarefa será interrompida. Além disso, AWS DMS não exclui as entradas que criou na `ALL_DIRECTORIES` exibição, 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 ``` ### Usando um Oracle Standby autogerenciado como fonte com o Binary Reader for CDC em 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 dms_user; ``` 1. Crie um endpoint de origem para o Oracle Standby utilizando o Console de gerenciamento da AWS 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 obter mais informações, consulte [Configurações de endpoint ao usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib). 1. 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\$1MM\$1DD. 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’; ``` 1. 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 ``` 1. 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’; ... ``` 1. Criar uma tarefa do programador do Oracle que seja executada diariamente e criar o diretório necessário. 1. Configure o destino do log on-line. Crie um diretório Oracle que aponte para o diretório do sistema operacional com logs de redo em espera: ``` CREATE OR REPLACE DIRECTORY STANDBY_REDO_DIR AS ''; GRANT READ ON DIRECTORY STANDBY_REDO_DIR TO ; ``` ### Usando um banco de dados gerenciado pelo usuário no Oracle Cloud Infrastructure (OCI) como fonte para o CDC em 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](#CHAP_Source.Oracle.Self-Managed.Privileges). 1. 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](#CHAP_Source.Oracle.Self-Managed.BinaryReaderPrivileges). 1. 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](#CHAP_Source.Oracle.Self-Managed.ASMBinaryPrivileges). 1. Configure o registro em log suplementar. Para obter mais informações, consulte [Configuração do registro em log suplementar](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging). 1. 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](#CHAP_Source.Oracle.Encryption). 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 bancos de dados autônomos. ## 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 `dms_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 `dms_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"` ou`CREATE 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 dms_user; GRANT SELECT ANY TRANSACTION to dms_user; GRANT SELECT on DBA_TABLESPACES to dms_user; GRANT SELECT ON any-replicated-table to dms_user; GRANT EXECUTE on rdsadmin.rdsadmin_util to dms_user; -- For Oracle 12c or higher: GRANT LOGMINING to dms_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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html#Appendix.Oracle.CommonDBATasks.TransferPrivileges). ``` exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_VIEWS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_PARTITIONS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_INDEXES', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TABLES', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_USERS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CATALOG', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONSTRAINTS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONS_COLUMNS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_IND_COLUMNS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_LOG_GROUPS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$CONTAINERS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS', 'dms_user', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','dms_user','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR', 'dms_user', 'EXECUTE'); -- (as of Oracle versions 12.1 and higher) exec rdsadmin.rdsadmin_util.grant_sys_object('REGISTRY$SQLPATCH', 'dms_user', 'SELECT'); -- (for Amazon RDS Active Dataguard Standby (ADG)) exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STANDBY_LOG', 'dms_user', 'SELECT'); -- (for transparent data encryption (TDE)) exec rdsadmin.rdsadmin_util.grant_sys_object('ENC$', 'dms_user', 'SELECT'); -- (for validation with LOB columns) exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_CRYPTO', 'dms_user', 'EXECUTE'); -- (for binary reader) exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DIRECTORIES','dms_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', 'dms_user', 'SELECT'); ``` Para obter mais informações sobre como utilizar o Amazon RDS Active Dataguard Standby (ADG) com o AWS DMS , consulte [Usando um Amazon RDS Oracle Standby (réplica de leitura) como fonte com o Binary Reader for CDC em AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.StandBy). Para obter mais informações sobre como usar o Oracle TDE com AWS DMS, consulte[Métodos de criptografia suportados para usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.Encryption). #### 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)) )'; ``` 1. 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Enabling) 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. 1. 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'); ``` 1. O exemplo a seguir ativa o registro em log suplementar de chave primária. ``` exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY'); ``` 1. (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 obter mais informações, consulte [Privilégios de conta de usuário necessários em uma fonte Oracle AWS gerenciada para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Privileges). 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; ``` 1. 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 dms_user; GRANT READ ON DIRECTORY ARCHIVELOG_DIR TO dms_user; ``` 1. 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](#CHAP_Source.Oracle.CDC.Configuration). ### Usando um Amazon RDS Oracle Standby (réplica de leitura) como fonte com o Binary Reader for CDC em 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. 1. 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; ``` 1. 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.\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-rds-server-level-directories.png) 1. 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 dms_user; GRANT READ ON DIRECTORY ARCHIVELOG_DIR_B TO dms_user; GRANT READ ON DIRECTORY ONLINELOG_DIR_A TO dms_user; GRANT READ ON DIRECTORY ONLINELOG_DIR_B TO dms_user; ``` 1. 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. 1. Execute uma consulta `ALL_DIRECTORIES` no Oracle Standby para confirmar se as alterações foram aplicadas. 1. 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 ``` 1. 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. + Para um banco de dados Oracle autogerenciado como origem, consulte [Configuração de registro em log suplementar](#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging). + Para um banco AWS de dados de origem Oracle gerenciado, consulte[Configurando uma fonte Oracle AWS gerenciada para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.Configuration). + AWS DMS não oferece suporte ao banco de dados raiz de contêiner multilocatário (CDB\$1ROOT). Ele é compatível com um PDB utilizando o Binary Reader. + AWS DMS não suporta restrições diferidas. + AWS DMS a versão 3.5.3 e superior oferece suporte total à segurança. LOBs + 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](#CHAP_Source.Oracle.ConnectionAttrib). Além disso, observe que em tarefas de CARGA MÁXIMA\$1CDC, 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. + Quando o modo LOB de tamanho limitado está ativado, BLOB/CLOB as colunas vazias na fonte Oracle são replicadas como valores NULL. Quando o modo LOB completo está habilitado, elas são replicadas como uma string vazia (‘ ’). + 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 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. + AWS DMS não suporta transações XA na replicação ao usar o Oracle LogMiner. + LogMiner O Oracle 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 logs redo on-line em dispositivos brutos. + O Binary Reader é compatível com 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 de 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 suporta 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$` ou`DR$`. + 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. + Antes da AWS DMS versão 3.5.3, o procedimento de carregamento direto `INSERT` com a opção de execução paralela não era suportado 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. + 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 oferece suporte à replicação de tabelas com restrições de validade temporal. + Se a fonte Oracle ficar indisponível durante uma tarefa de carga total, AWS DMS poderá marcar a tarefa como concluída após várias tentativas de reconexão, mesmo que a migração de dados permaneça incompleta. Nesse cenário, as tabelas de destino contêm somente os registros migrados antes da perda da conexão, possivelmente criando inconsistências de dados entre os sistemas de origem e de destino. Para garantir a integridade dos dados, reinicie totalmente a tarefa de carga máxima ou recarregue as tabelas específicas afetadas pela interrupção da conexão. ## 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. **Topics** + [Utilizar um certificado existente para SSL no Oracle](#CHAP_Security.SSL.Oracle.Existing) + [Utilizar um certificado autoassinado para SSL no Oracle](#CHAP_Security.SSL.Oracle.SelfSigned) ### 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. **Para usar uma instalação existente do cliente Oracle para Oracle SSL com 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 ``` 1. Anexe `$ORACLE_HOME/lib` ao sistema variável `LD_LIBRARY_PATH`. ``` prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib ``` 1. Crie um diretório para o Oracle Wallet em `$ORACLE_HOME/ssl_wallet`. ``` prompt>mkdir $ORACLE_HOME/ssl_wallet ``` 1. 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 o download desse arquivo, consulte Como [usar SSL/TLS para criptografar uma conexão com uma instância](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) de banco de dados no Guia do *usuário do Amazon RDS*. 1. Se o seu certificado CA contiver mais de um arquivo PEM (como o pacote global ou regional do Amazon RDS), divida-os em arquivos separados e adicione-os à carteira Oracle usando o script Bash a seguir. Esse script requer duas entradas de parâmetro: o caminho para o certificado CA e o caminho para a pasta da carteira Oracle criada anteriormente. ``` #!/usr/bin/env bash certnum=$(grep -c BEGIN <(cat $1)) cnt=0 temp_cert="" while read line do if [ -n "$temp_cert" -a "$line" == "-----BEGIN CERTIFICATE-----" ] then cnt=$(expr $cnt + 1) printf "\rImporting certificate # $cnt of $certnum" orapki wallet add -wallet "$2" -trusted_cert -cert <(echo -n "${temp_cert}") -auto_login_only 1>/dev/null 2>/dev/null temp_cert="" fi temp_cert+="$line"$'\n' done < <(cat $1) cnt=$(expr $cnt + 1) printf "\rImporting certificate # $cnt of $certnum" orapki wallet add -wallet "$2" -trusted_cert -cert <(echo -n "${temp_cert}") -auto_login_only 1>/dev/null 2>/dev/null echo "" ``` 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 ``` 1. Altere para o diretório que você criou na etapa anterior. ``` cd /u01/app/oracle/self_signed_cert ``` 1. Crie uma chave raiz. ``` openssl genrsa -out self-rootCA.key 2048 ``` 1. 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 1. Crie um diretório do Oracle Wallet para o banco de dados Oracle. ``` mkdir -p /u01/app/oracle/wallet ``` 1. Crie um novo Oracle Wallet. ``` orapki wallet create -wallet "/u01/app/oracle/wallet" -pwd oracle123 -auto_login_local ``` 1. 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 ``` 1. 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 ``` 1. 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 ``` 1. Execute o comando a seguir. ``` 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 ``` 1. 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` 1. Obtenha a assinatura do certificado. ``` openssl req -noout -text -in certdms.csr | grep -i signature ``` A chave de assinatura desta postagem é `sha256WithRSAEncryption`. 1. 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 ``` 1. Adicione o certificado à carteira. ``` orapki wallet add -wallet /u01/app/oracle/wallet -pwd oracle123 -user_cert -cert certdms.crt ``` 1. Visualize a carteira. Deve haver duas entradas. Consulte o seguinte código: ``` orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123 ``` 1. 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) ``` 1. Interrompa o receptor do Oracle. ``` lsnrctl stop ``` 1. 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)) ) ) ``` 1. Configure o arquivo `tnsnames.ora` (`$ORACLE_HOME/network/admin/tnsnames.ora`). ``` = (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ) ) ) _ssl= (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ) ) ) ``` 1. Reinicie o receptor do Oracle. ``` lsnrctl start ``` 1. Mostre o status do receptor do Oracle. ``` lsnrctl status ``` 1. 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 ``` 1. Verifique se você se conectou com êxito utilizando SSL. ``` SELECT SYS_CONTEXT('USERENV', 'network_protocol') FROM DUAL; SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') -------------------------------------------------------------------------------- tcps ``` 1. Altere o diretório para o diretório com o certificado autoassinado. ``` cd /u01/app/oracle/self_signed_cert ``` 1. Crie uma nova carteira Oracle de cliente AWS DMS para usar. ``` orapki wallet create -wallet ./ -auto_login_only ``` 1. Adicione o certificado raiz autoassinado ao Oracle Wallet. ``` orapki wallet add -wallet ./ -trusted_cert -cert self-rootCA.pem -auto_login_only ``` 1. 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 ``` 1. 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. 1. Obtenha o ID da chave principal para uma fonte não CDB ou CDB da seguinte forma: 1. Para uma fonte que não CDB, execute a seguinte consulta para recuperar o ID da chave de criptografia principal: ``` SQL> select rownum, key_id, activation_time from v$encryption_keys; ROWNUM KEY_ID ACTIVATION_TIME ------ ------------------------------------------------------ --------------- 1 AeKask0XZU+NvysflCYBEVwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 04-SEP-24 10.20.56.605200 PM +00:00 2 AV7WU9uhoU8rv8daE/HNnSwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 10-AUG-21 07.52.03.966362 PM +00:00 3 AckpoJ/f+k8xvzJ+gSuoVH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 14-SEP-20 09.26.29.048870 PM +00:00 ``` O tempo de ativação é útil se você planeja iniciar a CDC em algum momento no passado. Por exemplo, usando os resultados acima, você pode iniciar a CDC a partir de algum ponto entre 10 de agosto de 2021 às 19h52m3s e 14 de setembro de 2020 às 21h26m29s usando o ID da chave principal na ROWNUM 2. Quando a tarefa atinge o redo gerado em ou após 14 de setembro de 2020, às 19h26m29s, ela falha. Você deve modificar o endpoint de origem, fornecer o ID da chave principal na ROWNUM 3 e, em seguida, retomar a tarefa. 1. Para CDB, o DMS de origem requer a chave de criptografia principal CDB\$1ROOT. Conecte-se à CDB\$1ROOT e execute a seguinte consulta: ``` SQL> select rownum, key_id, activation_time from v$encryption_keys where con_id = 1; ROWNUM KEY_ID ACTIVATION_TIME ------ ---------------------------------------------------- ----------------------------------- 1 Aa2E/Vwb5U+zv5hCncS5ErMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 29-AUG-24 12.51.19.699060 AM +00:00 ``` 1. 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. 1. 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. 1. 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 ``` 1. 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: Crie um keystore local. ``` ADMINISTER KEY MANAGEMENT create keystore file system wallet location identified by wallet password; ``` 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. | Versão | Básico | 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](#CHAP_Source.Oracle.NestedTables.JoinExample). É 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 do AWS DMS suporte para tabelas aninhadas da Oracle como fonte 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 AWS DMS replica tabelas aninhadas da Oracle como fonte 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 chamada`NESTED_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); ``` 1. 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; ``` 1. 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](https://support.oracle.com/knowledge/Oracle Cloud/1495104_1.html). 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), 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. | Name (Nome) | Description | | --- | --- | | 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 obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). 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](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-data-repair-concepts.html#GUID-1805CCF7-4AF2-482D-B65A-998192F89C2B) 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.Oracle.html) Valor padrão: falso Valores válidos: true/false Exemplo: `--oracle-settings '{"AddSupplementalLogging": false}'` 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 obter mais informações, consulte [Replicando tabelas aninhadas usando o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.NestedTables). 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\$1id da visualização v\$1archived\$1log. 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 `parallelASMReadThreads`. Quando você define esse atributo, o leitor AWS DMS binário usa um PL/SQL bloco 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 obter mais informações, consulte [Curingas no mapeamento de tabela](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Wildcards.md). Valor padrão: nulo Valores válidos: qualquer caractere que não seja um caractere curinga Exemplo: `--oracle-settings '{"EscapeCharacter": "#"}'` É 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 mais um destino para um ou mais redo logs arquivados. IDs Esses IDs são os valores da coluna dest\$1id na visualização v\$1archived\$1log. 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}'` 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). Você deve observar que a perda de precisão pode ocorrer quando essa configuração é definida incorretamente. | | `OpenTransactionWindow` | Fornece o período em minutos para verificar se há transações abertas apenas para tarefas da CDC. Quando você define `OpenTransactionWindow` como 1 ou acima, o DMS usa `SCN_TO_TIMESTAMP` para converter valores de SCN em valores de carimbo de data/hora. Devido às limitações do banco de dados Oracle, se você especificar um SCN muito antigo como ponto inicial de CDC, SCN\$1TO\$1TIMESTAMP apresentará falha com um erro `ORA-08181`, e você não poderá iniciar tarefas somente de 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 obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).Valor padrão: nenhum Valor válido:/rdsdbdata/db/ORCL\$1A/ 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 obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). 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. Você pode especificar um valor inteiro entre 1000 (o padrão) e 2.000.000 (o máximo). Use esse atributo junto com o atributo `ParallelASMReadThreads`. Para obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC). Valor padrão: 1000 Valores válidos: um número inteiro de 1000 a 2.000.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 obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).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](#CHAP_Source.Oracle.Encryption). 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\$1GEOMETRY 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: SDO2 GEOJSON 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 obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).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](#CHAP_Source.Oracle.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: Y/N (ao definir esse valor como ECA); true/false (ao definir esse valor como uma configuração de ponto final). 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](#CHAP_Source.Oracle.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: Y/N (ao definir esse valor como ECA); true/false (ao definir esse valor como uma configuração de ponto final). 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 obter mais informações, consulte [Configurando uma tarefa do CDC para usar o Binary Reader com uma fonte do RDS for Oracle para AWS DMS](#CHAP_Source.Oracle.Amazon-Managed.CDC).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, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipo de dados do Oracle | AWS DMS tipo de dados | | --- | --- | | BINARY\$1FLOAT | REAL4 | | BINARY\$1DOUBLE | REAL8 | | BINARY | BYTES | | FLOAT (P) | Se a precisão for menor ou igual a 24, use REAL4. Se a precisão for maior que 24, use REAL8. | | NUMBER (P,S) | Quando a escala for maior que 0, utilize NUMERIC. Quando a escala for 0: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.Oracle.html) Quando a escala for menor que 0, use REAL8. | | DATE | 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 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.Oracle.html) | | NCHAR | WSTRING | | NVARCHAR2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.Oracle.html) | | 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 o suporte LOB para bancos de dados de origem em uma tarefa AWS DMS](CHAP_Tasks.LOBSupport.md) | | 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, o 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 o suporte LOB para bancos de dados de origem em uma tarefa AWS DMS](CHAP_Tasks.LOBSupport.md) | | XMLTYPE | CLOB | | SDO\$1GEOMETRY | BLOB (quando é uma migração de Oracle para Oracle)CLOB (quando é uma migração de Oracle para PostgreSQL) | As tabelas de origem do Oracle que têm colunas com os tipos de dados relacionados 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\$1GEOMETRY. 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\$1GEOMETRY 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\$1SDO\$1GEOM\$1METADATA 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 obter mais informações, consulte [Configurações de endpoint ao usar o Oracle como fonte para AWS DMS](#CHAP_Source.Oracle.ConnectionAttrib). + 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 o suporte LOB para bancos de dados de origem em uma tarefa AWS DMS](CHAP_Tasks.LOBSupport.md). + 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. # Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS Migre dados de um ou vários bancos de dados do Microsoft SQL Server usando o. AWS DMS Com um banco de dados do SQL Server como fonte, você pode migrar dados para outro banco de dados do SQL Server ou para um dos outros bancos de dados AWS DMS compatíveis. Para obter informações sobre as versões do SQL Server que oferecem AWS DMS suporte como fonte, consulte[Fontes para AWS DMS](CHAP_Introduction.Sources.md). O banco de dados de origem SQL Server pode ser instalado em qualquer computador na rede. É necessário ter uma conta do SQL Server com os privilégios de acesso ao banco de dados de origem adequados ao tipo de tarefa escolhido para utilizar com o AWS DMS. Para obter mais informações, consulte [Permissões para tarefas do SQL Server](#CHAP_Source.SQLServer.Permissions). AWS DMS oferece suporte à migração de dados de instâncias nomeadas do SQL Server. É possível utilizar a seguinte notação no nome do servidor ao criar o endpoint de origem. ``` IPAddress\InstanceName ``` Por exemplo, o seguinte é um nome do servidor do endpoint de origem correto. Aqui, a primeira parte do nome é o endereço IP do servidor e a segunda parte é o nome da instância do SQL Server (neste exemplo, SQLTest). ``` 10.0.0.25\SQLTest ``` Além disso, obtenha o número da porta que sua instância nomeada do SQL Server escuta e use-o para configurar seu endpoint de AWS DMS origem. **nota** A porta 1433 é o padrão para o Microsoft SQL Server. No entanto, as portas dinâmicas que são alteradas a cada vez que o SQL Server é iniciado e os números de portas estáticas específicos utilizados para conexão ao SQL Server por meio de um firewall também são utilizados com frequência. Então, você quer saber o número real da porta da sua instância nomeada do SQL Server ao criar o endpoint de AWS DMS origem. É possível utilizar SSL para criptografar conexões entre o endpoint do SQL Server e a instância de replicação. Para obter mais informações sobre como utilizar o SSL com um endpoint do SQL Server, consulte [Usando SSL com AWS Database Migration Service](CHAP_Security.SSL.md). Você pode usar CDC para a migração contínua de um banco de dados do SQL Server. Para ter informações sobre como configurar o banco de dados do SQL Server de origem para CDC, consulte [Capturar alterações de dados para replicação contínua no SQL Server](CHAP_Source.SQLServer.CDC.md). Para obter detalhes adicionais sobre como trabalhar com bancos de dados de origem do SQL Server e AWS DMS, consulte o seguinte. **Topics** + [Limitações no uso do SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.Limitations) + [Permissões para tarefas do SQL Server](#CHAP_Source.SQLServer.Permissions) + [Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server](#CHAP_Source.SQLServer.Prerequisites) + [Métodos de compactação compatíveis com o SQL Server](#CHAP_Source.SQLServer.Compression) + [Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server](#CHAP_Source.SQLServer.AlwaysOn) + [Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib) + [Tipos de dados de origem no SQL Server](#CHAP_Source.SQLServer.DataTypes) + [Capturar alterações de dados para replicação contínua no SQL Server](CHAP_Source.SQLServer.CDC.md) ## Limitações no uso do SQL Server como fonte para AWS DMS As seguintes limitações se aplicam ao utilizar um banco de dados SQL como origem do AWS DMS: + A propriedade identity de uma coluna não é migrada para uma coluna de banco de dados de destino. + O endpoint do SQL Server não é compatível com a utilização de tabelas com colunas esparsas. + A Autenticação do Windows não é compatível. + As alterações em campos computados em um SQL Server não são replicadas. + Tabelas temporais não são compatíveis. + A alternância de partições do SQL Server não é compatível. + Ao usar os utilitários WRITETEXT e UPDATETEXT, AWS DMS não captura eventos aplicados no banco de dados de origem. + O seguinte padrão da linguagem de manipulação de dados (DML) não é compatível: ``` SELECT * INTO new_table FROM existing_table ``` + Ao utilizar o SQL Server como uma origem, a criptografia em nível de colunas não é compatível. + AWS DMS não oferece suporte a auditorias em nível de servidor no SQL Server 2008 ou no SQL Server 2008 R2 como fontes. Isso ocorre devido a um problema conhecido com o SQL Server 2008 e 2008 R2. Por exemplo, a execução do comando a seguir causa AWS DMS a falha. ``` USE [master] GO ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on) GO ``` + Não é possível usar geometria e colunas de geometria no modo LOB completo ao utilizar o SQL Server como origem. Em vez disso, utilize o modo LOB limitado ou defina a configuração da tarefa `InlineLobMaxSize` para utilizar o modo LOB em linha. + Ao utilizar um banco de dados de origem Microsoft SQL Server em uma tarefa de replicação, as definições do publicador de replicação do SQL Server não serão removidas se você remover a tarefa. Um administrador de sistema do Microsoft SQL Server deve excluir essas definições do Microsoft SQL Server. + A migração de dados de non-schema-bound visualizações e vinculados a esquemas é suportada somente para tarefas de carga total. + A renomeação de tabelas não é compatível com a utilização de sp\$1rename (por exemplo, `sp_rename 'Sales.SalesRegion', 'SalesReg;)`) + A renomeação de colunas não é compatível com a utilização de sp\$1rename (por exemplo, `sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';`) + AWS DMS não oferece suporte ao processamento de alterações para definir e desdefinir valores padrão da coluna (usando a `ALTER COLUMN SET DEFAULT` cláusula com `ALTER TABLE` instruções). + AWS DMS não oferece suporte ao processamento de alterações para definir a nulidade da coluna (usando a `ALTER COLUMN [SET|DROP] NOT NULL` cláusula com instruções). `ALTER TABLE` + Com o SQL Server 2012 e o SQL Server 2014, ao utilizar a replicação do DMS com grupos de disponibilidade, o banco de dados de distribuição não pode ser colocado em um grupo de disponibilidade. O SQL 2016 oferece suporte à colocação do banco de dados de distribuição em um grupo de disponibilidade, exceto para bancos de dados de distribuição usados em topologias de mesclagem, bidirecional ou peer-to-peer replicação. + Para tabelas particionadas, AWS DMS não oferece suporte a diferentes configurações de compactação de dados para cada partição. + Ao inserir um valor em tipos de dados espaciais (GEOGRAPHY e GEOMETRY) no SQL Server, é possível ignorar a propriedade de identificador de sistema de referência espacial (SRID) ou especificar outro número. Ao replicar tabelas com tipos de dados espaciais, AWS DMS substitui o SRID pelo SRID padrão (0 para GEOMETRIA e 4326 para GEOGRAFIA). + Se seu banco de dados não estiver configurado para MS-REPLICATION ou MS-CDC, você ainda poderá capturar tabelas que não tenham uma chave primária, mas somente eventos DML serão capturados. INSERT/DELETE Os eventos UPDATE e TRUNCATE TABLE são ignorados. + Os índices Columnstore não são compatíveis. + Tabelas otimizadas para memória (utilizando OLTP na memória) não são compatíveis. + Ao replicar uma tabela com uma chave primária que consiste em várias colunas, a atualização das colunas de chave primária durante a carga máxima não é compatível. + A durabilidade atrasada não é compatível. + A configuração do endpoint `readBackupOnly=true` (atributo de conexão adicional) não funciona em instâncias de origem do RDS para SQL Server devido à forma como o RDS executa backups. + O `EXCLUSIVE_AUTOMATIC_TRUNCATION` não funciona em instâncias de origem do Amazon RDS SQL Server porque os usuários do RDS não têm acesso para executar o procedimento armazenado do SQL Server, `sp_repldone`. + AWS DMS não captura comandos truncados. + AWS DMS não oferece suporte à replicação de bancos de dados com a recuperação acelerada de banco de dados (ADR) ativada. + AWS DMS não suporta a captura de instruções de linguagem de definição de dados (DDL) e linguagem de manipulação de dados (DML) em uma única transação. + AWS DMS não oferece suporte à replicação de pacotes de aplicativos de camada de dados (DACPAC). + As instruções UPDATE que envolvem chaves primárias ou índices exclusivos e atualizam várias linhas de dados podem causar conflitos ao aplicar alterações no banco de dados de destino. Isso pode acontecer, por exemplo, quando o banco de dados de destino aplica atualizações, como instruções INSERT e DELETE, em vez de uma única instrução UPDATE. Com o modo de aplicação otimizado em lote, a tabela pode ser ignorada. Com o modo de aplicação transacional, a operação UPDATE pode resultar em violações de restrições. Para evitar esse problema, recarregue a tabela relevante. Como alternativa, localize os registros problemáticos na tabela de controle Exceções da aplicação (`dmslogs.awsdms_apply_exceptions`) e edite-os manualmente no banco de dados de destino. Para obter mais informações, consulte [Configurações de ajuste de processamento de alterações](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md). + AWS DMS não suporta a replicação de tabelas e esquemas, em que o nome inclui um caractere especial do conjunto a seguir. `\\ -- \n \" \b \r ' \t ;` + O mascaramento de dados não é suportado. AWS DMS migra dados mascarados sem mascarar. + AWS DMS replica até 32.767 tabelas com chaves primárias e até 1.000 colunas para cada tabela. Isso ocorre porque AWS DMS cria um artigo de replicação do SQL Server para cada tabela replicada, e os artigos de replicação do SQL Server têm essas limitações. + Ao utilizar a captura de dados de alteração (CDC), defina todas as colunas que compõem um índice exclusivo como `NOT NULL`. Se esse requisito não for atendido, ocorrerá o erro 22838 do sistema do SQL Server. + É possível perder eventos se o SQL Server armazená-los do log de transações ativo para o log de backup ou truncá-los no log de transações ativo. As seguintes limitações se aplicam ao acessar os logs de transação de backup: + Backups criptografados não são compatíveis. + Backups armazenados em um URL ou no Windows Azure não são compatíveis. + AWS DMS não suporta o processamento direto de backups de registros de transações no nível do arquivo a partir de pastas compartilhadas alternativas. + Para fontes do Cloud SQL Server que não sejam Amazon RDS para Microsoft SQL Server AWS DMS , o Amazon RDS for Microsoft SQL Server oferece suporte à replicação contínua (CDC) somente com o log de transações ativo. Não é possível utilizar o log de backup com a CDC. É possível perder eventos se o SQL Server armazená-los do log de transações ativo para o log de backup ou truncá-los no log de transações ativo antes que o DMS consiga lê-los. + Para fontes do Amazon RDS for Microsoft SQL Server AWS DMS , a versão 3.5.2 e versões anteriores oferecem suporte à replicação contínua (CDC) somente com o log de transações ativo, porque o DMS não pode acessar o log de backup com o CDC. É possível perder eventos se o RDS para SQL Server armazená-los do log de transações ativo para o log de backup ou truncá-los no log de transações ativo antes que o DMS consiga lê-los. Essa limitação não se aplica à AWS DMS versão 3.5.3 e superior. + AWS DMS não oferece suporte ao CDC para Amazon RDS Proxy for SQL Server como fonte. + Se a origem do SQL Server ficar indisponível durante uma tarefa de carga máxima, o AWS DMS poderá marcar a tarefa como concluída após várias tentativas de reconexão, mesmo que a migração de dados permaneça incompleta. Nesse cenário, as tabelas de destino contêm somente os registros migrados antes da perda da conexão, possivelmente criando inconsistências de dados entre os sistemas de origem e de destino. Para garantir a integridade dos dados, você deve reiniciar totalmente a tarefa de carga máxima ou recarregar as tabelas específicas afetadas pela interrupção da conexão. ## Permissões para tarefas do SQL Server **Topics** + [Permissões para tarefas somente de carga máxima](#CHAP_Source.SQLServer.Permissions.FullLoad) + [Permissões para tarefas com replicação contínua](#CHAP_Source.SQLServer.Permissions.Ongoing) ### Permissões para tarefas somente de carga máxima As permissões a seguir são necessárias para realizar tarefas somente de carga máxima. Observe que o AWS DMS não cria o login `dms_user`. Para ter informações sobre como criar um login para o SQL Server, consulte o tópico [Create a database user](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-database-user?view=sql-server-ver16) na *documentação da Microsoft*. ``` USE db_name; CREATE USER dms_user FOR LOGIN dms_user; ALTER ROLE [db_datareader] ADD MEMBER dms_user; GRANT VIEW DATABASE STATE to dms_user; GRANT VIEW DEFINITION to dms_user; USE master; GRANT VIEW SERVER STATE TO dms_user; ``` ### Permissões para tarefas com replicação contínua As instâncias autogerenciadas do SQL Server podem ser configuradas para replicação contínua usando o DMS com ou sem o uso do perfil `sysadmin`. Para instâncias do SQL Server nas quais você não pode conceder o perfil `sysadmin`, garanta que o usuário do DMS tenha os privilégios descritos a seguir. **Configurar permissões para replicação contínua a partir de um banco de dados autogerenciado do SQL Server** 1. Crie uma nova conta do SQL Server com autenticação por senha utilizando o SQL Server Management Studio (SSMS) ou conforme descrito anteriormente em [Permissões para tarefas somente de carga máxima](#CHAP_Source.SQLServer.Permissions.FullLoad), por exemplo `self_managed_user`. 1. Execute os seguintes comandos `GRANT`: ``` GRANT VIEW SERVER STATE TO self_managed_user; USE msdb; GRANT SELECT ON msdb.dbo.backupset TO self_managed_user; GRANT SELECT ON msdb.dbo.backupmediafamily TO self_managed_user; GRANT SELECT ON msdb.dbo.backupfile TO self_managed_user; USE db_name; CREATE USER self_managed_user FOR LOGIN self_managed_user; ALTER ROLE [db_owner] ADD MEMBER self_managed_user; GRANT VIEW DEFINITION to self_managed_user; ``` 1. Além das permissões anteriores, o usuário precisa de uma das seguintes: + O usuário deve ser um membro do perfil `sysadmin` fixo do servidor + Configurações e permissões conforme descrito em [Configurar a replicação contínua em um SQL Server em um ambiente de grupo de disponibilidade: sem o perfil sysadmin](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.ag) ou [Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.standalone), dependendo da configuração da origem. #### Configurar permissões para replicação contínua a partir de um banco de dados do SQL Server na nuvem Uma instância do SQL Server hospedada na nuvem é uma instância em execução no Amazon RDS para Microsoft SQL Server, uma instância gerenciada do Azure SQL ou qualquer outra instância gerenciada do SQL Server na nuvem compatível com o DMS. Crie uma nova conta do SQL Server com autenticação por senha utilizando o SQL Server Management Studio (SSMS) ou conforme descrito anteriormente em [Permissões para tarefas somente de carga máxima](#CHAP_Source.SQLServer.Permissions.FullLoad), por exemplo `rds_user`. Execute os seguintes comandos de concessão: ``` GRANT VIEW SERVER STATE TO rds_user; ``` Para origens do Amazon RDS para Microsoft SQL Server, a versão 3.5.3 e superiores do DMS são compatíveis com leitura de backups de logs de transações. Para garantir que o DMS possa acessar os backups de log, além do descrito acima, conceda privilégios de usuário `master` ou os seguintes privilégios em uma origem do RDS para SQL Server: ``` USE msdb; GRANT EXEC ON msdb.dbo.rds_dms_tlog_download TO rds_user; GRANT EXEC ON msdb.dbo.rds_dms_tlog_read TO rds_user; GRANT EXEC ON msdb.dbo.rds_dms_tlog_list_current_lsn TO rds_user; GRANT EXEC ON msdb.dbo.rds_task_status TO rds_user; USE db_name; CREATE USER rds_user FOR LOGIN rds_user; ALTER ROLE [db_owner] ADD MEMBER rds_user; GRANT VIEW DEFINITION to rds_user; ``` Para as instâncias gerenciadas de SQL do Amazon Azure, conceda os seguintes privilégios: ``` GRANT SELECT ON msdb.dbo.backupset TO rds_user; GRANT SELECT ON msdb.dbo.backupmediafamily TO rds_user; GRANT SELECT ON msdb.dbo.backupfile TO rds_user; ``` ## Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server É possível utilizar a replicação contínua (captura de dados de alteração, ou CDC) para um banco de dados SQL Server autogerenciado on-premises ou no Amazon EC2, ou um banco de dados de nuvem, como o Amazon RDS ou uma instância gerenciada pelo Microsoft Azure SQL. Os seguintes requisitos se aplicam especificamente ao utilizar a replicação contínua com um banco de dados SQL Server como uma origem para o AWS DMS: + O SQL Server deve ser configurado para fazer backups completos e um backup deve ser feito antes do início da replicação dos dados. + O modelo de recuperação deve ser definido como **Bulk-logged** ou **Full**. + O backup do SQL Server para múltiplos discos não é compatível. Se o backup estiver definido para gravar o backup do banco de dados em vários arquivos em discos diferentes, não será AWS DMS possível ler os dados e a AWS DMS tarefa falhará. + Para origens do SQL Server autogerenciadas, as definições do SQL Server Replication Publisher para a origem utilizada em uma tarefa de CDC do DMS não são removidas quando você remove a tarefa. Um administrador de sistema do SQL Server deve excluir essas definições do SQL Server para origens autogerenciadas. + Durante o CDC, é AWS DMS necessário consultar os backups do log de transações do SQL Server para ler as alterações. AWS DMS não oferece suporte a backups de log de transações do SQL Server criados usando software de backup de terceiros que *não estejam* em formato nativo. Para compatibilidade com backups de logs de transações *que estão* em formato nativo e foram criados utilizando software de backup de terceiros, adicione o atributo de conexão `use3rdPartyBackupDevice=Y` ao endpoint de origem. + Para origens autogerenciadas do SQL Server, lembre-se de que o SQL Server não captura alterações em tabelas recém-criadas até que elas sejam publicadas. Quando as tabelas são adicionadas a uma fonte do SQL Server, AWS DMS gerencia a criação da publicação. No entanto, esse processo pode demorar alguns minutos. As operações feitas durante esse intervalo nas tabelas recentemente criadas não são capturadas ou replicadas no destino. + AWS DMS a captura de dados de alteração exige que o registro completo de transações seja ativado no SQL Server. Para ativar o registro em log de transações completo no SQL Server, ative MS-REPLICATION ou CHANGE DATA CAPTURE (CDC). + As entradas *tlog* do SQL Server não serão marcadas para reutilização até que o trabalho de captura de MS CDC processe essas alterações. + As operações de CDC não são compatíveis com tabelas com otimização de memória. Essa limitação se aplica ao SQL Server 2014 (quando o recurso foi introduzido pela primeira vez) e posterior. + AWS DMS a captura de dados de alteração requer, por padrão, um banco de dados de distribuição no Amazon EC2 ou no servidor SQL On-Prem como fonte. Portanto, ative o distribuidor ao configurar a replicação de MS para tabelas com chaves primárias. ## Métodos de compactação compatíveis com o SQL Server Observe o seguinte sobre os métodos de compactação compatíveis com o SQL Server no AWS DMS: + AWS DMS oferece suporte à Row/Page compactação no SQL Server versão 2008 e posterior. + AWS DMS não suporta o formato de armazenamento Vardecimal. + AWS DMS não suporta colunas esparsas e compressão de estrutura colunar. ## Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server A disponibilidade dos grupos de disponibilidade AlwaysOn do SQL Server fornece alta disponibilidade e recuperação de desastres como alternativa ao espelhamento do banco de dados no nível empresarial. Em AWS DMS, você pode migrar as alterações de uma única réplica primária ou secundária do grupo de disponibilidade. ### Como trabalhar com a réplica primária do grupo de disponibilidade **Para usar o grupo de disponibilidade principal como fonte em AWS DMS, faça o seguinte:** 1. Ative a opção de distribuição em todas as instâncias do SQL Server em suas réplicas de disponibilidade. Para obter mais informações, consulte [Configurar a replicação contínua em um SQL Server autogerenciado](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC). 1. No AWS DMS console, abra as configurações do banco de dados de origem do SQL Server. Em **Nome do servidor**, especifique o nome do serviço de nomes de domínio (DNS) ou o endereço IP configurado para o receptor do grupo de disponibilidade. Quando você inicia uma AWS DMS tarefa pela primeira vez, ela pode levar mais tempo do que o normal para ser iniciada. Essa lentidão ocorre porque a criação dos artigos da tabela está sendo duplicada pelo servidor de grupos de disponibilidade. ### Como trabalhar com uma réplica do grupo de disponibilidade secundário **Para usar um grupo de disponibilidade secundário como origem em AWS DMS, faça o seguinte:** 1. Use as mesmas credenciais usadas pelo usuário do endpoint de AWS DMS origem para se conectar a réplicas individuais. 1. Certifique-se de que sua instância de AWS DMS replicação possa resolver os nomes DNS de todas as réplicas existentes e se conectar a elas. É possível utilizar a consulta SQL a seguir para obter os nomes DNS de todas as réplicas. ``` select ar.replica_server_name, ar.endpoint_url from sys.availability_replicas ar JOIN sys.availability_databases_cluster adc ON adc.group_id = ar.group_id AND adc.database_name = ''; ``` 1. Ao criar o endpoint de origem, especifique o nome DNS do receptor do grupo de disponibilidade do **Nome do servidor** do endpoint ou o **Endereço do servidor** do segredo do endpoint. Para obter mais informações sobre receptores de grupos de disponibilidade, consulte [O que é um receptor de grupos de disponibilidade?](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15) na documentação do SQL Server. É possível utilizar um servidor DNS público ou um servidor DNS on-premises para resolver o receptor do grupo de disponibilidade, a réplica primária e as réplicas secundárias. Para utilizar um servidor DNS on-premises, configure o Amazon Route 53 Resolver. Para obter mais informações, consulte [Utilização do seu próprio servidor de nomes on-premises](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). 1. Adicione os seguintes atributos de conexão adicional ao endpoint de origem. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.SQLServer.html) 1. Ative a opção de distribuição em todas as réplicas no grupo de disponibilidade. Adicione todos os nós à lista de distribuidores. Para obter mais informações, consulte [Como configurar a distribuição](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC.Setup). 1. Execute a consulta a seguir na réplica primária de leitura e gravação para ativar a publicação do banco de dados. Você executa essa consulta somente uma vez para o banco de dados. ``` sp_replicationdboption @dbname = N'', @optname = N'publish', @value = N'true'; ``` #### Limitações Veja a seguir as limitações ao trabalhar com uma réplica secundária do grupo de disponibilidade: + AWS DMS não oferece suporte ao Safeguard ao usar uma réplica de grupo de disponibilidade somente para leitura como fonte. Para obter mais informações, consulte [Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib). + AWS DMS não oferece suporte ao atributo de conexão `setUpMsCdcForTables` extra ao usar uma réplica de grupo de disponibilidade somente para leitura como fonte. Para obter mais informações, consulte [Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib). + AWS DMS pode usar uma réplica autogerenciada do grupo de disponibilidade secundário como banco de dados de origem para replicação contínua (captura de dados de alteração ou CDC) a partir da versão 3.4.7. As réplicas de leitura do Cloud SQL Server Multi-AZ não são compatíveis. Se você usa versões anteriores do AWS DMS, certifique-se de usar a réplica principal do grupo de disponibilidade como banco de dados de origem para o CDC. #### Failover para outros nós Se você definir o atributo de conexão `ApplicationIntent` extra para seu endpoint`ReadOnly`, sua AWS DMS tarefa se conectará ao nó somente leitura com a maior prioridade de roteamento somente para leitura. Ele executa failover para outros nós somente leitura no grupo de disponibilidade quando o nó somente leitura de prioridade mais alta não está disponível. Se você não definir`ApplicationIntent`, sua AWS DMS tarefa se conectará somente ao nó primário (leitura/gravação) em seu grupo de disponibilidade. ## Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS É possível utilizar as configurações de endpoint para configurar a origem do SQL Server de forma semelhante à utilização de atributos de conexão adicional. 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--microsoft-sql-server-settings '{"EndpointSetting": "value", ...}'` JSON. A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o SQL Server como origem. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.SQLServer.html) ## Tipos de dados de origem no SQL Server A migração de dados que usa o SQL Server como fonte de AWS DMS suporte à maioria dos tipos de dados do SQL Server. A tabela a seguir mostra os tipos de dados de origem do SQL Server que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados. 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, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de dados do SQL Server | AWS DMS tipos de dados | | --- | --- | | BIGINT | INT8 | | BIT | BOOLEAN | | DECIMAL | NUMERIC | | INT | INT4 | | MONEY | NUMERIC | | NUMERIC (p,s) | NUMERIC | | SMALLINT | INT2 | | SMALLMONEY | NUMERIC | | TINYINT | UINT1 | | REAL | REAL4 | | FLOAT | REAL8 | | DATETIME | DATETIME | | DATETIME2 (SQL Server 2008 e versões posteriores) | DATETIME | | SMALLDATETIME | DATETIME | | DATE | DATE | | TIME | TIME | | DATETIMEOFFSET | WSTRING | | CHAR | STRING | | VARCHAR | STRING | | VARCHAR (máximo) | CLOB TEXT Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso de tipos de dados CLOB para uma tarefa específica. Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Durante o CDC, AWS DMS suporta tipos de dados CLOB somente em tabelas que incluem uma chave primária. | | NCHAR | WSTRING | | NVARCHAR (tamanho) | WSTRING | | NVARCHAR (máximo) | NCLOB NTEXT Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso de SupportLobs para uma tarefa específica. Para obter mais informações sobre como ativar a compatibilidade com o LOB, consulte [Configurando o suporte LOB para bancos de dados de origem em uma tarefa AWS DMS](CHAP_Tasks.LOBSupport.md). Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Durante o CDC, AWS DMS suporta tipos de dados CLOB somente em tabelas que incluem uma chave primária. | | BINARY | BYTES | | VARBINARY | BYTES | | VARBINARY (máximo) | BLOB IMAGE Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. 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. | | TIMESTAMP | BYTES | | UNIQUEIDENTIFIER | STRING | | HIERARCHYID | Utilize o tipo HIERARCHYID ao replicar para um endpoint de destino do SQL Server. Utilize WSTRING (250) ao replicar para os demais endpoints de destino. | | XML | NCLOB Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. 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. | | GEOMETRY | Utilize o tipo GEOMETRY ao replicar para endpoints de destino compatíveis com esse tipo de dados. Use o tipo CLOB ao replicar para endpoints de destino que não são compatíveis com esse tipo de dados. | | GEOGRAPHY | Utilize o tipo GEOGRAPHY ao replicar para endpoints de destino compatíveis com esse tipo de dados. Use o tipo CLOB ao replicar para endpoints de destino que não são compatíveis com esse tipo de dados. | AWS DMS não oferece suporte a tabelas que incluam campos com os seguintes tipos de dados. + CURSOR + SQL\$1VARIANT + TABLE **nota** A existência de suporte para um tipo de dados definido pelo usuário vai depender do tipo base utilizado. Por exemplo, um tipo de dados definido pelo usuário baseado no tipo DATETIME é tratado como o tipo de dados DATETIME. # Capturar alterações de dados para replicação contínua no SQL Server Este tópico descreve como configurar a replicação de CDC em uma origem do SQL Server. **Topics** + [Capturar dados alterados no SQL Server autogerenciado on-premises ou no Amazon EC2](#CHAP_Source.SQLServer.CDC.Selfmanaged) + [Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem](#CHAP_Source.SQLServer.Configuration) ## Capturar dados alterados no SQL Server autogerenciado on-premises ou no Amazon EC2 Para capturar as alterações de um banco de dados de origem do Microsoft SQL Server, verifique se o banco de dados está configurado para backups completos. Configure o banco de dados no modo de recuperação total ou no modo de registro em log em massa. Para uma fonte autogerenciada do SQL Server, AWS DMS use o seguinte: **Replicação de MS** Para capturar alterações em tabelas com chaves primárias. Você pode configurar isso automaticamente concedendo privilégios de administrador de sistema ao usuário do AWS DMS endpoint na instância de origem do SQL Server. Ou você pode seguir as etapas desta seção para preparar a fonte e usar um usuário que não tenha privilégios de administrador de sistema para o endpoint. AWS DMS **MS-CDC** Para capturar alterações em tabelas sem chaves primárias. Ative a MS-CDC no nível do banco de dados e em todas as tabelas individualmente. Ao configurar um banco de dados SQL Server para replicação contínua (CDC), é possível seguir um destes procedimentos: + Configurar a replicação contínua utilizando o perfil sysadmin. + Configurar a replicação contínua para não utilizar o perfil sysadmin. **nota** Você pode usar o seguinte script para encontrar todas as tabelas sem uma chave primária ou exclusiva: ``` USE [DBname] SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name FROM sys.tables WHERE OBJECTPROPERTY(object_id, 'TableHasPrimaryKey') = 0 AND OBJECTPROPERTY(object_id, 'TableHasUniqueCnst') = 0 ORDER BY schema_name, table_name; ``` ### Configurar a replicação contínua em um SQL Server autogerenciado Esta seção contém informações sobre como configurar a replicação contínua em um servidor SQL autogerenciado com ou sem a utilização do perfil sysadmin. **Topics** + [Configurar a replicação contínua em um SQL Server autogerenciado: utilizando o perfil sysadmin](#CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin) + [Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin](#CHAP_SupportScripts.SQLServer.standalone) + [Configurar a replicação contínua em um SQL Server em um ambiente de grupo de disponibilidade: sem o perfil sysadmin](#CHAP_SupportScripts.SQLServer.ag) #### Configurar a replicação contínua em um SQL Server autogerenciado: utilizando o perfil sysadmin AWS DMS a replicação contínua para o SQL Server usa a replicação nativa do SQL Server para tabelas com chaves primárias e a captura de dados alterados (CDC) para tabelas sem chaves primárias. Antes de configurar a replicação contínua, consulte [Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). Para tabelas com chaves primárias, geralmente é AWS DMS possível configurar os artefatos necessários na fonte. No entanto, para instâncias de origem do SQL Server que são autogerenciadas, configure primeiro a distribuição do SQL Server manualmente. Depois de fazer isso, os usuários de AWS DMS origem com permissão de administrador de sistema podem criar automaticamente a publicação para tabelas com chaves primárias. Para verificar se a distribuição já foi configurada, execute o comando a seguir. ``` sp_get_distributor ``` Se o resultado for `NULL` para a distribuição de colunas, a distribuição não estará configurada. É possível utilizar o procedimento a seguir para configurar a distribuição. **Como configurar a distribuição** 1. Conecte-se ao banco de dados de origem do SQL Server utilizando a ferramenta SQL Server Management Studio (SSMS). 1. Abra o menu de contexto (clique com o botão direito do mouse) da pasta **Replicação** e escolha **Configurar distribuição**. O assistente de configuração da distribuição é exibido. 1. Siga o assistente para inserir os valores padrão e criar a distribuição. **Como configurar a CDC** AWS DMS a versão 3.4.7 e superior pode configurar o MS CDC para seu banco de dados e todas as suas tabelas automaticamente se você não estiver usando uma réplica somente para leitura. Para utilizar esse recurso, defina o ECA `SetUpMsCdcForTables` como verdadeiro. Para obter informações sobre ECAs, consulte[Configurações de endpoint](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.ConnectionAttrib). Para versões AWS DMS anteriores à 3.4.7 ou para uma réplica somente leitura como fonte, execute as seguintes etapas: 1. Para tabelas sem chaves primárias, configure a MS-CDC para o banco de dados. Para fazer isso, utilize uma conta que tenha o perfil sysadmin atribuído a ela e execute o comando a seguir. ``` use [DBname] EXEC sys.sp_cdc_enable_db ``` 1. Configure a MS-CDC para cada uma das tabelas de origem. Para cada tabela com chaves exclusivas, mas sem chave primária, execute a consulta a seguir para configurar a MS-CDC. ``` exec sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @index_name = N'unique_index_name', @role_name = NULL, @supports_net_changes = 1 GO ``` 1. Para cada tabela sem chave primária nem chaves exclusivas, execute a consulta a seguir para configurar a MS-CDC. ``` exec sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @role_name = NULL GO ``` Para obter mais informações sobre como configurar a MS-CDC para tabelas específicas, consulte a [Documentação do SQL Server](https://msdn.microsoft.com/en-us/library/cc627369.aspx). #### Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin Esta seção descreve como configurar a replicação contínua para uma origem de banco de dados SQL Server autônomo que não exige que a conta do usuário tenha privilégios de sysadmin. **nota** Depois de executar as etapas desta seção, o usuário do DMS que não for administrador de sistema terá permissões para fazer o seguinte: Ler as alterações do arquivo de log de transações on-line. Acessar o disco para ler as alterações dos arquivos de backup do log de transações. Adicionar ou alterar a publicação que o DMS usa. Adicionar artigos à publicação. 1. Configure o Microsoft SQL Server para replicação conforme descrito em [Capturar alterações de dados para replicação contínua no SQL Server](#CHAP_Source.SQLServer.CDC). 1. Ative MS-REPLICATION no banco de dados de origem. Isso pode ser feito manualmente ou executando a tarefa uma vez como usuário sysadmin. 1. Crie o esquema `awsdms` no banco de dados de origem utilizando o seguinte script: ``` use master go create schema awsdms go -- Create the table valued function [awsdms].[split_partition_list] on the Master database, as follows: USE [master] GO set ansi_nulls on go set quoted_identifier on go if (object_id('[awsdms].[split_partition_list]','TF')) is not null drop function [awsdms].[split_partition_list]; go create function [awsdms].[split_partition_list] ( @plist varchar(8000), --A delimited list of partitions @dlm nvarchar(1) --Delimiting character ) returns @partitionsTable table --Table holding the BIGINT values of the string fragments ( pid bigint primary key ) as begin declare @partition_id bigint; declare @dlm_pos integer; declare @dlm_len integer; set @dlm_len = len(@dlm); while (charindex(@dlm,@plist)>0) begin set @dlm_pos = charindex(@dlm,@plist); set @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint); insert into @partitionsTable (pid) values (@partition_id) set @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist)); end set @partition_id = cast (ltrim(rtrim(@plist)) as bigint); insert into @partitionsTable (pid) values ( @partition_id ); return end GO ``` 1. Crie o procedimento `[awsdms].[rtm_dump_dblog]` no banco de dados mestre utilizando o seguinte script: ``` use [MASTER] go if (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null drop procedure [awsdms].[rtm_dump_dblog]; go set ansi_nulls on go set quoted_identifier on GO CREATE procedure [awsdms].[rtm_dump_dblog] ( @start_lsn varchar(32), @seqno integer, @filename varchar(260), @partition_list varchar(8000), -- A comma delimited list: P1,P2,... Pn @programmed_filtering integer, @minPartition bigint, @maxPartition bigint ) as begin declare @start_lsn_cmp varchar(32); -- Stands against the GT comparator SET NOCOUNT ON -- – Disable "rows affected display" set @start_lsn_cmp = @start_lsn; if (@start_lsn_cmp) is null set @start_lsn_cmp = '00000000:00000000:0000'; if (@partition_list is null) begin RAISERROR ('Null partition list waspassed',16,1); return end if (@start_lsn) is not null set @start_lsn = '0x'+@start_lsn; if (@programmed_filtering=0) SELECT [Current LSN], [operation], [Context], [Transaction ID], [Transaction Name], [Begin Time], [End Time], [Flag Bits], [PartitionID], [Page ID], [Slot ID], [RowLog Contents 0], [Log Record], [RowLog Contents 1] FROM fn_dump_dblog ( @start_lsn, NULL, N'DISK', @seqno, @filename, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default) where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS and ( ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') ) or ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW') and ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1)))) and [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,',')) ) or ([operation] = 'LOP_HOBT_DDL') ) else SELECT [Current LSN], [operation], [Context], [Transaction ID], [Transaction Name], [Begin Time], [End Time], [Flag Bits], [PartitionID], [Page ID], [Slot ID], [RowLog Contents 0], [Log Record], [RowLog Contents 1] -- After Image FROM fn_dump_dblog ( @start_lsn, NULL, N'DISK', @seqno, @filename, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default) where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS and ( ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') ) or ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW') and ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1)))) and ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition) ) or ([operation] = 'LOP_HOBT_DDL') ) SET NOCOUNT OFF -- Re-enable "rows affected display" end GO ``` 1. Crie o certificado no banco de dados mestre utilizando o seguinte script: ``` Use [master] Go CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert] ENCRYPTION BY PASSWORD = N'@5trongpassword' WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions'; ``` 1. Crie o login no certificado utilizando o seguinte script: ``` Use [master] Go CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE [awsdms_rtm_dump_dblog_cert]; ``` 1. Adicione o login ao perfil do servidor sysadmin utilizando o seguinte script: ``` ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login]; ``` 1. Adicione a assinatura ao [master].[awsdms].[rtm\$1dump\$1dblog] utilizando o certificado e o seguinte script: ``` Use [master] GO ADD SIGNATURE TO [master].[awsdms].[rtm_dump_dblog] BY CERTIFICATE [awsdms_rtm_dump_dblog_cert] WITH PASSWORD = '@5trongpassword'; ``` **nota** Se você recriar o procedimento armazenado, será necessário adicionar a assinatura novamente. 1. Crie o [awsdms].[rtm\$1position\$11st\$1timestamp] no banco de dados principal usando o seguinte script: ``` use [master] if object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp]; go create procedure [awsdms].[rtm_position_1st_timestamp] ( @dbname sysname, -- Database name @seqno integer, -- Backup set sequence/position number within file @filename varchar(260), -- The backup filename @1stTimeStamp varchar(40) -- The timestamp to position by ) as begin SET NOCOUNT ON -- Disable "rows affected display" declare @firstMatching table ( cLsn varchar(32), bTim datetime ) declare @sql nvarchar(4000) declare @nl char(2) declare @tb char(2) declare @fnameVar nvarchar(254) = 'NULL' set @nl = char(10); -- New line set @tb = char(9) -- Tab separator if (@filename is not null) set @fnameVar = ''''+@filename +'''' set @sql='use ['+@dbname+'];'+@nl+ 'select top 1 [Current LSN],[Begin Time]'+@nl+ 'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @fnameVar+','+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default)'+@nl+ 'where operation=''LOP_BEGIN_XACT''' +@nl+ 'and [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl --print @sql delete from @firstMatching insert into @firstMatching exec sp_executesql @sql -- Get them all select top 1 cLsn as [matching LSN],convert(varchar,bTim,121) as [matching Timestamp] from @firstMatching; SET NOCOUNT OFF -- Re-enable "rows affected display" end GO ``` 1. Crie o certificado no banco de dados mestre utilizando o seguinte script: ``` Use [master] Go CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert] ENCRYPTION BY PASSWORD = '@5trongpassword' WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions'; ``` 1. Crie o login no certificado utilizando o seguinte script: ``` Use [master] Go CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]; ``` 1. Adicione o login ao perfil sysadmin utilizando o seguinte script: ``` ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login]; ``` 1. Adicione a assinatura ao [master].[awsdms].[rtm\$1position\$11st\$1timestamp] utilizando o certificado e o seguinte script: ``` Use [master] GO ADD SIGNATURE TO [master].[awsdms].[rtm_position_1st_timestamp] BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert] WITH PASSWORD = '@5trongpassword'; ``` 1. Conceda ao usuário do DMS acesso de execução ao novo procedimento armazenado usando o seguinte script: ``` use master go GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dms_user; ``` 1. Crie um usuário com as seguintes permissões e perfis em cada um dos seguintes bancos de dados: **nota** Crie a conta de usuário dmsnosysadmin com o mesmo SID em cada réplica. A consulta SQL a seguir pode ajudar a verificar o valor do SID da conta dmsnosysadmin em cada réplica. Para obter mais informações sobre como criar um usuário, consulte [CREATE USER (Transact-SQL) ](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) na [Documentação do Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Para obter mais informações sobre a criação de contas de usuário do SQL para o banco de dados SQL do Azure, consulte [Replicação geográfica ativa](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview). ``` use master go grant select on sys.fn_dblog to [DMS_user] grant view any definition to [DMS_user] grant view server state to [DMS_user]--(should be granted to the login). grant execute on sp_repldone to [DMS_user] grant execute on sp_replincrementlsn to [DMS_user] grant execute on sp_addpublication to [DMS_user] grant execute on sp_addarticle to [DMS_user] grant execute on sp_articlefilter to [DMS_user] grant select on [awsdms].[split_partition_list] to [DMS_user] grant execute on [awsdms].[rtm_dump_dblog] to [DMS_user] ``` ``` use msdb go grant select on msdb.dbo.backupset to self_managed_user grant select on msdb.dbo.backupmediafamily to self_managed_user grant select on msdb.dbo.backupfile to self_managed_user ``` Execute o seguinte script no banco de dados de origem: ``` use Source_DB Go EXEC sp_addrolemember N'db_owner', N'DMS_user' ``` 1. Por fim, adicione um atributo de conexão extra (ECA) ao endpoint do SQL Server de origem: ``` enableNonSysadminWrapper=true; ``` #### Configurar a replicação contínua em um SQL Server em um ambiente de grupo de disponibilidade: sem o perfil sysadmin Esta seção descreve como configurar a replicação contínua para uma origem de banco de dados SQL Server em um ambiente de grupo de disponibilidade que não exige que a conta do usuário tenha privilégios de sysadmin. **nota** Depois de executar as etapas desta seção, o usuário do DMS que não for administrador de sistema terá permissões para fazer o seguinte: Ler as alterações do arquivo de log de transações on-line. Acessar o disco para ler as alterações dos arquivos de backup do log de transações. Adicionar ou alterar a publicação que o DMS usa. Adicionar artigos à publicação. **Como configurar a replicação contínua sem utilizar o usuário sysadmin em um ambiente de grupo de disponibilidade** 1. Configure o Microsoft SQL Server para replicação conforme descrito em [Capturar alterações de dados para replicação contínua no SQL Server](#CHAP_Source.SQLServer.CDC). 1. Ative MS-REPLICATION no banco de dados de origem. Isso pode ser feito manualmente ou executando a tarefa uma vez utilizando um usuário sysadmin. **nota** Configure o distribuidor MS-REPLICATION como local ou de uma forma que permita acesso a usuários que não sejam administradores de sistema por meio do servidor vinculado associado. 1. Se a opção do endpoint **Usar exclusivamente sp\$1repldone em uma única tarefa** estiver ativada, interrompa o trabalho do MS-REPLICATION Log Reader. 1. Execute as seguintes etapas em cada réplica: 1. Crie o esquema `[awsdms]`[awsdms] no banco de dados mestre: ``` CREATE SCHEMA [awsdms] ``` 1. Crie o perfil com valor de tabela `[awsdms].[split_partition_list]` no banco de dados mestre: ``` USE [master] GO SET ansi_nulls on GO SET quoted_identifier on GO IF (object_id('[awsdms].[split_partition_list]','TF')) is not null DROP FUNCTION [awsdms].[split_partition_list]; GO CREATE FUNCTION [awsdms].[split_partition_list] ( @plist varchar(8000), --A delimited list of partitions @dlm nvarchar(1) --Delimiting character ) RETURNS @partitionsTable table --Table holding the BIGINT values of the string fragments ( pid bigint primary key ) AS BEGIN DECLARE @partition_id bigint; DECLARE @dlm_pos integer; DECLARE @dlm_len integer; SET @dlm_len = len(@dlm); WHILE (charindex(@dlm,@plist)>0) BEGIN SET @dlm_pos = charindex(@dlm,@plist); SET @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint); INSERT into @partitionsTable (pid) values (@partition_id) SET @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist)); END SET @partition_id = cast (ltrim(rtrim(@plist)) as bigint); INSERT into @partitionsTable (pid) values ( @partition_id ); RETURN END GO ``` 1. Crie o procedimento `[awsdms].[rtm_dump_dblog]` no banco de dados mestre: ``` USE [MASTER] GO IF (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null DROP PROCEDURE [awsdms].[rtm_dump_dblog]; GO SET ansi_nulls on GO SET quoted_identifier on GO CREATE PROCEDURE [awsdms].[rtm_dump_dblog] ( @start_lsn varchar(32), @seqno integer, @filename varchar(260), @partition_list varchar(8000), -- A comma delimited list: P1,P2,... Pn @programmed_filtering integer, @minPartition bigint, @maxPartition bigint ) AS BEGIN DECLARE @start_lsn_cmp varchar(32); -- Stands against the GT comparator SET NOCOUNT ON -- Disable "rows affected display" SET @start_lsn_cmp = @start_lsn; IF (@start_lsn_cmp) is null SET @start_lsn_cmp = '00000000:00000000:0000'; IF (@partition_list is null) BEGIN RAISERROR ('Null partition list was passed',16,1); return --set @partition_list = '0,'; -- A dummy which is never matched END IF (@start_lsn) is not null SET @start_lsn = '0x'+@start_lsn; IF (@programmed_filtering=0) SELECT [Current LSN], [operation], [Context], [Transaction ID], [Transaction Name], [Begin Time], [End Time], [Flag Bits], [PartitionID], [Page ID], [Slot ID], [RowLog Contents 0], [Log Record], [RowLog Contents 1] -- After Image FROM fn_dump_dblog ( @start_lsn, NULL, N'DISK', @seqno, @filename, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default) WHERE [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator. AND ( ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') ) OR ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW') AND ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') ) AND [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,',')) ) OR ([operation] = 'LOP_HOBT_DDL') ) ELSE SELECT [Current LSN], [operation], [Context], [Transaction ID], [Transaction Name], [Begin Time], [End Time], [Flag Bits], [PartitionID], [Page ID], [Slot ID], [RowLog Contents 0], [Log Record], [RowLog Contents 1] -- After Image FROM fn_dump_dblog ( @start_lsn, NULL, N'DISK', @seqno, @filename, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default, default) WHERE [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator. AND ( ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') ) OR ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW') AND ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') ) AND ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition) ) OR ([operation] = 'LOP_HOBT_DDL') ) SET NOCOUNT OFF -- Re-enable "rows affected display" END GO ``` 1. Crie um certificado no banco de dados mestre: ``` USE [master] GO CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert] ENCRYPTION BY PASSWORD = N'@hardpassword1' WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions' ``` 1. Crie um login no certificado: ``` USE [master] GO CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE [awsdms_rtm_dump_dblog_cert]; ``` 1. Adicione o login ao perfil do servidor sysadmin: ``` ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login]; ``` 1. Adicione a assinatura ao procedimento [master].[awsdms].[rtm\$1dump\$1dblog] utilizando o certificado: ``` USE [master] GO ADD SIGNATURE TO [master].[awsdms].[rtm_dump_dblog] BY CERTIFICATE [awsdms_rtm_dump_dblog_cert] WITH PASSWORD = '@hardpassword1'; ``` **nota** Se você recriar o procedimento armazenado, será necessário adicionar a assinatura novamente. 1. Crie o procedimento `[awsdms].[rtm_position_1st_timestamp]` no banco de dados mestre: ``` USE [master] IF object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp]; GO CREATE PROCEDURE [awsdms].[rtm_position_1st_timestamp] ( @dbname sysname, -- Database name @seqno integer, -- Backup set sequence/position number within file @filename varchar(260), -- The backup filename @1stTimeStamp varchar(40) -- The timestamp to position by ) AS BEGIN SET NOCOUNT ON -- Disable "rows affected display" DECLARE @firstMatching table ( cLsn varchar(32), bTim datetime ) DECLARE @sql nvarchar(4000) DECLARE @nl char(2) DECLARE @tb char(2) DECLARE @fnameVar sysname = 'NULL' SET @nl = char(10); -- New line SET @tb = char(9) -- Tab separator IF (@filename is not null) SET @fnameVar = ''''+@filename +'''' SET @filename = ''''+@filename +'''' SET @sql='use ['+@dbname+'];'+@nl+ 'SELECT TOP 1 [Current LSN],[Begin Time]'+@nl+ 'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @filename +','+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default,'+@nl+ @tb+'default, default, default, default, default, default, default)'+@nl+ 'WHERE operation=''LOP_BEGIN_XACT''' +@nl+ 'AND [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl --print @sql DELETE FROM @firstMatching INSERT INTO @firstMatching exec sp_executesql @sql -- Get them all SELECT TOP 1 cLsn as [matching LSN],convert(varchar,bTim,121) AS[matching Timestamp] FROM @firstMatching; SET NOCOUNT OFF -- Re-enable "rows affected display" END GO ``` 1. Crie um certificado no banco de dados mestre: ``` USE [master] GO CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert] ENCRYPTION BY PASSWORD = N'@hardpassword1' WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions'; ``` 1. Crie um login no certificado: ``` USE [master] GO CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]; ``` 1. Adicione o login ao perfil do servidor sysadmin: ``` ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login]; ``` 1. Adicione a assinatura ao procedimento `[master].[awsdms].[rtm_position_1st_timestamp]` utilizando o certificado: ``` USE [master] GO ADD SIGNATURE TO [master].[awsdms].[rtm_position_1st_timestamp] BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert] WITH PASSWORD = '@hardpassword1'; ``` **nota** Se você recriar o procedimento armazenado, será necessário adicionar a assinatura novamente. 1. Crie um usuário com o seguinte permissions/roles em cada um dos seguintes bancos de dados: **nota** Crie a conta de usuário dmsnosysadmin com o mesmo SID em cada réplica. A consulta SQL a seguir pode ajudar a verificar o valor do SID da conta dmsnosysadmin em cada réplica. Para obter mais informações sobre como criar um usuário, consulte [CREATE USER (Transact-SQL) ](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) na [Documentação do Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Para obter mais informações sobre a criação de contas de usuário do SQL para o banco de dados SQL do Azure, consulte [Replicação geográfica ativa](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview). ``` SELECT @@servername servername, name, sid, create_date, modify_date FROM sys.server_principals WHERE name = 'dmsnosysadmin'; ``` 1. Conceda permissões no banco de dados mestre em cada réplica: ``` USE master GO GRANT select on sys.fn_dblog to dmsnosysadmin; GRANT view any definition to dmsnosysadmin; GRANT view server state to dmsnosysadmin -- (should be granted to the login). GRANT execute on sp_repldone to dmsnosysadmin; GRANT execute on sp_replincrementlsn to dmsnosysadmin; GRANT execute on sp_addpublication to dmsnosysadmin; GRANT execute on sp_addarticle to dmsnosysadmin; GRANT execute on sp_articlefilter to dmsnosysadmin; GRANT select on [awsdms].[split_partition_list] to dmsnosysadmin; GRANT execute on [awsdms].[rtm_dump_dblog] to dmsnosysadmin; GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dmsnosysadmin; ``` 1. Conceda permissões no banco de dados msdb em cada réplica: ``` USE msdb GO GRANT select on msdb.dbo.backupset TO self_managed_user GRANT select on msdb.dbo.backupmediafamily TO self_managed_user GRANT select on msdb.dbo.backupfile TO self_managed_user ``` 1. Adicione o perfil `db_owner` ao `dmsnosysadmin` no banco de dados de origem. Como o banco de dados é sincronizado, é possível adicionar o perfil somente na réplica primária. ``` use GO EXEC sp_addrolemember N'db_owner', N'dmsnosysadmin' ``` ## Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem Esta seção descreve como configurar a CDC em uma instância de banco de dados SQL Server hospedada na nuvem. Uma instância do SQL Server hospedada na nuvem é uma instância em execução no Amazon RDS para SQL Server, uma instância gerenciada do Azure SQL ou qualquer outra instância gerenciada do SQL Server na nuvem. Para obter informações sobre as limitações da replicação contínua para cada tipo de banco de dados, consulte [Limitações no uso do SQL Server como fonte para AWS DMS](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Limitations). Antes de configurar a replicação contínua, consulte [Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). Ao contrário das origens autogerenciadas do SQL Server, o Amazon RDS para SQL Server não é compatível com a MS-Replication. Portanto, AWS DMS precisa usar o MS-CDC para tabelas com ou sem chaves primárias. O Amazon RDS não concede privilégios de administrador de sistema para definir artefatos de replicação AWS DMS usados para alterações contínuas em uma instância de origem do SQL Server. Ative a MS-CDC na instância do Amazon RDS (utilizando privilégios de usuário mestre) como no procedimento a seguir. **Para ativar a MS-CDC em uma instância de banco de dados do SQL Server na nuvem** 1. Execute as consultas a seguir no nível do banco de dados. Para uma instância de banco de dados RDS para SQL Server, utilize essa consulta. ``` exec msdb.dbo.rds_cdc_enable_db 'DB_name' ``` Para uma instância de banco de dados gerenciada do Azure SQL, utilize essa consulta. ``` USE DB_name GO EXEC sys.sp_cdc_enable_db GO ``` 1. Para cada tabela com uma chave primária, execute a consulta a seguir para ativar a MS-CDC. ``` exec sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @role_name = NULL, @supports_net_changes = 1 GO ``` Para cada tabela com chaves exclusivas, mas sem chave primária, execute a consulta a seguir para ativar a MS-CDC. ``` exec sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @index_name = N'unique_index_name', @role_name = NULL, @supports_net_changes = 1 GO ``` Para cada tabela sem chave primária e sem chaves exclusivas, execute a consulta a seguir para habilitar a MS-CDC. ``` exec sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @role_name = NULL GO ``` 1. Defina o período de retenção: + Para instâncias do RDS para SQL Server que estão sendo replicadas usando o DMS versão 3.5.3 e superiores, garanta que o período de retenção esteja definido com o valor padrão de 5 segundos. Se você estiver atualizando ou migrando do DMS 3.5.2 e versões anteriores para o DMS 3.5.3 e versões posteriores, altere o valor do intervalo de sondagem depois que as tarefas estiverem em execução na instância nova ou atualizada. O script a seguir define o período de retenção como 5 segundos: ``` use dbname EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 5 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' ``` + O parâmetro `@pollinginterval` é medido em segundos com um valor recomendado definido como 86399. Isso significa que o log de transações retém as alterações por 86.399 segundos (um dia) quando `@pollinginterval = 86399`. O procedimento `exec sp_cdc_start_job 'capture'` inicia as configurações. **nota** Com algumas versões do SQL Server, se o valor de `pollinginterval` for definido como mais de 3599 segundos, o valor será redefinido para os cinco segundos padrão. Quando isso acontece, as entradas do T-Log são removidas antes que AWS DMS você possa lê-las. Para determinar quais versões do SQL Server são afetadas por esse problema conhecido, consulte [este artigo da Microsoft KB](https://support.microsoft.com/en-us/topic/kb4459220-fix-incorrect-results-occur-when-you-convert-pollinginterval-parameter-from-seconds-to-hours-in-sys-sp-cdc-scan-in-sql-server-dac8aefe-b60b-7745-f987-582dda2cfa78). Se estiver utilizando o Amazon RDS com multi-AZ, defina também o secundário para ter os valores corretos em caso de failover. ``` exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , <5 or preferred value> ``` **Para manter o período de retenção quando uma tarefa de AWS DMS replicação é interrompida por mais de uma hora** **nota** As etapas a seguir não são necessárias para replicação de uma origem do RDS para SQL Server usando o DMS 3.5.3 e superiores. 1. Interrompa o trabalho que está truncando os logs de transações utilizando este comando: ``` exec sp_cdc_stop_job 'capture' ``` 1. Encontre sua tarefa no AWS DMS console e continue a tarefa. 1. Escolha a guia **Monitoramento** e marque a métrica `CDCLatencySource`. 1. Quando a métrica `CDCLatencySource` for igual a 0 (zero) e permanecer nesse valor, reinicie o trabalho truncando os logs de transações com o seguinte comando: ``` exec sp_cdc_start_job 'capture' ``` Lembre-se de iniciar o trabalho que trunca os logs de transações do SQL Server. Caso contrário, o armazenamento na instância do SQL Server poderá ficar cheio. ### Configurações recomendadas ao usar o RDS para SQL Server como fonte para AWS DMS #### Para AWS DMS 3.5.3 e superior **nota** A versão inicial do recurso de backup de log do RDS para SQL Server está habilitada por padrão para endpoints que você criou ou modificou após o lançamento do DMS versão 3.5.3. Para usar esse recurso para endpoints existentes, modifique o endpoint sem fazer nenhuma alteração. AWS DMS a versão 3.5.3 introduz suporte para leitura de backups de log. O DMS depende principalmente da leitura dos logs de transações ativos para replicar eventos. Se o backup de uma transação for feito antes que o DMS possa lê-la no log ativo, a tarefa acessará os backups do RDS sob demanda e lerá os logs de backup subsequentes até alcançar o log de transações ativo. Para garantir que o DMS tenha acesso aos backups de log, defina o período de retenção de backup automatizado do RDS para pelo menos um dia. Para ter informações sobre como configurar o período de retenção de backup automatizado, consulte [Período de retenção de backup](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupRetention) no *Guia do usuário do Amazon RDS*. Uma tarefa do DMS que acessa os backups de log utiliza o armazenamento na instância do RDS. Observe que a tarefa só acessa os backups de log necessários para a replicação. O Amazon RDS remove esses backups baixados em algumas horas. Essa remoção não afeta os backups do Amazon RDS retidos no Amazon S3 ou a funcionalidade `RESTORE DATABASE` do Amazon RDS. É recomendável alocar armazenamento adicional em sua origem do RDS para SQL Server, se pretender replicar usando o DMS. Uma forma de estimar a quantidade de armazenamento necessária é identificar o backup a partir do qual o DMS iniciará ou retomará a replicação e somar os tamanhos dos arquivos de todos os backups subsequentes usando a função de metadados `tlog backup` do RDS. Para ter mais informações sobre a função `tlog backup`, consulte [Listar os backups de logs de transações disponíveis](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER.SQLServer.AddlFeat.TransactionLogAccess.html#USER.SQLServer.AddlFeat.TransactionLogAccess.Listing) no *Guia do usuário do Amazon RDS*. Como alternativa, você pode optar por ativar o escalonamento automático de armazenamento e/ou acionar o escalonamento de armazenamento com base na métrica CloudWatch `FreeStorageSpace` da sua instância do Amazon RDS. É altamente recomendável que você não inicie ou retome a partir de um ponto muito distante nos backups do log de transações, pois isso pode fazer com que o armazenamento em sua instância do SQL Server fique cheio. Nesses casos, é aconselhável iniciar uma carga máxima. A replicação do backup do log de transações é mais lenta do que a leitura dos logs de transações ativos. Para obter mais informações, consulte [Processamento de backup do log de transações do RDS para SQL Server](CHAP_Troubleshooting_Latency_Source_SQLServer.md#CHAP_Troubleshooting_Latency_Source_SQLServer_backup). Observe que o acesso aos backups de log requer privilégios adicionais. Para ter mais informações, consulte os detalhes em [Configurar permissões para replicação contínua a partir de um banco de dados do SQL Server na nuvem](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Permissions.Cloud). Conceda esses privilégios antes que a tarefa comece a ser replicada. #### Para AWS DMS 3.5.2 e versões anteriores Quando você trabalha com o Amazon RDS para SQL Server como origem, o trabalho de captura do MS-CDC depende dos parâmetros `maxscans` e `maxtrans`. Esses parâmetros governam o número máximo de verificações que a captura do MS-CDC faz no log de transações e o número de transações que são processadas para cada verificação. Para bancos de dados, em que o número de transações é maior que `maxtrans*maxscans`, aumentar o valor de `polling_interval` pode causar um acúmulo de registros no log de transações. Por sua vez, esse acúmulo pode levar a um aumento no tamanho do log de transações. Observe que AWS DMS não depende da tarefa de captura do MS-CDC. A tarefa de captura da MS-CDC marca as entradas do log de transações como processadas. Isso permite que a tarefa de backup do log de transações remova as entradas do log de transações. É recomendável monitorar o tamanho do log de transações e o sucesso das tarefas da MS-CDC. Se as tarefas do MS-CDC falharem, o registro de transações poderá crescer excessivamente e causar falhas na replicação. AWS DMS É possível monitorar erros do trabalho de captura da MS-CDC utilizando a visualização de gerenciamento dinâmico `sys.dm_cdc_errors` no banco de dados de origem. É possível monitorar o tamanho do log de transações utilizando o comando de gerenciamento `DBCC SQLPERF(LOGSPACE)`. **Como abordar o aumento do log de transações causado pela MS-CDC** 1. Verifique de onde `Log Space Used %` o banco de dados AWS DMS está sendo replicado e valide se ele aumenta continuamente. ``` DBCC SQLPERF(LOGSPACE) ``` 1. Identifique o que está bloqueando o processo de backup do log de transações. ``` Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name(); ``` Se o valor de `log_reuse_wait_desc` for igual a `REPLICATION`, a retenção do backup do log será causada pela latência na MS-CDC. 1. Aumente o número de eventos processados pelo trabalho de captura aumentando os valores dos parâmetros `maxtrans` e `maxscans`. ``` EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@maxtrans = 5000, @maxscans = 20 exec sp_cdc_stop_job 'capture' exec sp_cdc_start_job 'capture' ``` Para resolver esse problema, defina os valores de `maxscans` e para que `maxtrans` `maxtrans*maxscans` sejam iguais ao número médio de eventos gerados para tabelas que são AWS DMS replicadas do banco de dados de origem para cada dia. Se você definir esses parâmetros acima do valor recomendado, os trabalhos de captura processarão todos os eventos nos logs de transações. Se você definir esses parâmetros abaixo do valor recomendado, a latência da MS-CDC aumentará e o log de transações também. A identificação dos valores apropriados para `maxscans` e `maxtrans` pode ser difícil porque as alterações na workload produzem um número variável de eventos. Nesse caso, é recomendável configurar o monitoramento na latência da MS-CDC. Para obter mais informações, consulte [Monitorar o processo](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/administer-and-monitor-change-data-capture-sql-server?view=sql-server-ver15#Monitor) na documentação do SQL Server. Configure `maxtrans` e `maxscans` dinamicamente com base nos resultados do monitoramento. Se a AWS DMS tarefa não conseguir encontrar os números de sequência de log (LSNs) necessários para retomar ou continuar a tarefa, a tarefa poderá falhar e exigir uma recarga completa. **nota** Ao usar AWS DMS para replicar dados de uma fonte do RDS para SQL Server, você pode encontrar erros ao tentar retomar a replicação após um evento de stop-start da instância do Amazon RDS. Isso ocorre porque o processo do SQL Server Agent reinicia o processo da tarefa de captura quando ele é reiniciado após o evento de interrupção-inicialização. Isso ignora o intervalo de pesquisa da MS-CDC. Por esse motivo, em bancos de dados com volumes de transações menores do que o processamento da tarefa de captura do MS-CDC, isso pode fazer com que os dados sejam processados ou marcados como replicados e copiados antes AWS DMS de serem retomados de onde pararam, resultando no seguinte erro: ``` [SOURCE_CAPTURE ]E: Failed to access LSN '0000dbd9:0006f9ad:0003' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:764) ``` Para mitigar esse problema, defina os valores de `maxtrans` e de `maxscans` conforme recomendado anteriormente. # Usando o banco de dados SQL do Microsoft Azure como fonte para AWS DMS Com AWS DMS, você pode usar o Banco de Dados SQL do Microsoft Azure como fonte da mesma forma que usa o SQL Server. AWS DMS suporta, como fonte, a mesma lista de versões de banco de dados que são compatíveis com o SQL Server executado localmente ou em uma instância do Amazon EC2. Para obter mais informações, consulte [Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS](CHAP_Source.SQLServer.md). **nota** AWS DMS não oferece suporte a operações de captura de dados de alteração (CDC) com o Banco de Dados SQL do Azure. # Usando a Instância Gerenciada SQL do Microsoft Azure como fonte para AWS DMS Com AWS DMS, você pode usar a Instância Gerenciada SQL do Microsoft Azure como fonte da mesma forma que usa o SQL Server. AWS DMS suporta, como fonte, a mesma lista de versões de banco de dados que são compatíveis com o SQL Server executado localmente ou em uma instância do Amazon EC2. Para obter mais informações, consulte [Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS](CHAP_Source.SQLServer.md). # Usando o servidor flexível do Banco de Dados Microsoft Azure para PostgreSQL como fonte para AWS DMS Com AWS DMS, você pode usar o servidor flexível do Banco de Dados do Microsoft Azure para PostgreSQL como fonte da mesma forma que usa com o PostgreSQL. Para obter informações sobre as versões do servidor flexível do Banco de Dados Microsoft Azure para PostgreSQL AWS DMS que oferecem suporte como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) ## Configurar o servidor flexível do Microsoft Azure para PostgreSQL para replicação lógica e decodificação É possível utilizar os recursos de replicação lógica e decodificação no servidor flexível do Microsoft Azure Database para PostgreSQL durante a migração do banco de dados. Para decodificação lógica, o DMS utiliza o plug-in `test_decoding` ou `pglogical`. Se o plug-in `pglogical` estiver disponível em um banco de dados PostgreSQL de origem, o DMS criará um slot de replicação utilizando o `pglogical`, caso contrário, o plug-in `test_decoding` será utilizado. Para configurar o servidor flexível do Microsoft Azure para PostgreSQL como um endpoint de origem para o DMS, execute as seguintes etapas: 1. Abra a página Parâmetros do servidor no portal. 1. Defina o parâmetro `wal_level` do servidor como `LOGICAL`. 1. Se quiser utilizar a extensão `pglogical`, defina os parâmetros `shared_preload_libraries` e `azure.extensions` como`pglogical`. 1. Defina o parâmetro `max_replication_slots` como o número máximo de tarefas do DMS que você planeja executar simultaneamente. No Microsoft Azure, o valor padrão desse parâmetro é 10. O valor máximo desse parâmetro depende da memória disponível na instância do PostgreSQL, permitindo entre 2 e 8 slots de replicação por GB de memória. 1. Defina o parâmetro `max_wal_senders` como um valor maior que 1. O parâmetro `max_wal_senders` define o número de tarefas simultâneas que podem ser executadas. O valor padrão é 10. 1. Defina o valor do parâmetro `max_worker_processes` como pelo menos 16. Caso contrário, você poderá ver erros como os seguintes: ``` WARNING: out of background worker slots. ``` 1. Salve as alterações. Reinicie o servidor para aplicar as alterações. 1. Confirme se a instância do PostgreSQL permite tráfego de rede no recurso de conexão. 1. Conceda permissões de replicação a um usuário existente ou crie um novo usuário com permissões de replicação utilizando os comandos a seguir. + Conceda as permissões de replicação a um usuário existente utilizando o seguinte comando: ``` ALTER USER WITH REPLICATION; ``` + Crie um novo usuário com permissões de replicação utilizando o seguinte comando: ``` CREATE USER aws_dms_user PASSWORD 'aws_dms_user_password'; GRANT azure_pg_admin to aws_dms_user; ALTER ROLE aws_dms_user REPLICATION LOGIN; ``` Para obter mais informações sobre a replicação lógica com o PostgreSQL, consulte os tópicos a seguir: + [Ativar a captura de dados de alteração (CDC) utilizando replicação lógica](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security) + [Utilizar pontos de início nativos da CDC para configurar uma carga de CDC de uma origem PostgreSQL](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.v10) + [Replicação lógica e decodificação lógica no Azure Database for PostgreSQL: servidor flexível](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-logical) na [Documentação do Azure Database para PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/). # Usando o servidor flexível do Banco de Dados do Microsoft Azure para MySQL como fonte para AWS DMS Com AWS DMS, você pode usar o servidor flexível do Banco de Dados do Microsoft Azure para MySQL como fonte da mesma forma que usa o MySQL. Para obter informações sobre as versões do servidor flexível do Banco de Dados do Microsoft Azure para MySQL que AWS DMS oferecem suporte como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) Para obter mais informações sobre como usar um banco de dados compatível com MySQL gerenciado pelo cliente, consulte. AWS DMS[Usando um banco de dados autogerenciado compatível com MySQL como fonte para AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.CustomerManaged) ## Limitações ao usar o Azure MySQL como fonte para AWS Database Migration Service + O valor padrão da variável de sistema do servidor flexível MySQL do Azure `sql_generate_invisible_primary_key` é`ON`, e o servidor adiciona automaticamente uma chave primária invisível (GIPK) gerada a qualquer tabela criada sem uma chave primária explícita. AWS DMS não oferece suporte à replicação contínua de tabelas MySQL com restrições GIPK. # Usando o OCI MySQL Heatwave como fonte para AWS DMS Com AWS DMS, você pode usar o OCI MySQL Heatwave como fonte da mesma forma que usa o MySQL. A utilização do OCI MySQL Heatwave como origem requer algumas mudanças adicionais na configuração. Para obter informações sobre as versões do OCI MySQL Heatwave AWS DMS que oferecem suporte como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) ## Configurar o OCI MySQL Heatwave para replicação lógica Para configurar a instância do OCI MySQL Heatwave como um endpoint de origem do DMS, faça o seguinte: 1. Faça login no console do OCI e abra o menu principal de hambúrguer (≡) no canto superior esquerdo. 1. Escolha **Bancos de dados**, **Sistemas de banco de dados**. 1. Abra o menu **Configurações**. 1. Escolha **Criar configuração**. 1. Insira um nome da configuração, como **dms\$1configuration**. 1. Escolha a forma da instância do OCI MySQL Heatwave atual. É possível encontrar a forma da **Configuração do sistema de banco de dados** da instância, na seção **Configuração do sistema de banco de dados: forma**. 1. Na seção **Variáveis do usuário**, escolha a variável `binlog_row_value_options` do sistema. O valor padrão é `PARTIAL_JSON`. Limpe o valor. 1. Escolha o botão **Criar**. 1. Abra sua SQLHeatwave instância OCI My e escolha o botão **Editar**. 1. Na seção **Configuração**, escolha o botão **Alterar configuração** e escolha a configuração da forma que você criou na etapa 4. 1. Depois que as alterações estiverem em vigor, a instância estará pronta para a replicação lógica. # Usando o Google Cloud para MySQL como fonte para AWS DMS Com AWS DMS, você pode usar o Google Cloud para MySQL como fonte da mesma forma que usa o MySQL. Para obter informações sobre as versões do GCP MySQL AWS DMS compatíveis como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) Para obter mais informações, consulte [Usando um banco de dados compatível com MySQL como fonte para AWS DMS](CHAP_Source.MySQL.md). **nota** O suporte para o GCP MySQL 8.0 como fonte está disponível AWS DMS na versão 3.4.6. AWS DMS não é compatível com o modo SSL `verify-full` para instâncias do GCP para MySQL. A `Allow only SSL connections` configuração de segurança do GCP MySQL não é compatível porque exige a verificação do certificado do servidor e do cliente. AWS DMS só oferece suporte à verificação do certificado do servidor. AWS DMS suporta o valor padrão do GCP CloudSQL para MySQL de para o sinalizador de banco de `CRC32` dados. `binlog_checksum` # Usando o Google Cloud para PostgreSQL como fonte para AWS DMS Com AWS DMS, você pode usar o Google Cloud para PostgreSQL como fonte da mesma forma que usa bancos de dados PostgreSQL autogerenciados. Para obter informações sobre as versões do GCP PostgreSQL compatíveis como fonte AWS DMS , consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) Para obter mais informações, consulte [Usando um banco de dados PostgreSQL como fonte AWS DMS](CHAP_Source.PostgreSQL.md). ## Configurar o Google Cloud para PostgreSQL para replicação lógica e decodificação É possível utilizar os recursos lógicos de replicação e de decodificação no Google Cloud SQL para PostgreSQL durante a migração do banco de dados. Para decodificação lógica, o DMS utiliza um dos seguintes plug-ins: + `test_decoding` + `pglogical` Se o plug-in `pglogical` estiver disponível em um banco de dados PostgreSQL de origem, o DMS criará um slot de replicação utilizando o `pglogical`, caso contrário, o plug-in `test_decoding` será utilizado. Observe o seguinte sobre o uso da decodificação lógica com AWS DMS: 1. Com o Google Cloud SQL para PostgreSQL, ative a decodificação lógica definindo a sinalização `cloudsql.logical_decoding` como `on`. 1. Para ativar o `pglogical`, defina o sinalizador `cloudsql.enable_pglogical` como `on` e reinicie o banco de dados. 1. Para utilizar os recursos de decodificação lógica, crie um usuário do PostgreSQL com o atributo `REPLICATION`. Ao utilizar a extensão do `pglogical`, o usuário deve ter o perfil `cloudsqlsuperuser`. Para criar um usurário com o perfil `cloudsqlsuperuser`, faça o seguinte: ``` CREATE USER new_aws_dms_user WITH REPLICATION IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'new_aws_dms_user_password'; ``` Para definir esse atributo em um usuário existente, faça o seguinte: ``` ALTER USER existing_user WITH REPLICATION; ``` 1. Defina o parâmetro `max_replication_slots` como o número máximo de tarefas do DMS que você planeja executar simultaneamente. No Google Cloud SQL, o valor padrão desse parâmetro é 10. O valor máximo desse parâmetro depende da memória disponível na instância do PostgreSQL, permitindo entre 2 e 8 slots de replicação por GB de memória. Para obter mais informações sobre a replicação lógica com o PostgreSQL, consulte os tópicos a seguir: + [Ativar a captura de dados de alteração (CDC) utilizando replicação lógica](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security) + [Utilizar pontos de início nativos da CDC para configurar uma carga de CDC de uma origem PostgreSQL](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.v10) + [Configurar a replicação lógica e a decodificação](https://cloud.google.com/sql/docs/postgres/replication/configure-logical-replication) na [Documentação do Cloud SQL para PostgreSQL](https://cloud.google.com/sql/docs/postgres). # Usando um banco de dados PostgreSQL como fonte AWS DMS Você pode migrar dados de um ou vários bancos de dados PostgreSQL usando o. AWS DMS Com um banco de dados PostgreSQL como origem, é possível migrar dados para outro banco de dados PostgreSQL ou para um dos outros bancos de dados compatíveis. Para obter informações sobre as versões do PostgreSQL AWS DMS que oferecem suporte como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) AWS DMS oferece suporte ao PostgreSQL para esses tipos de bancos de dados: + Bancos de dados on-premises + Bancos de dados em uma instância do Amazon EC2 + Bancos de dados em uma instância de banco de dados Amazon RDS + Bancos de dados em uma instância de banco de dados com base na edição do Amazon Aurora compatível com PostgreSQL + Bancos de dados em uma instância de banco de dados com base na edição Tecnologia Sem Servidor do Amazon Aurora compatível com o PostgreSQL **nota** O DMS é compatível com o Amazon Aurora PostgreSQL—com Tecnologia Sem Servidor V1 como origem somente para carga máxima. Mas é possível utilizar o Amazon Aurora PostgreSQL—com Tecnologia Sem Servidor V2 como origem para tarefas de carga máxima, carga máxima \$1 CDC e CDC somente. É possível utilizar o Secure Socket Layers (SSL) para criptografar conexões entre o endpoint do PostgreSQL e a instância de replicação. Para obter mais informações sobre como utilizar o SSL com um endpoint do PostgreSQL, consulte [Usando SSL com AWS Database Migration Service](CHAP_Security.SSL.md). O único requisito de segurança ao utilizar o PostgreSQL como origem é que a conta de usuário especificada deve ser de um usuário registrado no banco de dados PostgreSQL. Para configurar um banco de dados PostgreSQL como AWS DMS um endpoint de origem, faça o seguinte: + Crie um usuário do PostgreSQL com as permissões apropriadas para AWS DMS fornecer acesso ao seu banco de dados de origem do PostgreSQL. **nota** Se o banco de dados de origem PostgreSQL for autogerenciado, consulte [Trabalhando com bancos de dados PostgreSQL autogerenciados como fonte em AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites) para obter mais informações. Se o banco de dados de origem PostgreSQL for gerenciado pelo Amazon RDS, consulte [Trabalhando com bancos AWS de dados PostgreSQL gerenciados como fonte de DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL) para obter mais informações. + Crie um endpoint de origem do PostgreSQL que esteja em conformidade com a configuração do banco do dados PostgreSQL escolhida. + Crie uma tarefa ou um conjunto de tarefas para migrar as tabelas. Para criar uma full-load-only tarefa, nenhuma configuração adicional de endpoint é necessária. Antes de criar uma tarefa de captura de dados de alteração (uma tarefa de CDC somente ou de carga máxima e CDC), consulte [Habilitando o CDC usando um banco de dados PostgreSQL autogerenciado como fonte AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) ou [Habilitando o CDC com uma instância de banco AWS de dados PostgreSQL gerenciada com AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC). **Topics** + [Trabalhando com bancos de dados PostgreSQL autogerenciados como fonte em AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites) + [Trabalhando com bancos AWS de dados PostgreSQL gerenciados como fonte de DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL) + [Ativar a captura de dados de alteração (CDC) utilizando replicação lógica](#CHAP_Source.PostgreSQL.Security) + [Utilizar pontos de início nativos da CDC para configurar uma carga de CDC de uma origem PostgreSQL](#CHAP_Source.PostgreSQL.v10) + [Migrando do PostgreSQL para o PostgreSQL usando AWS DMS](#CHAP_Source.PostgreSQL.Homogeneous) + [Migração do Babelfish para o Amazon Aurora PostgreSQL usando AWS DMS](#CHAP_Source.PostgreSQL.Babelfish) + [Removendo AWS DMS artefatos de um banco de dados de origem do PostgreSQL](#CHAP_Source.PostgreSQL.CleanUp) + [Definições de configuração adicionais ao utilizar um banco de dados PostgreSQL como origem do DMS](#CHAP_Source.PostgreSQL.Advanced) + [Ler a réplica como origem do PostgreSQL](#CHAP_Source.PostgreSQL.ReadReplica) + [Utilizar a configuração de endpoint `MapBooleanAsBoolean` do PostgreSQL](#CHAP_Source.PostgreSQL.ConnectionAttrib.Endpointsetting) + [Configurações de endpoint e atributos extras de conexão (ECAs) ao usar o PostgreSQL como fonte de DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib) + [Limitações ao utilizar um banco de dados PostgreSQL como origem do DMS](#CHAP_Source.PostgreSQL.Limitations) + [Tipos de dados de origem para o PostgreSQL](#CHAP_Source-PostgreSQL-DataTypes) ## Trabalhando com bancos de dados PostgreSQL autogerenciados como fonte em AWS DMS Com um banco de dados PostgreSQL autogerenciado como fonte, você pode migrar dados para outro banco de dados PostgreSQL ou para um dos outros bancos de dados de destino suportados pelo. AWS DMS A origem do banco de dados pode ser um banco de dados on-premises ou um mecanismo autogerenciado em execução em uma instância do Amazon EC2. É possível utilizar uma instância de banco de dados para tarefas de carga máxima e de captura de dados de alteração (CDC). ### Pré-requisitos para usar um banco de dados PostgreSQL autogerenciado como fonte AWS DMS Antes de migrar dados de um banco de dados PostgreSQL de origem autogerenciado, faça o seguinte: + Utilize um banco de dados PostgreSQL com a versão 9.4.x ou superior. + Para tarefas de carga máxima mais CDC ou tarefas de somente CDC, conceda permissões de superusuário para a conta de usuário especificada para o banco de dados de origem do PostgreSQL. A conta de usuário precisa de permissões de superusuário para acessar perfis específicos de replicação na origem. A conta de usuário do DMS precisa de permissões SELECT em todas as colunas para migrar tabelas com êxito. No caso de perda de permissões nas colunas, o DMS cria uma tabela de destino usando mapeamentos regulares de tipos de dados do DMS, o que provoca diferenças nos metadados e falhas nas tarefas. + Adicione o endereço IP do servidor de AWS DMS replicação ao arquivo de `pg_hba.conf` configuração e habilite a replicação e as conexões de soquete. Veja a seguir um exemplo. ``` # Replication Instance host all all 12.3.4.56/00 md5 # Allow replication connections from localhost, by a user with the # replication privilege. host replication dms 12.3.4.56/00 md5 ``` O arquivo de configuração `pg_hba.conf` do PostgreSQL controla a autenticação do cliente. (HBA significa autenticação baseada em host.) O arquivo é tradicionalmente armazenado no diretório de dados do cluster de banco de dados. + Se você estiver configurando um banco de dados como fonte para replicação lógica usando consulte AWS DMS [Habilitando o CDC usando um banco de dados PostgreSQL autogerenciado como fonte AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) **nota** Algumas AWS DMS transações ficam inativas por algum tempo antes que o mecanismo do DMS as use novamente. Com a utilização do parâmetro `idle_in_transaction_session_timeout` no PostgreSQL versões 9.6 e superior é possível fazer com que as transações ociosas atinjam o tempo limite e falhem. Não encerre transações ociosas quando você usar o AWS DMS. ### Habilitando o CDC usando um banco de dados PostgreSQL autogerenciado como fonte AWS DMS AWS DMS suporta captura de dados de alteração (CDC) usando replicação lógica. Para ativar a replicação lógica de um banco de dados de origem do PostgreSQL autogerenciado, defina os seguintes parâmetros e valores no arquivo de configuração `postgresql.conf`: + Defina `wal_level = logical`. + Defina `max_replication_slots` como um valor maior que 1. Defina o valor de `max_replication_slots` de acordo com o número de tarefas a serem executadas. Por exemplo, para executar cinco tarefas, defina no mínimo cinco slots. Os slots são abertos automaticamente assim que uma tarefa é iniciada e permanecem abertos até mesmo quando a tarefa não está mais em execução. Exclua manualmente os slots abertos. Observe que o DMS descarta automaticamente os slots de replicação quando a tarefa é excluída, se o DMS tiver criado o slot. + Defina `max_wal_senders` como um valor maior que 1. O parâmetro `max_wal_senders` define o número de tarefas simultâneas que podem ser executadas. + O parâmetro `wal_sender_timeout` encerra as conexões de replicação que estão inativas por mais tempo do que o número de milissegundos especificado. O padrão para um banco de dados PostgreSQL on-premises é 60000 milissegundos (60 segundos). A definição do valor como 0 (zero) desativa o mecanismo de tempo limite e é uma configuração válida para o DMS. Ao definir `wal_sender_timeout` como um valor diferente de zero, uma tarefa do DMS com CDC requer um mínimo de 10000 milissegundos (10 segundos) e falha se o valor for menor que 10000. Mantenha o valor em menos de 5 minutos para evitar provocar um atraso durante um failover de multi-AZ de uma instância de replicação do DMS. Alguns parâmetros são estáticos, e você só pode defini-los na inicialização do servidor. Quaisquer alterações nas entradas do arquivo de configuração (para um banco de dados autogerenciado) ou no grupo de parâmetros do banco de dados (para um banco de dados RDS para PostgreSQL) são ignoradas até que o servidor seja reiniciado. Para obter mais informações, consulte a [Documentação do PostgreSQL](https://www.postgresql.org/docs/current/intro-whatis.html). Para obter mais informações sobre como ativar a CDC, consulte [Ativar a captura de dados de alteração (CDC) utilizando replicação lógica](#CHAP_Source.PostgreSQL.Security). ## Trabalhando com bancos AWS de dados PostgreSQL gerenciados como fonte de DMS Você pode usar uma instância AWS de banco de dados PostgreSQL gerenciada como fonte para. AWS DMSÉ possível executar tarefas de carga máxima e tarefas de captura de dados de alteração (CDC) utilizando uma origem PostgreSQL gerenciado pela AWS. ### Pré-requisitos para usar um banco de dados AWS PostgreSQL gerenciado como fonte de DMS Antes de migrar dados de um banco de dados de origem AWS PostgreSQL gerenciado, faça o seguinte: + Recomendamos que você use uma conta de AWS usuário com as permissões mínimas necessárias para a instância de banco de dados PostgreSQL como a conta de usuário para o endpoint de origem do PostgreSQL. AWS DMS A utilização de uma conta mestre não é recomendada. A conta deve ter o perfil `rds_superuser` e o perfil `rds_replication`. O perfil `rds_replication` concede permissões para gerenciar slots lógicos e transmitir dados utilizando slots lógicos. Crie vários objetos da conta do usuário mestre para a conta que você utiliza. Para obter mais informações sobre como criar esses objetos, consulte [Migrar um banco de dados Amazon RDS para PostgreSQL sem utilizar a conta de usuário mestre](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser). + Se o banco de dados de origem estiver em uma nuvem privada virtual (VPC), selecione o grupo de segurança da VPC que fornece acesso à instância de banco de dados em que o banco de dados reside. Isso é necessário para que a instância de replicação do DMS se conecte com êxito à instância de banco de dados de origem. Quando o banco de dados e a instância de replicação do DMS estiverem na mesma VPC, adicione o grupo de segurança apropriado às suas próprias regras de entrada. **nota** Algumas AWS DMS transações ficam inativas por algum tempo antes que o mecanismo do DMS as use novamente. Com a utilização do parâmetro `idle_in_transaction_session_timeout` no PostgreSQL versões 9.6 e superior é possível fazer com que as transações ociosas atinjam o tempo limite e falhem. Não encerre transações ociosas quando você usar o AWS DMS. ### Habilitando o CDC com uma instância de banco AWS de dados PostgreSQL gerenciada com AWS DMS AWS DMS oferece suporte ao CDC nos bancos de dados PostgreSQL do Amazon RDS quando a instância de banco de dados está configurada para usar a replicação lógica. A tabela a seguir resume a compatibilidade de replicação lógica de cada versão AWS gerenciada do PostgreSQL. | Versão do PostgreSQL | AWS DMS suporte de carga total | AWS DMS Suporte CDC | | --- | --- | --- | | Aurora PostgreSQL versão 2.1 compatível com o PostgreSQL 10.5 (ou inferior) | Sim | Não | | Compatibilidade do Aurora PostgreSQL versão 2.2 com o PostgreSQL 10.6 (ou superior) | Sim | Sim | | Compatibilidade do RDS para PostgreSQL com o PostgreSQL 10.21 (ou superior) | Sim | Sim | **Como ativar a replicação lógica para uma instância de banco de dados RDS PostgreSQL** 1. Use a conta de usuário AWS principal para a instância de banco de dados PostgreSQL como a conta de usuário para o endpoint de origem do PostgreSQL. A conta de usuário mestra tem as funções necessárias para permitir a configuração da captura de dados de alteração (CDC). Se você utilizar uma conta diferente da conta de usuário mestre, deverá criar vários objetos da conta mestre para a conta utilizada. Para obter mais informações, consulte [Migrar um banco de dados Amazon RDS para PostgreSQL sem utilizar a conta de usuário mestre](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser). 1. Defina o parâmetro `rds.logical_replication` no grupo de parâmetros do CLUSTER do banco de dados como 1. Esse parâmetro estático requer uma reinicialização da instância de banco de dados para entrar em vigor. Como parte da aplicação desse parâmetro, o AWS DMS define os parâmetros `wal_level`, `max_wal_senders`, `max_replication_slots` e `max_connections`. Essas alterações de parâmetros podem aumentar o log de gravação antecipada (WAL), portanto, só defina `rds.logical_replication` ao utilizar slots de replicação lógica. 1. O parâmetro `wal_sender_timeout` encerra as conexões de replicação que estão inativas por mais tempo do que o número de milissegundos especificado. O padrão para um banco AWS de dados PostgreSQL gerenciado é 30.000 milissegundos (30 segundos). A definição do valor como 0 (zero) desativa o mecanismo de tempo limite e é uma configuração válida para o DMS. Ao definir `wal_sender_timeout` como um valor diferente de zero, uma tarefa do DMS com CDC requer um mínimo de 10000 milissegundos (10 segundos) e falhará se o valor estiver entre 0 e 10000. Mantenha o valor em menos de 5 minutos para evitar provocar um atraso durante um failover de multi-AZ de uma instância de replicação do DMS. 1. Verifique se o valor do parâmetro `max_worker_processes` no grupo de parâmetros do cluster do banco de dados é igual ou superior aos valores totais combinados de `max_logical_replication_workers``autovacuum_max_workers` e `max_parallel_workers`. Um alto número de processos de trabalho em segundo plano pode impactar as workloads das aplicações em instâncias pequenas. Portanto, monitore o desempenho do banco de dados se você definir um valor de `max_worker_processes` mais alto que o padrão. 1. Ao usar o Aurora PostgreSQL como origem com CDC, defina `synchronous_commit` como `ON`. **Como utilizar a réplica de leitura do cluster de banco de dados multi-AZ do PostgreSQL para CDC (replicação contínua)** 1. Defina os parâmetros `rds.logical_replication` e `sync_replication_slots` no grupo de parâmetros do CLUSTER de banco de dados como 1. Esses parâmetros estáticos requerem a reinicialização da instância de banco de dados para entrar em vigor. 1. Execute o seguinte comando para criar a tabela `awsdms_ddl_audit` no Gravador e substituir o `objects_schema` pelo nome do esquema a ser utilizado: ``` CREATE TABLE objects_schema.awsdms_ddl_audit ( c_key bigserial primary key, c_time timestamp, -- Informational c_user varchar(64), -- Informational: current_user c_txn varchar(16), -- Informational: current transaction c_tag varchar(24), -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE' c_oid integer, -- For future use - TG_OBJECTID c_name varchar(64), -- For future use - TG_OBJECTNAME c_schema varchar(64), -- For future use - TG_SCHEMANAME. For now - holds current_schema c_ddlqry text -- The DDL query associated with the current DDL event ); ``` 1. Execute o seguinte comando para criar uma função `awsdms_intercept_ddl` e substituir o `objects_schema` pelo nome do esquema a ser utilizado: ``` CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl() RETURNS event_trigger LANGUAGE plpgsql SECURITY DEFINER AS $$ declare _qry text; BEGIN if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then SELECT current_query() into _qry; insert into objects_schema.awsdms_ddl_audit values ( default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry ); delete from objects_schema.awsdms_ddl_audit; end if; END; $$; ``` 1. Execute o seguinte comando para criar o gatilho de eventos `awsdms_intercept_ddl`: ``` CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl(); ``` Verifique se todos os usuários e perfis que acessam esses eventos têm as permissões de DDL necessárias. Por exemplo: ``` grant all on public.awsdms_ddl_audit to public; grant all on public.awsdms_ddl_audit_c_key_seq to public; ``` 1. Crie um slot de replicação no Gravador: ``` SELECT * FROM pg_create_logical_replication_slot('dms_read_replica_slot', 'test_decoding', false, true); ``` 1. Verifique se o slot de replicação está disponível no Leitor: ``` select * from pg_catalog.pg_replication_slots where slot_name = 'dms_read_replica_slot'; slot_name |plugin |slot_type|datoid|database|temporary|active|active_pid|xmin|catalog_xmin|restart_lsn|confirmed_flush_lsn|wal_status|safe_wal_size|two_phase|inactive_since |conflicting|invalidation_reason|failover|synced| ---------------------+-------------+---------+------+--------+---------+------+----------+----+------------+-----------+-------------------+----------+-------------+---------+-----------------------------+-----------+-------------------+--------+------+ dms_read_replica_slot|test_decoding|logical | 5|postgres|false |false | | |3559 |0/180011B8 |0/180011F0 |reserved | |true |2025-02-10 15:45:04.083 +0100|false | |false |false | ``` 1. Crie um endpoint de origem do DMS para a réplica de leitura e defina o nome do slot de replicação lógica por meio do atributo de conexão adicional: ``` slotName=dms_read_replica_slot; ``` 1. Crie e inicie a tarefa CDC/FL\$1CDC. **nota** Para migrações CDC/FL\$1CDC, o DMS considera o horário de início da tarefa como uma posição inicial da CDC. Todos os mais antigos LSNs do slot de replicação são ignorados. ### Migrar um banco de dados Amazon RDS para PostgreSQL sem utilizar a conta de usuário mestre Em alguns casos, é possível não utilizar a conta de usuário mestre para a instância de banco de dados Amazon RDS PostgreSQL que você está utilizando como origem. Nesses casos, crie vários objetos para capturar os eventos da linguagem de definição de dados (DDL). Crie esses objetos utilizando uma conta diferente da conta mestrr e, depois, crie um acionador na conta de usuário mestre. **nota** Se você definir a configuração do endpoint `CaptureDdls` como `false` no endpoint de origem, não precisará criar a tabela e o acionador a seguir no banco de dados de origem. Utilize o procedimento a seguir para criar esses objetos. **Como criar objetos** 1. Escolha um esquema onde os objetos serão criados. O esquema padrão é `public`. Verifique se o esquema existe e pode ser acessado pela conta `OtherThanMaster`. 1. Faça login na instância de banco de dados PostgreSQL utilizando uma conta de usuário diferente da conta mestre, aqui a conta `OtherThanMaster`. 1. Crie a tabela `awsdms_ddl_audit` executando o comando a seguir, substituindo `objects_schema` no código seguinte pelo nome do esquema a ser utilizado. ``` CREATE TABLE objects_schema.awsdms_ddl_audit ( c_key bigserial primary key, c_time timestamp, -- Informational c_user varchar(64), -- Informational: current_user c_txn varchar(16), -- Informational: current transaction c_tag varchar(24), -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE' c_oid integer, -- For future use - TG_OBJECTID c_name varchar(64), -- For future use - TG_OBJECTNAME c_schema varchar(64), -- For future use - TG_SCHEMANAME. For now - holds current_schema c_ddlqry text -- The DDL query associated with the current DDL event ); ``` 1. Crie o perfil `awsdms_intercept_ddl` executando o comando a seguir, substituindo `objects_schema` no código seguinte pelo nome do esquema a ser utilizado. ``` CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl() RETURNS event_trigger LANGUAGE plpgsql SECURITY DEFINER AS $$ declare _qry text; BEGIN if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then SELECT current_query() into _qry; insert into objects_schema.awsdms_ddl_audit values ( default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry ); delete from objects_schema.awsdms_ddl_audit; end if; END; $$; ``` 1. Faça logout da conta `OtherThanMaster` e faça login com uma conta que tenha o perfil `rds_superuser` atribuído. 1. Crie o trigger de evento `awsdms_intercept_ddl` executando o comando a seguir. ``` CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl(); ``` 1. Verifique se todos os usuários e perfis que acessam esses eventos têm as permissões de DDL necessárias. Por exemplo: ``` grant all on public.awsdms_ddl_audit to public; grant all on public.awsdms_ddl_audit_c_key_seq to public; ``` Ao concluir o procedimento anterior, você poderá criar o endpoint de origem do AWS DMS utilizando a conta `OtherThanMaster`. **nota** Esses eventos são acionados pelas instruções `CREATE TABLE`, `ALTER TABLE` e `DROP TABLE`. ## Ativar a captura de dados de alteração (CDC) utilizando replicação lógica É possível utilizar o recurso de replicação lógica nativa do PostgreSQL para ativar a captura de dados de alteração (CDC) durante a migração do banco de dados de origens do PostgreSQL. É possível utilizar esse recurso com o PostgreSQL autogerenciado e também com uma instância do banco de dados Amazon RDS para PostgreSQL. Essa abordagem reduz o tempo de inatividade e ajuda a garantir que o banco de dados de destino esteja sincronizado com o banco de dados PostgreSQL de origem. AWS DMS suporta CDC para tabelas PostgreSQL com chaves primárias. Se uma tabela não tiver uma chave primária, os logs de gravação antecipada (WAL) não incluirão uma imagem anterior da linha do banco de dados. Nesse caso, o DMS não pode atualizar a tabela. Aqui, é possível utilizar configurações adicionais e utilizar a identidade da réplica da tabela como uma solução alternativa. No entanto, essa abordagem pode gerar logs adicionais. É recomendável utilizar a identidade da réplica da tabela como solução alternativa somente após testes cuidadosos. Para obter mais informações, consulte [Definições de configuração adicionais ao utilizar um banco de dados PostgreSQL como origem do DMS](#CHAP_Source.PostgreSQL.Advanced). **nota** A REPLICA IDENTITY FULL é compatível com um plug-in de decodificação lógica, mas não com um plug-in pglogical. Para obter mais informações, consulte a [Documentação do pglogical](https://github.com/2ndQuadrant/pglogical#primary-key-or-replica-identity-required). Para tarefas de carga total e somente CDC e CDC, AWS DMS usa slots de replicação lógica para reter os registros do WAL para replicação até que os registros sejam decodificados. Ao reiniciar (não ao retomar) para uma carga máxima e uma tarefa de CDC ou uma tarefa de somente de CDC, o slot de replicação é recriado. **nota** Para decodificação lógica, o DMS utiliza o plug-in test\$1decoding ou pglogical. Se o plug-in pglogical estiver disponível em um banco de dados PostgreSQL de origem, o DMS criará um slot de replicação utilizando pglogical, caso contrário, um plug-in test\$1decoding será utilizado. Para obter mais informações sobre o plug-in test\$1decoding, consulte a [Documentação do PostgreSQL](https://www.postgresql.org/docs/9.4/test-decoding.html). Se o parâmetro `max_slot_wal_keep_size` do banco de dados for definido como um valor não padrão e o `restart_lsn` de um slot de replicação ficar atrás do LSN atual em mais do que esse tamanho, a tarefa do DMS falhará devido à remoção dos arquivos WAL necessários. ### Configurar o plug-in pglogical Implementado como uma extensão do PostgreSQL, o plug-in pglogical é um sistema de replicação lógica e um modelo para replicação seletiva de dados. A tabela a seguir identifica as versões de origem do banco de dados PostgreSQL que são compatíveis com o plug-in pglogical. | Origem PostgreSQL | Compatível com o pglogical | | --- | --- | | PostgreSQL 9.4 autogerenciado ou superior | Sim | | Amazon RDS PostgreSQL 9.5 ou inferior | Não | | Amazon RDS PostgreSQL 9.6 ou superior | Sim | | Aurora PostgreSQL 1.x até 2.5.x | Não | | Aurora PostgreSQL 2.6.x ou superior | Sim | | Aurora PostgreSQL 3.3.x ou superior | Sim | Antes de configurar o pglogical para uso com AWS DMS, primeiro habilite a replicação lógica para captura de dados de alteração (CDC) em seu banco de dados de origem do PostgreSQL. + Para obter informações sobre como ativar a replicação lógica para CDC em bancos de dados de origem PostgreSQL *autogerenciados*, consulte [Habilitando o CDC usando um banco de dados PostgreSQL autogerenciado como fonte AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites.CDC) + Para obter informações sobre como ativar a replicação lógica para CDC em bancos de dados de origem PostgreSQL *gerenciado pela AWS*, consulte [Habilitando o CDC com uma instância de banco AWS de dados PostgreSQL gerenciada com AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC). Depois que a replicação lógica estiver ativada no banco de dados de origem PostgreSQL, utilize as etapas a seguir para configurar o pglogical para utilização com o DMS. **Para usar o plug-in pglogical para replicação lógica em um banco de dados de origem PostgreSQL com AWS DMS** 1. Crie uma extensão de pglogical no banco de dados de origem PostgreSQL: 1. Defina o parâmetro correto: + Para bancos de dados PostgreSQL autogerenciados, defina o parâmetro `shared_preload_libraries= 'pglogical'` do banco de dados. + Para o PostgreSQL nos bancos de dados Amazon RDS e Amazon Aurora edição compatível com o PostgreSQL, defina o parâmetro `shared_preload_libraries` como `pglogical` no mesmo grupo de parâmetros do RDS. 1. Reinicie o banco de dados de origem PostgreSQL. 1. No banco de dados PostgreSQL, execute o comando `create extension pglogical;`. 1. Execute o comando a seguir para verificar se a instalação do pglogical foi bem-sucedida: `select * FROM pg_catalog.pg_extension` Agora você pode criar uma AWS DMS tarefa que realiza a captura de dados de alteração para o endpoint do banco de dados de origem do PostgreSQL. **nota** Se você não ativar o pglogical no banco de dados de origem PostgreSQL, o AWS DMS utilizará o plug-in `test_decoding` por padrão. Quando pglogical está habilitado para decodificação lógica, AWS DMS usa pglogical por padrão. Mas é possível definir o atributo de conexão adicional, para que o `PluginName` utilize o plug-in `test_decoding` em vez disso. ## Utilizar pontos de início nativos da CDC para configurar uma carga de CDC de uma origem PostgreSQL Para ativar os pontos de início nativos da CDC com o PostgreSQL como origem, defina o atributo de conexão adicional `slotName` como o nome de um slot de replicação lógica existente ao criar o endpoint. Esse slot de replicação lógica mantém as alterações contínuas desde a hora da criação do endpoint, portanto, ele é compatível com a replicação de um ponto no tempo. O PostgreSQL grava as alterações do banco de dados em arquivos WAL que são descartados somente depois que o AWS DMS faz a leitura das alterações do slot de replicação lógica com êxito. O uso de slots de replicação lógica pode impedir que as alterações registradas sejam excluídas antes de serem consumidas pelo mecanismo de replicação. No entanto, dependendo da taxa de alteração e consumo, as alterações mantidas em um slot de replicação lógica podem causar a utilização elevado do disco. É recomendável definir alarmes de utilização de espaço na instância de origem PostgreSQL ao utilizar slots de replicação lógica. Para obter mais informações sobre como definir o atributo de conexão adicional `slotName`, consulte [Configurações de endpoint e atributos extras de conexão (ECAs) ao usar o PostgreSQL como fonte de DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib). O procedimento a seguir demonstra essa abordagem com mais detalhes. **Como utilizar um ponto inide início nativo da CDC para configurar uma carga de CDC de um endpoint de origem PostgreSQL** 1. Identifique o slot de replicação lógica utilizado por uma tarefa de replicação anterior (uma tarefa pai) que você queira utilizar como ponto de partida. Consulte a visualização `pg_replication_slots` no banco de dados de origem para se certificar de que esse slot não tenha conexões ativas. Se isso acontecer, resolva-os e feche-os antes de continuar. Para as etapas a seguir, vamos supor que o slot de replicação lógica seja `abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef`. 1. Crie um novo endpoint de origem que inclua a configuração de atributo de conexão adicional a seguir. ``` slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef; ``` 1. Crie uma nova tarefa somente para CDC usando o console AWS CLI ou AWS DMS a API. Por exemplo, utilizando a CLI, é possível executar o seguinte comando `create-replication-task`. ``` aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test --source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 --target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 --replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE --migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" --replication-task-settings "file://task-pg.json" ``` No comando anterior, as seguintes opções são definidas: + A opção `source-endpoint-arn` é definida como o valor criado na etapa 2. + A opção `replication-instance-arn` é definida como o mesmo valor da tarefa pai da etapa 1. + As opções `table-mappings` e `replication-task-settings` são definidas como os mesmos valores da tarefa pai na etapa 1. + A opção `cdc-start-position` é definida como um valor de posição de início. Para localizar essa posição de início, consulte a visualização `pg_replication_slots` no banco de dados de origem ou visualize os detalhes do console da tarefa pai na etapa 1. Para obter mais informações, consulte [Determinar um ponto de início de CDC nativo](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint.Native). Para ativar o modo de início personalizado do CDC ao criar uma nova tarefa somente para CDC usando o AWS DMS console, faça o seguinte: + Na seção **Configurações da tarefa**, em **Modo de início da CDC para transações de origem**, escolha **Ativar o modo de início da CDC personalizado**. + Em **Ponto de início da CDC personalizado para transações de origem**, escolha **Especificar um número de sequência de log**. Especifique o número de alteração do sistema ou escolha **Especificar um ponto de verificação de recuperação** e forneça um ponto de verificação de recuperação. Quando essa tarefa do CDC é AWS DMS executada, gera um erro se o slot de replicação lógica especificado não existir. Ele também gerará um erro se a tarefa não for criada com uma configuração válida para `cdc-start-position`. Ao utilizar pontos de início nativos da CDC com o plug-in pglogical e quiser utilizar um novo slot de replicação, conclua as etapas de configuração a seguir antes de criar uma tarefa de CDC. **Como utilizar um novo slot de replicação não criado anteriormente como parte de outra tarefa do DMS** 1. Crie um slot de replicação, conforme mostrado a seguir: ``` SELECT * FROM pg_create_logical_replication_slot('replication_slot_name', 'pglogical'); ``` 1. Depois que o banco de dados criar o slot de replicação, obtenha e anote os valores de **restart\$1lsn** e de **confirmed\$1flush\$1lsn** do slot: ``` select * from pg_replication_slots where slot_name like 'replication_slot_name'; ``` Observe que a posição de início da CDC nativo para uma tarefa de CDC criada após o slot de replicação não pode ser mais antiga do que o valor de **confirmed\$1flush\$1lsn**. Para obter informações sobre os valores de **restart\$1lsn** e de **confirmed\$1flush\$1lsn**, consulte [pg\$1replication\$1slots](https://www.postgresql.org/docs/14/view-pg-replication-slots.html) 1. Crie um nó pglogical. ``` SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name'); ``` 1. Crie dois conjuntos de replicação utilizando o perfil `pglogical.create_replication_set`. O primeiro conjunto de replicação rastreia as atualizações e as exclusões das tabelas que têm chaves primárias. O segundo conjunto de replicação rastreia somente inserções e tem o mesmo nome do primeiro conjunto de replicação, com o prefixo 'i' adicionado. ``` SELECT pglogical.create_replication_set('replication_slot_name', false, true, true, false); SELECT pglogical.create_replication_set('ireplication_slot_name', true, false, false, true); ``` 1. Adicione uma tabela ao conjunto de réplicas. ``` SELECT pglogical.replication_set_add_table('replication_slot_name', 'schemaname.tablename', true); SELECT pglogical.replication_set_add_table('ireplication_slot_name', 'schemaname.tablename', true); ``` 1. Defina o atributo de conexão adicional (ECA) a seguir ao criar o endpoint de origem. ``` PluginName=PGLOGICAL;slotName=slot_name; ``` Agora é possível criar uma tarefa somente de CDC com um ponto de início nativo do PostgreSQL utilizando o novo slot de replicação. Para obter mais informações sobre o plug-in pglogical, consulte a [Documentação do pglogical 3.7](https://www.enterprisedb.com/docs/pgd/3.7/pglogical/) ## Migrando do PostgreSQL para o PostgreSQL usando AWS DMS Quando você migra de um mecanismo de banco de dados diferente do PostgreSQL para um banco de dados PostgreSQL, é quase sempre a melhor ferramenta AWS DMS de migração a ser usada. No entanto, ao migrar de um banco de dados PostgreSQL para um banco de dados PostgreSQL, as ferramentas do PostgreSQL podem ser mais eficazes. ### Utilize ferramentas nativas do PostgreSQL para migrar dados É recomendável utilizar ferramentas nativas de migração do banco de dados PostgreSQL, como `pg_dump`, nas seguintes condições: + Quando há uma migração homogênea, na qual você migra de um banco de dados PostgreSQL de origem para um banco de dados PostgreSQL de destino. + Quando for migrar um banco de dados inteiro. + As ferramentas nativas permitem que você migre os dados com um tempo mínimo de inatividade. O utilitário pg\$1dump utiliza o comando COPY para criar um esquema e um despejo de dados de um banco de dados PostgreSQL. O script de despejo gerado pelo pg\$1dump carrega os dados em um banco de dados com o mesmo nome e recria as tabelas, os índices e as chaves estrangeiras. Para restaurar os dados para um banco de dados com outro nome, utilize o comando `pg_restore` e o parâmetro `-d`. Se estiver migrando dados de um banco de dados de origem PostgreSQL sendo executado no EC2 para um destino Amazon RDS para PostgreSQL, você poderá utilizar o plug-in pglogical. Para obter mais informações sobre como importar de um banco de dados PostgreSQL para o Amazon RDS para PostgreSQL ou para a edição do Amazon Aurora compatível com PostgreSQL, consulte [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html). ### Utilizar o DMS para migrar dados do PostgreSQL para o PostgreSQL AWS DMS pode migrar dados, por exemplo, de um banco de dados PostgreSQL de origem que está no local para uma instância de destino do Amazon RDS for PostgreSQL ou do Aurora PostgreSQL. Os tipos de dados do PostgreSQL fundamentais ou básicos geralmente migram com êxito. **nota** Ao replicar tabelas particionadas de uma origem PostgreSQL para o destino PostgreSQL, você não precisa mencionar a tabela pai como parte dos critérios de seleção na tarefa do DMS. Mencionar a tabela principal faz com que os dados sejam duplicados nas tabelas filho no destino, possivelmente causando uma violação de PK. Ao selecionar apenas as tabelas filho nos critérios de seleção do mapeamento de tabelas, a tabela pai é preenchida automaticamente. Os tipos de dados compatíveis com o banco de dados de origem, mas que não são compatíveis com o destino, podem não ser migrados com êxito. AWS DMS transmite alguns tipos de dados como cadeias de caracteres se o tipo de dados for desconhecido. Alguns tipos de dados, como XML e JSON, podem ser migrados com êxito como arquivos pequenos, mas podem falhar se forem documentos grandes. Ao executar a migração do tipo de dados, lembre-se de que: + Em alguns casos, o tipo de dados PostgreSQL NUMERIC(p,s) não especifica nenhuma precisão e escala. Nas versões 3.4.2 e anteriores do DMS, o DMS utiliza uma precisão de 28 e uma escala de 6 por padrão, NUMERIC(28,6). Por exemplo, o valor 0,611111104488373 da origem é convertido em 0,611111 no destino do PostgreSQL. + Uma tabela com o tipo de dados ARRAY deve ter uma chave primária. Uma tabela com um tipo de dados ARRAY sem uma chave primária é suspensa durante a carga máxima. A tabela a seguir mostra os tipos de dados do PostgreSQL de origem e se podem ser migrados com êxito. | Tipo de dados | Será migrado com êxito | Migra parcialmente | Não migra | Comentários | | --- | --- | --- | --- | --- | | INTEGER | X | | | | | SMALLINT | X | | | | | BIGINT | X | | | | | NUMERIC/DECIMAL(p,s) | | X | | Em que 038 ou p=s=0 | | REAL | X | | | | | DOUBLE | X | | | | | SMALLSERIAL | X | | | | | SERIAL | X | | | | | BIGSERIAL | X | | | | | MONEY | X | | | | | CHAR | | X | | Sem precisão especificada | | CHAR(n) | X | | | | | VARCHAR | | X | | Sem precisão especificada | | VARCHAR(n) | X | | | | | TEXT | X | | | | | BYTEA | X | | | | | TIMESTAMP | X | | | Os valores infinitos positivos e negativos são truncados para '9999-12-31 23:59:59' e '4713-01-01 00:00:00 BC', respectivamente. | | TIMESTAMP WITH TIME ZONE | | X | | | | DATE | X | | | | | TIME | X | | | | | TIME WITH TIME ZONE | X | | | | | INTERVAL | | X | | | | BOOLEAN | X | | | | | ENUM | | | X | | | CIDR | X | | | | | INET | | | X | | | MACADDR | | | X | | | TSVECTOR | | | X | | | TSQUERY | | | X | | | XML | | X | | | | POINT | X | | | Tipo de dados espaciais do PostGIS | | LINE | | | X | | | LSEG | | | X | | | BOX | | | X | | | PATH | | | X | | | POLYGON | X | | | Tipo de dados espaciais do PostGIS | | CIRCLE | | | X | | | JSON | | X | | | | ARRAY | X | | | Requer chave primária | | COMPOSITE | | | X | | | RANGE | | | X | | | LINESTRING | X | | | Tipo de dados espaciais do PostGIS | | MULTIPOINT | X | | | Tipo de dados espaciais do PostGIS | | MULTILINESTRING | X | | | Tipo de dados espaciais do PostGIS | | MULTIPOLYGON | X | | | Tipo de dados espaciais do PostGIS | | GEOMETRYCOLLECTION | X | | | Tipo de dados espaciais do PostGIS | ### Migrar tipos de dados espaciais do PostGIS *Dados espaciais* identificam a informação de geometria de um objeto ou local no espaço. Os bancos de dados relacionais de objetos PostgreSQL são compatíveis com os tipos de dados espaciais do PostGIS. Antes de migrar objetos de dados espaciais do PostgreSQL, verifique se o plug-in PostGIS está ativado no nível global. Isso garante a AWS DMS criação exata das colunas de dados espaciais de origem para a instância de banco de dados de destino do PostgreSQL. Para AWS DMS migrações homogêneas de PostgreSQL para PostgreSQL, suporta a migração de tipos e subtipos de objetos de dados geométricos e geográficos (coordenadas geodésicas) PostGIS, como os seguintes: + POINT + LINESTRING + POLYGON + MULTIPOINT + MULTILINESTRING + MULTIPOLYGON + GEOMETRYCOLLECTION ## Migração do Babelfish para o Amazon Aurora PostgreSQL usando AWS DMS Você pode migrar as tabelas de origem do PostgreSQL do Babelfish for Aurora para qualquer endpoint de destino compatível usando o. AWS DMS Ao criar seu endpoint de AWS DMS origem usando o console do DMS, a API ou os comandos da CLI, você define a origem como **Amazon Aurora PostgreSQL** e o nome do banco de dados como. **babelfish\$1db** Na seção **Configurações do Endpoint**, verifique se o **DatabaseMode**está definido como **Babelfish** e **BabelfishDatabaseName**está definido como o nome do banco de dados Babelfish T-SQL de origem. Em vez de usar a porta TCP **1433** do Babelfish, use a porta TCP **5432** do Aurora PostgreSQL. Crie as tabelas antes de migrar os dados para garantir que o DMS utilize os tipos de dados e metadados de tabela corretos. Se você não criar as tabelas no destino antes de executar a migração, o DMS poderá criar as tabelas com tipos de dados e permissões incorretos. ### Adicionar regras de transformação à tarefa de migração Ao criar uma tarefa de migração para uma origem do Babelfish, inclua regras de transformação que garantam que o DMS utilize as tabelas de destino pré-criadas. Se você definiu o modo de migração de vários bancos de dados ao definir seu cluster do Babelfish para PostgreSQL, adicione uma regra de transformação que renomeia o nome do esquema para o esquema do T-SQL. Por exemplo, se o nome do esquema do T-SQL for `dbo` e o nome do esquema do Babelfish para PostgreSQL for `mydb_dbo`, renomeie o esquema para `dbo` utilizando uma regra de transformação. Para encontrar o nome do esquema do PostgreSQL, consulte [Arquitetura do Babelfish](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/babelfish-architecture.html) no *Guia do usuário do Amazon Aurora*. Se você utilizar o modo de banco de dados único, não será necessário usar uma regra de transformação para renomear os esquemas de bancos de dados. Os nomes dos esquemas do PostgreSQL têm one-to-one um mapeamento para os nomes dos esquemas no banco de dados T-SQL. O exemplo de regra de transformação a seguir mostra como renomear o nome do esquema de `mydb_dbo` de volta para `dbo`: ``` { "rules": [ { "rule-type": "transformation", "rule-id": "566251737", "rule-name": "566251737", "rule-target": "schema", "object-locator": { "schema-name": "mydb_dbo" }, "rule-action": "rename", "value": "dbo", "old-value": null }, { "rule-type": "selection", "rule-id": "566111704", "rule-name": "566111704", "object-locator": { "schema-name": "mydb_dbo", "table-name": "%" }, "rule-action": "include", "filters": [] } ] } ``` ### Limitações ao utilizar um endpoint de origem do PostgreSQL com tabelas do Babelfish As limitações a seguir se aplicam ao utilizar um endpoint de origem do PostgreSQL com tabelas do Babelfish: + O DMS é compatível somente com a migração do Babelfish versão 16.2/15.6 e posterior e do DMS versão 3.5.3 e posterior. + O DMS não replica as alterações na definição de tabelas do Babelfish para o endpoint de destino. Uma solução alternativa para essa limitação é primeiro aplicar as alterações na definição das tabelas no destino e, em seguida, alterar a definição das tabelas na origem do Babelfish. + Quando você cria tabelas do Babelfish com o tipo de dados BYTEA, o DMS as converte para o tipo de dados `varbinary(max)` ao migrar para o SQL Server como destino. + O DMS não é compatível com o modo LOB completo para tipos de dados binários. Em vez disso, use o modo LOB limitado para tipos de dados binários. + O DMS não é compatível com a validação de dados no Babelfish como origem. + Para a definição da tarefa **Modo de preparação da tabela de destino**, use somente os modos **Não fazer nada** ou **Truncar**. Não utilize o modo **Abandonar tabelas no destino**. Ao utilizar **Abandonar tabelas no destino**, o DMS poderá criar as tabelas com tipos de dados incorretos. + Ao utilizar a replicação contínua (CDC ou carga máxima e CDC), defina o atributo de conexão adicional (ECA) `PluginName` como `TEST_DECODING`. + O DMS não é compatível com replicação (CDC ou carga máxima e CDC) de tabelas particionadas no Babelfish como origem. ## Removendo AWS DMS artefatos de um banco de dados de origem do PostgreSQL Para capturar eventos DDL, AWS DMS cria vários artefatos no banco de dados PostgreSQL quando uma tarefa de migração é iniciada. Quando a tarefa é concluída, é recomendável remover esses artefatos. Para remover os artefatos, execute os comandos a seguir (na ordem em que são exibidos), em que `{AmazonRDSMigration}` é o esquema no qual os artefatos foram criados: O descarte de um esquema deve ser feito com extremo cuidado. Nunca descarte um esquema operacional, especialmente um esquema que seja público. ``` drop event trigger awsdms_intercept_ddl; ``` O gatilho de eventos não pertence a um esquema específico. ``` drop function {AmazonRDSMigration}.awsdms_intercept_ddl() drop table {AmazonRDSMigration}.awsdms_ddl_audit drop schema {AmazonRDSMigration} ``` ## Definições de configuração adicionais ao utilizar um banco de dados PostgreSQL como origem do DMS É possível adicionar definições de configuração ao migrar dados de um banco de dados PostgreSQL de duas maneiras: + É possível adicionar valores ao atributo de conexão adicional para capturar eventos de DDL e especificar o esquema no qual os artefatos de banco de dados DDL operacionais são criados. Para obter mais informações, consulte [Configurações de endpoint e atributos extras de conexão (ECAs) ao usar o PostgreSQL como fonte de DMS](#CHAP_Source.PostgreSQL.ConnectionAttrib). + É possível substituir os parâmetros da string de conexão. Escolha esta opção para realizar uma das seguintes ações: + Especifique AWS DMS os parâmetros internos. Esses parâmetros são raramente necessários e, portanto, não são expostos na interface do usuário. + Especifique valores de passagem (passthru) para o cliente de banco de dados específico. AWS DMS inclui parâmetros de passagem na cadeia de conexão passada para o cliente do banco de dados. + Ao usar o parâmetro em nível de tabela nas versões 9.4 e posteriores `REPLICA IDENTITY` do PostgreSQL, você pode controlar as informações gravadas em registros de gravação antecipada (). WALs Em particular, ele faz isso para identificar linhas WALs que são atualizadas ou excluídas. `REPLICA IDENTITY FULL`registra os valores antigos de todas as colunas na linha. Use `REPLICA IDENTITY FULL` com cuidado para cada tabela, pois pode `FULL` gerar um número extra WALs que pode não ser necessário. Para obter mais informações, consulte [ALTER TABLE-REPLICA IDENTITY](https://www.postgresql.org/docs/devel/sql-altertable.html) ## Ler a réplica como origem do PostgreSQL Use réplicas de leitura do PostgreSQL como fontes de CDC para reduzir a carga do banco de dados AWS DMS primário. Esse recurso está disponível no PostgreSQL 16.x e AWS DMS requer a versão 3.6.1 ou posterior. O uso de réplicas de leitura para processamento de CDC reduz o impacto operacional em seu banco de dados primário. **nota** A versão 16.x do Amazon RDS para PostgreSQL tem limitações quanto à replicação lógica de réplicas de leitura nas configurações three-AZ (TAZ). Para obter suporte completo à replicação lógica de réplicas de leitura em implantações TAZ, você deve usar o PostgreSQL versão 17.x ou posterior. ### Pré-requisitos Antes de usar uma réplica de leitura como fonte de CDC para AWS DMS, você deve habilitar a replicação lógica na instância primária do banco de dados e em sua réplica de leitura para criar decodificação lógica em uma réplica de leitura. Execute as seguintes ações: + Habilite a replicação lógica na instância de banco de dados primário e em sua réplica de leitura com quaisquer outros parâmetros de banco de dados necessários. Para obter mais informações, consulte [Trabalhando com bancos AWS de dados PostgreSQL gerenciados como fonte de DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.RDSPostgreSQL). + Para tarefas somente de CDC, crie um slot de replicação na instância primária (gravadora). Para ter mais informações, consulte [Utilizar pontos de início nativos da CDC para configurar uma carga de CDC de uma origem PostgreSQL](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10). Essa ação é necessária, pois não é possível criar um slot de replicação em réplicas de leitura. + Para o PostgreSQL versão 16, o slot deve ser criado manualmente na réplica de leitura. + Para o PostgreSQL versão 17 e posterior, o slot de replicação deve ser criado no primário e sincronizado automaticamente com a réplica de leitura. + Ao usar Full Load \$1 CDC ou tarefas somente CDC, AWS DMS pode gerenciar automaticamente os slots de replicação lógica nas instâncias primárias, mas não nas réplicas de leitura. Em relação a réplicas de leitura do PostgreSQL versão 16, elimine e recrie manualmente os slots de replicação antes de reiniciar uma tarefa (não a retomar). Ignorar essa etapa pode causar falhas na tarefa ou posições de início de CDC incorretas. A partir da versão 17 do PostgreSQL, a sincronização lógica de slots da instância primária automatiza esse processo. Depois de concluir os pré-requisitos, você pode configurar seu endpoint de origem com a replicação `SlotName` da AWS DMS fonte da réplica de leitura nas configurações do endpoint e configurar sua AWS DMS tarefa usando pontos iniciais nativos do CDC. Para obter mais informações, consulte [Configurações de endpoint e atributos extras de conexão (ECAs) ao usar o PostgreSQL como fonte de DMS [e Usar pontos de partida nativos do CDC para configurar uma carga CDC de uma](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) fonte do PostgreSQL](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.ConnectionAttrib). ## Utilizar a configuração de endpoint `MapBooleanAsBoolean` do PostgreSQL É possível utilizar as configurações de endpoint do PostgreSQL para mapear um booleano como um booleano da origem PostgreSQL para um destino Amazon Redshift. Por padrão, um tipo BOOLEAN é migrado como varchar(5). É possível especificar `MapBooleanAsBoolean` para permitir que o PostgreSQL migre o tipo booleano como booleano, conforme mostrado no exemplo a seguir. ``` --postgre-sql-settings '{"MapBooleanAsBoolean": true}' ``` Observe que você deve definir essa configuração nos endpoints de origem e de destino para que ela tenha efeito. Como o MySQL não tem um tipo BOOLEAN, utilize uma regra de transformação em vez dessa configuração ao migrar dados BOOLEAN para o MySQL. ## Configurações de endpoint e atributos extras de conexão (ECAs) ao usar o PostgreSQL como fonte de DMS Você pode usar configurações de endpoint e atributos extras de conexão (ECAs) para configurar seu banco de dados de origem do PostgreSQL. Você especifica as configurações do endpoint ao criar o endpoint de origem usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--postgre-sql-settings '{"EndpointSetting": "value", ...}'` JSON. A tabela a seguir mostra as configurações do endpoint e ECAs que você pode usar com o PostgreSQL como fonte. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.PostgreSQL.html) ## Limitações ao utilizar um banco de dados PostgreSQL como origem do DMS As limitações a seguir se aplicam à utilização do PostgreSQL como uma origem do AWS DMS: + AWS DMS não funciona com o Amazon RDS for PostgreSQL 10.4 ou o Amazon Aurora PostgreSQL 10.4 como origem ou destino. + Uma tabela capturada deve ter uma chave primária. Se uma tabela não tiver uma chave primária, AWS DMS ignorará as operações de registro DELETE e UPDATE dessa tabela. Como solução alternativa, consulte [Ativar a captura de dados de alteração (CDC) utilizando a replicação lógica](#CHAP_Source.PostgreSQL.Security). **Observação:** não recomendamos migrar sem um Key/Unique índice primário, caso contrário, limitações adicionais se aplicam, como a capacidade de aplicação em lote “NÃO”, a capacidade de LOB completa, a validação de dados e a incapacidade de replicar para o destino do Redshift de forma eficiente. + AWS DMS ignora uma tentativa de atualizar um segmento de chave primária. Nesses casos, o destino identifica a atualização como uma que não atualizou nenhuma linha. No entanto, como os resultados da atualização de uma chave primária no PostgreSQL são imprevisíveis, nenhum registro é gravado na tabela de exceções. + AWS DMS não suporta a opção **Iniciar alterações do processo a partir da execução do carimbo de data/hora**. + AWS DMS não replica as alterações resultantes de operações de partição ou subpartição (`ADD``DROP`, ou`TRUNCATE`). + A replicação de várias tabelas com o mesmo nome em que cada nome tem um caso diferente (por exemplo, tabela1 e Tabela1) pode TABLE1 causar um comportamento imprevisível. Devido a esse problema, AWS DMS não oferece suporte a esse tipo de replicação. + Na maioria dos casos, AWS DMS oferece suporte ao processamento de alterações das instruções DDL CREATE, ALTER e DROP para tabelas. AWS DMS não suporta esse processamento de alterações se as tabelas forem mantidas em um bloco interno de corpo de função ou procedimento ou em outras construções aninhadas. Por exemplo, a seguinte alteração não é capturada. ``` CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void LANGUAGE plpgsql AS $$ BEGIN create table attu.distributors1(did serial PRIMARY KEY,name varchar(40) NOT NULL); END; $$; ``` + Atualmente, os tipos de dados `boolean` em uma origem do PostgreSQL são migrados para um destino do SQL Server como o tipo de dados `bit` com valores inconsistentes. Como solução alternativa, pré-crie a tabela com um tipo de `VARCHAR(1)` dados para a coluna (ou AWS DMS crie a tabela). Depois, deixe o processamento downstream tratar um "F" como Falso e um "T" como Verdadeiro. + AWS DMS não suporta o processamento de alterações das operações TRUNCATE. + O tipo de dados OID LOB não é migrado para o destino. + AWS DMS suporta o tipo de dados PostGIS somente para migrações homogêneas. + Se a origem for um banco de dados PostgreSQL on-premises ou em uma instância do Amazon EC2, verifique se o plug-in de saída test\$1decoding está instalado no endpoint de origem. É possível encontrar esse plug-in no pacote contrib do PostgreSQL. Para obter mais informações sobre o plug-in de teste de decodificação, consulte a [documentação do PostgreSQL](https://www.postgresql.org/docs/10/static/test-decoding.html). + AWS DMS não oferece suporte ao processamento de alterações para definir e cancelar a definição dos valores padrão da coluna (usando a cláusula ALTER COLUMN SET DEFAULT nas instruções ALTER TABLE). + AWS DMS não oferece suporte ao processamento de alterações para definir a nulidade da coluna (usando a cláusula ALTER COLUMN [SET\$1DROP] NOT NULL nas instruções ALTER TABLE). + Quando a replicação lógica está ativada, o número máximo de alterações mantidas na memória por transação é de 4 MB. Depois disso, as alterações são transferidas para o disco. Como resultado, `ReplicationSlotDiskUsage` aumenta e `restart_lsn` não avança até que a transação seja concluída ou interrompida e a reversão seja concluída. Como é uma transação longa, ela pode demorar muito tempo para reverter. Portanto, evite transações de longa execução ou várias subtransações quando a replicação lógica estiver habilitada. Em vez disso, divida a transação em várias transações menores. Nas versões 13 e posteriores do Aurora PostgreSQL, você pode ajustar o parâmetro `logical_decoding_work_mem` para controlar quando o DMS despeja dados de alteração para o disco. Para obter mais informações, consulte [Arquivos de despejo no Aurora PostgreSQL](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill). + Uma tabela com o tipo de dados ARRAY deve ter uma chave primária. Uma tabela com um tipo de dados ARRAY sem uma chave primária é suspensa durante a carga máxima. + AWS DMS [não oferece suporte à migração de metadados de tabela relacionados ao particionamento ou herança de tabelas.](https://www.postgresql.org/docs/15/ddl-inherit.html) Ao AWS DMS encontrar uma tabela particionada ou uma tabela que usa herança, o seguinte comportamento é observado: + AWS DMS identifica e relata as tabelas principal e secundária envolvidas no particionamento ou na herança no banco de dados de origem. + **Criação de tabela no destino**: no banco de dados de destino, AWS DMS cria a tabela como uma tabela padrão (não particionada, não herdada), preservando a estrutura e as propriedades da (s) tabela (s) selecionada (s), mas não a lógica de particionamento ou herança. + **Diferenciação de registros em tabelas herdadas**: para tabelas que usam herança, AWS DMS não distingue registros pertencentes a tabelas secundárias ao preencher a tabela principal. Por isso, ele não utiliza consultas SQL com sintaxe, como `SELECT * FROM ONLY parent_table_name`. + Para replicar tabelas particionadas de uma origem PostgreSQL para um destino PostgreSQL, primeiro crie manualmente as tabelas pai e filho no destino. Defina uma tarefa separada a fim de replicar nessas tabelas. Nesse caso, defina a configuração da tarefa como **Truncar antes de carregar**. + O tipo de dados `NUMERIC` do PostgreSQL não tem um tamanho fixo. Na transferência de dados do tipo `NUMERIC` sem precisão e escala, o DMS utiliza `NUMERIC(28,6)` (uma precisão de 28 e escala 6) por padrão. Por exemplo, o valor 0,611111104488373 da origem é convertido em 0,611111 no destino do PostgreSQL. + AWS DMS oferece suporte ao Aurora PostgreSQL Serverless V1 como fonte somente para tarefas de carga total. AWS DMS oferece suporte ao Aurora PostgreSQL Serverless V2 como fonte para carga total, carga total e tarefas CDC e somente CDC. + AWS DMS não suporta a replicação de uma tabela com um índice exclusivo criado com uma função de coalescência. + Se a definição da chave primária na origem e no destino não corresponder, os resultados da replicação poderão ser imprevisíveis. + Ao utilizar o recurso Carga paralela, a segmentação de tabelas de acordo com partições ou subpartições não é compatível. Para obter mais informações sobre Carga paralela, consulte [Utilizar carga paralela para tabelas, visualizações e coleções selecionadas](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad). + AWS DMS não oferece suporte a restrições diferidas. + AWS DMS a versão 3.4.7 suporta o PostgreSQL 14.x como fonte com estas limitações: + AWS DMS não suporta o processamento de alterações de confirmações em duas fases. + AWS DMS não oferece suporte à replicação lógica para transmitir transações longas em andamento. + AWS DMS não oferece suporte ao CDC para Amazon RDS Proxy for PostgreSQL como fonte. + Ao utilizar [filtros de origem](CHAP_Tasks.CustomizingTasks.Filters.md) que não contêm uma coluna de chave primária, as operações `DELETE` não serão capturadas. + Se o banco de dados de origem também for um destino para outro sistema de replicação de terceiros, as alterações de DDL podem não ser migradas durante a CDC. Porque essa situação pode impedir que o acionador de eventos `awsdms_intercept_ddl` seja acionado. Para contornar a situação, modifique esse acionador no banco de dados de origem da seguinte maneira: ``` alter event trigger awsdms_intercept_ddl enable always; ``` + AWS DMS não suporta a replicação de alterações feitas nas definições de chave primária no banco de dados de origem. Se a estrutura da chave primária for alterada durante uma tarefa de replicação ativa, as alterações subsequentes nas tabelas afetadas não serão replicadas para o destino. + Na replicação de DDL como parte de um script, o número total máximo de comandos de DDL por script é 8.192 e o número total máximo de linhas por script é 8.192 linhas. + AWS DMS não oferece suporte a visualizações materializadas. + Para tarefas de carga total e CDC usando uma réplica de leitura como origem, AWS DMS não é possível criar slots de replicação em réplicas de leitura. ## Tipos de dados de origem para o PostgreSQL A tabela a seguir mostra os tipos de dados de origem do PostgreSQL que são compatíveis com o AWS DMS uso e o mapeamento AWS DMS padrão para os tipos de dados. 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, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de dados do PostgreSQL | Tipos de dados do DMS | | --- | --- | | INTEGER | INT4 | | SMALLINT | INT2 | | BIGINT | INT8 | | NUMERIC (p,s) | Se a precisão estiver entre 0 e 38, use NUMERIC. Se a precisão for maior ou igual a 39, use STRING. | | DECIMAL(P,S) | Se a precisão estiver entre 0 e 38, use NUMERIC. Se a precisão for maior ou igual a 39, use STRING. | | REAL | REAL4 | | DOUBLE | REAL8 | | SMALLSERIAL | INT2 | | SERIAL | INT4 | | BIGSERIAL | INT8 | | MONEY | NUMERIC(38,4) O tipo de dados MONEY é mapeado para FLOAT no SQL Server. | | CHAR | WSTRING (1) | | CHAR(N) | WSTRING (n) | | VARCHAR(N) | WSTRING (n) | | TEXT | NCLOB | | CITEXT | NCLOB | | BYTEA | BLOB | | TIMESTAMP | DATETIME | | TIMESTAMP WITH TIME ZONE | DATETIME | | DATE | DATE | | TIME | TIME | | TIME WITH TIME ZONE | TIME | | INTERVAL | STRING (128)—1 YEAR, 2 MONTHS, 3 DAYS, 4 HOURS, 5 MINUTES, 6 SECONDS | | BOOLEAN | CHAR (5) falso ou verdadeiro | | ENUM | STRING (64) | | CIDR | STRING (50) | | INET | STRING (50) | | MACADDR | STRING (18) | | BIT (n) | STRING (n) | | BIT VARYING (n) | STRING (n) | | UUID | STRING | | TSVECTOR | CLOB | | TSQUERY | CLOB | | XML | CLOB | | POINT | STRING (255) "(x,y)" | | LINE | STRING (255) "(x,y,z)" | | LSEG | STRING (255) "((x1,y1),(x2,y2))" | | BOX | STRING (255) "((x1,y1),(x2,y2))" | | PATH | CLOB "((x1,y1),(xn,yn))" | | POLYGON | CLOB "((x1,y1),(xn,yn))" | | CIRCLE | STRING (255) "(x,y),r" | | JSON | NCLOB | | JSONB | NCLOB | | ARRAY | NCLOB | | COMPOSITE | NCLOB | | HSTORE | NCLOB | | INT4ALCANCE | STRING (255) | | INT8ALCANCE | STRING (255) | | NUMRANGE | STRING (255) | | STRRANGE | STRING (255) | ### Como trabalhar com tipos de dados de origem LOB para PostgreSQL Os tamanhos de colunas do PostgreSQL afetam a conversão de tipos de dados LOB do PostgreSQL em tipos de dados do AWS DMS . Para trabalhar com isso, siga estas etapas para os seguintes tipos de dados do AWS DMS : + BLOB: defina **Limitar tamanho de LOB em** o valor de **Tamanho máximo de LOB (KB)** na criação da tarefa. + CLOB — A replicação trata cada personagem como um UTF8 personagem. Portanto, localize o tamanho do texto de caracteres mais longo na coluna, mostrado aqui como `max_num_chars_text`. Utilize esse tamanho para especificar o valor de **Limitar o tamanho do LOB em**. Se os dados incluírem caracteres de 4 bytes, multiplique por 2 para especificar o valor de ** Limitar o valor de LOB em**, que é em bytes. Nesse caso, **Limitar o tamanho de LOB para** será igual a `max_num_chars_text` multiplicado por 2. + NCLOB: a replicação trata cada caractere como um caractere de byte duplo. Portanto, localize o tamanho do texto de caracteres mais longo na coluna (`max_num_chars_text`) e multiplique por 2. Faça isso para especificar o valor de **Limitar o tamanho do LOB em**. Nesse caso, **Limitar o tamanho de LOB para** será igual a `max_num_chars_text` multiplicado por 2. Se os dados incluírem caracteres de 4 bytes, multiplique por 2 novamente. Nesse caso,** Limitar o tamanho de LOB para** será igual a `max_num_chars_text` multiplicado por 4. # Usando um banco de dados compatível com MySQL como fonte para AWS DMS Você pode migrar dados de qualquer banco de dados compatível com MySQL (MySQL, MariaDB ou Amazon Aurora MySQL) usando o Database Migration Service. AWS Para obter informações sobre as versões do MySQL que oferecem AWS DMS suporte como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) Você pode usar o SSL para criptografar conexões entre o endpoint compatível com MySQL e a instância de replicação. Para obter mais informações sobre o uso do SSL com um endpoint compatível com MySQL, consulte [Usando SSL com AWS Database Migration Service](CHAP_Security.SSL.md). Nas seções a seguir, o termo "autogerenciado" se aplica a qualquer banco de dados instalado on-premises ou no Amazon EC2. O termo "gerenciado pela AWS" se aplica a qualquer banco de dados no Amazon RDS, no Amazon Aurora, ou no Amazon S3. Para obter detalhes adicionais sobre como trabalhar com bancos de dados compatíveis com MySQL AWS DMS, consulte as seções a seguir. **Topics** + [Migrando do MySQL para o MySQL usando AWS DMS](#CHAP_Source.MySQL.Homogeneous) + [Usando qualquer banco de dados compatível com MySQL como fonte para AWS DMS](#CHAP_Source.MySQL.Prerequisites) + [Usando um banco de dados autogerenciado compatível com MySQL como fonte para AWS DMS](#CHAP_Source.MySQL.CustomerManaged) + [Usando um banco AWS de dados compatível com MySQL gerenciado como fonte para AWS DMS](#CHAP_Source.MySQL.AmazonManaged) + [Limitações no uso de um banco de dados MySQL como fonte para AWS DMS](#CHAP_Source.MySQL.Limitations) + [Compatibilidade com transações XA](#CHAP_Source.MySQL.XA) + [Configurações de endpoint ao usar o MySQL como fonte para AWS DMS](#CHAP_Source.MySQL.ConnectionAttrib) + [Tipos de dados de origem do MySQL](#CHAP_Source.MySQL.DataTypes) **nota** Ao configurar as regras de mapeamento AWS Database Migration Service (AWS DMS), é importante evitar o uso de curingas (%) para nomes de bancos de dados ou esquemas. Em vez disso, você deve especificar explicitamente somente os bancos de dados criados pelo usuário que precisam ser migrados. O uso de um caractere curinga inclui todos os bancos de dados no processo de migração, inclusive bancos dados do sistema que não são necessários na instância de destino. Como o usuário principal do Amazon RDS para MySQL não tem as permissões necessárias para importar dados para os bancos de dados do sistema de destino, a tentativa de migrar esses bancos de dados do sistema falha. ## Migrando do MySQL para o MySQL usando AWS DMS Para uma migração heterogênea, em que você está migrando de um mecanismo de banco de dados diferente do MySQL para um banco de dados MySQL AWS DMS , é quase sempre a melhor ferramenta de migração a ser usada. Mas para uma migração homogênea, na qual você está migrando de um banco de dados MySQL para um banco de dados MySQL, é recomendável utilizar um projeto de migração de dados homogênea. As migrações de dados homogêneas utilizam ferramentas de banco de dados nativas para fornecer um desempenho e precisão aprimorados da migração de dados em comparação com o AWS DMS. ## Usando qualquer banco de dados compatível com MySQL como fonte para AWS DMS Antes de começar a trabalhar com um banco de dados MySQL como fonte para AWS DMS, verifique se você tem os seguintes pré-requisitos. Esses pré-requisitos se aplicam a fontes autogerenciadas ou gerenciadas. AWS Você deve ter uma conta para AWS DMS que tenha a função de administrador de replicação. O perfil precisa dos seguintes privilégios: + **REPLICATION CLIENT**: este privilégio é necessário apenas para tarefas de CDC. Em outras palavras, full-load-only as tarefas não exigem esse privilégio. **nota** Para o MariaDB versão 10.5.2\$1, você pode usar o BINLOG MONITOR — ele substitui o REPLICATION CLIENT. + **REPLICATION SLAVE**: este privilégio é necessário apenas para tarefas de CDC. Em outras palavras, full-load-only as tarefas não exigem esse privilégio. + **SUPER**: este privilégio é necessário somente nas versões do MySQL anteriores à versão 5.6.6. O AWS DMS usuário também deve ter privilégios SELECT para as tabelas de origem designadas para replicação. Conceda os seguintes privilégios se você usar avaliações de pré-migração específicas do MySQL: ``` grant select on mysql.user to ; grant select on mysql.db to ; grant select on mysql.tables_priv to ; grant select on mysql.role_edges to #only for MySQL version 8.0.11 and higher grant select on performance_schema.replication_connection_status to ; #Required for primary instance validation - MySQL version 5.7 and higher only ``` Se você estiver usando uma fonte do RDS e planeja executar avaliações de pré-migração específicas do MySQL, adicione a seguinte permissão: ``` grant select on mysql.rds_configuration to ; #Required for binary log retention check ``` Se o parâmetro `BatchEnable` for `true`, será necessário conceder: ``` grant create temporary tables on ``.* to ; ``` ## Usando um banco de dados autogerenciado compatível com MySQL como fonte para AWS DMS É possível utilizar os bancos de dados autogerenciados a seguir, compatíveis com MySQL como origens para o AWS DMS: + MySQL Community Edition + MySQL Standard Edition + MySQL Enterprise Edition + MySQL Cluster Carrier Grade Edition + MariaDB Community Edition + MariaDB Enterprise Edition + MariaDB Column Store Para utilizar a CDC, ative o registro em log binário. Para habilitar o registro binário, os parâmetros a seguir devem ser configurados nos arquivos `my.ini` (Windows) ou `my.cnf` (UNIX) do MySQL. | Parâmetro | Valor | | --- | --- | | `server_id` | Defina este parâmetro com um valor maior ou igual a 1. | | `log-bin` | Defina a rota para o arquivo de log binário, por exemplo `log-bin=E:\MySql_Logs\BinLog`. Não inclua a extensão do arquivo. | | `binlog_format` | Defina este parâmetro como `ROW`. Essa configuração é recomendável durante a replicação porque, em certos casos, quando `binlog_format` está definido como `STATEMENT`, ele pode causar inconsistência ao replicar dados para o destino. O mecanismo de banco de dados também grava dados inconsistentes semelhantes no destino quando `binlog_format` está definido como `MIXED`, porque o mecanismo de banco de dados muda automaticamente para o registro em log baseado em `STATEMENT`, o que pode resultar na gravação de dados inconsistentes no banco de dados de destino. | | `expire_logs_days` | Defina este parâmetro com um valor maior ou igual a 1. Para evitar o uso excessivo de espaço em disco, recomendamos que você não utilize o valor padrão de 0. | | `binlog_checksum` | Defina esse parâmetro como `NONE` para a versão 3.4.7 ou anterior do DMS. | | `binlog_row_image` | Defina este parâmetro como `FULL`. | | `log_slave_updates` | Defina este parâmetro como `TRUE` se você estiver utilizando uma réplica de leitura do MySQL ou MariaDB como origem. | Se você estiver usando uma réplica de leitura do MySQL ou do MariaDB como origem para uma tarefa de migração do DMS usando o modo **Migrar dados existentes e replicar alterações contínuas**, há a possibilidade de perda de dados. O DMS não gravará uma transação durante os modos de carga máxima ou CDC nas seguintes condições: + A transação foi confirmada na instância primária antes do início da tarefa no DMS. + A transação não havia sido confirmada com a réplica até a tarefa do DMS já ter sido iniciada, devido ao atraso entre a instância primária e a réplica. Quanto maior o atraso entre a instância primária e a réplica, maior o potencial de perda de dados. Se sua origem NDB (cluster) utiliza o mecanismo de banco de dados, os parâmetros a seguir precisarão ser configurados para habilitar CDC em tabelas que utilizam esse mecanismo de armazenamento. Adicione essas alterações no arquivo `my.ini` do MySQL (Windows) ou `my.cnf` (UNIX). | Parâmetro | Valor | | --- | --- | | `ndb_log_bin` | Defina este parâmetro como `ON`. Este valor garante que as alterações em tabelas clusterizadas são registradas no log binário. | | `ndb_log_update_as_write` | Defina este parâmetro como `OFF`. Este valor impede o registro de instruções UPDATE como instruções INSERT no log binário. | | `ndb_log_updated_only` | Defina este parâmetro como `OFF`. Este valor garante que o log binário contém a linha completa e não apenas as colunas alteradas. | ## Usando um banco AWS de dados compatível com MySQL gerenciado como fonte para AWS DMS Você pode usar os seguintes bancos de dados compatíveis AWS com MySQL gerenciados como fontes para: AWS DMS + MySQL Community Edition + MariaDB Community Edition + Amazon Aurora Edição Compatível com MySQL Ao usar um banco AWS de dados compatível com MySQL gerenciado como fonte para AWS DMS, verifique se você tem os seguintes pré-requisitos para o CDC: + Para ativar os logs binários para o RDS para MySQL e para o RDS para MariaDB, ative backups automáticos no nível da instância. Para ativar logs binários para um cluster do Aurora MySQL, altere a variável `binlog_format` no grupo de parâmetros. Para obter mais informações sobre a configuração de backups automáticos, consulte [Trabalhar com backups automáticos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) no *Guia do usuário do Amazon RDS*. Para obter mais informações sobre como configurar o registro em log binário para um banco de dados Amazon RDS para MySQL, consulte [Configuração do formato de registro em log binário](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) no *Guia do usuário do Amazon RDS*. Para obter mais informações sobre como configurar o registro em log binário para um cluster do Aurora MySQL, consulte [Como faço para ativar o registro em log binário para meu cluster do Amazon Aurora MySQL?](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/). + Se você planejar utilizar a CDC, ative o registro em log binário. Para obter mais informações sobre como configurar o registro em log binário para um banco de dados Amazon RDS para MySQL, consulte [Configuração do formato de registro em log binário](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) no *Guia do usuário do Amazon RDS*. + Certifique-se de que os registros binários estejam disponíveis para AWS DMS o. Como os bancos AWS de dados compatíveis com MySQL gerenciados eliminam os registros binários o mais rápido possível, você deve aumentar o tempo em que os registros permanecem disponíveis. Por exemplo, para aumentar a retenção de log para 24 horas, execute o comando a seguir. ``` call mysql.rds_set_configuration('binlog retention hours', 24); ``` + Defina o parâmetro `binlog_format` como `"ROW"`. **nota** No MySQL ou no MariaDB, `binlog_format` é um parâmetro dinâmico, portanto, você não precisa reinicializar para que o novo valor entre em vigor. No entanto, o novo valor só se aplicará às novas sessões. Se você alternar `ROW` como `binlog_format` para fins de replicação, o banco de dados ainda poderá criar registros em logs binários subsequentes utilizando o formato `MIXED`, se essas sessões tiverem iniciado antes da alteração do valor. Isso pode AWS DMS impedir a captura adequada de todas as alterações no banco de dados de origem. Ao alterar a configuração `binlog_format` em um banco de dados MariaDB ou MySQL, reinicie o banco de dados para fechar todas as sessões existentes ou reinicie qualquer aplicação executando operações DML (linguagem de manipulação de dados). Forçar seu banco de dados a reiniciar todas as sessões após alterar o `binlog_format` parâmetro para `ROW` garantirá que seu banco de dados grave todas as alterações subsequentes no banco de dados de origem usando o formato correto, para que AWS DMS possa capturar essas alterações adequadamente. + Defina o parâmetro `binlog_row_image` como `"Full"`. + Defina o parâmetro `binlog_checksum` como `"NONE"` para a versão 3.4.7 ou anterior do DMS. Para obter mais informações sobre a configuração de parâmetros no Amazon RDS MySQL, consulte [Trabalhar com backups automáticos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) no *Guia do usuário do Amazon RDS*. + Se estiver utilizando uma réplica de leitura do Amazon RDS MySQL ou do Amazon RDS MariaDB como origem, ative os backups na réplica de leitura e garanta que o parâmetro `log_slave_updates` esteja definido como `TRUE`. ## Limitações no uso de um banco de dados MySQL como fonte para AWS DMS Ao utilizar um banco de dados MySQL como uma origem, considere o seguinte: + A captura de dados de alteração (CDC) não é compatível com o Amazon RDS MySQL 5.5 ou inferior. Para o Amazon RDS MySQL, utilize a versão 5.6, 5.7 ou 8.0 para ativar a CDC. A CDC é compatível com origens do MySQL 5.5 autogerenciado. + Para CDC, `CREATE TABLE`, `ADD COLUMN` e `DROP COLUMN` que alteram o tipo de dados da coluna e `renaming a column` são compatíveis. No entanto, `DROP TABLE`, `RENAME TABLE` e as atualizações feitas em outros atributos, como o valor padrão da coluna, a nulidade da coluna, o conjunto de caracteres e assim por diante, não são compatíveis. + Para tabelas particionadas na origem, quando você define o **modo de preparação da tabela Target** como **Drop tables on target**, AWS DMS cria uma tabela simples sem partições no destino do MySQL. Para migrar tabelas particionadas para uma tabela particionada no destino, pré-crie as tabelas particionadas no banco de dados MySQL de destino. + O uso de uma `ALTER TABLE table_name ADD COLUMN column_name` instrução para adicionar colunas no início (FIRST) ou no meio de uma tabela (AFTER) não é compatível com destinos relacionais. As colunas são sempre adicionadas ao final da tabela. Quando o destino é o Amazon S3 ou o Amazon Kinesis Data Streams, é possível adicionar colunas usando FIRST ou AFTER. + A CDC não é compatível quando um nome de tabela contém caracteres maiúsculos e minúsculos, e o mecanismo de origem está hospedado em um sistema operacional com nomes de arquivos que não diferenciam maiúsculas de minúsculas. Um exemplo é o Microsoft Windows ou o OS X que utilizam HFS\$1. + É possível utilizar a Edição com Tecnologia Sem Servidor v1 compatível com o Aurora MySQL para carga máxima, mas não é possível utilizá-la para CDC. Isso ocorre porque não é possível ativar os pré-requisitos para o MySQL. Para obter mais informações, consulte [Grupos de parâmetros e o Aurora Sem Servidor v1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html#aurora-serverless.parameter-groups). A Edição com Tecnologia Sem Servidor v2 compatível com o Aurora MySQL pode ser utilizada com CDC. + O atributo AUTO\$1INCREMENT em uma coluna não é migrado para uma coluna do banco de dados de destino. + A captura de alterações quando os logs binários não estão armazenados em armazenamento de bloco padrão não é compatível. Por exemplo, a CDC não funciona quando os logs binários são armazenados no Amazon S3. + AWS DMS cria tabelas de destino com o mecanismo de armazenamento InnoDB por padrão. Se precisar utilizar um mecanismo de armazenamento diferente do InnoDB, crie a tabela manualmente e migre-a utilizando o modo [Não executar nenhuma ação](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html). + Você não pode usar réplicas do Aurora MySQL como fonte, a AWS DMS menos que seu modo de tarefa de migração do DMS seja **Migrar** dados existentes — somente com carga total. + Se a origem compatível com MySQL for interrompida durante a carga máxima, a tarefa do AWS DMS não será interrompida com um erro. A tarefa terminará com êxito, mas o destino poderá estar fora de sincronia com a origem. Se isso acontecer, reinicie a tarefa ou recarregue as tabelas afetadas. + Índices criados em uma parte do valor de uma coluna não são migrados. Por exemplo, o índice CREATE INDEX first\$1ten\$1chars ON customer (name(10)) não é criado no destino. + Em alguns casos, a tarefa está configurada para não replicar LOBs (” SupportLobs "é falso nas configurações da tarefa ou **Não incluir colunas LOB** é escolhido no console de tarefas). Nesses casos, AWS DMS não migra nenhuma coluna MEDIUMBLOB, LONGBLOB, MEDIUMTEXT e LONGTEXT para o destino. As colunas BLOB, TINYBLOB, TEXT e TINYTEXT não são afetadas e são migradas para o destino. + Tabelas de dados temporais ou tabelas com versão do sistema não são compatíveis com bancos de dados MariaDB de origem e de destino. + Se estiver migrando entre dois clusters do Amazon RDS Aurora MySQL, o endpoint de origem do RDS Aurora MySQL deve ser uma instância, não uma instância de réplica. read/write + AWS DMS atualmente não oferece suporte à migração de visualizações para o MariaDB. + AWS DMS não suporta alterações de DDL para tabelas particionadas para MySQL. Para ignorar a suspensão de tabela para alterações de DDL da partição durante a CDC, defina `skipTableSuspensionForPartitionDdl` como `true`. + AWS DMS só suporta transações XA na versão 3.5.0 e superior. As versões anteriores não oferecem suporte a transações XA. AWS DMS não suporta transações XA no MariaDB versão 10.6 ou superior. Para obter mais informações, consulte a seguir. [Compatibilidade com transações XA](#CHAP_Source.MySQL.XA) + AWS DMS não é usado GTIDs para replicação, mesmo que os dados de origem os contenham. + AWS DMS não é compatível com o log binário aprimorado do Aurora MySQL. + AWS DMS não oferece suporte à compactação de transações de log binário. + AWS DMS não propaga eventos ON DELETE CASCADE e ON UPDATE CASCADE para bancos de dados MySQL usando o mecanismo de armazenamento InnoDB. Para esses eventos, o MySQL não gera log binário de eventos para refletir as operações em cascata nas tabelas secundárias. Consequentemente, não é AWS DMS possível replicar as alterações correspondentes nas tabelas secundárias. Para obter mais informações, consulte [Índices, chaves estrangeiras ou atualizações ou exclusões em cascata não migrados](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.FKsAndIndexes). + AWS DMS não captura alterações nas colunas computadas (`VIRTUAL`e`GENERATED ALWAYS`). Para trabalhar com essa limitação, faça o seguinte. + Pré-crie a tabela de destino no banco de dados de destino e crie a tarefa AWS DMS com a configuração de tarefa de carga máxima `DO_NOTHING` ou `TRUNCATE_BEFORE_LOAD`. + Adicione uma regra de transformação para remover a coluna computada do escopo da tarefa. Para obter mais informações sobre regras transformação, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). + Devido à limitação interna do MySQL, BINLOGs não AWS DMS pode processar mais do que 4 GB. BINLOGs maiores que 4 GB podem resultar em falhas nas tarefas do DMS ou em outros comportamentos imprevisíveis. Você deve reduzir o tamanho das transações para evitar BINLOGs mais de 4 GB. + AWS DMS não suporta marcações invertidas (```) ou aspas simples (`'`) em nomes de esquemas, tabelas e colunas. + 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. ## Compatibilidade com transações XA Uma transação de arquitetura estendida (XA) é uma transação que pode ser utilizada para agrupar uma série de operações de vários recursos transacionais em uma única transação global confiável. Uma transação XA utiliza um protocolo de confirmação de duas fases. Em geral, a captura de alterações enquanto há transações XA abertas pode resultar em perda de dados. Se o banco de dados não utilizar transações XA, é possível ignorar essa permissão e a configuração `IgnoreOpenXaTransactionsCheck` utilizando o valor padrão `TRUE`. Para começar a replicar a partir de uma origem que possui transações XA, faça o seguinte: + Certifique-se de que o usuário do AWS DMS endpoint tenha a seguinte permissão: ``` grant XA_RECOVER_ADMIN on *.* to 'userName'@'%'; ``` + Defina a configuração do endpoint `IgnoreOpenXaTransactionsCheck` como `false`. **nota** AWS DMS não suporta transações XA no MariaDB Source DB versão 10.6 ou superior. ## Configurações de endpoint ao usar o MySQL como fonte para AWS DMS É possível utilizar as configurações de endpoint para configurar o banco de dados MySQL de origem de forma semelhante à utilização de atributos de conexão adicional. 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--my-sql-settings '{"EndpointSetting": "value", ...}'` JSON. A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o MySQL como origem. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.MySQL.html) ## Tipos de dados de origem do MySQL A tabela a seguir mostra os tipos de dados de origem do banco de dados MySQL que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados. 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, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de dados do MySQL | AWS DMS tipos de dados | | --- | --- | | INT | INT4 | | BIGINT | INT8 | | MEDIUMINT | INT4 | | TINYINT | INT1 | | SMALLINT | INT2 | | UNSIGNED TINYINT | UINT1 | | UNSIGNED SMALLINT | UINT2 | | UNSIGNED MEDIUMINT | UINT4 | | UNSIGNED INT | UINT4 | | UNSIGNED BIGINT | UINT8 | | DECIMAL(10) | NUMERIC (10,0) | | BINARY | BYTES(1) | | BIT | BOOLEAN | | BIT(64) | BYTES(8) | | BLOB | BYTES(65.535) | | LONGBLOB | BLOB | | MEDIUMBLOB | BLOB | | TINYBLOB | BYTES(255) | | DATE | DATE | | DATETIME | DATETIME DATETIME sem um valor entre parênteses é replicado sem milissegundos. DATETIME com um valor entre parênteses de 1 a 5 (como`DATETIME(5)`) é replicado com milissegundos. Ao replicar uma coluna DATETIME, a hora permanece a mesma no destino. Não é convertida em UTC. | | TIME | STRING | | TIMESTAMP | DATETIME Ao replicar uma coluna TIMESTAMP, a hora é convertida em UTC no destino. | | YEAR | INT2 | | DOUBLE | REAL8 | | FLOAT | REAL(DOUBLE) Se os valores FLOAT não estiverem no intervalo a seguir, utilize uma transformação para mapear FLOAT para STRING. Para obter mais informações sobre transformações, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). Os intervalos compatíveis com FLOAT são -1.79E\$1308 a -2.23E-308, 0 e 2.23E-308 a 1.79E\$1308 | | VARCHAR (45) | WSTRING (45) | | VARCHAR (2000) | WSTRING (2000) | | VARCHAR (4000) | WSTRING (4000) | | VARBINARY (4000) | BYTES (4000) | | VARBINARY (2000) | BYTES (2000) | | CHAR | WSTRING | | TEXT | WSTRING | | LONGTEXT | NCLOB | | MEDIUMTEXT | NCLOB | | TINYTEXT | WSTRING(255) | | GEOMETRY | BLOB | | POINT | BLOB | | LINESTRING | BLOB | | POLYGON | BLOB | | MULTIPOINT | BLOB | | MULTILINESTRING | BLOB | | MULTIPOLYGON | BLOB | | GEOMETRYCOLLECTION | BLOB | | ENUM | SEQUÊNCIA DE CARACTERES () *length* Aqui *length* está o comprimento do valor mais longo no ENUM. | | SET | SEQUÊNCIA DE CARACTERES () *length* Aqui *length* está o tamanho total de todos os valores no SET, incluindo vírgulas. | | JSON | CLOB | **nota** Em alguns casos, é possível especificar os tipos de dados DATETIME e TIMESTAMP com um valor “zero” (ou seja, 0000-00-00). Nesse caso, verifique se o banco de dados de destino na tarefa de replicação é compatível com valores “zero” para os tipos de dados DATETIME e TIMESTAMP. Caso contrário, esses valores serão registrados como nulos no destino. # Usando um banco de dados SAP ASE como fonte para AWS DMS Você pode migrar dados de um banco de dados SAP Adaptive Server Enterprise (ASE), anteriormente conhecido como Sybase, usando. AWS DMS Com um banco de dados SAP ASE como fonte, você pode migrar dados para qualquer um dos outros bancos de dados de AWS DMS destino compatíveis. Para obter informações sobre as versões do SAP ASE que oferecem AWS DMS suporte como fonte, consulte[Fontes para AWS DMS](CHAP_Introduction.Sources.md). Para obter detalhes adicionais sobre como trabalhar com bancos de dados SAP ASE AWS DMS, consulte as seções a seguir. **Topics** + [Pré-requisitos para usar um banco de dados SAP ASE como fonte para AWS DMS](#CHAP_Source.SAP.Prerequisites) + [Limitações no uso do SAP ASE como fonte para AWS DMS](#CHAP_Source.SAP.Limitations) + [Permissões necessárias para usar o SAP ASE como fonte para AWS DMS](#CHAP_Source.SAP.Security) + [Remover o ponto de truncamento](#CHAP_Source.SAP.Truncation) + [Configurações de endpoint ao usar o SAP ASE como fonte para AWS DMS](#CHAP_Source.SAP.ConnectionAttrib) + [Tipos de dados de origem do SAP ASE](#CHAP_Source.SAP.DataTypes) ## Pré-requisitos para usar um banco de dados SAP ASE como fonte para AWS DMS Para que um banco de dados SAP ASE seja uma fonte AWS DMS, faça o seguinte: + Ative a replicação do SAP ASE para tabelas utilizando o comando `sp_setreptable`. Para obter mais informações, consulte [Sybase Infocenter Archive]( http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc32410_1501/html/refman/X37830.htm). + Desabilite `RepAgent` no banco de dados SAP ASE. Para obter mais informações, consulte [Parar e desativar o RepAgent encadeamento no banco de dados principal](http://infocenter-archive.sybase.com/help/index.jsp?topic=/com.sybase.dc20096_1260/html/mra126ag/mra126ag65.htm). + Para replicar para o SAP ASE versão 15.7 em uma instância do Windows EC2 configurada para caracteres não latinos (por exemplo, chinês), instale o SAP ASE 15.7 SP121 no computador de destino. **nota** Para a replicação de captura de dados de alteração (CDC), o DMS executa `dbcc logtransfer` e `dbcc log` para ler os dados do log de transações. ## Limitações no uso do SAP ASE como fonte para AWS DMS As seguintes limitações se aplicam quando um banco de dados SAP ASE é utilizado como origem do AWS DMS: + Você pode executar somente uma AWS DMS tarefa com replicação contínua ou CDC para cada banco de dados SAP ASE. Você pode executar várias full-load-only tarefas em paralelo. + Não é possível renomear uma tabela. Por exemplo, o comando a seguir falha. ``` sp_rename 'Sales.SalesRegion', 'SalesReg; ``` + Não é possível renomear uma coluna. Por exemplo, o comando a seguir falha. ``` sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN'; ``` + Os valores zero presentes no final de strings de tipos de dados binários são truncados quando replicados para o banco de dados de destino. Por exemplo, `0x0000000000000000000000000100000100000000` na tabela de origem torna-se `0x00000000000000000000000001000001` na tabela de destino. + Se o padrão do banco de dados estiver definido para não permitir valores NULL, AWS DMS cria a tabela de destino com colunas que não permitem valores NULL. Consequentemente, se uma carga completa ou tarefa de replicação do CDC contiver valores vazios, AWS DMS gerará um erro. É possível evitar esses erros permitindo valores NULL no banco de dados de origem com os seguintes comandos. ``` sp_dboption database_name, 'allow nulls by default', 'true' go use database_name CHECKPOINT go ``` + O comando de índice `reorg rebuild` não é compatível. + AWS DMS não suporta clusters nem usa MSA (Multi-Site Availability) /Warm Standby como fonte. + Quando a expressão do cabeçalho de transformação `AR_H_TIMESTAMP` é utilizada em regras de mapeamento, os milissegundos não serão capturados para uma coluna adicionada. + A execução de operações de mesclagem durante a CDC resultará em um erro não recuperável. Para sincronizar o destino novamente, execute uma carga máxima. + Os eventos de acionador de reversão não são compatíveis com tabelas que utilizam um esquema de bloqueio de linhas de dados. + AWS DMS não é possível retomar uma tarefa de replicação depois de eliminar uma tabela dentro do escopo da tarefa de um banco de dados SAP de origem. Se a tarefa de replicação do DMS foi interrompida e executou qualquer operação DML (INSERT, UPDATE, DELETE) seguida pelo descarte da tabela, reinicie a tarefa de replicação. ## Permissões necessárias para usar o SAP ASE como fonte para AWS DMS Para usar um banco de dados SAP ASE como fonte em uma AWS DMS tarefa, você precisa conceder permissões. Conceda à conta de usuário especificada nas definições do AWS DMS banco de dados as seguintes permissões no banco de dados SAP ASE: + sa\$1role + replication\$1role + sybase\$1ts\$1role + Por padrão, quando você precisa ter permissão para executar o procedimento `sp_setreptable` armazenado, AWS DMS ativa a opção de replicação do SAP ASE. Se você quiser executar `sp_setreptable` em uma tabela diretamente do endpoint do banco de dados e não por AWS DMS si só, você pode usar o atributo de conexão `enableReplication` extra. Para obter mais informações, consulte [Configurações de endpoint ao usar o SAP ASE como fonte para AWS DMS](#CHAP_Source.SAP.ConnectionAttrib). ## Remover o ponto de truncamento Quando uma tarefa é iniciada, AWS DMS estabelece uma `$replication_truncation_point` entrada na visualização do `syslogshold` sistema, indicando que um processo de replicação está em andamento. Enquanto AWS DMS está trabalhando, ele avança o ponto de truncamento de replicação em intervalos regulares, de acordo com a quantidade de dados que já foram copiados para o destino. Depois que a `$replication_truncation_point` entrada for estabelecida, mantenha a AWS DMS tarefa em execução para evitar que o log do banco de dados fique excessivamente grande. Se você quiser interromper a AWS DMS tarefa permanentemente, remova o ponto de truncamento de replicação emitindo o seguinte comando: ``` dbcc settrunc('ltm','ignore') ``` Depois que o ponto de truncamento for removido, você não poderá continuar a AWS DMS tarefa. O log continuará a ser automaticamente truncado nos pontos de verificação (se o truncamento automático for definido). ## Configurações de endpoint ao usar o SAP ASE como fonte para AWS DMS É possível utilizar as configurações de endpoint para configurar o banco de dados de origem do SAP ASE de maneira semelhante à utilização de atributos de conexão adicional. 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--sybase-settings '{"EndpointSetting": "value", ...}'` JSON. A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o SAP ASE como origem. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.SAP.html) ## Tipos de dados de origem do SAP ASE Para obter uma lista dos tipos de dados de origem do SAP ASE que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados, consulte a tabela a seguir. AWS DMS não suporta tabelas de origem do SAP ASE com colunas do tipo de dados do tipo definido pelo usuário (UDT). Colunas replicadas com esse tipo de dados são criadas como NULL. Para obter informações sobre como exibir o tipo de dados mapeado no destino, consulte a seção [Destinos para a migração de dados](CHAP_Target.md) relativa ao seu endpoint de destino. Para obter informações adicionais sobre AWS DMS os tipos de dados, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de dados do SAP ASE | AWS DMS tipos de dados | | --- | --- | | BIGINT | INT8 | | UNSIGNED BIGINT | UINT8 | | INT | INT4 | | UNSIGNED INT | UINT4 | | SMALLINT | INT2 | | UNSIGNED SMALLINT | UINT2 | | TINYINT | UINT1 | | DECIMAL | NUMERIC | | NUMERIC | NUMERIC | | FLOAT | REAL8 | | DOUBLE | REAL8 | | REAL | REAL4 | | MONEY | NUMERIC | | SMALLMONEY | NUMERIC | | DATETIME | DATETIME | | BIGDATETIME | DATETIME(6) | | SMALLDATETIME | DATETIME | | DATE | DATE | | TIME | TIME | | BIGTIME | TIME | | CHAR | STRING | | UNICHAR | WSTRING | | NCHAR | WSTRING | | VARCHAR | STRING | | UNIVARCHAR | WSTRING | | NVARCHAR | WSTRING | | BINARY | BYTES | | VARBINARY | BYTES | | BIT | BOOLEAN | | TEXT | CLOB | | UNITEXT | NCLOB | | IMAGE | BLOB | # Usando o MongoDB como fonte para AWS DMS Para obter informações sobre as versões do MongoDB AWS DMS que oferecem suporte como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) Observe o seguinte sobre a compatibilidade com a versão do MongoDB: + As versões AWS DMS 3.4.5 e posteriores oferecem suporte às versões 4.2 e 4.4 do MongoDB. + As versões AWS DMS 3.4.5 e posteriores e as versões do MongoDB 4.2 e posteriores oferecem suporte a transações distribuídas. Para obter mais informações sobre as transações distribuídas do MongoDB, consulte [Transações](https://docs.mongodb.com/manual/core/transactions/) na [Documentação do MongoDB](https://www.mongodb.com/docs/). + As versões AWS DMS 3.5.0 e posteriores não oferecem suporte às versões do MongoDB anteriores à 3.6. + As versões AWS DMS 3.5.1 e posteriores oferecem suporte à versão 5.0 do MongoDB. + As versões AWS DMS 3.5.2 e posteriores oferecem suporte à versão 6.0 do MongoDB. + As versões AWS DMS 3.5.4 e posteriores oferecem suporte às versões 7.0 e 8.0 do MongoDB. Se você é novo no MongoDB, esteja ciente quanto aos seguintes conceitos importantes sobre o banco de dados MongoDB. + Um registro no MongoDB é um *documento*, que é uma estrutura de dados composta por pares de campo e valor. O valor de um campo pode incluir outros documentos, matrizes e matrizes de documentos. Um documento é aproximadamente equivalente a uma linha em uma tabela de banco de dados relacional. + Uma *coleção* no MongoDB é um grupo de documentos e é aproximadamente equivalente a uma tabela de banco de dados relacional. + Um *banco de dados* no MongoDB é um conjunto de coleções e é aproximadamente equivalente a uma tabela de banco de dados relacional. + Internamente, um documento do MongoDB é armazenado como um arquivo binário JSON (BSON) em um formato compactado que inclui um tipo para cada campo no documento. Cada documento tem um ID exclusivo. AWS DMS *suporta dois modos de migração ao usar o MongoDB como fonte*, o modo Documento ou o modo Tabela*.* Você especifica o modo de migração a ser utilizado ao criar o endpoint do MongoDB ou ao configurar o parâmetro do **Modo metadados** no console do AWS DMS . Opcionalmente, é possível criar uma segunda coluna chamada `_id` que atue como a chave primária selecionando o botão de marca de seleção para **\$1id como uma coluna separada** no painel de configuração do endpoint. A escolha do modo de migração afeta o formato resultante dos dados de destino, conforme explicado a seguir. **Modo de documentos** No modo de documentos, o documento do MongoDB é migrado "no estado em que se encontra", ou seja, os dados do documento são consolidados em uma única coluna chamada `_doc` em uma tabela de destino. O modo de documentos é a configuração padrão ao utilizar o MongoDB como um endpoint de origem. Por exemplo, considere os seguintes documentos em uma coleção do MongoDB chamada myCollection. ``` db.myCollection.find() { "_id" : ObjectId("5a94815f40bd44d1b02bdfe0"), "a" : 1, "b" : 2, "c" : 3 } { "_id" : ObjectId("5a94815f40bd44d1b02bdfe1"), "a" : 4, "b" : 5, "c" : 6 } ``` Após a migração dos dados para uma tabela de banco de dados relacional usando o modo de documentos, os dados são estruturados como mostrado a seguir. Os campos de dados no documento do MongoDB são consolidados na coluna` _doc`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.MongoDB.html) Opcionalmente, é possível definir o atributo de conexão adicional `extractDocID` como *verdadeiro* para criar uma segunda coluna chamada `"_id"`, que servirá como a chave primária. Se for utilizar a CDC, defina esse parâmetro como *verdadeiro*. *Ao usar o CDC com fontes que produzem [transações com vários documentos](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), o `ExtractDocId` parâmetro **deve ser** definido como verdadeiro.* Se esse parâmetro não estiver ativado, a AWS DMS tarefa falhará quando encontrar uma transação com vários documentos. No modo documento, AWS DMS gerencia a criação e a renomeação de coleções da seguinte forma: + Se você adicionar uma nova coleção ao banco de dados de origem, AWS DMS cria uma nova tabela de destino para a coleção e replica todos os documentos. + Se você renomear uma coleção existente no banco de dados de origem, o AWS DMS não renomeará a tabela de destino. Se o endpoint de destino for o Amazon DocumentDB, execute a migração no **Modo documento**. **Modo de tabelas** No modo tabela, AWS DMS transforma cada campo de nível superior em um documento do MongoDB em uma coluna na tabela de destino. Se um campo estiver aninhado, AWS DMS nivela os valores aninhados em uma única coluna. AWS DMS em seguida, adiciona um campo-chave e tipos de dados ao conjunto de colunas da tabela de destino. Para cada documento do MongoDB AWS DMS , adiciona cada chave e tipo ao conjunto de colunas da tabela de destino. Por exemplo, usando o modo tabela, AWS DMS migra o exemplo anterior para a tabela a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.MongoDB.html) Os valores aninhados são simplificados em uma coluna que contém os nomes das chaves separados por pontos. A coluna é nomeado concatenação dos nomes dos campos simplificados, separados por pontos. Por exemplo, AWS DMS migra um documento JSON com um campo de valores aninhados, como `{"a" : {"b" : {"c": 1}}}` em uma coluna chamada `a.b.c.` Para criar as colunas de destino, AWS DMS digitaliza um número específico de documentos do MongoDB e cria um conjunto de todos os campos e seus tipos. AWS DMS em seguida, usa esse conjunto para criar as colunas da tabela de destino. Se criar ou modificar o endpoint de origem do MongoDB utilizando o console, especifique o número de documentos para verificação. O valor padrão são 1.000 documentos. Se você usar o AWS CLI, poderá usar o atributo de conexão extra`docsToInvestigate`. No modo tabela, AWS DMS gerencia documentos e coleções da seguinte forma: + Ao adicionar um documento a uma coleção existente, o documento é replicado. Se houver campos que não existem no destino, esses campos não serão replicados. + Quando você atualiza um documento, o documento atualizado é replicado. Se houver campos que não existem no destino, esses campos não serão replicados. + A exclusão de documentos é totalmente compatível. + A adição de uma coleção nova não resultará na criação de uma nova tabela no destino quando feita durante uma tarefa de CDC. + Na fase Change Data Capture (CDC), AWS DMS não oferece suporte à renomeação de uma coleção. **Topics** + [Permissões necessárias ao usar o MongoDB como fonte para AWS DMS](#CHAP_Source.MongoDB.PrerequisitesCDC) + [Configurar um conjunto de réplicas do MongoDB para a CDC](#CHAP_Source.MongoDB.PrerequisitesCDC.ReplicaSet) + [Requisitos de segurança ao usar o MongoDB como fonte para AWS DMS](#CHAP_Source.MongoDB.Security) + [Segmentar as coleções do MongoDB e migrar em paralelo](#CHAP_Source.MongoDB.ParallelLoad) + [Migrando vários bancos de dados ao usar o MongoDB como fonte para AWS DMS](#CHAP_Source.MongoDB.Multidatabase) + [Limitações ao usar o MongoDB como fonte para AWS DMS](#CHAP_Source.MongoDB.Limitations) + [Configurações de endpoint ao usar o MongoDB como fonte para AWS DMS](#CHAP_Source.MongoDB.Configuration) + [Tipos de dados de origem do MongoDB](#CHAP_Source.MongoDB.DataTypes) ## Permissões necessárias ao usar o MongoDB como fonte para AWS DMS Para uma AWS DMS migração com uma fonte do MongoDB, você pode criar uma conta de usuário com privilégios de root ou um usuário com permissões somente no banco de dados para migrar. O código a seguir cria um usuário para ser a conta raiz. ``` use admin db.createUser( { user: "root", pwd: "password", roles: [ { role: "root", db: "admin" } ] } ) ``` Para um origem do MongoDB 3.x, o código a seguir cria um usuário com privilégios mínimos no banco de dados a ser migrado. ``` use database_to_migrate db.createUser( { user: "dms-user", pwd: "password", roles: [ { role: "read", db: "local" }, "read"] }) ``` Para um MongoDB 4.x de origem, o código a seguir cria um usuário com privilégios mínimos. ``` { resource: { db: "", collection: "" }, actions: [ "find", "changeStream" ] } ``` Por exemplo, crie o seguinte perfil no banco de dados “admin”. ``` use admin db.createRole( { role: "changestreamrole", privileges: [ { resource: { db: "", collection: "" }, actions: [ "find","changeStream" ] } ], roles: [] } ) ``` Quando o perfil estiver criado, crie um usuário no banco de dados a ser migrado. ``` use test > db.createUser( { user: "dms-user12345", pwd: "password", roles: [ { role: "changestreamrole", db: "admin" }, "read"] }) ``` ## Configurar um conjunto de réplicas do MongoDB para a CDC Para usar a replicação contínua ou CDC com o MongoDB, é necessário AWS DMS acesso ao log de operações do MongoDB (oplog). Para criar o oplog, é necessário implantar um conjunto de réplicas, caso não exista. Para obter mais informações, consulte a [ documentação do MongoDB](https://docs.mongodb.com/manual/tutorial/deploy-replica-set/). É possível utilizar a CDC com o nó primário ou secundário de um conjunto de réplicas do MongoDB como o endpoint de origem. **Para converter uma instância independente em um conjunto de réplicas** 1. utilizando a linha de comando, conecte-se ao `mongo`. ``` mongo localhost ``` 1. Interrompa o serviço `mongod`. ``` service mongod stop ``` 1. Reinicie o `mongod` utilizando o comando a seguir: ``` mongod --replSet "rs0" --auth -port port_number ``` 1. Teste a conexão com o conjunto de réplicas utilizando os seguintes comandos: ``` mongo -u root -p password --host rs0/localhost:port_number --authenticationDatabase "admin" ``` Se planeja executar uma migração no modo de documentos, selecione a opção `_id as a separate column` ao criar o endpoint do MongoDB. Selecionar essa opção cria uma segunda coluna chamada `_id` que atua como a chave primária. Essa segunda coluna é necessária AWS DMS para suportar operações de linguagem de manipulação de dados (DML). **nota** AWS DMS usa o log de operações (oplog) para capturar as alterações durante a replicação contínua. Se o MongoDB eliminar os registros do oplog AWS DMS antes de lê-los, suas tarefas falharão. É recomendável dimensionar o oplog para reter as alterações por pelo menos 24 horas. ## Requisitos de segurança ao usar o MongoDB como fonte para AWS DMS AWS O DMS oferece suporte a dois métodos de autenticação para o MongoDB. Os dois métodos de autenticação são utilizados para criptografar a senha, e portanto só são utilizados quando o parâmetro `authType` está definido como *PASSWORD*. Os métodos de autenticação do MongoDB são os seguintes: + **MONGODB-CR**: para compatibilidade com versões anteriores + **SCRAM-SHA-1**: o padrão ao utilizar o MongoDB versão 3.x e 4.0. Se um método de autenticação não for especificado, o AWS DMS usa o método padrão para a versão da fonte do MongoDB. ## Segmentar as coleções do MongoDB e migrar em paralelo Para melhorar o desempenho de uma tarefa de migração, os endpoints de origem do MongoDB são compatíveis com duas opções para carga máxima paralela no mapeamento de tabela. Em outras palavras, é possível migrar uma coleção em paralelo utilizando segmentação automática ou segmentação por intervalo com mapeamento de tabela para uma carga máxima paralela nas configurações do JSON. Com a segmentação automática, você pode especificar os critérios AWS DMS para segmentar automaticamente sua fonte para migração em cada thread. Com a segmentação por faixa, você pode informar AWS DMS a faixa específica de cada segmento para que o DMS migre em cada thread. Para obter mais informações sobre essas configurações, consulte [Regras e operações de configurações de tabelas e coleções](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md). ### Migrar um banco de dados MongoDB em paralelo utilizando intervalos de segmentação automática É possível migrar os documentos em paralelo especificando os critérios do AWS DMS para particionar (segmentar) automaticamente os dados de cada thread. Especificamente, informe o número de documentos a serem migrados por thread. Usando essa abordagem, AWS DMS tenta otimizar os limites do segmento para obter o máximo desempenho por thread. É possível especificar os critérios de segmentação utilizando as opções de configurações de tabela a seguir no mapeamento de tabela. | Opção de configurações de tabela | Description | | --- | --- | | `"type"` | (Obrigatório) Defina como `"partitions-auto"` para MongoDB como origem. | | `"number-of-partitions"` | (Opcional) Número total de partições (segmentos) utilizadas para a migração. O padrão é 16. | | `"collection-count-from-metadata"` | (Opcional) Se essa opção estiver definida como `true`, o AWS DMS utilizará uma contagem estimada da coleção para determinar o número de partições. Se essa opção estiver definida como`false`, AWS DMS usa a contagem real da coleta. O padrão é `true`. | | `"max-records-skip-per-page"` | (Opcional) O número de registros a serem ignorados de uma vez ao determinar os limites de cada partição. AWS DMS usa uma abordagem de salto paginado para determinar o limite mínimo de uma partição. O padrão é 10.000. A definição de um valor relativamente grande pode resultar em tempos limite do cursor e falhas na tarefa. A definição de um valor relativamente baixo resulta em mais operações por página e em uma carga máxima mais lenta. | | `"batch-size"` | (Opcional) Limita o número de documentos retornados em um lote. Cada lote requer uma viagem de ida e volta ao servidor. Se o tamanho do lote for zero (0), o cursor utilizará o tamanho máximo do lote definido pelo servidor. O padrão é 0. | O exemplo a seguir mostra um mapeamento de tabela para segmentação automática. ``` { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "admin", "table-name": "departments" }, "rule-action": "include", "filters": [] }, { "rule-type": "table-settings", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "admin", "table-name": "departments" }, "parallel-load": { "type": "partitions-auto", "number-of-partitions": 5, "collection-count-from-metadata": "true", "max-records-skip-per-page": 1000000, "batch-size": 50000 } } ] } ``` A segmentação automática tem a seguinte limitação. A migração de cada segmento busca a contagem da coleção e o `_id` mínimo da coleção separadamente. Ela utiliza um salto paginado para calcular o limite mínimo desse segmento. Portanto, verifique se o valor mínimo de `_id` de cada coleção permanece constante até que todos os limites do segmento na coleção tenham sido calculados. Se você alterar o valor mínimo de `_id` de uma coleção durante o cálculo do limite do segmento, isso poderá causar perda de dados ou erros de linha duplicada. ### Migrar de um banco de dados MongoDB em paralelo utilizando segmentação de intervalo É possível migrar os documentos em paralelo especificando os intervalos de cada segmento em um thread. Usando essa abordagem, você instrui AWS DMS os documentos específicos a migrar em cada thread de acordo com sua escolha de intervalos de documentos por thread. O exemplo a seguir mostra uma coleção do MongoDB que tem sete itens e `_id` como chave primária. ![\[Coleção do MongoDB com sete itens.\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-docdb-collection.png) Para dividir a coleção em três segmentos específicos para AWS DMS migrar em paralelo, você pode adicionar regras de mapeamento de tabelas à sua tarefa de migração. Essa abordagem é mostrada no exemplo de JSON a seguir. ``` { // Task table mappings: "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "testdatabase", "table-name": "testtable" }, "rule-action": "include" }, // "selection" :"rule-type" { "rule-type": "table-settings", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "testdatabase", "table-name": "testtable" }, "parallel-load": { "type": "ranges", "columns": [ "_id", "num" ], "boundaries": [ // First segment selects documents with _id less-than-or-equal-to 5f805c97873173399a278d79 // and num less-than-or-equal-to 2. [ "5f805c97873173399a278d79", "2" ], // Second segment selects documents with _id > 5f805c97873173399a278d79 and // _id less-than-or-equal-to 5f805cc5873173399a278d7c and // num > 2 and num less-than-or-equal-to 5. [ "5f805cc5873173399a278d7c", "5" ] // Third segment is implied and selects documents with _id > 5f805cc5873173399a278d7c. ] // :"boundaries" } // :"parallel-load" } // "table-settings" :"rule-type" ] // :"rules" } // :Task table mappings ``` Essa definição de mapeamento de tabela divide a coleção de origem em três segmentos e migra em paralelo. Veja a seguir os limites de segmentação. ``` Data with _id less-than-or-equal-to "5f805c97873173399a278d79" and num less-than-or-equal-to 2 (2 records) Data with _id > "5f805c97873173399a278d79" and num > 2 and _id less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5 (3 records) Data with _id > "5f805cc5873173399a278d7c" and num > 5 (2 records) ``` Depois que a tarefa de migração for concluída, é possível verificar os logs de tarefas para saber se as tabelas foram carregadas em paralelo, conforme mostrado no exemplo a seguir. Também é possível verificar a cláusula `find` do MongoDB utilizada para descarregar cada segmento da tabela de origem. ``` [TASK_MANAGER ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328) [SOURCE_UNLOAD ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent. [TASK_MANAGER ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328) [SOURCE_UNLOAD ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent. [TARGET_LOAD ] I: Load finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 1 rows received. 0 rows skipped. Volume transfered 480. [TASK_MANAGER ] I: Load finished for segment #1 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. 2 records transferred. ``` Atualmente, AWS DMS oferece suporte aos seguintes tipos de dados do MongoDB como uma coluna de chave de segmento: + Duplo + String + ObjectId + Inteiro de 32 bits + Inteiro de 64 bits ## Migrando vários bancos de dados ao usar o MongoDB como fonte para AWS DMS AWS DMS as versões 3.4.5 e superiores oferecem suporte à migração de vários bancos de dados em uma única tarefa para todas as versões suportadas do MongoDB. Para migrar vários bancos de dados, utilize as seguintes etapas: 1. Ao criar o endpoint de origem do MongoDB, siga um destes procedimentos: + Na página **Criar endpoint** do console do DMS, verifique se o **Nome do banco de dados** está vazio em **Configuração do endpoint**. + Usando o AWS CLI `CreateEndpoint` comando, atribua um valor de string vazio ao `DatabaseName` parâmetro em`MongoDBSettings`. 1. Para cada banco de dados a ser migrado de uma origem do MongoDB, especifique o nome do banco de dados como um nome de esquema no mapeamento da tabela da tarefa. É possível fazer isso utilizando a entrada guiada no console ou diretamente no JSON. Para obter mais informações sobre a entrada guiada, consulte [Especificar a seleção de tabelas e as regras de transformação no console](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). Para obter mais informações sobre o JSON, consulte [Regras de seleção e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md). Por exemplo, é possível especificar o JSON a seguir para migrar três bancos de dados do MongoDB. **Example Migrar todas as tabelas em um esquema** O JSON a seguir migra todas as tabelas dos bancos de dados `Customers`, `Orders` e `Suppliers` no endpoint de origem para o endpoint de destino. ``` { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "Customers", "table-name": "%" }, "rule-action": "include", "filters": [] }, { "rule-type": "selection", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "Orders", "table-name": "%" }, "rule-action": "include", "filters": [] }, { "rule-type": "selection", "rule-id": "3", "rule-name": "3", "object-locator": { "schema-name": "Inventory", "table-name": "%" }, "rule-action": "include", "filters": [] } ] } ``` ## Limitações ao usar o MongoDB como fonte para AWS DMS A seguir estão as limitações ao usar o MongoDB como fonte para: AWS DMS + No modo tabela, os documentos em uma coleção devem ser consistentes com o tipo de dados que utilizam para o valor no mesmo campo. Por exemplo, se um documento em uma coleção incluir `'{ a:{ b:value ... }'`, todos os documentos da coleção que fazem referência ao `value` do campo `a.b` devem utilizar o mesmo tipo de dados para `value`, onde quer que apareçam na coleção. + Quando a opção `_id` está definida como uma coluna separada, a string de ID não pode exceder 200 caracteres. + As chaves de ID de objetos e de tipos de array são convertidas em colunas com o prefixo `oid` e `array` no modo de tabela. Internamente, essas colunas são referenciadas com os nomes prefixados. Se você usar regras de transformação para referenciar essas colunas, certifique-se de especificar a coluna prefixada. AWS DMS Por exemplo, especifique `${oid__id}` e não `${_id}`, ou `${array__addresses}` e não `${_addresses}`. + Os nomes de coleções e os nomes de chaves não podem conter o caractere de cifrão (\$1). + AWS DMS não oferece suporte a coleções contendo o mesmo campo com letras maiúsculas e minúsculas diferentes no modo de tabela com um destino RDBMS. Por exemplo, AWS DMS não suporta ter duas coleções chamadas `Field1` `field1` e. + Os modos tabelas e documento possuem as limitações descritas anteriormente. + A migração em paralelo que utiliza a segmentação automática possui as limitações descritas anteriormente. + Os filtros de origem não são compatíveis com o MongoDB. + AWS DMS não suporta documentos em que o nível de aninhamento seja maior que 97. + AWS DMS requer dados de origem codificados em UTF-8 ao migrar para destinos que não sejam do DocumentDB. Para fontes com caracteres não UTF-8, converta-os em UTF-8 antes da migração ou migre para o Amazon DocumentDB. + AWS DMS não oferece suporte aos seguintes recursos do MongoDB versão 5.0: + Refragmentação em tempo real + Criptografia em nível de campo do lado do cliente (CSFLE) + Migração de coleção de séries temporais **nota** Uma coleção de séries temporais migrada na fase de carga máxima será convertida em uma coleção normal no Amazon DocumentDB, porque o DocumentDB não é compatível com coleções de séries temporais. ## Configurações de endpoint ao usar o MongoDB como fonte para AWS DMS Ao configurar seu endpoint de origem do MongoDB, você pode especificar várias configurações de endpoint usando o console. AWS DMS A tabela a seguir descreve as configurações disponíveis ao usar bancos de dados MongoDB como fonte. AWS DMS | Configuração (atributo) | Valores válidos | Valor padrão e descrição | | --- | --- | --- | | **Modo de autenticação** | `"none"` `"password"` | O valor `"password"` solicita um nome de usuário e uma senha. Quando `"none"` for especificado, os parâmetros de nome de usuário e senha não serão utilizados. | | **Origem da autenticação** | Um nome de banco de dados MongoDB válido. | O nome do banco de dados MongoDB que você deseja utilizar para validar as credenciais para autenticação. O valor padrão é `"admin"`. | | **Mecanismo de autenticação** | `"default"` `"mongodb_cr"` `"scram_sha_1"` | O mecanismo de autenticação. O valor ` "default"` é `"scram_sha_1"`. Essa configuração não é utilizada quando `authType` está definido como `"no"`. | | **Modo metadados** | Documento e tabela | Escolhe o modo documento ou o modo tabela. | | **Número de documentos a serem verificados** (`docsToInvestigate`) | Um inteiro positivo maior do que `0`. | Utilize essa opção no modo tabela somente para definir a configuração da tabela de destino. | | **\$1id como uma coluna separada** | Marca de seleção na caixa | Marca de seleção opcional que cria uma segunda coluna chamada `_id` que atua como a chave primária. | | `ExtractDocID` | `true` `false` | `false`: utilize este atributo quando `NestingLevel` estiver definido como `"none"`. Ao usar o CDC com fontes que produzem [transações com vários documentos](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), o `ExtractDocId` parâmetro **deve ser** definido como. `true` Se esse parâmetro não estiver ativado, a AWS DMS tarefa falhará quando encontrar uma transação com vários documentos. | | `socketTimeoutMS` | Um número inteiro maior ou igual a 0. Somente atributo de conexão adicional (ECA). | Essa configuração está em unidades de milissegundos e configura o tempo limite de conexão para clientes MongoDB. Se o valor for menor ou igual a zero, o padrão do cliente MongoDB será utilizado. | | `UseUpdateLookUp` | `true` `false` | Quando verdadeiro, durante os eventos de atualização do CDC, AWS DMS copia todo o documento atualizado para o destino. Quando definido como false, AWS DMS usa o comando de atualização do MongoDB para atualizar somente os campos modificados no documento no destino. | | `ReplicateShardCollections` | `true` `false` | Quando verdadeiro, AWS DMS replica os dados em coleções de fragmentos. AWS DMS só usa essa configuração se o endpoint de destino for um cluster elástico DocumentDB. Quando essa configuração for verdadeira, observe o seguinte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.MongoDB.html) | | `useTransactionVerification` | `true` `false` | Quando `false`, a verificação entre o fluxo de alterações e os logs de operações é desabilitada. Você pode perder as operações se ocorrerem discrepâncias entre os fluxos de alterações e as entradas de log de operações, pois o comportamento padrão do DMS é não concluir a tarefa nesses cenários. Padrão: `true`. | | `useOplog` | `true` `false` | Quando `true`, a tarefa do DMS pode ler diretamente do “oplog” em vez de usar o fluxo de alterações. Padrão: `false`. | Se você escolher o **Documento** como **Modo metadados**, opções diferentes estarão disponíveis. Se o endpoint de destino for DocumentDB, execute a migração no **Modo documento**. Além disso, modifique o endpoint de origem e selecione a opção **\$1id como coluna separada**. Esse será um pré-requisito obrigatório se a workload de origem do MongoDB envolver transações. ## Tipos de dados de origem do MongoDB A migração de dados que usa o MongoDB como fonte AWS DMS suporta a maioria dos tipos de dados do MongoDB. Na tabela a seguir, você pode encontrar os tipos de dados de origem do MongoDB que são suportados durante o AWS DMS uso e o mapeamento AWS DMS padrão dos tipos de dados. Para obter mais informações sobre os tipos de dados do MongoDB, consulte [ Tipos de BSON](https://docs.mongodb.com/manual/reference/bson-types) na documentação do MongoDB. Para obter informações sobre como exibir o tipo de dados mapeado no destino, consulte a seção relativa ao endpoint de destino que está usando. Para obter informações adicionais sobre AWS DMS os tipos de dados, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de dados do MongoDB | AWS DMS tipos de dados | | --- | --- | | Booleano | Bool | | Binário | BLOB | | Data | Data | | Marca de data e hora | Data | | Int | INT4 | | Longo | INT8 | | Duplo | REAL8 | | String (UTF-8) | CLOB | | Array | CLOB | | OID | String | | REGEX | CLOB | | Código | CLOB | # Usando o Amazon DocumentDB (com compatibilidade com o MongoDB) como fonte para AWS DMS Para obter informações sobre as versões do Amazon DocumentDB (compatível com MongoDB) que são compatíveis com o AWS DMS como origem, consulte [Fontes para AWS DMS](CHAP_Introduction.Sources.md). Utilizando o Amazon DocumentDB como origem, é possível migrar dados de um cluster do Amazon DocumentDB para outro cluster do Amazon DocumentDB. Você também pode migrar dados de um cluster do Amazon DocumentDB para um dos outros endpoints de destino suportados pelo. AWS DMS Se não estiver familiarizado com o Amazon DocumentDB, fique ciente dos seguintes conceitos importantes de bancos de dados do Amazon DocumentDB: + Um registro no Amazon DocumentDB é um *documento*, uma estrutura de dados composta por pares de campo e valor. O valor de um campo pode incluir outros documentos, matrizes e matrizes de documentos. Um documento é aproximadamente equivalente a uma linha em uma tabela de banco de dados relacional. + Uma *coleção* no Amazon DocumentDB é um grupo de documentos, e é aproximadamente equivalente a uma tabela de banco de dados relacional. + Um *banco de dados* no Amazon DocumentDB é um conjunto de coleções, e é aproximadamente equivalente a um esquema em um banco de dados relacional. AWS DMS suporta dois modos de migração ao usar o Amazon DocumentDB como fonte, modo documento e modo tabela. Você especifica o modo de migração ao criar o endpoint de origem do Amazon DocumentDB no AWS DMS console, usando a opção do **modo de metadados** ou o atributo de conexão extra. `nestingLevel` Veja a seguir uma explicação de como a opção do modo de migração afeta o formato resultante dos dados de destino. **Modo de documentos** No *Modo documento*, o documento JSON é migrado como está. Isso significa que os dados do documento são consolidados em um de dois itens. Ao utilizar um banco de dados relacional como destino, os dados são uma única coluna nomeada `_doc` em uma tabela de destino. Ao utilizar um banco de dados não relacional como destino, os dados são um único documento JSON. O modo documento é o modo padrão, que é recomendável ao migrar para um destino do Amazon DocumentDB. Por exemplo, considere os seguintes documentos em uma coleção do Amazon DocumentDB chamada `myCollection`. ``` db.myCollection.find() { "_id" : ObjectId("5a94815f40bd44d1b02bdfe0"), "a" : 1, "b" : 2, "c" : 3 } { "_id" : ObjectId("5a94815f40bd44d1b02bdfe1"), "a" : 4, "b" : 5, "c" : 6 } ``` Após a migração dos dados para uma tabela de banco de dados relacional usando o modo de documentos, os dados são estruturados como mostrado a seguir. Os campos de dados no documento são consolidados na coluna ` _doc`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.DocumentDB.html) Opcionalmente, é possível definir o atributo de conexão adicional `extractDocID` como `true` para criar uma segunda coluna chamada `"_id"`, que servirá como a chave primária. Se você for utilizar a captura de dados de alteração (CDC), defina esse parâmetro como `true`, exceto ao utilizar o Amazon DocumentDB como destino. Ao usar o CDC com fontes que produzem [transações com vários documentos](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), o `ExtractDocId` parâmetro **deve ser** definido como. `true` Se esse parâmetro não estiver ativado, a AWS DMS tarefa falhará quando encontrar uma transação com vários documentos. Se você adicionar uma nova coleção ao banco de dados de origem, AWS DMS cria uma nova tabela de destino para a coleção e replica todos os documentos. **Modo de tabelas** No *Modo tabela*, o AWS DMS transforma cada campo de nível superior de um documento do Amazon DocumentDB em uma coluna na tabela de destino. Se um campo estiver aninhado, AWS DMS nivela os valores aninhados em uma única coluna. AWS DMS em seguida, adiciona um campo-chave e tipos de dados ao conjunto de colunas da tabela de destino. Para cada documento do Amazon DocumentDB, AWS DMS adiciona cada chave e tipo ao conjunto de colunas da tabela de destino. Por exemplo, usando o modo tabela, AWS DMS migra o exemplo anterior para a tabela a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.DocumentDB.html) Os valores aninhados são simplificados em uma coluna que contém os nomes das chaves separados por pontos. A coluna é nomeada utilizando concatenação dos nomes dos campos simplificados, separados por pontos. Por exemplo, AWS DMS migra um documento JSON com um campo de valores aninhados, como `{"a" : {"b" : {"c": 1}}}` em uma coluna chamada `a.b.c.` Para criar as colunas de destino, AWS DMS digitaliza um número específico de documentos do Amazon DocumentDB e cria um conjunto de todos os campos e seus tipos. AWS DMS em seguida, usa esse conjunto para criar as colunas da tabela de destino. Ao criar ou modificar o endpoint de origem do Amazon DocumentDB utilizando o console, especifique o número de documentos para verificação. O valor padrão são 1.000 documentos. Se você usar o AWS CLI, poderá usar o atributo de conexão extra`docsToInvestigate`. No modo tabela, AWS DMS gerencia documentos e coleções da seguinte forma: + Ao adicionar um documento a uma coleção existente, o documento é replicado. Se houver campos que não existem no destino, esses campos não serão replicados. + Quando você atualiza um documento, o documento atualizado é replicado. Se houver campos que não existem no destino, esses campos não serão replicados. + A exclusão de documentos é totalmente compatível. + A adição de uma coleção nova não resultará na criação de uma nova tabela no destino quando feita durante uma tarefa de CDC. + Na fase Change Data Capture (CDC), AWS DMS não oferece suporte à renomeação de uma coleção. **Topics** + [Definir permissões para utilizar o Amazon DocumentDB como origem](#CHAP_Source.DocumentDB.Permissions) + [Configurar a CDC para um cluster do Amazon DocumentDB](#CHAP_Source.DocumentDB.ConfigureCDC) + [Conectar-se ao Amazon DocumentDB utilizando TLS](#CHAP_Source.DocumentDB.TLS) + [Criar um endpoint de origem do Amazon DocumentDB](#CHAP_Source.DocumentDB.ConfigureEndpoint) + [Segmentar as coleções do Amazon DocumentDB e migrar em paralelo](#CHAP_Source.DocumentDB.ParallelLoad) + [Migração de vários bancos de dados ao usar o Amazon DocumentDB como fonte para AWS DMS](#CHAP_Source.DocumentDB.Multidatabase) + [Limitações ao usar o Amazon DocumentDB como fonte para AWS DMS](#CHAP_Source.DocumentDB.Limitations) + [Utilizar configurações de endpoint com o Amazon DocumentDB como origem](#CHAP_Source.DocumentDB.ECAs) + [Tipos de dados de origem do Amazon DocumentDB](#CHAP_Source.DocumentDB.DataTypes) ## Definir permissões para utilizar o Amazon DocumentDB como origem Ao usar a fonte do Amazon DocumentDB para uma AWS DMS migração, você pode criar uma conta de usuário com privilégios de root. Ou é possível criar um usuário com permissões somente para o banco de dados a ser migrado. O código a seguir cria um usuário para ser a conta raiz. ``` use admin db.createUser( { user: "root", pwd: "password", roles: [ { role: "root", db: "admin" } ] }) ``` Para o Amazon DocumentDB 3.6, o código a seguir cria um usuário com privilégios mínimos no banco de dados a ser migrado. ``` use db_name db.createUser( { user: "dms-user", pwd: "password", roles: [{ role: "read", db: "db_name" }] } ) ``` Para o Amazon DocumentDB 4.0 e superior, AWS DMS usa um fluxo de alterações em toda a implantação. Aqui, o código a seguir cria um usuário com privilégios mínimos. ``` db.createUser( { user: "dms-user", pwd: "password", roles: [ { role: "readAnyDatabase", db: "admin" }] }) ``` ## Configurar a CDC para um cluster do Amazon DocumentDB Para usar a replicação contínua ou o CDC com o Amazon DocumentDB AWS DMS , é necessário acesso aos fluxos de alterações do cluster Amazon DocumentDB. Para obter uma descrição da sequência ordenada por tempo dos eventos de atualização nas coleções e bancos de dados do cluster, consulte [Como utilizar fluxos de alterações](https://docs.aws.amazon.com/documentdb/latest/developerguide/change_streams.html) no *Guia do desenvolvedor do Amazon DocumentDB*. Autentique-se no cluster do Amazon DocumentDB utilizando o shell do MongoDB. Execute o comando a seguir para ativar os fluxos de alterações. ``` db.adminCommand({modifyChangeStreams: 1, database: "DB_NAME", collection: "", enable: true}); ``` Essa abordagem ativa o fluxo de alterações para todas as coleções no banco de dados. Depois que os fluxos de alterações forem habilitados, você poderá criar uma tarefa de migração que migre os dados existentes e, ao mesmo tempo, replique as alterações em andamento. AWS DMS continua capturando e aplicando alterações mesmo após o carregamento dos dados em massa. Por fim, os bancos de dados de origem e de destino ficarão sincronizados, minimizando o tempo de inatividade de uma migração. **nota** AWS DMS usa o log de operações (oplog) para capturar as alterações durante a replicação contínua. Se o Amazon DocumentDB eliminar os registros do oplog antes de AWS DMS lê-los, suas tarefas falharão. É recomendável dimensionar o oplog para reter as alterações por pelo menos 24 horas. ## Conectar-se ao Amazon DocumentDB utilizando TLS Por padrão, um cluster recém-criado do Amazon DocumentDB aceita conexões seguras somente quando o Transport Layer Security (TLS) é utilizado. Quando o TLS está ativado, cada conexão ao Amazon DocumentDB requer uma chave pública. Você pode recuperar a chave pública para o Amazon DocumentDB baixando o `rds-combined-ca-bundle.pem` arquivo de AWS um bucket do Amazon S3 hospedado. Para obter mais informações sobre como baixar esse arquivo, consulte [Criptografar conexões utilizando TLS](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) no *Guia do desenvolvedor do Amazon DocumentDB.* Depois de baixar o `rds-combined-ca-bundle.pem` arquivo, você pode importar a chave pública que ele contém AWS DMS. As etapas a seguir descrevem como fazer isso. **Para importar sua chave pública usando o AWS DMS console** 1. Faça login no Console de gerenciamento da AWS e escolha AWS DMS. 1. No painel de navegação, escolha **Certificates**. 1. Escolha **Importar certificado**. A página **Importar novo certificado CA** é exibida. 1. Na seção de **Configuração de certificado**, execute uma das seguintes ações: + Para **Identificador do certificado**, insira um nome exclusivo para o certificado, por exemplo `docdb-cert`. + Selecione **Escolher arquivo**, navegue até o local onde salvou o arquivo `rds-combined-ca-bundle.pem` e selecione-o. 1. Escolha **Adicionar novo certificado CA**. O exemplo a AWS CLI seguir usa o AWS DMS `import-certificate` comando para importar o `rds-combined-ca-bundle.pem` arquivo de chave pública. ``` aws dms import-certificate \ --certificate-identifier docdb-cert \ --certificate-pem file://./rds-combined-ca-bundle.pem ``` ## Criar um endpoint de origem do Amazon DocumentDB É possível criar um endpoint de origem do Amazon DocumentDB utilizando o console ou a AWS CLI. Utilize o procedimento a seguir com o console. **Para configurar um endpoint de origem do Amazon DocumentDB usando o console AWS DMS** 1. Faça login no Console de gerenciamento da AWS e escolha AWS DMS. 1. No painel de navegação, escolha **Endpoints** e **Criar endpoint**. 1. Em **Identificador do endpoint**, forneça um nome que ajude a identificá-lo facilmente, como `docdb-source`. 1. Em **Mecanismo de origem**, escolha **Amazon DocumentDB (compatível com MongoDB)**. 1. Em **Nome do servidor**, insira o nome do servidor em que o endpoint do banco de dados Amazon DocumentDB reside. Por exemplo, é possível inserir o nome DNS público da instância do Amazon EC2, como `democluster.cluster-cjf6q8nxfefi.us-east-2.docdb.amazonaws.com`. 1. Em **Porta**, insira 27017. 1. Para **SSL mode (Modo SSL)**, escolha **verificar-full**. Se tiver desativado o SSL no cluster do Amazon DocumentDB, ignore essa etapa. 1. Em **Certificado CA**, escolha o certificado do Amazon DocumentDB, `rds-combined-ca-bundle.pem`. Para obter instruções sobre como adicionar esse certificado, consulte [Conectar-se ao Amazon DocumentDB utilizando TLS](#CHAP_Source.DocumentDB.TLS). 1. Em **Nome do banco de dados**, insira o nome do banco de dados a ser migrado. Utilize o procedimento a seguir com a CLI. **Para configurar um endpoint de origem do Amazon DocumentDB usando o AWS CLI** + Execute o AWS DMS `create-endpoint` comando a seguir para configurar um endpoint de origem do Amazon DocumentDB, substituindo os espaços reservados por seus próprios valores. ``` aws dms create-endpoint \ --endpoint-identifier a_memorable_name \ --endpoint-type source \ --engine-name docdb \ --username value \ --password value \ --server-name servername_where_database_endpoint_resides \ --port 27017 \ --database-name name_of_endpoint_database ``` ## Segmentar as coleções do Amazon DocumentDB e migrar em paralelo Para melhorar o desempenho de uma tarefa de migração, os endpoints de origem do Amazon DocumentDB são compatíveis com duas opções do recurso de carga máxima paralela no mapeamento de tabela. Em outras palavras, é possível migrar uma coleção em paralelo utilizando as opções de segmentação automática ou de segmentação de intervalo do mapeamento de tabela para uma carga máxima paralela nas configurações de JSON. As opções de segmentação automática permitem que você especifique os critérios AWS DMS para segmentar automaticamente sua fonte para migração em cada thread. As opções de segmentação de intervalo permitem que você informe AWS DMS o intervalo específico de cada segmento para o DMS migrar em cada thread. Para obter mais informações sobre essas configurações, consulte [Regras e operações de configurações de tabelas e coleções](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md). ### Migrar um banco de dados Amazon DocumentDB em paralelo utilizando intervalos de segmentação automática É possível migrar os documentos em paralelo especificando os critérios do AWS DMS para particionar (segmentar) automaticamente os dados de cada thread, especialmente o número de documentos a serem migrados por thread. Ao utilizar essa abordagem, o AWS DMS tenta otimizar os limites do segmento para obter o máximo desempenho por thread. É possível especificar os critérios de segmentação utilizando as opções de configurações de tabela a seguir no mapeamento de tabela: | Opção de configurações de tabela | Description | | --- | --- | | `"type"` | (Obrigatório) Defina o Amazon DocumentDB. como a origem do `"partitions-auto"`. | | `"number-of-partitions"` | (Opcional) Número total de partições (segmentos) utilizadas para a migração. O padrão é 16. | | `"collection-count-from-metadata"` | (Opcional) Se definido como`true`, AWS DMS usa uma contagem estimada de coleta para determinar o número de partições. Se definido como`false`, AWS DMS usa a contagem real da coleta. O padrão é `true`. | | `"max-records-skip-per-page"` | (Opcional) O número de registros a serem ignorados de uma vez ao determinar os limites de cada partição. AWS DMS usa uma abordagem de salto paginado para determinar o limite mínimo de uma partição. O padrão é 10000. A definição de um valor relativamente grande pode resultar em tempos limite do cursor e falhas na tarefa. A definição de um valor relativamente baixo resulta em mais operações por página e em uma carga máxima mais lenta. | | `"batch-size"` | (Opcional) Limita o número de documentos retornados em um lote. Cada lote requer uma viagem de ida e volta ao servidor. Se o tamanho do lote for zero (0), o cursor utilizará o tamanho máximo do lote definido pelo servidor. O padrão é 0. | O exemplo a seguir mostra um mapeamento de tabela para segmentação automática. ``` { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "admin", "table-name": "departments" }, "rule-action": "include", "filters": [] }, { "rule-type": "table-settings", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "admin", "table-name": "departments" }, "parallel-load": { "type": "partitions-auto", "number-of-partitions": 5, "collection-count-from-metadata": "true", "max-records-skip-per-page": 1000000, "batch-size": 50000 } } ] } ``` A segmentação automática tem a seguinte limitação. A migração de cada segmento busca a contagem da coleção e o `_id` mínimo da coleção separadamente. Ela utiliza um salto paginado para calcular o limite mínimo desse segmento. Portanto, verifique se o valor mínimo de `_id` de cada coleção permanece constante até que todos os limites do segmento na coleção tenham sido calculados. Se você alterar o valor de `_id` mínimo de uma coleção durante o cálculo do limite do segmento, isso poderá causar perda de dados ou erros de linha duplicada. ### Migrar um banco de dados Amazon DocumentDB em paralelo utilizando intervalos de segmentos específicos O exemplo a seguir mostra uma coleção do Amazon DocumentDB que tem sete itens e `_id` como chave primária. ![\[Coleção Amazon DocumentDB com sete itens.\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-docdb-collection.png) Para dividir a coleção em três segmentos e migrar paralelamente, é possível adicionar regras de mapeamento de tabela à tarefa de migração, conforme mostrado no exemplo de JSON a seguir. ``` { // Task table mappings: "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "testdatabase", "table-name": "testtable" }, "rule-action": "include" }, // "selection" :"rule-type" { "rule-type": "table-settings", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "testdatabase", "table-name": "testtable" }, "parallel-load": { "type": "ranges", "columns": [ "_id", "num" ], "boundaries": [ // First segment selects documents with _id less-than-or-equal-to 5f805c97873173399a278d79 // and num less-than-or-equal-to 2. [ "5f805c97873173399a278d79", "2" ], // Second segment selects documents with _id > 5f805c97873173399a278d79 and // _id less-than-or-equal-to 5f805cc5873173399a278d7c and // num > 2 and num less-than-or-equal-to 5. [ "5f805cc5873173399a278d7c", "5" ] // Third segment is implied and selects documents with _id > 5f805cc5873173399a278d7c. ] // :"boundaries" } // :"parallel-load" } // "table-settings" :"rule-type" ] // :"rules" } // :Task table mappings ``` Essa definição de mapeamento de tabela divide a coleção de origem em três segmentos e migra em paralelo. Veja a seguir os limites de segmentação. ``` Data with _id less-than-or-equal-to "5f805c97873173399a278d79" and num less-than-or-equal-to 2 (2 records) Data with _id less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5 and not in (_id less-than-or-equal-to "5f805c97873173399a278d79" and num less-than-or-equal-to 2) (3 records) Data not in (_id less-than-or-equal-to "5f805cc5873173399a278d7c" and num less-than-or-equal-to 5) (2 records) ``` Depois que a tarefa de migração for concluída, é possível verificar os logs de tarefas para saber se as tabelas foram carregadas em paralelo, conforme mostrado no exemplo a seguir. Também é possível verificar a cláusula `find` do Amazon DocumentDB utilizada para descarregar cada segmento da tabela de origem. ``` [TASK_MANAGER ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328) [SOURCE_UNLOAD ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent. [TASK_MANAGER ] I: Start loading segment #1 of 3 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. Start load timestamp 0005B191D638FE86 (replicationtask_util.c:752) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is initialized. (mongodb_unload.c:157) [SOURCE_UNLOAD ] I: Range Segmentation filter for Segment #0 is: { "_id" : { "$lte" : { "$oid" : "5f805c97873173399a278d79" } }, "num" : { "$lte" : { "$numberInt" : "2" } } } (mongodb_unload.c:328) [SOURCE_UNLOAD ] I: Unload finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 2 rows sent. [TARGET_LOAD ] I: Load finished for segment #1 of segmented table 'testdatabase'.'testtable' (Id = 1). 1 rows received. 0 rows skipped. Volume transfered 480. [TASK_MANAGER ] I: Load finished for segment #1 of table 'testdatabase'.'testtable' (Id = 1) by subtask 1. 2 records transferred. ``` Atualmente, AWS DMS oferece suporte aos seguintes tipos de dados do Amazon DocumentDB como uma coluna de chave de segmento: + Duplo + String + ObjectId + Inteiro de 32 bits + Inteiro de 64 bits ## Migração de vários bancos de dados ao usar o Amazon DocumentDB como fonte para AWS DMS AWS DMS as versões 3.4.5 e superiores oferecem suporte à migração de vários bancos de dados em uma única tarefa somente para as versões 4.0 e superiores do Amazon DocumentDB. Para migrar vários bancos de dados, faça o seguinte: 1. Ao criar o endpoint de origem do Amazon DocumentDB: + No formulário AWS DMS, Console de gerenciamento da AWS deixe o **nome do banco de dados** vazio em **Configuração do endpoint** na página **Criar endpoint**. + No AWS Command Line Interface (AWS CLI), atribua um valor de string vazio ao **DatabaseName**parâmetro no **Documento DBSettings** que você especifica para a **CreateEndpoint**ação. 1. Para cada banco de dados a ser migrado que você quer migrar desse endpoint de origem do Amazon DocumentDB, especifique o nome de cada banco de dados como o nome de um esquema no mapeamento de tabela da tarefa utilizando a entrada guiada no console ou diretamente no JSON. Para obter mais informações sobre a entrada guiada, consulte a descrição de [Especificar a seleção de tabelas e as regras de transformação no console](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md). Para obter mais informações sobre o JSON, consulte [Regras de seleção e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md). Por exemplo, é possível especificar o JSON a seguir para migrar três bancos de dados do Amazon DocumentDB. **Example Migrar todas as tabelas em um esquema** O JSON a seguir migra todas as tabelas dos bancos de dados `Customers`, `Orders` e `Suppliers` no endpoint de origem para o endpoint de destino. ``` { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "Customers", "table-name": "%" }, "object-locator": { "schema-name": "Orders", "table-name": "%" }, "object-locator": { "schema-name": "Inventory", "table-name": "%" }, "rule-action": "include" } ] } ``` ## Limitações ao usar o Amazon DocumentDB como fonte para AWS DMS A seguir estão as limitações ao usar o Amazon DocumentDB como fonte para: AWS DMS + Quando a opção `_id` está definida como uma coluna separada, a string de ID não pode exceder 200 caracteres. + As chaves de ID de objetos e de tipos de array são convertidas em colunas com o prefixo `oid` e `array` no modo de tabela. Internamente, essas colunas são referenciadas com os nomes prefixados. Se você usar regras de transformação para referenciar essas colunas, certifique-se de especificar a coluna prefixada. AWS DMS Por exemplo, especifique `${oid__id}` e não `${_id}`, ou `${array__addresses}` e não `${_addresses}`. + Os nomes de coleções e os nomes de chaves não podem conter o caractere de cifrão (\$1). + Os modos de tabelas e documentos possuem as limitações discutidas anteriormente. + A migração em paralelo que utiliza a segmentação automática possui as limitações descritas anteriormente. + Uma origem do Amazon DocumentDB (compatível com MongoDB) não é compatível com a utilização de um timestamp específico como uma posição inicial para a captura de dados de alteração (CDC). Uma tarefa de replicação contínua começa a capturar as alterações, independentemente do timestamp. + AWS DMS não oferece suporte a documentos em que o nível de aninhamento seja maior que 97 para AWS DMS versões anteriores à 3.5.2. + Filtros de origem não são compatíveis com o DocumentDB. + AWS DMS não oferece suporte à replicação CDC (captura de dados de alteração) para DocumentDB como fonte no modo de cluster elástico. ## Utilizar configurações de endpoint com o Amazon DocumentDB como origem É possível utilizar as configurações de endpoint para configurar o banco de dados Amazon DocumentDB como destino de forma semelhante à utilização de atributos de conexão adicional. 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--doc-db-settings '{"EndpointSetting": "value", ...}'` JSON. A tabela a seguir mostra as configurações de endpoint que podem ser utilizadas com o Amazon DocumentDB como origem. | Nome do atributo | Valores válidos | Valor padrão e descrição | | --- | --- | --- | | `NestingLevel` | `"none"` `"one"` | `"none"`: especifique `"none"` para utilizar o modo de documento. Especifique `"one"` para utilizar o modo de tabela. | | `ExtractDocID` | `true` `false` | `false`: utilize este atributo quando `NestingLevel` estiver definido como `"none"`. Ao usar o CDC com fontes que produzem [transações com vários documentos](https://www.mongodb.com/docs/manual/reference/method/Session.startTransaction/#mongodb-method-Session.startTransaction), o `ExtractDocId` parâmetro **deve ser** definido como. `true` Se esse parâmetro não estiver ativado, a AWS DMS tarefa falhará quando encontrar uma transação com vários documentos. | | `DocsToInvestigate` | Um inteiro positivo maior do que `0`. | `1000`: utilize este atributo quando `NestingLevel` estiver definido como `"one"`. | | `ReplicateShardCollections ` | `true` `false` | Quando verdadeiro, AWS DMS replica os dados em coleções de fragmentos. AWS DMS só usa essa configuração se o endpoint de destino for um cluster elástico DocumentDB. Quando essa configuração for verdadeira, observe o seguinte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.DocumentDB.html) | ## Tipos de dados de origem do Amazon DocumentDB Na tabela a seguir, é possível encontrar os tipos de dados de origem do Amazon DocumentDB que são compatíveis ao utilizar o AWS DMS. Você também pode encontrar o mapeamento padrão dos tipos de AWS DMS dados nesta tabela. Para obter mais informações sobre os tipos de dados, consulte [Tipos BSON](https://docs.mongodb.com/manual/reference/bson-types) na documentação do MongoDB. Para obter informações sobre como exibir o tipo de dados mapeado no destino, consulte a seção relativa ao endpoint de destino que está usando. Para obter informações adicionais sobre AWS DMS os tipos de dados, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de dados do Amazon DocumentDB | AWS DMS tipos de dados | | --- | --- | | Booleano | Bool | | Binário | BLOB | | Data | Data | | Marca de data e hora | Data | | Int | INT4 | | Longo | INT8 | | Duplo | REAL8 | | String (UTF-8) | CLOB | | Array | CLOB | | OID | String | # Usando o Amazon S3 como fonte para AWS DMS Você pode migrar dados de um bucket do Amazon S3 usando. AWS DMS Para fazer isso, conceda acesso a um bucket do Amazon S3 que contenha um ou mais arquivos de dados. Neste bucket do S3, inclua um arquivo JSON que descreve o mapeamento entre os dados e as tabelas de banco de dados referentes aos dados nesses arquivos. Os arquivos de dados de origem devem estar presentes no bucket do Amazon S3 para que a carga máxima seja iniciada. Especifique o nome do bucket utilizando o parâmetro `bucketName`. Os arquivos de dados de origem podem estar nos seguintes formatos: + Valores separados por vírgula (.csv) + Parquet (DMS versão 3.5.3 e posterior). Para ter informações sobre como usar arquivos no formato Parquet, consulte [Usando arquivos no formato Parquet no Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.Parquet). Para arquivos de dados de origem no formato de valores separados por vírgula (.csv), nomeie-os usando a seguinte convenção de nomenclatura. Nessa convenção, *`schemaName`* é o esquema de origem, e *`tableName`* é o nome de uma tabela dentro desse esquema. ``` /schemaName/tableName/LOAD001.csv /schemaName/tableName/LOAD002.csv /schemaName/tableName/LOAD003.csv ... ``` Por exemplo, suponha que os arquivos de dados estejam no `amzn-s3-demo-bucket`, no seguinte caminho do Amazon S3. ``` s3://amzn-s3-demo-bucket/hr/employee ``` No momento do carregamento, AWS DMS presume que o nome do esquema de origem seja `hr` e que o nome da tabela de origem seja. `employee` Além disso `bucketName` (o que é obrigatório), você pode, opcionalmente, fornecer um `bucketFolder` parâmetro para especificar onde AWS DMS procurar arquivos de dados no bucket do Amazon S3. Continuando com o exemplo anterior, se você `bucketFolder` definir como`sourcedata`, AWS DMS lê os arquivos de dados no caminho a seguir. ``` s3://amzn-s3-demo-bucket/sourcedata/hr/employee ``` É possível especificar o delimitador de coluna, o delimitador de linha, o indicador de valor nulo e outros parâmetros utilizando os atributos de conexão adicionais. Para obter mais informações, consulte [Configurações de endpoint para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.Configuring). É possível especificar o proprietário do bucket e evitar o corte utilizando a configuração `ExpectedBucketOwner` do endpoint do Amazon S3, conforme mostrado a seguir. Ao fazer uma solicitação para testar uma conexão ou executar uma migração, o S3 verifica o ID da conta do proprietário do bucket em relação ao parâmetro especificado. ``` --s3-settings='{"ExpectedBucketOwner": "AWS_Account_ID"}' ``` **Topics** + [Definindo tabelas externas para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.ExternalTableDef) + [Usando o CDC com o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.CDC) + [Pré-requisitos ao usar o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.Prerequisites) + [Limitações ao usar o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.Limitations) + [Configurações de endpoint para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.Configuring) + [Tipos de dados de origem do Amazon S3](#CHAP_Source.S3.DataTypes) + [Usando arquivos no formato Parquet no Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.Parquet) ## Definindo tabelas externas para o Amazon S3 como fonte para AWS DMS Além dos arquivos de dados, você também deve fornecer uma definição de tabela externa. Uma *definição de tabela externa* é um documento JSON que descreve como AWS DMS interpretar os dados do Amazon S3. O tamanho máximo deste documento é 2 MB. Se você criar um endpoint de origem usando o AWS DMS Management Console, poderá inserir o JSON diretamente na caixa de mapeamento de tabelas. Se você usar o AWS Command Line Interface (AWS CLI) ou a AWS DMS API para realizar migrações, poderá criar um arquivo JSON para especificar a definição da tabela externa. Suponha que você tem um arquivo de dados que inclui o seguinte. ``` 101,Smith,Bob,2014-06-04,New York 102,Smith,Bob,2015-10-08,Los Angeles 103,Smith,Bob,2017-03-13,Dallas 104,Smith,Bob,2017-03-13,Dallas ``` Veja a seguir um exemplo de definição de tabela externa para esses dados. ``` { "TableCount": "1", "Tables": [ { "TableName": "employee", "TablePath": "hr/employee/", "TableOwner": "hr", "TableColumns": [ { "ColumnName": "Id", "ColumnType": "INT8", "ColumnNullable": "false", "ColumnIsPk": "true" }, { "ColumnName": "LastName", "ColumnType": "STRING", "ColumnLength": "20" }, { "ColumnName": "FirstName", "ColumnType": "STRING", "ColumnLength": "30" }, { "ColumnName": "HireDate", "ColumnType": "DATETIME" }, { "ColumnName": "OfficeLocation", "ColumnType": "STRING", "ColumnLength": "20" } ], "TableColumnsTotal": "5" } ] } ``` Os elementos neste documento JSON são os seguintes: `TableCount`: o número de tabelas de origem. Neste exemplo, há somente uma tabela. `Tables`: uma matriz que consiste em um mapa JSON por tabela de origem. Neste exemplo, há somente um mapa. Cada mapa consiste nos seguintes elementos: + `TableName`: o nome da tabela de origem. + `TablePath`: o caminho no bucket do Amazon S3 em que o AWS DMS pode encontrar o arquivo de carga máxima de dados. Se um valor `bucketFolder` for especificado, esse valor será pré-associado ao caminho. + `TableOwner`: o nome do esquema desta tabela. + `TableColumns`: uma matriz de um ou mais mapas, cada um dos quais descrevendo uma coluna na tabela de origem: + `ColumnName`: o nome de uma coluna na tabela de origem. + `ColumnType`: o tipo de dados da coluna. Para tipos de dados válidos, consulte [Tipos de dados de origem do Amazon S3](#CHAP_Source.S3.DataTypes). + `ColumnLength`: o número de bytes nesta coluna. O comprimento máximo da coluna é limitado a 2147483647 bytes (2.047 MegaBytes), pois uma fonte S3 não oferece suporte ao modo FULL LOB. `ColumnLength`é válido para os seguintes tipos de dados: + BYTE + STRING + `ColumnNullable`: um valor booleano que será `true`, se esta coluna puder conter valores NULL (padrão=`false`). + `ColumnIsPk`: um valor booleano que será `true`, se esta coluna fizer parte da chave primária (padrão=`false`). + `ColumnDateFormat`: o formato de data de entrada para uma coluna com os tipos DATE, TIME e DATETIME e utilizado para analisar uma string de dados em um objeto de data. Os possíveis valores incluem: ``` - YYYY-MM-dd HH:mm:ss - YYYY-MM-dd HH:mm:ss.F - YYYY/MM/dd HH:mm:ss - YYYY/MM/dd HH:mm:ss.F - MM/dd/YYYY HH:mm:ss - MM/dd/YYYY HH:mm:ss.F - YYYYMMdd HH:mm:ss - YYYYMMdd HH:mm:ss.F ``` + `TableColumnsTotal`: o número total de colunas. Esse número deve corresponder ao número de elementos no array `TableColumns`. Se você não especificar o contrário, AWS DMS presume que `ColumnLength` seja zero. **nota** Nas versões compatíveis do AWS DMS, os dados de origem do S3 também podem conter uma coluna de operação opcional como a primeira coluna antes do valor da `TableName` coluna. Essa coluna de operação identifica a operação (`INSERT`) utilizada para migrar os dados para um endpoint de destino do S3 durante a carga máxima. Se presente, o valor dessa coluna é o caractere inicial da palavra-chave de operação `INSERT` (`I`). Se especificado, essa coluna geralmente indica que a origem do S3 foi criada pelo DMS como um destino do S3 durante uma migração anterior. Nas versões do DMS anteriores a 3.4.2, essa coluna não estava presente nos dados de origem do S3 criados em uma carga máxima do DMS anterior. Adicionar essa coluna aos dados de destino do S3 permite que o formato de todas as linhas gravadas no destino do S3 seja consistente se forem gravadas durante uma carga máxima ou durante uma carga de CDC. Para obter mais informações sobre as opções de formatação de dados de destino do S3, consulte [Indicar operações de banco de dados de origem em dados migrados do S3](CHAP_Target.S3.md#CHAP_Target.S3.Configuring.InsertOps). Para obter uma coluna do tipo NUMERIC, especifique a precisão e a escala. *Precision* é o número total de dígitos em um número, e *scale* é o número de dígitos à direita do ponto decimal. Você utiliza os elementos `ColumnPrecision` e `ColumnScale` para isso, como mostrado a seguir. ``` ... { "ColumnName": "HourlyRate", "ColumnType": "NUMERIC", "ColumnPrecision": "5" "ColumnScale": "2" } ... ``` Para uma coluna do tipo DATETIME com dados que contêm segundos fracionários, especifique a escala. A *Escala* é o número de dígitos dos segundos fracionários e pode variar de 0 a 9. Você utiliza o elemento `ColumnScale` para isso, conforme mostrado a seguir. ``` ... { "ColumnName": "HireDate", "ColumnType": "DATETIME", "ColumnScale": "3" } ... ``` Se você não especificar o contrário, AWS DMS assume que `ColumnScale` é zero e trunca os segundos fracionários. ## Usando o CDC com o Amazon S3 como fonte para AWS DMS Depois de AWS DMS realizar um carregamento completo de dados, ele pode, opcionalmente, replicar as alterações de dados no endpoint de destino. Para fazer isso, você carrega arquivos de captura de dados alterados (arquivos CDC) no seu bucket do Amazon S3. AWS DMS lê esses arquivos CDC quando você os carrega e, em seguida, aplica as alterações no endpoint de destino. Os arquivos de CDC são nomeados como segue: ``` CDC00001.csv CDC00002.csv CDC00003.csv ... ``` **nota** Para replicar com êxito os arquivos CDC na pasta de dados de alteração, faça upload em ordem léxica (sequencial). Por exemplo, carregue o arquivo CDC00002 .csv antes do CDC00003 arquivo.csv. Caso contrário, CDC00002 .csv será ignorado e não será replicado se você carregá-lo depois de .csv. CDC00003 Mas o arquivo CDC00004 .csv é replicado com sucesso se carregado após .csv. CDC00003 Para indicar onde AWS DMS encontrar os arquivos, especifique o `cdcPath` parâmetro. Continuando o exemplo anterior, se você definir `cdcPath` como `changedata`, o AWS DMS lerá os arquivos de CDC no seguinte caminho. ``` s3://amzn-s3-demo-bucket/changedata ``` Se você definir `cdcPath` como `changedata` e `bucketFolder` como `myFolder`, o AWS DMS lerá os arquivos de CDC no caminho a seguir. ``` s3://amzn-s3-demo-bucket/myFolder/changedata ``` Os registros em um arquivo de CDC são formatados da seguinte forma: + Operação: a operação de alteração a ser executada: `INSERT` ou `I`, `UPDATE` ou `U` ou `DELETE` ou `D`. Esses valores de caractere e palavras-chave não fazem distinção entre maiúsculas e minúsculas. **nota** Nas AWS DMS versões suportadas, AWS DMS pode identificar a operação a ser executada para cada registro de carga de duas maneiras. AWS DMS pode fazer isso a partir do valor da palavra-chave do registro (por exemplo,`INSERT`) ou do caractere inicial da palavra-chave (por exemplo,`I`). Nas versões anteriores, AWS DMS reconhecia a operação de carregamento somente a partir do valor completo da palavra-chave. Nas versões anteriores do AWS DMS, o valor completo da palavra-chave era gravado para registrar os dados do CDC. Além disso, as versões anteriores gravavam o valor da operação para qualquer destino do S3 utilizando apenas a inicial da palavra-chave. O reconhecimento de ambos os formatos permite AWS DMS lidar com a operação, independentemente de como a coluna de operação é gravada para criar os dados de origem do S3. Essa abordagem é compatível com a utilização de dados de destino do S3 como origem para uma migração posterior. Com essa abordagem, você não precisa alterar o formato de nenhum valor inicial de palavra-chave que aparece na coluna da operação de origem do S3 posterior. + Nome da tabela: o nome da tabela de origem. + Nome do esquema: o nome do esquema de origem. + Dados: uma ou mais colunas que representam os dados a serem alterados. Veja a seguir um exemplo de arquivo de CDC para uma tabela chamada `employee`. ``` INSERT,employee,hr,101,Smith,Bob,2014-06-04,New York UPDATE,employee,hr,101,Smith,Bob,2015-10-08,Los Angeles UPDATE,employee,hr,101,Smith,Bob,2017-03-13,Dallas DELETE,employee,hr,101,Smith,Bob,2017-03-13,Dallas ``` ## Pré-requisitos ao usar o Amazon S3 como fonte para AWS DMS Para usar o Amazon S3 como fonte AWS DMS, seu bucket S3 de origem deve estar na mesma AWS região da instância de replicação do DMS que migra seus dados. Além disso, a conta da AWS que você utiliza para a migração deve ter acesso de leitura ao bucket de origem. Para a AWS DMS versão 3.4.7 e superior, o DMS deve acessar o bucket de origem por meio de um VPC endpoint ou de uma rota pública. Para ter informações sobre os endpoints da VPC, consulte [Configurando endpoints VPC para AWS DMS](CHAP_VPC_Endpoints.md). A função AWS Identity and Access Management (IAM) atribuída à conta de usuário usada para criar a tarefa de migração deve ter o seguinte conjunto de permissões. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket*/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket*" ] } ] } ``` ------ A função AWS Identity and Access Management (IAM) atribuída à conta de usuário usada para criar a tarefa de migração deve ter o seguinte conjunto de permissões se o controle de versão estiver habilitado no bucket do Amazon S3. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket*/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket*" ] } ] } ``` ------ ## Limitações ao usar o Amazon S3 como fonte para AWS DMS As limitações a seguir se aplicam ao utilizar o Amazon S3 como origem: + Não ative o versionamento para o S3. Se o versionamento do S3 for necessário, utilize políticas de ciclo de vida para excluir ativamente as versões antigas. Caso contrário, é possível encontrar falhas na conexão de teste de endpoint devido ao tempo limite de uma chamada `list-object` do S3. Para criar uma política de ciclo de vida para um bucket do S3, consulte [Gerenciar o ciclo de vida do armazenamento](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html). Para excluir a versão de um objeto do S3, consulte [Excluir versões de objetos de um bucket com versionamento ativado](https://docs.aws.amazon.com/AmazonS3/latest/dev/DeletingObjectVersions.html). + Um bucket do S3 ativado para VPC (VPC do gateway) é compatível com as versões 3.4.7 e superiores. + O MySQL converte o tipo de dados `time` para `string`. Para ver os valores do tipo de dados `time` no MySQL, defina a coluna na tabela de destino como `string` e defina a configuração do **modo de preparação da tabela de destino** da tarefa como **Truncar**. + AWS DMS usa o tipo de `BYTE` dados internamente para dados em ambos os tipos `BYTE` de `BYTES` dados. + Os endpoints de origem do S3 não são compatíveis com o recurso de recarga de tabela do DMS. + AWS DMS não suporta o modo LOB completo com o Amazon S3 como fonte. As limitações a seguir se aplicam ao utilizar arquivos no formato Parquet no Amazon S3 como origem: + Datas nos formatos `MMYYYYDD` ou `DDMMYYYY` não são compatíveis com o recurso de particionamento de data de origem do Parquet S3. ## Configurações de endpoint para o Amazon S3 como fonte para AWS DMS É possível utilizar as configurações do endpoint para configurar o banco de dados de origem do Amazon S3 de forma semelhante à utilização de atributos de conexão adicional. 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--s3-settings '{"EndpointSetting": "value", ...}'` JSON. **nota** AWS DMS usa como padrão uma conexão segura com o endpoint do Amazon S3 sem a necessidade de especificar o modo SSL ou o certificado. A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o Amazon S3 como origem. | **Opção** | **Descrição** | | --- | --- | | BucketFolder | (Opcional) Um nome da pasta no bucket do S3. Se o atributo de origem for fornecido, os arquivos de dados de origem e os arquivos da CDC serão lidos no caminho `s3://amzn-s3-demo-bucket/bucketFolder/schemaName/tableName/` e `s3://amzn-s3-demo-bucket/bucketFolder/` respectivamente. Se esse atributo não for especificado, o caminho utilizado será `schemaName/tableName/`. `'{"BucketFolder": "sourceData"}'` | | BucketName | O nome do bucket do S3. `'{"BucketName": "amzn-s3-demo-bucket"}'` | | CdcPath | A localização dos arquivos da CDC. Esse atributo é necessário quando uma tarefa captura dados de alterações; caso contrário, ele é opcional. Se CdcPath estiver presente, AWS DMS lê os arquivos CDC desse caminho e replica as alterações de dados no endpoint de destino. Para obter mais informações, consulte [Usando o CDC com o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.CDC). `'{"CdcPath": "changeData"}'` | | CsvDelimiter | O delimitador utilizado para separar colunas nos arquivos de origem. O padrão é uma vírgula. Veja a seguir um exemplo. `'{"CsvDelimiter": ","}'` | | CsvNullValue | Uma string definida pelo usuário que é AWS DMS tratada como nula ao ler a partir da fonte. O padrão é uma string vazia. Se você não definir esse parâmetro, AWS DMS tratará uma string vazia como um valor nulo. Se você definir esse parâmetro como uma string como “\$1 N”, AWS DMS tratará essa string como o valor nulo e tratará as strings vazias como um valor de string vazio. | | CsvRowDelimiter | O delimitador utilizado para separar linhas nos arquivos de origem. O padrão é uma nova linha (`\n`). `'{"CsvRowDelimiter": "\n"}'` | | DataFormat | Defina esse valor como `Parquet` para ler dados no formato Parquet. `'{"DataFormat": "Parquet"}'` | | IgnoreHeaderRows | Quando esse valor é definido como 1, AWS DMS ignora o cabeçalho da primeira linha em um arquivo.csv. Um valor de 1 habilita o recurso, um valor de 0 desabilita o recurso. O padrão é 0. `'{"IgnoreHeaderRows": 1}'` | | Rfc4180 | Quando esse valor é definido como `true` ou `y`, as aspas duplas de abertura devem ser seguidas por aspas duplas de fechamento. Essa formatação está em conformidade com RFC 4180. Quando esse valor for definido para `false` ou `n`, os literais das strings serão copiados no destino como estão. Nesse caso, um delimitador (linha ou coluna) sinaliza o final do campo. Assim, você não poderá utilizar um delimitador como parte da string, pois ele sinalizará o final do valor. O padrão é `true`. Valores válidos: `true`, `false`, `y`, `n` `'{"Rfc4180": false}'` | ## Tipos de dados de origem do Amazon S3 Migração de dados que usa o Amazon S3 como fonte para AWS DMS necessidades de mapear dados do Amazon S3 AWS DMS para tipos de dados. Para obter mais informações, consulte [Definindo tabelas externas para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.ExternalTableDef). 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, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). Os seguintes tipos de AWS DMS dados são usados com o Amazon S3 como fonte: + BYTE: requer `ColumnLength`. Para obter mais informações, consulte [Definindo tabelas externas para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.ExternalTableDef). + DATE + TIME + DATETIME: para obter mais informações e um exemplo, consulte o exemplo do tipo DATETIME em [Definindo tabelas externas para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.ExternalTableDef). + INT1 + INT2 + INT4 + INT8 + NUMÉRICO — Requer `ColumnPrecision` e. `ColumnScale` AWS DMS suporta os seguintes valores máximos: + **ColumnPrecision: 38** + **ColumnScale: 31** Para obter mais informações e um exemplo, consulte o exemplo do tipo NUMERIC em [Definindo tabelas externas para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.ExternalTableDef). + REAL4 + REAL8 + STRING: requer `ColumnLength`. Para obter mais informações, consulte [Definindo tabelas externas para o Amazon S3 como fonte para AWS DMS](#CHAP_Source.S3.ExternalTableDef). + UINT1 + UINT2 + UINT4 + UINT8 + BLOB + CLOB + BOOLEAN ## Usando arquivos no formato Parquet no Amazon S3 como fonte para AWS DMS Na AWS DMS versão 3.5.3 e posterior, você pode usar arquivos no formato Parquet em um bucket do S3 como fonte para replicação de carga completa ou CDC. O DMS só é compatível com arquivos no formato Parquet como origem que o DMS gera ao migrar dados para um endpoint de destino do S3. Os nomes dos arquivos devem estar no formato compatível, ou o DMS não os incluirá na migração. Para arquivos de dados de origem no formato Parquet, eles devem estar na seguinte pasta e convenção de nomenclatura. ``` schema/table1/LOAD00001.parquet schema/table2/LOAD00002.parquet schema/table2/LOAD00003.parquet ``` Para arquivos de dados de origem para dados de CDC no formato Parquet, nomeie-os e armazene-os usando a seguinte pasta e convenção de nomenclatura. ``` schema/table/20230405-094615814.parquet schema/table/20230405-094615853.parquet schema/table/20230405-094615922.parquet ``` Para acessar arquivos no formato Parquet, defina as seguintes configurações de endpoint: + Defina `DataFormat` como `Parquet`. + Não defina a configuração `cdcPath`. Crie os arquivos no formato Parquet nas pastas schema/table especificadas. Para ter mais informações sobre as configurações dos endpoints do S3, consulte [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) na *Referência de API do AWS Database Migration Service *. ### Tipos de dados compatíveis com arquivos no formato Parquet AWS DMS suporta os seguintes tipos de dados de origem e destino ao migrar dados de arquivos no formato Parquet. Garanta que a tabela de destino tenha colunas dos tipos de dados corretos antes de migrar. | Tipo de dados de origem | Tipo de dados de destino | | --- | --- | | BYTE | BINARY | | DATE | DATE32 | | TIME | TIME32 | | DATETIME | TIMESTAMP | | INT1 | INT8 | | INT2 | INT16 | | INT4 | INT32 | | INT8 | INT64 | | NUMERIC | DECIMAL | | REAL4 | FLOAT | | REAL8 | DOUBLE | | STRING | STRING | | UINT1 | UINT8 | | UINT2 | UINT16 | | UINT4 | UINT32 | | UINT8 | UINT | | WSTRING | STRING | | BLOB | BINARY | | NCLOB | STRING | | CLOB | STRING | | BOOLEAN | BOOL | # Usando o banco de dados IBM Db2 para Linux, Unix, Windows e Amazon RDS (Db2 LUW) como fonte para AWS DMS Você pode migrar dados de um banco de dados IBM Db2 para Linux, Unix, Windows e Amazon RDS (Db2 LUW) para qualquer banco de dados de destino compatível usando (). AWS Database Migration Service AWS DMS Para obter informações sobre as versões do Db2 no Linux, Unix, Windows e RDS que oferecem AWS DMS suporte como fonte, consulte. [Fontes para AWS DMS](CHAP_Introduction.Sources.md) É possível utilizar SSL para criptografar conexões entre o endpoint do Db2 LUW e a instância de replicação. Para obter mais informações sobre a utilização de SSL com um endpoint do Db2 LUW, consulte [Usando SSL com AWS Database Migration Service](CHAP_Security.SSL.md). Ao AWS DMS ler dados de um banco de dados de origem do IBM Db2, ele usa o nível de isolamento padrão CURSOR STABILITY (CS) para o Db2 versão 9.7 e superior. Para ter mais informações, consulte a documentação do [IBM Db2 para Linux, do UNIX e do Windows](https://www.ibm.com/docs/en/db2/12.1.0). ## Pré-requisitos ao usar o Db2 LUW como fonte para AWS DMS Os pré-requisitos a seguir são necessários antes de utilizar um banco de dados Db2 LUW como origem. Para habilitar a replicação contínua, também chamada de captura de dados de alteração (CDC), faça o seguinte: + Defina o banco de dados para ser recuperável, o que AWS DMS requer a captura de alterações. Um banco de dados será recuperável se um ou os dois parâmetros de configuração de banco de dados `LOGARCHMETH1` e `LOGARCHMETH2` estiverem definidos como `ON`. Se seu banco de dados for recuperável, AWS DMS poderá acessar o Db2, `ARCHIVE LOG` se necessário. + Certifique-se de que os registros de DB2 transações estejam disponíveis, com um período de retenção suficiente para serem processados AWS DMS. + DB2 requer `DBADM` autorização `SYSADM` para extrair registros do registro de transações. Conceda à conta do usuário as seguintes permissões: + `SYSADM` ou `DBADM` + `DATAACCESS` **nota** Para tarefas somente de carga máxima, a conta de usuário do DMS precisa da permissão DATAACCESS. + Ao usar o IBM DB2 for LUW versão 9.7 como fonte, defina o atributo de conexão extra (ECA), da seguinte `CurrentLsn` forma: `CurrentLsn=LSN` em que `LSN` especifica um número de sequência de log (LSN) em que você deseja que a replicação seja iniciada. Ou, `CurrentLsn=scan`. + Ao usar o Amazon RDS for Db2 LUW como fonte, certifique-se de que os registros de arquivamento estejam disponíveis para o. AWS DMS Como os bancos AWS de dados DB2 gerenciados eliminam os registros de arquivamento o mais rápido possível, você deve aumentar o tempo em que os registros permanecem disponíveis. Por exemplo, para aumentar a retenção de log para 24 horas, execute o comando a seguir: ``` db2 "call rdsadmin.set_archive_log_retention( ?, 'TESTDB', '24')" ``` Para ter mais informações sobre os procedimentos do Amazon RDS para Db2 LUW, consulte [Referência de procedimentos armazenados do Amazon RDS para Db2](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/db2-stored-procedures.html) no *Guia do usuário do Amazon Relational Database Service*. + Conceda os seguintes privilégios se você usar avaliações DB2 específicas de pré-migração: ``` GRANT CONNECT ON DATABASE TO USER ; GRANT SELECT ON SYSIBM.SYSDUMMY1 TO USER ; GRANT SELECT ON SYSIBMADM.ENV_INST_INFO TO USER ; GRANT SELECT ON SYSIBMADM.DBCFG TO USER ; GRANT SELECT ON SYSCAT.SCHEMATA TO USER ; GRANT SELECT ON SYSCAT.COLUMNS TO USER ; GRANT SELECT ON SYSCAT.TABLES TO USER ; GRANT EXECUTE ON FUNCTION SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID TO ; GRANT EXECUTE ON PACKAGE NULLID.SYSSH200 TO USER ; ``` ## Limitações ao usar o Db2 LUW como fonte para AWS DMS AWS DMS não oferece suporte a bancos de dados em cluster. No entanto, é possível definir um Db2 LUW separado para cada um dos endpoints de um cluster. Por exemplo, é possível criar uma tarefa de migração de carga máxima com qualquer um dos nós no cluster e criar tarefas separadas em cada nó. AWS DMS não suporta o tipo de `BOOLEAN` dados em seu banco de dados Db2 LUW de origem. Ao utilizar a replicação contínua (CDC), aplicam-se as seguintes limitações: + Quando uma tabela com várias partições é truncada, o número de eventos DDL mostrados no AWS DMS console é igual ao número de partições. Isso ocorre porque o Db2 LUW registra um DDL separado para cada partição. + As ações de DDL a seguir não são compatíveis em tabelas particionadas: + ALTER TABLE ADD PARTITION + ALTER TABLE DETACH PARTITION + ALTER TABLE ATTACH PARTITION + AWS DMS não suporta uma migração contínua de replicação de uma instância em espera de recuperação de desastres de DB2 alta disponibilidade (HADR). O modo de espera é inacessível. + O tipo de dados DECFLOAT não é compatível. Consequentemente, alterações nas colunas DECFLOAT são ignoradas durante a replicação contínua. + A instrução RENAME COLUMN não é compatível. + Ao realizar atualizações nas tabelas de agrupamento multidimensional (MDC), cada atualização é mostrada no AWS DMS console como INSERT \$1 DELETE. + Quando a configuração da tarefa **Incluir colunas LOB na replicação** não está ativada, qualquer tabela que tenha com colunas LOB é suspensa durante a replicação contínua. + Para as versões 10.5 e superiores do Db2 LUW, as colunas de string de comprimento variável com dados armazenados são ignoradas. out-of-row Essa limitação se aplica somente a tabelas criadas com tamanho de linha estendido para colunas com tipos de dados, como VARCHAR e VARGRAPHIC. Para contornar essa limitação, mova a tabela para um espaço de tabela com um tamanho de página maior. Para obter mais informações, consulte [O que posso fazer se eu quiser alterar o tamanho da página dos espaços de DB2 tabela]( https://www.ibm.com/support/pages/what-can-i-do-if-i-want-change-pagesize-db2-tablespaces ). + Para a replicação contínua, o DMS não oferece suporte à migração de dados carregados no nível da página pelo utilitário LOAD. DB2 Em vez disso, utilize o utilitário IMPORT que utiliza inserções SQL. Para obter mais informações, consulte [diferenças entre os utilitários de importação e de carregamento]( https://www.ibm.com/docs/en/db2/11.1?topic=utilities-differences-between-import-load-utility). + Enquanto uma tarefa de replicação está em execução, o DMS captura CREATE TABLE DDLs somente se as tabelas tiverem sido criadas com o atributo DATA CAPTURE CHANGE. + O DMS apresenta as seguintes limitações ao usar o Db2 Database Partition Feature (DPF): + O DMS não pode coordenar transações entre nós do Db2 em um ambiente do DPF. Isso se deve às restrições na interface da API IBM DB2 READLOG. No DPF, as transações podem abranger vários nós do Db2, dependendo de como DB2 particiona os dados. Como resultado, sua solução DMS deve capturar transações de cada nó do Db2 de forma independente. + O DMS pode capturar transações locais de cada nó do Db2 no cluster do DPF configurando `connectNode` como `1` em vários endpoints de origem do DMS. Essa configuração corresponde aos números de nós lógicos definidos no arquivo de configuração do DB2 servidor`db2nodes.cfg`. + As transações locais em nós individuais do Db2 podem ser partes de uma transação global maior. O DMS aplica cada transação local de forma independente no destino, sem coordenação com transações em outros nós do Db2. Esse processamento independente pode levar a complicações, em especial quando as linhas são movidas entre as partições. + Quando o DMS faz replicações de vários nós do Db2, não há garantia da ordem correta das operações no destino, pois o DMS aplica as operações de forma independente para cada nó do Db2. Você deve garantir que a captura de transações locais de forma independente de cada nó do Db2 funcione para seu caso de uso específico. + Ao migrar de um ambiente do DPF, recomendamos primeiro executar uma tarefa de carga máxima sem eventos em cache e, em seguida, executar tarefas somente de CDC. Recomendamos executar uma tarefa por nó do Db2, começando pelo timestamp de início do Full Load ou pelo LRI (identificador de registro de log) definido usando o atributo de conexão extra do `StartFromContext` endpoint. Para ter informações sobre como determinar o ponto de partida da replicação, consulte [Finding the LSN or LRI value for replication start](https://www.ibm.com/support/pages/db2-finding-lsn-or-lri-value-replication-start) na *documentação de suporte do IBM*. + Para replicação contínua (CDC), se você planeja iniciar a replicação a partir de um timestamp específico, você deve definir o atributo de conexão `StartFromContext` extra para o timestamp necessário. + Atualmente, o DMS não oferece suporte ao Db2 pureScale Feature, uma extensão do DB2 LUW que você pode usar para escalar sua solução de banco de dados. + A opção `DATA CAPTURE CHANGES` de tabela é um pré-requisito crucial para os processos de replicação DB2 de dados. Deixar de ativar essa opção ao criar tabelas pode causar a perda de dados, especialmente para tarefas de replicação somente do CDC (Change Data Capture) iniciadas a partir de um ponto de partida anterior. AWS DMS habilitará esse atributo por padrão ao reiniciar uma tarefa CDC ou FULL\$1CDC. No entanto, qualquer alteração feita no banco de dados de origem antes da reinicialização da tarefa pode passar despercebida. ``` ALTER TABLE TABLE_SCHEMA.TABLE_NAME DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS; ``` ## Configurações de endpoint ao usar o Db2 LUW como fonte para AWS DMS Você pode especificar as configurações ao criar o endpoint de origem usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/create-endpoint.html), com o `--ibm-db2-settings '{"EndpointSetting1": "value1","EndpointSetting2": "value2"}'` Sintaxe JSON. A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o Db2 LUW como origem. | Nome da configuração | Description | | --- | --- | | `CurrentLsn` | Para replicação contínua (CDC), utilize `CurrentLsn` para especificar um número de sequência de log (LSN) em que você deseja que a replicação seja iniciada. | | `MaxKBytesPerRead` | Número máximo de bytes por leitura, como um valor NUMBER. O padrão é 64 KB. | | `SetDataCaptureChanges` | Habilita a replicação contínua (CDC) como um valor BOOLEAN. O padrão é true. | ## Atributos de conexão extras (ECAs) ao usar o Db2 LUW como fonte para AWS DMS Você pode especificar os Atributos de Conexão Extra (ECAs) ao criar o endpoint de origem usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/create-endpoint.html), com o `--extra-connection-attributes 'ECAname1=value1;ECAname2=value2;'` A tabela a seguir mostra o ECAs que você pode usar com o Db2 LUW como fonte. | Nome do atributo | Description | | --- | --- | | `ConnectionTimeout` | Use esse ECA para definir o tempo limite de conexão do endpoint para o endpoint Db2 LUW, em segundos. O valor de padrão é de 10 segundos. Exemplo: `ConnectionTimeout=30;` | | `executeTimeout` | Atributo de conexão extra que define o tempo limite da instrução (consulta) para o endpoint DB2 LUW, em segundos. O valor padrão é de 60 segundos. Exemplo: `executeTimeout=120;` | | `StartFromContext` | Para replicação contínua (CDC), utilize `StartFromContext` para especificar o limite inferior de um log em que iniciar a replicação. `StartFromContext` aceita diferentes formas de valores. Os valores válidos são: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.DB2.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.DB2.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.DB2.html) Para determinar o LRI/LSN intervalo de um arquivo de log, execute o `db2flsn` comando conforme mostrado no exemplo a seguir. 
db2flsn -db SAMPLE -lrirange 2
O resultado desse exemplo é semelhante ao exemplo a seguir. 

S0000002.LOG: has LRI range 00000000000000010000000000002254000000000004F9A6 to 
000000000000000100000000000022CC000000000004FB13
Nessa saída, o arquivo de log é S0000002.LOG e o valor do **StartFromContext**LRI são os 34 bytes no final do intervalo. 
0100000000000022CC000000000004FB13
| ## Tipos de dados de origem para IBM Db2 LUW A migração de dados que usa o Db2 LUW como fonte para AWS DMS suportar a maioria dos tipos de dados do Db2 LUW. A tabela a seguir mostra os tipos de dados de origem do Db2 LUW que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados. Para obter mais informações sobre os tipos de dados do Db2 LUW, consulte a [documentação do Db2 LUW](https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0008483.html). 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, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de dados do Db2 LUW | AWS DMS tipos de dados | | --- | --- | | INTEGER | INT4 | | SMALLINT | INT2 | | BIGINT | INT8 | | DECIMAL (p,s) | NUMERIC (p,s) | | FLOAT | REAL8 | | DOUBLE | REAL8 | | REAL | REAL4 | | DECFLOAT (p) | Se a precisão for 16, então REAL8; se a precisão for 34, então STRING | | GRAPHIC (n) | WSTRING, para strings de gráficos de comprimento fixo de caracteres de byte duplo com um comprimento maior que 0 e menor ou igual a 127 | | VARGRAPHIC (n) | WSTRING, para strings de gráficos de comprimento variável com um comprimento maior que 0 e menor ou igual a 16.352 caracteres de byte duplo. | | LONG VARGRAPHIC (n) | CLOB, para strings de gráficos de comprimento variável com um comprimento maior que 0 e menor ou igual a 16.352 caracteres de byte duplo. | | CHARACTER (n) | STRING, para strings de comprimento fixo de caracteres de byte duplo com um comprimento maior que 0 e menor ou igual a 255 | | VARCHAR (n) | STRING, para strings de comprimento variável de caracteres de byte duplo com um comprimento maior que 0 e menor ou igual a 32.704 | | LONG VARCHAR (n) | CLOB, para strings de comprimento variável de caracteres de byte duplo com um comprimento maior que 0 e menor ou igual a 32.704 | | CHAR (n) FOR BIT DATA | BYTES | | VARCHAR (n) FOR BIT DATA | BYTES | | LONG VARCHAR FOR BIT DATA | BYTES | | DATE | DATE | | TIME | TIME | | TIMESTAMP | DATETIME | | BLOB (n) | BLOB O comprimento máximo é 2.147.483.647 bytes | | CLOB (n) | CLOB O comprimento máximo é 2.147.483.647 bytes | | DBCLOB (n) | CLOB O comprimento máximo é 1.073.741.824 caracteres de byte duplo | | XML | CLOB | # Usando o IBM Db2 para z/OS bancos de dados como fonte para AWS DMS Você pode migrar dados de um banco de dados IBM for para qualquer z/OS banco de dados de destino suportado usando AWS Database Migration Service (AWS DMS). Para obter informações sobre as versões do Db2 z/OS que AWS DMS oferecem suporte como fonte, consulte[Fontes para AWS DMS](CHAP_Introduction.Sources.md). ## Pré-requisitos ao usar o Db2 for como fonte para z/OS AWS DMS Para usar um z/OS banco de dados IBM Db2 for como origem em AWS DMS, conceda os seguintes privilégios ao Db2 for z/OS usuário especificado nas configurações de conexão do endpoint de origem. ``` GRANT SELECT ON SYSIBM.SYSTABLES TO Db2USER; GRANT SELECT ON SYSIBM.SYSTABLESPACE TO Db2USER; GRANT SELECT ON SYSIBM.SYSTABLEPART TO Db2USER; GRANT SELECT ON SYSIBM.SYSCOLUMNS TO Db2USER; GRANT SELECT ON SYSIBM.SYSDATABASE TO Db2USER; GRANT SELECT ON SYSIBM.SYSDUMMY1 TO Db2USER ``` Também conceda SELECT ON em tabelas de origem `user defined`. Um endpoint AWS DMS IBM Db2 for z/OS source depende do IBM Data Server Driver for ODBC para acessar os dados. O servidor de banco de dados deve ter uma licença válida do IBM ODBC Connect para que o DMS se conecte a esse endpoint. ## Limitações ao usar o Db2 for z/OS como fonte para AWS DMS As seguintes limitações se aplicam ao usar um z/OS banco de dados IBM Db2 for como fonte para AWS DMS: + Somente tarefas de replicação de carga máxima são compatíveis. A captura de dados de alteração (CDC) não é compatível. + A carga paralela não é compatível. + A validação de dados das visualizações não é compatível. + Os nomes do esquema, da tabela e das colunas devem ser especificados em maiúsculas nos mapeamentos de tabela para transformações de nível e filtros de seleção em Column/table nível de linha. ## Tipos de dados de origem do IBM Db2 for z/OS As migrações de dados que usam o Db2 for z/OS como fonte de AWS DMS suporte à maioria dos tipos de dados do Db2. z/OS A tabela a seguir mostra o Db2 para tipos de dados de z/OS origem que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados. Para obter mais informações sobre o Db2 para tipos de z/OS dados, consulte a documentação do [IBM Db2](https://www.ibm.com/docs/en/db2-for-zos/12?topic=elements-data-types). z/OS 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, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Db2 para tipos z/OS de dados | AWS DMS tipos de dados | | --- | --- | | INTEGER | INT4 | | SMALLINT | INT2 | | BIGINT | INT8 | | DECIMAL (p,s) | NUMERIC (p,s) Se um ponto decimal estiver definido como uma vírgula (,) na DB2 configuração, configure Replicate para suportar a configuração. DB2 | | FLOAT | REAL8 | | DOUBLE | REAL8 | | REAL | REAL4 | | DECFLOAT (p) | Se a precisão for 16, então REAL8; se a precisão for 34, então STRING | | GRAPHIC (n) | Se n>= 127 que WSTRING, para strings de gráficos de tamanho fixo de strings de caracteres de byte duplo com um tamanho maior que 0 e menor que ou igual a 127 | | VARGRAPHIC (n) | WSTRING, para strings de gráficos de comprimento variável com um comprimento maior que 0 e menor ou igual a 16.352 caracteres de byte duplo. | | LONG VARGRAPHIC (n) | CLOB, para strings de gráficos de comprimento variável com um comprimento maior que 0 e menor ou igual a 16.352 caracteres de byte duplo. | | CHARACTER (n) | STRING, para strings de comprimento fixo de caracteres de byte duplo com um comprimento maior que 0 e menor ou igual a 255 | | VARCHAR (n) | STRING, para strings de comprimento variável de caracteres de byte duplo com um comprimento maior que 0 e menor ou igual a 32.704 | | LONG VARCHAR (n) | CLOB, para strings de comprimento variável de caracteres de byte duplo com um comprimento maior que 0 e menor ou igual a 32.704 | | CHAR (n) FOR BIT DATA | BYTES | | VARCHAR (n) FOR BIT DATA | BYTES | | LONG VARCHAR FOR BIT DATA | BYTES | | DATE | DATE | | TIME | TIME | | TIMESTAMP | DATETIME | | BLOB (n) | BLOB O comprimento máximo é 2.147.483.647 bytes | | CLOB (n) | CLOB O comprimento máximo é 2.147.483.647 bytes | | DBCLOB (n) | CLOB O comprimento máximo é 1.073.741.824 caracteres de byte duplo | | XML | CLOB | | BINARY | BYTES | | VARBINARY | BYTES | | ROWID | BYTES. Para obter mais informações sobre como trabalhar com ROWID, consulte o seguinte. | | TIMESTAMP WITH TIME ZONE | Sem compatibilidade. | As colunas ROWID são migradas por padrão quando o modo de preparação da tabela de destino para a tarefa é definido como DROP\$1AND\$1CREATE (o padrão). A validação de dados ignora essas colunas porque as linhas não têm sentido fora do banco de dados e da tabela específicos. Para desativar a migração dessas colunas, é possível executar uma das seguintes etapas preparatórias: + Pré-crie a tabela de destino sem essas colunas. Defina o modo de preparação da tabela de destino da tarefa como DO\$1NOTHING ou TRUNCATE\$1BEFORE\$1LOAD. Você pode usar AWS Schema Conversion Tool (AWS SCT) para pré-criar a tabela de destino sem as colunas. + Adicione uma regra de mapeamento de tabela a uma tarefa que filtra essas colunas para que elas sejam ignoradas. Para obter mais informações, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). ## Agrupamentos EBCDIC no PostgreSQL para serviço de modernização de mainframe AWS AWS O programa de modernização de mainframe ajuda você a modernizar seus aplicativos de mainframe para AWS ambientes de tempo de execução gerenciados. Ele fornece ferramentas e recursos para ajudar a planejar e implementar os projetos de migração e de modernização. Para obter mais informações sobre modernização e migração de mainframe, consulte Modernização de [mainframe](https://aws.amazon.com/mainframe/) com. AWS Alguns conjuntos de z/OS dados IBM Db2 são codificados no conjunto de caracteres Extended Binary Coded Decimal Interchange (EBCDIC). Esse é um conjunto de caracteres que foi desenvolvido antes do ASCII (American Standard Code for Information Interchange) se tornar comumente utilizado. Uma *página de código* mapeia cada caractere do texto para os caracteres em um conjunto de caracteres. Uma página de código tradicional contém as informações de mapeamento entre um ponto de código e um ID de caractere. Um *ID de caractere* é uma string de dados de caracteres de 8 bytes. Um *ponto de código* é um número binário de 8 bits que representa um caractere. Os pontos de código geralmente são mostrados como representações hexadecimais de seus valores binários. Se você usa atualmente a Micro Focus ou BluAge um componente do serviço de modernização de mainframe, você deve pedir AWS DMS para *mudar* (traduzir) determinados pontos de código. Você pode usar as configurações da AWS DMS tarefa para realizar os turnos. O exemplo a seguir mostra como usar a AWS DMS `CharacterSetSettings` operação para mapear os turnos em uma configuração de tarefa do DMS. ``` "CharacterSetSettings": { "CharacterSetSupport": null, "CharacterReplacements": [ {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"} } ] } ``` Já existem alguns agrupamentos de EBCDIC para o PostgreSQL que compreendem a mudança necessária. Várias páginas de código diferentes são compatíveis. As seções a seguir fornecem exemplos de JSON do que você deve mudar para todas as páginas de código compatíveis. Você pode simplesmente usar copy-and-past o JSON necessário para sua tarefa do DMS. ### Agrupamentos de EBCDIC específicos da Micro Focus Para a Micro Focus, mude um subconjunto de caracteres conforme necessário para os seguintes agrupamentos. ``` da-DK-cp1142m-x-icu de-DE-cp1141m-x-icu en-GB-cp1146m-x-icu en-US-cp1140m-x-icu es-ES-cp1145m-x-icu fi-FI-cp1143m-x-icu fr-FR-cp1147m-x-icu it-IT-cp1144m-x-icu nl-BE-cp1148m-x-icu ``` **Example Mudanças de dados da Micro Focus por agrupamento:** **en\$1us\$1cp1140m** Mudança de código: ``` 0000 0180 00A6 0160 00B8 0161 00BC 017D 00BD 017E 00BE 0152 00A8 0153 00B4 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1141m** Mudança de código: ``` 0000 0180 00B8 0160 00BC 0161 00BD 017D 00BE 017E 00A8 0152 00B4 0153 00A6 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1142m** Mudança de código: ``` 0000 0180 00A6 0160 00B8 0161 00BC 017D 00BD 017E 00BE 0152 00A8 0153 00B4 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1143m** Mudança de código: ``` 0000 0180 00B8 0160 00BC 0161 00BD 017D 00BE 017E 00A8 0152 00B4 0153 00A6 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1144m** Mudança de código: ``` 0000 0180 00B8 0160 00BC 0161 00BD 017D 00BE 017E 00A8 0152 00B4 0153 00A6 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1145m** Mudança de código: ``` 0000 0180 00A6 0160 00B8 0161 00A8 017D 00BC 017E 00BD 0152 00BE 0153 00B4 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1146m** Mudança de código: ``` 0000 0180 00A6 0160 00B8 0161 00BC 017D 00BD 017E 00BE 0152 00A8 0153 00B4 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1147m** Mudança de código: ``` 0000 0180 00B8 0160 00A8 0161 00BC 017D 00BD 017E 00BE 0152 00B4 0153 00A6 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0178"} ``` **en\$1us\$1cp1148m** Mudança de código: ``` 0000 0180 00A6 0160 00B8 0161 00BC 017D 00BD 017E 00BE 0152 00A8 0153 00B4 0178 ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0000","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "00A6","TargetCharacterCodePoint": "0160"} ,{"SourceCharacterCodePoint": "00B8","TargetCharacterCodePoint": "0161"} ,{"SourceCharacterCodePoint": "00BC","TargetCharacterCodePoint": "017D"} ,{"SourceCharacterCodePoint": "00BD","TargetCharacterCodePoint": "017E"} ,{"SourceCharacterCodePoint": "00BE","TargetCharacterCodePoint": "0152"} ,{"SourceCharacterCodePoint": "00A8","TargetCharacterCodePoint": "0153"} ,{"SourceCharacterCodePoint": "00B4","TargetCharacterCodePoint": "0178"} ``` ### BluAge agrupamentos específicos do EBCDIC Para BluAge, altere todos os *valores baixos* e *altos* a seguir, conforme necessário. Esses agrupamentos só devem ser usados para oferecer suporte ao serviço de migração de mainframe. BluAge ``` da-DK-cp1142b-x-icu da-DK-cp277b-x-icu de-DE-cp1141b-x-icu de-DE-cp273b-x-icu en-GB-cp1146b-x-icu en-GB-cp285b-x-icu en-US-cp037b-x-icu en-US-cp1140b-x-icu es-ES-cp1145b-x-icu es-ES-cp284b-x-icu fi-FI-cp1143b-x-icu fi-FI-cp278b-x-icu fr-FR-cp1147b-x-icu fr-FR-cp297b-x-icu it-IT-cp1144b-x-icu it-IT-cp280b-x-icu nl-BE-cp1148b-x-icu nl-BE-cp500b-x-icu ``` **Example BluAge Mudanças de dados:** **da-DK-cp277b** e **da-DK-cp1142b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **de-DE-273b** e **de-DE-1141b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **en-GB-285b** e **en-GB-1146b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **en-us-037b** e **en-us-1140b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **es-ES-284b** e **es-ES-1145b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **fi\$1FI-278b** e **fi-FI-1143b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **fr-FR-297b** e**fr-FR-1147b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **it-IT-280b** e **it-IT-1144b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ``` **nl-BE-500b** e **nl-BE-1148b** Mudança de código: ``` 0180 0180 0001 0181 0002 0182 0003 0183 009C 0184 0009 0185 0086 0186 007F 0187 0097 0188 008D 0189 008E 018A 000B 018B 000C 018C 000D 018D 000E 018E 000F 018F 0010 0190 0011 0191 0012 0192 0013 0193 009D 0194 0085 0195 0008 0196 0087 0197 0018 0198 0019 0199 0092 019A 008F 019B 001C 019C 001D 019D 001E 019E 001F 019F 0080 01A0 0081 01A1 0082 01A2 0083 01A3 0084 01A4 000A 01A5 0017 01A6 001B 01A7 0088 01A8 0089 01A9 008A 01AA 008B 01AB 008C 01AC 0005 01AD 0006 01AE 0007 01AF 0090 01B0 0091 01B1 0016 01B2 0093 01B3 0094 01B4 0095 01B5 0096 01B6 0004 01B7 0098 01B8 0099 01B9 009A 01BA 009B 01BB 0014 01BC 0015 01BD 009E 01BE 001A 01BF 009F 027F ``` Mapeamento de entrada correspondente para uma AWS DMS tarefa: ``` {"SourceCharacterCodePoint": "0180","TargetCharacterCodePoint": "0180"} ,{"SourceCharacterCodePoint": "0001","TargetCharacterCodePoint": "0181"} ,{"SourceCharacterCodePoint": "0002","TargetCharacterCodePoint": "0182"} ,{"SourceCharacterCodePoint": "0003","TargetCharacterCodePoint": "0183"} ,{"SourceCharacterCodePoint": "009C","TargetCharacterCodePoint": "0184"} ,{"SourceCharacterCodePoint": "0009","TargetCharacterCodePoint": "0185"} ,{"SourceCharacterCodePoint": "0086","TargetCharacterCodePoint": "0186"} ,{"SourceCharacterCodePoint": "007F","TargetCharacterCodePoint": "0187"} ,{"SourceCharacterCodePoint": "0097","TargetCharacterCodePoint": "0188"} ,{"SourceCharacterCodePoint": "008D","TargetCharacterCodePoint": "0189"} ,{"SourceCharacterCodePoint": "008E","TargetCharacterCodePoint": "018A"} ,{"SourceCharacterCodePoint": "000B","TargetCharacterCodePoint": "018B"} ,{"SourceCharacterCodePoint": "000C","TargetCharacterCodePoint": "018C"} ,{"SourceCharacterCodePoint": "000D","TargetCharacterCodePoint": "018D"} ,{"SourceCharacterCodePoint": "000E","TargetCharacterCodePoint": "018E"} ,{"SourceCharacterCodePoint": "000F","TargetCharacterCodePoint": "018F"} ,{"SourceCharacterCodePoint": "0010","TargetCharacterCodePoint": "0190"} ,{"SourceCharacterCodePoint": "0011","TargetCharacterCodePoint": "0191"} ,{"SourceCharacterCodePoint": "0012","TargetCharacterCodePoint": "0192"} ,{"SourceCharacterCodePoint": "0013","TargetCharacterCodePoint": "0193"} ,{"SourceCharacterCodePoint": "009D","TargetCharacterCodePoint": "0194"} ,{"SourceCharacterCodePoint": "0085","TargetCharacterCodePoint": "0195"} ,{"SourceCharacterCodePoint": "0008","TargetCharacterCodePoint": "0196"} ,{"SourceCharacterCodePoint": "0087","TargetCharacterCodePoint": "0197"} ,{"SourceCharacterCodePoint": "0018","TargetCharacterCodePoint": "0198"} ,{"SourceCharacterCodePoint": "0019","TargetCharacterCodePoint": "0199"} ,{"SourceCharacterCodePoint": "0092","TargetCharacterCodePoint": "019A"} ,{"SourceCharacterCodePoint": "008F","TargetCharacterCodePoint": "019B"} ,{"SourceCharacterCodePoint": "001C","TargetCharacterCodePoint": "019C"} ,{"SourceCharacterCodePoint": "001D","TargetCharacterCodePoint": "019D"} ,{"SourceCharacterCodePoint": "001E","TargetCharacterCodePoint": "019E"} ,{"SourceCharacterCodePoint": "001F","TargetCharacterCodePoint": "019F"} ,{"SourceCharacterCodePoint": "0080","TargetCharacterCodePoint": "01A0"} ,{"SourceCharacterCodePoint": "0081","TargetCharacterCodePoint": "01A1"} ,{"SourceCharacterCodePoint": "0082","TargetCharacterCodePoint": "01A2"} ,{"SourceCharacterCodePoint": "0083","TargetCharacterCodePoint": "01A3"} ,{"SourceCharacterCodePoint": "0084","TargetCharacterCodePoint": "01A4"} ,{"SourceCharacterCodePoint": "000A","TargetCharacterCodePoint": "01A5"} ,{"SourceCharacterCodePoint": "0017","TargetCharacterCodePoint": "01A6"} ,{"SourceCharacterCodePoint": "001B","TargetCharacterCodePoint": "01A7"} ,{"SourceCharacterCodePoint": "0088","TargetCharacterCodePoint": "01A8"} ,{"SourceCharacterCodePoint": "0089","TargetCharacterCodePoint": "01A9"} ,{"SourceCharacterCodePoint": "008A","TargetCharacterCodePoint": "01AA"} ,{"SourceCharacterCodePoint": "008B","TargetCharacterCodePoint": "01AB"} ,{"SourceCharacterCodePoint": "008C","TargetCharacterCodePoint": "01AC"} ,{"SourceCharacterCodePoint": "0005","TargetCharacterCodePoint": "01AD"} ,{"SourceCharacterCodePoint": "0006","TargetCharacterCodePoint": "01AE"} ,{"SourceCharacterCodePoint": "0007","TargetCharacterCodePoint": "01AF"} ,{"SourceCharacterCodePoint": "0090","TargetCharacterCodePoint": "01B0"} ,{"SourceCharacterCodePoint": "0091","TargetCharacterCodePoint": "01B1"} ,{"SourceCharacterCodePoint": "0016","TargetCharacterCodePoint": "01B2"} ,{"SourceCharacterCodePoint": "0093","TargetCharacterCodePoint": "01B3"} ,{"SourceCharacterCodePoint": "0094","TargetCharacterCodePoint": "01B4"} ,{"SourceCharacterCodePoint": "0095","TargetCharacterCodePoint": "01B5"} ,{"SourceCharacterCodePoint": "0096","TargetCharacterCodePoint": "01B6"} ,{"SourceCharacterCodePoint": "0004","TargetCharacterCodePoint": "01B7"} ,{"SourceCharacterCodePoint": "0098","TargetCharacterCodePoint": "01B8"} ,{"SourceCharacterCodePoint": "0099","TargetCharacterCodePoint": "01B9"} ,{"SourceCharacterCodePoint": "009A","TargetCharacterCodePoint": "01BA"} ,{"SourceCharacterCodePoint": "009B","TargetCharacterCodePoint": "01BB"} ,{"SourceCharacterCodePoint": "0014","TargetCharacterCodePoint": "01BC"} ,{"SourceCharacterCodePoint": "0015","TargetCharacterCodePoint": "01BD"} ,{"SourceCharacterCodePoint": "009E","TargetCharacterCodePoint": "01BE"} ,{"SourceCharacterCodePoint": "001A","TargetCharacterCodePoint": "01BF"} ,{"SourceCharacterCodePoint": "009F","TargetCharacterCodePoint": "027F"} ```