Rilevamento e risoluzione dei conflitti di aggiornamento in coda

Poiché le sottoscrizioni ad aggiornamento in coda consentono modifiche agli stessi dati in più posizioni, possono verificarsi conflitti durante la sincronizzazione dei dati nel server di pubblicazione. La replica rileva eventuali conflitti quando le modifiche vengono sincronizzate con il server di pubblicazione e risolve tali conflitti utilizzando i criteri di risoluzione selezionati durante la creazione della pubblicazione. Possono verificarsi i conflitti seguenti:

• Conflitti di aggiornamento e inserimento. Questo conflitto si verifica quando gli stessi dati vengono modificati in due posizioni. Un cambiamento vince e l'altro perde.

• Elimina conflitti. Questo conflitto si verifica quando la stessa riga viene eliminata in una posizione e modificata all'altra.

Il rilevamento e la risoluzione dei conflitti possono essere un processo dispendioso in termini di tempo e di risorse; pertanto, è consigliabile ridurre al minimo i conflitti nell'applicazione creando partizioni di dati in modo che i diversi Sottoscrittori modifichino subset di dati diversi.

Rilevamento dei conflitti

Quando si crea una pubblicazione e si abilita l'aggiornamento in coda, la replica aggiunge una colonna uniqueidentifier (msrepl_tran_version) con il valore predefinito newid() alla tabella sottostante. Quando i dati pubblicati vengono modificati nel server di pubblicazione o nel Sottoscrittore, la riga riceve un nuovo identificatore univoco globale (GUID) per indicare che esiste una nuova versione di riga. L'agente di lettura coda usa questa colonna durante la sincronizzazione per determinare se esiste un conflitto.

Una transazione in una coda mantiene i valori delle versioni di riga precedenti e nuove. Quando la transazione viene applicata al Publisher, vengono confrontati i GUID della transazione e il GUID nella pubblicazione. Se il GUID precedente archiviato nella transazione corrisponde al GUID nella pubblicazione, la pubblicazione viene aggiornata e alla riga viene assegnato il nuovo GUID generato dal Sottoscrittore. Aggiornando la pubblicazione con il GUID della transazione, avrai versioni di riga corrispondenti sia nella pubblicazione che nella transazione.

Se il GUID precedente archiviato nella transazione non corrisponde al GUID nella pubblicazione, viene rilevato un conflitto. Il nuovo GUID nella pubblicazione indica che esistono due versioni di riga diverse: una nella transazione inviata dal Sottoscrittore e una più recente presente nel Publisher. In questo caso, un altro Sottoscrittore o il server di pubblicazione ha aggiornato la stessa riga della pubblicazione prima della sincronizzazione della transazione del Sottoscrittore.

A differenza della replica di tipo merge, l'uso di una colonna GUID non viene usato per identificare la riga stessa, ma viene usato per verificare se la riga è stata modificata.

Risoluzione dei conflitti

Quando si crea una pubblicazione utilizzando l'aggiornamento in coda, si seleziona un sistema di risoluzione dei conflitti da utilizzare se vengono rilevati conflitti. Il sistema di risoluzione dei conflitti determina il modo in cui l'agente di lettura coda gestisce versioni diverse della stessa riga rilevate durante la sincronizzazione. È possibile modificare i criteri di risoluzione dei conflitti dopo la creazione della pubblicazione, purché non siano presenti sottoscrizioni alla pubblicazione. Le scelte del sistema di risoluzione dei conflitti sono le seguenti:

• Il server di pubblicazione vince (impostazione predefinita)

• Il server di pubblicazione vince e la sottoscrizione viene reinizializzata

• Il Sottoscrittore vince

I conflitti vengono registrati e possono essere visualizzati tramite il Visualizzatore conflitti.

Impostare la politica di risoluzione dei conflitti per gli aggiornamenti in coda

• SQL Server Management Studio: impostare le opzioni di risoluzione dei conflitti per l'aggiornamento in coda (SQL Server Management Studio)

• Programmazione della replica Transact-SQL: Abilitare le sottoscrizioni ad aggiornamento per le pubblicazioni transazionali

Per visualizzare i conflitti di dati

• SQL Server Management Studio: Visualizzare i conflitti di dati per le pubblicazioni transazionali (SQL Server Management Studio)

Vince l'editore

Quando la risoluzione dei conflitti è impostata in modo che prevalga il Publisher, la consistenza transazionale viene mantenuta basandosi sui dati del Publisher. Viene eseguito il rollback della transazione in conflitto nel Sottoscrittore che lo ha avviato.

L'agente di lettura coda rileva un conflitto e i comandi di compensazione vengono generati e propagati al Sottoscrittore pubblicandoli nel database di distribuzione. L'agente di distribuzione applica quindi i comandi di compensazione al Sottoscrittore che ha originato la transazione in conflitto. Le azioni di correzione aggiornano le righe sul Sottoscrittore per farle corrispondere alle righe sull'Editore.

Fino a quando non vengono applicati i comandi di compensazione, è possibile leggere i risultati di una transazione che alla fine verrà eseguito il rollback nel Sottoscrittore. Equivale a una lettura sporca (livello di isolamento read uncommitted). Non esiste alcuna compensazione per le transazioni dipendenti successive che possono verificarsi. Tuttavia, i confini delle transazioni vengono rispettati e tutte le azioni vengono confermate all'interno di una transazione oppure, in caso di conflitto, vengono annullate.

Il server di pubblicazione vince e la sottoscrizione viene reinizializzata

La reinizializzazione del Sottoscrittore per risolvere i conflitti mantiene una coerenza transazionale rigorosa nel Sottoscrittore, ma può richiedere molto tempo se la pubblicazione contiene grandi quantità di dati.

Quando l'agente di lettura coda rileva un conflitto, tutte le transazioni rimanenti nella coda (inclusa la transazione in conflitto) vengono rifiutate e il Sottoscrittore viene contrassegnato per la reinizializzazione. Lo snapshot successivo generato per la pubblicazione viene applicato dall'agente di distribuzione al Sottoscrittore.

Vince il Sottoscrittore

Il rilevamento dei conflitti secondo il criterio 'vittoria del Sottoscrittore' significa che l'ultima transazione del Sottoscrittore per aggiornare il Pubblicatore prevale. In questo caso, quando viene rilevato un conflitto, la transazione inviata dal Sottoscrittore viene ancora utilizzata e il server di pubblicazione viene aggiornato. Questo criterio è adatto alle applicazioni in cui tali modifiche non comprometteno l'integrità dei dati.

Vedere anche

Sottoscrizioni modificabili per la replica transazionale