As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Utilizar o mapeamento de tabela para especificar as configurações da tarefa
O mapeamento de tabela utiliza vários tipos de regras para especificar a fonte de dados, o esquema de origem, os dados e todas transformações que devem ocorrer durante a tarefa. É possível utilizar o mapeamento de tabela para especificar as tabelas individuais em um banco de dados a serem migradas e o esquema a ser utilizado na migração.
Ao trabalhar com mapeamento de tabela, é possível utilizar filtros para especificar os dados que deseja replicar de colunas de tabela. Além disso, é possível utilizar transformações para modificar esquemas, tabelas ou visualizações selecionadas antes que sejam gravadas no banco de dados de destino.
**Topics**
+ [
# Especificar a seleção de tabelas e as regras de transformação no console
](CHAP_Tasks.CustomizingTasks.TableMapping.Console.md)
+ [
# Especificar a seleção de tabelas e as regras de transformação utilizando JSON
](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.md)
+ [
# Regras de seleção e ações
](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md)
+ [
# Curingas no mapeamento de tabela
](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Wildcards.md)
+ [
# Regras de transformação e ações
](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md)
+ [
# Utilizar expressões de regra de transformação para definir o conteúdo da coluna
](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions.md)
+ [
# Regras e operações de configurações de tabelas e coleções
](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md)
+ [
# Usar mascaramento de dados para ocultar informações sensíveis
](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Masking.md)
**nota**
Ao trabalhar com mapeamento de tabela para um endpoint de origem do MongoDB, é possível utilizar filtros para especificar os dados que deseja replicar e especificar um nome de banco de dados no lugar do `schema_name`. Ou, é possível utilizar o valor padrão `"%"`.
# Especificar a seleção de tabelas e as regras de transformação no console
Você pode usar o Console de gerenciamento da AWS para realizar o mapeamento da tabela, incluindo a especificação da seleção e das transformações da tabela. No console, utilize a seção **Onde** para especificar o esquema, a tabela e a ação (incluir ou excluir). Utilize a seção **Filtrar** para especificar o nome da coluna em uma tabela e as condições que você deseja aplicar a uma tarefa de replicação. Juntas, essas duas ações criam uma regra de seleção.
As transformações podem ser incluídas no mapeamento de tabela após você especificar pelo menos uma regra de seleção. As transformações podem ser usadas para renomear um esquema ou uma tabela, adicionar um prefixo ou sufixo a um esquema ou uma tabela ou remover a coluna de uma tabela.
**nota**
AWS DMS não oferece suporte a mais de uma regra de transformação por nível de esquema, nível de tabela ou nível de coluna.
O procedimento a seguir mostra como configurar regras de seleção com base em uma tabela chamada **Customers** em um esquema chamado **EntertainmentAgencySample**.
**Como especificar uma seleção de tabela, critérios de filtro e transformações utilizando o console**
1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
Se estiver conectado como usuário do IAM, verifique se você tem as permissões necessárias para acessar o AWS DMS. Para obter mais informações sobre as permissões necessárias, consulte [Permissões do IAM necessárias para usar AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Na página **Painel**, escolha **Tarefas de migração de banco de dados**.
1. Escolha **Create Task**.
1. Na seção **Configuração da tarefa**, insira as informações da tarefa, incluindo o **Identificador da tarefa**, a **Instância de replicação**, o **Endpoint do banco de dados de origem**, o **Endpoint do banco de dados de destino** e o **Tipo de migração**.
![\[Seleção de esquema e tabela\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-create-task-20.png)
1. Na seção **Mapeamento de tabela**, insira o nome do esquema ou o nome da tabela. É possível utilizar "%" como um valor curinga ao especificar o nome do esquema ou o nome da tabela. Para obter informações sobre outros curingas que é possível utilizar, consulte [Curingas no mapeamento de tabela](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Wildcards.md). Especifique a ação a ser executada para incluir ou excluir os dados definidos pelo filtro.
![\[Seleção de esquema e tabela\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-Tasks-selecttransfrm.png)
1. Especifique as informações de filtro utilizando os links **Add column filter (Adicionar filtro de coluna)** e **Add condition (Adicionar condição)**.
1. Selecione **Add column filter (Adicionar filtro de coluna)** para especificar uma coluna e as condições.
1. Selecione **Adicionar condition (Adicionar condição)** para adicionar mais condições.
O exemplo a seguir mostra um filtro para a tabela **Customers** que inclui **AgencyIDs** entre **01** e **85**.
![\[Seleção de esquema e tabela\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-Tasks-filter.png)
1. Quando tiver criado as seleções desejadas, selecione **Adicionar nova regra de seleção**.
1. Depois de criar pelo menos uma regra de seleção, é possível adicionar uma transformação à tarefa. Selecione **Add transformation rule (Adicionar regra de transformação)**.
![\[regra de transformação\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-Tasks-transform1.png)
1. Selecione o destino que deseja transformar e insira as informações adicionais solicitadas. O exemplo a seguir mostra uma transformação que exclui a coluna **AgencyStatus** da tabela **Customer**.
![\[regra de transformação\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-Tasks-transform2.png)
1. Selecione **Add transformation rule**.
1. Escolha **Criar tarefa**.
**nota**
AWS DMS não oferece suporte a mais de uma regra de transformação por nível de esquema, nível de tabela ou nível de coluna.
# Especificar a seleção de tabelas e as regras de transformação utilizando JSON
Para especificar os mapeamentos de tabela que deseja aplicar durante a migração, é possível criar um arquivo JSON. Se você criar uma tarefa de migração utilizando o console, poderá procurar esse arquivo JSON ou inserir o JSON diretamente na caixa de mapeamento de tabela. Se utilizar a CLI ou a API para executar migrações, é possível especificar esse arquivo utilizando o parâmetro `TableMappings` da operação de API `CreateReplicationTask` ou `ModifyReplicationTask`.
AWS DMS só pode processar arquivos JSON de mapeamento de tabelas de até 2 MB. É recomendável manter o tamanho do arquivo JSON da regra de mapeamento abaixo do limite de 2 MB ao trabalhar com tarefas do DMS. Isso evita erros inesperados durante a criação ou a modificação da tarefa. Quando um arquivo de regra de mapeamento excede o limite de 2 MB, é recomendável dividir as tabelas em várias tarefas para reduzir o tamanho do arquivo de regras de mapeamento para que ele permaneça abaixo desse limite.
É possível especificar com quais tabelas, visualizações e esquemas você deseja trabalhar. Também é possível executar transformações de tabela, visualização e esquema e especificar configurações de como o AWS DMS carrega tabelas e visualizações individuais. Crie regras de mapeamento de tabela para essas opções utilizando os seguintes tipos de regra:
+ Regras de `selection`: identificam os tipos e nomes das tabelas de origem, visualizações e esquemas a serem carregados. Para obter mais informações, consulte [Regras de seleção e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md).
+ Regras de `transformation`: especificam determinadas alterações ou adições a tabelas de origem e esquemas específicos na origem antes de serem carregados no destino. Para obter mais informações, consulte [Regras de transformação e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
Além disso, para definir o conteúdo de colunas novas e existentes, é possível utilizar uma expressão em uma regra de transformação. Para obter mais informações, consulte [Utilizar expressões de regra de transformação para definir o conteúdo da coluna](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions.md).
+ Regras de `table-settings`: especificam como as tarefas do DMS carregam os dados de tabelas individuais. Para obter mais informações, consulte [Regras e operações de configurações de tabelas e coleções](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md).
**nota**
Para destinos do Amazon S3, também é possível marcar objetos do S3 mapeados para tabelas e esquemas selecionados utilizando o tipo de regra `post-processing` e a ação da regra `add-tag`. Para obter mais informações, consulte [Marcação de objetos do Amazon S3](CHAP_Target.S3.md#CHAP_Target.S3.Tagging).
Para os destinos a seguir, é possível especificar como e onde os esquemas e tabelas selecionados são migrados para o destino utilizando o tipo de regra `object-mapping`:
Amazon DynamoDB: para obter mais informações, consulte [Utilizar o mapeamento de objetos para migrar dados para o DynamoDB](CHAP_Target.DynamoDB.md#CHAP_Target.DynamoDB.ObjectMapping).
Amazon Kinesis: para obter mais informações, consulte [Utilizar o mapeamento de objetos para migrar dados para um fluxo de dados do Kinesis](CHAP_Target.Kinesis.md#CHAP_Target.Kinesis.ObjectMapping).
Apache Kafka: para obter mais informações, consulte [Utilizar o mapeamento de objetos para migrar dados para um tópico do Kafka](CHAP_Target.Kafka.md#CHAP_Target.Kafka.ObjectMapping).
# Regras de seleção e ações
Usando o mapeamento de tabela, é possível especificar as tabelas, as exibições e os esquemas com os quais deseja trabalhar utilizando ações e regras de seleção. Os seguintes valores podem ser aplicados a regras de mapeamento de tabela que utilizam o tipo de regra de seleção.
**Atenção**
Não inclua dados confidenciais nessas regras.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.html)
**Example Migrar todas as tabelas em um esquema**
O exemplo a seguir migra todas as tabelas de um esquema chamado `Test` da origem para o endpoint de destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
}
]
}
```
**Example Migrar algumas tabelas em um esquema**
O exemplo a seguir migra todas as tabelas, exceto as que começam com `DMS`, de um esquema chamado `Test` na origem para o endpoint de destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "Test",
"table-name": "DMS%"
},
"rule-action": "exclude"
}
]
}
```
**Example Migrar uma única tabela especificada em um único esquema**
O exemplo a seguir migra a tabela `Customer` do esquema `NewCust` na origem para o endpoint de destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "NewCust",
"table-name": "Customer"
},
"rule-action": "explicit"
}
]
}
```
É possível selecionar explicitamente várias tabelas e esquemas especificando várias regras de seleção.
**Example Migrar tabelas em uma ordem definida**
As tabelas e visualizações são migradas de acordo com os respectivos valores de ordem de carregamento, e os valores mais altos têm prioridade na sequência da migração. O exemplo a seguir migra duas tabelas, `loadfirst` com um valor de prioridade 2 e `loadsecond` com um valor de prioridade 1. A tarefa de migração primeiro processa a tabela `loadfirst` para prosseguir para a tabela `loadsecond`. Esse mecanismo de priorização garante que as dependências entre os objetos do banco de dados sejam respeitadas durante o processo da migração.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "loadsecond"
},
"rule-action": "include",
"load-order": "1"
},
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "Test",
"table-name": "loadfirst"
},
"rule-action": "include",
"load-order": "2"
}
]
}
```
**nota**
`load-order` é aplicável à inicialização da tabela. A carga de uma tabela sucessiva não aguardará a conclusão de uma carga de tabela anterior se `MaxFullLoadSubTasks` for maior que 1.
**Example Migrar algumas exibições em um esquema**
O exemplo a seguir migra algumas exibições de um esquema chamado `Test` na origem para tabelas equivalentes no destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "Test",
"table-name": "view_DMS%",
"table-type": "view"
},
"rule-action": "include"
}
]
}
```
**Example Migrar todas as tabelas e exibições em um esquema**
O exemplo a seguir migra todas as tabelas e exibições de um esquema chamado `report` na origem para tabelas equivalentes no destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "3",
"rule-name": "3",
"object-locator": {
"schema-name": "report",
"table-name": "%",
"table-type": "all"
},
"rule-action": "include"
}
]
}
```
# Curingas no mapeamento de tabela
Esta seção descreve os curingas que é possível utilizar ao especificar o esquema e os nomes das tabelas para o mapeamento de tabela.
| Curinga | Correspondências |
| --- |--- |
| % | Zero ou mais caracteres |
| \$1 | Um único caractere |
| [\$1] | Um caractere de sublinhado literal |
| [ab] | Um conjunto de caracteres. Por exemplo, [ab] corresponde a 'a' ou 'b'. |
| [a-d] | Uma variedade de personagens. Por exemplo, [a-d] corresponde a 'a', 'b', 'c' ou 'd'. |
Para endpoints de origem e de destino do Oracle, é possível utilizar o atributo de conexão adicional `escapeCharacter` para especificar um caractere de escape. Um caractere de escape permite que você utilize um caractere curinga especificado em expressões como se não fosse curinga. Por exemplo, `escapeCharacter=#` permite que você utilize '\$1' para fazer com que um caractere curinga atue como um caractere comum em uma expressão, como neste código de exemplo.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "542485267",
"rule-name": "542485267",
"object-locator": { "schema-name": "ROOT", "table-name": "TEST#_T%" },
"rule-action": "include",
"filters": []
}
]
}
```
Aqui, o caractere de escape '\$1' faz com que o caractere curinga '\$1' atue como um caractere normal. AWS DMS seleciona tabelas no esquema chamado`ROOT`, em que cada tabela tem um nome com seu `TEST_T` prefixo.
# Regras de transformação e ações
As ações de transformação são utilizadas para especificar as transformações que você deseja aplicar ao esquema, à tabela ou à visualização selecionada. As regras da transformação são opcionais.
## Limitações
+ Não é possível aplicar mais de uma ação de regra de transformação ao mesmo objeto (esquema, tabela, coluna, espaço para tabela ou espaço para tabela de índice). É possível aplicar várias ações de regra de transformação em qualquer nível, desde que cada ação de transformação seja aplicada em um objeto diferente. No entanto, essa restrição não é válida ao usar regras de transformação de mascaramento de dados, nas quais você pode ter outra transformação, como `ADD-COLUMN` ou `CHANGE-DATA-TYPE`, para a mesma coluna.
+ Os nomes de tabelas e de colunas nas regras de transformação diferenciam maiúsculas de minúsculas. Por exemplo, você deve fornecer nomes de tabelas e nomes de colunas para um banco de dados Oracle ou Db2 em letras maiúsculas.
+ As transformações não são suportadas para nomes de colunas com Right-to-Left idiomas.
+ As transformações não podem ser executadas em colunas que contenham caracteres especiais (por exemplo, \$1, \$1, /, -) em seu nome.
+ A única transformação suportada para colunas mapeadas para tipos de BLOB/CLOB dados é soltar a coluna no destino.
+ AWS DMS não oferece suporte à replicação de duas tabelas de origem em uma única tabela de destino. AWS DMS replica registros de tabela em tabela e de coluna em coluna, de acordo com as regras de transformação da tarefa de replicação. Os nomes dos objetos devem ser exclusivos para evitar sobreposição.
Por exemplo, uma tabela de origem tem uma coluna chamada `ID` e a tabela de destino correspondente tem uma coluna preexistente chamada `id`. Se uma regra usa uma `ADD-COLUMN` instrução para adicionar uma nova coluna chamada `id` e uma SQLite instrução para preencher a coluna com valores personalizados, isso cria um objeto duplicado e ambíguo chamado `id` e não é suportado.
+ Ao criar uma regra de transformação, recomendamos usar o parâmetro `data-type` somente quando as regras de seleção especificarem várias colunas, por exemplo, quando você define `column-name` como `%`. Não recomendamos usar `data-type` para selecionar uma única coluna.
+ AWS DMS não oferece suporte a regras de transformação em que objetos de origem e destino (tabelas) estejam no mesmo banco de dados/esquema. Usar a mesma tabela como origem e destino em uma regra de transformação pode gerar resultados inesperados e possivelmente prejudiciais, como, entre outros, alterações indesejadas nos dados da tabela, modificação da estrutura das tabelas ou até mesmo a eliminação de tabelas.
## Valores
Os seguintes valores podem ser aplicados a regras de mapeamento de tabela que utilizam o tipo de regra de transformação
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.html)
## Exemplos
**Example Renomear um esquema**
O exemplo a seguir renomeia um esquema de `Test` na origem para `Test1` no destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "rename",
"rule-target": "schema",
"object-locator": {
"schema-name": "Test"
},
"value": "Test1"
}
]
}
```
**Example Renomeação de uma tabela**
O exemplo a seguir renomeia uma tabela de `Actor` na origem para `Actor1` no destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "rename",
"rule-target": "table",
"object-locator": {
"schema-name": "Test",
"table-name": "Actor"
},
"value": "Actor1"
}
]
}
```
**Example Renomeação de uma coluna**
O exemplo a seguir renomeia uma coluna na tabela `Actor` de `first_name` na origem para `fname` no destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "4",
"rule-name": "4",
"rule-action": "rename",
"rule-target": "column",
"object-locator": {
"schema-name": "test",
"table-name": "Actor",
"column-name" : "first_name"
},
"value": "fname"
}
]
}
```
**Example Renomear um espaço de tabela da tabela do Oracle**
O exemplo a seguir renomeia o espaço de tabela denominado `SetSpace` para uma tabela denominada `Actor` na origem do Oracle para `SceneTblSpace` no endpoint de destino do Oracle.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Play",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "rename",
"rule-target": "table-tablespace",
"object-locator": {
"schema-name": "Play",
"table-name": "Actor",
"table-tablespace-name": "SetSpace"
},
"value": "SceneTblSpace"
}
]
}
```
**Example Renomear um espaço de tabela de índice do Oracle**
O exemplo a seguir renomeia o espaço de tabela de índice denominado `SetISpace` para uma tabela denominada `Actor` na origem do Oracle para `SceneIdxSpace` no endpoint de destino do Oracle.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Play",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "rename",
"rule-target": "table-tablespace",
"object-locator": {
"schema-name": "Play",
"table-name": "Actor",
"table-tablespace-name": "SetISpace"
},
"value": "SceneIdxSpace"
}
]
}
```
**Example Adicionar uma coluna**
O exemplo a seguir adiciona uma coluna `datetime` à tabela `Actor` no esquema `test`.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "test",
"table-name": "actor"
},
"value": "last_updated",
"data-type": {
"type": "datetime",
"precision": 6
}
}
]
}
```
**Example Remover uma coluna**
O exemplo a seguir transforma a tabela `Actor` na origem para remover todas as colunas que começam com os caracteres `col` no destino.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "remove-column",
"rule-target": "column",
"object-locator": {
"schema-name": "test",
"table-name": "Actor",
"column-name": "col%"
}
}]
}
```
**Example Converter para minúsculas**
O exemplo a seguir converte o nome de uma tabela de `ACTOR` na origem em `actor` no destino.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "convert-lowercase",
"rule-target": "table",
"object-locator": {
"schema-name": "test",
"table-name": "ACTOR"
}
}]
}
```
**Example Converter em maiúsculas**
O exemplo a seguir converte todas as colunas em todas as tabelas e todos os esquemas de minúsculas, na origem, para maiúsculas, no destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "convert-uppercase",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%",
"column-name": "%"
}
}
]
}
```
**Example Adicionar um prefixo**
O exemplo a seguir transforma todas as tabelas na origem para adicionar o prefixo `DMS_` a elas no destino.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-prefix",
"rule-target": "table",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"value": "DMS_"
}]
}
```
**Example Substituir um prefixo**
O exemplo a seguir transforma todas as colunas contendo o prefixo `Pre_` na origem para substituí-lo por `NewPre_` no destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "replace-prefix",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%",
"column-name": "%"
},
"value": "NewPre_",
"old-value": "Pre_"
}
]
}
```
**Example Remover um sufixo**
O exemplo a seguir transforma todas as tabelas na origem para remover o sufixo `_DMS` delas no destino.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "remove-suffix",
"rule-target": "table",
"object-locator": {
"schema-name": "test",
"table-name": "%"
},
"value": "_DMS"
}]
}
```
**Example Definir uma chave primária**
O exemplo a seguir define uma chave primária denominada `ITEM-primary-key` em três colunas da tabela `ITEM` migradas para o endpoint de destino.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "inventory",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "define-primary-key",
"rule-target": "table",
"object-locator": {
"schema-name": "inventory",
"table-name": "ITEM"
},
"primary-key-def": {
"name": "ITEM-primary-key",
"columns": [
"ITEM-NAME",
"BOM-MODEL-NUM",
"BOM-PART-NUM"
]
}
}]
}
```
**Example Definir um índice exclusivo**
O exemplo a seguir define um índice exclusivo denominado `ITEM-unique-idx` em três colunas da tabela `ITEM` migradas para o endpoint de destino.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "inventory",
"table-name": "%"
},
"rule-action": "include"
}, {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "define-primary-key",
"rule-target": "table",
"object-locator": {
"schema-name": "inventory",
"table-name": "ITEM"
},
"primary-key-def": {
"name": "ITEM-unique-idx",
"origin": "unique-index",
"columns": [
"ITEM-NAME",
"BOM-MODEL-NUM",
"BOM-PART-NUM"
]
}
}]
}
```
**Example Alterar o tipo de dados da coluna de destino**
O exemplo a seguir altera o tipo de dados de uma coluna de destino chamada `SALE_AMOUNT` de um tipo de dados existente para `int8`.
```
{
"rule-type": "transformation",
"rule-id": "1",
"rule-name": "RuleName 1",
"rule-action": "change-data-type",
"rule-target": "column",
"object-locator": {
"schema-name": "dbo",
"table-name": "dms",
"column-name": "SALE_AMOUNT"
},
"data-type": {
"type": "int8"
}
}
```
**Example Adicionar uma coluna de imagem anterior**
Para uma coluna de origem chamada `emp_no`, a regra de transformação no exemplo a seguir adiciona uma nova coluna chamada `BI_emp_no` no destino.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "employees"
},
"rule-action": "add-before-image-columns",
"before-image-def": {
"column-prefix": "BI_",
"column-suffix": "",
"column-filter": "pk-only"
}
}
]
}
```
Aqui, a instrução a seguir preenche uma coluna `BI_emp_no` na linha correspondente com 1.
```
UPDATE employees SET emp_no = 3 WHERE BI_emp_no = 1;
```
Ao escrever atualizações do CDC em AWS DMS destinos compatíveis, a `BI_emp_no` coluna possibilita saber quais linhas têm valores atualizados na `emp_no` coluna.
# Utilizar expressões de regra de transformação para definir o conteúdo da coluna
Para definir o conteúdo de colunas novas e existentes, é possível utilizar uma expressão em uma regra de transformação. Por exemplo, utilizando expressões, é possível adicionar uma coluna ou replicar cabeçalhos de tabela de origem para um destino. Também é possível utilizar expressões para sinalizar registros em tabelas de destino como inseridos, atualizados ou excluídos na origem.
**Topics**
+ [
## Adicionar uma coluna utilizando uma expressão
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions-adding)
+ [
## Sinalizar registros de destino utilizando uma expressão
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions-Flagging)
+ [
## Replicar cabeçalhos de tabela de origem utilizando expressões
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions-Headers)
+ [
## Usando SQLite funções para criar expressões
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions-SQLite)
+ [
## Adicionar metadados a uma tabela de destino utilizando expressões
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions-Metadata)
## Adicionar uma coluna utilizando uma expressão
Para adicionar colunas a tabelas utilizando uma expressão em uma regra de transformação, utilize uma ação de regra `add-column` e um destino de regra `column`.
O exemplo a seguir adiciona uma nova coluna à tabela `ITEM`. Ele define o nome da nova coluna como `FULL_NAME`, com um tipo de dados de `string`, com 50 caracteres. A expressão concatena os valores de duas colunas existentes, `FIRST_NAME` e `LAST_NAME`, para avaliar para `FULL_NAME`. Os parâmetros `schema-name` e `table-name` e de expressão se referem aos objetos na tabela do banco de dados de origem. `Value` e o bloco `data-type` se referem aos objetos na tabela do banco de dados de destino.
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "Test",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "Test",
"table-name": "ITEM"
},
"value": "FULL_NAME",
"expression": "$FIRST_NAME||'_'||$LAST_NAME",
"data-type": {
"type": "string",
"length": 50
}
}
]
}
```
## Sinalizar registros de destino utilizando uma expressão
Para sinalizar registros em tabelas de destino como inseridos, atualizados ou excluídos na tabela de origem, utilize uma expressão em uma regra de transformação. A expressão utiliza um perfil `operation_indicator` para sinalizar registros. Os registros excluídos da origem não são excluídos do destino. Em vez disso, o registro de destino é sinalizado com um valor fornecido pelo usuário para indicar que ele foi excluído da origem.
**nota**
O perfil `operation_indicator` funciona somente em tabelas que têm uma chave primária no banco de dados de origem e de destino.
Por exemplo, a regra de transformação a seguir primeiro adiciona uma nova coluna `Operation` à uma tabela de destino. Ela atualiza a coluna com o valor `D` sempre que um registro for excluído de uma tabela de origem.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "add-column",
"value": "Operation",
"expression": "operation_indicator('D', 'U', 'I')",
"data-type": {
"type": "string",
"length": 50
}
}
```
## Replicar cabeçalhos de tabela de origem utilizando expressões
Por padrão, os cabeçalhos das tabelas de origem não são replicados no destino. Para indicar quais cabeçalhos a serem replicados, utilize uma regra de transformação com uma expressão que inclua o cabeçalho da coluna da tabela.
É possível utilizar os cabeçalhos de coluna a seguir em expressões.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions.html)
O exemplo a seguir adiciona uma nova coluna ao destino utilizando o valor da posição do fluxo da origem. Para o SQL Server, o valor da posição do fluxo é o LSN do endpoint de origem. Para o Oracle, o valor da posição do fluxo é o SCN do endpoint de origem.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "add-column",
"value": "transact_id",
"expression": "$AR_H_STREAM_POSITION",
"data-type": {
"type": "string",
"length": 50
}
}
```
O exemplo a seguir adiciona uma nova coluna ao destino que tem um número incremental exclusivo da origem. Esse valor representa um número exclusivo de 35 dígitos no nível da tarefa. Os primeiros 16 dígitos fazem parte de um timestamp e os últimos 19 dígitos são o número de record\$1id incrementado pelo DBMS.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "add-column",
"value": "transact_id",
"expression": "$AR_H_CHANGE_SEQ",
"data-type": {
"type": "string",
"length": 50
}
}
```
## Usando SQLite funções para criar expressões
Utilize as configurações da tabela para especificar quaisquer configurações que deseja aplicar à tabela ou à visualização selecionada para uma operação especificada. As regras de configuração de tabela são opcionais.
**nota**
Em vez do conceito de tabelas e visualizações, os bancos de dados MongoDB e DocumentDB armazenam os registros de dados como documentos reunidos em *coleções*. Portanto, ao migrar de uma origem do MongoDB ou do DocumentDB, considere o tipo de segmentação por intervalo das configurações de carga paralela para *coleções* selecionadas, em vez de tabelas e visualizações.
**Topics**
+ [
### Utilizar uma expressão CASE
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions-SQLite.CASE)
+ [
### Exemplos
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Expressions-SQLite.Ex)
A seguir, você encontrará perfis de string que podem ser utilizadas para criar expressões de regras de transformação.
| Funções de string | Description |
| --- | --- |
| `lower(x)` | O perfil `lower(x)` retorna uma cópia da string *`x`* com todos os caracteres convertidos em minúsculas. O padrão, o perfil `lower` integrado funciona somente para caracteres ASCII. |
| `upper(x)` | O perfil `upper(x)` retorna uma cópia da string *`x`* com todos os caracteres convertidos em maiúsculas. O padrão, o perfil `upper` integrado funciona somente para caracteres ASCII. |
| `ltrim(x,y)` | O perfil `ltrim(x,y)` retorna uma string formada pela remoção de todos os caracteres que aparecem em y do lado esquerdo de x. Se não houver nenhum valor para y, `ltrim(x)` removerá os espaços do lado esquerdo de x. |
| `replace(x,y,z)` | O perfil `replace(x,y,z)` retorna uma string formada pela substituição da string z de cada ocorrência da string y na string x. |
| `rtrim(x,y)` | O perfil `rtrim(x,y)` retorna uma string formada pela remoção de todos os caracteres que aparecem em y do lado direito de x. Se não houver nenhum valor para y, `rtrim(x)` removerá os espaços do lado direito de x. |
| `substr(x,y,z)` | O perfil `substr(x,y,z)` retorna uma substring da string de entrada `x` que começa com o `y`º caractere e tem *`z`* caracteres. Se *`z`* for omitido, `substr(x,y)` retornará todos os caracteres até o final da string `x` começando com o caractere `y`º. O caractere mais à esquerda de `x` é o número 1. Se *`y`* for negativo, o primeiro caractere da substring será encontrado contando a partir da direita em vez da esquerda. Se *`z`* for negativo, os caracteres `abs(z)` anteriores ao `y`º caractere serão retornados. Se `x` for uma string, os índices de caracteres se referem aos caracteres UTF-8 reais. Se `x` for um BLOB, os índices se referirão a bytes. |
| trim(x,y) | O perfil `trim(x,y)` retorna uma string formada pela remoção de todos os caracteres que aparecem em `y` do dois lados de `x`. Se não houver nenhum valor para `y`, `trim(x)` removerá os espaços dos dois lados de `x`. |
A seguir, é possível encontrar perfis de LOB que podem ser utilizados para criar expressões de regras de transformação.
| Perfis de LOB | Description |
| --- | --- |
| `hex(x)` | O perfil `hex` recebe um BLOB como argumento e retorna uma versão de string hexadecimal em maiúsculas do conteúdo do BLOB. |
| `randomblob (N)` | O perfil `randomblob(N)` retorna um BLOB de `N`-bytes que contém bytes pseudoaleatórios. Se *N* for menor que 1, um BLOB aleatório de 1 byte será retornado. |
| `zeroblob(N)` | O perfil `zeroblob(N)` retorna um BLOB que consiste em `N` bytes de 0x00. |
A seguir, é possível encontrar perfis numéricos que podem ser utilizados para criar expressões de regras de transformação.
| Perfis numéricos | Description |
| --- | --- |
| `abs(x)` | O perfil `abs(x)` retorna o valor absoluto do argumento numérico `x`. A `abs(x)` função retornará NULL se *x* for NULL. A `abs(x)` função retornará 0,0 se **x** for uma string ou BLOB que não pode ser convertida em um valor numérico. |
| `random()` | O perfil `random` retorna um número inteiro pseudoaleatório entre -9.223.372.036.854.775.808 e \$19.223.372.036.854.775.807. |
| `round (x,y)` | A `round (x,y)` função retorna um valor de ponto flutuante *x* arredondado para *y* dígitos à direita do ponto decimal. Se não houver valor para*y*, presume-se que seja 0. |
| `max (x,y...)` | O perfil `max` de multiargumento retorna o argumento com o valor máximo ou retorna NULL se algum argumento for NULL. O perfil `max` pesquisa seus argumentos da esquerda para a direita em busca de um argumento que defina um perfil de agrupamento. Se um for encontrado, ele utilizará esse perfil de agrupamento para todas as comparações de strings. Se nenhum dos argumentos para `max` definir um perfil de agrupamento, o perfil de agrupamento `BINARY` será utilizado. O perfil `max` é simples quando há dois ou mais argumentos, mas funciona como um perfil agregado se tiver um único argumento. |
| `min (x,y...)` | O perfil `min` de multiargumento retorna o argumento com o valor mínimo. O perfil `min` pesquisa seus argumentos da esquerda para a direita em busca de um argumento que defina um perfil de agrupamento. Se um for encontrado, ele utilizará esse perfil de agrupamento para todas as comparações de strings. Se nenhum dos argumentos para `min` definir um perfil de agrupamento, o perfil de agrupamento `BINARY` será utilizado. O perfil `min` é simples quando há dois ou mais argumentos, mas funciona como um perfil agregado se tiver um único argumento. |
A seguir, é possível encontrar perfis de verificação de NULL que podem ser utilizados para criar expressões de regras de transformação.
| Perfis de verificação NULL | Description |
| --- | --- |
| `coalesce (x,y...)` | O perfil `coalesce` retorna uma cópia do primeiro argumento não NULL, mas retornará NULL se todos os argumentos forem NULL. O perfil de agrupamento tem pelo menos dois argumentos. |
| `ifnull(x,y)` | O perfil `ifnull` retorna uma cópia do primeiro argumento não NULL, mas retornará NULL se os dois argumentos forem NULL. O perfil `ifnull` tem exatamente dois argumentos. O perfil `ifnull` é igual a `coalesce` com dois argumentos. |
| `nullif(x,y)` | O perfil `nullif(x,y)` retornará uma cópia do primeiro argumento se os argumentos forem diferentes, mas retornará NULL se os argumentos forem iguais. O perfil `nullif(x,y)` pesquisa seus argumentos da esquerda para a direita em busca de um argumento que defina um perfil de agrupamento. Se um for encontrado, ele utilizará esse perfil de agrupamento para todas as comparações de strings. Se nenhum dos argumentos nullif definir um perfil de agrupamento, o perfil de agrupamento `BINARY` será utilizado. |
A seguir, é possível encontrar perfis de data e hora que podem ser utilizados para criar expressões de regras de transformação.
| Perfis de data e hora | Description |
| --- | --- |
| `date(timestring, modifier, modifier...)` | A `date` função retorna a data no formato YYYY-MM-DD. |
| `time(timestring, modifier, modifier...)` | O perfil `time` retorna a hora no formato HH:MM:SS. |
| `datetime(timestring, modifier, modifier...)` | A `datetime` função retorna a data e a hora no formato YYYY-MM-DD HH:MM:SS. |
| `julianday(timestring, modifier, modifier...)` | O perfil `julianday` retorna o número de dias desde o meio-dia em Greenwich em 24 de novembro de 4714 a.C. |
| `strftime(format, timestring, modifier, modifier...)` | O perfil `strftime` retorna a data de acordo com a string de formato especificada como o primeiro argumento, utilizando uma das seguintes variáveis: `%d`: dia do mês `%H`: hora 00 a 24 `%f`: \$1\$1 segundos fracionários SS.SSS `%j`: dia do ano 001 a 366 `%J`: \$1\$1 número do dia juliano `%m`: mês 1 a 12 `%M`: minuto 00 a 59 `%s`: segundos desde 1-1-1970 `%S`: segundos 00 a 59 `%w`: dia da semana 0 a 6 domingo==0 `%W`: semana do ano 00 a 53 `%Y`: ano 0000 a 9999 `%%`: % |
A seguir, é possível encontrar um perfil de hash que pode ser utilizado para criar expressões de regras de transformação.
| Função de hash | Description |
| --- | --- |
| `hash_sha256(x)` | O perfil `hash` gera um valor de hash para uma coluna de entrada (utilizando o algoritmo SHA-256) e retorna o valor hexadecimal do valor de hash gerado. Para utilizar o perfil `hash` em uma expressão, adicione `hash_sha256(x)` à expressão e substitua *`x`* pelo nome da coluna de origem. |
### Utilizar uma expressão CASE
A SQLite `CASE` expressão avalia uma lista de condições e retorna uma expressão com base no resultado. A sintaxe é mostrada a seguir.
```
CASE case_expression
WHEN when_expression_1 THEN result_1
WHEN when_expression_2 THEN result_2
...
[ ELSE result_else ]
END
# Or
CASE
WHEN case_expression THEN result_1
WHEN case_expression THEN result_2
...
[ ELSE result_else ]
END
```
### Exemplos
**Example de adição de uma nova coluna de string à tabela de destino utilizando uma condição de caso**
O seguinte exemplo de regra de transformação adiciona uma nova coluna string, `emp_seniority`, à tabela de destino, `employee`. Ele usa a SQLite `round` função na coluna de salário, com uma condição de caso para verificar se o salário é igual ou superior a 20.000. Se isso acontecer, a coluna obterá o valor `SENIOR` e qualquer outra coisa terá o valor `JUNIOR`.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "public",
"table-name": "employee"
},
"value": "emp_seniority",
"expression": " CASE WHEN round($emp_salary)>=20000 THEN ‘SENIOR’ ELSE ‘JUNIOR’ END",
"data-type": {
"type": "string",
"length": 50
}
}
```
**Example de adição de uma nova coluna string à tabela de destino utilizando função SUBSTR**
O exemplo de regra de transformação a seguir adiciona uma nova coluna de string usando SQLite operadores ou funções para definir os dados em uma coluna. Essa abordagem envolve o uso de SQLite funções para transformar os dados GUID carregados do formato Oracle para o formato UUID antes de inseri-los na tabela de destino do Postgresql.
A regra a seguir usa as funções SQLite substring (SUBSTR), função hexadecimal (HEX) e minúsculas (LOWER) para dividir os dados do GUID em vários grupos separados por hífens, especificamente um grupo de 8 dígitos seguido por três grupos de 4 dígitos seguidos por um grupo de 12 dígitos, totalizando 32 dígitos representando os 128 bits.
Veja o abaixo o exemplo de dados de origem e saída no pós-processamento de destino por meio da regra de transformação:
**Tabela de origem (formato GUID do Oracle)**
T\$1 COL2
```
06F6949D234911EE80670242AC120002
1A2B3C4D5E6F11EE80670242AC120003
F5E4D3C2B1A011EE80670242AC120004
```
**Tabela de destino (formato UUID do PostgreSQL)**
T\$1 \$1TMP COL2
```
06f6949d-2349-11ee-8067-0242ac120002
1a2b3c4d-5e6f-11ee-8067-0242ac120003
f5e4d3c2-b1a0-11ee-8067-0242ac120004
```
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "SPORTS",
"table-name": "TEST_TBL_2"
},
"value": "t_col2_tmp",
"expression": "CASE LOWER(SUBSTR(HEX($T_COL2), 1, 8) || '-' || SUBSTR(HEX($T_COL2), 9, 4) || '-' || SUBSTR(HEX($T_COL2), 13, 4) || '-' || SUBSTR(HEX($T_COL2), 17, 4) || '-' || SUBSTR(HEX($T_COL2), 21, 12)) WHEN '----' THEN NULL ELSE LOWER(SUBSTR(HEX($T_COL2), 1, 8) || '-' || SUBSTR(HEX($T_COL2), 9, 4) || '-' || SUBSTR(HEX($T_COL2), 13, 4) || '-' || SUBSTR(HEX($T_COL2), 17, 4) || '-' || SUBSTR(HEX($T_COL2), 21, 12)) END",
"data-type": {
"type": "string",
"length": 60
}
}
```
**Example da adição de uma nova coluna de data à tabela de destino**
O exemplo a seguir adiciona uma nova coluna de data, `createdate`, à tabela de destino, `employee`. Quando você usa a função de SQLite data`datetime`, a data é adicionada à tabela recém-criada para cada linha inserida.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "public",
"table-name": "employee"
},
"value": "createdate",
"expression": "datetime ()",
"data-type": {
"type": "datetime",
"precision": 6
}
}
```
**Example da adição de uma nova coluna numérica à tabela de destino**
O exemplo a seguir adiciona uma nova coluna numérica, `rounded_emp_salary`, à tabela de destino, `employee`. Ele usa a SQLite `round` função para adicionar o salário arredondado.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "public",
"table-name": "employee"
},
"value": "rounded_emp_salary",
"expression": "round($emp_salary)",
"data-type": {
"type": "int8"
}
}
```
**Example da adição de uma nova coluna string à tabela de destino utilizando o perfil hash**
O exemplo a seguir adiciona uma nova coluna string, `hashed_emp_number`, à tabela de destino, `employee`. A SQLite `hash_sha256(x)` função cria valores com hash no destino para a coluna de origem,`emp_number`.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "public",
"table-name": "employee"
},
"value": "hashed_emp_number",
"expression": "hash_sha256($emp_number)",
"data-type": {
"type": "string",
"length": 64
}
}
```
## Adicionar metadados a uma tabela de destino utilizando expressões
É possível adicionar informações de metadados à tabela de destino utilizando as seguintes expressões:
+ `$AR_M_SOURCE_SCHEMA`: o nome do esquema de origem.
+ `$AR_M_SOURCE_TABLE_NAME`: o nome da tabela de origem.
+ `$AR_M_SOURCE_COLUMN_NAME`: o nome de uma coluna na tabela de origem.
+ `$AR_M_SOURCE_COLUMN_DATATYPE`: o tipo de dados de uma coluna na tabela de origem.
**Example da adição de uma coluna para um nome de esquema utilizando o nome do esquema da origem**
O exemplo a seguir adiciona uma nova coluna `schema_name` ao destino utilizando o nome do esquema da origem.
```
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-action": "add-column",
"rule-target": "column",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "add-column",
"value":"schema_name",
"expression": "$AR_M_SOURCE_SCHEMA",
"data-type": {
"type": "string",
"length": 50
}
}
```
# Regras e operações de configurações de tabelas e coleções
Utilize as configurações de tabela para especificar quaisquer configurações que deseja aplicar a uma tabela ou visualização selecionada para uma operação especificada. As regras de configuração de tabela são opcionais, dependendo do endpoint e dos requisitos da migração.
Em vez de utilizar tabelas e visualizações, os bancos de dados MongoDB e Amazon DocumentDB armazenam registros de dados como documentos que são reunidos em *coleções*. Um único banco de dados de qualquer endpoint do MongoDB ou do Amazon DocumentDB é um conjunto específico de coleções identificadas pelo nome do banco de dados.
Ao migrar de uma origem do MongoDB ou do Amazon DocumentDB, você trabalha com configurações de carregamento paralelo de forma um pouco diferente. Nesse caso, considere o tipo de segmentação automática ou de segmentação por intervalo das configurações de carga paralela para coleções selecionadas, em vez de tabelas e visualizações.
**Topics**
+ [
## Curingas nas configurações de tabela são restritos
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.Wildcards)
+ [
## Utilizar carga paralela para tabelas, visualizações e coleções selecionadas
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad)
+ [
## Especificar configurações de LOB para uma tabela ou exibição selecionada
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.LOB)
+ [
## Exemplos de configurações de tabela
](#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.Examples)
Para as regras de mapeamento de tabela que utilizam o tipo de regra de configurações de tabela, é possível aplicar os parâmetros a seguir.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.html)
## Curingas nas configurações de tabela são restritos
A utilização do curinga de porcentagem (`"%"`) em regras `"table-settings"` não é compatível com bancos de dados de origem, conforme mostrado a seguir.
```
{
"rule-type": "table-settings",
"rule-id": "8",
"rule-name": "8",
"object-locator": {
"schema-name": "ipipeline-prod",
"table-name": "%"
},
"parallel-load": {
"type": "partitions-auto",
"number-of-partitions": 16,
"collection-count-from-metadata": "true",
"max-records-skip-per-page": 1000000,
"batch-size": 50000
}
}
```
Se você usar `"%"` as `"table-settings"` regras conforme mostrado, AWS DMS retornará a exceção a seguir.
```
Error in mapping rules. Rule with ruleId = x failed validation. Exact
schema and table name required when using table settings rule.
```
Além disso, AWS recomenda que você não carregue um grande número de coleções grandes usando uma única tarefa com`parallel-load`. Observe que o AWS DMS limita a contenção de recursos, bem como o número de segmentos carregados em paralelo pelo valor do parâmetro de configurações de tarefa `MaxFullLoadSubTasks`, com um valor máximo de 49.
Em vez disso, especifique todas as coleções do banco de dados de origem para as maiores coleções especificando cada `"schema-name"` e `"table-name"` individualmente. Além disso, aumente a escala verticalmente da migração de forma adequada. Por exemplo, execute várias tarefas em um número suficiente de instâncias de replicação para tratar um grande número de coleções grandes no banco de dados.
## Utilizar carga paralela para tabelas, visualizações e coleções selecionadas
Para acelerar a migração e torná-la mais eficiente, é possível utilizar a carga paralela para tabelas, visualizações e coleções selecionadas. Em outras palavras, é possível migrar uma única tabela, visualização ou coleção utilizando vários threads em paralelo. Para fazer isso, AWS DMS divide uma tarefa de carga completa em segmentos, com cada segmento da tabela alocado em seu próprio encadeamento.
Utilizando esse processo de carregamento paralelo, é possível primeiro fazer o upload de vários threads de várias tabelas, visualizações e coleções em paralelo no endpoint de origem. É possível que vários threads migrem e carreguem as mesmas tabelas, visualizações e coleções em paralelo para o endpoint de destino. Para alguns mecanismos de banco de dados, é possível segmentar as tabelas e as exibições pelas partições ou subpartições existentes. Para outros mecanismos de banco de dados, você pode segmentar AWS DMS automaticamente as coleções de acordo com parâmetros específicos (segmentação automática). Caso contrário, é possível segmentar qualquer tabela, visualização ou coleção pelos intervalos de valores de coluna especificados.
O carregamento paralelo é compatível com os seguintes endpoints de origem:
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ PostgreSQL
+ IBM Db2 LUW
+ SAP Adaptive Server Enterprise (ASE)
+ MongoDB (compatível somente com as opções de segmentação automática e com a segmentação por intervalo de uma carga máxima paralela)
+ Amazon DocumentDB (compatível somente com as opções de segmentação automática e com a segmentação por intervalo de uma carga máxima paralela)
Para endpoints MongoDB e Amazon DocumentDB AWS DMS , suporta os seguintes tipos de dados para colunas que são chaves de partição para a opção de segmentação de intervalo de uma carga completa paralela.
+ Duplo
+ String
+ ObjectId
+ Inteiro de 32 bits
+ Inteiro de 64 bits
A carga paralela para uso com regras de configuração de tabela é suportada para os seguintes endpoints de destino:
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ PostgreSQL
+ Amazon S3
+ SAP Adaptive Server Enterprise (ASE)
+ banco de dados de origem
+ MongoDB (compatível somente com as opções de segmentação automática e com a segmentação por intervalo de uma carga máxima paralela)
+ Amazon DocumentDB (compatível somente com as opções de segmentação automática e com a segmentação por intervalo de uma carga máxima paralela)
+ Db2 LUW
Para especificar o número máximo de tabelas e visualizações para carga em paralelo, utilize a configuração de tarefa `MaxFullLoadSubTasks`.
Para especificar o número máximo de threads por tabela ou visualização para destinos compatíveis de uma tarefa de carga paralela, defina mais segmentos utilizando limites de valor-coluna.
**Importante**
`MaxFullLoadSubTasks` controla o número de tabelas ou segmentos de tabela a serem carregados em paralelo. `ParallelLoadThreads` controla o número de threads utilizados por uma tarefa de migração para executar as cargas em paralelo. *Essas configurações são multiplicativas.* Dessa forma, o número total de threads utilizados durante uma tarefa de carga máxima é aproximadamente o resultado do valor de `ParallelLoadThreads ` multiplicado pelo valor de `MaxFullLoadSubTasks` (`ParallelLoadThreads`**\$1**`MaxFullLoadSubtasks)`.
Se você criar tarefas com um grande número de subtarefas de carga máxima e um grande número de threads de carga paralela, a tarefa poderá consumir muita memória e falhar.
Para especificar o número máximo de threads por tabela para destinos do Amazon DynamoDB, do Amazon Kinesis Data Streams, do Apache Kafka ou do Amazon Elasticsearch Service, utilize a configuração da tarefa de metadados de destino `ParallelLoadThreads`.
Para especificar o tamanho do buffer para uma tarefa de carga paralela quando `ParallelLoadThreads` é utilizada, utilize a configuração da tarefa de metadados `ParallelLoadBufferSize`.
A disponibilidade e as configurações de `ParallelLoadThreads` e `ParallelLoadBufferSize` dependem do endpoint de destino.
Para obter mais informações sobre `ParallelLoadThreads` e `ParallelLoadBufferSize`, consulte [Configurações de tarefa de metadados de destino](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md). Para obter mais informações sobre a configuração de `MaxFullLoadSubTasks`, consulte [Configurações de tarefa de carregamento completo](CHAP_Tasks.CustomizingTasks.TaskSettings.FullLoad.md). Para obter informações específicas de endpoints de destino, consulte os tópicos relacionados.
Para utilizar a carga paralela, crie uma regra de mapeamento de tabelas do tipo `table-settings` com a opção `parallel-load`. Na regra `table-settings`, é possível especificar os critérios de segmentação para uma única tabela, visualização ou coleção para carregamento em paralelo. Para fazer isso, defina o parâmetro `type` da opção `parallel-load` como uma das várias opções.
Como fazer isso depende de como você deseja segmentar a tabela, visualização ou coleção para carga paralela:
+ Por partições (ou segmentos): carregue todas as partições da tabela ou da visualização existentes (ou segmentos) utilizando o tipo `partitions-auto`. Ou carregue somente as partições selecionadas utilizando o tipo `partitions-list` com uma matriz de partições especificada.
Somente para endpoints do MongoDB e do Amazon DocumentDB, carregue todas as coleções ou as coleções especificadas por segmentos AWS DMS que calculam automaticamente também usando o tipo e os parâmetros opcionais adicionais. `partitions-auto` `table-settings`
+ (Somente endpoints do Oracle) Por subpartições: carregue todas as subpartições da tabela ou da visualização existente utilizando o tipo `subpartitions-auto`. Ou carregue somente as subpartições selecionadas utilizando o tipo `partitions-list` com uma matriz de `subpartitions` especificada.
+ Pelos segmentos que você define: carregue os segmentos da tabela, visualização ou coleção que você define utilizando limites de coluna-valor. Para fazer isso, utilize o tipo `ranges` com as matrizes `columns` e `boundaries` especificadas.
**nota**
Os endpoints do PostgreSQL são compatíveis somente com esse tipo de carga paralela. O MongoDB e o Amazon DocumentDB como endpoints de origem são compatíveis com esse tipo de segmentação por intervalo e com o tipo de segmentação automática de uma carga máxima paralela (`partitions-auto`).
Para identificar tabelas, visualizações ou coleções adicionais a serem carregadas em paralelo, especifique os objetos `table-settings` adicionais com as opções de `parallel-load`.
Nos procedimentos a seguir, é possível saber como codificar JSON para cada tipo de carga paralela, da mais simples à mais complexa.
**Como especificar todas as partições de tabela, visualização ou coleção ou todas as subpartições de tabela ou visualização**
+ Especifique `parallel-load` com o tipo `partitions-auto` ou o tipo `subpartitions-auto` (mas não com os dois).
Cada partição ou subpartição da tabela, visualização ou coleção é automaticamente alocada para seu próprio thread.
Em alguns endpoints, a carga paralela incluirá partições ou subpartições somente se elas já estiverem definidas para a tabela ou visualização. Para endpoints de origem do MongoDB e do Amazon DocumentDB, você pode AWS DMS calcular automaticamente as partições (ou segmentos) com base em parâmetros adicionais opcionais. Entre elas estão `number-of-partitions`, `collection-count-from-metadata`, `max-records-skip-per-page` e `batch-size`.
**Como especificar partições, subpartições selecionadas da tabela ou da exibição ou ambas**
1. Especifique `parallel-load` com o tipo `partitions-list`.
1. (Opcional) Inclua as partições, especificando uma matriz de nomes de partição como o valor de `partitions`.
Cada partição especificada será então alocada para seu próprio thread.
**Importante**
Para endpoints do Oracle, verifique se as partições e subpartições não estão sobrepostas ao escolhê-las para a carga paralela. Se você utilizar partições e subpartições sobrepostas para carregar dados em paralelo, isso duplicará as entradas ou falhará devido a uma violação de duplicação da chave primária.
1. (Opcional) Somente para endpoints do Oracle inclua as subpartições especificando uma matriz de nomes de subpartições como o valor de `subpartitions`.
Cada subpartição especificada será então alocada para seu próprio thread.
**nota**
A carga paralela inclui partições ou subpartições somente se elas já estão definidas para a tabela ou a exibição.
É possível especificar os segmentos de tabela ou visualização como intervalos de valores de colunas. Ao fazer isso, lembre-se destas características da coluna:
+ A especificação de colunas indexadas melhora significativamente o desempenho.
+ É possível especificar até 10 colunas.
+ Você não pode usar colunas para definir limites de segmentos com os seguintes tipos de AWS DMS dados: DOUBLE, FLOAT, BLOB, CLOB e NCLOB
+ Os registros com valores nulos não são replicados.
**Como especificar os segmentos de tabela, visualização ou coleção como intervalos de valores de colunas**
1. Especifique `parallel-load` com o tipo `ranges`.
1. Defina um limite entre os segmentos da tabela ou da exibição, especificando uma matriz de nomes de coluna da tabela como o valor de `columns`. Faça isso para cada coluna para a qual você deseja definir um limite entre os segmentos da tabela ou da exibição.
Observe que a ordem das colunas é significativa. A primeira coluna é a mais significativa e a última coluna é a menos significativa na definição de cada limite, conforme descrito a seguir.
1. Defina os intervalos de dados para todos os segmentos da tabela ou da exibição especificando uma matriz de limites como o valor de `boundaries`. Uma *matriz de limites* é uma matriz de matrizes de coluna/valor. Para fazer isso, siga as estas etapas:
1. Especifique cada elemento de uma matriz de coluna/valor como um valor que corresponda a cada coluna. Uma *matriz de coluna/valor* representa o limite superior de cada segmento da tabela ou da exibição que você deseja definir. Especifique cada coluna na mesma ordem em que você especificou essa coluna na matriz `columns`.
Insira valores para as colunas DATE no formato com suporte pela origem.
1. Especifique cada matriz de valores de coluna como o limite superior, em ordem, de cada segmento da parte inferior até o next-to-top segmento da tabela ou exibição. Se houver linhas acima do limite superior especificado, essas linhas completarão o segmento superior da tabela ou da exibição. Portanto, o número de segmentos com base em intervalo será potencialmente mais um que o número de limites de segmentos na matriz de limites. Cada segmento com base em intervalo é alocado para seu próprio thread.
Todos os dados não nulos serão replicados, mesmo que você não defina intervalos de dados para todas as colunas da tabela ou da exibição.
Por exemplo, suponha que você defina três matrizes de valores de coluna para colunas COL1 COL2, e COL3 da seguinte forma.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.html)
Você definiu três limites de segmento para um total possível de quatro segmentos.
Para identificar os intervalos de linhas a serem replicados para cada segmento, a instância de replicação realiza uma pesquisa com essas três colunas para cada um dos quatro segmentos: A pesquisa é semelhante à seguinte:
**Segmento 1**
Replicar todas as linhas onde o seguinte é verdadeiro: os primeiros valores de duas colunas são menores ou iguais aos seus valores de limite superior do **segmento 1** correspondentes. Além disso, os valores da terceira coluna são menores que o valor limite superior do **segmento 1**.
**Segmento 2**
Replique todas as linhas (exceto as linhas do **segmento 1** ) em que o seguinte é verdadeiro: os primeiros valores de duas colunas são menores ou iguais aos valores de limite superior **do segmento 2** correspondentes. Além disso, os valores da terceira coluna são menores que o valor limite superior do **segmento 2**.
**Segmento 3**
Replique todas as linhas (exceto as linhas do **segmento 2**) em que o seguinte é verdadeiro: os primeiros valores de duas colunas são menores ou iguais aos valores de limite superior do **segmento 3** correspondentes. Além disso, os valores da terceira coluna são menores que o valor limite superior do **segmento 3**.
**Segmento 4**
Replicar todas as linhas restantes (exceto as linhas do **Segmento 1, 2 e 3**).
Nesse caso, a instância de replicação cria uma cláusula `WHERE` para carregar cada segmento da seguinte forma:
**Segmento 1**
`((COL1 < 10) OR ((COL1 = 10) AND (COL2 < 30)) OR ((COL1 = 10) AND (COL2 = 30) AND (COL3 < 105)))`
**Segmento 2**
`NOT ((COL1 < 10) OR ((COL1 = 10) AND (COL2 < 30)) OR ((COL1 = 10) AND (COL2 = 30) AND (COL3 < 105))) AND ((COL1 < 20) OR ((COL1 = 20) AND (COL2 < 20)) OR ((COL1 = 20) AND (COL2 = 20) AND (COL3 < 120)))`
**Segmento 3**
`NOT ((COL1 < 20) OR ((COL1 = 20) AND (COL2 < 20)) OR ((COL1 = 20) AND (COL2 = 20) AND (COL3 < 120))) AND ((COL1 < 100) OR ((COL1 = 100) AND (COL2 < 12)) OR ((COL1 = 100) AND (COL2 = 12) AND (COL3 < 99)))`
**Segmento 4**
`NOT ((COL1 < 100) OR ((COL1 = 100) AND (COL2 < 12)) OR ((COL1 = 100) AND (COL2 = 12) AND (COL3 < 99)))`
## Especificar configurações de LOB para uma tabela ou exibição selecionada
É possível definir as configurações de LOB de tarefa para uma ou mais tabelas criando uma regra de mapeamento de tabela do tipo `table-settings` com a opção `lob-settings` para um ou mais objetos `table-settings`.
A especificação das configurações de LOB para tabelas ou exibições selecionadas tem suporte para os seguintes endpoints de origem:
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ PostgreSQL
+ IBM Db2, dependendo do `mode` e das configurações de `bulk-max-size`, como descrito a seguir
+ SAP Adaptive Server Enterprise (ASE), de acordo com as configurações de `bulk-max-size` e `mode`, como descrito a seguir
A especificação das configurações de LOB para tabelas ou exibições selecionadas tem suporte para os seguintes endpoints de destino:
+ Oracle
+ Microsoft SQL Server
+ MySQL
+ PostgreSQL
+ SAP ASE, dependendo do `mode` e das configurações de `bulk-max-size`, como descrito a seguir
**nota**
É possível utilizar tipos de dados de LOB somente com tabelas e visualizações que incluem uma chave primária.
Para utilizar as configurações de LOB para uma tabela ou visualização selecionada, crie uma regra de mapeamento de tabela do tipo `table-settings` com a opção `lob-settings`. Isso especifica o tratamento de LOB para a tabela ou a exibição identificada pela opção `object-locator`. Na regra `table-settings`, é possível especificar um objeto de `lob-settings` com os seguintes parâmetros:
+ `mode`: especifica o mecanismo para tratar a migração de LOB para a tabela ou a visualização selecionada da seguinte forma:
+ `limited`: o modo LOB limitado padrão é o mais rápido e mais eficiente. Use esse modo somente se todos os seus LOBs forem pequenos (dentro de 100 MB) ou se o endpoint de destino não suportar um tamanho de LOB ilimitado. Além disso, se você usar`limited`, todos LOBs precisam estar dentro do tamanho que você definiu`bulk-max-size`.
Nesse modo, para uma tarefa de carga total, a instância de replicação migra tudo LOBs em linha junto com outros tipos de dados de coluna como parte da tabela principal ou do armazenamento de visualização. No entanto, a instância trunca qualquer LOB maior que o valor de `bulk-max-size` para o tamanho especificado. Para uma tarefa de carregamento de captura de dados de alteração (CDC), a instância migra tudo LOBs usando uma pesquisa na tabela de origem, como no modo LOB completo padrão (veja a seguir).
**nota**
Você pode migrar exibições somente para tarefas de carregamento completo.
+ `unlimited`: o mecanismo de migração para o modo LOB completo depende do valor definido para `bulk-max-size` da seguinte forma:
+ **Modo LOB completo padrão** — Quando você define como zero, `bulk-max-size` a instância de replicação migra tudo LOBs usando o modo LOB completo padrão. Esse modo exige uma pesquisa na tabela ou na exibição de origem para migrar cada LOB, independentemente do tamanho. Isso normalmente resulta em uma migração muito mais lenta do que no modo LOB limitado. Use esse modo somente se todos ou a maioria dos seus LOBs forem grandes (1 GB ou mais).
+ **Combinação do modo LOB completo**: quando você define `bulk-max-size` como um valor diferente de zero, esse modo LOB completo utiliza uma combinação de modo LOB limitado e do modo LOB completo padrão. Isso é para uma tarefa de carga máxima, se o tamanho de um LOB estiver dentro de seu valor de `bulk-max-size`, a instância migrará o LOB em linha como no modo LOB limitado. Se o tamanho do LOB for maior que esse valor, a instância migrará o LOB utilizando uma pesquisa da tabela ou da exibição de origem como no modo LOB completo padrão. Para uma tarefa de carregamento de captura de dados de alteração (CDC), a instância migra tudo LOBs usando uma pesquisa na tabela de origem, como no modo LOB completo padrão (veja a seguir). Ela faz isso independentemente do tamanho do LOB.
**nota**
Você pode migrar exibições somente para tarefas de carregamento completo.
Esse modo resulta em uma velocidade de migração que é um compromisso entre o mais rápido, modo LOB limitado, e o mais lento, modo LOB completo padrão. Use esse modo somente quando você tiver uma mistura de pequeno e grande LOBs, e a maioria deles LOBs for pequena.
Essa combinação de modo LOB completo está disponível somente para os seguintes endpoints:
+ IBM Db2 como origem
+ SAP ASE como origem ou destino
Independentemente do mecanismo especificado para o `unlimited` modo, a instância migra LOBs totalmente, sem truncamento.
+ `none`— A instância de replicação migra LOBs na tabela ou exibição selecionada usando as configurações de LOB da tarefa. Utilize essa opção para ajudar a comparar os resultados de migração com e sem configurações de LOB para a tabela ou a exibição selecionada.
Se a tabela ou exibição especificada tiver sido LOBs incluída na replicação, você poderá definir a configuração da `BatchApplyEnabled` tarefa como `true` somente ao usar o modo `limited` LOB.
Em alguns casos, é possível definir `BatchApplyEnabled` como `true` e `BatchApplyPreserveTransaction` como `false`. Nesses casos, a instância define `true` se `BatchApplyPreserveTransaction` a tabela ou visualização tem LOBs e os endpoints de origem e destino são Oracle.
+ `bulk-max-size`: defina esse valor como zero ou como um valor diferente de zero em quilobytes, dependendo do `mode`, conforme descrito nos itens anteriores. No modo `limited`, você deve definir um valor diferente para esse parâmetro.
A instância é convertida em LOBs formato binário. Portanto, para especificar o maior LOB que você precisa replicar, multiplique seu tamanho por três. Por exemplo, se o seu maior LOB for de 2 MB, defina `bulk-max-size` como 6.000 (6 MB).
## Exemplos de configurações de tabela
Veja a seguir alguns exemplos que demonstram a utilização de configurações de tabela.
**Example Carregar uma tabela segmentada por partições**
O exemplo a seguir carrega uma tabela `SALES` em sua origem de forma mais eficiente carregando-a em paralelo com base em todas as partições.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "HR",
"table-name": "SALES"
},
"parallel-load": {
"type": "partitions-auto"
}
}
]
}
```
**Example Carregar uma tabela segmentada por subpartições**
O exemplo a seguir carrega uma tabela `SALES` em sua origem do Oracle de forma mais eficiente carregando-a em paralelo com base em todas as suas subpartições.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "HR",
"table-name": "SALES"
},
"parallel-load": {
"type": "subpartitions-auto"
}
}
]
}
```
**Example Carregar uma tabela segmentada por uma lista de partições**
O exemplo a seguir carrega uma tabela `SALES` em sua origem carregando-a em paralelo por uma lista específica de partições. Aqui, as partições especificadas são nomeadas de acordo com valores começando com partes do alfabeto, por exemplo, `ABCD`, `EFGH` e assim por diante.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "HR",
"table-name": "SALES"
},
"parallel-load": {
"type": "partitions-list",
"partitions": [
"ABCD",
"EFGH",
"IJKL",
"MNOP",
"QRST",
"UVWXYZ"
]
}
}
]
}
```
**Example Carregar uma tabela segmentada do Oracle por uma lista selecionada de partições e subpartições**
O exemplo a seguir carrega uma tabela `SALES` na origem do Oracle carregando-a em paralelo por uma lista selecionada de partições e subpartições. Aqui, as partições especificadas são nomeadas de acordo com valores começando com partes do alfabeto, por exemplo, `ABCD`, `EFGH` e assim por diante. As subpartições especificadas são nomeadas de acordo com os valores começando com numerais, por exemplo, `01234` e `56789`.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "HR",
"table-name": "SALES"
},
"parallel-load": {
"type": "partitions-list",
"partitions": [
"ABCD",
"EFGH",
"IJKL",
"MNOP",
"QRST",
"UVWXYZ"
],
"subpartitions": [
"01234",
"56789"
]
}
}
]
}
```
**Example Carregar uma tabela segmentada por intervalos de valores de coluna**
O exemplo a seguir carrega uma tabela `SALES` em sua origem, carregando-a em paralelo por segmentos especificados por intervalos dos valores das colunas `SALES_NO` e `REGION`.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "HR",
"table-name": "SALES"
},
"parallel-load": {
"type": "ranges",
"columns": [
"SALES_NO",
"REGION"
],
"boundaries": [
[
"1000",
"NORTH"
],
[
"3000",
"WEST"
]
]
}
}
]
}
```
Aqui, duas colunas são especificadas para os intervalos dos segmentos com os nomes `SALES_NO` e `REGION`. Dois limites são especificados com dois conjuntos de valores de colunas (`["1000","NORTH"]` e `["3000","WEST"]`).
Esses dois limites, portanto, identificam os seguintes três segmentos da tabela a serem carregados em paralelo:
Segmento 1
As linhas com `SALES_NO` menor ou igual a 1.000 e `REGION` menor que "NORTH". Em outras palavras, o números de vendas até 1.000 na região EAST.
Segmento 2
As linhas que não são do **segmento 1** com `SALES_NO` menor ou igual a 3.000 e `REGION` menor que "WEST". Em outras palavras, os números de vendas acima de 1.000 até 3.000 nas regiões NORTH e SOUTH.
Segmento 3
Todas as demais linhas que não sejam do **Segmento 1** e do **Segmento 2**. Em outras palavras, os números de vendas acima de 3.000 na região "WEST".
**Example Carregar duas tabelas: uma segmentada por intervalos e outra segmentada por partições**
O exemplo a seguir carrega uma tabela `SALES` em paralelo com os limites do segmento que você identificar. Ele também carrega uma tabela `ORDERS` em paralelo por todas as suas partições, como nos exemplos anteriores.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "HR",
"table-name": "SALES"
},
"parallel-load": {
"type": "ranges",
"columns": [
"SALES_NO",
"REGION"
],
"boundaries": [
[
"1000",
"NORTH"
],
[
"3000",
"WEST"
]
]
}
},
{
"rule-type": "table-settings",
"rule-id": "3",
"rule-name": "3",
"object-locator": {
"schema-name": "HR",
"table-name": "ORDERS"
},
"parallel-load": {
"type": "partitions-auto"
}
}
]
}
```
**Example Carregar uma tabela LOBs usando as configurações de LOB da tarefa**
O exemplo a seguir carrega uma `ITEMS` tabela em sua fonte, incluindo todas LOBs, usando suas configurações de LOB de tarefas. A configuração de `bulk-max-size` de 100 MB é ignorada e abandonada apenas se houver uma redefinição rápida para o modo `limited` ou `unlimited`.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "INV",
"table-name": "ITEMS"
},
"lob-settings": {
"mode": "none",
"bulk-max-size": "100000"
}
}
]
}
```
**Example Carregar uma tabela LOBs usando o modo LOB limitado**
O exemplo a seguir carrega uma `ITEMS` tabela incluída LOBs em sua fonte usando o modo LOB limitado (o padrão) com um tamanho máximo não truncado de 100 MB. Qualquer um LOBs que seja maior que esse tamanho é truncado para 100 MB. Todos LOBs são carregados em linha com todos os outros tipos de dados da coluna.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "INV",
"table-name": "ITEMS"
},
"lob-settings": {
"bulk-max-size": "100000"
}
}
]
}
```
**Example Carregar uma tabela LOBs usando o modo LOB completo padrão**
O exemplo a seguir carrega uma `ITEMS` tabela em sua fonte, incluindo todas as LOBs sem truncamento, usando o modo LOB completo padrão. Todos LOBs, independentemente do tamanho, são carregados separadamente dos outros tipos de dados usando uma pesquisa para cada LOB na tabela de origem.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "INV",
"table-name": "ITEMS"
},
"lob-settings": {
"mode": "unlimited",
"bulk-max-size": "0"
}
}
]
}
```
**Example Carregar uma tabela LOBs usando o modo LOB completo combinado**
O exemplo a seguir carrega uma `ITEMS` tabela em sua fonte, incluindo todas as LOBs sem truncamento, usando a combinação do modo LOB completo. Todos LOBs com 100 MB de tamanho são carregados em linha junto com outros tipos de dados, como no modo LOB limitado. Todos os tamanhos LOBs com mais de 100 MB são carregados separadamente dos outros tipos de dados. Essa carga separada utiliza uma pesquisa para cada LOB na tabela de origem, como no modo LOB completo padrão.
```
{
"rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "table-settings",
"rule-id": "2",
"rule-name": "2",
"object-locator": {
"schema-name": "INV",
"table-name": "ITEMS"
},
"lob-settings": {
"mode": "unlimited",
"bulk-max-size": "100000"
}
}
]
}
```
# Usar mascaramento de dados para ocultar informações sensíveis
Para ocultar dados sensíveis armazenados em uma ou mais colunas das tabelas que estão sendo migradas, você pode utilizar as ações de regra de transformação de mascaramento de dados. A partir da versão 3.5.4, AWS DMS permite o uso de ações de regras de transformação de mascaramento de dados no mapeamento de tabelas, permitindo que você altere o conteúdo de uma ou mais colunas durante o processo de migração. AWS DMS carrega os dados modificados nas tabelas de destino.
AWS Database Migration Service fornece três opções para ações de regras de transformação de mascaramento de dados:
+ Mascaramento de dados: máscara de dígitos
+ Mascaramento de dados: dígitos randomizados
+ Mascaramento de dados: máscara de hash
Essas ações de regra de transformação de mascaramento de dados podem ser configuradas no mapeamento de tabela da sua tarefa de replicação, de forma semelhante a outras regras de transformação. O destino da regra deve ser definido em nível de coluna.
## Mascarar números nos dados da coluna com um caractere de mascaramento
A ação de regra de transformação de “Mascaramento de dados: máscara de dígitos” permite mascarar dados numéricos em uma ou mais colunas substituindo dígitos por um único caractere ASCII imprimível especificado por você (exceto caracteres vazios ou de espaço em branco).
Veja aqui um exemplo que mascara todos os dígitos na coluna `cust_passport_no` da tabela `customer_master` com o caractere de mascaramento `'#'` e carrega os dados mascarados na tabela de destino:
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "cust_schema",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "cust_schema",
"table-name": "customer_master",
"column-name": "cust_passport_no"
},
"rule-action": "data-masking-digits-mask",
"value": "#"
}
]
}
```
Por exemplo, se a coluna `cust_passport_no` na tabela de origem contiver o registro “C6 BGJ566669 K”, a AWS DMS tarefa gravará esses dados na tabela de destino como`"C#BGJ######K"`.
## Substituir números na coluna por números aleatórios
A regra de transformação “Mascaramento de dados: dígitos randomizados” permite a substituição de cada dígito numérico em uma ou mais colunas por um número aleatório. No exemplo a seguir, AWS DMS substitui cada dígito na `cust_passport_no` coluna da tabela `customer_master` de origem por um número aleatório e grava os dados modificados na tabela de destino:
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "cust_schema",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "cust_schema",
"table-name": "customer_master",
"column-name": "cust_passport_no"
},
"rule-action": "data-masking-digits-randomize"
}
]
}
```
Por exemplo, a AWS DMS tarefa transformará o valor `"C6BGJ566669K"` na `cust_passport_no` coluna da tabela de origem `"C1BGJ842170K"` e o gravará no banco de dados de destino.
## Substituir dados da coluna por um valor de hash
A regra de transformação “Mascaramento de dados: máscara de hash” permite substituir os dados da coluna por um hash gerado usando o algoritmo `SHA256`. O tamanho do hash sempre será de 64 caracteres; portanto, o tamanho da coluna da tabela de destino deve ser de 64 caracteres no mínimo. Outra opção é adicionar uma ação de regra de transformação `change-data-type` à coluna para aumentar a respectiva largura na tabela de destino.
O seguinte exemplo gera um valor de hash de 64 caracteres para os dados na coluna `cust_passport_no` da tabela de origem `customer_master` e carrega os dados transformados na tabela de destino depois de aumentar o tamanho da coluna:
```
{
"rules": [
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "cust_schema",
"table-name": "%"
},
"rule-action": "include"
},
{
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "2",
"rule-target": "column",
"object-locator": {
"schema-name": "cust_schema",
"table-name": "customer_master",
"column-name": "cust_passport_no"
},
"rule-action": "change-data-type",
"data-type": {
"type": "string",
"length": "100",
"scale": ""
}
},
{
"rule-type": "transformation",
"rule-id": "3",
"rule-name": "3",
"rule-target": "column",
"object-locator": {
"schema-name": "cust_schema",
"table-name": "customer_master",
"column-name": "cust_passport_no"
},
"rule-action": "data-masking-hash-mask"
}
]
}
```
Por exemplo, se a coluna `cust_passport_no` da tabela de origem contiver valor`“C6BGJ566669K”`, a AWS DMS tarefa gravará um hash `“7CB06784764C9030CCC41E25C15339FEB293FFE9B329A72B5FED564E99900C75”` na tabela de destino.
## Limitações
+ Cada opção de regra de transformação de mascaramento de dados é compatível somente com tipos de AWS DMS dados específicos:
+ É possível usar “Mascaramento de dados: máscara de dígitos” em colunas dos tipos de dados `WSTRING` e `STRING`.
+ É possível usar “Mascaramento de dados: dígitos randomizados” em colunas dos tipos de dados `WSTRING, STRING; NUMERIC, INT1, INT2, INT4, and INT8 ` com equivalentes não assinados.
+ É possível usar “Mascaramento de dados: máscara de hash” em colunas dos tipos de dados `WSTRING` e `STRING`.
Para saber mais sobre o mapeamento de tipos de AWS DMS dados para os tipos de dados do seu mecanismo de origem, consulte o mapeamento de tipos de dados do seu mecanismo de origem com tipos de AWS DMS dados. Veja os tipos de dados de origem para [Tipos de dados de origem do Oracle](CHAP_Source.Oracle.md#CHAP_Source.Oracle.DataTypes), [Tipos de dados de origem no SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.DataTypes), [Tipos de dados de origem para o PostgreSQL](CHAP_Source.PostgreSQL.md#CHAP_Source-PostgreSQL-DataTypes) e [Tipos de dados de origem do MySQL](CHAP_Source.MySQL.md#CHAP_Source.MySQL.DataTypes).
+ Usar uma ação de regra de mascaramento de dados para uma coluna com um tipo de dados incompatível causará um erro na tarefa do DMS. Consulte as configurações DataMaskingErrorPolicy de tarefas do DMS para especificar o comportamento de tratamento de erros. Para saber mais sobre o `DataMaskingErrorPolicy`, consulte [Configurações de tarefa de tratamento de erros](CHAP_Tasks.CustomizingTasks.TaskSettings.ErrorHandling.md).
+ Você pode adicionar uma ação de regra de change-data-type transformação para alterar o tipo de dados da coluna para um tipo compatível se o tipo de coluna de origem não for compatível com a opção de mascaramento que você planeja usar. O `rule-id` da transformação `change-data-type` deve ser um número menor do que o ID da regra de transformação de mascaramento para que a alteração do tipo de dados ocorra antes do mascaramento.
+ Use a ação “Mascaramento de dados: máscara de hash” para mascarar as colunas de chave primária/chave única/chave estrangeira, pois o valor de hash gerado será único e consistente. Outras duas opções de mascaramento não podem garantir a exclusividade.
+ Enquanto as ações “Mascaramento de dados: máscara de dígitos” e “Mascaramento de dados: dígitos randomizados” afetam somente os dígitos nos dados da coluna e não o tamanho dos dados, a ação “Mascaramento de dados: máscara de hash” modifica a coluna inteira, mudando o tamanho dos dados para 64 caracteres. Portanto, a tabela de destino deve ser criada adequadamente ou uma regra de change-data-type transformação deve ser adicionada à coluna que está sendo mascarada.
+ As colunas com a ação da regra de transformação de mascaramento de dados especificada são excluídas da validação de dados no AWS DMS. Se as colunas Chave primária/Chave única estiverem mascaradas, a validação de dados não será executada para essa tabela; o status de validação dessa tabela será igual a `No Primary key`.