In questo articolo, esaminiamo le opzioni di monitoraggio a livello di riga e colonna nella replica di tipo merge e come queste vengono utilizzate per rilevare i conflitti durante la replica di tipo merge.
Unire replica: La replica di tipo merge viene utilizzata per replicare i dati in entrambi i modi, ovvero dall'editore all'abbonato e dall'abbonato all'editore.
L'istantanea iniziale degli oggetti viene acquisita e applicata agli abbonati. Le modifiche incrementali ai dati e allo schema vengono tracciate utilizzando i trigger e applicate agli abbonati quando l'abbonato si sincronizza con l'editore.
Conflitti:
Nella replica di tipo merge, sia l'abbonato che l'editore sono indipendenti e i dati possono essere modificati su qualsiasi nodo.
Quando i dati vengono modificati sia sull'editore che sull'abbonato all'interno del ciclo di replica e quando l'abbonato si sincronizza con l'editore, si verifica un conflitto. L'agente di fusione determina il vincitore su entrambe le parti a seconda del risolutore di conflitti. Per impostazione predefinita, il vincitore è determinato da diversi parametri come abbonamento client o server, abbonamento pull o push, ecc.
Rilevamento dei conflitti:
Il rilevamento dei conflitti dipende dal tipo di monitoraggio che configuriamo per l'articolo.
- Tracciamento a livello di riga: Se vengono apportate modifiche ai dati a qualsiasi colonna della stessa riga su entrambe le estremità, viene considerato un conflitto.
- Tracciamento a livello di colonna: Se le modifiche ai dati vengono apportate alla stessa colonna a entrambe le estremità, questa modifica viene qualificata come conflitto.
Solutori:
I risolutori applicano i dati del vincitore a entrambe le estremità quando si verifica un conflitto.
Per impostazione predefinita, se c'è un conflitto tra l'editore e l'abbonato, l'editore vince sempre.
Se si verifica un conflitto tra due abbonati, il vincitore è determinato dall'abbonato client/server e dagli abbonamenti pull/push.
Oltre al resolver predefinito, ci sono anche alcuni resolver personalizzati. Discuteremo dei risolutori personalizzati nei prossimi articoli.
Configura la replica di tipo merge con il monitoraggio a livello di riga:
Database editore:pub_db
Database abbonati:sub_db
Creiamo la tabella "TBL_EMP" e la aggiungiamo per unire la replica.
CREATE TABLE TBL_EMP (EmpID INT, Emp_FName varchar(100),Emp_Lname varchar(100)) INSERT INTO TBL_EMP VALUES (1,'Jhon','P') INSERT INTO TBL_EMP VALUES (2,'Alison','P') INSERT INTO TBL_EMP VALUES (3,'Angela','P')
Per configurare la replica di tipo merge, l'editore deve essere configurato per utilizzare la distribuzione locale o la distribuzione remota.
Dopo aver configurato la distribuzione, vai alla cartella di replica in SSMS e fai clic con il pulsante destro del mouse su pubblicazioni locali.
Fai clic su Avanti e seleziona il database di pubblicazione, fai clic su Avanti e seleziona la replica di tipo merge, seleziona 2008 o successivo e aggiungi la tabella alla replica.
Ora fai clic sulle proprietà dell'articolo e seleziona le proprietà dell'articolo evidenziato.
Seleziona il livello di monitoraggio come monitoraggio a livello di riga.
Per impostazione predefinita, sarà il monitoraggio a livello di riga. Fai clic su OK, Avanti, Avanti . Aggiungi un filtro se desideri inviare dati specifici all'abbonato, altrimenti ignora, abilita Crea istantanea immediatamente , configura la sicurezza dell'agente secondo le tue esigenze, abilita Crea pubblicazione , specifica il nome della pubblicazione e fai clic su Fine .
Una volta generata l'istantanea iniziale, aggiungi l'abbonato.
Passare alla pubblicazione creata nella cartella di replica sull'editore, fare clic con il pulsante destro del mouse e selezionare Nuova sottoscrizione.
Fai clic su Avanti , seleziona la pubblicazione, fai clic su Avanti e seleziona l'abbonamento pull o push secondo le tue esigenze. In questo caso, ho utilizzato l'abbonamento push.
Seleziona il database degli abbonamenti e fai clic su Avanti , configura le credenziali di accesso per l'agente di unione e fai clic su Avanti .
Scegli il programma dell'agente in base alle tue esigenze. In questo caso, ho utilizzato Esegui solo su richiesta . Fai clic su Avanti , seleziona Inizializza immediatamente e seleziona client come tipo di abbonamento, fai clic su Avanti , attiva Crea abbonamento , fai clic su Avanti e Fine .
Dopo aver applicato lo snapshot iniziale, esegui la seguente dichiarazione sull'editore per aggiornare il record.
update TBL_EMP set Emp_Fname = 'Amanda' where empid = 1
Ora, sul db dell'abbonato, esegui l'istruzione seguente per aggiornare il cognome.
update TBL_EMP set Emp_Lname = 'A' where empid = 1
Ora, la stessa riga è stata modificata sia nel database dell'editore che nel database dell'abbonato all'interno dello stesso ciclo di replica.
In base all'opzione di monitoraggio che abbiamo impostato, ovvero il monitoraggio a livello di riga, la modifica è considerata un conflitto e verrà registrata nelle tabelle dei conflitti quando viene eseguito l'agente di unione.
Passa alla pubblicazione che hai creato ed espandi la pubblicazione per visualizzare le iscrizioni. Fare clic con il pulsante destro del mouse sull'abbonamento, selezionare Visualizza stato sincronizzazione e fare clic su Avvia.
Una volta che l'agente di unione è stato eseguito correttamente, vai all'abbonato e controlla i dati utilizzando la dichiarazione seguente.
use sub_db select * from TBL_EMP where empid = 1
Possiamo vedere che la modifica dell'editore ha vinto e la modifica dell'abbonato ha perso.
Le informazioni sui conflitti sono archiviate nelle tabelle dei conflitti e possono essere visualizzate nel visualizzatore dei conflitti.
Accedi al publisher, fai clic con il pulsante destro del mouse e seleziona Visualizza conflitti.
Seleziona la tabella dei conflitti e fai clic su OK per visualizzare i dettagli.
Modifica del livello di monitoraggio
Ora cambiamo il livello di monitoraggio nel monitoraggio a livello di colonna. Passare alla pubblicazione, fare clic con il pulsante destro del mouse e selezionare Proprietà editore. Fai clic su Articoli, seleziona la tabella, fai clic su Proprietà articolo, imposta le proprietà dell'articolo della tabella evidenziato, seleziona Monitoraggio a livello di colonna, fai clic su OK, fai clic su OK e quindi fai clic su Contrassegna per la reinizializzazione.
Questo contrassegnerà tutti gli abbonati per la reinizializzazione poiché stiamo cambiando il livello di tracciamento esistente con uno nuovo.
Passare alla pubblicazione, fare clic con il pulsante destro del mouse sulla pubblicazione e fare clic su Visualizza stato dell'agente snapshot , fai clic su Avvia per generare una nuova istantanea. Esistono anche altri modi per generare uno snapshot.
Ora, esegui la dichiarazione di seguito contro l'editore per aggiornare un record.
update TBL_EMP set Emp_Fname = 'Amanda' where empid = 2
Ora, esegui l'istruzione di seguito sul db dell'abbonato per aggiornare il cognome.
update TBL_EMP set Emp_Lname = 'A' where empid = 2
Eseguire manualmente l'agente di unione. Vedo ancora il conflitto nel record anche se abbiamo aggiornato due colonne diverse e impostato il livello di monitoraggio sul livello di colonna.
Possiamo vedere i dettagli nel visualizzatore di conflitti. La modifica del livello di tracciabilità esistente non ha funzionato. Quindi, ho riconfigurato la pubblicazione, impostato il livello di monitoraggio sul monitoraggio a livello di colonna prima di generare lo snapshot iniziale. È stato creato uno snapshot ed è stato aggiunto un abbonato alla pubblicazione.
Dopo aver applicato lo snapshot iniziale all'abbonato, esegui le seguenti istruzioni nel database dell'editore.
update TBL_EMP set Emp_Fname = 'Amanda' where empid = 3
Esegui la seguente istruzione nel database degli abbonati.
update TBL_EMP set Emp_Lname = 'A' where empid = 3
Eseguire manualmente l'agente di unione. Ora, nel database degli abbonati, interroga la tabella TBL_EMP.
L'aggiornamento dell'editore e dell'abbonato non è qualificato come conflitto poiché entrambi si trovano su colonne diverse e il livello di tracciamento è impostato sul tracciamento a livello di colonna. Non viene registrato alcun conflitto nelle tabelle dei conflitti, gli aggiornamenti sia sull'editore che sull'abbonato su colonne diverse non vanno persi.
Aggiorniamo la stessa colonna sull'editore e l'iscritto.
Eseguire la seguente istruzione sul database dell'editore.
use pub_db update TBL_EMP set Emp_Lname = 'B' where empid = 1
Eseguire la seguente istruzione sul database dell'abbonato.
use sub_db update TBL_EMP set Emp_Lname = 'C' where empid = 1
Eseguire l'agente di unione e interrogare la tabella TBL_EMP sull'abbonato. L'aggiornamento sull'abbonato viene perso e il conflitto viene registrato.
Rendimento:
Potrebbe esserci un sovraccarico delle prestazioni con il monitoraggio a livello di colonna rispetto al monitoraggio a livello di riga quando sono presenti enormi aggiornamenti. Ma nel mio caso, non ho notato alcuna differenza nei tempi di sincronizzazione sia per il monitoraggio a livello di riga che a livello di colonna in caso di enormi aggiornamenti poiché la tabella potrebbe essere semplice nella struttura (cioè pochissime colonne) e sia l'abbonato che il publisher si trovano sulla stessa istanza del server SQL.
Note:
- Per impostazione predefinita, è sempre il monitoraggio a livello di riga quando è configurata la replica di tipo merge.
- L'opzione del livello di monitoraggio dipende da una tabella. Quindi, puoi avere un livello di riga su una tabella e un livello di colonna su un'altra tabella.
- Queste opzioni aiutano solo quando viene rilevato un conflitto in base a un aggiornamento, non risolvendolo.
- Riconfigura la pubblicazione se la modifica del livello di tracciabilità esistente non funziona.
- Imposta il livello di monitoraggio in base alle tue esigenze aziendali.
