Considerazioni su tutti i tipi di replica
In questa sezione della documentazione sono incluse aree che è consigliabile valutare prima di implementare la replica, ad esempio le colonne Identity, i vincoli e i tipi di dati. In questo argomento vengono trattate aree che influenzano tutti i tipi di replica, mentre negli argomenti seguenti vengono fornite ulteriori informazioni:
Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION
Utilizzo di più versioni di SQL Server in una topologia di replica
Oltre a tali argomenti, nell'argomento relativo a ogni funzionalità di replica vengono illustrate le considerazioni necessarie per l'implementazione della funzionalità specifica.
SQL Server Agent
La replica utilizza programmi autonomi, denominati agenti, per eseguire le attività associate al rilevamento delle modifiche e alla distribuzione dei dati. Per impostazione predefinita, gli agenti di replica vengono eseguiti come processi pianificati in SQL Server Agent. Affinché i processi vengano eseguiti, è necessario che SQL Server Agent sia in esecuzione. Per impostazione predefinita, il servizio SQL Server Agent è disattivato durante l'installazione di SQL Server a meno che non si scelga in modo esplicito di avviarlo automaticamente durante l'installazione. Per ulteriori informazioni sull'avvio del servizio SQL Server Agent, vedere Avvio di SQL Server Agent.
Considerazioni relative alla protezione
È importante comprendere come rendere sicuro un ambiente di replica per proteggere i dati e la logica di business presenti nell'applicazione. La protezione dell'ambiente di replica consiste essenzialmente nella comprensione delle opzioni di autenticazione e autorizzazione, dell'utilizzo corretto delle funzionalità di filtro della replica e delle misure specifiche per la protezione di ogni componente dell'ambiente di replica, tra cui il server di distribuzione, il server di pubblicazione, i Sottoscrittori e la cartella snapshot. Per ulteriori informazioni, vedere Sicurezza e protezione (replica).
Considerazioni sull'amministrazione
Dopo avere configurato la replica, è importante comprendere come amministrare una topologia di replica. Per informazioni sulle procedure consigliate per l'amministrazione della replica, vedere Procedure consigliate per l'amministrazione della replica. In questo argomento sono incluse le procedure consigliate relative ad alcune aree specifiche, con collegamenti a ulteriori informazioni per ogni area. Oltre a seguire tali procedure consigliate, valutare la lettura dell'argomento relativo alle domande frequenti per acquisire familiarità con le domande e i problemi più comuni: Domande frequenti per gli amministratori di replica.
Considerazioni relative alla rete e alle prestazioni
È disponibile un certo numero di procedure consigliate correlate alle prestazioni per le aree 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
Per ulteriori informazioni, vedere Prestazioni (replica).
Se la replica viene eseguita utilizzando una connessione lenta, è possibile personalizzare i profili degli agenti interessati dalla replica. Le opzioni di configurazione variano in base all'agente specifico di cui si sta personalizzando il profilo. Per ulteriori informazioni, vedere Profili degli agenti di replica e Problemi causati da una rete lenta.
La velocità della rete spesso rappresenta un fattore determinante ai fini dell'applicazione dello snapshot iniziale. Il numero di modifiche incrementali potrebbe essere basso, mentre il volume dei dati distribuiti inizialmente potrebbe risultare elevato. Le soluzioni possibili sono le seguenti:
Trasferire lo snapshot utilizzando un CD o un dispositivo nastro. Per ulteriori informazioni, vedere Posizioni alternative della cartella snapshot e Snapshot compressi.
Inizializzare le sottoscrizioni senza uno snapshot. Per ulteriori informazioni, vedere Inizializzazione di una sottoscrizione transazionale senza uno snapshot e Inizializzazione di una sottoscrizione di tipo merge senza snapshot.
Impostazione dei nomi dei server nelle topologie di replica
Quando si specificano i nomi delle istanze dei server che partecipano alla replica, è necessario indicare il nome nel formato del nome dell'istanza del server registrata di SQL Server. È ad esempio necessario utilizzare il nome dell'istanza di SQL Server quando si specificano i parametri del server di pubblicazione o del Sottoscrittore nelle stored procedure della replica o le impostazioni per la connessione dell'agente di replica nella riga di comando. Se il nome della rete per l'istanza di SQL Server è diverso dal nome dell'istanza registrata, gli agenti non saranno in grado di stabilire le connessioni di replica. Se il nome di rete dell'istanza e il nome dell'istanza di SQL Server sono diversi, valutare l'opportunità di aggiungere il nome dell'istanza di SQL Server come nome di rete valido. Uno dei metodi disponibili per impostare un nome di rete alternativo consiste nell'aggiungerlo al file hosts locale. Il file hosts locale è disponibile per impostazione predefinita nella cartella WINDOWS\system32\drivers\etc o WINNT\system32\drivers\etc. Per ulteriori informazioni, vedere la documentazione di Windows.
Ad esempio, se il nome del computer è comp1, l'indirizzo IP del computer è 10.193.17.129 e il nome dell'istanza è inst1/instname, aggiungere la voce seguente al file hosts:
10.193.17.129 inst1
Integrità dei dati
Per le topologie che consentono gli aggiornamenti nei Sottoscrittori, è necessario verificare che venga mantenuta l'integrità dell'applicazione in ogni Sottoscrittore. È necessario che tutti i controlli utilizzati per convalidare le modifiche apportate ai dati nel server di pubblicazione, ad esempio i vincoli, siano presenti nel Sottoscrittore o vengano gestiti nell'applicazione. Per informazioni sugli agenti di replica e i vincoli nel Sottoscrittore, vedere Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION.
Conflitti di dati
Per le topologie che consentono gli aggiornamenti nei Sottoscrittori, è necessario progettare l'applicazione riducendo al minimo i conflitti. Se nei Sottoscrittori è richiesta la lettura e non l'aggiornamento dei dati, non si verificherà alcun conflitto. Grazie al partizionamento logico dei dati in base alle sedi geografiche o agli usi aziendali è possibile evitare che gli stessi valori di dati vengano aggiornati da più utenti e, pertanto, evitare i conflitti. Per ulteriori informazioni sul partizionamento dei dati, vedere Applicazione di filtri ai dati pubblicati.
Tipi di dati LOB (Large OBject)
I tipi di dati text, ntext e image sono obsoleti. È consigliabile utilizzare rispettivamente i tipi di dati varchar(max), nvarchar(max), varbinary(max). Se si utilizzano i tipi di dati text, ntext e image e si desiderano ulteriori informazioni, vedere la sezione relativa ai tipi di dati LOB (Large OBject) negli argomenti seguenti Considerazioni sulla replica transazionale e Considerazioni per la replica di tipo merge.
Gli snapshot in modalità carattere vengono utilizzati dai server di pubblicazione non SQL Server, dai Sottoscrittori non SQL Server e dai Sottoscrittori in cui è in esecuzione MicrosoftSQL Server Compact 3.5 SP1. Se si utilizza uno snapshot in modalità carattere, i tipi LOB vengono convertiti nel formato Unicode, con un conseguente aumento della dimensione dei dati LOB presenti nel file snapshot pari a quattro volte la dimensione degli stessi dati nel database di pubblicazione. Quando i dati vengono copiati nel database di sottoscrizione, vengono nuovamente convertiti e risultano avere la stessa dimensione dei dati nel database di pubblicazione.
Mapping dei tipi di dati
Se una topologia di replica include versioni precedenti di SQL Server, SQL Server Compact 3.5 SP1, server di pubblicazione non SQL Server oppure di Sottoscrittori non SQL Server, verrà eseguito il mapping dei tipi di dati tra i database. Per un elenco di mapping dei tipi di dati, vedere:
Colonne Identity
Per utilizzare le colonne Identity in una topologia di replica che include aggiornamenti in più nodi, è necessario che ogni nodo nella topologia utilizzi un intervallo diverso di valori Identity, in modo che non vi siano duplicati. La replica gestisce le colonne Identity attraverso tutti i tipi di pubblicazioni e di sottoscrizioni, consentendo di gestire le colonne manualmente o automaticamente tramite la replica stessa. Per ulteriori informazioni, vedere Replica di colonne Identity.
Colonne calcolate
Tramite la replica viene copiata nel Sottoscrittore solo la definizione delle colonne calcolate. Il valore per ogni riga nel Sottoscrittore dipende dai dati disponibili nel Sottoscrittore e dall'utilizzo o meno delle funzioni non deterministiche per il calcolo della colonna. Se i dati disponibili nel server di pubblicazione e nel Sottoscrittore sono identici in un momento specifico e il calcolo utilizza solo funzioni deterministiche, i valori calcolati per una riga saranno identici. Se i dati sono diversi o il calcolo utilizza una o più funzioni non deterministiche, i valori nel server di pubblicazione e nel Sottoscrittore potrebbero differire. Per ulteriori informazioni sul determinismo delle funzioni, vedere Funzioni deterministiche e non deterministiche.