Domande frequenti per gli amministratori di replica

No. Durante la creazione di una pubblicazione l'attività sul database può proseguire. Tenere presente che la produzione di uno snapshot può impegnare una grande quantità di risorse, per questo conviene generare gli snapshot durante i periodi di minore attività sul database. Per impostazione predefinita, viene generato uno snapshot al termine della Creazione guidata nuova pubblicazione.

La durata dei blocchi dipende dal tipo di replica utilizzata:

• Per le pubblicazioni di tipo merge, l'agente snapshot non registra alcun blocco.

• Per le pubblicazioni transazionali, l'agente snapshot per impostazione predefinita registra i blocchi solo durante la fase iniziale della generazione dello snapshot.

• Per le pubblicazioni snapshot, l'agente snapshot registra i blocchi durante l'intero processo di generazione dello snapshot.

Dato tuttavia che il blocco impedisce l'aggiornamento delle tabelle da parte di altri utenti, è consigliabile pianificare l'esecuzione dell'agente snapshot durante gli orari di minore attività del database, specialmente per le pubblicazioni snapshot.

Una sottoscrizione è disponibile dopo che al database di sottoscrizione è stato applicato lo snapshot. Anche se il database di sottoscrizione è accessibile prima di questo momento, non dovrebbe essere utilizzato prima che sia stato applicato lo snapshot. Utilizzare Monitoraggio replica per verificare lo stato della generazione e dell'applicazione dello snapshot.

• Lo snapshot viene generato dall'agente snapshot. Visualizzare lo stato della generazione dello snapshot nella scheda Agenti per una pubblicazione in Monitoraggio replica. Per ulteriori informazioni, vedere Procedura: Visualizzazione delle informazioni ed esecuzione di attività relative agli agenti associati a una pubblicazione (Monitoraggio replica).

• Lo snapshot viene applicato dall'agente di distribuzione o dall'agente di merge. Visualizzare lo stato dell'applicazione dello snapshot nella pagina Agente di distribuzione o Agente di merge di Monitoraggio replica. Per ulteriori informazioni, vedere Procedura: Visualizzazione delle informazioni ed esecuzione delle attività degli agenti associati a una sottoscrizione (Monitoraggio replica).

L'esecuzione dell'agente di distribuzione o di merge in contemporanea con quella dell'agente shapshot non genera un errore. Tuttavia, è necessario considerare quanto segue:

• Se l'agente di distribuzione o di merge è configurato per essere eseguito in modo continuato, lo snapshot verrà applicato automaticamente al termine dell'esecuzione dell'agente snapshot.

• Se l'agente di distribuzione o di merge è configurato per essere eseguito in base a una pianificazione o su richiesta e quando viene eseguito non è disponibile alcuno snapshot, l'agente verrà chiuso e invierà un messaggio indicante che ancora non vi è uno snapshot disponibile. È necessario ripetere l'esecuzione dell'agente per applicare lo snapshot dopo l'esecuzione dell'agente snapshot. Per ulteriori informazioni sull'esecuzione degli agenti, vedere Procedura: Sincronizzazione di una sottoscrizione push (SQL Server Management Studio), Procedura: Sincronizzazione di una sottoscrizione pull (SQL Server Management Studio), e Concetti di base relativi ai file eseguibili dell'agente di replica.

Sì. La creazione dello script della configurazione di replica è un elemento fondamentale di qualunque piano di ripristino d'emergenza per una topologia di replica. Per ulteriori informazioni sulla creazione di script, vedere Creazione di script di replica.

Le funzioni di replica che utilizzano correttamente uno dei modelli di recupero: con registrazione minima, con registrazione minima delle operazioni bulk o con registrazione completa. La replica di tipo merge tiene traccia delle modifiche archiviando le informazioni in tabelle di metadati. La replica transazionale tiene traccia delle modifiche contrassegnando il log delle transazioni, ma il modello di recupero non influisce su questo processo di contrassegno.

Per tener traccia delle modifiche, la replica di tipo merge e la replica transazionale con sottoscrizioni ad aggiornamento in coda devono essere in grado di identificare in modo univoco ogni riga di ogni tabella pubblicata. A tale scopo:

• La replica di tipo merge aggiunge la colonna rowguid a ogni tabella, a meno che questa non contenga già una colonna del tipo di dati uniqueidentifier con il set di proprietà ROWGUIDCOL: in tal caso, viene usata questa colonna. Se la tabella viene rimossa dalla pubblicazione, la colonna rowguid viene eliminata; se per il rilevamento è stata utilizzata una colonna esistente, questa non viene eliminata.

• Se una pubblicazione transazionale supporta le sottoscrizioni ad aggiornamento in coda, la replica aggiunge la colonna msrepl_tran_version a ogni tabella. Se la tabella viene rimossa dalla pubblicazione, la colonna msrepl_tran_version non viene eliminata.

Riguardo ai vincoli sulle tabelle pubblicate, è necessario considerare diversi elementi:

• La replica transazionale richiede un vincolo di chiave primaria in ogni tabella pubblicata. La replica di tipo merge non richiede una chiave primaria ma se ne contiene una è necessario che venga replicata. La replica snapshot non richiede una chiave primaria.

• Per impostazione predefinita i vincoli di chiave primaria, gli indici e i vincoli CHECK vengono replicati nei Sottoscrittori.

• Per impostazione predefinita, l'opzione NOT FOR REPLICATION viene specificata per i vincoli di chiave esterna e per i vincoli CHECK; questi vincoli vengono imposti per le operazioni dell'utente ma non per quelle dell'agente. Per ulteriori informazioni, vedere Controllo di vincoli, identità e trigger con l'opzione NOT FOR REPLICATION.

Per ulteriori informazioni sull'impostazione delle opzioni dello schema che controllano l'esecuzione o meno della replica dei vincoli, vedere Procedura: Impostazione delle opzioni dello schema (SQL Server Management Studio) e Procedura: Impostazione delle opzioni dello schema (programmazione Transact-SQL della replica).

La replica offre la gestione automatica dell'intervallo di valori Identity per le topologie di replica che includono aggiornamenti nel Sottoscrittore. Per ulteriori informazioni, vedere Replica di colonne Identity.

Sì, ma con alcune restrizioni. Per ulteriori informazioni, vedere la sezione relativa alla pubblicazione di tabelle in più pubblicazioni nell'argomento Pubblicazione di dati e oggetti di database.

Sì. Non vi sono restrizioni al numero o ai tipi di pubblicazioni che possono utilizzare lo stesso database di distribuzione. Tutte le pubblicazioni di un dato server di pubblicazione devono utilizzare lo stesso server di distribuzione e database di distribuzione.

Se si dispone di più pubblicazioni, è possibile configurare più database di distribuzione nel server di distribuzione per garantire che il flusso di dati che attraversa ogni database di distribuzione provenga da una sola pubblicazione. Per aggiungere un database di distribuzione, utilizzare la finestra di dialogo Proprietà server di distribuzione oppure sp_adddistributiondb (Transact-SQL). Per ulteriori informazioni sull'accesso a questa finestra di dialogo, vedere Procedura: Visualizzazione e modifica delle proprietà del server di distribuzione (SQL Server Management Studio).

Queste informazioni sono disponibili tramite SQL Server Management Studio e diverse stored procedure di replica. Per informazioni, vedere Proprietà della replica e Script di informazioni sui server di distribuzione e di pubblicazione.

No. La replica non crittografa i dati archiviati nel database o trasferiti nella rete. Per ulteriori informazioni, vedere la sezione relativa alla crittografia nell'argomento Panoramica della protezione (replica).

È possibile replicare i dati su Internet utilizzando:

• Una rete privata virtuale (VPN). Per ulteriori informazioni, vedere Pubblicazione dei dati su Internet utilizzando VPN.

• L'opzione di sincronizzazione tramite il Web per la replica di tipo merge. Per ulteriori informazioni, vedere Sincronizzazione Web per la replica di tipo merge.

Tutti i tipi di replica di Microsoft SQL Server possono replicare i dati in una VPN, ma è consigliabile considerare la sincronizzazione tramite Web se si utilizza la replica di tipo merge.

Sì. L'elaborazione della replica viene ripresa dal punto in cui si era arrestata per interruzione della connessione. Se si utilizza la replica di tipo merge in una rete inaffidabile, è consigliabile considerare l'utilizzo dei record logici, che garantisce che le modifiche correlate vengano elaborate come una unità. Per ulteriori informazioni, vedere Raggruppamento di modifiche alla righe correlate con record logici.

Sì, la replica funziona su connessioni a larghezza di banda ridotta. Per le connessioni TCP/IP, utilizza la compressione offerta dal protocollo ma non offre una compressione aggiuntiva. Per le connessioni con sincronizzazione tramite il Web in HTTPS, utilizza la compressione offerta dal protocollo e la compressione aggiuntiva dei file XML utilizzati per replicare le modifiche. Per ulteriori informazioni sulla replica nelle connessioni a larghezza di banda ridotta, vedere Problemi causati da una rete lenta.

No. Per trasferire account di accesso e password da un server di pubblicazione a uno o più Sottoscrittori, si potrebbe creare un pacchetto DTS. Per ulteriori informazioni, vedere Progettazione e implementazione di pacchetti (Integration Services).

A partire da Microsoft SQL Server 2005, il termine schema ha due significati:

• La definizione di un oggetto, come un'istruzione CREATE TABLE. Per impostazione predefinita, la replica copia le definizioni di tutti gli oggetti replicati nel Sottoscrittore.

• Lo spazio dei nomi in cui viene creato un oggetto: <Database>.<Schema>.<Oggetto>. Gli schemi vengono definiti utilizzando l'istruzione CREATE SCHEMA. Per ulteriori informazioni sugli schemi, vedere Schemi (Motore di database).

• In relazione agli schemi e alla proprietà degli oggetti, la replica ha il seguente comportamento predefinito nella Creazione guidata nuova pubblicazione:

• Per gli articoli di pubblicazioni di tipo merge con un livello di compatibilità 90 o superiore, per le pubblicazioni snapshot e quelle transazionali: per impostazione predefinita, il proprietario dell'oggetto nel Sottoscrittore è uguale al proprietario dell'oggetto corrispondente nel server di pubblicazione. Se nel Sottoscrittore non esistono gli schemi che possiedono gli oggetti, vengono creati automaticamente.

• Per gli articoli di pubblicazioni di tipo merge con un livello di compatibilità inferiore a 90: per impostazione predefinita, il proprietario rimane vuoto e viene specificato come dbo durante la creazione dell'oggetto nel Sottoscrittore.

• Per articoli contenuti in pubblicazioni Oracle: per impostazione predefinita, viene specificato il proprietario dbo.

• Per gli articoli di pubblicazioni che utilizzano snapshot in modalità carattere (utilizzati per Sottoscrittori non SQL Server e Sottoscrittori SQL Server Compact 3.5 SP1: per impostazione predefinita, il proprietario rimane vuoto. Per impostazione predefinita, il proprietario è quello associato all'account utilizzato dall'agente di distribuzione o di merge per connettersi al Sottoscrittore.

È possibile cambiare il proprietario dell'oggetto utilizzando la finestra di dialogo Proprietà articolo - <Article> oppure le seguenti stored procedure: sp_addarticle, sp_addmergearticle, sp_changearticle e sp_changemergearticle. Per ulteriori informazioni, vedere Procedura: Visualizzazione e modifica delle proprietà delle pubblicazioni e degli articoli (SQL Server Management Studio), Procedura: Definizione di un articolo (programmazione Transact-SQL della replica) e Procedura: Visualizzazione e modifica delle proprietà degli articoli (programmazione Transact-SQL della replica).

Per impostazione predefinita, la replica non esegue istruzioni GRANT nel database di sottoscrizione. Se si desidera che le autorizzazioni del database di sottoscrizione corrispondano a quelle del database di pubblicazione, utilizzare uno dei seguenti metodi.

• Eseguire le istruzioni GRANT direttamente nel database di sottoscrizione.

• Per eseguire le istruzioni, utilizzare uno script post-snapshot. Per ulteriori informazioni, vedere Esecuzione di script prima e dopo l'applicazione dello snapshot.

• Per eseguire le istruzioni, utilizzare la stored procedure sp_addscriptexec.

Per impostazione predefinita, gli oggetti nel Sottoscrittore vengono eliminati e ricreati quando viene reinizializzata una sottoscrizione, cosa che provoca l'eliminazione di tutte le autorizzazioni concesse per tali oggetti. Questa operazione può essere gestita in due modi:

• Riapplicare le concessioni dopo la reinizializzazione utilizzando le tecniche descritte nella sezione precedente.

• Specificare che gli oggetti non devono essere eliminati alla reinizializzazione della sottoscrizione. Prima della reinizializzazione, eseguire una delle seguenti operazioni:

  • Eseguire sp_changearticle o sp_changemergearticle. Specificare il valore 'pre_creation_cmd' (sp_changearticle) o 'pre_creation_command' (sp_changemergearticle) per il parametro @property e il valore 'none', 'delete' o 'truncate' per il parametro @value.

  • Nella sezione Oggetto di destinazione della finestra di dialogo Proprietà articolo - <Article> selezionare il valore Non modificare l'oggetto esistente, Elimina i dati. Se all'articolo è associato un filtro di riga, elimina solo i dati che soddisfano i criteri del filtro. oppure Tronca tutti i dati nell'oggetto esistente per l'opzione Azione se il nome è in uso. Per ulteriori informazioni sull'accesso a questa finestra di dialogo, vedere Procedura: Visualizzazione e modifica delle proprietà delle pubblicazioni e degli articoli (SQL Server Management Studio).

TRUNCATE TABLE è un'operazione non registrata che non attiva i trigger. Non è consentita perché la replica non può tener traccia delle modifiche provocate dall'operazione: la replica transazionale tiene traccia delle modifiche tramite il log delle transazioni, la replica di tipo merge tramite i trigger sulle tabelle pubblicate.

Per la replica transazionale, gli inserimenti bulk vengono rilevati e replicati come gli altri inserimenti. Per la replica di tipo merge, è necessario verificare che i metadati di rilevamento delle modifiche vengano aggiornati correttamente. Per ulteriori informazioni, vedere la sezione relativa all'inserimento bulk di dati nelle tabelle pubblicate nell'argomento Considerazioni per la replica di tipo merge.

Sì. I database interessati alla replica richiedono alcune considerazioni speciali per i database. Per ulteriori informazioni, vedere Backup e ripristino dei database replicati.

A differenza della replica di tipo merge e della replica snapshot, la replica transazionale può influire sulla dimensione del log delle transazioni. Se un database include una o più pubblicazioni transazionali, il log non viene troncato finché tutte le transazioni significative per le pubblicazioni non sono state recapitate al database di distribuzione. Se la dimensione del log delle transazioni aumenta in modo eccessivo e l'agente di lettura log viene eseguito in base a una pianificazione, è consigliabile ridurre l'intervallo tra le esecuzioni oppure impostare l'esecuzione in modalità continua. Se l'agente viene impostato per l'esecuzione in modalità continua (impostazione predefinita) verificare che venga eseguito. Per ulteriori informazioni sulla verifica dello stato dell'agente di lettura log, vedere Procedura: Visualizzazione delle informazioni ed esecuzione di attività relative agli agenti associati a una pubblicazione (Monitoraggio replica).

Inoltre, se nel database di pubblicazione o in quello di distribuzione è stata impostata l'opzione 'sync with backup', il troncamento del log delle transazioni avviene solo dopo il backup di tutte le transazioni. Se la dimensione del log delle transazioni sta aumentando in modo eccessivo e questa azione è stata impostata, è consigliabile accorciare l'intervallo tra l'esecuzione di operazioni di backup di tale log. Per ulteriori informazioni sul backup e sul ripristino di database interessati alla replica transazionale, vedere Strategie per il backup e il ripristino della replica snapshot e della replica transazionale.

Per la ricostruzione degli indici esistono diversi meccanismi. Possono essere utilizzati tutti, senza considerazioni speciali per la replica, con la seguente eccezione: le chiavi primarie sono necessarie nelle tabelle delle pubblicazioni transazionali, pertanto non è possibile eliminare e ricreare le chiavi primarie su queste tabelle.

È possibile aggiungere gli indici nel server di pubblicazione o nei Sottoscrittori senza particolari considerazioni per la replica. Ricordare che gli indici possono influire sulle prestazioni. CREATE INDEX e ALTER INDEX non vengono replicati, pertanto se si aggiunge o si modifica un indice, ad esempio, nel server di pubblicazione, è necessario eseguire la stessa aggiunta o modifica nel Sottoscrittore se si desidera che venga riflessa in quest'ultimo.

Nelle versioni di SQL Server precedenti a SQL Server 2005 lo spostamento o la ridenominazione dei file di database richiede lo scollegamento e il ricollegamento del database. Poiché un database replicato non può essere scollegato, innanzitutto era necessario rimuovere la replica da questi database. A partire da SQL Server 2005, è possibile spostare o rinominare i file senza scollegare e ricollegare il database, senza alcun effetto sulla replica. Per ulteriori informazioni sullo spostamento e la ridenominazione di file, vedere ALTER DATABASE (Transact-SQL).

Eliminare in primo luogo l'articolo dalla pubblicazione utilizzando sp_droparticle, sp_dropmergearticle o la finestra di dialogo Proprietà pubblicazione - <Publication>, quindi eliminarlo dal database utilizzando DROP <Object>. Dopo l'aggiunta di sottoscrizioni non è possibile eliminare articoli dalle pubblicazioni snapshot o transazionali: è necessario eliminare prima le sottoscrizioni. Per ulteriori informazioni, vedere Aggiunta ed eliminazione di articoli a e da pubblicazioni esistenti.

SQL Server supporta una vasta gamma di modifiche dello schema sugli oggetti pubblicati, inclusa l'aggiunta e l'eliminazione di colonne. Ad esempio, se si esegue ALTER TABLE … DROP COLUMN nel server di pubblicazione, l'istruzione viene replicata ai Sottoscrittori e poi eseguita per eliminare la colonna. I Sottoscrittori che eseguono versioni di SQL Server precedenti a SQL Server 2005 supportano l'aggiunta e l'eliminazione di colonne tramite le stored procedure sp_repladdcolumn e sp_repldropcolumn. Per ulteriori informazioni, vedere Modifiche allo schema nei database di pubblicazione.

Utilizzando la convalida. La convalida segnala se uno specifico Sottoscrittore è sincronizzato con il server di pubblicazione. Per ulteriori informazioni, vedere Convalida dei dati replicati. A differenza dell'utilità tablediff, la convalida non offre informazioni sulle eventuali righe che non sono sincronizzate correttamente.

Per aggiungere una tabella o un altro oggetto, non è necessario interrompere l'attività sui database di pubblicazione o di sottoscrizione. Aggiungere una tabella a una pubblicazione utilizzando la finestra di dialogo Proprietà pubblicazione - <Publication> o le stored procedure sp_addarticle e sp_addmergearticle. Per ulteriori informazioni, vedere Aggiunta ed eliminazione di articoli a e da pubblicazioni esistenti.

Rimuovere una tabella dalla pubblicazione utilizzando sp_droparticle, sp_dropmergearticle o la finestra di dialogo Proprietà pubblicazione - <Publication>. Dopo l'aggiunta di sottoscrizioni non è possibile eliminare articoli dalle pubblicazioni snapshot o transazionali: è necessario eliminare prima le sottoscrizioni. Per ulteriori informazioni, vedere Aggiunta ed eliminazione di articoli a e da pubblicazioni esistenti.

La reinizializzazione delle sottoscrizioni è necessaria per diverse modifiche degli articoli e delle pubblicazioni. Per ulteriori informazioni, vedere Modifica delle proprietà di pubblicazioni e articoli.

Vi sono diverse modifiche degli articoli e delle pubblicazioni che rendono non validi gli snapshot e richiedono la generazione di un nuovo snapshot. Per ulteriori informazioni, vedere Modifica delle proprietà di pubblicazioni e articoli.

Le azioni necessarie per rimuovere la replica da un database dipendono dalla funzione del database come database di pubblicazione, di sottoscrizione o entrambi. Per ulteriori informazioni, vedere Rimozione della replica.

Per la replica transazionale, utilizzare le stored procedure o la scheda Comandi non distribuiti di Monitoraggio replica. Per ulteriori informazioni, vedere Procedura: Visualizzazione di comandi replicati e di altre informazioni nel database di distribuzione (programmazione Transact-SQL della replica) e Procedura: Visualizzazione delle informazioni ed esecuzione delle attività degli agenti associati a una sottoscrizione (Monitoraggio replica).

Per la replica di tipo merge, utilizzare la stored procedure sp_showpendingchanges. Per ulteriori informazioni, vedere sp_showpendingchanges (Transact-SQL).

Utilizzare la stored procedure sp_replmonitorsubscriptionpendingcmds o la scheda Comandi non distribuiti di Monitoraggio replica. La stored procedure e la scheda mostrano:

• Numero di comandi del database di distribuzione che non sono stati recapitati al Sottoscrittore selezionato. Un comando consiste in un'unica istruzione Transact-SQL DML (Data Manipulation Language) o DDL (Data Definition Language).

• Intervallo di tempo stimato per recapitare i comandi al Sottoscrittore. Se questo valore è maggiore dell'intervallo di tempo necessario per generare e applicare uno snapshot al Sottoscrittore, è consigliabile reinizializzare il Sottoscrittore. Per ulteriori informazioni, vedere Reinizializzazione di una sottoscrizione.

Per ulteriori informazioni, vedere sp_replmonitorsubscriptionpendingcmds (Transact-SQL) e Procedura: Visualizzazione delle informazioni ed esecuzione delle attività degli agenti associati a una sottoscrizione (Monitoraggio replica).

Sì. Per ulteriori informazioni, vedere Replica e log shipping e Replica e mirroring del database.

Sì. Non vi sono considerazioni speciali, poiché tutti i dati vengono archiviati su un solo set di dischi nel cluster.