MS-SQL Server 2005: inizializzazione di una sottoscrizione di unione con posizione di istantanea alternativa

Question

Abbiamo iniziato alcune repliche di unione oltreoceano 1 anno fa e fino ad ora tutto sta andando bene. Il mio problema è che ora disponiamo di così tanti dati nel nostro sistema che qualsiasi arresto anomalo su uno dei server dell'abbonato sarà un disastro: reinizializzare un abbonamento nel modo standard richiederà giorni (i nostri collegamenti sono decisamente lenti, ma già molto, molto costosi)! Tra le idee che ho seguito sono le seguenti:

1. crea una copia dell'originale database, congelarlo, inviare i file in aereo per l'abbonato, e avviare la replica senza istantanea: questo è qualcosa che era fatto tradizionalmente con gli anziani versioni di SQL, ma suona a un po 'confuso con me: avrei per inserire i dati del mio editore modalità di sola lettura e ferma tutto repliche fino all'operazione completata.
2. crea un'istantanea dei dati, inviare i file dell'istantanea all'estero, installarli sull'abbonato e indica la nuova posizione dell'istantanea come posizione alternativa in proprietà di replica. Questo mi sembra giusto (non è necessario sospendere le repliche in corso, nessun blocco dei dati), ma, su questo punto, la guida di Microsoft non ... aiuto.

Sono sicuro che alcuni di voi abbiano già vissuto una situazione del genere. Qual è stata la tua scelta?

EDIT: ovviamente, si potrebbe dire " Perché non provi semplicemente le tue idee " ;, ma ci vorranno ore (più istanze di sql-server, macchine virtuali e tutto il resto ... ) e stavo pensando che il ragazzo che lo ha fatto avrà bisogno di solo 2 minuti per spiegare la sua idea. E sarei l'uomo più felice se qualcuno accettasse di perdere 2 minuti del suo tempo per risparmiarmi ore di duro lavoro ...

Answer 1

Ho dovuto fare qualcosa di simile a questo durante la replica di dati da Los Angeles, California alla Cina. Il caricamento dello snap avrebbe richiesto 44 giorni utilizzando i metodi normali.

Quello che ho fatto è stato configurare la replica SQL per utilizzare un percorso locale per lo snapshot. Ho quindi disabilitato il lavoro transazionale (nel tuo caso il lavoro di unione). Ho quindi eseguito lo snap. Ho compresso lo snap e inviato i file FTP dalla California alla Cina. Quando sono arrivati ??in Cina, li ho decompressi e li ho messi nello stesso percorso di cartella che ho usato in California.

Ho quindi eseguito il file distribut.exe dalla riga di comando sul server in Cina. Questo ha caricato i dati nella tabella in Cina. Una volta caricato lo snap, ho chiuso il distributore sul server in Cina e ho avviato il normale distributore sul server in California.

Questo metodo ha richiesto solo circa 28 ore anziché più di un mese.

Se i tuoi dati impiegheranno più di un paio di giorni per arrivare a destinazione, dovrai modificare la pubblicazione e aumentare la quantità di dati che possono essere messi in coda o l'abbonato sarà scaduto e una nuova istantanea verrà deve essere preso.

Answer 2

Abbiamo appena attraversato qualcosa del genere, e non è carino. Anche se tutti i server coinvolti erano locali, ci è voluto ancora molto tempo.

Solo per rendere le cose più difficili, almeno con SQL 2000, lo snapshot fallirà se la cabina compressa superasse i 4 Gig.

Il miglior consiglio che posso offrire è quello di assicurarsi che ogni sito abbia buoni backup disponibili. Con ciò, almeno i dati non dovrebbero essere trasferiti manualmente al sottoscrittore.