

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á.

# Regras e operações de configurações de tabelas e coleções
<a name="CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings"></a>

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 name="CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.Wildcards"></a>

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
<a name="CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad"></a>

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
<a name="CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.LOB"></a>

É 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
<a name="CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.Examples"></a>

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"
            }
        }
     ]
}
```