none
Copia dati da server test a produzione - Consigli RRS feed

  • Domanda

  • ciao a tutti

    vorrei trovare un modo migliore per copiare dei data da un db di test a uno di produzione.

    in questo momento quando devo fare la prima pubblicazione faccio l'attch del db sul server produzione, ovviamente i problemi nascono quando si devono aggiornare dei dati, aggiungere dei campi nelle tabelle o delle viste.. eseguendo l'attach perderei i dati che ci sono sul server di produzione perche non allineati con quelli di test..

    come conviene organizzarsi in un contesto reale?

    ho visto varie opzioni all'interno di SQL Management Studio:

    Copy database, Export e Import Data, Replica, Script,..

    ma ciascuno presenta dei limiti , ad esempio Copy Database non permette di selezionare quali Viste e/o Tabelle copiare..

    Potete suggerirmi una soluzione piu flessibile e professionale??

    Grazie a tutti

    mercoledì 23 settembre 2015 10:19

Risposte

  • ciao,

    di solito il database di test non dovrebbe essere preso e "attachato" in produzione. Di solito questi due sono ambienti completamente isolati e separati, e l'unica cosa che li accomuna è la struttura logica del database. Ma di certo i dati sono completamente diversi e la parte fisica di definizione della base dati è ottimizzata per la produzione, in produzione.

    Al di là di questo, personalmente utilizzo un source control per tutto il codice sorgente e per gli script di pubblicazione del database. Utilizzo poi dei tool di terze parti per fare la diff della struttura logica del database. In poche parole, si fa la differenza tra la situazione di sviluppo (o test, anche se utilizziamo la linea di deploy e non l'ambiente di test) e il database verso il quale andare a pubblicare. Tuttavia puoi evitare tool di terze parti. Puoi anche usare visual studio con i suoi progetti di tipo database. Se però non hai tutto questo, dovrai creare gli script di pubblicazione a mano (o provare uno dei tool che trovi su internet, purtroppo i migliori a pagamento) e andare a rilasciarli con tutti i crismi che servono per salvaguardare la tua produzione (backup, script di gestione con rollback, ecc.).

    Concludo:

    Se non vuoi comprare tool di terze parti (come quelli di Red Gate e ApexSQL che si installano DIRETTAMENTE su management studio, e quindi sono comodissimi se usi SSMS) penserei a Visual Studio per i database, in modo da autogenerare il pacchetto di deploy.

    Oppure, munirti di pazienza e generare ad ogni release le corrette differenze.

    Non seguirei nulla tra backup/restore, copy database, import ed export data, replica.. non sono gli strumenti per il delivery di un database.


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    mercoledì 23 settembre 2015 15:59
    Moderatore
  • I DTS sono morti per MS con la versione 2000 di SQL Server, quindi vivono solo per gli utenti finali ancora fedeli alla piattaforma SQL Server 2000. Il nuovo strumento che, non solo li sostituisce, ma che li ha potenziati e migliorati all'ennesima potenza è denominato Integration Services (troverai anche la dicitura SSIS). La curva di apprendimento non è piccola, ma puoi provarlo, è molto valido.

    I dati di solito sono suddivisi in due grandi categorie, dati utente che cambiano costantemente nel tempo e dati utente ma statici (come le tabelle per le foreign key, le lookup, i valori di dominio e configurazione, ecc.). Mentre per la prima categoria, si può dire che la produzione ha la sua vita (e guai a chi la tocca), per la categoria dei dati statici il problema è annoso. Ci sono strumenti che ti consentono di tenere sotto controllo del codice sorgente (ma devi averne uno, come VSO, TFS, Git, Mercurial, ecc.) i dati statici, appunto, e poi di poterli rilasciare in totale sicurezza ed isolamento nei confronti dei dati utente "intoccabili".

    In mancanza di strumenti di terze parti, purtroppo, con Visual Studio, puoi pensare ad una fase di Pre deploy e Post deploy, nella quale andare a creare uno script di "pubblicazione" di tutti i dati statici di cui necessita la tua applicazione/database.

    Ma è un argomento enorme da approfondire. Pensa che negli ultimi anni sto cercando di parlarne agli eventi proprio per sensibilizzare alcune aziende alla problematica, troppo spesso rinviata in passato. Ci sono corsi, ruoli professionali, tante cose che ruotano attorno a questo "nuovo" topic (seppure non sia per nulla una novità).


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    • Contrassegnato come risposta cicciux giovedì 1 ottobre 2015 12:15
    martedì 29 settembre 2015 15:41
    Moderatore

Tutte le risposte

  • ciao,

    di solito il database di test non dovrebbe essere preso e "attachato" in produzione. Di solito questi due sono ambienti completamente isolati e separati, e l'unica cosa che li accomuna è la struttura logica del database. Ma di certo i dati sono completamente diversi e la parte fisica di definizione della base dati è ottimizzata per la produzione, in produzione.

    Al di là di questo, personalmente utilizzo un source control per tutto il codice sorgente e per gli script di pubblicazione del database. Utilizzo poi dei tool di terze parti per fare la diff della struttura logica del database. In poche parole, si fa la differenza tra la situazione di sviluppo (o test, anche se utilizziamo la linea di deploy e non l'ambiente di test) e il database verso il quale andare a pubblicare. Tuttavia puoi evitare tool di terze parti. Puoi anche usare visual studio con i suoi progetti di tipo database. Se però non hai tutto questo, dovrai creare gli script di pubblicazione a mano (o provare uno dei tool che trovi su internet, purtroppo i migliori a pagamento) e andare a rilasciarli con tutti i crismi che servono per salvaguardare la tua produzione (backup, script di gestione con rollback, ecc.).

    Concludo:

    Se non vuoi comprare tool di terze parti (come quelli di Red Gate e ApexSQL che si installano DIRETTAMENTE su management studio, e quindi sono comodissimi se usi SSMS) penserei a Visual Studio per i database, in modo da autogenerare il pacchetto di deploy.

    Oppure, munirti di pazienza e generare ad ogni release le corrette differenze.

    Non seguirei nulla tra backup/restore, copy database, import ed export data, replica.. non sono gli strumenti per il delivery di un database.


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    mercoledì 23 settembre 2015 15:59
    Moderatore
  • Ciao,

    grazie per la risposta.

    Ricordo che esistevano i DTS ( anche se li ho usati poco) per fare operazioni simili come prodotto nativo di casa Microsoft, ma se non ho capito male non esistono piu?!?!

    In effetti ho usato qualche volta il progetto DB in Visual Studio e sono una buona soluzione, ma non ho ho capito bene come faccio a importare solo le tabelle che mi interessano dal DB SQL SERVER e come faccio a gestire il travaso dei dati .. ma mi documentero.

    Grazie ancora per le indicazioni.

    ciao ciao

    lunedì 28 settembre 2015 13:17
  • I DTS sono morti per MS con la versione 2000 di SQL Server, quindi vivono solo per gli utenti finali ancora fedeli alla piattaforma SQL Server 2000. Il nuovo strumento che, non solo li sostituisce, ma che li ha potenziati e migliorati all'ennesima potenza è denominato Integration Services (troverai anche la dicitura SSIS). La curva di apprendimento non è piccola, ma puoi provarlo, è molto valido.

    I dati di solito sono suddivisi in due grandi categorie, dati utente che cambiano costantemente nel tempo e dati utente ma statici (come le tabelle per le foreign key, le lookup, i valori di dominio e configurazione, ecc.). Mentre per la prima categoria, si può dire che la produzione ha la sua vita (e guai a chi la tocca), per la categoria dei dati statici il problema è annoso. Ci sono strumenti che ti consentono di tenere sotto controllo del codice sorgente (ma devi averne uno, come VSO, TFS, Git, Mercurial, ecc.) i dati statici, appunto, e poi di poterli rilasciare in totale sicurezza ed isolamento nei confronti dei dati utente "intoccabili".

    In mancanza di strumenti di terze parti, purtroppo, con Visual Studio, puoi pensare ad una fase di Pre deploy e Post deploy, nella quale andare a creare uno script di "pubblicazione" di tutti i dati statici di cui necessita la tua applicazione/database.

    Ma è un argomento enorme da approfondire. Pensa che negli ultimi anni sto cercando di parlarne agli eventi proprio per sensibilizzare alcune aziende alla problematica, troppo spesso rinviata in passato. Ci sono corsi, ruoli professionali, tante cose che ruotano attorno a questo "nuovo" topic (seppure non sia per nulla una novità).


    Alessandro Alpi - SQL Server MVP CTO at Engage IT Services S.r.l.

    • Contrassegnato come risposta cicciux giovedì 1 ottobre 2015 12:15
    martedì 29 settembre 2015 15:41
    Moderatore