Come sincronizzare manualmente le sottoscrizioni di replica utilizzando backup o ripristino

Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell’utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell’utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 320499
Questo articolo è stato archiviato. L’articolo, quindi, viene offerto “così come è” e non verrà più aggiornato.
Sommario
In questo articolo viene descritto come sincronizzare manualmente le sottoscrizioni di replica push utilizzando backup e ripristino.

In alcuni casi, è Impossibile sincronizzare completamente le sottoscrizioni di replica, utilizzando il metodo predefinito a causa dei seguenti motivi possibili:
  1. Le tabelle di grandi dimensioni che è necessario trasferire il server di sottoscrizione.
  2. Larghezza di banda della rete può gestire solo le modifiche incrementali BCPs di grandi dimensioni può pertanto verificarsi il timeout.
  3. Il server di pubblicazione è un server di produzione; di conseguenza, business implica il tempo verso il basso per essere ridotta a icona.
In questi casi, è possibile utilizzare i backup di SQL Server per creare copie di database pubblicato e quindi è possibile ripristinare i dati nel Sottoscrittore; in tal modo, è possibile impostare la replica e verificare l'utilizzo della replica senza recapito i dati dello schema o l'utente attraverso la rete. Le sezioni seguenti riportano i passaggi e le considerazioni che è necessario utilizzare per assicurarsi che la sincronizzazione manuale abbia esito positivo.

back to the top

La replica transazionale

La replica transazionale memorizza e inoltra le transazioni seriale al server di sottoscrizione. È fondamentale che le tabelle pubblicate le modifiche vengano recapitate al server di sottoscrizione nell'ordine in cui vengono inoltrati.

Con una nuova sottoscrizione, la replica transazionale vengono contrassegnati come ogni modifica apportata a tabella pubblicata (o tabelle) nel registro delle transazioni. Il metodo di recapito predefinito sottoscrizione blocca le tabelle, verranno esportati i dati utilizzando l'utilità bcp , sblocca le tabelle pubblicate e avvia quindi il rilevamento delle modifiche al database pubblicato. In SQL Server 2000, la funzionalità di Snapshot concorrenti consente di migliorare snapshot blocco overhead. SQL Server 2000 e SQL Server 7.0 è possibile trasferire lo snapshot utilizzando FTP (File Transfer Protocol). Tuttavia, è possibile utilizzare il metodo di backup per le situazioni in cui queste opzioni non sono accettabili.

Backup del database pubblicato e ripristino al server di sottoscrizione, è possibile ridurre il tempo di creazione di snapshot il tempo necessario per il backup del database pubblicato. Il backup del database include tutti gli oggetti che non vengono trasferiti al server di sottoscrizione per la replica; non necessario eseguire un trasferimento di bcp delle tabelle nella rete.

Esistono due metodi per il backup del database pubblicato. Il primo metodo viene utilizzato un backup completo del database pubblicato. Il metodo di backup completo funziona meglio se il database è piccolo o se il database non è configurato per la modalità di recupero completo. Il secondo metodo utilizza un backup del log delle transazioni e si presuppone che già acquisite un backup completo del database. Il metodo di backup del log delle transazioni consente dell'ora in cui il database deve essere in modalità utente singolo. Backup del log delle transazioni richiedono meno tempo rispetto al backup completo. Se si prevede di utilizzare il metodo di backup del log delle transazioni, attenersi alla seguente procedura:
  1. Se il database pubblicato non è in esecuzione in recupero completo modalità, modificarlo in modalità di recupero completo.
  2. Eseguire il backup del database pubblicato.
  3. Eseguire il backup del file di registro per ridurre il tempo impiegato per scorrere la procedura di sottoscrizione e quindi seguire le istruzioni nella procedura successiva.
Per impostare la sottoscrizione, attenersi alla seguente procedura:
  1. Posizionare il database pubblicato in modalità utente singolo per impedire che le modifiche vengano effettuate nel database eseguendo la stored procedure seguente: sp_dboption 'DBNAME', 'utente singolo', 'true' . Ciò impedisce che le modifiche vengano effettuate nel database. Si tratta di un passaggio critico, si effettuano che il server di pubblicazione rimane sincronizzato con il server di sottoscrizione. È necessario arrestare tutti i agenti di replica che sono connessi al database prima di eseguire la stored procedure sp_dboption stored procedure.
  2. Se si utilizza il metodo di backup completo, eseguire il backup del database pubblicato. Se si utilizza il metodo di registro delle transazioni, eseguire il backup di log delle transazioni per il database pubblicato.
  3. Creare una nuova sottoscrizione alla pubblicazione. Selezionare non per distribuire dati e schema.
  4. Durante l'impostazione della sottoscrizione, cercare la schermata pianificazione agente di distribuzione. Modificare l'attività per eseguire una sola volta. (L'agente di distribuzione questo impedisce di eseguire fino a quando, dopo il ripristino del database [e il backup del log delle transazioni] al server di sottoscrizione.)
  5. Rimuovere il database dal modalità utente singolo utilizzando la seguente chiamata di stored procedure: sp_dboption 'DBNAME', 'utente singolo', 'false' . Perché la sottoscrizione è impostata, tutte le modifiche vengono inoltrate al database di distribuzione.
  6. Ripristinare il database nel server di sottoscrizione. Se si utilizza il metodo di registro delle transazioni, è necessario ripristinare il backup completo e il backup del log delle transazioni. L'agente di distribuzione non deve essere eseguito a questo punto. In caso affermativo, impedirà il database ripristinato. L'Agente è stato modificare la pianificazione nel passaggio 4.
  7. Consente di generare le procedure INSERT , Update e Delete vengono utilizzate durante la replica. È possibile generare le istruzioni CREATE PROCEDURE per queste procedure eseguendo una delle seguenti procedure: (le procedure variano a seconda del tipo di replica e la versione di SQL Server)
    1. Per SQL Server 2000: sp_scriptpublicationcustomprocs

      Eseguire sp_scriptpublicationcustomprocs sul server di pubblicazione. Questa procedura genera testo per le stored procedure sono necessarie nel server di sottoscrizione. Eseguire lo script generato nel database di sottoscrizione.
    2. Per l'aggiornamento immediato e il server di sottoscrizione in coda: sp_script_synctran_commands

      Nota L'aggiornamento immediato e server di sottoscrizione in coda rappresentano un'eccezione a passaggio 4. Prima di applicare l'output per il sp_script_synctran_commands a database di sottoscrizione perché l'agente di distribuzione genera una tabella di supporto è denominata MSsubscription_agents , è necessario eseguire l'agente di distribuzione. Dopo aver eseguito l'agente di distribuzione, applicare lo script generato da sp_script_synctran_commands al database del server di sottoscrizione. È inoltre necessario eseguire la procedura sp_scriptpublicationcustomprocs memorizzati per i sottoscrittori ad aggiornamento immediati nel server di pubblicazione e lo script generato nel database di sottoscrizione.

    3. È necessario applicare l'output per sp_script_synctran_commands a database di sottoscrizione; tuttavia, è necessario eseguire l'agente di distribuzione per generare una tabella di supporto denominata MSsubscription_agents e quindi è possibile applicare l'output generato quando si esegue sp_script_synctran_commands . È inoltre necessario eseguire sp_scriptpublicationcustomprocs per i sottoscrittori aggiornamento immediato nel server di pubblicazione. Eseguire lo script generato nel database di sottoscrizione.
    4. Per SQL Server 7.0: Sp_scriptinsproc sp_scriptdelproc , sp_scriptupdproc , sp_scriptmappedupdproc

      Queste procedure generano script per le procedure necessarie nel server di sottoscrizione. Consente di eseguire questi script del database di sottoscrizione.
  8. Avviare l'agente di distribuzione. Sarà necessario impostare l'agente di distribuzione per l'esecuzione continua. A tale scopo, aggiungere in modo - Continua alla riga di comando dell'agente di distribuzione.
Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
299903FIX: sp_scriptpublicationcustomprocs genera stored procedure di replica
back to the top

Replica di tipo merge

Nota No-sincronizzare sottoscrizioni non sono supportate per le sottoscrizioni pull di tipo merge.

Quando si utilizza backup o ripristino configurazione di una sottoscrizione di una pubblicazione di stampa unione con l'opzione nosync, attenersi alla seguente procedura:
  1. Pubblicare il database e quindi eseguire l'agente snapshot. Se il database è stato pubblicato, è sufficiente eseguire l'agente snapshot.

    Tutte le modifiche apportate nel server di pubblicazione siano ora registrate nelle tabelle di sistema di replica di unione.
  2. Eseguire il backup del database pubblicato e quindi ripristinarli sul server di sottoscrizione.
  3. Creare una nuova sottoscrizione e quindi selezionare No, lo schema e dati sono disponibili da server di sottoscrizione già .
  4. Eseguire l'agente di unione.

    Quando viene eseguito l'agente di merge, viene utilizzato prima lo snapshot per creare l'unione di tabelle di replica. Tutte le modifiche apportate dal momento che è stato generato lo snapshot vengono applicate ai server di sottoscrizione:
    • Se tutte le righe tra passaggio 1 e il passaggio 2 è stato aggiunto in questa procedura, si noterà le nuove righe aggiornamenti sul server di sottoscrizione. Le righe già esistono a causa del ripristino. Di conseguenza, si noterà le nuove righe nel Sottoscrittore.
    • Se è stato eliminato tutte le righe tra passaggio 1 e il passaggio 2 in questa procedura, l'agente di merge vengono segnalati che non devono essere apportate modifiche perché le righe non esistono nel Sottoscrittore. Il backup o ripristino è stata eseguita dopo le righe sono state eliminate nel server di pubblicazione.
    • Se tutte le righe sono state aggiornate tra passaggio 1 e il passaggio 2 in questa procedura, verrà visualizzato come gli aggiornamenti nel Sottoscrittore.
back to the top
Informazioni
Per ulteriori informazioni su come inizializzare una sottoscrizione transazionale da un backup in SQL Server 2005, visitare il seguente sito Web MSDN (informazioni in lingua inglese): Per ulteriori informazioni su come inizializzare una sottoscrizione di tipo merge da un backup in SQL Server 2005, visitare il seguente sito Web MSDN:

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 320499 - Ultima revisione: 12/07/2015 10:24:22 - Revisione: 7.1

Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2000 Developer Edition

  • kbnosurvey kbarchive kbmt kbhowtomaster KB320499 KbMtit
Feedback