Domande frequenti per gli amministratori di replica

Articolo
12/15/2008

Data aggiornamento: 14 aprile 2006

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.

Lo snapshot viene generato dall'agente snapshot. Visualizzare lo stato della generazione dello snapshot nella scheda Avvisi e 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).

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:

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 Programming Replication Agent Executables.

È 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 transazioni di massa 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 How to: Specify Schema Options (Replication Transact-SQL Programming).

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 Elementi della protezione della replica.

Come si replicano i dati su Internet?

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

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 creazione di pacchetti di Integration Services.

Cosa sono gli schemi e in che modo vengono replicati?

In 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.
Il proprietario di un oggetto, che viene utilizzato nel nome in più parti, ad esempio <Database>.<Schema>.<Object>. Gli schemi vengono definiti utilizzando 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 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 gli articoli nelle pubblicazioni Oracle: per impostazione predefinita, il proprietario viene specificato come dbo.
Per gli articoli di pubblicazioni che utilizzano snapshot in modalità carattere (utilizzati per Sottoscrittori non SQL Server e Sottoscrittori SQL Server 2005 Compact Edition): 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), How to: Define an Article (Replication Transact-SQL Programming) e How to: View and Modify Article Properties (Replication Transact-SQL Programming).

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 ulteriori informazioni, vedere Esecuzione di script prima e dopo l'applicazione dello snapshot.
Per eseguire le istruzioni, utilizzare la stored procedure sp_addscriptexec (Transact-SQL).

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 (Transact-SQL) o sp_changemergearticle (Transact-SQL). 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 di massa 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 di massa 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 sta aumentando in modo eccessivo e l'agente di lettura log viene eseguito in base a una pianificazione, è consigliabile accorciare l'intervallo tra le esecuzioni o 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 esegue l'aggiornamento da SQL Server versione 7.0 o SQL Server 2000 se si dispone di database replicati?

SQL Server 2005 supporta l'aggiornamento dei database replicati di precedenti versioni di SQL Server. Per ulteriori informazioni, vedere Aggiornamento dei database replicati.

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 precedenti versioni di SQL Server, lo spostamento o la ridenominazione dei file di database richiedeva lo scollegamento e il ricollegamento del database. Poiché un database replicato non può essere scollegato, innanzitutto era necessario rimuovere la replica da questi database. In 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?

Innanzitutto, eliminare l'articolo dalla pubblicazione utilizzando sp_droparticle (Transact-SQL), sp_dropmergearticle (Transact-SQL) 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 2005 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 precedenti di SQL Server supportano l'aggiunta e l'eliminazione di colonne utilizzando le stored procedure sp_repladdcolumn (Transact-SQL) e sp_repldropcolumn (Transact-SQL). 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 della Utilità tablediff, la convalida non offre informazioni sulle eventuali singole 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. È possibile aggiungere una tabella a una pubblicazione utilizzando la finestra di dialogo Proprietà pubblicazione - <Publication> o le stored procedure sp_addarticle (Transact-SQL) e sp_addmergearticle (Transact-SQL). Per ulteriori informazioni, vedere Aggiunta ed eliminazione di articoli a e da pubblicazioni esistenti.

Come si rimuove una tabella da una pubblicazione?

È possibile rimuovere una tabella dalla pubblicazione utilizzando sp_droparticle (Transact-SQL), sp_dropmergearticle (Transact-SQL) 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 How to: View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming) 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 alla distribuzione dei log e al mirroring del database?

Sì. Per ulteriori informazioni, vedere Replica e distribuzione dei log 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.

Vedere anche

Condividi tramite