Replica transazionale

Si applica a:SQL ServerDatabase SQL di AzureIstanza gestita di SQL di Azure

Questo articolo presenta la replica transazionale per SQL Server. La replica transazionale in genere ha inizio con la creazione di uno snapshot degli oggetti e dei dati del database di pubblicazione. Dopo la creazione dello snapshot iniziale, le successive modifiche ai dati e allo schema eseguite nel server di pubblicazione vengono generalmente recapitate al Sottoscrittore nel momento in cui vengono eseguite. Le modifiche ai dati vengono applicate al Sottoscrittore nello stesso ordine e negli stessi limiti della transazione con cui vengono eseguite nel server di pubblicazione. Di conseguenza, la consistenza transazionale all'interno di una pubblicazione è garantita.

Informazioni generali

La replica transazionale viene solitamente utilizzata negli ambienti da server a server ed è appropriata ai casi seguenti:

• Si desidera propagare modifiche incrementali ai Sottoscrittori appena vengono apportate.

• L'applicazione richiede una bassa latenza tra il momento in cui le modifiche vengono apportate nel server di pubblicazione e il momento in cui raggiungono il Sottoscrittore.

• L'applicazione richiede l'accesso a stati dei dati intermedi. Se una riga viene modificata cinque volte, ad esempio, la replica transazionale consente a un'applicazione di rispondere a ogni modifica, ad esempio attivando un trigger, anziché soltanto alla modifica di dati netta apportata alla riga.

• Il server di pubblicazione è caratterizzato da un'intensa attività di inserimento, aggiornamento ed eliminazione.

• Il server di pubblicazione o il Sottoscrittore è un database non SQL Server, ad esempio Oracle.

Per impostazione predefinita, i sottoscrittori delle pubblicazioni transazionali devono essere considerati solo in lettura, perché le modifiche non vengono propagate nuovamente all'Editore. La replica transazionale offre tuttavia opzioni che consentono aggiornamenti nel Sottoscrittore.

Configurare la crittografia TLS 1.3

SQL Server 2025 (17.x) introduce il supporto TDS 8.0 per la replica transazionale, che include:

• Configurazione degli agenti di replica per l'uso della crittografia TLS 1.3 tra istanze di SQL Server 2025 (17.x) e anche tra SQL Server 2025 (17.x) e Istanza gestita di SQL di Azure.
• Crittografia predefinita per la comunicazione tra server collegati tra istanze di SQL Server 2025 (17.x) in una topologia di replica. I server collegati in SQL Server 2025 (17.x) utilizzano il driver OLE DB v19, che per impostazione predefinita utilizza la crittografia Encrypt=Mandatory.

Funzionamento della replica transazionale

La replica transazionale viene implementata dall'agente di snapshot, dall'agente di lettura log e dall'agente di distribuzione SQL Server. L'agente snapshot prepara i file di snapshot contenenti lo schema e i dati delle tabelle pubblicate e degli oggetti di database, archivia i file nella cartella snapshot e registra i processi di sincronizzazione nel database di distribuzione sul server di distribuzione.

L'agente di lettura log esegue il monitoraggio del log delle transazioni di tutti i database configurati per la replica transazionale e copia le transazioni contrassegnate per la replica dal log delle transazioni al database di distribuzione, che agisce come coda di archiviazione e inoltro affidabile. L'agente di distribuzione copia nei Sottoscrittori i file snapshot iniziali dalla cartella snapshot e le transazioni archiviate nelle tabelle del database di distribuzione.

Le modifiche incrementali apportate nel server di pubblicazione vengono propagate ai sottoscrittori secondo la pianificazione dell'agente di distribuzione, che può essere eseguito in modo continuo per ridurre al minimo la latenza oppure a intervalli pianificati. Poiché le modifiche ai dati devono essere apportate nel server di pubblicazione, quando la replica transazionale viene utilizzata senza le opzioni di aggiornamento immediato o di aggiornamento in coda, si evitano conflitti di aggiornamento. Alla fine, tutti i sottoscrittori avranno gli stessi valori del pubblicatore. Se si utilizza la replica transazionale con l'opzione di aggiornamento immediato o in coda, è possibile apportare aggiornamenti nel Sottoscrittore. Nel caso dell'aggiornamento in coda, è possibile che si verifichino conflitti.

Nella figura seguente vengono illustrati i componenti principali della replica transazionale.

Set di dati iniziale

Un nuovo Sottoscrittore per la replica transazionale può ricevere modifiche incrementali da un server di pubblicazione solo quando contiene lo stesso schema e gli stessi dati disponibili nelle tabelle del server di pubblicazione. Il set di dati iniziale è generalmente uno snapshot creato dall'agente snapshot e distribuito e applicato dall'agente di distribuzione. Il set di dati iniziale può anche essere fornito tramite un backup o altri mezzi, come SQL Server Integration Services.

Quando gli snapshot vengono distribuiti e applicati ai Sottoscrittori, sono interessati solo i Sottoscrittori in attesa degli snapshot iniziali. Gli altri sottoscrittori di quella pubblicazione (quelli già inizializzati) non sono interessati.

Elaborazione concorrente delle snapshot

La replica snapshot applica blocchi condivisi a tutte le tabelle pubblicate come parte della replica per tutta la durata della generazione dello snapshot. La presenza di tali blocchi può impedire l'esecuzione di aggiornamenti nelle tabelle di pubblicazione. L'elaborazione simultanea degli snapshot, l'impostazione predefinita con la replica transazionale, non mantiene i blocchi di condivisione sul posto durante l'intera generazione di snapshot, che consente agli utenti di continuare a lavorare senza interruzioni mentre la replica crea file snapshot iniziali.

Agente snapshot

Le procedure in base alle quali l'agente snapshot implementa lo snapshot iniziale nella replica transazionale sono le stesse procedure usate nella replica snapshot , ad eccezione di quanto descritto in precedenza per quanto riguarda l'elaborazione simultanea degli snapshot.

Dopo avere generato i file di snapshot, è possibile visualizzarli nella cartella snapshot tramite Esplora risorse di Microsoft.

Modifica dei dati e dell'agente di lettura del log

L'agente di lettura log viene eseguito nel server di distribuzione, generalmente in modo continuo sebbene sia possibile eseguirlo anche in base a una pianificazione stabilita. Durante l'esecuzione, l'Agente di lettura log legge innanzitutto il log delle transazioni della pubblicazione (lo stesso log del database usato per il tracciamento e il ripristino delle transazioni durante le normali operazioni di Motore di database di SQL Server) e identifica eventuali istruzioni INSERT, UPDATE e DELETE, o altre modifiche apportate ai dati nelle transazioni contrassegnate per la replicazione. L'agente copia quindi le transazioni in batch nel database di distribuzione del server di distribuzione. L'Agente di lettura log usa la stored procedure interna sp_replcmds per ottenere dal log il gruppo successivo di comandi contrassegnati per la replica. Il database di distribuzione diventa quindi la coda di memorizzazione e inoltro da cui le modifiche vengono inviate ai Sottoscrittori. Al database di distribuzione vengono inviate solo le transazioni di cui è stato eseguito il commit.

Dopo che l'intero batch di transazioni è stato scritto correttamente nel database di distribuzione, viene eseguito il commit. Al termine del commit di ogni batch di comandi nel server di distribuzione l'agente di lettura log chiama la stored procedure sp_repldone per contrassegnare il punto in cui è stato completato l'ultimo processo di replica, quindi contrassegna le righe del log delle transazioni pronte per essere eliminate. Le righe che sono ancora in attesa di essere replicate non vengono cancellate.

I comandi delle transazioni vengono archiviati nel database di distribuzione fino a quando non vengono propagati a tutti i Sottoscrittori o fino al raggiungimento del periodo di conservazione massimo della distribuzione. I Sottoscrittori ricevono le transazioni nello stesso ordine in cui sono state applicate nel server di pubblicazione.

Agente di distribuzione

L'agente di distribuzione viene eseguito nel server di distribuzione per le sottoscrizioni push e nel Sottoscrittore per le sottoscrizioni pull. L'agente sposta le transazioni dal database di distribuzione al Sottoscrittore. Se una sottoscrizione è contrassegnata per la verifica, l'Agente di distribuzione controlla anche se i dati nell'Editore e nel Sottoscrittore corrispondono.

Tipi di pubblicazione

La replica transazionale offre quattro tipi di pubblicazione: