Modalità di rilevamento e risoluzione dei conflitti da parte della replica di tipo merge

Quando si crea una sottoscrizione, oltre a specificare se si tratta di una sottoscrizione push o pull, si specifica se è una sottoscrizione client o server. Dopo aver creato la sottoscrizione, non è più possibile modificarne il tipo (nelle precedenti versioni di Microsoft SQL Server, le sottoscrizioni client e server erano denominate rispettivamente sottoscrizioni locali e globali).

Una sottoscrizione a cui è stata assegnata una priorità (da 0.00 a 99.99) viene denominata sottoscrizione server, mentre una sottoscrizione che utilizza la priorità del server di pubblicazione viene denominata sottoscrizione client. Inoltre, i Sottoscrittori con sottoscrizioni server possono ripubblicare i dati negli altri Sottoscrittori. Nella tabella seguente vengono descritte le differenze e gli utilizzi principali dei due tipi di Sottoscrittore.

Se viene modificata una riga in una sottoscrizione client, alla modifica non viene assegnata alcuna priorità fino alla sincronizzazione della sottoscrizione. Durante la sincronizzazione, alle modifiche provenienti dal Sottoscrittore viene assegnata la priorità del server di pubblicazione e queste mantengono tale priorità per le successive sincronizzazioni. In un certo senso, il server di pubblicazione diventa il proprietario della modifica. Questo comportamento permette al primo Sottoscrittore di sincronizzarsi con il server di pubblicazione in modo da prevalere nei successivi conflitti con altri Sottoscrittori per una specifica riga o colonna.

Quando viene modificata una riga in una sottoscrizione server, la priorità della sottoscrizione viene archiviata nei metadati per la modifica. Al momento dell'esecuzione del merge con le modifiche degli altri Sottoscrittori, la riga modificata viene trasferita con questo valore di priorità. In tal modo si garantisce che una modifica eseguita da una sottoscrizione con priorità inferiore non prevalga su una modifica eseguita da una sottoscrizione con priorità superiore.

Una sottoscrizione non può avere un valore di priorità esplicito superiore a quello del proprio server di pubblicazione. Il server di pubblicazione di massimo livello in una topologia di replica di tipo merge ha sempre un valore esplicito di priorità pari a 100.00. Tutte le sottoscrizioni a tale pubblicazione devono avere un valore di priorità inferiore a tale valore. In una topologia di ripubblicazione:

• Se il Sottoscrittore ripubblica i dati, la sottoscrizione deve essere una sottoscrizione server con valore di priorità inferiore a quella del server di pubblicazione al di sopra del Sottoscrittore.

• Se il Sottoscrittore non ripubblica i dati (poiché è al livello foglia dell'albero di ripubblicazione) la sottoscrizione deve essere di tipo client.

Per ulteriori informazioni sulla sottoscrizioni server e sulle priorità, vedere Esempio di risoluzione dei conflitti di merge in base al tipo di sottoscrizione e alle priorità assegnate.

Notifica ritardata dei conflitti

Una modifica di dati si qualifica come conflitto a seconda del tipo di rilevamento dei conflitti impostato per un articolo: a livello di riga, a livello di colonna o a livello di record logici. Per ulteriori informazioni sul rilevamento a livello di record logici, vedere Rilevamento e risoluzione dei conflitti nei record logici.

Quando i conflitti sono rilevati a livello di riga, le modifiche apportate alle righe corrispondenti vengono riconosciute come conflitti, indipendentemente dal fatto che siano state apportate o meno nella stessa colonna. Si supponga, ad esempio, che venga modificata la colonna dell'indirizzo di una riga del server di pubblicazione e che una seconda modifica venga apportata alla colonna del numero di telefono nella riga corrispondente della stessa tabella nel Sottoscrittore. Se si utilizza il rilevamento a livello di riga, viene rilevato un conflitto in quanto sono state apportate modifiche alla stessa riga. Se si utilizza il rilevamento a livello di colonna, non viene rilevato alcun conflitto in quanto le modifiche sono state apportate in colonne diverse della stessa riga.

Per il rilevamento a livello di riga e a livello di colonna, il processo di risoluzione dei conflitti è sempre lo stesso: l'intera riga di dati viene sovrascritta dalla riga che ha prevalso nel conflitto (per il rilevamento a livello di record logici, la risoluzione dipende dalla proprietà dell'articolo logical_record_level_conflict_resolution).

In genere, l'opzione di rilevamento da utilizzare viene determinata dalla semantica dell'applicazione. Se, ad esempio, si esegue l'aggiornamento di dati di clienti che di norma vengono immessi contemporaneamente, come indirizzi o numeri telefonici, è consigliabile scegliere il rilevamento a livello di riga. Se in questa situazione viene scelto il rilevamento a livello di colonna, le modifiche apportate all'indirizzo del cliente in un sito e quelle apportate al numero telefonico del cliente in un altro sito non vengono rilevate come conflitto, i dati vengono uniti durante la sincronizzazione e l'errore non viene rilevato. In altre situazioni, la soluzione ottimale potrebbe essere l'aggiornamento di singole colonne da siti diversi. Ad esempio, due siti possono avere accesso a informazioni statistiche diverse relative a un cliente, quali il livello di reddito e l'importo totale degli acquisti tramite carta di credito. Il rilevamento a livello di colonna garantisce che in entrambi i siti sia possibile immettere dati statistici per colonne diverse senza generare conflitti inutili.

L'agente di merge rileva i conflitti aggiornamento-aggiornamento quando l'aggiornamento di una riga (o colonna o record logico) in un nodo è in conflitto con un altro aggiornamento della stessa riga in un altro nodo. Il comportamento del sistema di risoluzione predefinito in questo caso prevede l'invio della versione della riga che ha prevalso al nodo della riga perdente e la registrazione di quest'ultima nella tabella dei conflitti dell'articolo.

L'agente di merge rileva i conflitti aggiornamento-eliminazione quando l'aggiornamento di dati in un nodo è in conflitto con un'eliminazione in un altro nodo. In questo caso, l'agente di merge aggiorna una riga; tuttavia, quando ricerca la stessa riga nella destinazione, non la trova perché è stata eliminata. Se ha prevalso il nodo che ha aggiornato la riga, l'eliminazione nell'altro nodo viene ignorata e l'agente di merge invia la riga appena aggiornata al nodo di quella eliminata, quindi registra le informazioni sulla versione perdente della riga nella tabella MSmerge_conflicts_info.

L'agente di merge genera questi conflitti quando non è in grado di applicare una particolare modifica. In genere, questo accade a causa di una differenza tra le definizioni dei vincoli nel server di pubblicazione e nel Sottoscrittore e per il diverso uso della proprietà NOT FOR REPLICATION (NFR) nel vincolo. Esempi di tali situazioni:

• Un conflitto di chiave esterna nel Sottoscrittore, che può verificarsi quando il vincolo del lato Sottoscrittore non è contrassegnato come NFR.

• Differenze di vincoli tra server di pubblicazione e Sottoscrittori, e mancato contrassegno dei vincoli come NFR.

• Indisponibilità di oggetti dipendenti nel Sottoscrittore. Ad esempio, se si pubblica una vista ma non la tabella dalla quale dipende, se si tenta di inserirsi nel Sottoscrittore attraverso la vista si verifica un errore.

• Logica di filtraggio join per una pubblicazione che non corrisponde ai vincoli di chiave primaria e di chiave esterna. Possono verificarsi dei conflitti quando il motore relazionale di SQL Server prova a rispettare un vincolo ma l'agente di merge rispetta la definizione di filtro join tra articoli. L'agente di merge non può applicare la modifica nel nodo di destinazione a causa dei vincoli a livello di tabella, cosa che genera un conflitto.

• È possibile che si verifichino conflitti a causa di violazioni di indice univoco, vincolo univoco o chiave primaria se per l'articolo vengono definite colonne Identity e non viene utilizzata la gestione automatica delle identità. Questo può essere un problema se due Sottoscrittori utilizzano lo stesso valore Identity per una riga appena inserita. Per ulteriori informazioni sulla gestione degli intervalli di valori Identity, vedere Replica di colonne Identity.

• Conflitti dovuti a una logica di trigger che impedisce all'agente di merge di inserire una riga nella tabella di destinazione. Si consideri un trigger di aggiornamento definito nel Sottoscrittore, che non è contrassegnato come NFR e nella propria logica include un ROLLBACK. In caso di errore, il trigger esegue un rollback della transazione e di conseguenza l'agente di merge rileva un conflitto di modifica non riuscita.