Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:
SQL Server
In questo argomento vengono illustrate le varie combinazioni di metodi possibili per il rilevamento e la risoluzione dei conflitti nell'utilizzo di record logici. Nella replica di merge si verificano conflitti quando più di un nodo modifica gli stessi dati oppure quando, durante la replica di modifiche, si riscontrano determinati tipi di errori, ad esempio la violazione di un vincolo. Per ulteriori informazioni sul rilevamento e sulla risoluzione dei conflitti, vedere Advanced Merge Replication Conflict Detection and Resolution.
Per specificare il rilevamento dei conflitti e il livello di risoluzione per un articolo, vedere Modify Merge Replication options (Modificare le opzioni per la replica di tipo merge).
Rilevamento dei conflitti
La modalità con cui vengono rilevati i conflitti per i record logici è determinata da due proprietà degli articoli: column_tracking e logical_record_level_conflict_detection. SQL Server 2005 (9.x) e versioni successive supportano anche rilevamento a livello di record logico.
La proprietà articolo logical_record_level_conflict_detection può essere impostata su TRUE o FALSE. Il valore deve essere impostato solo per l'articolo padre di primo livello e verrà ignorato dagli articoli figlio. Se questo valore è impostato su FALSE, nella replica di tipo merge i conflitti vengono rilevati come nelle precedenti versioni di SQL Server, ovvero esclusivamente in base al valore della proprietà column_tracking dell'articolo. Se questo valore è TRUE, la replica di tipo merge ignorerà la proprietà column_tracking dell'articolo e rileverà un conflitto se vengono apportate modifiche in qualsiasi parte del record logico. Ad esempio, si consideri lo scenario seguente:
Viene rilevato un conflitto se due utenti modificano uno qualsiasi dei valori del record logico Customer2 nelle tabelle Customers, Orderso OrderItems . Questo esempio riguarda modifiche apportate tramite un'istruzione UPDATE, ma il conflitto può essere rilevato anche da modifiche apportate con istruzioni INSERT o DELETE.
Risoluzione dei conflitti
Per impostazione predefinita, la replica di merge utilizza una logica basata sulle priorità per risolvere i conflitti. Se in due database di sottoscrizione viene apportata una modifica in conflitto, ha la priorità la modifica del Sottoscrittore con la priorità di sottoscrizione più elevata. Nel caso in cui la priorità sia uguale, viene applicata per prima la modifica che raggiunge il server di pubblicazione. Con il rilevamento a livello di riga e di colonna, l'intera riga vincente sovrascrive sempre la riga perdente.
La proprietà articolo logical_record_level_conflict_resolution può essere impostata su TRUE o FALSE. Il valore dovrebbe essere impostato solo per l'articolo padre di primo livello e sarà ignorato dagli articoli figlio. Se il valore è impostato su TRUE, il record logico confermato sovrascrive interamente il record logico non confermato. Se è FALSE, le singole righe risultanti possono provenire da Sottoscrittori o Server di pubblicazione diversi. Ad esempio, il Sottoscrittore A può prevalere in un conflitto in una riga della tabella Orders , mentre il Sottoscrittore B può prevalere in una riga correlata nella tabella OrderItems . Il risultato è un record logico contenente la riga Orders del Sottoscrittore A e la riga OrderItems del Sottoscrittore B.
Interazione delle impostazioni di rilevamento e risoluzione dei conflitti
Il risultato dei conflitti dipende dall'interazione delle impostazioni di rilevamento e risoluzione dei conflitti. Negli esempi seguenti si presuppone l'utilizzo della risoluzione dei conflitti basata sulle priorità. Nel caso di record logici esistono le possibilità seguenti:
Rilevamento a livello di riga o di colonna, risoluzione a livello di riga
Rilevamento a livello di colonna, risoluzione del record logico
Rilevamento a livello di riga, risoluzione del record logico
Rilevamento del record logico, risoluzione del record logico
Rilevamento a livello di riga o di colonna, risoluzione a livello di riga
In questo esempio, la pubblicazione è configurata come segue:
column_tracking è TRUE o FALSE
logical_record_level_conflict_detection è impostata su FALSE
logical_record_level_conflict_resolution è FALSE
In questo caso, il rilevamento è a livello di riga o di colonna e la risoluzione è a livello di riga. Queste impostazioni consentono di replicare tutte le modifiche apportate a un record logico come singola unità, senza rilevare o risolvere conflitti a livello del record logico.
Rilevamento a livello di colonna, risoluzione dei record logici
In questo esempio, la pubblicazione è configurata come segue:
column_tracking è TRUE
logical_record_level_conflict_detection è impostata su FALSE
logical_record_level_conflict_resolution è impostata su TRUE
Un server di pubblicazione e un Sottoscrittore dispongono dello stesso set di dati iniziale e tra le tabelle orders e customers viene definito un record logico. Il server di pubblicazione modifica la colonna custcol1 della tabella customers e la colonna ordercol1 della tabella orders . Il Sottoscrittore modifica la stessa riga della colonna custcol1 nella tabella customers e la stessa riga della colonna ordercol2 nella tabella orders . Le modifiche apportate alla stessa colonna della tabella customers risultano in conflitto, mentre le modifiche apportate alla tabella orders non lo sono.
Poiché i conflitti vengono risolti a livello di record logico, le modifiche vincenti apportate nell'Editore sostituiscono le modifiche apportate nelle tabelle del Sottoscrittore durante l'elaborazione della replicazione.
Rilevamento a livello di riga, risoluzione del record logico
In questo esempio, la pubblicazione è configurata come segue:
column_tracking è FALSE
logical_record_level_conflict_detection è impostata su FALSE
logical_record_level_conflict_resolution è impostata su TRUE
Un server di pubblicazione e un Sottoscrittore dispongono dello stesso set di dati iniziale. Il server di pubblicazione modifica la colonna custcol1 della tabella customers . Il Sottoscrittore modifica la colonna custcol2 della tabella customers e la colonna ordercol2 della tabella orders. Le modifiche apportate alla stessa riga della tabella customers risultano in conflitto, mentre le modifiche apportate nel Sottoscrittore alla tabella orders non lo sono.
Poiché i conflitti vengono risolti a livello di record logico, durante la sincronizzazione le modifiche prevalenti apportate nell'Autore di pubblicazione sostituiscono le modifiche apportate nelle tabelle del Sottoscrittore.
Rilevamento del record logico, risoluzione del record logico
In questo esempio, la pubblicazione è configurata come segue:
logical_record_level_conflict_detection è impostata su TRUE
logical_record_level_conflict_resolution è impostata su TRUE
Un server di pubblicazione e un Sottoscrittore dispongono dello stesso set di dati iniziale. Il server di pubblicazione modifica la colonna custcol1 della tabella customers . Il Sottoscrittore modifica la colonna ordercol1 della tabella orders . Non vi sono modifiche alla stessa riga o colonna. Tuttavia, dato che le modifiche sono state apportate allo stesso record logico per custid=1, le modifiche vengono rilevate come conflitto a livello dei record logici.
Poiché i conflitti vengono risolti anche a livello di record logico, durante la sincronizzazione la modifica risultata vincente apportata nel server di pubblicazione sostituisce la modifica apportata nelle tabelle del Sottoscrittore.
