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

  • Articolo

Questo articolo illustra come comprendere l'ordine di elaborazione dell'articolo di 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 merge 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 dell'articolo è importante:

  • In molti casi, il agente di merge deve elaborare le modifiche apportate agli articoli che partecipano ai vincoli DRI (Declarative Referential 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) tentate in un ordine errato, ovvero provare a INSERIRE una riga figlio prima di quella dell'elemento 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.

Nota

Il agente di merge può ignorare la valutazione del vincolo FOREIGN KEY e l'esecuzione del trigger utente quando applica le operazioni di modifica di SQL DML a una replica partner. A tale scopo, 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 merge presuppone che SQL Server abbia valutato correttamente la logica di business quando esegue la modifica avviata dall'utente originale sull'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 sull'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 apporta modifiche a una replica partner è importante.

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

  • Soprannome di un articolo.

  • Una generazione.

Ecco una descrizione dei due concetti.

  • Nomi alternativi dell'articolo

    Un nickname è un valore intero usato dal agente di merge per identificare un articolo (una tabella SQL Server) per la replica di tipo merge. Il processo di installazione di merge assegna un nome alternativo all'articolo quando aggiunge l'articolo a una pubblicazione di tipo merge. Se un articolo fa parte dei vincoli DRI, il processo di installazione di merge tenta di generare un nome alternativo dell'articolo che riflette i vincoli DRI definiti. Il processo di merge assegna alle tabelle a cui fa riferimento un vincolo FOREIGN KEY (padre) un nome alternativo dell'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 fa parte dei vincoli DRI, il processo di installazione 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 apportate a un articolo specifico. Tutte le modifiche apportate a un particolare articolo in una replica specifica tra sincronizzazioni di merge sono associate alla stessa generazione. Ogni volta che viene eseguito il agente di merge, chiude la generazione aperta esistente e quindi apre una nuova generazione a cui associare il set di modifiche successivo.

Elaborazione di INSERT, UPDATE E DELETE

Il agente di merge partiziona gli articoli per una pubblicazione specifica 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 agli articoli coinvolti nei filtri di join in un unico gruppo.

  • Il agente di merge inserisce articoli esplicitamente coinvolti nelle relazioni di filtro di join e articoli correlati agli articoli di filtro join 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 rispettivi gruppi, l'agente di merge elabora INSERTs e UPDATEs in ordine crescente di soprannome dell'articolo e elabora DELETEs in ordine decrescente di soprannome dell'articolo. In primo luogo, il agente di merge elabora tutti DELETEs nella loro interezza in un determinato gruppo, seguito da UPDATEs e INSERTs (anche in un determinato gruppo). Concettualmente, il agente di merge accoda i due gruppi indicati in precedenza tra loro (non uniti) nell'ordine elencato in precedenza. Il agente di merge inizia dall'elaborazione DELETEs per il primo gruppo e quindi estende DELETE l'elaborazione al secondo gruppo e il resto delle modifiche per i due gruppi viene elaborato 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 degli articoli rigoroso tra i due rispettivi gruppi. Di conseguenza, nel caso di o INSERTUPDATE, è possibile che le modifiche dal primo gruppo con un soprannome di articolo superiore possano arrivare prima di quelle del secondo gruppo con un soprannome inferiore. La situazione inversa può verificarsi anche per un DELETEoggetto . Entrambi questi comportamenti sono di progettazione.

Possibili effetti del batch di generazione sull'ordine di elaborazione degli articoli

Come indicato in precedenza, con una generazione è possibile raggruppare logicamente le modifiche (INSERTsUPDATEse DELETEs) che si verificano per un particolare articolo in una replica specifica tra sessioni di sincronizzazione. In definitiva, il agente di merge funziona con le 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 per enumerare le 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, detti anche batch di generazione. Per impostazione predefinita, in ogni batch di generazione vengono incluse 100 generazioni 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 e -UploadGenerationsPerBatch i -DownloadGenerationsPerBatch parametri agente di merge o tramite il profilo agente di merge. Nel caso predefinito, se sono presenti più di 100 generazioni che è necessario scambiare (ovvero scaricare e caricare o entrambe) 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 in vigore per una sessione di merge specifica.

In una situazione in cui vengono scambiati più batch di generazione, il agente di merge può suddividere le modifiche padre e figlio correlate in due batch di generazione separati. In questo caso, il agente di merge può fornire una modifica figlio in un batch di generazione prima del batch di generazione che contiene la modifica padre associata. Nelle topologie di unione gerarchica che usano ri-editori, esiste una situazione rara in cui la suddivisione delle modifiche padre e figlio tra i batch di generazione può portare alla non 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 dividere le modifiche padre e figlio tra i batch di generazione.

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