Ottimizzazione delle prestazioni della replica di tipo merge con il rilevamento condizionale delle eliminazioni
[!NOTA]
Questa caratteristica verrà rimossa a partire da una delle prossime versioni di Microsoft SQL Server. Evitare di utilizzare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata.
Con la replica di tipo merge è possibile specificare che le eliminazioni per uno o più articoli non devono essere rilevate dai trigger di replica e dalle tabelle di sistema. Se si specifica questa opzione per un articolo, le eliminazioni non vengono rilevate o replicate dal server di pubblicazione o da qualsiasi Sottoscrittore. Questa opzione è disponibile per il supporto di numerosi scenari applicativi e per offrire l'ottimizzazione delle prestazioni, nei casi in cui la replica delle eliminazioni non è necessaria o desiderata. Il miglioramento delle prestazioni avviene per tre motivi: non vengono archiviati i metadati delle eliminazioni, le eliminazioni non vengono enumerate durante la sincronizzazione e, infine, non vengono replicate nel Sottoscrittore e applicate allo stesso.
[!NOTA]
Per utilizzare gli articoli di solo download, il livello di compatibilità della pubblicazione deve essere almeno 90RTM. Per ulteriori informazioni, vedere la sezione relativa al livello di compatibilità per le pubblicazioni di tipo merge nell'argomento Utilizzo di più versioni di SQL Server in una topologia di replica.
Questa opzione può essere specificata alla creazione della pubblicazione oppure attivata e disattivata se un'applicazione richiede la replica di alcune eliminazioni e non di altre, ad esempio eliminazioni batch. Gli esempi seguenti illustrano le modalità di utilizzo di questa opzione in un'applicazione.
Un'applicazione per la forza vendita mobile in genere contiene tabelle come SalesOrderHeader, SalesOrderDetail e Product. Gli ordini vengono immessi nel Sottoscrittore e poi replicati nel server di pubblicazione, che spesso assicura i dati a un sistema di evasione degli ordini. Molti lavoratori mobili utilizzano dispositivi palmari che hanno una capacità di archiviazione limitata: quando l'ordine viene ricevuto nel server di pubblicazione, può essere eliminato nel Sottoscrittore. L'eliminazione non viene propagata al server di pubblicazione, perché l'ordine è ancora attivo nel sistema.
In questo scenario, le eliminazioni non verrebbero rilevate per le tabelle SalesOrderHeader e SalesOrderDetail. Verrebbero invece rilevate per la tabella Product perché se un prodotto viene eliminato nel server di pubblicazione l'eliminazione deve essere inviata al Sottoscrittore per mantenere aggiornato l'elenco dei prodotti.
Un'applicazione potrebbe archiviare i dati storici in una tabella come TransactionHistory, da cui vengono periodicamente eliminati i record più vecchi di un anno. La tabella potrebbe essere filtrata in modo che i Sottoscrittori ricevano solo i dati delle transazioni del mese corrente. Le eliminazioni batch mensili del server di pubblicazione, con cui vengono eliminati i dati più vecchi, non interessano i Sottoscrittori, ma verrebbero comunque rilevate ed enumerate per impostazione predefinita.
In questo scenario, prima che abbia luogo l'elaborazione batch, sarebbe possibile interrompere l'attività del sistema e disattivare il rilevamento delle eliminazioni dall'applicazione. Al termine dell'elaborazione, sarebbe possibile riattivare la rilevazione.
.gif "Nota importante") Importante |
|---|
Se nel server di pubblicazione prosegue l'attività, è necessario verificare che le eliminazioni che dovrebbero essere propagate ai Sottoscrittori non abbiano luogo mentre il rilevamento delle eliminazioni è disattivato. |
Per specificare di non rilevare le eliminazioni
- Programmazione Transact-SQL della replica: Procedura: Disattivazione del rilevamento delle eliminazioni per gli articoli di merge (programmazione Transact-SQL della replica)