Informazioni sull'ordine di elaborazione dell'articolo replica di tipo merge

Questo articolo illustra come comprendere l'ordine di elaborazione dell'articolo replica di tipo merge.

Versione originale del prodotto: SQL Server
Numero KB originale: 307356

Riepilogo

Il agente di merge segue un set specifico di regole che regolano l'ordine in cui il processo di unione applica le modifiche agli articoli durante il processo di sincronizzazione.

Questo articolo illustra perché l'ordine di elaborazione degli articoli è importante.

Ulteriori informazioni

Esistono due motivi principali per cui l'ordine di elaborazione degli articoli è importante:

• In molti casi, il agente di merge deve elaborare le modifiche agli articoli che partecipano ai vincoli DRI (Declarative Referial Integrity) in un ordine specifico per ottenere prestazioni ottimali. In caso contrario, l'agente di merge potrebbe dover ripetere le operazioni DML (Data Manipulation Language) che ha provato in un ordine non corretto, ovvero provare a INSERIRE una riga figlio prima di quella del padre.

• Le applicazioni che usano trigger per mantenere l'integrità referenziale richiedono l'agente di merge di inviare modifiche in un ordine specifico. Se il agente di merge invia modifiche in un ordine non corretto, il trigger eseguirà probabilmente il rollback della modifica e la modifica non verrà propagata in tutta la topologia di replica.

Note

Il agente di merge può ignorare la valutazione dei vincoli FOREIGN KEY e l'esecuzione del trigger utente quando applica le operazioni di modifica di SQL DML a una replica partner. Affinché ciò si verifichi, il vincolo FOREIGN KEY e il trigger utente, o entrambi, devono essere stati creati con l'opzione NOT FOR REPLICATION . In entrambi i casi, il processo di unione presuppone che SQL Server abbia valutato correttamente la logica di business quando esegue la modifica avviata dall'utente originale rispetto all'oggetto e che non debba rivalutare queste condizioni quando replica i dati nella replica partner. Il vantaggio principale dell'uso di NOT FOR REPLICATION in questo modo è l'aumento delle prestazioni. Per altre informazioni sull'opzione NOT FOR REPLICATION e su come usarla in modo appropriato, vedere l'argomento relativo all'opzione NOT FOR REPLICATION nella documentazione online di SQL Server 2000.

Per i due motivi elencati in precedenza, l'ordine in cui il agente di merge recapita le modifiche a una replica partner è importante.

Prima di iniziare una discussione sull'ordine di elaborazione degli articoli, è importante avere una conoscenza di due concetti chiave. I due concetti chiave sono i seguenti:

• Nome alternativo di un articolo.

• Generazione.

Ecco una descrizione dei due concetti.

• Nomi alternativi articolo

  Un nome alternativo è un valore intero usato dal agente di merge per identificare un articolo (una tabella di SQL Server) per unire la replica. Il processo di installazione unione assegna un nome alternativo all'articolo quando aggiunge l'articolo a una pubblicazione di tipo merge. Se un articolo partecipa ai vincoli DRI, il processo di configurazione di merge tenta di generare un nome alternativo articolo che rifletta i vincoli DRI definiti. Il processo di unione assegna tabelle a cui fa riferimento un vincolo FOREIGN KEY (padre) un nome alternativo articolo più piccolo rispetto a quello della tabella di riferimento (la tabella figlio o la tabella in cui è definito il vincolo FOREIGN KEY).

  Se una tabella non partecipa ai vincoli DRI, il processo di configurazione di merge assegna il nome alternativo dell'articolo in base all'ordine in cui aggiunge l'articolo alla pubblicazione (in ordine crescente).

• Generazione

Una generazione è un valore intero usato dal agente di merge per tenere traccia di un gruppo logico di modifiche a un determinato articolo. Tutte le modifiche apportate a un articolo specifico in una determinata replica tra sincronizzazioni di tipo merge sono associate alla stessa generazione. Ogni volta che viene eseguita la agente di merge, chiude la generazione aperta esistente e quindi apre una nuova generazione con cui associare il set successivo di modifiche.

Elaborazione di INSERT, UPDATEs e DELET

Il agente di merge partiziona gli articoli per una particolare pubblicazione in due gruppi distinti:

• Il agente di merge inserisce articoli che non sono coinvolti in alcuna relazione di filtro di join e non correlati tramite DRI ad alcun articolo coinvolto nei filtri di join in un unico gruppo.

• Il agente di merge inserisce articoli coinvolti in modo esplicito nelle relazioni di filtro di join e articoli correlati all'aggiunta di articoli di filtro tramite DRI in un secondo gruppo distinto.

Il agente di merge aggiunge ogni articolo definito alla pubblicazione solo a uno dei gruppi precedenti.

Il agente di merge utilizza i gruppi per determinare l'ordine di elaborazione complessivo di UPDATEs, INSERTse DELETEs per tutti gli articoli definiti nella pubblicazione.

In ognuno dei due gruppi, i processi di agente di merge INSERTs e UPDATEs in ordine alternativo dell'articolo crescente e elaborano DELETEs in ordine decrescente il nome alternativo dell'articolo. In primo luogo, l'agente di merge elabora tutti nel DELETEs loro insieme in un determinato gruppo, seguito da UPDATEs e INSERTs (anche in un determinato gruppo). Concettualmente, il agente di merge accoda i due gruppi sopra indicati l'uno all'altro (non unito) nell'ordine elencato in precedenza. Il agente di merge inizia elaborando DELETEs per il primo gruppo e quindi estende DELETE l'elaborazione al secondo gruppo e il resto delle modifiche per i due gruppi vengono elaborati in parallelo. Anche se il agente di merge mantiene l'ordine di elaborazione degli articoli in ogni rispettivo gruppo, il agente di merge non mantiene un ordine di elaborazione rigoroso degli articoli tra i due gruppi corrispondenti. Di conseguenza, nel caso di un INSERT oggetto o UPDATE, è possibile che le modifiche del primo gruppo con un nome alternativo di articolo superiore possano arrivare prima di quelle del secondo gruppo con un soprannome inferiore. La situazione viceversa può verificarsi anche per un oggetto DELETE. Entrambi questi comportamenti sono in fase di progettazione.

Possibili effetti dell'invio in batch di generazione sull'ordine di elaborazione degli articoli

Come indicato in precedenza, con una generazione è possibile raggruppare logicamente le modifiche (INSERTse UPDATEs DELETEs) che si verificano per un determinato articolo in una determinata replica tra sessioni di sincronizzazione. In definitiva, il agente di merge funziona con generazioni quando determina quali modifiche deve scambiare tra due repliche. Il agente di merge negozia una generazione comune nei punti seguenti del processo di sincronizzazione:

• Prima di caricare le modifiche dal sottoscrittore al server di pubblicazione.

• Prima di scaricare le modifiche dal server di pubblicazione al sottoscrittore.

Il agente di merge usa questa generazione comune come punto di partenza durante l'enumerazione delle generazioni da inviare a una replica partner durante le fasi di caricamento e download della sincronizzazione di tipo merge.

Il agente di merge elabora le generazioni in batch, dette anche batch di generazione. Per impostazione predefinita, 100 generazioni vengono incluse in ogni batch di generazione che il agente di merge carica nel server di pubblicazione dal sottoscrittore o scarica nel sottoscrittore dal server di pubblicazione. Le dimensioni del batch di generazione sono configurabili tramite -UploadGenerationsPerBatch e i -DownloadGenerationsPerBatch parametri agente di merge o tramite il profilo di agente di merge. Nel caso predefinito, se sono presenti più di 100 generazioni che è necessario scambiare (ovvero scaricare e caricare o entrambi) tra un server di pubblicazione (o un nuovo editore) e un sottoscrittore, il agente di merge elabora più batch di generazione. Il numero di batch dipende dal numero di generazioni che il agente di merge deve scambiare e dalle generazioni per ogni impostazione batch forzata per una determinata sessione di merge.

In una situazione in cui vengono scambiati batch di più generazione, il agente di merge può suddividere le modifiche padre e figlio correlate tra due batch di generazione distinti. In tal caso, il agente di merge può recapitare una modifica figlio in un batch di generazione prima del batch di generazione che contiene la modifica padre associata. Nelle topologie di merge gerarchiche che usano re-publisher, si verifica una rara situazione in cui la suddivisione delle modifiche padre e figlio tra batch di generazione può portare alla mancata convergenza. Per altre informazioni sulla non convergenza, vedere l'articolo seguente:

Non convergenza quando SQL Server elabora le generazioni figlio e padre in batch di generazione separati.

È possibile aumentare i -UploadGenerationsPerBatch parametri e -DownloadGenerationsPerBatch descritti in precedenza per evitare di suddividere le modifiche padre e figlio tra batch di generazione.

L'ordine di elaborazione degli articoli viene mantenuto in un determinato batch di generazione in base alle regole descritte in precedenza. Tuttavia, il agente di merge non può mantenere l'ordine di elaborazione degli articoli tra batch di generazione.