Si applica a: 
SQL Server Istanza gestita di SQL di Azure
Le domande e risposte seguenti offrono indicazioni su una vasta gamma di attività svolte dagli amministratori dei database replicati.
Configurazione della replica
È necessario arrestare l'attività su un database quando questo viene pubblicato?
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.
Durante la generazione dello snapshot le tabelle sono bloccate?
La durata dei blocchi dipende dal tipo di replica utilizzata:
Per le pubblicazioni di tipo merge, l'agente snapshot non imposta 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.
Quando è disponibile una sottoscrizione? Quando è possibile utilizzare il database di sottoscrizione?
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 altre informazioni, vedere Visualizzare le informazioni ed eseguire attività usando 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 altre informazioni, vedere Visualizzare le informazioni ed eseguire attività usando Monitoraggio replica.
Cosa accade se l'agente snapshot non ha concluso la propria attività quando viene avviato l'agente di distribuzione o l'agente di merge?
L'esecuzione dell'agente di distribuzione o di merge in contemporanea con quella dell'agente snapshot 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 altre informazioni sull'esecuzione degli agenti, vedere Sincronizzare una sottoscrizione push, Sincronizzare una sottoscrizione pull e Concetti di base relativi ai file eseguibili dell'agente di replica.
È necessario creare lo script della configurazione di replica?
Sì. La creazione dello script della configurazione di replica è un elemento fondamentale di qualunque piano di ripristino di emergenza per una topologia di replica. Per ulteriori informazioni sulla creazione di script, vedere Scripting Replication.
Quale modello di recupero è necessario su un database replicato?
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.
Perché la replica aggiunge una colonna alle tabelle replicate? Tale colonna viene rimossa se la tabella non viene pubblicata?
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.
In un filtro non deve essere inclusa la colonna rowguidcol utilizzata dalla replica per identificare le righe. Per impostazione predefinita, si tratta della colonna aggiunta al momento dell'impostazione della replica di tipo merge ed è denominata rowguid.
Come si gestiscono i vincoli sulle tabelle pubblicate?
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 informazioni sull'impostazione delle opzioni dello schema tramite cui si controlla l'eventuale esecuzione della replica dei vincoli, vedere Specify Schema Options.
Come si gestiscono le colonne Identity?
La replica offre la gestione automatica dell'intervallo di valori Identity per le topologie di replica che includono aggiornamenti nel Sottoscrittore. Per altre informazioni, vedere Replicare colonne Identity.
È possibile pubblicare gli stessi oggetti in pubblicazioni diverse?
Sì, ma con alcune restrizioni. Per altre informazioni, vedere la sezione "Pubblicazione di tabelle in più di una pubblicazione" nell'argomento Pubblicare dati e oggetti di database.
È possibile l'utilizzo dello stesso database di distribuzione da parte di più pubblicazioni?
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, usare la finestra di dialogo Proprietà distributore oppure sp_adddistributiondb (Transact-SQL). Per altre informazioni sull'accesso a questa finestra di dialogo, vedere Visualizzare e modificare le proprietà del server di pubblicazione e del distributore.
In che modo è possibile reperire informazioni sul server di distribuzione e sul quello di pubblicazione, ad esempio per sapere quali oggetti di un database vengono pubblicati?
Queste informazioni sono disponibili tramite SQL Server Management Studio e diverse stored procedure di replica. Per altre informazioni, vedere Distributor and Publisher Information Script.
La replica crittografa i dati?
No. La replica non crittografa i dati archiviati nel database o trasferiti nella rete. Per altre informazioni, vedere la sezione "Crittografia" nell'argomento Visualizzazione e modifica delle impostazioni di sicurezza della replica.
Come si replicano i dati su Internet?
È possibile replicare i dati su Internet utilizzando:
Una rete privata virtuale (VPN). Per altre informazioni, vedere Pubblicare i dati su Internet tramite VPN.
L'opzione di sincronizzazione Web per la replica di tipo merge. Per altre informazioni, vedere Web Synchronization for Merge Replication.
Tutti i tipi di replica di replica di Microsoft SQL Server possono replicare i dati in una VPN, ma è consigliabile considerare la sincronizzazione Web se si usa la replica di tipo merge.
La replica viene ripresa in caso di interruzione della connessione?
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 altre informazioni, vedere Raggruppare modifiche alle righe correlate con record logici.
La replica funziona su connessioni a larghezza di banda ridotta? Utilizza la compressione?
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 Web in HTTPS, utilizza la compressione offerta dal protocollo e la compressione aggiuntiva dei file XML utilizzati per replicare le modifiche.
È possibile configurare la replica se ci si connette al server usando l'indirizzo IP?
No, la replica funziona solo quando si usa il nome effettivo del server. A partire da SQL Server Management Studio (SSMS) 18.0, la replica può essere configurata usando il nome del server e il numero di porta effettivi.
Account di accesso e proprietà degli oggetti
Gli account di accesso e le password vengono replicati?
No. Per trasferire account di accesso e password da un server di pubblicazione a uno o più sottoscrittori, è possibile creare un pacchetto SSIS.
Cosa sono gli schemi e in che modo vengono replicati?
A partire da Microsoft SQL Server 2005 (9.x), lo schema ha due significati:
La definizione di un oggetto, ad esempio 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 usando l'istruzione
CREATE SCHEMA.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 articoli contenuti in pubblicazioni di tipo merge con un livello di compatibilità inferiore a 90: per impostazione predefinita, il proprietario viene lasciato 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 articoli di pubblicazioni che usano snapshot in modalità carattere (usati per abbonati non SQL Server e abbonati SQL Server Compact): per impostazione predefinita, il proprietario rimane vuoto. Il proprietario viene impostato sul proprietario associato all'account utilizzato dall'agente di distribuzione o dall'agente di merge per la connessione al Sottoscrittore.
Il proprietario dell'oggetto può essere modificato tramite la finestra di dialogo Proprietà articolo - <Articolo> e tramite le stored procedure sp_addarticle, sp_addmergearticle, sp_changearticle e sp_changemergearticle. Per altre informazioni, vedere Visualizzare e modificare le proprietà della pubblicazione, Definire un articolo e Visualizzare e modificare le proprietà degli articoli.
In che modo è possibile configurare le concessioni del database di sottoscrizione per ottenere la corrispondenza con quelle del database di pubblicazione?
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 altre informazioni, vedere Eseguire gli script prima e dopo l'applicazione dello snapshot.
Per eseguire le istruzioni, utilizzare la stored procedure sp_addscriptexec .
Cosa accade alle autorizzazioni concesse in un database di sottoscrizione se una sottoscrizione viene reinizializzata?
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
@propertye il valore 'none', 'delete' o 'truncate' per il parametro@value.Nella finestra di dialogo Proprietà articolo - <Articolo> della sezione Oggetto di destinazione, selezionare il valore Mantieni l'oggetto esistente invariato, Elimina dati. Se l'articolo ha un filtro di riga, eliminare solo i dati che corrispondono al filtro o Tronca tutti i dati nell'oggetto esistente per l'opzione Azione se il nome è in uso. Per altre informazioni sull'accesso a questa finestra di dialogo, vedere Visualizzare e modificare le proprietà della pubblicazione.
Manutenzione database
Per quale motivo non è possibile eseguire TRUNCATE TABLE su una tabella pubblicata?
TRUNCATE TABLE è un'istruzione DDL che non registra eliminazioni di singole righe e non attiva trigger DML. 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 DML sulle tabelle pubblicate.
Quale è l'effetto dell'esecuzione di un comando BULK INSERT su un database replicato?
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.
Il backup e il ripristino presentano delle considerazioni relativamente alla replica?
Sì. I database interessati alla replica richiedono alcune considerazioni speciali per i database. Per altre informazioni, vedere Eseguire il backup e ripristino di database replicati.
La replica influisce sulla dimensione del log delle transazioni?
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 altre informazioni sul controllo dello stato dell'agente di lettura log, vedere Visualizzare le informazioni ed eseguire attività usando 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 altre informazioni sul backup e il ripristino dei database coinvolti nella replica transazionale, vedere Strategie di backup e ripristino della replica snapshot e della replica transazionale.
Come si ricompilano gli indici o le tabelle nei database replicati?
Per la ricompilazione 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.
Come si aggiungono o si modificano gli indici nei database di pubblicazione e di sottoscrizione?
È 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 replicate, 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 vuole che venga riflessa in quest'ultimo.
Come si spostano o si rinominano i file per i database interessati alla replica?
Nelle versioni di SQL Server precedenti a SQL Server 2005 (9.x), 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 (9.x), è possibile spostare o rinominare i file senza scollegare e ricollegare il database, senza alcun effetto sulla replica. Per altre informazioni sullo spostamento e la ridenominazione dei file, vedere ALTER DATABASE (Transact-SQL).
Come si elimina una tabella in corso di replica?
Eliminare in primo luogo l'articolo dalla pubblicazione usando sp_droparticle, sp_dropmergearticle o la finestra di dialogo Proprietà pubblicazione - <Pubblicazione>>, quindi eliminarlo dal database usando DROP <Object>. Dopo l'aggiunta di sottoscrizioni non è possibile eliminare articoli dalle pubblicazioni snapshot o transazionali: è necessario eliminare prima le sottoscrizioni. Per altre informazioni, vedere Aggiungere ed eliminare articoli in pubblicazioni esistenti.
Come si aggiungono o si eliminano colonne in una tabella pubblicata?
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 nei sottoscrittori e poi eseguita per eliminare la colonna. Gli abbonati che eseguono versioni di SQL Server precedenti a SQL Server 2005 (9.x) supportano l'aggiunta e l'eliminazione di colonne tramite le stored procedure sp_repladdcolumn e sp_repldropcolumn. Per altre informazioni, vedere Apportare modifiche allo schema nei database di pubblicazione.
Manutenzione della replica
Come si stabilisce se i dati nei Sottoscrittori sono sincronizzati con quelli nel server di pubblicazione?
Utilizzando la convalida. La convalida segnala se uno specifico Sottoscrittore è sincronizzato con il server di pubblicazione. Per altre informazioni, vedere Convalidare i dati replicati. A differenza dell' utilità tablediff , la convalida non offre informazioni sulle eventuali righe che non sono sincronizzate correttamente.
Come si aggiunge una tabella a una pubblicazione esistente?
Per aggiungere una tabella o un altro oggetto, non è necessario arrestare l'attività sui database di pubblicazione o di sottoscrizione. Aggiungere una tabella a una pubblicazione usando la finestra di dialogo Proprietà pubblicazione - <Pubblicazione> o le stored procedure sp_addarticle e sp_addmergearticle. Per altre informazioni, vedere Aggiungere ed eliminare articoli in pubblicazioni esistenti.
Come si rimuove una tabella da una pubblicazione?
Rimuovere una tabella dalla pubblicazione usando 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 altre informazioni, vedere Aggiungere ed eliminare articoli in pubblicazioni esistenti.
Quali azioni richiedono la reinizializzazione delle sottoscrizioni?
La reinizializzazione delle sottoscrizioni è necessaria per diverse modifiche degli articoli e delle pubblicazioni. Per altre informazioni, vedere Modificare le proprietà di pubblicazioni e articoli.
Quali azioni rendono non validi gli snapshot?
Vi sono diverse modifiche degli articoli e delle pubblicazioni che rendono non validi gli snapshot e richiedono la generazione di un nuovo snapshot. Per altre informazioni, vedere Modificare le proprietà di pubblicazioni e articoli.
Come si rimuove la replica?
Le azioni necessarie per rimuovere la replica da un database dipendono dalla funzione del database come database di pubblicazione, di sottoscrizione o entrambi.
In che modo è possibile determinare se vi sono transazioni o righe da replicare?
Per la replica transazionale, utilizzare le stored procedure o la scheda Comandi non distribuiti di Monitoraggio replica. Per altre informazioni, vedere Visualizzare comandi replicati e altre informazioni nel database di distribuzione (programmazione Transact-SQL della replica) e Visualizzare le informazioni ed eseguire attività usando Monitoraggio replica.
Per la replica di tipo merge, utilizzare la stored procedure sp_showpendingchanges. Per altre informazioni, vedere sp_showpendingchanges (Transact-SQL).
Quanto rimane indietro l'agente di distribuzione? È necessario ripetere l'inizializzazione?
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 nel database di distribuzione che non sono stati recapitati al Sottoscrittore selezionato. Un comando è composto da un'istruzione DDL (Data Definition Language) o da un'istruzione DML (Data Manipulation Language) Transact-SQL.
Tempo stimato per il recapito dei comandi al Sottoscrittore. Se questo valore è maggiore del tempo necessario per generare uno snapshot e applicarlo al Sottoscrittore, potrebbe risultare conveniente reinizializzare il Sottoscrittore. Per altre informazioni, vedere Reinizializzare le sottoscrizioni.
Per altre informazioni, vedere sp_replmonitorsubscriptionpendingcmds (Transact-SQL) e Visualizzare le informazioni ed eseguire attività usando Monitoraggio replica.
Replica e altre funzionalità del database
La replica funziona insieme al log shipping e al mirroring del database?
Sì. Per altre informazioni, vedere Log shipping e replica (SQL Server) e Mirroring e replica del database (SQL Server).
La replica funziona insieme al clustering?
Sì. Non vi sono considerazioni speciali, poiché tutti i dati vengono archiviati su un solo set di dischi nel cluster.
Come posso risolvere i problemi di una soluzione di terzi basata sulla replica SQL?
È consigliabile contattare il fornitore terzo per eventuali problemi per ricevere supporto. In genere, se il problema è isolato dal fornitore e identificato come problema di replica principale fornito con SQL Server, il supporto tecnico Microsoft è coinvolto per agevolare ulteriormente.