• Articolo

Domande frequenti per gli amministratori di replica

Le domande e risposte seguenti offrono indicazioni su una vasta gamma di attività svolte dagli amministratori dei database replicati.

Configurazione della replica

È necessario interrompere 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 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.

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.

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 shapshot non genera un errore. Tuttavia, è necessario considerare quanto segue:

È 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 d'emergenza per una topologia di replica. Per ulteriori informazioni sulla creazione di script, vedere Creazione di script di replica.

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.

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 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).

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 ulteriori informazioni, vedere Replica di colonne Identity.

È possibile pubblicare gli stessi oggetti in pubblicazioni diverse?

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.

È 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, 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).

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 informazioni, vedere Proprietà della replica e Script di informazioni sui server di distribuzione e di pubblicazione.

La replica crittografa i dati?

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).

Come si replicano i dati su Internet?

È possibile replicare i dati su Internet utilizzando:

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.

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 ulteriori informazioni, vedere Raggruppamento di modifiche alla 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 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.

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, si potrebbe creare un pacchetto DTS. Per ulteriori informazioni, vedere Progettazione e implementazione di pacchetti (Integration Services).

Cosa sono gli schemi e in che modo vengono replicati?

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).

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.

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 @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).

Manutenzione database

Per quale motivo non è possibile eseguire TRUNCATE TABLE su una tabella pubblicata?

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.

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. Per ulteriori informazioni, vedere la sezione relativa all'inserimento bulk di dati nelle tabelle pubblicate nell'argomento Considerazioni per la replica di tipo merge.

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 ulteriori informazioni, vedere Backup e ripristino dei 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 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.

Come si ricostruiscono gli indici o le tabelle nei database replicati?

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.

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 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.

Come si spostano o si rinominano i file per i database interessati alla replica?

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).

Come si elimina una tabella in corso di replica?

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.

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 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.

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 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.

Come si aggiunge una tabella a una pubblicazione esistente?

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.

Come si rimuove una tabella da una pubblicazione?

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.

Quali azioni richiedono la reinizializzazione delle sottoscrizioni?

La reinizializzazione delle sottoscrizioni è necessaria per diverse modifiche degli articoli e delle pubblicazioni. Per ulteriori informazioni, vedere Modifica delle 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 ulteriori informazioni, vedere Modifica delle 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. Per ulteriori informazioni, vedere Rimozione della replica.

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 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).

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 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).

Replica e altre funzionalità del database

La replica funziona insieme al log shipping e al mirroring del database?

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

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.