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à.
SQLRisoluzione dei problemi relativi agli endpoint del server
Questa sezione contiene scenari di replica specifici per SQL il server. Per determinare quali modifiche replicare dal SQL server, AWS DMS legge i log delle transazioni ed esegue scansioni periodiche sul database di origine. La latenza di replica in genere deriva dal fatto che il SQL server limita queste scansioni a causa di vincoli di risorse. Può anche derivare da un aumento significativo del numero di eventi scritti nel log delle transazioni in un breve periodo di tempo.
Argomenti
Ricostruzione degli indici
Quando SQL Server ricostruisce un indice di grandi dimensioni, utilizza una singola transazione. Ciò genera molti eventi e può utilizzare una grande quantità di spazio di registro se il SQL Server ricostruisce più indici contemporaneamente. In tal caso, è possibile aspettarsi brevi picchi nella replica. Se la fonte SQL del server presenta picchi di registro sostenuti, controlla quanto segue:
Innanzitutto, controlla il periodo di tempo in cui si sono verificati i picchi di latenza utilizzando le
CDCLatencySource
CloudWatch metricheCDCLatencySource
and o controllando i messaggi di Throughput Monitoring nei log delle attività. Per informazioni sulle metriche per, consulta CloudWatch . AWS DMSParametri dell'attività di replicaVerifica se la dimensione dei log delle transazioni o dei backup dei log attivi è aumentata durante il picco di latenza. Controlla anche se durante quel periodo è stato eseguito un intervento di manutenzione o una ricostruzione. Per informazioni sulla verifica delle dimensioni del registro delle transazioni, consulta Monitorare l'utilizzo dello spazio di registro
nella documentazione tecnica del SQL server . Verifica che il tuo piano di manutenzione segua le best practice SQL del server. Per informazioni sulle migliori pratiche di manutenzione SQL del server, consulta Index maintenance strategy
nella documentazione tecnica del SQL server .
Per risolvere i problemi di latenza durante le ricostruzioni degli indici, prova a eseguire queste operazioni:
Utilizza il modello di ripristino
BULK_LOGGED
per le ricostruzioni offline per ridurre gli eventi che l'attività deve elaborare.Se possibile, interrompi l'attività durante la ricostruzione dell'indice. In alternativa, prova a pianificare la ricostruzione dell'indice durante le ore non di punta per mitigare l'impatto di un picco di latenza.
Provate a identificare i punti deboli delle risorse che rallentano le DMS letture, come la latenza del disco o il throughput di I/O, e risolvili.
Transazioni di grandi dimensioni
Le transazioni con molti eventi o le transazioni di lunga durata fanno aumentare la dimensione del log delle transazioni. Ciò fa sì che le DMS letture richiedano più tempo, con conseguente latenza. Questo approccio è simile all'effetto che le ricostruzioni degli indici hanno sulle prestazioni della replica.
Potrebbe essere difficile identificare questo problema se non si conosce il carico di lavoro tipico del database di origine. Per risolvere questo problema, esegui questi passaggi:
Innanzitutto, identifica l'ora in cui è aumentata la latenza utilizzando le
WriteThroughput
CloudWatch metricheReadThroughput
and o controllando i messaggi di Throughput Monitoring nei log delle attività.Controlla se sono state eseguite query di lunga durata sul database di origine durante il picco di latenza. Per informazioni sulle query a esecuzione prolungata, consulta Risolvere i problemi relativi alle query a esecuzione lenta
in Server nella documentazione tecnica del server. SQL SQL Verifica se la dimensione dei log delle transazioni o dei backup dei log attivi è aumentata. Per ulteriori informazioni, consulta Monitorare l'utilizzo dello spazio di registro
nella documentazione tecnica del Server. SQL
Per risolvere il problema, procedi in uno dei seguenti modi:
La soluzione migliore è ristrutturare le transazioni sul lato dell'applicazione in modo che vengano completate rapidamente.
Se non è possibile ristrutturare le transazioni, una soluzione alternativa a breve termine consiste nel verificare eventuali problemi relativi alle risorse, ad esempio attese o contese sui dischi. CPU Se si riscontrano problemi nel database di origine, è possibile ridurre la latenza aumentando le risorse del disco e della memoria per il database di origine. CPU Ciò riduce il conflitto per le risorse di sistema, permettendo DMS di completare le query più velocemente.
Intervallo di CDC polling MS non configurato correttamente per Amazon Server RDS SQL
Un'impostazione errata dell'intervallo di polling sulle RDS istanze Amazon può causare un aumento del registro delle transazioni. Questo avviene perché la replica impedisce il troncamento del log. Sebbene le attività in esecuzione possano continuare a replicarsi con una latenza minima, l'interruzione e la ripresa delle attività o il solo avvio di attività possono causare errori nelle attività. CDC Ciò è dovuto ai timeout che si verificano durante la scansione del log delle transazioni di grandi dimensioni.
Per risolvere il problema relativo a un intervallo di polling configurato in modo errato, esegui queste operazioni:
Controlla se la dimensione del log delle transazioni attivo sta aumentando e se l'utilizzo del log è vicino al 100%. Per ulteriori informazioni, consulta Monitorare l'utilizzo dello spazio di registro
nella documentazione tecnica del server. SQL Controlla se il troncamento del log viene ritardato con
log_reuse_wait_desc value
pari aREPLICATION
. Per ulteriori informazioni, vedere Il registro delle transazioni (SQLserver)nella documentazione tecnica del SQL server .
Se riscontrate problemi con uno qualsiasi degli elementi dell'elenco precedente, regolate l'intervallo di CDC MS-polling. Per informazioni sull'ottimizzazione dell'intervallo di polling, consulta Impostazioni consigliate quando si utilizza RDS for SQL Server come fonte per AWS DMS.
Replica di più CDC attività dallo stesso database di origine
Durante la fase di pieno carico, consigliamo di suddividere le tabelle tra le attività per migliorare le prestazioni, separare logicamente le tabelle dipendenti e mitigare l'impatto di un errore dell'attività. Tuttavia, durante la CDC fase, consigliamo di consolidare le attività per ridurre al minimo DMS le scansioni. Durante la CDC fase, ogni DMS attività analizza i registri delle transazioni alla ricerca di nuovi eventi più volte al minuto. Poiché ogni attività viene eseguita in modo indipendente, ciascuna attività analizza ogni log delle transazioni singolarmente. Ciò aumenta il disco e CPU l'utilizzo del database del SQL server di origine. Di conseguenza, un gran numero di attività eseguite in parallelo può far sì che SQL Server rallenti le DMS letture, con conseguente aumento della latenza.
Potrebbe essere difficile identificare questo problema se più attività vengono avviate gradualmente. Il sintomo più comune di questo problema è che la maggior parte delle scansioni delle attività inizia a richiedere molto tempo. Ciò comporta una maggiore latenza per le scansioni. SQLIl server dà la priorità ad alcune scansioni delle attività, quindi alcune di esse mostrano una latenza normale. Per risolvere questo problema, controlla la metrica CDCLatencySource
per tutte le attività. Se alcune attività sono in aumentoCDCLatencySource
, mentre alcune attività sono basseCDCLatencySource
, è probabile che SQL Server stia limitando la DMS lettura di alcune attività.
Se SQL Server limita la lettura delle attività durante la sessioneCDC, consolida le attività per ridurre al minimo il numero di scansioni. DMS Il numero massimo di attività che possono connettersi al database di origine senza creare conflitti dipende da fattori quali la capacità del database di origine, la percentuale di aumento del log delle transazioni o il numero di tabelle. Per determinare il numero ideale di attività per il tuo scenario di replica, prova la replica in un ambiente di test simile all'ambiente di produzione.
Elaborazione del backup del registro delle transazioni per For Server RDS SQL
AWS DMS 3.5.3 e versioni successive supportano la replica da RDS per i backup dei log SQL del server. La replica degli eventi dai log di backup sulle RDS istanze è più lenta della replica degli eventi dal log delle transazioni attivo. Questo perché DMS richiede l'accesso ai backup in modo seriale per garantire che mantenga la sequenza delle transazioni e per ridurre al minimo il rischio che lo storage delle RDS istanze Amazon si riempia. Inoltre, per quanto riguarda RDS Amazon, il tempo necessario per rendere disponibili i backup DMS varia a seconda delle dimensioni del backup del registro e del carico sull'istanza RDS for SQL Server.
A causa di questi vincoli, ti consigliamo di impostare su. ECA ActivateSafeguard
true
Ciò garantisce che non venga eseguito il backup delle transazioni mentre l'DMSattività viene letta dal registro delle transazioni attivo. Questa impostazione impedisce inoltre ad Amazon di RDS archiviare le transazioni nel log attivo durante DMS la lettura delle transazioni dal backup, eliminando così la possibilità che DMS non riesca a recuperare il log attivo. Tieni presente che ciò potrebbe causare un aumento delle dimensioni del registro attivo mentre l'attività sta recuperando terreno. Assicurati che l'istanza disponga di spazio di archiviazione sufficiente per evitare che lo spazio sull'istanza si esaurisca.
Per un'attività di CDC sola replica da RDS fonti SQL Server, utilizza, se possibile, la posizione di CDC avvio nativa rispetto all'ora di CDC avvio nativa. Questo perché si DMS affida alle tabelle di sistema per identificare il punto di partenza per la posizione iniziale nativa, anziché eseguire la scansione dei singoli backup dei log quando si specifica un'ora di inizio nativa.