Condividi tramite

  • Articolo

Miglioramento delle prestazioni generali della replica

È possibile migliorare le prestazioni generali di tutti i tipi di replica nell'applicazione e nella rete attenendosi alle istruzioni riportate in questo argomento.

Server e rete

  • Impostare la quantità minima e massima di memoria allocata a Microsoft Motore di database di SQL Server.

    Per impostazione predefinita, nel Motore di database i requisiti di memoria possono variare dinamicamente in base alle risorse di sistema disponibili. Per evitare che durante le attività di replica la memoria risulti insufficiente, impostare la quantità minima di memoria disponibile tramite l'opzione min server memory. Per evitare che il sistema operativo richieda memoria del disco, è inoltre possibile impostare una quantità massima di memoria mediante l'opzione max server memory. Per ulteriori informazioni, vedere Opzioni per la memoria server.

  • Verificare la corretta allocazione dei file di dati e dei file di log del database. Utilizzare un'unità disco distinta per il log delle transazioni di tutti i database interessati dalla replica.

    Per ridurre i tempi di scrittura delle transazioni, archiviare i file di log in un'unità disco diversa da quella in cui è archiviato il database. È possibile eseguire il mirroring dell'unità utilizzando la modalità 1 della tecnologia RAID (Redundant Array of Inexpensive Disks), se è necessario implementare la tolleranza di errore. Per gli altri file di database utilizzare RAID 0 o 0+1, a seconda delle esigenze specifiche di tolleranza di errore. Questo metodo è ottimale indipendentemente dal fatto che venga utilizzata o meno la replica. Per ulteriori informazioni, vedere Livelli RAID e SQL Server.

  • Considerare l'opportunità di aggiungere memoria ai server utilizzati per la replica, in particolare al server di distribuzione.

  • Utilizzare computer multiprocessore.

    Gli agenti di replica sono in grado di utilizzare processori aggiuntivi del server. In sistemi con utilizzo elevato della CPU è consigliabile installare una CPU più veloce o più CPU.

  • Utilizzare una rete veloce.

    La rete può rappresentare un significativo collo di bottiglia per le prestazioni, in particolare per la replica transazionale. È possibile migliorare notevolmente la propagazione delle modifiche nei Sottoscrittori utilizzando una rete veloce pari a 100 megabit al secondo (Mbps) o superiore. Se la rete è lenta, specificare impostazioni di rete e parametri di agente appropriati. Per ulteriori informazioni, vedere Problemi causati da una rete lenta.

Progettazione di database

  • Per la progettazione del database attenersi alle procedure consigliate.

    Un database replicato generalmente usufruisce delle stesse ottimizzazioni delle prestazioni di un database non replicato. È tuttavia consigliabile utilizzare gli indici con attenzione nel Sottoscrittore, tenendo presente che è necessario indicizzare la colonna chiave primaria nel Sottoscrittore, ma che ulteriori indici possono influire sulle prestazioni relative alle operazioni di inserimento, aggiornamento ed eliminazione. Per ulteriori informazioni sull'ottimizzazione dei database, vedere Ottimizzazione dei database.

  • Provare a impostare l'opzione del database READ_COMMITTED_SNAPSHOT.

    Per ridurre la contesa tra l'attività dell'utente e quella dell'agente di replica, impostare questa opzione per i database di pubblicazione e sottoscrizione:

    ALTER DATABASE AdventureWorks2008R2
SET READ_COMMITTED_SNAPSHOT ON

    Per ulteriori informazioni, vedere ALTER DATABASE (Transact-SQL).

  • Prestare attenzione alla logica dell'applicazione nei trigger.

    La logica di business nei trigger definiti dall'utente nel Sottoscrittore può rallentare la replica delle modifiche in quest'ultimo:

    Se si utilizzano trigger nel Sottoscrittore, vedere gli argomenti seguenti per ulteriori informazioni: Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION e Considerazioni sulla replica transazionale. Se si utilizzano trigger per mantenere l'integrità referenziale in tabelle pubblicate per la replica di tipo merge, specificare l'ordine di elaborazione delle tabelle in modo da ridurre il numero di tentativi necessari per l'agente di merge. Per ulteriori informazioni, vedere Impostazione dell'ordine di elaborazione degli articoli di merge.

  • Limitare l'utilizzo dei tipi di dati LOB (Large Object).

    Tali dati richiedono uno spazio di archiviazione e un'elaborazione maggiori rispetto ad altri tipi di dati di colonna. Non includere queste colonne negli articoli a meno che non sia necessario per l'applicazione in uso. I tipi di dati text, ntext e image sono deprecati. Se non si includono dati LOB, è consigliabile utilizzare i tipi di dati varchar(max), nvarchar(max) e varbinary(max), rispettivamente.

    Per la replica transazionale, provare a utilizzare il profilo dell'agente di distribuzione denominato Profilo di distribuzione per flussi OLEDB. Per ulteriori informazioni, vedere Profili degli agenti di replica.

Progettazione pubblicazione

  • Pubblicare solo i dati necessari.

    La semplicità di impostazione della replica favorisce la tendenza a pubblicare una quantità di dati maggiore di quella effettivamente necessaria con il conseguente utilizzo di risorse aggiuntive nei database di distribuzione e nei file di snapshot e la diminuzione della velocità effettiva dei dati richiesti. Evitare la pubblicazione di tabelle non necessarie e aggiornare le pubblicazioni con una frequenza minore.

  • Ridurre i conflitti mediante la progettazione della pubblicazione e il comportamento dell'applicazione.

    La modifica dei dati nei Sottoscrittori è consentita nella replica di tipo merge, nella replica transazionale con sottoscrizioni aggiornabili e nella replica transazionale peer-to-peer. La replica di tipo merge e la replica transazionale con sottoscrizioni aggiornabili supportano conflitti di dati se una determinata riga viene aggiornata in più nodi tra le sincronizzazioni. La replica peer-to-peer non supporta conflitti di dati e le modifiche dei dati devono essere partizionate. Indipendentemente dal tipo di replica utilizzato, è consigliabile partizionare le modifiche quando possibile, in modo da ridurre l'elaborazione richiesta per il rilevamento e la risoluzione dei conflitti.

    Le modifiche possono essere partizionate pubblicando subset di dati in ogni Sottoscrittore oppure facendo in modo che un'applicazione indirizzi le modifiche relative a una specifica riga a uno determinato nodo:

    • La replica di tipo merge supporta la pubblicazione dei subset di dati utilizzando filtri con parametri con una singola pubblicazione. Per ulteriori informazioni, vedere Filtri di riga con parametri.

    • La replica transazionale supporta la pubblicazione dei subset di dati utilizzando filtri statici con più pubblicazioni. Per ulteriori informazioni, vedere Applicazione di filtri ai dati pubblicati.

  • Utilizzare i filtri di riga in modo razionale.

    Quando una pubblicazione transazionale include uno o più articoli che utilizzano filtri di riga, l'agente di lettura log deve applicare il filtro a ogni riga interessata da un aggiornamento relativo alla tabella durante l'analisi del log delle transazioni. Questo, pertanto, influisce sulla velocità effettiva dell'agente di lettura log.

    Analogamente, la replica di tipo merge deve valutare le righe modificate o eliminate per stabilire quali Sottoscrittori devono riceverle. Se si utilizzano i filtri di riga per ridurre i dati richiesti da un Sottoscrittore, questo tipo di elaborazione risulta più complesso e lento rispetto alla pubblicazione di tutte le righe di una tabella. Tenere conto che i minori requisiti di archiviazione in ogni Sottoscrittore sono controbilanciati dalla necessità di ottimizzazione della velocità effettiva. Per ulteriori informazioni sul filtro, vedere Applicazione di filtri ai dati pubblicati.

Considerazioni sulla sottoscrizione

  • Utilizzare sottoscrizioni pull se il numero di Sottoscrittori è elevato.

    L'agente di distribuzione e l'agente di merge vengono eseguiti nel server di distribuzione per le sottoscrizioni push e nei Sottoscrittori per le sottoscrizioni pull. L'utilizzo delle sottoscrizioni pull può migliorare le prestazioni spostando l'elaborazione dell'agente dal server di distribuzione ai Sottoscrittori. Per ulteriori informazioni, vedere Sottoscrizione delle pubblicazioni.

  • Provare a reinizializzare la sottoscrizione in caso di forte ritardo dei Sottoscrittori.

    Se è necessario inviare ai Sottoscrittori quantità di modifiche elevate, può essere più conveniente reinizializzarle tutte con un nuovo snapshot anziché utilizzare la replica per spostare le singole modifiche. Per ulteriori informazioni, vedere Reinizializzazione di una sottoscrizione.

    Per la replica transazionale, nella scheda Comandi non distribuiti di Monitoraggio replica vengono visualizzate informazioni relative al numero di transazioni presenti nel database di distribuzione e non ancora distribuite in un Sottoscrittore e al tempo stimato per la relativa distribuzione. Per ulteriori informazioni, vedere Procedura: Visualizzazione delle informazioni ed esecuzione delle attività degli agenti associati a una sottoscrizione (Monitoraggio replica).

Considerazioni sugli snapshot

  • Eseguire l'agente snapshot solo quando è necessario e non nei periodi di massima attività.

    L'agente snapshot esegue la copia bulk dei dati provenienti dalla tabella pubblicata del server di pubblicazione in un file incluso nella cartella snapshot del server di distribuzione. Il processo di generazione di uno snapshot può richiedere un utilizzo elevato delle risorse e pertanto se ne sconsiglia la pianificazione nei periodi di massima attività.

  • Utilizzare uno snapshot in modalità nativa a meno che non sia richiesto uno snapshot in modalità carattere.

    Utilizzare lo snapshot predefinito in modalità nativa per tutti i Sottoscrittori tranne quelli non SQL Server e quelli che eseguono SQL Server Compact 3.5 SP2, i quali richiedono uno snapshot in modalità carattere.

  • Utilizzare un'unica cartella snapshot per pubblicazione.

    Quando si specificano le proprietà di una pubblicazione correlate alla posizione dello snapshot, è possibile scegliere di generare file di snapshot nella cartella snapshot predefinita e/o alternativa. Per generare file di snapshot in entrambe le posizioni è necessario spazio di archiviazione aggiuntivo e un'ulteriore elaborazione durante l'esecuzione dell'agente snapshot.

  • Installare la cartella snapshot in un'unità locale sul server di distribuzione non utilizzata per l'archiviazione di file di database o di log.

    L'agente snapshot esegue una scrittura sequenziale dei dati nella cartella snapshot. Installando la cartella snapshot in un'unità separata da quella in cui risiedono i file di database o di log è possibile ridurre la contesa tra i dischi e completare più rapidamente il processo di snapshot.

  • Quando si crea il database di sottoscrizione nel Sottoscrittore, provare a specificare un modello di recupero con registrazione minima o con registrazione minima delle operazioni bulk. Questo consente la registrazione minima degli inserimenti bulk eseguiti durante l'applicazione dello snapshot nel Sottoscrittore. Se necessario, dopo aver applicato lo snapshot al database di sottoscrizione, è possibile passare a un modello di recupero differente (con i database replicati è consentito l'utilizzo di uno qualsiasi dei modelli di recupero). Per ulteriori informazioni sulla selezione di un modello di recupero, vedere Panoramica del ripristino e del recupero (SQL Server).

  • Provare a utilizzare la cartella snapshot alternativa e gli snapshot compressi sui supporti rimovibili per le reti a larghezza di banda ridotta.

    La compressione dei file di snapshot nella cartella snapshot alternativa può ridurre i requisiti di archiviazione su disco degli snapshot e semplificare il trasferimento dei file di snapshot sui supporti rimovibili.

    In alcuni casi, gli snapshot compressi possono migliorare le prestazioni del trasferimento dei file di snapshot in rete. La compressione dello snapshot richiede, tuttavia, un'ulteriore elaborazione da parte dell'agente snapshot per la generazione dei file di snapshot e da parte dell'agente di distribuzione o dell'agente di merge per l'applicazione di tali file. Questo può rallentare il processo di generazione degli snapshot e, in alcuni casi, aumentare il tempo necessario per applicarli. Inoltre, poiché non è possibile riprendere gli snapshot compressi in caso di errore della rete, tali snapshot non sono adatti per le reti non affidabili. Quando si utilizzano snapshot compressi in una rete è necessario tenere conto di tutti i pro e i contro. Per ulteriori informazioni, vedere Posizioni alternative della cartella snapshot e Snapshot compressi.

  • Provare a inizializzare una sottoscrizione manualmente.

    In alcuni scenari, ad esempio quelli che comportano l'utilizzo di set di dati iniziali di grandi dimensioni, è preferibile inizializzare una sottoscrizione utilizzando un metodo diverso dallo snapshot. Per ulteriori informazioni, vedere Inizializzazione di una sottoscrizione transazionale senza uno snapshot e Inizializzazione di una sottoscrizione di tipo merge senza snapshot.

Parametri degli agenti

  • Ridurre i livelli di dettaglio degli agenti di replica eccetto durante le operazioni iniziali di verifica, monitoraggio o debug.

    Ridurre i parametri –HistoryVerboseLevel e –OutputVerboseLevel degli agenti di distribuzione o degli agenti di merge, per ridurre il numero di nuove righe inserite ai fini del rilevamento della cronologia e dell'output degli agenti. I messaggi precedenti sulla cronologia con lo stesso stato vengono invece aggiornati in base alle nuove informazioni relative alla cronologia. Aumentare i livelli di dettaglio ai fini della verifica, del monitoraggio e del debug in modo da ottenere il maggior numero possibile di informazioni sull'attività degli agenti.

  • Utilizzare il parametro –MaxBCPThreads dell'agente snapshot, dell'agente di merge e dell'agente di distribuzione (il numero di thread specificati non deve superare il numero di processori installati sul computer). Questo parametro specifica il numero di operazioni di copia bulk che è possibile eseguire in parallelo quando lo snapshot viene creato e applicato.

  • Utilizzare il parametro –UseInprocLoader dell'agente di distribuzione e dell'agente di merge, tenendo presente che non è possibile utilizzarlo se le tabelle pubblicate includono colonne XML. Grazie alla specifica di tale parametro, l'agente utilizzerà il comando BULK INSERT al momento dell'applicazione dello snapshot.

I parametri degli agenti possono essere specificati nei profili agente e dalla riga di comando. Per ulteriori informazioni, vedere:

Vedere anche

Concetti

Prestazioni (replica)