Strategie di backup e ripristino della replica snapshot e della replica transazionale

Si applica a:SQL ServerDatabase SQL di Azure

Quando si progetta una strategia di backup e ripristino per la replica snapshot e la replica transazionale, ci sono tre aree da considerare:

  • Database di cui eseguire il backup.
  • Impostazioni di backup per la replica transazionale.
  • Passaggi richiesti per ripristinare un database, i quali variano in base al tipo di replica e alle opzioni scelte.

In questo argomento vengono illustrate le tre aree elencate in precedenza. Per informazioni sul backup e sul ripristino per gli editori Oracle, vedere Backup e ripristino per gli editori Oracle.

Nota

L'istanza gestita di SQL di Azure può essere un server di pubblicazione, un server di distribuzione e un sottoscrittore per la replica snapshot e transazionale. I database nel database SQL di Azure possono essere solo sottoscrittori push per la replica snapshot e transazionale. Per altre informazioni, vedere Replica transazionale con il database SQL di Azure e con Istanza gestita di SQL di Azure.

Backup di database

Per la replica snapshot e la replica transazionale è necessario effettuare a intervalli regolari il backup dei database seguenti:

  • Il database delle pubblicazioni nel Publisher.

  • Il database di distribuzione presso il Distributore.

  • Il database delle sottoscrizioni presso ciascun sottoscrittore.

  • I database di sistema master e msdb nel Server di pubblicazione, nel Server di distribuzione e in tutti i Sottoscrittori. Il backup di questi database deve essere eseguito contemporaneamente e nello stesso momento del relativo database di replica. Eseguire ad esempio il backup dei database master e msdb nel server di pubblicazione nello stesso momento in cui si esegue il backup del database di pubblicazione. Se il database di pubblicazione viene ripristinato, verificare che i database master e msdb siano consistenti con il database di pubblicazione in termini di impostazioni e configurazione della replica.

Se si eseguono backup regolari del registro, tutte le eventuali modifiche relative alla replica dovrebbero essere acquisite nei backup del registro. Se non si eseguono i backup del log, è necessario eseguire un backup ogni volta che un'impostazione relativa alla replica viene modificata. Per ulteriori informazioni, consultare Azioni comuni che richiedono un backup aggiornato.

Impostazioni di backup per la replica transazionale

La replica transazionale implica l'utilizzo dell'opzione sync with backup , che può essere impostata nel database di distribuzione e nel database di pubblicazione:

  • Si consiglia di impostare sempre questa opzione nel database di distribuzione.

    L'impostazione di questa opzione nel database di distribuzione impedisce che le transazioni nel log del database di pubblicazione vengano troncate fino al relativo backup nel database di distribuzione. È possibile ripristinare lo stato del database di distribuzione al momento dell'ultimo backup. Eventuali transazioni mancanti verranno recapitate dal database di pubblicazione al database di distribuzione. La replica continua senza interruzioni.

    L'impostazione di questa opzione nel database di distribuzione non influisce sulla latenza di replica. L'opzione ritarderà tuttavia il troncamento del log nel database di pubblicazione fino a quando non viene eseguito il backup delle transazioni corrispondenti nel database di distribuzione. Ciò può comportare la creazione di un log delle transazioni di dimensioni maggiori nel database di pubblicazione.

  • Si consiglia di impostare questa opzione nel database di pubblicazione se l'applicazione in uso tollera un'ulteriore latenza.

    L'impostazione di questa opzione nel database di pubblicazione garantisce che le transazioni vengano recapitate al database di distribuzione solo dopo che è stato eseguito il backup nel database di pubblicazione. Nel server di pubblicazione è quindi possibile ripristinare il backup più recente del database di pubblicazione, evitando che il database di distribuzione disponga di transazioni che risultino mancanti nel database di pubblicazione ripristinato.

    La latenza e la velocità effettiva sono influenzate, perché le transazioni non possono essere inviate al database di distribuzione finché non ne è stato eseguito il backup sul server di pubblicazione. Se ad esempio viene eseguito un backup del log delle transazioni ogni cinque minuti, si verifica un'ulteriore latenza di cinque minuti tra l'esecuzione del commit di una transazione nel server di pubblicazione e il recapito della transazione al database di distribuzione e successivamente al Sottoscrittore.

    Nota

    L'opzione sync with backup garantisce la consistenza tra il database di pubblicazione e il database di distribuzione, ma non offre alcuna garanzia contro la perdita dei dati. Se ad esempio il log delle transazioni viene perso, le transazioni di cui è stato eseguito il commit dopo l'ultimo backup del log non saranno disponibili nel database di pubblicazione o nel database di distribuzione. Questo comportamento è identico a quello di un database non replicato.

    L'impostazione dell'opzione di sincronizzazione con il backup nel database di distribuzione non è compatibile quando il database di pubblicazione fa parte di un gruppo di disponibilità. Questo potrebbe causare il seguente errore quando l'agente di lettura del log viene avviato dopo il failover.

    Impossibile eseguire il processo “sp_repldone/sp_replcounters” in “machinename\instance”. (Origine: MSSQL_REPL, Numero di errore: MSSQL_REPL20011) Ottieni assistenza: http://help/MSSQL_REPL20011 Possibile stato incoerente nel database di distribuzione: dist_backup_lsn {nnnnnnnn:nnnnnnnn:nnnn}, dist_last_lsn {nnnnnnnn:nnnnnnnn:nnnn}. Eseguire "sp_repldone NULL, NULL, 0, 0, 1", quindi eseguire sp_replflush. Reinizializzare tutte le sottoscrizioni della pubblicazione. (Origine: MSSQLServer, Numero errore: 18846)

Per impostare l'opzione sync with backup

Ripristino di database coinvolti nella replicazione

È possibile ripristinare tutti i database in una topologia di replica se sono disponibili backup recenti e viene eseguita la procedura appropriata. La procedura di ripristino per il database di pubblicazione dipende dal tipo di replica e dalle opzioni utilizzate, mentre quella per tutti gli altri database è indipendente da tali fattori.

La replica supporta il ripristino dei database replicati nello stesso server e nello stesso database da cui è stato creato il backup. Se si ripristina un backup di un database replicato in un altro server o database, le impostazioni di replica non potranno essere mantenute. In questo caso, è necessario ricreare tutte le pubblicazioni e le sottoscrizioni dopo il ripristino dei backup.

Editore

Sono disponibili procedure di ripristino per i tipi di replica seguenti:

  • Replica di snapshot

  • Replica transazionale in sola lettura

  • Replicazione transazionale con sottoscrizioni aggiornabili

  • Replica transazionale peer-to-peer

Il ripristino dei database msdb e master , descritti in questa sezione, è identico per tutti i quattro tipi.

Database di pubblicazione: Replica snapshot

  1. Ripristinare il backup più recente del database di pubblicazione. Andare al passaggio 2.

  2. Il backup del database di pubblicazione contiene la configurazione più recente per tutte le pubblicazioni e le sottoscrizioni? In caso affermativo, il ripristino viene completato. In caso contrario, andare al passaggio 3.

  3. Rimuovere la configurazione della replica dal server di pubblicazione, dal database di distribuzione e dai Sottoscrittori, quindi ricreare la configurazione. Il ripristino viene completato.

    Per altre informazioni su come rimuovere la replica, vedere sp_removedbreplication (Transact-SQL).

Database di pubblicazione: replica transazionale di sola lettura

  1. Ripristinare il backup più recente del database di pubblicazione. Andare al passaggio 2.

  2. L'opzione sync with backup era abilitata nel database di pubblicazione prima dell'errore? In caso affermativo, andare al passaggio 3. In caso contrario, andare al passaggio 5.

    Se l'opzione è abilitata, la query SELECT DATABASEPROPERTYEX('<PublicationDatabaseName>', 'IsSyncWithBackup') restituisce "1".

  3. Il backup ripristinato è completo e aggiornato? Contiene la configurazione più recente per tutte le pubblicazioni e le sottoscrizioni? In caso affermativo, il ripristino viene completato. In caso contrario, andare al passaggio 4.

  4. Le informazioni di configurazione nel database di pubblicazione ripristinato non sono aggiornate. È pertanto necessario assicurarsi che i Sottoscrittori dispongano di tutti i comandi in sospeso nel database di distribuzione, quindi eliminare e ricreare la configurazione della replica.

    1. Eseguire l'Agente di distribuzione finché tutti i sottoscrittori non sono sincronizzati con i comandi in sospeso nel database di distribuzione. Verificare che tutti i comandi vengano recapitati ai Sottoscrittori utilizzando la scheda Comandi non distribuiti in Monitoraggio replica oppure eseguendo una query sulla vista MSdistribution_status nel database di distribuzione. Vai al passaggio b.

      Per altre informazioni su come eseguire l'agente di distribuzione, vedere Avviare e arrestare un agente di replica (SQL Server Management Studio) e Concetti di base relativi ai file eseguibili dell'agente di replica.

      Per altre informazioni su come verificare i comandi, 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.

    2. Rimuovere la configurazione della replica dal server di pubblicazione, dal database di distribuzione e dai Sottoscrittori, quindi ricreare la configurazione. Quando si ricreano le sottoscrizioni, specificare che il Sottoscrittore dispone già dei dati. Il ripristino viene completato.

      Per altre informazioni su come rimuovere la replica, vedere sp_removedbreplication (Transact-SQL).

      Per ulteriori informazioni su come specificare che il Sottoscrittore dispone già dei dati, vedere Initialize a Subscription Manually.

  5. L'opzione sync with backup non è stata impostata nel database di pubblicazione. Le transazioni che non sono state incluse nel backup ripristinato potrebbero pertanto essere state recapitate al database di distribuzione e ai Sottoscrittori. È a questo punto necessario assicurarsi che i Sottoscrittori dispongano di tutti i comandi in sospeso nel database di distribuzione, quindi applicare manualmente al database di pubblicazione eventuali transazioni non incluse nel backup ripristinato.

    Importante

    Questo processo può comportare il ripristino delle tabelle pubblicate in base a una temporizzazione più recente rispetto a quella di altre tabelle non pubblicate ripristinate dal backup.

    1. Eseguire l'agente di distribuzione finché tutti i sottoscrittori non sono sincronizzati con i comandi in sospeso nel database di distribuzione. Verificare che tutti i comandi vengano recapitati ai Sottoscrittori utilizzando la scheda Comandi non distribuiti in Monitoraggio replica oppure eseguendo una query sulla vista MSdistribution_status nel database di distribuzione. Vai al passaggio b.

      Per altre informazioni su come eseguire l'agente di distribuzione, vedere Avviare e arrestare un agente di replica (SQL Server Management Studio) e Concetti di base relativi ai file eseguibili dell'agente di replica.

      Per altre informazioni su come verificare i comandi, 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.

    2. Utilizzare l' utilità tablediff o un altro strumento per sincronizzare manualmente il server di pubblicazione con il Sottoscrittore. Questa operazione consente di recuperare i dati del database di sottoscrizione non inclusi nel backup del database di pubblicazione. Vai al passo c.

      Per altre informazioni sull'utilità tablediff, vedere Confrontare tabelle replicate al fine di individuare le differenze (programmazione della replica).

    3. Il backup ripristinato è completo e aggiornato? Contiene la configurazione più recente per tutte le pubblicazioni e le sottoscrizioni? In caso affermativo, eseguire la stored procedure sp_replrestart per risincronizzare i metadati del server di pubblicazione con i metadati del database di distribuzione. Il ripristino viene completato. In caso contrario, vai al passaggio d.

    4. Rimuovere la configurazione della replica dal server di pubblicazione, dal database di distribuzione e dai Sottoscrittori, quindi ricreare la configurazione. Quando si ricreano le sottoscrizioni, specificare che il Sottoscrittore dispone già dei dati. Il ripristino viene completato.

      Per altre informazioni su come rimuovere la replica, vedere sp_removedbreplication (Transact-SQL).

      Per ulteriori informazioni su come specificare che il Sottoscrittore dispone già dei dati, vedere Initialize a Subscription Manually.

Database di pubblicazione: replica transazionale con sottoscrizioni aggiornabili

  1. Ripristinare il backup più recente del database di pubblicazione. Andare al passaggio 2.

  2. Eseguire l'agente di distribuzione finché tutti i Sottoscrittori non sono sincronizzati con i comandi in sospeso nel database di distribuzione. Verificare che tutti i comandi vengano recapitati ai Sottoscrittori utilizzando la scheda Comandi non distribuiti in Monitoraggio replica oppure eseguendo una query sulla vista MSdistribution_status nel database di distribuzione. Vai al passaggio 3.

    Per altre informazioni su come eseguire l'agente di distribuzione, vedere Avviare e arrestare un agente di replica (SQL Server Management Studio) e Concetti di base relativi ai file eseguibili dell'agente di replica.

    Per altre informazioni su come verificare i comandi, 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.

  3. Se si utilizzano sottoscrizioni con aggiornamenti in coda, connettersi a ogni sottoscrittore ed eliminare tutte le righe dalla tabella MSreplication_queue (Transact-SQL) nel database di sottoscrizione. Andare al passaggio 4.

    Nota

    Se si utilizzano sottoscrizioni ad aggiornamento in coda e le tabelle contengono colonne Identity, è necessario assicurarsi che dopo un ripristino vengano assegnati gli intervalli di valori Identity corretti. Per altre informazioni, vedere Replicare le colonne IDENTITY.

  4. È a questo punto necessario assicurarsi che i Sottoscrittori dispongano di tutti i comandi in sospeso nel database di distribuzione, quindi applicare manualmente al database di pubblicazione eventuali transazioni non incluse nel backup ripristinato.

    Importante

    Questo processo può comportare il ripristino delle tabelle pubblicate in base a una temporizzazione più recente rispetto a quella di altre tabelle non pubblicate ripristinate dal backup.

    1. Eseguire l'Agente di distribuzione finché tutti i sottoscrittori non sono sincronizzati con i comandi in sospeso nel database di distribuzione. Verificare che tutti i comandi vengano recapitati ai Sottoscrittori utilizzando Monitoraggio replica oppure eseguendo una query sulla vista MSdistribution_status nel database di distribuzione. Vai al passaggio b.

    2. Utilizzare l' tablediff Utility o un altro strumento per sincronizzare manualmente il server di pubblicazione con il Sottoscrittore. Questa operazione consente di recuperare i dati del database di sottoscrizione non inclusi nel backup del database di pubblicazione. Vai alla fase c.

      Per altre informazioni sull'utilità tablediff, vedere Confrontare tabelle replicate al fine di individuare le differenze (programmazione della replica).

    3. Il backup ripristinato è completo e aggiornato? Contiene la configurazione più recente per tutte le pubblicazioni e le sottoscrizioni? In caso affermativo, eseguire la stored procedure sp_replrestart per risincronizzare i metadati del server di pubblicazione con i metadati del database di distribuzione. Il ripristino viene completato. In caso negativo, vai al passaggio d.

    4. Rimuovere la configurazione della replica dal server di pubblicazione, dal database di distribuzione e dai Sottoscrittori, quindi ricreare la configurazione. Quando si ricreano le sottoscrizioni, specificare che il Sottoscrittore dispone già dei dati. Il ripristino viene completato.

      Per altre informazioni su come rimuovere la replica, vedere sp_removedbreplication (Transact-SQL).

      Per ulteriori informazioni su come specificare che il Sottoscrittore dispone già dei dati, vedere Initialize a Subscription Manually.

Database di pubblicazione: replica transazionale peer-to-peer

Nella procedura seguente i database di pubblicazione A, Be C sono inclusi in una topologia di replica transazionale peer-to-peer. I database A e C sono online e funzionano correttamente. Il database B è il database da ripristinare. Il processo descritto, specialmente i passaggi 7, 10 e 11, è molto simile al processo per l'aggiunta di un nodo a una topologia peer-to-peer. Il modo più semplice per eseguire questi passaggi è utilizzare la Configurazione guidata della topologia peer-to-peer, ma è anche possibile usare procedure memorizzate.

  1. Eseguire gli agenti di distribuzione per sincronizzare le sottoscrizioni nei database A e C. Andare al passaggio 2.

    Per altre informazioni su come eseguire l'agente di distribuzione, vedere Avviare e arrestare un agente di replica (SQL Server Management Studio) e Concetti di base relativi ai file eseguibili dell'agente di replica.

  2. Se il database di distribuzione usato da B è ancora disponibile, eseguire gli agenti di distribuzione per sincronizzare le sottoscrizioni tra i database B e A e tra i database B e C. Andare al passaggio 3.

  3. Rimuovere i metadati dal database di distribuzione usato da B eseguendo sp_removedistpublisherdbreplication nel database di distribuzione per B. Andare al passaggio 4.

  4. Nei database A e C eliminare le sottoscrizioni della pubblicazione nel database B. Andare al passaggio 5.

    Per ulteriori informazioni sull'eliminazione delle sottoscrizioni, vedere Subscribe to Publications.

  5. Eseguire un backup del log oppure un backup completo del database A. Andare al passaggio 6.

  6. Ripristinare il backup del database A nel database B. Il database B include ora i dati del database A, ma non la configurazione della replica. Quando si ripristina un backup in un altro server, la replica viene rimossa. La replica è stata quindi rimossa dal database B. Andare al passaggio 7.

  7. Ricreare la pubblicazione nel database B, quindi ricreare le sottoscrizioni tra i database A e B. (Sottoscrizioni che coinvolgono il database C viene gestito in una fase successiva).

    1. Ricreare la pubblicazione nel database B. Andare al passaggio b.

    2. Ricreare la sottoscrizione nel database B della pubblicazione nel database A, specificando che è necessario inizializzare la sottoscrizione con un backup, ovvero impostando il valore initialize with backup per il parametro @sync_type di sp_addsubscription. Vai alla fase c.

    3. Ricreare la sottoscrizione nel database A per la pubblicazione nel database B, specificando che il Sottoscrittore dispone già dei dati, ovvero assegnando il valore replication support only al parametro @sync_type di sp_addsubscription. Vai al passaggio 8.

  8. Eseguite gli agenti di distribuzione per sincronizzare le sottoscrizioni nei database A e B. Se nelle tabelle pubblicate sono presenti colonne di identità, andare al passaggio 9. In caso contrario, andare al passaggio 10.

  9. Dopo il ripristino, anche l'intervallo Identity assegnato per ogni tabella nel database A verrà usato nel database B. Assicurarsi che il database ripristinato B abbia ricevuto tutte le modifiche dal database non riuscito B che sono state propagate al database A e al database C; quindi reinizializzare l'intervallo Identity per ogni tabella.

    1. Eseguire sp_requestpeerresponse nel database B e recuperare il parametro di output @request_id. Vai al passaggio b.

    2. Per impostazione predefinita, l'agente di distribuzione è impostato per l'esecuzione continua. I token dovrebbero pertanto essere inviati automaticamente a tutti i nodi. Se l'agente di distribuzione non viene eseguito in modalità continua, eseguire l'agente. Per altre informazioni, vedere Concetti di base relativi ai file eseguibili dell’agente di replica o Avviare e arrestare un agente di replica (SQL Server Management Studio). Vai alla fase c.

    3. Eseguire sp_helppeerresponses, specificando il valore @request_id recuperato nel passaggio b. Attendere fino a quando tutti i nodi indichino di aver ricevuto la richiesta del peer. Vai al passaggio d.

    4. Utilizzare DBCC CHECKIDENT per reinizializzare ciascuna tabella nel database B , in modo da garantire l'utilizzo di un intervallo appropriato. Vai al passaggio 10.

    Per ulteriori informazioni su come gestire gli intervalli di identità, vedere la sezione "Assegnazione degli intervalli per la gestione manuale degli intervalli di identità" di Replicate Identity Columns.

  10. A questo punto, il database B e il database C non sono direttamente connessi, ma riceveranno modifiche tramite il database A. Se la topologia contiene nodi che eseguono SQL Server 2005 (9.x), andare al passaggio 11; in caso contrario, andare al passaggio 12.

  11. Mettere in stato di inattività il sistema e ricreare la sottoscrizione tra il database B e il database C. Mettere in stato di inattività un sistema significa arrestare le attività sulle tabelle pubblicate in tutti i nodi e verificare che ogni nodo abbia ricevuto tutte le modifiche dagli altri nodi.

    1. Interrompere tutte le attività sulle tabelle pubblicate nella topologia peer-to-peer. Vai al passaggio b.

    2. Eseguire sp_requestpeerresponse nel database B e recuperare il parametro di output @request_id. Vai alla fase c.

    3. Per impostazione predefinita, l'agente di distribuzione è impostato per l'esecuzione continua. I token dovrebbero pertanto essere inviati automaticamente a tutti i nodi. Se l'Agente di distribuzione non è in esecuzione in modalità continua, avviare l'agente. Vai al passaggio d.

    4. Eseguire sp_helppeerresponses, specificando il valore @request_id recuperato nel passaggio b. Attendere fino a quando tutti i nodi indichino di aver ricevuto la richiesta del peer. Vai al passaggio e.

    5. Ricreare la sottoscrizione nel database B alla pubblicazione nel database C, specificando che il Sottoscrittore dispone già dei dati. Vai al passaggio b.

    6. Ricrea la sottoscrizione nel database C alla pubblicazione nel database B, specificando che il Sottoscrittore dispone già dei dati. Vai al passaggio 13.

  12. Ricreare la sottoscrizione tra i database B e C:

    1. Nel database Beseguire una query sulla tabella MSpeer_lsns per recuperare il numero di sequenza del file di log (LSN) della transazione più recente che il database B ha ricevuto dal database C.

    2. Ricrea la sottoscrizione nel database B alla pubblicazione nel database C, specificando che la sottoscrizione deve essere inizializzata in base all'LSN (ovvero un valore di initialize from lsn per il parametro @sync_type di sp_addsubscription). Passare alla fase b.

    3. Ricreare la sottoscrizione nel database C alla pubblicazione nel database B, specificando che il Sottoscrittore dispone già dei dati. Vai al passaggio 13.

  13. Eseguire gli agenti di distribuzione per sincronizzare le sottoscrizioni nei database B e C. Il ripristino viene completato.

Database msdb (server di pubblicazione)

  1. Ripristinare il backup più recente del database msdb .

  2. Il backup ripristinato è completo e aggiornato? Contiene la configurazione più recente per tutte le pubblicazioni e le sottoscrizioni? In caso affermativo, il recupero viene completato. In caso contrario, andare al passaggio 3.

  3. Ricreare il processo di pulizia dei riferimenti alle sottoscrizioni dagli script di replica. Il recupero viene completato.

Database master (server di pubblicazione)

  1. Ripristinare il backup più recente del database master .

  2. Assicurarsi che il database sia consistente con il database di pubblicazione in termini di impostazioni e configurazione della replica.

Database presso il distributore

Database di distribuzione

  1. Ripristinare il backup più recente del database di distribuzione.

  2. L'opzione sync with backup era abilitata nel database di distribuzione prima dell'errore? In caso affermativo, andare al passaggio 3. In caso contrario, andare al passaggio 4.

    Se l'opzione è abilitata, la query SELECT DATABASEPROPERTYEX('<DistributionDatabaseName>', 'IsSyncWithBackup') restituisce "1".

  3. Il backup ripristinato è completo e aggiornato? Contiene la configurazione più recente per tutte le pubblicazioni e le sottoscrizioni? In caso affermativo, il recupero viene completato. In caso contrario, andare al passaggio 4.

  4. Le informazioni di configurazione nel database di distribuzione ripristinato non sono aggiornate o l'opzione sync with backup non è stata impostata nel database di distribuzione. Dopo il ripristino, è possibile che nel database di distribuzione manchino le transazioni di cui è stato eseguito il commit nel server di pubblicazione, ma che non sono state ancora recapitate agli abbonati. Eliminare e ricreare la replica, quindi eseguire la convalida.

    1. Rimuovere la configurazione della replica dal server di pubblicazione, dal database di distribuzione e dai Sottoscrittori, quindi ricreare la configurazione. Quando si ricreano le sottoscrizioni, specificare che il Sottoscrittore dispone già dei dati. Vai al passaggio b.

      Per altre informazioni su come rimuovere la replica, vedere sp_removedbreplication (Transact-SQL).

      Per ulteriori informazioni su come specificare che il Sottoscrittore dispone già dei dati, vedere Initialize a Subscription Manually.

    2. Contrassegnare tutte le pubblicazioni per la convalida. Reinizializzare eventuali sottoscrizioni che non superano la convalida. Il recupero viene completato.

      Per ulteriori informazioni sulla convalida, vedere Validate Replicated Data. Per altre informazioni sulla reinizializzazione, vedere Reinizializzare le sottoscrizioni.

Database msdb (database di distribuzione)

  1. Ripristinare il backup più recente del database msdb .

  2. Il backup ripristinato è completo e aggiornato? Contiene la configurazione più recente per tutte le pubblicazioni e le sottoscrizioni? In caso affermativo, il recupero viene completato. In caso contrario, andare al passaggio 3.

  3. Rimuovere la configurazione della replica dal server di pubblicazione, dal database di distribuzione e dai Sottoscrittori, quindi ricreare la configurazione. Quando si ricreano le sottoscrizioni, specificare che il Sottoscrittore dispone già dei dati. Andare al passaggio 4.

    Per altre informazioni su come rimuovere la replica, vedere sp_removedbreplication (Transact-SQL).

    Per ulteriori informazioni su come specificare che il Sottoscrittore dispone già dei dati, vedere Initialize a Subscription Manually.

  4. Contrassegnare tutte le pubblicazioni per la convalida. Reinizializzare eventuali sottoscrizioni che non superano la convalida. Il recupero viene completato.

    Per ulteriori informazioni sulla convalida, vedere Validate Replicated Data. Per altre informazioni sulla reinizializzazione, vedere Reinizializzare le sottoscrizioni.

Database master (database di distribuzione)

  1. Ripristinare il backup più recente del database master .

  2. Assicurarsi che il database sia consistente con il database di pubblicazione in termini di impostazioni e configurazione della replica.

Database presso l'abbonato

Database di sottoscrizione

  1. L'ultimo backup del database di sottoscrizione è più recente dell'impostazione minima relativa alla memorizzazione per la distribuzione nel database di distribuzione? (Questo determina se il Distributore abbia ancora tutti i comandi necessari per portare il Sottoscrittore allo stato aggiornato.) In caso affermativo, passare al passaggio 2. In caso contrario, reinizializzare la sottoscrizione. Il recupero viene completato.

    Per determinare l'impostazione massima relativa alla memorizzazione per la distribuzione, eseguire sp_helpdistributiondb e recuperare il valore dalla colonna max_distretention . Questo valore è espresso in ore.

    Per ulteriori informazioni sulla reinizializzazione di una sottoscrizione, vedere Reinitialize a Subscription.

  2. Ripristinare il backup del database di sottoscrizione più recente. Vai al passaggio 3.

  3. Se il database di sottoscrizione contiene solo sottoscrizioni push, andare al passaggio 4. Se il database di sottoscrizione contiene sottoscrizioni pull, determinare quanto segue: le informazioni sulla sottoscrizione sono aggiornate? Nel database sono incluse tutte le tabelle e le opzioni impostate al momento dell'errore? In caso affermativo, andare al passaggio 4. In caso contrario, reinizializzare la sottoscrizione. Il recupero viene completato.

  4. Per sincronizzare il Sottoscrittore, eseguire l'agente di distribuzione. Il recupero viene completato.

    Per altre informazioni su come eseguire l'agente di distribuzione, vedere Avviare e arrestare un agente di replica (SQL Server Management Studio) e Concetti di base relativi ai file eseguibili dell'agente di replica.

Database msdb (Sottoscrittore)

  1. Ripristinare il backup più recente del database msdb . In questo Sottoscrittore vengono utilizzate sottoscrizioni pull? In caso di risposta negativa, il ripristino viene completato. In caso affermativo, andare al passaggio 2.

  2. Il backup ripristinato è completo e aggiornato? Contiene la configurazione più recente per tutte le sottoscrizioni pull? In caso affermativo, il recupero viene completato. In caso contrario, andare al passaggio 3.

  3. Eliminare e ricreare le sottoscrizioni pull. Quando si ricreano le sottoscrizioni, specificare che il Sottoscrittore dispone già dei dati. Il ripristino viene completato.

    Per ulteriori informazioni sull'eliminazione delle sottoscrizioni, vedere Subscribe to Publications.

    Per ulteriori informazioni su come specificare che il Sottoscrittore dispone già dei dati, vedere Initialize a Subscription Manually.

Database principale (Sottoscrittore)

  1. Ripristinare il backup più recente del database master .

  2. Assicurarsi che il database sia consistente con il database di pubblicazione in termini di impostazioni e configurazione della replica.

Contenuto correlato

  • Last updated on