Nel sistema si è verificato un problema di prestazioni
Data aggiornamento: 12 dicembre 2006
Le prestazioni di replica possono essere misurate secondo le cinque dimensioni seguenti:
- Latenza: quantità di tempo necessaria per la propagazione di una modifica dei dati tra i nodi in una topologia di replica.
- Velocità effettiva: quantità di attività di replica, espressa in comandi recapitati in un periodo di tempo specifico, che un sistema è in grado di sostenere nel tempo.
- Concorrenza: numero di processi di replica che possono essere eseguiti simultaneamente in un sistema.
- Durata della sincronizzazione: tempo necessario per il completamento di una sincronizzazione specifica.
- Utilizzo delle risorse: risorse hardware e di rete utilizzate per l'elaborazione della replica.
La latenza e la velocità effettiva interessano in particolare la replica transazionale, in quanto i sistemi basati su questo tipo di replica richiedono in genere una bassa latenza e una velocità effettiva elevata. La concorrenza e la durata della sincronizzazione interessano in particolare la replica di tipo merge, in quanto i sistemi basati su questo tipo di replica includono in genere un numero elevato di Sottoscrittori e un server di pubblicazione può eseguire una quantità significativa di sincronizzazioni simultanee con tali Sottoscrittori.
Dopo avere configurato la replica, è consigliabile sviluppare un riferimento per le prestazioni, che consenta di determinare il comportamento della replica con un carico di lavoro tipico per le applicazioni e la topologia in uso. Utilizzare Monitoraggio replica e Monitor di sistema per determinare i valori tipici delle cinque dimensioni delle prestazioni elencate in precedenza. Dopo avere definito i valori di riferimento, impostare soglie e avvisi in Monitoraggio replica. Per ulteriori informazioni, vedere Monitoraggio delle prestazioni con Monitoraggio replica, Impostazione di valori di soglia e avvisi in Monitoraggio replica e Utilizzo degli avvisi per gli eventi dell'agente di replica. Per ulteriori informazioni sugli strumenti che possono essere utilizzati per risolvere i problemi relativi alla replica, vedere Strumenti di risoluzione dei problemi relativi alla replica.
Spiegazione e azione dell'utente
Le prestazioni di replica sono interessate dai fattori seguenti:
- Hardware del server e della rete
- Progettazione del database
- Configurazione del server di distribuzione
- Progettazione e opzioni della pubblicazione
- Progettazione e utilizzo dei filtri
- Opzioni di sottoscrizione
- Opzioni per gli snapshot
- Parametri degli agenti
- Manutenzione
Se viene rilevato un problema di prestazioni, è consigliabile esaminare i suggerimenti indicati nelle sezioni seguenti e applicare le modifiche nelle aree che influiscono sui problemi riscontrati. Ad esempio:
- Se si utilizza una replica di tipo merge e in Monitoraggio replica si nota che a un singolo articolo filtrato è assegnata una percentuale elevata di tempo di sincronizzazione, assicurarsi di utilizzare le opzioni di filtro appropriate e che le colonne nel filtro siano indicizzate.
- Se si utilizza la replica transazionale e si riscontra un'elevata latenza durante l'esecuzione di operazioni batch sulle tabelle pubblicate, valutare l'opportunità di replicare l'esecuzione di una stored procedure per effettuare l'operazione batch nel Sottoscrittore.
Tutti i tipi di replica
Per tutti i tipi di replica è consigliabile valutare le aree indicate di seguito. Per ulteriori informazioni, vedere Miglioramento delle prestazioni generali della replica.
- Server e rete
- Impostare la quantità minima e la quantità massima di memoria allocata a Microsoft Motore di database di SQL Server.
- Garantire la corretta allocazione dei file di dati del database e dei file di log. Utilizzare un'unità disco distinta per il log delle transazioni di tutti i database interessati dalla replica.
- Valutare l'opportunità di aggiungere memoria ai server utilizzati per la replica, in particolare al server di distribuzione.
- Utilizzare computer multiprocessore.
- Utilizzare una rete veloce. Se la rete è lenta, specificare le impostazioni di rete e i parametri degli agenti appropriati. Per ulteriori informazioni, vedere Problemi causati da una rete lenta.
- Progettazione del database
- Seguire le procedure consigliate per la progettazione del database.
- Valutare l'opportunità di impostare l'opzione di database READ_COMMITTED_SNAPSHOT.
- Prestare attenzione alla logica dell'applicazione nei trigger.
- Limitare l'utilizzo di tipi di dati LOB (Large Object).
- Progettazione e opzioni della pubblicazione
- Pubblicare solo i dati richiesti.
- Ridurre al minimo i conflitti tramite la progettazione della pubblicazione e il comportamento delle applicazioni.
- Utilizzare in modo razionale i filtri di riga.
- Ridurre i livelli di dettaglio degli agenti di replica eccetto durante le operazioni iniziali di verifica, monitoraggio o debug.
- Opzioni di sottoscrizione
- Utilizzare sottoscrizioni pull se il numero di Sottoscrittori è elevato.
- Valutare l'opportunità di reinizializzare la sottoscrizione se i Sottoscrittori subiscono ritardi elevati.
- Opzioni per gli snapshot
- Eseguire l'agente snapshot solo quando è necessario e non nei periodi di massima attività.
- Utilizzare una singola cartella snapshot per una pubblicazione.
- Installare la cartella snapshot in un'unità locale del server di distribuzione che non sia utilizzata per la memorizzazione di file di database o di log.
- Quando si crea il database di sottoscrizione nel Sottoscrittore, valutare l'opportunità di specificare un modello di recupero con registrazione minima o con registrazione minima delle transazioni di massa.
- Utilizzare la cartella snapshot alternativa e gli snapshot compressi in supporti rimovibili per le reti a larghezza di banda ridotta.
- Utilizzare il parametro –MaxBCPThreads dell'agente snapshot, dell'agente di merge e dell'agente di distribuzione. Utilizzare il parametro –UseInprocLoader dell'agente di distribuzione e dell'agente di merge.
Replica transazionale
Per la replica transazionale è consigliabile valutare le aree indicate di seguito. Per ulteriori informazioni, vedere Miglioramento delle prestazioni della replica transazionale.
- Progettazione del database
- Ridurre al minimo le dimensioni delle transazioni nella progettazione dell'applicazione.
- Configurazione del server di distribuzione
- Configurare il server di distribuzione in un server dedicato.
- Impostare una dimensione appropriata per il database di distribuzione.
- Progettazione e opzioni della pubblicazione
- Replicare l'esecuzione di stored procedure quando si effettuano aggiornamenti in batch nelle tabelle pubblicate.
- Distribuire gli articoli tra più pubblicazioni.
- Opzioni di sottoscrizione
- Utilizzare agenti indipendenti anziché agenti condivisi se sono disponibili più pubblicazioni nello stesso server di pubblicazione. Si tratta dell'impostazione predefinita in SQL Server 2005.
- Eseguire gli agenti in modo continuo anziché pianificarne l'esecuzione con frequenza elevata.
- Parametri degli agenti
- Utilizzare il parametro –MaxCmdsInTran per l'agente di lettura log.
- Utilizzare il parametro –SubcriptionStreams per l'agente di distribuzione.
- Aumentare il valore del parametro -ReadBatchSize per l'agente di lettura log.
- Aumentare il valore del parametro -CommitBatchSize per l'agente di distribuzione.
- Ridurre il valore del parametro -PollingInterval per l'agente di lettura log.
Replica di tipo merge
Per la replica di tipo merge è consigliabile valutare le aree indicate di seguito. Per ulteriori informazioni, vedere Miglioramento delle prestazioni della replica di tipo merge.
- Progettazione del database
- Indicizzare le colonne utilizzate nei filtri di riga e nei filtri join.
- Valutare l'opportunità di normalizzare in misura significativa le tabelle che includono i tipi di dati LOB (Large Object).
- Progettazione della pubblicazione
- Impostare il livello di compatibilità della pubblicazione su 90RTM (SQL Server 2005).
- Utilizzare impostazioni di memorizzazione della pubblicazione appropriate.
- Utilizzare articoli solo download nelle tabelle che vengono modificate solo nel server di pubblicazione.
- Progettazione e utilizzo dei filtri
- Limitare la complessità delle clausole di filtro di riga.
- Utilizzare partizioni pre-calcolate con filtri con parametri. Questa funzionalità è utilizzata per impostazione predefinita.
- Utilizzare partizioni non sovrapposte se i dati vengono filtrati, ma non condivisi tra gli utenti.
- Evitare di creare gerarchie di filtri join complesse.
- Impostare l'opzione join_unique_key su 1 se la logica lo consente.
- Considerazioni sulle partizioni pre-calcolate
- Quando i batch contengono molte modifiche ai dati, progettare l'applicazione con attenzione. È consigliabile che le modifiche ai dati nella tabella padre in un filtro join vengano apportate prima delle corrispondenti modifiche nelle tabelle figlio.
- Quando i batch contengono molte modifiche ai dati, ridurre il numero di modifiche in un batch ed eseguire l'agente di merge tra i batch. Se non è possibile, aumentare il valore di generation_leveling_threshold per la pubblicazione.
- Considerazioni sulla sottoscrizione
- Distribuire le pianificazioni della sincronizzazione per le sottoscrizioni.
- Parametri degli agenti
- Se una sottoscrizione viene sincronizzata tramite una connessione veloce e le modifiche vengono inviate dal server di pubblicazione al Sottoscrittore, utilizzare il parametro –ParallelUploadDownload per l'agente di merge.
- Opzioni per gli snapshot
- Creare una colonna ROWGUIDCOL in tabelle di grandi dimensioni prima di generare lo snapshot iniziale.
- Creare snapshot preliminari e/o consentire ai Sottoscrittori di richiedere la generazione e l'applicazione degli snapshot alla prima sincronizzazione.
- Manutenzione
- Eseguire occasionalmente la reindicizzazione delle tabelle di sistema per la replica di tipo merge.
- Monitorare le prestazioni di sincronizzazione utilizzando la scheda Cronologia sincronizzazione in Monitoraggio replica.
Vedere anche
Concetti
Risoluzione dei problemi relativi alla replica
Guida in linea e informazioni
Cronologia modifiche
| Versione | Cronologia |
|---|---|
12 dicembre 2006 |
|