Come sincronizzare manualmente le sottoscrizioni di replica utilizzando backup o ripristino

Traduzione articoli Traduzione articoli
Identificativo articolo: 320499 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

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.

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

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.

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):
http://msdn2.microsoft.com/en-us/library/ms151705.aspx
Per ulteriori informazioni su come inizializzare una sottoscrizione di tipo merge da un backup in SQL Server 2005, visitare il seguente sito Web MSDN:
http://msdn2.microsoft.com/en-us/library/ms152488.aspx

ProprietÓ

Identificativo articolo: 320499 - Ultima modifica: lunedý 12 novembre 2007 - Revisione: 7.1
Le informazioni in questo articolo si applicano a:
  • 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
Chiavi:á
kbmt kbhowtomaster KB320499 KbMtit
Traduzione automatica articoli
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
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com