Condividi tramite

  • Articolo

Modalità di valutazione delle partizioni nelle pubblicazioni filtrate per la replica di tipo merge

Se una o più tabelle di una pubblicazione di tipo merge vengono filtrate mediante filtri con parametri e filtri join, i dati delle tabelle pubblicate vengono partizionati. Una partizione è un subset di righe di una tabella. Quando un Sottoscrittore esegue la sincronizzazione con un server di pubblicazione, tale server deve determinare quali righe appartengono a una partizione del Sottoscrittore sulla base dei valori implementati dal Sottoscrittore per le funzioni di sistema SUSER_SNAME() e/o HOST_NAME(). Il processo che include la valutazione dell'appartenenza delle modifiche a una partizione nel server di pubblicazione per ogni Sottoscrittore che riceve un set di dati filtrato viene definito valutazione delle partizioni.

A seconda dei dati presenti nelle tabelle pubblicate e delle impostazioni scelte durante la creazione di un filtro con parametri e di altri filtri join correlati, ogni riga di una tabella pubblicata può:

  • Appartenere a una partizione ed essere distribuita a un solo Sottoscrittore (valore 3 per il parametro @partition_options di sp_addmergearticle). Ad esempio, nel database AdventureWorks è possibile filtrare la tabella Employee mediante la clausola di filtro seguente: WHERE Employee.LoginID = SUSER_SNAME(). La riga corrispondente a ogni ID di accesso viene inviata a un solo Sottoscrittore.

  • Appartenere a una partizione ed essere replicata a più di un Sottoscrittore (valore 2 per @partition_options). Ad esempio, nel database AdventureWorks è possibile filtrare a tabella Products mediante la clausola di filtro seguente: WHERE Products.ProductLine = HOST_NAME(). Il valore di HOST_NAME() viene ignorato in modo che il gruppo di venditori responsabili per la vendita delle mountain bike riceva tutte le righe con un valore "M" nella colonna ProductLine. Ogni riga con un valore "M" appartiene a una sola partizione, ma viene inviata a più di un Sottoscrittore. Per ulteriori informazioni sull'utilizzo di HOST_NAME(), vedere la sezione relativa al filtraggio tramite HOST_NAME() in Filtri di riga con parametri.

  • Appartenere a più di una partizione ed essere distribuita a più di un Sottoscrittore (valore 0 o 1 per @partition_options). Ad esempio, nel database AdventureWorks è possibile filtrare la tabella Products mediante la clausola di filtro seguente: WHERE Products.ProductLine = HOST_NAME() or Products.ListPrice < 100. In questo caso, i venditori responsabili per la vendita delle mountain bike possono proporre anche altri prodotti purché il prezzo di vendita sia inferiore a 100 dollari. Poiché nella clausola di filtro è presente l'operatore OR, la riga può appartenere a più di una partizione.

Modalità di valutazione delle partizioni

La valutazione delle partizioni può essere eseguita in due modi nella replica di tipo merge, in relazione all'utilizzo o meno della funzionalità delle partizioni precalcolate. Se vengono soddisfatti alcuni requisiti, per impostazione predefinita le nuove pubblicazioni di tipo merge vengono create con la funzionalità delle partizioni precalcolate attivata e le pubblicazioni esistenti vengono automaticamente aggiornate per l'utilizzo della funzionalità. Per un elenco completo dei requisiti, vedere Ottimizzazione delle prestazioni dei filtri con parametri con le partizioni pre-calcolate.

Valutazione delle partizioni mediante partizioni precalcolate

Le partizioni precalcolate consentono di precalcolare e rendere persistente l'appartenenza per tutte le modifiche nel server di pubblicazione nel momento in cui le modifiche vengono apportate alle tabelle pubblicate. Di conseguenza, quando un Sottoscrittore esegue la sincronizzazione con il server di pubblicazione, può iniziare subito a scaricare le modifiche relative alla propria partizione senza dover eseguire il processo di valutazione delle partizioni. Questa soluzione determina un notevole vantaggio in termini di prestazioni quando la pubblicazione include un elevato numero di modifiche, Sottoscrittori o articoli.

Le tabelle di sistema seguenti sono coinvolte nella valutazione delle partizioni precalcolata:

  • MSmerge_partition_groups

  • MSmerge_current_partition_mappings

  • MSmerge_past_partition_mappings

In MSmerge_partition_groups è inclusa una riga per ogni partizione definita in una pubblicazione. Le partizioni possono essere:

  • Definite in modo esplicito mediante sp_addmergepartition o la pagina Partizioni dati della finestra di dialogo Proprietà pubblicazione.

  • Create automaticamente quando un Sottoscrittore esegue la sincronizzazione, se il Sottoscrittore richiede una partizione a cui non è ancora associata una voce in MSmerge_partition_groups.

Le altre due tabelle (MSmerge_current_partition_mappings e MSmerge_past_partition_mappings) vengono popolate in base alle modifiche apportate alle tabelle pubblicate. Ogni volta che si apporta una modifica a una tabella pubblicata nel database di pubblicazione, viene attivato un trigger di tipo merge che registra i metadati:

  • In MSmerge_current_partition_mappings è inclusa una riga per ogni combinazione univoca di righe in MSmerge_contents e MSmerge_partition_groups. Ad esempio, se una riga di una tabella utente appartenente a due partizioni viene aggiornata, viene inserita una riga in MSmerge_contents per estendere l'aggiornamento e due righe vengono inserite in MSmerge_current_partition_mappings per indicare che la riga aggiornata appartiene a due partizioni.

  • In MSmerge_past_partition_mappings è inclusa una riga per ogni riga che non appartiene più a una determinata partizione. Una riga viene esclusa da una partizione nei seguenti casi:

    • La riga viene eliminata. Se una riga viene eliminata da una tabella utente, viene inserita una riga in MSmerge_tombstone e una o più righe vengono inserite in MSmerge_past_partition_mappings.

    • Il valore in una colonna utilizzata come filtro viene modificato. Ad esempio, se un filtro con parametri è basato sullo stato in cui si trova la sede centrale di un'azienda e quest'ultima si trasferisce, la riga relativa all'azienda e tutte quelle correlate in altre tabelle possono essere escluse dalla partizione di dati di un venditore e inserite nella partizione di un altro venditore. Se una riga viene aggiornata in modo tale da non appartenere più a una partizione, in MSmerge_contents viene inserita o aggiornata una riga e una o più righe vengono inserite in MSmerge_past_partition_mappings.

    [!NOTA]

    Se si utilizzano partizioni non sovrapposte con una sottoscrizione per partizione (valore 3 per il parametro sp_addmergearticle di @partition_options), le tabelle di sistema MSmerge_current_partition_mappings e MSmerge_past_partition_mappings non vengono utilizzate per tenere traccia dei mapping di partizione delle righe, poiché ogni riga appartiene solo a una partizione e può essere modificata in un solo Sottoscrittore.

Valutazione delle partizioni mediante il processo SetupBelongs

Se non si adottano partizioni precalcolate, viene utilizzato un processo denominato SetupBelongs. Durante la sincronizzazione, la valutazione delle partizioni viene eseguita per ogni modifica apportata a una tabella filtrata nel server di pubblicazione dall'ultima esecuzione dell'agente di merge per un determinato Sottoscrittore. Questo processo viene ripetuto per ogni Sottoscrittore che esegue la sincronizzazione con il server di pubblicazione.

Per eseguire la valutazione delle partizioni per un Sottoscrittore, l'agente di merge richiama la stored procedure di sistema sp_MSsetupbelongs, che:

  1. Crea due tabelle temporanee per ogni articolo filtrato: #belongs_<RandomNumber> e #notbelongs_<RandomNumber>.

  2. Utilizza il valore restituito dalle funzioni SUSER_SNAME() e/o HOST_NAME() al Sottoscrittore per eseguire una query in una vista di sistema. La query consente di determinare se una riga in MSmerge_contents o MSmerge_tombstone è rilevante per la partizione del Sottoscrittore.

  3. Se la riga non è rilevante per il Sottoscrittore, ad esempio un inserimento per un'altra partizione, i metadati per questa riga non vengono archiviati in #belongs o #notbelongs. Se la riga è rilevante per la partizione, possono verificarsi due situazioni:

    • Una riga viene aggiunta a #belongs se la riga in MSmerge_contents è un inserimento che appartiene alla partizione oè un aggiornamento che non modifica alcun valore nelle colonne utilizzate per il filtro.

    • Una riga viene aggiunta a #notbelongs se la riga in MSmerge_contents è un aggiornamento che modifica un valore in una o più colonne utilizzate per il filtro (ovvero sposta la riga in una nuova partizione) o se la riga in MSmerge_tombstone rappresenta l'eliminazione di una riga nella partizione.

[!NOTA]

Anche se le partizioni precalcolate sono attivate, il processo SetupBelongs viene utilizzato per la prima sincronizzazione di una sottoscrizione se quest'ultima viene creata dopo che altre sottoscrizioni hanno iniziato a ricevere le modifiche.