Condividi tramite

Miglioramento delle prestazioni della replica di tipo merge

  • Articolo

Data aggiornamento: 12 dicembre 2006

Dopo aver valutato i suggerimenti relativi alle prestazioni generali descritti in Miglioramento delle prestazioni generali della replica, è opportuno considerare questi ulteriori aspetti specifici della replica di tipo merge.

Progettazione di database

  • Colonne di indice utilizzate in filtri di riga e filtri join.
    Se si applica un filtro di riga a un articolo pubblicato, è necessario creare un indice per ogni colonna specificata nella clausola WHERE del filtro. In assenza dell'indice, ogni riga della tabella deve essere letta da Microsoft SQL Server per determinare se debba essere inclusa o meno nella partizione. In presenza dell'indice, SQL Server è in grado di individuare rapidamente le righe da includere. L'elaborazione più rapida si ottiene quando tramite la replica è possibile risolvere completamente la clausola WHERE del filtro solo in base all'indice.
    È inoltre importante indicizzare tutte le colonne utilizzate nei filtri join. A ogni esecuzione dell'agente di merge viene eseguita la ricerca della tabella di base per determinare quali righe della tabella padre e delle tabelle correlate sono incluse in una partizione. La creazione di un indice delle colonne unite in join consente di evitare la lettura di ogni riga della tabella da parte di SQL Server a ogni esecuzione dell'agente di merge.
    Per ulteriori informazioni sull'utilizzo dei filtri, vedere Filtraggio dei dati pubblicati per la replica di tipo merge.
  • ‏Si considerino le tabelle in fase di sovranormalizzazione che includono tipi di dati LOB (Large Object).
    Quando viene eseguita la sincronizzazione, è possibile che l'agente di merge debba leggere e trasferire l'intera riga di dati da un server di pubblicazione o un Sottoscrittore. Se la riga include colonne con dati LOB, questo processo può richiedere l'allocazione di memoria aggiuntiva e influire negativamente sulle prestazioni anche se tali colonne non sono state aggiornate. Per ridurre la probabilità di tale impatto negativo sulle prestazioni, è possibile inserire le colonne LOB in una tabella distinta utilizzando una relazione uno-a-uno con la parte rimanente della riga di dati. I tipi di dati text, ntext e image sono obsoleti. Se è necessario includere dati LOB, è consigliabile utilizzare rispettivamente i tipi di dati varchar(max), nvarchar(max) e varbinary(max).

Progettazione della pubblicazione

  • Utilizzare un livello di compatibilità della pubblicazione di 90RTM (SQL Server 2005).
    A meno che uno o più Sottoscrittori utilizzino una versione diversa di SQL Server, specificare che la pubblicazione deve supportare solo SQL Server 2005. Ciò consente di sfruttare le nuove funzioni e le ottimizzazioni delle prestazioni. Per ulteriori informazioni, vedere la sezione relativa al livello di compatibilità per le pubblicazioni di tipo merge in Utilizzo di più versioni di SQL Server in una topologia di replica.
  • Utilizzare impostazioni appropriate relative al periodo di memorizzazione della pubblicazione.
    Il periodo di memorizzazione della pubblicazione, ovvero il periodo di tempo massimo prima che una sottoscrizione debba essere sincronizzata, determina la durata dell'archiviazione dei metadati di rilevamento. Un valore elevato può influire sulle prestazioni di elaborazione e archiviazione. Per ulteriori informazioni sull'impostazione del periodo di memorizzazione della pubblicazione, vedere Scadenza e disattivazione delle sottoscrizioni.
  • Utilizzare articoli di solo download per le tabelle modificate solo nel server di pubblicazione. Per ulteriori informazioni, vedere Ottimizzazione delle prestazioni della replica di tipo merge con gli articoli di solo download.

Progettazione e utilizzo dei filtri

  • Limitare la complessità delle clausole dei filtri di riga.
    Limitando la complessità dei criteri di filtro è possibile migliorare le prestazioni durante la valutazione da parte dell'agente di merge delle modifiche delle righe da inviare ai Sottoscrittori. Evitare di utilizzare selezioni secondarie all'interno delle clausole dei filtri di riga. Considerare, invece, l'opportunità di utilizzare filtri di join, in genere più efficienti se utilizzati per partizionare i dati di una tabella in base alla clausola del filtro di riga di un'altra tabella. Per ulteriori informazioni sull'utilizzo dei filtri, vedere Filtraggio dei dati pubblicati per la replica di tipo merge.
  • Utilizzare partizioni pre-calcolate con filtri con parametri (funzionalità utilizzata per impostazione predefinita). Per ulteriori informazioni, vedere Ottimizzazione delle prestazioni dei filtri con parametri con le partizioni pre-calcolate.
    Le partizioni pre-calcolate impongono vari limiti al funzionamento dei filtri. Se l'applicazione non è in grado di rispettare tali limiti, impostare l'opzione keep_partition_changes su True. Ciò consente di migliorare le prestazioni. Per ulteriori informazioni, vedere Filtri di riga con parametri.
  • Utilizzare partizioni non sovrapposte se i dati vengono filtrati ma non condivisi tra gli utenti.
    La replica consente di ottimizzare le prestazioni dei dati che non vengono condivisi tra partizioni o sottoscrizioni. Per ulteriori informazioni, vedere Filtri di riga con parametri.
  • Evitare di creare gerarchie di filtri join complesse.
    I filtri join composti da più di cinque tabelle possono avere un impatto decisivo sulle prestazioni durante l'elaborazione di tipo merge. Se è necessario generare filtri join per cinque o più tabelle, è consigliabile optare per altre soluzioni:
    • Evitare di filtrare le tabelle che fungono principalmente da tabelle di ricerca, le tabelle di dimensioni ridotte e le tabelle non soggette a modifica, che è preferibile inserire nella pubblicazione senza ricorrere ad alcun filtro. È consigliabile utilizzare filtri join solo tra tabelle che devono essere partizionate tra i Sottoscrittori. Per ulteriori informazioni, vedere Filtri join.
    • Considerare la denormalizzazione della progettazione del database o l'utilizzo di una tabella di mapping qualora in un join siano presenti molte tabelle. Ad esempio, se un venditore necessita solo dei dati relativi ai propri clienti e per associare un cliente a un determinato venditore sono necessari sei join, considerare l'opportunità di aggiungere alla tabella dei clienti una colonna che identifica il venditore. I dati del venditore sono ridondanti, ma i costi della denormalizzazione delle tabelle vengono compensati in una certa misura dai vantaggi a livello delle prestazioni per la partizione della replica.
    • Per migliorare le prestazioni delle partizioni pre-calcolate quando i batch contengono molte modifiche ai dati, progettare l'applicazione con attenzione. Assicurare che le modifiche ai dati nella tabella padre in un filtro join vengano apportate prima delle corrispondenti modifiche nelle tabelle figlio.
  • Impostare l'opzione join_unique_key su 1 se la logica lo consente.
    Impostando questo parametro su 1, la relazione tra le tabelle figlio e le tabelle padre in un filtro join sarà di tipo uno-a-uno o uno-a-molti. Impostare questo parametro su 1 solo se esiste un vincolo nella colonna di join della tabella figlio che garantisce l'univocità. Un'impostazione non corretta del parametro su 1 può impedire la convergenza dei dati. Per ulteriori informazioni, vedere Filtri join.
  • Non eseguire batch con molte modifiche se si utilizzano partizioni pre-calcolate.
    Se l'agente di merge viene eseguito dopo un batch che contiene molte modifiche ai dati, tenterà di suddividere il batch di grandi dimensioni in batch minori. Nel frattempo altri processi dell'agente di merge potrebbero risultare bloccati. Provare a ridurre il numero di modifiche contenute in un batch e ad eseguire l'agente di merge tra i batch. Se non è possibile, aumentare il valore di generation_leveling_threshold per la pubblicazione.

Considerazioni sulle sottoscrizioni

Parametri dell'agente di merge

  • Aggiornare tutti i Sottoscrittori per le sottoscrizioni pull a SQL Server 2005.
    Se si aggiorna un Sottoscrittore a SQL Server 2005, viene aggiornato anche l'agente di merge utilizzato dalle sottoscrizioni in quel Sottoscrittore. Per poter utilizzare molte delle nuove funzionalità e ottimizzazioni delle prestazioni, è necessario l'Agente di merge di SQL Server 2005.
  • Se la sincronizzazione di una sottoscrizione avviene tramite una connessione veloce e le modifiche vengono inviate dal server di pubblicazione e dal Sottoscrittore, utilizzare il parametro –ParallelUploadDownload per l'agente di merge.
    In SQL Server 2005 è disponibile un nuovo parametro dell'agente di merge, ovvero –ParallelUploadDownload. L'impostazione di questo parametro consente di elaborare in parallelo le modifiche caricate nel server di pubblicazione e le modifiche scaricate nel Sottoscrittore. Ciò è utile negli ambienti caratterizzati da volumi di traffico elevati con un'ampia larghezza di banda di rete. I parametri degli agenti possono essere specificati nei profili agente e dalla riga di comando. Per ulteriori informazioni, vedere:
  • Quando si sincronizzano righe di dati con un'ingente quantità di dati, ad esempio righe con colonne LOB, la sincronizzazione tramite il Web può richiedere l'allocazione di memoria aggiuntiva e ridurre le prestazioni. Ciò si verifica quando l'agente di merge genera un messaggio XML contenente un numero troppo elevato di righe di dati con ingenti quantità di dati. Se l'agente di merge utilizza una quantità eccessiva di risorse durante la sincronizzazione tramite il Web, ridurre il numero di righe inviate in un singolo messaggio in uno dei modi seguenti:
    • Utilizzare il profilo agente a collegamento lento per l'agente di merge. Per ulteriori informazioni, vedere Profili degli agenti di replica.
    • Ridurre i parametri -DownloadGenerationsPerBatch e -UploadGenerationsPerBatch per l'agente di merge a un valore uguale o inferiore a 10. Il valore predefinito di questi parametri è 50.

Considerazioni sugli snapshot

  • Creare una colonna ROWGUIDCOL nelle tabelle di grandi dimensioni prima di generare lo snapshot iniziale.
    La replica di tipo merge richiede che ogni tabella pubblicata includa una colonna ROWGUIDCOL. Se la colonna ROWGUIDCOL non è disponibile quando l'agente snapshot crea i file di snapshot iniziali, l'agente dovrà innanzitutto aggiungere e popolare la colonna ROWGUIDCOL. Per migliorare le prestazioni delle operazioni di generazione di snapshot durante la replica di tipo merge, creare la colonna ROWGUIDCOL in tutte le tabelle prima della pubblicazione. Anche se, per impostazione predefinita, l'agente snapshot utilizza il nome rowguid, a tale colonna può essere assegnato qualsiasi nome che includa le caratteristiche seguenti relative al tipo di dati:
    • Un tipo di dati UNIQUEIDENTIFIER.
    • Un valore predefinito di tipo NEWSEQUENTIALID() o NEWID(). Per garantire un migliore livello di prestazioni durante l'inserimento e il rilevamento di modifiche, è consigliabile utilizzare NEWSEQUENTIALID().
    • Il set di proprietà ROWGUIDCOL.
    • Un indice univoco nella colonna.
  • Creare snapshot preliminari e/o consentire ai Sottoscrittori di richiedere la generazione e l'applicazione di snapshot alla prima sincronizzazione.
    Utilizzare una o entrambe le opzioni per generare snapshot per le pubblicazioni che utilizzando filtri con parametri. Se non si specifica alcuna opzione, le sottoscrizioni vengono inizializzate tramite una serie di istruzioni SELECT e INSERT, anziché tramite l'utilità bcp. Questo processo risulta decisamente più lento. Per ulteriori informazioni, vedere Snapshot per pubblicazioni di tipo merge con filtri con parametri.

Considerazioni sulla manutenzione e sul monitoraggio

  • Eseguire occasionalmente la reindicizzazione delle tabelle di sistema per la replica di tipo merge.
    Nell'ambito delle operazioni di manutenzione ai fini della replica di tipo merge, è necessario verificare occasionalmente l'aumento delle tabelle di sistema associate a questo tipo di replica, ovvero MSmerge_contents, MSmerge_genhistory, MSmerge_tombstone, MSmerge_current_partition_mappings e MSmerge_past_partition_mappings. Eseguire periodicamente la reindicizzazione di queste tabelle. Per ulteriori informazioni, vedere Riorganizzazione e ricostruzione degli indici.
  • Monitorare le prestazioni della sincronizzazione utilizzando la scheda Cronologia sincronizzazione in Monitoraggio replica.
    Per la replica di tipo merge in Monitoraggio replica nella scheda Cronologia sincronizzazione vengono visualizzate statistiche dettagliate di ogni articolo elaborato durante la sincronizzazione, inclusa la quantità di tempo impiegato in ogni fase di elaborazione (caricamento delle modifiche, download delle modifiche e così via). Ciò può essere utile per individuare tabelle specifiche che determinano rallentamenti ed è l'opzione migliore per risolvere problemi relativi alle prestazioni delle sottoscrizioni di tipo merge. Per ulteriori informazioni sulla visualizzazione delle statistiche dettagliate, vedere Procedura: Visualizzazione delle informazioni ed esecuzione delle attività degli agenti associati a una sottoscrizione (Monitoraggio replica).

Vedere anche

Concetti

Miglioramento delle prestazioni della replica

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche

Versione Cronologia

12 dicembre 2006
Nuovo contenuto:
  • Aggiunta di indicazioni per le prestazioni in caso di esecuzione di batch di grandi dimensioni con partizioni pre-calcolate.

17 luglio 2006
Nuovo contenuto:
  • Aggiunta di indicazioni relative alle prestazioni per la sincronizzazione dei dati LOB mediante la sincronizzazione tramite il Web.