Funzionamento delle sottoscrizioni aggiornabili
Le sottoscrizioni aggiornabili per la replica transazionale consentono ai Sottoscrittori di replicare le modifiche al server di pubblicazione. I trigger vengono aggiunti alle tabelle pubblicate nel database di sottoscrizione e, quando viene apportata una modifica al Sottoscrittore, il trigger viene attivato:
Per le sottoscrizioni ad aggiornamento immediato, la modifica viene propagata direttamente al server di pubblicazione e applicata utilizzando il servizio Distributed Transaction Coordinator (MSDTC) di Microsoft.
Per le sottoscrizioni ad aggiornamento in coda, la modifica viene prima propagata a una coda e quindi applicata al server di pubblicazione dall'agente di lettura coda.
Le modifiche apportate al server di pubblicazione vengono replicate ai Sottoscrittori proprio come le pubblicazioni transazionali con Sottoscrittori di sola lettura. Per ulteriori informazioni, vedere Funzionamento della replica transazionale.
Aggiornamento immediato
Le sottoscrizioni ad aggiornamento immediato utilizzano i seguenti componenti:
Colonna per il rilevamento per ogni tabella pubblicata
Quando una tabella viene pubblicata in una pubblicazione che consente sottoscrizioni aggiornabili, alla tabella viene aggiunta la colonna MSrepl_tran_version. Tale colonna viene utilizzata per il rilevamento delle modifiche e dei conflitti. I conflitti di aggiornamento immediato si verificano se il Sottoscrittore aggiorna una copia obsoleta dei dati.
MSDTC
Per ogni modifica apportata a un Sottoscrittore, MSDTC gestisce un'operazione di commit in due fasi tra il server di pubblicazione e il Sottoscrittore che esegue il commit della modifica. Questo metodo non prevede le limitazioni di disponibilità associate all'utilizzo del commit in due fasi in tutti i siti interessati, in quanto è sufficiente che sia disponibile il server di pubblicazione. Dopo aver apportato la modifica al server di pubblicazione utilizzando il commit in due fasi, tale modifica viene replicata ad altri Sottoscrittori dall'agente di distribuzione.
Trigger nelle tabelle del database di sottoscrizione
Trigger di inserimento, aggiornamento ed eliminazione vengono aggiunti a ogni tabella pubblicata nel database di sottoscrizione. I trigger vengono creati utilizzando il modificatore NOT FOR REPLICATION dell'istruzione CREATE TRIGGER in modo che le modifiche applicate dall'agente di distribuzione non provochino l'attivazione dei trigger. Per ulteriori informazioni, vedere Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION.
Per le sottoscrizioni ad aggiornamento immediato, i trigger gestiscono anche valori per le colonne identity e timestamp del Sottoscrittore. I valori vengono generati nel server di pubblicazione per questi tipi di colonne e propagati al Sottoscrittore durante l'operazione di commit in due fasi.
Stored procedure
Quando si crea una pubblicazione attivandola per le sottoscrizioni ad aggiornamento immediato, vengono create stored procedure di tipo insert, update e delete per ogni tabella pubblicata nel database di pubblicazione. Quando viene apportata una modifica nel Sottoscrittore, un trigger di replica esegue una chiamata di procedura remota mediante MSDTC alla stored procedure appropriata del server di pubblicazione, che quindi applica la modifica.
Le stored procedure nel server di pubblicazione applicano modifiche solo se non sono in conflitto con le modifiche apportate al server di pubblicazione dopo che Sottoscrittore ha ricevuto l'ultima copia delle righe modificate. In caso di conflitto, la transazione viene rifiutata e ne viene eseguito il rollback nel server di pubblicazione e nel Sottoscrittore.
Nella figura riportata di seguito sono illustrati i componenti principali utilizzati in una topologia che include sottoscrizioni ad aggiornamento immediato.
.gif "Componenti e flusso di dati per l'aggiornamento immediato")
Una modifica apportata nel Sottoscrittore viene acquisita da un trigger nella tabella di sottoscrizione.
Il trigger esegue una chiamata tramite MSDTC alla stored procedure appropriata nel server di pubblicazione.
La stored procedure esegue l'inserimento, l'aggiornamento o l'eliminazione, a meno che non si verifichi un conflitto. In questo caso, viene eseguito il rollback della modifica nel server di pubblicazione e nel Sottoscrittore.
Le modifiche apportate nel server di pubblicazione in seguito alla replica di modifiche da un Sottoscrittore vengono propagate a tutti i Sottoscrittori in base alla pianificazione dell'agente di distribuzione.
Aggiornamento in coda
Le sottoscrizioni ad aggiornamento in coda utilizzano i seguenti componenti:
Colonna per il rilevamento per ogni tabella pubblicata
Quando una tabella viene pubblicata in una pubblicazione che consente sottoscrizioni aggiornabili, alla tabella viene aggiunta la colonna MSrepl_tran_version. Tale colonna viene utilizzata per il rilevamento delle modifiche e dei conflitti.
Trigger nelle tabelle del database di sottoscrizione
Trigger di inserimento, aggiornamento ed eliminazione vengono aggiunti a ogni tabella pubblicata nel database di sottoscrizione. I trigger vengono creati utilizzando il modificatore NOT FOR REPLICATION dell'istruzione CREATE TRIGGER in modo che le modifiche applicate dall'agente di distribuzione non provochino l'attivazione dei trigger. Per ulteriori informazioni, vedere Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION.
Stored procedure
Quando si crea una pubblicazione attivandola per le sottoscrizioni ad aggiornamento in coda, vengono create stored procedure di tipo insert, update e delete per ogni tabella pubblicata nel database di pubblicazione.
Le stored procedure vengono richiamate dall'agente di lettura coda allo scopo di applicare le transazioni nel server di pubblicazione, rilevare i conflitti e, se necessario, generare comandi di compensazione, inviarli al database di distribuzione e quindi inoltrarli al Sottoscrittore.
Nel server di pubblicazione viene creata inoltre una stored procedure per la registrazione delle informazioni sui conflitti del server di pubblicazione e, facoltativamente, per l'invio delle informazioni ai Sottoscrittori appropriati. In caso di conflitto, la stored procedure viene richiamata dall'agente di lettura coda.
Microsoft Coda SQL Server
Ogni database di sottoscrizione contiene la tabella di sistema MSreplication_queue in cui vengono archiviate le modifiche del Sottoscrittore.
Agente di lettura coda SQL Server
L'agente di lettura coda legge le modifiche della MSreplication_queue e le applica al server di pubblicazione. Per ulteriori informazioni, vedere Agente lettura coda repliche.
Nella figura riportata di seguito sono illustrati i componenti principali utilizzati in una topologia che include sottoscrizioni ad aggiornamento in coda.
.gif "Componenti e flusso di dati per l'aggiornamento in coda")
Gli aggiornamenti eseguiti nel Sottoscrittore vengono acquisiti dai trigger nelle tabelle di sottoscrizione. I trigger archiviano questi aggiornamenti nella MSreplication_queue.
L'agente di lettura coda legge dalla MSreplication_queue e applica le transazioni in coda alla pubblicazione appropriata utilizzando stored procedure di replica.
Durante l'applicazione delle transazioni in coda, gli eventuali conflitti vengono rilevati e risolti in base ai criteri di risoluzione dei conflitti impostati in fase di creazione della pubblicazione. Di conseguenza potrebbero essere generati i comandi di compensazione per l'esecuzione del rollback di una transazione in un Sottoscrittore utilizzando i processi standard di distribuzione della replica transazionale. Tali comandi tuttavia possono essere inviati solo al Sottoscrittore che ha generato il conflitto. Per ulteriori informazioni, vedere Rilevamento e risoluzione dei conflitti nell'aggiornamento in coda.
Le modifiche apportate nel server di pubblicazione in seguito alla replica di modifiche da un Sottoscrittore vengono propagate a tutti i Sottoscrittori in base alla pianificazione dell'agente di distribuzione.