Come interpretare l'ordine di elaborazione articolo di replica di tipo Merge

Riepilogo

L'agente di Merge segue un insieme specifico di regole che determinano l'ordine in cui il processo di merge applica le modifiche agli articoli durante il processo di sincronizzazione.

In questo articolo viene descritto perché è importante utilizzare l'ordine di elaborazione articolo.

Ulteriori informazioni

Esistono due motivi principali perché è importante utilizzare l'ordine di elaborazione articolo:

  • In molti casi, l'agente di Merge deve elaborare le modifiche agli articoli che fanno parte di vincoli di integrità referenziale dichiarativa (DRI) in un ordine specifico per raggiungere prestazioni ottimali. Se no, l'agente di Merge potrebbe dover ripetere le operazioni di Data Manipulation Language (DML) tentate in un ordine non corretto (ovvero, tentare di INSERIRE una riga figlio prima di quella del padre).

  • Applicazioni che utilizzano trigger per mantenere l'integrità referenziale richiedono l'agente di Merge inviare le modifiche in un ordine specifico. Se l'agente di Merge invia le modifiche in un ordine errato, il trigger verrà probabilmente eseguito il rollback della modifica e la modifica non si propaga in tutta la topologia di replica.

Notare che l'agente di Merge può ignorare la valutazione di vincolo di chiave esterna e l'esecuzione del trigger utente quando viene applicato SQL DML modificare operazioni in una replica partner. A questo scopo, il vincolo FOREIGN KEY e il trigger dell'utente o entrambi, deve essere stati creati con l'opzione NOT FOR REPLICATION. In entrambi i casi, il processo di unione presuppone che SQL Server ha valutato la logica di business correttamente quando viene eseguita la modifica avviata dall'utente originale in base all'oggetto e che non è necessario rivalutare queste condizioni, quando i dati di replica alla replica di partner. Il principale vantaggio di utilizzare non per la replica in questo modo è un aumento delle prestazioni. Per ulteriori informazioni, l'opzione NOT FOR REPLICATION e come utilizzarlo in modo appropriato, vedere l'argomento "Non per l'opzione di replica" nella documentazione in linea di SQL Server 2000.

Per due ragioni elencate in precedenza, è importante l'ordine in cui l'agente di Merge trasmette le modifiche a una replica partner.

Prima di iniziare una discussione dell'ordine di elaborazione articolo, è importante conoscere i due concetti chiave. Di seguito sono riportati i due concetti chiave:

  • Un nome alternativo di articolo.

  • Una generazione.

Di seguito è riportata una descrizione dei due concetti.

Articolo pseudonimi

Un nome alternativo è un valore integer che l'agente di Merge viene utilizzato per identificare un articolo, una tabella di SQL Server, per replica di tipo merge. Il processo di unione il programma di installazione assegna un nome alternativo articolo durante l'aggiunta dell'articolo per una pubblicazione di tipo merge. Se vincoli DRI fa parte di un articolo, il processo di unione il programma di installazione tenta di generare un nome alternativo di articolo che riflette definiti vincoli DRI. Il processo di merge assegna tabelle cui fa riferimento un vincolo FOREIGN KEY (padre), nome alternativo di un articolo di dimensioni inferiore rispetto a quello della tabella di riferimento (tabella figlio, o la tabella in cui è definito il vincolo FOREIGN KEY).

Se nei vincoli DRI fa parte di una tabella, il processo di installazione di unione viene assegnato il soprannome di articolo in base all'ordine in cui aggiunto l'articolo alla pubblicazione (in ordine crescente).


Generazione

Una generazione è un valore integer che l'agente di Merge viene utilizzato per tenere traccia di un gruppo logico di modifiche a un determinato articolo. Tutte le modifiche apportate a un determinato articolo in una determinata replica tra le sincronizzazioni unione associati alla stessa generazione. Ogni volta che viene eseguito l'agente di Merge, chiude la generazione di apertura esistente e quindi viene aperta una nuova generazione a cui associare il successivo set di modifiche.

Elaborazione di inserimenti, aggiornamenti ed eliminazioni

L'agente di Merge partizioni degli articoli per una particolare pubblicazione in due gruppi distinti:

  • L'agente di Merge colloca gli articoli che non è coinvolta in tutte le relazioni di filtro di join e tramite DRI non riguardano tutti gli articoli coinvolti nei filtri join in un unico gruppo.

  • In relazioni filtro join e articoli relativi a partecipare filtro articoli tramite DRI in un gruppo distinto in secondo luogo, l'agente di Merge inserito articoli che sono coinvolti in modo esplicito.

L'agente di Merge aggiunge ogni articolo definito per la pubblicazione a uno solo dei gruppi precedenti.

L'agente di Merge utilizza i gruppi per determinare l'intero ordine di elaborazione degli aggiornamenti, inserimenti ed eliminazioni per tutti gli articoli per la pubblicazione.

In ciascuno dei due rispettivi gruppi, l'agente di Merge elabora gli inserimenti e aggiornamenti nell'articolo soprannome ordine crescente e processi di eliminazioni in senso decrescente soprannome articolo. Tutti i processi di agente di Merge, Elimina interamente in un determinato gruppo, seguito da aggiornamenti e inserimenti (anche in un determinato gruppo). Concettualmente, l'agente di Merge aggiunge due suddetti gruppi l'uno a altro (non unite) nell'ordine indicato in precedenza. L'agente di Merge avvia l'elaborazione delle eliminazioni per il primo gruppo e quindi estende l'elaborazione al secondo gruppo di eliminazione e il resto delle modifiche per i due gruppi vengono eseguito in parallelo. Anche se l'agente di Merge mantiene l'ordine di elaborazione articolo ogni gruppo, l'agente di Merge non mantiene l'ordine di elaborazione articolo strict tra i due gruppi di corrispondenti. Di conseguenza, in caso di un inserimento o aggiornamento, è possibile che le modifiche del primo gruppo con un soprannome articolo superiore possono arrivare prima di quelli del secondo gruppo con uno pseudonimo inferiore. Il caso contrario può verificarsi anche per un'operazione di eliminazione. Entrambi questi comportamenti sono in base alla progettazione.


Possibili effetti della generazione, la divisione in batch articolo ordine di elaborazione

Come affermato in precedenza, con una generazione è possibile raggruppare logicamente modifiche (inserimenti, aggiornamenti ed eliminazioni) che si verificano per un determinato articolo in una determinata replica tra sessioni di sincronizzazione. In definitiva, l'agente di Merge funziona con le generazioni quando determina quali modifiche è necessario scambiare tra due repliche. L'agente di Merge negozia una generazione comune ai seguenti punti nel processo di sincronizzazione:

  • Prima che carica le modifiche dal server di sottoscrizione al server di pubblicazione.

  • Prima che scarica le modifiche dal server di pubblicazione nel server di sottoscrizione.

L'agente di Merge utilizza questa generazione comune come punto di partenza quando si enumerano le generazioni di inviare a una replica partner durante il caricamento e scaricare le fasi della sincronizzazione di tipo merge.

L'agente di Merge elabora generazioni in batch, noto anche come batch di generazione. Per impostazione predefinita, le generazioni 100 sono inclusi in ogni batch di generazione che l'agente di Merge carica al server di pubblicazione dal server di sottoscrizione, o il download al server di sottoscrizione dal server di pubblicazione. La dimensione del batch di generazione è configurabile tramite il
-UploadGenerationsPerBatch e Parametri-DownloadGenerationsPerBatch dell'agente di Merge parametri, o tramite il profilo di agente di Merge. Nel caso predefinito, se esistono più di 100 generazioni che è necessario exchange (ovvero, download e caricamento o entrambi) tra un server di pubblicazione (o un server di ripubblicazione) e un server di sottoscrizione, l'agente di Merge elabora più batch di generazione. Il numero di batch dipende dal numero di generazioni che è l'agente di Merge per lo scambio e le generazioni per batch impostazioni in forza di una sessione particolare unione.


In una situazione in cui vengono scambiati più batch di generazione, l'agente di Merge può suddividere modifiche di figlio e padre correlati in due batch di generazione separata. In tal caso, l'agente di Merge può consegnare una modifica figlio in un batch di generazione in batch di generazione che contiene la modifica del padre associata. In topologie di unione gerarchica che utilizzano la pubblicazione, è una rara situazione in cui la divisione di padre e figlio modifiche in batch di generazione può portare a non di convergenza. Per ulteriori informazioni non di convergenza, vedere il seguente articolo della Microsoft Knowledge Base:

308266 PRB: Non convergenza quando SQL Server elabora figlio e padre generazioni batch di generazione separata

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

Ordine di elaborazione articolo viene mantenuto in un batch di generazione ai sensi delle norme descritte in precedenza. Tuttavia, l'agente di Merge non può gestire articolo ordine di elaborazione in batch di generazione.

Serve aiuto?

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa a Microsoft Insider

Queste informazioni sono risultate utili?

Grazie per il feedback!

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×