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á.
# AWS DMS Componentes sem servidor
Para gerenciar os recursos necessários para realizar uma replicação, o AWS DMS Serverless tem estados granulares que revelam diferentes ações internas tomadas pelo serviço. Ao iniciar a replicação, o AWS DMS com Tecnologia Sem Servidor calcula a carga da capacidade, provisiona a capacidade calculada e inicia a replicação dos dados de acordo com os seguintes estados de replicação.
O diagrama a seguir mostra as transições de estado para uma replicação AWS DMS sem servidor.
![\[AWS DMS Estados de replicação sem servidor\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-replicationstate_updated.png)
+ O primeiro estado depois de iniciar a replicação é **Inicializando**. Nesse estado, todos os parâmetros necessários são inicializados.
+ Os estados imediatamente seguintes incluem **Preparação de recursos de metadados**, **Teste de conexão** e **Busca de metadados**. Nesses estados, o AWS DMS Serverless se conecta ao seu banco de dados de origem para obter as informações necessárias para prever a capacidade necessária.
+ Quando o estado de replicação é **Testar conexão**, o AWS DMS Serverless verifica se a conexão com seus bancos de dados de origem e destino foi configurada com êxito.
+ O estado de replicação depois de **Testando a conexão** é **Buscando metadados**. Aqui, AWS DMS recupera as informações necessárias para calcular a capacidade.
+ Depois de AWS DMS recuperar as informações necessárias, o próximo estado é **Calcular a capacidade**. Aqui, o sistema calcula o tamanho dos recursos subjacentes necessários para executar a replicação.
+ A transição de estado após **Calculando a capacidade** é **Provisionando a capacidade**. Enquanto a replicação está nesse estado, o AWS DMS com Tecnologia Sem Servidor inicializa os recursos de computação subjacentes.
+ O estado de replicação após o provisionamento bem-sucedido de todos os recursos é **Iniciando a replicação**. Nesse estado, o AWS DMS Serverless inicia a replicação dos dados. As fases de uma replicação incluem o seguinte:
+ **Carga máxima:** nesta fase, o DMS replica o datastore de origem como era quando a replicação foi iniciada.
+ **CDC (inicial):** nesta fase, o DMS replica as alterações no datastore de origem que ocorreram durante a fase de carga máxima. O DMS só executa essa fase se a configuração da tarefa `StopTaskCachedChangesNotApplied` for `false`.
+ **CDC (contínua):** após a fase inicial de CDC, o DMS replica as alterações no banco de dados de origem à medida que elas ocorrem. O DMS só continua executando a replicação após a fase inicial de CDC se a configuração da tarefa `StopTaskCachedChangesApplied` for `false`.
+ O estado final é **Em execução**. No estado **Em execução**, a replicação dos dados está em andamento.
+ Uma replicação interrompida entra no estado **Interrompida**. Uma replicação pode entrar em um estado interrompido somente para tarefas de replicação com carga total que tenham sido concluídas com êxito. Essas circunstâncias precisam ser consideradas para retomar ou reiniciar as replicações no estado interrompido ou com falha:
+ Você não pode reiniciar uma replicação que não tenha sido iniciada em 48 horas, pois AWS DMS desprovisiona os recursos.
**Topics**
+ [Endpoints compatíveis](#CHAP_Serverless.SupportedVersions)
+ [Criar uma replicação que utiliza tecnologia sem servidor](#CHAP_Serverless.create)
+ [Modificando replicações AWS DMS sem servidor](#CHAP_Serverless.modify)
+ [Configuração da computação](#CHAP_Serverless.computeconfig)
+ [Entendendo o escalonamento automático sem servidor AWS DMS](#CHAP_Serverless.autoscaling)
+ [Monitorando AWS DMS replicações sem servidor](#CHAP_Serverless.monitoring)
+ [Melhoria do throughput para migrações de carga máxima do Oracle para o Amazon Redshift e o Amazon S3](#CHAP_Serverless.Throughput)
+ [Entendendo o escalonamento automático de armazenamento sem servidor AWS DMS](#CHAP.Serverless.storage.autoscaling)
**Para AWS DMS Serverless, o painel de navegação esquerdo do AWS DMS console tem uma nova opção, replicações sem servidor.** Para **Replicações que usam tecnologia sem servidor**, especifique *Replicações* em vez de tipos de instância de replicação ou tarefas para definir uma replicação. Além disso, você especifica as unidades de capacidade máxima e mínima do DMS (DCUs) que você deseja que o DMS provisione para a replicação. Uma DCU tem 2 GB de RAM. AWS DMS cobra de sua conta cada DCU que sua replicação está usando atualmente. Para obter informações sobre AWS DMS preços, consulte [Preços do AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
AWS DMS em seguida, provisiona automaticamente os recursos de replicação com base em seus mapeamentos de tabelas e no tamanho previsto de sua carga de trabalho. Essa unidade de capacidade é um valor na faixa dos valores de unidades de capacidade mínima e máxima que você especifica.
## Endpoints compatíveis
Com o AWS DMS Serverless, você não precisa escolher e gerenciar as versões do mecanismo, pois o serviço lida com essa configuração. AWS DMS O Serverless oferece suporte às seguintes fontes:
+ MongoDB
+ Amazon DocumentDB (compatível com MongoDB)
+ Microsoft SQL Server
+ Bancos de dados compatíveis com o PostgreSQL
+ Bancos de dados compatíveis com o MySQL
+ MariaDB
+ Oracle
+ Amazon S3
+ IBM Db2
AWS DMS O Serverless oferece suporte aos seguintes destinos:
+ Microsoft SQL Server
+ PostgreSQL
+ Bancos de dados compatíveis com o MySQL
+ Oracle
+ Amazon S3
+ banco de dados de origem
+ Amazon DynamoDB
+ Amazon Kinesis Data Streams
+ Amazon Managed Streaming for Apache Kafka
+ OpenSearch Serviço Amazon
+ Amazon DocumentDB (compatível com MongoDB)
+ Amazon Neptune
Como parte do AWS DMS Serverless, você tem acesso aos comandos do console que permitem criar, configurar, iniciar e gerenciar replicações sem AWS DMS servidor. Para executar esses comandos utilizando a seção **Replicações que usam tecnologia sem servidor** do console, faça o seguinte:
+ Configure uma nova política AWS Identity and Access Management (IAM) e uma função do IAM para anexar essa política.
+ Use um AWS CloudFormation modelo para fornecer o acesso de que você precisa.
AWS DMS O Serverless exige que uma função vinculada ao serviço (SLR) exista em sua conta. AWS DMS gerencia a criação e o uso dessa função. Para obter mais informações sobre como garantir que você tem a SLR necessária, consulte [Função vinculada ao serviço para AWS DMS](slr-services-sl.md).
## Criar uma replicação que utiliza tecnologia sem servidor
Para criar uma replicação sem servidor entre dois AWS DMS endpoints existentes, faça o seguinte. Para obter informações sobre a criação de AWS DMS endpoints, consulte[Criar endpoints de origem e de destino](CHAP_Endpoints.Creating.md).
**Criar uma replicação que utiliza tecnologia sem servidor**
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/).
1. No painel de navegação, escolha **Replicações que usam tecnologia sem servidor** e **Criar replicação**.
1. Na página **Criar replicação**, especifique a configuração da replicação que utiliza tecnologia sem servidor:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Serverless.Components.html)
Na seção **Configurações**, defina as configurações necessárias para a replicação.
Na seção **Mapeamentos de tabelas**, configure o mapeamento de tabela para definir as regras para selecionar e filtrar os dados que você está replicando. Antes de especificar o mapeamento, analise a seção da documentação sobre o mapeamento de tipo de dados do banco de dados de origem e de destino. Para ter informações sobre o mapeamento de tipos de dados para os bancos de dados de origem e de destino, consulte a seção de tipos de dados referente aos seus tipos de endpoint de origem e de destino no tópico [Trabalhando com endpoints AWS do DMS](CHAP_Endpoints.md).
Na seção **Configurações de computação**, defina as seguintes configurações. Para obter mais informações sobre como definir essas configurações, consulte [Configuração da computação](#CHAP_Serverless.computeconfig).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Serverless.Components.html)
Deixe as configurações de **Manutenção** como estão.
1. Escolha **Criar replicação**.
AWS DMS cria uma replicação sem servidor para realizar sua migração.
## Modificando replicações AWS DMS sem servidor
Para modificar a configuração da replicação, utilize a ação `modify-replication-config`. Você só pode modificar uma configuração AWS DMS de replicação que esteja nos `FAILED` estados `CREATED``STOPPED`, ou. Para obter informações sobre a `modify-replication-config` ação, consulte [ModifyReplicationConfig](https://docs.aws.amazon.com/dms/latest/APIReference/API_ModifyReplicationConfig.html)a *Referência AWS Database Migration Service da API*.
**Para modificar uma configuração de replicação sem servidor usando o Console de gerenciamento da AWS**
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/).
1. No painel de navegação, escolha **Replicações que usam tecnologia sem servidor**.
1. Escolha a instância de replicação que deseja modificar. A tabela a seguir descreve as modificações que podem ser feitas com base no estado atual da replicação.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Serverless.Components.html)
**nota**
Não é possível modificar endpoints associados a uma tarefa do DMS quando o status da tarefa é “iniciando” ou “em execução”.
## Configuração da computação
Você configura o provisionamento da replicação utilizando o parâmetro Compute Config ou a seção do console. Os campos no objeto Compute Config incluem o seguinte:
| Opção | Description |
| --- | --- |
| **MinCapacityUnits** | Esse é o número mínimo de unidades de capacidade (DCU) do DMS que AWS DMS serão provisionadas. Essa também é a DCU mínima para a qual o ajuste de escala automático pode reduzir a escala verticalmente. |
| **MaxCapacityUnits** | Essa é a quantidade máxima de unidades de capacidade do DMS (DCU) que o AWS DMS pode provisionar, dependendo da previsão de capacidade da replicação. Essa também é a DCU máxima para a qual o ajuste de escala automático pode aumentar a escala verticalmente. |
| **KmsKeyId** | Escolha a chave de criptografia a ser utilizada para criptografar o armazenamento da replicação e as informações de conexão. Se você escolher (Padrão) aws/dms, AWS DMS usa a chave KMS padrão associada à sua conta e. Região da AWS Uma descrição e o número da sua conta aparecem juntamente com o ARN da chave. Para obter mais informações sobre a utilização da chave de criptografia, consulte [Configurando uma chave de criptografia e especificando permissões AWS KMS](CHAP_Security.md#CHAP_Security.EncryptionKey). Neste tutorial, deixe (Padrão) aws/dms escolhido. |
| **ReplicationSubnetGroupId** | Escolha o grupo de sub-rede de replicação na VPC selecionada em que deseja que instância de replicação seja criada. Se o banco de dados de origem estiver em uma VPC, escolha o grupo de sub-redes que contém o banco de dados de origem como o local da instância de replicação. Para obter mais informações sobre grupos de sub-rede de replicação, consulte [Criar um grupo de sub-rede de replicação](CHAP_ReplicationInstance.VPC.md#CHAP_ReplicationInstance.VPC.Subnets). |
| **VpcSecurityGroupIds** | A instância de replicação é criada em um VPC. Se o banco de dados de origem estiver em uma VPC, selecione o grupo de segurança da VPC que fornece acesso à instância de banco de dados em que o banco de dados está localizado. |
| **PreferredMaintenanceWindow** | Esse parâmetro define um período semanal durante o qual a manutenção do sistema pode ocorrer, em Universal Coordinated Time (UTC). O padrão é uma janela de 30 minutos selecionada aleatoriamente a partir de um bloco de 8 horas por vez Região da AWS, ocorrendo em um dia aleatório da semana. |
| **MultiAZ** | A configuração desse parâmetro opcional cria uma réplica em espera da replicação em outra zona de disponibilidade para suporte a failover. Se você pretender utilizar a captura de dados de alteração (CDC) ou a replicação contínua, ative essa opção. |
## Entendendo o escalonamento automático sem servidor AWS DMS
Depois de provisionar uma replicação e ela estar no `RUNNING` estado, o AWS DMS serviço gerencia a capacidade dos recursos subjacentes de se adaptarem às mudanças nas cargas de trabalho. Esse gerenciamento escala os recursos da replicação com base nas seguintes configurações da replicação:
+ `MinCapacityUnits`
+ `MaxCapacityUnits`
As replicações aumentam a escala verticalmente após um período de utilização excessiva e reduzem a escala verticalmente quando a utilização da capacidade fica abaixo do limite mínimo de utilização da capacidade por um período mais longo.
**nota**
As replicações com tecnologia sem servidor não podem ser reduzidas automaticamente enquanto uma carga máxima estiver em andamento.
### Ajustando o escalonamento automático sem servidor AWS DMS
Para ajustar seus parâmetros de escalonamento automático de replicação, recomendamos que você `MaxCapacityUnits` defina o valor máximo e deixe AWS DMS gerenciar o provisionamento de recursos. É recomendável escolher a maior configuração da capacidade máxima de DCU para permitir maior benefício no ajuste de escala automático, a fim de acomodar picos no volume de transações. A calculadora de preços mostra o custo mensal máximo se a replicação utilizar continuamente a DCU máxima. A DCU máxima não representa o custo real, pois você paga apenas pela capacidade utilizada.
Se sua replicação não estiver usando seus recursos em sua capacidade total, AWS DMS desprovisionará gradualmente os recursos para economizar seus custos. No entanto, como o provisionamento e o desprovisionamento de recursos demoram, é recomendável definir a configuração `MinCapacityUnits` como um valor que possa tratar qualquer pico repentino esperado na workload de replicação. Isso evitará que sua replicação seja subprovisionada e, ao mesmo tempo, provisionará recursos para o nível mais alto da AWS DMS carga de trabalho.
Se você subprovisionar a replicação com uma configuração de capacidade máxima muito baixa para os requisitos dos dados ou uma capacidade mínima muito baixa para lidar com picos repentinos na workload de replicação, é provável que a métrica `CapacityUtilization` se evidencie consistentemente em seu valor máximo. Isso pode fazer com que a replicação falhe. Se sua replicação falhar devido a recursos subprovisionados, AWS DMS cria um out-of-memory evento em seus registros de replicação. Quando ocorre uma out-of-memory condição devido a um aumento repentino na carga de trabalho de replicação ou na configuração ajustada, o sistema tem recursos integrados de auto-scaling para lidar com a situação e retomar o processamento. No entanto, esse mecanismo de recuperação automática não é imediato e pode levar algum tempo para se tornar efetivo. Para uma recuperação mais rápida, você pode realizar uma ação manual modificando a configuração da tarefa, especificamente aumentando o valor `MinCapacityUnits` e retomando a tarefa. Essa intervenção manual fornece uma resolução mais rápida para o out-of-memory erro em comparação com a espera pelo processo de auto-scaling automático.
## Monitorando AWS DMS replicações sem servidor
AWS fornece várias ferramentas para monitorar suas replicações AWS DMS sem servidor e responder a possíveis incidentes:
+ [AWS DMS métricas de replicação sem servidor](#CHAP_Serverless.monitoring.metrics)
+ [AWS DMS registros de replicação sem servidor](#CHAP_Serverless.monitoring.logs)
### AWS DMS métricas de replicação sem servidor
O monitoramento da replicação sem servidor inclui CloudWatch métricas da Amazon para as seguintes estatísticas. Essas estatísticas são agrupadas por cada replicação que utiliza tecnologia sem servidor.
| Métrica | Unidades | Description |
| --- | --- | --- |
| CapacityUtilization | Percentual | A porcentagem de memória utilizada pela replicação que utiliza tecnologia sem servidor |
| CDCIncomingMudanças | Percentual | O número total de eventos de alteração em um point-in-time que estão aguardando para serem aplicados ao alvo. Observe que isso não é o mesmo que uma medida da taxa de alteração de transação do endpoint de origem. Um grande número dessa métrica geralmente indica que não AWS DMS é possível aplicar as alterações capturadas em tempo hábil, causando alta latência alvo. |
| CDCLatencyFonte | Segundos | A lacuna, em segundos, entre o último evento capturado do endpoint de origem e a data e hora atual do sistema da AWS DMS instância. CDCLatencyA origem representa a latência entre a origem e a instância de replicação. CDCLatencyFonte alta significa que o processo de captura de alterações da fonte está atrasado. Para identificar a latência em uma replicação contínua, você pode visualizar essa métrica junto com CDCLatency o Target. Se a CDCLatency Origem e o CDCLatency Destino estiverem altos, investigue primeiro a CDCLatency Fonte. CDCLatencyA origem pode ser 0 quando não há atraso de replicação entre a origem e a replicação. CDCLatencyA origem também pode se tornar zero quando a replicação tenta ler o próximo evento no log de transações da origem e não há novos eventos em comparação com a última vez que ela foi lida da origem. Quando isso acontece, a replicação redefine a CDCLatency Fonte para 0. |
| CDCLatencyAlvo | Segundos | O intervalo, em segundos, entre o primeiro timestamp de evento em espera de confirmação no destino e o timestamp atual da instância do AWS DMS . A latência do destino é a diferença entre a hora do servidor da instância de replicação e o ID do evento não confirmado mais antigo encaminhado para um componente de destino. Em outras palavras, a latência de destino é a diferença do timestamp entre a instância de replicação e o evento mais antigo aplicado, mas não confirmado pelo endpoint de TRG (99%). Quando a CDCLatency meta está alta, isso indica que o processo de aplicação de eventos de alteração à meta está atrasado. Para identificar a latência em uma replicação contínua, você pode visualizar essa métrica junto com CDCLatency a Fonte. Se a CDCLatency meta for alta, mas a CDCLatency fonte não for alta, investigue se: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Serverless.Components.html) |
| CDCThroughputBandwidthTarget | KB por segundo | Dados de saída transmitidos para o destino em KB por segundo. CDCThroughputA largura de banda registra os dados de saída transmitidos nos pontos de amostragem. Se nenhum tráfego de rede for encontrado, o valor será zero. Como a CDC não emite transações prolongadas, o tráfego de rede pode não ser registrado. |
| CDCThroughputRowsSource | Linhas por segundo | As alterações de entrada na origem em linhas por segundo. |
| CDCThroughputRowsTarget | Linhas por segundo | As alterações de saída para o destino em linhas por segundo. |
| FullLoadThroughputBandwidthTarget | KB por segundo | Dados de saída transmitidos de uma carga máxima para o destino em KB por segundo. |
| FullLoadThroughputRowsTarget | Linhas por segundo | As alterações de saída de uma carga completa para o destino em linhas por segundo. |
### AWS DMS registros de replicação sem servidor
Você pode usar CloudWatch a Amazon para registrar informações de replicação durante um processo de AWS DMS migração. Você ativa o registro em log quando seleciona as configurações da replicação.
As replicações sem servidor carregam registros de status em sua CloudWatch conta para fornecer maior visibilidade sobre o progresso da replicação e ajudar na solução de problemas.
AWS DMS carrega registros vinculados sem servidor para um grupo de registros dedicado com o prefixo. `dms-serverless-replication-` Nesse desse grupo de logs, há um fluxo de logs chamado `dms-serverless-replication-orchestrator-`. Esse fluxo de logs relata o estado da replicação e uma mensagem associada fornecendo mais detalhes sobre o trabalho que está sendo realizado nesse estágio. Para obter exemplos de entradas de logs, consulte o [Exemplos de logs de replicações que usam tecnologia sem servidor](#CHAP_Serverless.monitoring.logs.examples) a seguir.
**nota**
AWS DMS não cria o grupo de logs nem o stream até que você execute a replicação. AWS DMS não cria o grupo de logs ou o stream se você criar apenas a replicação.
Para visualizar logs de uma tarefa executada, siga estas etapas:
1. Abra o AWS DMS console e escolha **Replicações sem servidor** no painel de navegação. A caixa de diálogo **Replicações que usam tecnologia sem servidor** é exibida.
1. Vá para a seção **Configuração** e escolha **Visualizar logs sem servidor** na coluna Geral. O grupo CloudWatch de registros é aberto.
Se sua replicação falhar, AWS DMS cria uma entrada de registro com um estado de `failed` replicação e uma mensagem descrevendo o motivo da falha. Você deve verificar seus CloudWatch registros como a primeira etapa para solucionar uma falha na replicação.
**nota**
Assim como no AWS DMS Standard, você tem a opção de ativar um registro mais granular sobre o progresso da própria migração de dados; ou seja, os registros emitidos pela tarefa de replicação subjacente. É possível habilitar esses logs nas suas configurações de replicação definindo o `EnableLogging` no campo `Logging` como `true`. Veja o exemplo de JSON a seguir:
```
{
"Logging": {
"EnableLogging": true
}
}
```
Se você ativar esses logs, eles só começarão a aparecer durante o estágio `running` da replicação que utiliza tecnologia sem servidor. Eles aparecerão no mesmo grupo de logs do fluxo de logs anterior, mas estarão no novo fluxo de logs `dms-serverless-serv-res-id-{unique identifier}`. Consulte a seção a seguir para obter informações sobre como interpretar logs de replicações que usam tecnologia sem servidor.
#### Exemplos de logs de replicações que usam tecnologia sem servidor
Esta seção inclui um exemplo de entradas de log para replicações que usam tecnologia sem servidor.
##### Exemplo: Início da replicação
Quando você executa uma replicação sem servidor, AWS DMS cria uma entrada de registro semelhante à seguinte:
```
{'replication_state':'initializing', 'message': 'Initializing the replication workflow.'}
```
##### Exemplo: Falha na replicação
Se um dos endpoints da replicação não estiver configurado corretamente, AWS DMS cria uma entrada de registro semelhante à seguinte:
```
{'replication_state':'failed', 'message': 'Test connection failed for endpoint X.', 'failure_message': 'X'}
```
Se você vir essa mensagem no log após uma falha, verifique se o endpoint especificado está íntegro e configurado corretamente.
## Melhoria do throughput para migrações de carga máxima do Oracle para o Amazon Redshift e o Amazon S3
AWS DMS fornece um desempenho de taxa de transferência significativamente aprimorado para migrações de carga total da Oracle para o Amazon Redshift e o Amazon S3. O DMS habilita automaticamente esse recurso para tabelas sem a opção `parallel-load` personalizada em mapeamentos de tabela. Para tabelas com opções personalizadas de carregamento paralelo, o DMS com tecnologia sem servidor distribui a carga da tabela com base nas configurações de mapeamento de tabela fornecidas. Para usar o throughput aprimorado, faça o seguinte:
+ Forneça regras de seleção que não façam referência a partições ou limites. Por exemplo, se as configurações da tabela nos mapeamentos de tabela contiverem `parallel-load`, o DMS com tecnologia sem servidor não usará o recurso de throughput aprimorado. Para obter mais informações, consulte [Regras de seleção e ações](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md).
+ Defina `MaxFileSize` e `WriteBufferSize` como 64 MB. Para obter mais informações, consulte [Configurações de endpoint ao usar o Amazon Redshift como destino para AWS DMS](CHAP_Target.Redshift.md#CHAP_Target.Redshift.ConnectionAttrib).
+ Recomendamos configurar `CompressCsvFiles` como `true` para um datastore com dados esparsos e como `false` para um datastore com dados densos.
+ Defina as seguintes configurações da tarefa como `0`:
+ `ParallelLoadThreads`
+ `ParallelLoadQueuesPerThread`
+ `ParallelApplyThreads`
+ `ParallelApplyQueuesPerThread`
+ `ParallelLoadBufferSize`
+ Defina `MaxFullLoadSubTasks` como `49` para oferecer suporte à migração de dados paralela.
+ Defina `LOB mode` como `inline`. Para obter mais informações, consulte [Configurando o suporte LOB para bancos de dados de origem em uma tarefa AWS DMS](CHAP_Tasks.LOBSupport.md).
AWS DMS não fornece desempenho aprimorado de taxa de transferência para as seguintes replicações:
+ Replicações com tabelas usando carga paralela. Para obter mais informações, consulte [Utilizar carga paralela para tabelas, visualizações e coleções selecionadas](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad).
+ Replicações com regras de transformação de dados.
+ Replicações com regras de filtro.
+ Replicações com a regra de transformação .
+ Replicações com o Amazon Redshift Serverless como destino.
## Entendendo o escalonamento automático de armazenamento sem servidor AWS DMS
Quando você inicia um processo de replicação, o AWS DMS Serverless aloca 100 GB de armazenamento inicial para a replicação. O armazenamento é consumido principalmente por arquivos de log e transações armazenadas em cache. Para transações armazenadas em cache, o armazenamento só é usado quando elas devem ser gravadas em disco. Portanto, o AWS DMS Serverless não usa uma quantidade significativa de armazenamento. Algumas exceções incluem o seguinte:
+ Tabelas muito grandes que incorrem em uma carga de transação significativa. Carregar uma tabela grande pode demorar um tempo, então transações armazenadas em cache têm mais chances de ser gravadas em disco durante o carregamento de uma tabela grande.
+ Tarefas configuradas para pausar antes de carregar transações em cache. Nesse caso, todas as transações são armazenadas em cache até que o carregamento seja concluído para todas as tabelas. Com essa configuração, boa parte do armazenamento pode ser consumida por transações armazenadas em cache.
+ Tarefas configuradas com tabelas sendo carregadas no Amazon Redshift. Essa configuração não é um problema quando o destino é o Amazon Aurora.
Portanto, o AWS DMS Serverless monitora a utilização do armazenamento a cada 15 minutos. Quando o armazenamento alocado é utilizado em 90%, o AWS DMS Serverless aumenta a replicação com armazenamento adicional. Caso seja utilizado 100% do armazenamento da replicação e as tarefas de replicação falhem antes ou durante o processo de ajuste de escala, o DMS sem servidor retomará as tarefas quando o ajuste de escala for concluído com êxito.
**nota**
As operações de carga máxima são reiniciadas desde o início para qualquer tabela incompleta quando você retoma uma tarefa interrompida anteriormente.
Não há impacto no desempenho da tarefa do DMS durante o evento de ajuste escala do armazenamento.
Não há período de resfriamento entre dois eventos de ajuste de escala automático do armazenamento.