Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # AWS DMS Componenti serverless Per gestire le risorse necessarie per eseguire una replica, AWS DMS Serverless dispone di stati granulari che rivelano le diverse azioni interne intraprese dal servizio. Quando si avvia la replica, AWS DMS serverless calcola il carico della capacità, alloca la capacità calcolata e avvia la replica dei dati secondo i seguenti stati di replica. Il diagramma seguente mostra le transizioni di stato per una replica serverless. AWS DMS ![\[AWS DMS Stati di replica senza server\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/images/datarep-replicationstate_updated.png) + Il primo stato dopo l'avvio della replica è **Inizializzazione in corso**. In questo stato vengono inizializzati tutti i parametri richiesti. + Gli stati immediatamente successivi sono **Preparazione delle risorse di metadati in corso**, **Verifica della connessione in corso** e **Recupero dei metadati in corso**. In questi stati, AWS DMS Serverless si connette al database di origine per ottenere le informazioni necessarie a prevedere la capacità necessaria. + Quando lo stato di replica è **Testing Connection**, AWS DMS Serverless verifica che la connessione ai database di origine e di destinazione sia configurata correttamente. + Lo stato di replica dopo **Verifica della connessione in corso** è **Recupero dei metadati in corso**. Qui AWS DMS recupera le informazioni necessarie per calcolare la capacità. + Una volta AWS DMS recuperate le informazioni necessarie, lo stato successivo è **Calcolo** della capacità. In questo stato, il sistema calcola la dimensione delle risorse sottostanti necessarie per eseguire la replica. + La transizione di stato successiva a **Calcolo della capacità in corso** è **Capacità di allocazione**. Quando la replica è in questo stato, AWS DMS serverless inizializza le risorse di elaborazione sottostanti. + Lo stato di replica dopo che tutte le risorse sono state correttamente allocate è **Avvio della replica**. In questo stato, AWS DMS Serverless inizia la replica dei dati. Le fasi di una replica includono quanto segue: + **Carico completo:** in questa fase, DMS replica il data store di origine com'era all'inizio della replica. + **CDC (iniziale):** in questa fase, DMS replica le modifiche al data store di origine avvenute durante la fase di caricamento completo. DMS esegue questa fase solo se l'impostazione dell'attività è`StopTaskCachedChangesNotApplied`. `false` + **CDC (in corso):** dopo la fase CDC iniziale, DMS replica le modifiche nel database di origine non appena si verificano. DMS continua a eseguire la replica dopo la fase iniziale del CDC solo se l'impostazione dell'attività è. `StopTaskCachedChangesApplied` `false` + Lo stato finale è **In esecuzione**. Lo stato **In esecuzione** indica che la replica dei dati è in corso. + **Una replica interrotta entra nello stato Interrotto.** Una replica può passare allo stato di arresto solo per le attività di replica a pieno carico che sono state completate con successo. È necessario tenere conto di queste circostanze per riprendere o riavviare le repliche nello stato interrotto o fallito: + Non è possibile riavviare una replica che non viene avviata da 48 ore poiché depredispone le risorse. AWS DMS **Topics** + [Endpoint supportati](#CHAP_Serverless.SupportedVersions) + [Creazione di una replica serverless](#CHAP_Serverless.create) + [Modifica delle repliche serverless AWS DMS](#CHAP_Serverless.modify) + [Configurazione del calcolo](#CHAP_Serverless.computeconfig) + [Comprendere la scalabilità automatica in modalità serverless AWS DMS](#CHAP_Serverless.autoscaling) + [Monitoraggio delle repliche senza server AWS DMS](#CHAP_Serverless.monitoring) + [Throughput migliorato per le migrazioni a pieno carico da Oracle ad Amazon Redshift e Amazon S3](#CHAP_Serverless.Throughput) + [Comprendere la scalabilità automatica dello storage in modalità serverless AWS DMS](#CHAP.Serverless.storage.autoscaling) **Per AWS DMS Serverless, il pannello di navigazione a sinistra della AWS DMS console presenta una nuova opzione, le repliche Serverless.** Per **Repliche serverless** è necessario specificare le *repliche* anziché i tipi o le attività dell'istanza di replica per definire una replica. Inoltre, si specificano le unità di capacità DMS massima e minima (DCUs) di cui si desidera che DMS fornisca per la replica. Una DCU è composta da 2 GB di RAM. AWS DMS fattura all'account ogni DCU attualmente utilizzata dalla replica. Per informazioni sui AWS DMS prezzi, consulta la pagina dei [prezzi AWS del Database Migration Service](https://aws.amazon.com/dms/pricing/). AWS DMS quindi effettua automaticamente il provisioning delle risorse di replica in base alle mappature delle tabelle e alla dimensione prevista del carico di lavoro. Questa unità di capacità è un valore compreso nell'intervallo dei valori delle unità di capacità minime e massime specificati. ## Endpoint supportati Con AWS DMS Serverless, non è necessario scegliere e gestire le versioni del motore, poiché il servizio gestisce tale impostazione. AWS DMS Serverless supporta le seguenti fonti: + MongoDB + Amazon DocumentDB (compatibile con MongoDB) + Microsoft SQL Server + Database compatibili con PostgreSQL + Database compatibili con MySQL + MariaDB + Oracle + Simple Storage Service (Amazon S3) + IBM Db2 AWS DMS Serverless supporta i seguenti obiettivi: + Microsoft SQL Server + PostgreSQL + Database compatibili con MySQL + Oracle + Simple Storage Service (Amazon S3) + Amazon Redshift + Amazon DynamoDB + Flusso di dati Amazon Kinesis + Amazon Managed Streaming per Apache Kafka + OpenSearch Servizio Amazon + Amazon DocumentDB (compatibile con MongoDB) + Amazon Neptune Come parte di AWS DMS Serverless, hai accesso ai comandi della console che ti consentono di creare, configurare, avviare e gestire repliche AWS DMS serverless. Per usare questi comandi con la sezione **Repliche serverless** della console, devi eseguire una delle seguenti operazioni: + Imposta una nuova policy AWS Identity and Access Management (IAM) e un nuovo ruolo IAM a cui allegare quella policy. + Utilizza un AWS CloudFormation modello per fornire l'accesso di cui hai bisogno. AWS DMS Serverless richiede che nel tuo account esista un ruolo collegato al servizio (SLR). AWS DMS gestisce la creazione e l'utilizzo di questo ruolo. Per ulteriori informazioni su come verificare la disponibilità del ruolo collegato al servizio necessario, consulta [Ruolo collegato al servizio per AWS DMS](slr-services-sl.md). ## Creazione di una replica serverless Per creare una replica serverless tra due AWS DMS endpoint esistenti, procedi come segue. Per informazioni sulla creazione di AWS DMS endpoint, consulta. [Creazione di endpoint di origine e destinazione](CHAP_Endpoints.Creating.md) **Creazione di una replica serverless** 1. Accedi a Console di gestione AWS e apri la AWS DMS console alla [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). 1. Nel riquadro di navigazione scegli **Repliche serverless**, quindi seleziona **Crea replica**. 1. Nella pagina **Crea replica** specifica la configurazione della replica serverless: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Serverless.Components.html) Nella sezione **Impostazioni** configura le impostazioni richieste dalla replica. Nella sezione **Mappature delle tabelle** imposta la mappatura delle tabelle per definire le regole per selezionare e filtrare i dati che stai replicando. Prima di specificare la mappatura, consulta la sezione della documentazione sulla mappatura del tipo di dati per il database di origine e di destinazione. Per informazioni sulla mappatura dei tipi di dati per i database di origine e di destinazione, consulta la sezione sui tipi di dati per i tipi di endpoint di origine e di destinazione nell'argomento. [Utilizzo degli AWS endpoint DMS](CHAP_Endpoints.md) Nella sezione **Impostazioni di calcolo** configura le seguenti opzioni. Per informazioni sulle impostazioni di configurazione del calcolo, consulta [Configurazione del calcolo](#CHAP_Serverless.computeconfig). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Serverless.Components.html) Lascia le impostazioni di **Manutenzione** invariate. 1. Scegli **Crea replica**. AWS DMS crea una replica senza server per eseguire la migrazione. ## Modifica delle repliche serverless AWS DMS Per modificare la configurazione della replica, utilizza l'azione `modify-replication-config`. È possibile modificare solo una configurazione di AWS DMS replica che si trova negli stati`CREATED`, `STOPPED` o. `FAILED` Per informazioni sull'`modify-replication-config`azione, consulta [ModifyReplicationConfig](https://docs.aws.amazon.com/dms/latest/APIReference/API_ModifyReplicationConfig.html)l'*AWS Database Migration Service API Reference.* **Per modificare una configurazione di replica senza server utilizzando il Console di gestione AWS** 1. [Accedere a Console di gestione AWS e aprire la AWS DMS console nella versione v2/. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/) 1. Nel riquadro di navigazione scegli **Repliche serverless**. 1. Scegli la replica che desideri modificare. La tabella seguente descrive le modifiche che è possibile apportare in base allo stato corrente della replica. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Serverless.Components.html) **Nota** Non è possibile modificare gli endpoint associati a un'attività DMS quando lo stato dell'attività è in avvio o in esecuzione. ## Configurazione del calcolo È possibile configurare il provisioning della replica utilizzando il parametro Configurazione del calcolo o la sezione della console. I campi dell'oggetto Configurazione del calcolo sono i seguenti: | Opzione | Description | | --- | --- | | **MinCapacityUnits** | Questo è il numero minimo di unità di capacità DMS (DCU) che verranno fornite. AWS DMS È anche la DCU minima a cui il dimensionamento automatico può essere ridotto. | | **MaxCapacityUnits** | È il numero massimo di unità di capacità DMS (DCU) che AWS DMS può allocare, in base alla previsione della capacità di replica. È anche la DCU massima a cui il dimensionamento automatico può essere aumentato. | | **KmsKeyId** | La chiave di crittografia da utilizzare per crittografare le informazioni di connessione e archiviazione della replica. Se scegli (Predefinito) aws/dms, AWS DMS utilizza la chiave KMS predefinita associata al tuo account e. Regione AWS Vengono mostrati una descrizione e il numero di account, insieme all'ARN della chiave. Per ulteriori informazioni sull'utilizzo della chiave di crittografia, consulta [Impostazione di una chiave di crittografia e specificazione delle autorizzazioni AWS KMS](CHAP_Security.md#CHAP_Security.EncryptionKey). Per questo tutorial, lascia selezionato (Impostazione predefinita) aws/dms. | | **ReplicationSubnetGroupId** | Il gruppo di sottoreti di replica nel VPC selezionato in cui desideri creare la replica. Se il database di origine è in un VPC, scegli il gruppo di sottoreti che contiene il database di origine come posizione per la replica. Per ulteriori informazioni sui gruppi di sottoreti di replica, consulta [Creazione di un gruppo di sottoreti di replica](CHAP_ReplicationInstance.VPC.md#CHAP_ReplicationInstance.VPC.Subnets). | | **VpcSecurityGroupIds** | L'istanza di replica viene creata in un VPC. Se il database di origine è in un VPC, seleziona il gruppo di sicurezza VPC che fornisce l'accesso all'istanza database in cui si trova il database. | | **PreferredMaintenanceWindow** | Questo parametro definisce un intervallo temporale settimanale nel fuso orario UTC (Universal Coordinated Time) durante il quale può verificarsi la manutenzione del sistema. L'impostazione predefinita è una finestra di 30 minuti selezionata a caso da un intervallo di tempo di 8 ore per volta Regione AWS, che si verifica in un giorno casuale della settimana. | | **MultiAZ** | Questo parametro facoltativo crea una replica di standby della replica in un'altra zona di disponibilità per il supporto del failover. Se desideri utilizzare l'acquisizione dei dati di modifica (CDC) o la replica continua, ti consigliamo di attivare questa opzione. | ## Comprendere la scalabilità automatica in modalità serverless AWS DMS Dopo aver effettuato il provisioning di una replica che si trova `RUNNING` nello stato in cui si trova, il AWS DMS servizio gestisce la capacità delle risorse sottostanti di adattarsi ai carichi di lavoro in evoluzione. Questa gestione dimensiona le risorse di replica in base alle seguenti impostazioni di replica: + `MinCapacityUnits` + `MaxCapacityUnits` Le repliche aumentano dopo il periodo di superamento della soglia di utilizzo massima e diminuiscono quando l'utilizzo della capacità è inferiore alla soglia di utilizzo minima della capacità per un lungo periodo. **Nota** Le repliche serverless non possono essere ridimensionate automaticamente mentre è in corso un carico completo. ### Ottimizzazione AWS DMS della scalabilità automatica in modalità serverless Per ottimizzare i parametri di scalabilità automatica della replica, si consiglia di impostarli sul valore massimo e di lasciare che sia possibile `MaxCapacityUnits` gestire il provisioning delle risorse. AWS DMS Ti consigliamo di scegliere l'impostazione più ampia della capacità massima di DCU per sfruttare al massimo il dimensionamento automatico e far fronte ai picchi di volume delle transazioni. Il calcolatore dei prezzi mostra il costo mensile massimo se la replica utilizza continuamente la capacità massima di DCU. La capacità massima di DCU non rappresenta il costo effettivo, in quanto paghi solo per ciò che utilizzi. Se la replica non utilizza le risorse a piena capacità, AWS DMS procederà gradualmente al rifornimento delle risorse per ridurre i costi. Tuttavia, poiché il provisioning e l'annullamento del provisioning delle risorse richiedono tempo, ti consigliamo di impostare `MinCapacityUnits` su un valore in grado di gestire eventuali picchi improvvisi previsti nel carico di lavoro di replica. In questo modo si eviterà che la replica venga sottoposta a un provisioning insufficiente e al contempo si riforniranno le risorse per un livello di carico di AWS DMS lavoro più elevato. Se il provisioning della replica è insufficiente per l'impostazione della capacità massima troppo bassa per i requisiti dei dati o della capacità minima troppo bassa per gestire picchi improvvisi nel carico di lavoro di replica, è possibile che la metrica `CapacityUtilization` raggiunga costantemente il suo valore massimo. causando l'esito negativo della replica. Se la replica fallisce a causa di un approvvigionamento insufficiente delle risorse, crea un evento nei log di replica. AWS DMS out-of-memory Quando si verifica una out-of-memory condizione dovuta a un improvviso picco nel carico di lavoro di replica o a una configurazione ottimizzata, il sistema dispone di funzionalità di auto-scaling integrate per gestire la situazione e riprendere l'elaborazione. Tuttavia, questo meccanismo di ripristino automatico non è immediato e potrebbe richiedere del tempo prima che diventi efficace. Per un ripristino più rapido, è possibile intraprendere un'azione manuale modificando la configurazione dell'attività, in particolare aumentando il `MinCapacityUnits` valore e quindi riprendendo l'attività. Questo intervento manuale fornisce una risoluzione più rapida dell' out-of-memoryerrore rispetto all'attesa del processo di auto-scaling automatico. ## Monitoraggio delle repliche senza server AWS DMS AWS offre diversi strumenti per monitorare le repliche AWS DMS serverless e rispondere a potenziali incidenti: + [AWS DMS metriche di replica senza server](#CHAP_Serverless.monitoring.metrics) + [AWS DMS log di replica senza server](#CHAP_Serverless.monitoring.logs) ### AWS DMS metriche di replica senza server Il monitoraggio della replica senza server include i CloudWatch parametri di Amazon per le seguenti statistiche. Queste statistiche sono raggruppate per ogni replica serverless. | Metrica | Unità | Description | | --- | --- | --- | | CapacityUtilization | Percentuale | Percentuale di memoria utilizzata dalla replica serverless | | CDCIncomingModifiche | Percentuale | Il numero totale di eventi di modifica in corso point-in-time che attendono di essere applicati all'obiettivo. Tieni presente che questo non equivale alla misura della frequenza di modifica della transazione dell'endpoint di origine. Un numero elevato per questa metrica di solito indica che non AWS DMS è in grado di applicare le modifiche acquisite in modo tempestivo, causando così un'elevata latenza target. | | CDCLatencyFonte | Secondi | L'intervallo, in secondi, tra l'ultimo evento acquisito dall'endpoint di origine e il timestamp corrente del sistema dell' AWS DMS istanza. CDCLatencyL'origine rappresenta la latenza tra l'origine e l'istanza di replica. High CDCLatency Source significa che il processo di acquisizione delle modifiche dalla fonte viene ritardato. Per identificare la latenza in una replica in corso, puoi visualizzare questa metrica insieme a Target. CDCLatency Se sia CDCLatency Source che CDCLatency Target sono elevati, analizza CDCLatency prima Source. CDCLatencyL'origine può essere 0 quando non vi è alcun ritardo di replica tra l'origine e la replica. CDCLatencyL'origine può inoltre diventare zero quando la replica tenta di leggere l'evento successivo nel registro delle transazioni dell'origine e non ci sono nuovi eventi rispetto all'ultima lettura dall'origine. Quando ciò accade, la replica reimposta il CDCLatency codice Source su 0. | | CDCLatencyObiettivo | Secondi | Il divario, in secondi, tra il primo timestamp dell'evento in attesa di commit sulla destinazione e il timestamp corrente dell'istanza AWS DMS . La latenza della destinazione è la differenza tra l'ora del server dell'istanza di replica e l'ID dell'evento non confermato meno recente inoltrato a un componente di destinazione. In altre parole, la latenza della destinazione è la differenza di timestamp tra l'istanza di replica e l'evento meno recente applicato ma non confermato dall'endpoint di destinazione (99%). Quando CDCLatency Target è alto, indica che il processo di applicazione degli eventi di modifica alla destinazione è in ritardo. Per identificare la latenza in una replica in corso, puoi visualizzare questa metrica insieme a Source. CDCLatency Se CDCLatency Target è alto ma CDCLatency Source non lo è, verifica se: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Serverless.Components.html) | | CDCThroughputBandwidthTarget | KB al secondo | Dati in uscita trasmessi per la destinazione in KB al secondo. CDCThroughputLa larghezza di banda registra i dati in uscita trasmessi sui punti di campionamento. Se non viene rilevato traffico di rete, il valore è zero. CDC non emette transazioni di lunga durata, pertanto il traffico di rete potrebbe non essere registrato. | | CDCThroughputRowsSource | Righe al secondo | Modifiche in entrata dall'origine in righe al secondo. | | CDCThroughputRowsTarget | Righe al secondo | Modifiche in uscita per la destinazione in righe al secondo. | | FullLoadThroughputBandwidthTarget | KB al secondo | Dati in uscita trasmessi da un pieno carico per la destinazione in KB al secondo. | | FullLoadThroughputRowsTarget | Righe al secondo | Modifiche in uscita da un pieno carico per la destinazione in righe al secondo. | ### AWS DMS log di replica senza server Puoi utilizzare Amazon CloudWatch per registrare le informazioni di replica durante un processo di AWS DMS migrazione. Puoi abilitare la registrazione quando selezioni le impostazioni di replica. Le repliche serverless caricano i log di stato CloudWatch sul tuo account per fornire una maggiore visibilità sullo stato di avanzamento della replica e per facilitare la risoluzione dei problemi. AWS DMS carica i log collegati senza server in un gruppo di log dedicato con il prefisso. `dms-serverless-replication-` All'interno di questo gruppo di log è presente un flusso di log denominato `dms-serverless-replication-orchestrator-`. Questo flusso di log riporta lo stato della replica e un messaggio associato che fornisce ulteriori dettagli sul lavoro svolto in questa fase. Per esempi di voci di log, consulta [Esempi di log della replica serverless](#CHAP_Serverless.monitoring.logs.examples) di seguito. **Nota** AWS DMS non crea né il gruppo di log né lo stream finché non si esegue la replica. AWS DMS non crea il gruppo o lo stream di log se si crea solo la replica. Per visualizzare i log di una replica eseguita, procedi come segue: 1. Apri la AWS DMS console e scegli **Repliche senza server dal pannello** di navigazione. Viene visualizzata la finestra di dialogo **Repliche serverless**. 1. Vai alla sezione **Configurazione** e scegli **Visualizza i log serverless** nella colonna Generale. Si apre il gruppo di CloudWatch log. Se la replica fallisce, AWS DMS crea una voce di registro con uno stato di replica di `failed` e un messaggio che descrive il motivo dell'errore. È consigliabile controllare i CloudWatch log come primo passaggio per la risoluzione dei problemi di replica non riuscita. **Nota** Come con AWS DMS Standard, è possibile abilitare una registrazione più granulare sullo stato di avanzamento della migrazione dei dati stessa, ovvero i log emessi dall'attività di replica sottostante. È possibile abilitare questi log nelle impostazioni di replica impostando `EnableLogging` su `true` nel campo `Logging`, come nel seguente esempio JSON: ``` { "Logging": { "EnableLogging": true } } ``` Una volta abilitati, questi log sono disponibili solo durante la fase `running` della replica serverless. Sono presenti nello stesso gruppo di log del flusso di log precedente, ma dispongono del nuovo `dms-serverless-serv-res-id-{unique identifier}` del flusso di log. Per informazioni su come interpretare i log della replica serverless, consulta la sezione seguente. #### Esempi di log della replica serverless In questa sezione sono inclusi esempi di voci di log delle repliche serverless. ##### Esempio: avvio della replica Quando si esegue una replica senza server, AWS DMS crea una voce di registro simile alla seguente: ``` {'replication_state':'initializing', 'message': 'Initializing the replication workflow.'} ``` ##### Esempio: errore della replica Se uno degli endpoint della replica non è configurato correttamente, AWS DMS crea una voce di registro simile alla seguente: ``` {'replication_state':'failed', 'message': 'Test connection failed for endpoint X.', 'failure_message': 'X'} ``` Se vedi questo messaggio nel log dopo un errore, assicurati che l'endpoint specificato sia integro e configurato correttamente. ## Throughput migliorato per le migrazioni a pieno carico da Oracle ad Amazon Redshift e Amazon S3 AWS DMS offre prestazioni di throughput notevolmente migliorate per le migrazioni a pieno carico da Oracle ad Amazon Redshift e Amazon S3. DMS abilita automaticamente questa funzionalità per le tabelle senza l'opzione personalizzata `parallel-load` nelle mappature delle tabelle. Per le tabelle con opzioni di caricamento parallelo personalizzate, DMS serverless distribuisce il carico della tabella in base alle configurazioni di mappatura delle tabelle fornite. Per utilizzare una velocità effettiva migliorata, procedi come segue: + Fornite regole di selezione che non facciano riferimento a partizioni o limiti. Ad esempio, se le impostazioni della tabella nelle mappature delle tabelle lo contengono`parallel-load`, DMS Serverless non utilizzerà la funzionalità di throughput avanzata. Per ulteriori informazioni, consulta [Operazioni e regole di selezione](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md). + `MaxFileSize`Imposta e fino a 64 MB. `WriteBufferSize` Per ulteriori informazioni, consulta [Impostazioni degli endpoint quando si utilizza Amazon Redshift come destinazione per AWS DMS](CHAP_Target.Redshift.md#CHAP_Target.Redshift.ConnectionAttrib). + Si consiglia `CompressCsvFiles` di impostare su `true` per un data store con dati sparsi e `false` per un data store con dati densi. + Imposta le seguenti impostazioni delle attività su: `0` + `ParallelLoadThreads` + `ParallelLoadQueuesPerThread` + `ParallelApplyThreads` + `ParallelApplyQueuesPerThread` + `ParallelLoadBufferSize` + Impostato `MaxFullLoadSubTasks` su `49` per supportare la migrazione parallela dei dati. + Imposta `LOB mode` su `inline`. Per ulteriori informazioni, consulta [Impostazione del supporto LOB per i database di origine in un task AWS DMS](CHAP_Tasks.LOBSupport.md). AWS DMS non fornisce prestazioni di throughput migliorate per le seguenti repliche: + Repliche con tabelle che utilizzano il caricamento parallelo. Per ulteriori informazioni, consulta [Utilizzo del caricamento parallelo per le tabelle, le viste e le raccolte selezionate](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad). + Repliche con regole di trasformazione dei dati. + Repliche con regole di filtro. + Repliche con la regola di trasformazione. + Repliche con Amazon Redshift Serverless come destinazione. ## Comprendere la scalabilità automatica dello storage in modalità serverless AWS DMS Quando si avvia un processo di replica, AWS DMS Serverless alloca 100 GB di storage iniziale per la replica. Lo storage è principalmente consumato dai file di log e dalle transazioni memorizzate nella cache. Per le transazioni memorizzate nella cache, lo storage viene utilizzato solo quando le transazioni memorizzate nella cache devono essere scritte su disco. Pertanto, AWS DMS Serverless non utilizza una quantità significativa di storage. Di seguito sono riportate alcune eccezioni: + Tabelle di grandissime dimensioni che sostengono un notevole carico di transazioni. Il caricamento di una tabella di grandi dimensioni può richiedere del tempo, perciò le transazioni memorizzate nella cache hanno maggiori probabilità di essere scritte su disco durante il caricamento di una tabella di grandi dimensioni. + Le attività configurate per la sospensione prima del caricamento delle transazioni memorizzate nella cache. In questo caso, tutte le transazioni vengono memorizzate nella cache fino alla conclusione del caricamento completo per tutte le tabelle. Con questa configurazione, le transazioni memorizzate nella cache potrebbero consumare una discreta quantità di spazio di archiviazione. + Attività configurate con tabelle in fase di caricamento in Amazon Redshift. Questa configurazione non è un problema quando Amazon Aurora è la destinazione. Pertanto, AWS DMS Serverless monitora l'utilizzo dello storage ogni 15 minuti. Una volta che lo storage allocato viene utilizzato del 90%, AWS DMS Serverless ridimensiona la replica con storage aggiuntivo. Nel caso in cui venga utilizzato lo storage al 100% della replica e le attività di replica falliscano prima o durante il processo di scaling, DMS Serverless riprende le attività una volta completata correttamente la scalabilità. **Nota** Le operazioni di caricamento completo vengono riavviate dall'inizio per tutte le tabelle incomplete quando si riprende un'attività interrotta in precedenza. Non vi è alcun impatto sulle prestazioni delle attività DMS durante l'evento di scalabilità dello storage. Non esiste un periodo di raffreddamento tra due eventi di auto scaling dello storage.