none
SQL Replica su Database esistente.. RRS feed

  • Domanda

  • Ciao a tutti, in azienda stiamo valutando la possibilità di attivare la replica dei nostri database tra le varie sedi. Ora, uno dei nostri problemi è, oltre alla più completa mancanza di esperienza, il seguente: dovendo attivare la replica nei database già esistenti (che attualmente sono privi di UniqueIdentifier e dove TUTTE le primary key sono degli ID di tipo INT identity e le foreign key puntano a queste ID), come faccio a rimpiazzare questi ID in UniqueIdentifier? Stiamo parlando di 5 database con un totale di circa 300 tabelle per qualche centinaia di migliaia di record.........

    Ci sono dei tools e/o script già fatti (affidabili) oppure devo abituarmi all'idea che non sarà possibile attivare la replica?

    Ciao Enrico

    venerdì 19 novembre 2010 10:49

Risposte

  • Ciao Enrico,

    poichè parli di Replica tra uffici diversi desumo che l'orientamento sia verso la replica merge, ma visto anche che parli di "più completa mancanza di esperienza", forse il primo punto è proprio determinare il tipo di replica che vorreste implementare.

    Considera però che per quanto sia uno strumento sensazionalmente potente la replica è anche uno strumento parecchio complicato.

    Un database in replica, per funzionare bene, dovrebbe essere "pensato per la replica" e questo mi pare che proprio che purtroppo non sia il caso vostro.

    Esistono in generale due ordini di problemi da considerare. Uno di tipo tecnologico (la questione uniqueidentifier, distribuzione degli identity e compagnia) e uno di tipo architetturale (come si gestisce la numerazione progressiva e univoca a livello di gruppo di documenti?).

    Ora, ammesso che i vostri databases non abbiano problemi architetturali e che ognuno possa davvero lavorare per se su un flusso di dati che poi si riorganizza in un server centrale, restano da superare gli ostacoli tecnici.

    Quello che citi è uno più semplici, non appena metti un  db in replica (merge) si occupa sql stesso di aggiungere tutti i gui rowguidcol del caso. Poi di problemi ne sorgono mille altri. Le tabelle non hanno più la stessa forma, quindi tutte le select * non ritornano più gli stessi dati...

    Insomma, mettete in conto una bella fase di lacrime e sangue e moltissimo studio.

    marc.

    giovedì 2 dicembre 2010 18:15

Tutte le risposte

  • Dove hai trovato scritto che la replica non è possibile senza UniqueIdentifiers?

    hai letto qui?

    http://technet.microsoft.com/en-us/library/ms151198.aspx

     


    Diego Castelli - MCSA 2003, MCP ISA 2004, MCTS Forefront. ITA: Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposto come risposta Diego Castelli martedì 30 novembre 2010 14:55
    venerdì 26 novembre 2010 13:48
  • Ciao Enrico,

    poichè parli di Replica tra uffici diversi desumo che l'orientamento sia verso la replica merge, ma visto anche che parli di "più completa mancanza di esperienza", forse il primo punto è proprio determinare il tipo di replica che vorreste implementare.

    Considera però che per quanto sia uno strumento sensazionalmente potente la replica è anche uno strumento parecchio complicato.

    Un database in replica, per funzionare bene, dovrebbe essere "pensato per la replica" e questo mi pare che proprio che purtroppo non sia il caso vostro.

    Esistono in generale due ordini di problemi da considerare. Uno di tipo tecnologico (la questione uniqueidentifier, distribuzione degli identity e compagnia) e uno di tipo architetturale (come si gestisce la numerazione progressiva e univoca a livello di gruppo di documenti?).

    Ora, ammesso che i vostri databases non abbiano problemi architetturali e che ognuno possa davvero lavorare per se su un flusso di dati che poi si riorganizza in un server centrale, restano da superare gli ostacoli tecnici.

    Quello che citi è uno più semplici, non appena metti un  db in replica (merge) si occupa sql stesso di aggiungere tutti i gui rowguidcol del caso. Poi di problemi ne sorgono mille altri. Le tabelle non hanno più la stessa forma, quindi tutte le select * non ritornano più gli stessi dati...

    Insomma, mettete in conto una bella fase di lacrime e sangue e moltissimo studio.

    marc.

    giovedì 2 dicembre 2010 18:15