Condividi tramite

  • Articolo

Procedure consigliate per l'amministrazione della replica

Dopo aver configurato la replica, è importante comprendere in che modo amministrare una topologia di replica. In questo argomento sono contenute procedure consigliate di base relative a diverse aree, con collegamenti ad altre informazioni per ogni area. Oltre ad attenersi a tali procedure, provare a familiarizzare con domande e problemi comuni leggendo l'argomento Domande frequenti per gli amministratori di replica.

È preferibile suddividere le procedure consigliate in due aree:

  • Nelle informazioni seguenti sono descritte le procedure consigliate da implementare per tutte le topologie di replica:

    • Sviluppare e testare una strategia di backup e ripristino.

    • Creare lo script della topologia di replica.

    • Creare soglie e avvisi.

    • Monitorare la topologia di replica.

    • Stabilire dati di riferimento per le prestazioni e regolare la replica, se necessario.

  • Negli argomenti seguenti sono riportate le procedure consigliate che è opportuno prendere in considerazione, sebbene potrebbero non essere richieste per la topologia in uso:

    • Convalidare i dati periodicamente.

    • Regolare i parametri dell'agente mediante i profili.

    • Regolare i periodi di memorizzazione della pubblicazione e della distribuzione.

    • Comprendere in che modo modificare le proprietà degli articoli e della pubblicazione se i requisiti dell'applicazione cambiano.

    • Comprendere in che modo apportare modifiche allo schema se i requisiti dell'applicazione cambiano.

Sviluppare e testare una strategia di backup e ripristino.

È consigliabile eseguire regolarmente il backup di tutti i database nonché testare periodicamente la capacità di ripristino di tali backup. Le stesse procedure sono consigliate anche per i database replicati. Di seguito sono elencati i database da sottoporre a backup regolarmente:

  • Database di pubblicazione

  • Database di distribuzione

  • Database di sottoscrizione

  • Database msdb e master nel server di pubblicazione, nel server di distribuzione e in tutti i Sottoscrittori

Il backup e il ripristino dei dati dei database replicati richiedono un'attenzione particolare. Per ulteriori informazioni, vedere Backup e ripristino dei database replicati.

Creare lo script della topologia di replica

Tutti i componenti di replica in una topologia devono essere inseriti in uno script come parte di un piano di ripristino di emergenza. Tali script possono inoltre essere utilizzati per automatizzare le attività ripetitive. Essi contengono le stored procedure di sistema Transact-SQL necessarie per implementare i componenti di replica inseriti in uno script, ad esempio una pubblicazione o una sottoscrizione, e possono essere creati mediante una procedura guidata, quale Creazione guidata nuova pubblicazione, o in Microsoft SQL Server Management Studio dopo aver creato un componente. È possibile visualizzare, modificare ed eseguire lo script utilizzando SQL Server Management Studio o sqlcmd. Gli script possono essere memorizzati con file di backup da utilizzare nel caso in cui sia necessario riconfigurare una topologia di replica. Per ulteriori informazioni, vedere Procedura: Creazione di script per gli oggetti di replica (SQL Server Management Studio).

In caso di modifiche a una proprietà, è necessario riscrivere lo script di un componente. Se si utilizzano stored procedure personalizzate con la replica transazionale, è necessario memorizzare una copia di ogni stored procedure con gli script. Tale copia deve essere aggiornata in caso di modifica della stored procedure (generalmente aggiornate in seguito a modifiche dello schema o dei requisiti dell'applicazione). Per ulteriori informazioni sulle procedure personalizzate, vedere Impostazione della modalità di propagazione delle modifiche per gli articoli transazionali.

Stabilire dati di riferimento per le prestazioni e regolare la replica, se necessario

Prima di configurare la replica, è consigliabile acquisire familiarità con i fattori che influiscono sulle relative prestazioni:

  • 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

Per ulteriori informazioni sul modo in cui questi fattori influiscono su ogni tipo di replica, vedere:

Dopo aver configurato la replica, è consigliabile sviluppare dati di riferimento per le prestazioni in modo da poter stabilire il comportamento della replica in presenza del carico di lavoro tipico delle applicazioni e della topologia in uso. Utilizzare Monitoraggio replica e Monitor di sistema per stabilire i valori tipici per le cinque dimensioni seguenti delle prestazioni della replica:

  • Latenza: la quantità di tempo impiegato per la propagazione di una modifica dei dati tra i nodi di una topologia di replica.

  • Velocità effettiva: la quantità di attività di replica (misurata in comandi recapitati in un intervallo di tempo) che un sistema è in grado di sostenere nel tempo.

  • Concorrenza: il numero di processi di replica che è possibile eseguire contemporaneamente in un sistema.

  • Durata della sincronizzazione: il tempo necessario per il completamento di una determinata sincronizzazione.

  • Consumo di risorse: le risorse hardware e di rete utilizzate per l'elaborazione della replica.

La latenza e la velocità effettiva sono più rilevanti per la replica transazionale in quanto i sistemi che si basano su questo tipo di replica in genere richiedono una bassa latenza e un'elevata velocità effettiva. La concorrenza e la durata della sincronizzazione sono più rilevanti per la replica di tipo merge in quanto i sistemi che si basano su questo tipo di replica sono spesso caratterizzati da un numero elevato di Sottoscrittori e un server di pubblicazione può stabilire un numero significativo di sincronizzazioni simultanee con tali Sottoscrittori.

Dopo aver stabilito i numeri di riferimento, impostare le soglie in Monitoraggio replica. Per ulteriori informazioni, vedere Impostazione di valori di soglia e avvisi in Monitoraggio replica e Utilizzo degli avvisi per gli eventi dell'agente di replica. In caso di problemi di prestazioni, è consigliabile leggere i suggerimenti riportati negli argomenti relativi al miglioramento delle prestazioni elencati sopra e apportare modifiche nelle aree che hanno determinato tali problemi.

Creare soglie e avvisi

Monitoraggio replica consente di impostare diverse soglie relative allo stato e alle prestazioni. È consigliabile impostare soglie appropriate per la topologia. Se si raggiunge una soglia, viene visualizzato un messaggio e, facoltativamente, è possibile inviare un avviso a un account di posta elettronica, un cercapersone o un altro dispositivo. Per ulteriori informazioni, vedere Impostazione di valori di soglia e avvisi in Monitoraggio replica.

Oltre agli avvisi che possono essere associati alle soglie di monitoraggio, la replica offre diversi avvisi predefiniti che rispondono alle azioni dell'agente di replica. Tali avvisi possono essere utilizzati da un amministratore per rimanere aggiornato sullo stato della topologia di replica. È consigliabile leggere l'argomento in cui sono descritti gli avvisi e utilizzare quelli che soddisfano le proprie esigenze amministrative. Se necessario, è inoltre possibile creare avvisi aggiuntivi. Per ulteriori informazioni, vedere Utilizzo degli avvisi per gli eventi dell'agente di replica.

Monitorare la topologia di replica

Dopo aver impostato la topologia di replica e aver configurato soglie e avvisi, è consigliabile monitorare regolarmente la replica. Il monitoraggio di una topologia di replica rappresenta un aspetto essenziale della distribuzione di una replica. Poiché l'attività di replica viene distribuita, è essenziale tenere traccia dell'attività e dello stato di tutti i computer coinvolti in questo processo. Per monitorare la replica è possibile utilizzare gli strumenti seguenti:

Convalidare i dati periodicamente

La procedura di convalida non è richiesta per la replica, ma è consigliabile eseguirla periodicamente per quella transazionale e di tipo merge. Tale procedura consente di verificare che i dati nel Sottoscrittore corrispondano ai dati nel server di pubblicazione. Una convalida riuscita indica che in quel particolare momento tutte le modifiche del server di pubblicazione sono state replicate nel Sottoscrittore (e dal Sottoscrittore nel server di pubblicazione se il Sottoscrittore supporta gli aggiornamenti) e che i due database sono sincronizzati.

È consigliabile eseguire la convalida in base alla pianificazione del backup del database di pubblicazione. Se, ad esempio, per il database di pubblicazione è stato impostato un backup completo ogni settimana, è possibile eseguire una convalida ogni settimana al termine del backup. Per ulteriori informazioni, vedere Convalida dei dati replicati.

Utilizzare i profili agenti per modificare i parametri dell'agente, se necessario

I profili agenti consentono di impostare facilmente i parametri dell'agente di replica. È inoltre possibile specificare tali parametri dalla riga di comando dell'agente, sebbene sia generalmente più corretto utilizzare un profilo agente predefinito oppure creare un nuovo profilo se è necessario modificare il valore di un parametro. Se, ad esempio, si utilizza la replica di tipo merge e un Sottoscrittore passa da una connessione a banda larga a una connessione remota, provare a utilizzare il profilo a collegamento lento per l'agente di merge. Tale profilo utilizza un insieme di parametri che sono più adatti per il collegamento di comunicazione più lento. Per ulteriori informazioni, vedere Profili degli agenti di replica.

Regolare i periodi di memorizzazione della pubblicazione e della distribuzione

La replica transazionale e la replica di tipo merge utilizzano periodi di memorizzazione per stabilire, rispettivamente, l'intervallo di tempo durante il quale le transazioni vengono memorizzate nel database di distribuzione e la frequenza con cui è necessario sincronizzare una sottoscrizione. Inizialmente è consigliabile utilizzare le impostazioni predefinite, monitorando la topologia per stabilire se è necessario modificarle. Nel caso ad esempio della replica di tipo merge, il periodo di memorizzazione della pubblicazione (pari a 14 giorni per impostazione predefinita) determina l'intervallo di tempo durante il quale i metadati vengono memorizzati in tabelle di sistema. Se le sottoscrizioni vengono sincronizzate entro cinque giorni, provare a regolare l'impostazione su un numero inferiore, in modo da ridurre i metadati ed eventualmente ottenere prestazioni migliori. Per ulteriori informazioni, vedere Scadenza e disattivazione delle sottoscrizioni.

Comprendere in che modo modificare le pubblicazioni se i requisiti dell'applicazione cambiano

Dopo aver creato una pubblicazione, potrebbe essere necessario aggiungere o eliminare articoli oppure modificare le proprietà di articoli e pubblicazione. Al termine della creazione di una pubblicazione è possibile apportare la maggior parte delle modifiche, ma in alcuni casi è necessario generare un nuovo snapshot per una pubblicazione e/o reinizializzare le sottoscrizioni della pubblicazione. Per ulteriori informazioni, vedere Modifica delle proprietà di pubblicazioni e articoli e Aggiunta ed eliminazione di articoli a e da pubblicazioni esistenti.

Comprendere in che modo apportare modifiche allo schema se i requisiti dell'applicazione cambiano

In molti casi le modifiche apportate allo schema sono richieste quando un'applicazione viene messa in produzione. In una topologia di replica tali modifiche devono spesso essere propagate a tutti i Sottoscrittori. La replica supporta un'ampia gamma di modifiche di schema per gli oggetti pubblicati. Quando si apporta una delle modifiche di schema seguenti nell'oggetto pubblicato appropriato in un server di pubblicazione Microsoft SQL Server, tale modifica viene propagata per impostazione predefinita a tutti i Sottoscrittori SQL Server:

  • ALTER TABLE

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

Per ulteriori informazioni, vedere Modifiche allo schema nei database di pubblicazione.

Vedere anche

Altre risorse

Amministrazione (replica)