Dipendenze oggetti/script Sql Server
Fabrizio Ramponi
database.
Magari da integrare con un server SVN.
So che si trova già qualcosa di pronto, ma volevo provarci a fare
qualcosa da solo (sto trafficando da poco con PowerShell e Sql SMO).
Qualcuno ha consigli su letture o altro.
In particolare mi interesserebbe sapere come gestire le dipendenze tra
i vari script in automatico.
Finché scripti tutto il DB in un unico file la cosa è risolta perché
lo scripter in teoria dovrebbe mettere i vari frammenti di codice
nell'ordine giusto, ma se suddividi il DB in più file (uno per ogni
oggetto) poi come ad avere l'ordine giusto di esecuzione.
In passato ho creato gli script di alcuni miei DB con Management
Studio usando l'opzione "usa più file" ma poi ho perso un sacco di
tempo nel fare il batch di lancio che eseguisse gli script nell'ordine
giusto a soddisfare le dipendenze.
E meno male che erano DB non troppo grossi e fatti da me (ossia
conoscevo già le dipendenze), se erano DB
grossi e per me sconosciuti c'era da impazzire.
Ciao
Andrea Montanari
Fabrizio Ramponi wrote:
> Stavo cercando di fare un sistema di scripting e versioning dei
> database.
> Magari da integrare con un server SVN.
>
> qualcosa da solo (sto trafficando da poco con PowerShell e Sql SMO).
>
> Qualcuno ha consigli su letture o altro.
> In particolare mi interesserebbe sapere come gestire le dipendenze tra
> i vari script in automatico.
> lo scripter in teoria dovrebbe mettere i vari frammenti di codice
> oggetto) poi come ad avere l'ordine giusto di esecuzione.
>
> In passato ho creato gli script di alcuni miei DB con Management
> tempo nel fare il batch di lancio che eseguisse gli script nell'ordine
> giusto a soddisfare le dipendenze.
> E meno male che erano DB non troppo grossi e fatti da me (ossia
> grossi e per me sconosciuti c'era da impazzire.
>
l'ordine non e' mai "molto garantito", in quanto ancora non "abbiamo" una
vera e valida risorsa in tal senso.. pare che cio' cambiera' in futuro, ma
l'ho sentito dire molto spesso...
personalmente mi sono quindi abituato a separare completamente le
dipendenze.. nel senso che prima ottengo lo script degli oggetti primari e
solo alla fine ottengo, ad esempio, gli script delle problematiche chiavi di
integrita' referenziale.. magari le metto anche in un file completamente
separato..
per procedure e quant'altro siamo "supportati" da una bruttura in questo
caso funzionale, la deferred name resolution, cosi' che una procedura puo'
referenziare al momento del suo salvataggio anche oggetti non ancora
presenti.. viene sollevato un warning ma nulla di piu'...
sulla base di queste esisgenze ho scritto amScript, uno strumento
(liberamente scaricabile ed utilizzabile) basato su SMO, disponibile presso
il mio sito in calce.. e' abbastanza parametrizzabile.. saluti
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz
DbaMgr2k ver 0.21.1 - DbaMgr ver 0.65.1 and further SQL Tools
http://www.hotelsole.com - http://www.hotelsolericcione.de
--------- remove DMO to reply
Fabrizio Ramponi
wrote:
> l'ordine non e' mai "molto garantito", in quanto ancora non "abbiamo" una
> vera e valida risorsa in tal senso.. pare che cio' cambiera' in futuro, ma
> l'ho sentito dire molto spesso...
> personalmente mi sono quindi abituato a separare completamente le
> dipendenze.. nel senso che prima ottengo lo script degli oggetti primari e
> solo alla fine ottengo, ad esempio, gli script delle problematiche chiavi di
> integrita' referenziale.. magari le metto anche in un file completamente
> separato..
> per procedure e quant'altro siamo "supportati" da una bruttura in questo
> caso funzionale, la deferred name resolution, cosi' che una procedura puo'
> referenziare al momento del suo salvataggio anche oggetti non ancora
> presenti.. viene sollevato un warning ma nulla di piu'...
> sulla base di queste esisgenze ho scritto amScript, uno strumento
> (liberamente scaricabile ed utilizzabile) basato su SMO, disponibile presso
> il mio sito in calce.. e' abbastanza parametrizzabile.. saluti
> --
> Andrea Montanari (Microsoft MVP - SQL Server)http://www.asql.biz
>
Io conoscevo i tool :
da linea di comando
ScriptDB: http://scriptdb.codeplex.com/
o con interfaccia grafica
ScriptIO: http://scriptio.codeplex.com/
ma con entrambi ho avuto dei problemi (più che altro di autorizzazioni
DotNet, di cui sono poco pratico) ed allora mi sono messo a provare a
fare qualcosa io (sia per apprendere meglio l'arte, sia per magari
customizzarlo meglio alle mie necessità).
Leggendo qui: http://www.codeproject.com/KB/database/SQLScripter.aspx
ho appreso che in teoria è pure possibile scoprire quali sono gli
oggetti cambiati dall'ultima volta e scriptare solo quelli (utile
quando fai versioning di grossi DB e non vuoi fare gli script
dell'intero DB per poi scoprire che solo 2 o 3 procedure sono
cambiata).
Il link non cita purtroppo come (ed io non essendo registrato sul sito
non ho potuto prendere i sorgenti per esaminarli), ma immagino che ci
siano delle proprietà di sistema di Sql Server che dicano quando un
oggetto è stato alterato nella struttura.
Cmq ho provato a scaricare anche il tuo sw, ma purtroppo ho scoperto
che richiede DotNet 3.5 ed io sto usando per ora (anche se presto
probabil. finalmente migrerò) ancora un vecchio Windows 2000 Prof.
Sono riuscito a forzargli su una powershell 1.0 ma dubito che riuscirò
mai a installare DotNet 3.5 su di esso :) e naturalmente il tuo sw va
subito in exception appena provo ad usarlo.
Ciao
dawn
> Cmq ho provato a scaricare anche il tuo sw, ma purtroppo ho scoperto
> che richiede DotNet 3.5 ed io sto usando per ora [...]ancora un vecchio Windows 2000 Prof.
Che legame c'è tra il framework e il SO?
> [...] ma dubito che riuscirò mai a installare DotNet 3.5 su di esso :)
Proverei...
Lorenzo Benaglia
> Che legame c'� tra il framework e il SO?
http://www.microsoft.com/downloads/details.aspx?FamilyID=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en
Supported Operating Systems: Windows Server 2003; Windows Server 2008;
Windows Vista; Windows XP
> Proverei...
Non si installerebbe su Windows 2000 :-)
Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo
http://social.microsoft.com/Forums/it-IT/sqlserverit
Fabrizio Ramponi
MS ha deciso (dal 2006/7 in poi circa) di spingere sulla morte
anticipata di Windows 2000 (Prof. e Server) evitando di rilasciare i
suoi nuovi prodotti anche per quell'OS ed in questo modo ha fatto
indirettamente pressioni per l'upgrade a minimo WIndows XP (o 2003
Server).
Noi però abbiamo clienti che ancora nel 2009 installano Windows 2000
Server su macchine nuove :-), perché hanno sw (pagati cari) che sono
certificati solo su 2000 e non vogliono rogne a scoprire se vanno su
2003 (o 2008) server, ne pagare i costi di licenza delle nuove
versioni certificate almeno 2003 server.
Di conseguenza poi noi dobbiamo scegliere tecnologie che girino sui
server dei clienti (o aggiungere un ulteriore server ns, se i costi lo
permettono).
Io stesso ho una macchina di sviluppo basata su 2000 Prof. ma qui non
per motivi di sw da usare, ma solo per pigrizia di non trovare mai il
tempo/voglia di rifarla ex-novo con un OS più recente (inizialmente
pensavo XP64, ma poi ho deciso di aspettare Seven saltando Vista)
Non ricordo Office 2007, ma tutti i prodotti MS targati con sigla 2008
NON vanno su OS Win 2000 (ergo è lo stesso per Sql 2008).
Windows 2000 è stato relegato a max Sql Server 2005 (ma va già più che
bene), max Visual Studio 2005, max DotNet 2.0 (per Office non saprei,
la 2003 va, la 2007 non ho mai verificato).
Anche PowerShell 1.0 NON è installabile su Windows 2000, ma essendo
basata solo su DotNet 2.0, il limite di installazione è più
commerciale che tecnico.
Infatti seguendo questa guida: http://ntldr.com/2008/07/26/WindowsPowerShellOnWindows2000.aspx
(e facendo qualche cambiamento agli script per l'uso sui Path di un OS
Italiano) si riesce ad installarla senza problemi.
Poi magari non tutte le funzionalità sono al 100% operative (perché
magari su 2000 mancano delle DLL di serie invece da XP in su), ma
FUNZIONA e torna davvero utile averla.
Invece installare DotNet 3.0 o 3.5 su Windows 2000 è un lavoro che
richiederebbe conoscenze troppo approfondite di Win 2000 e dei moduli
DotNet 3.x per fare tutto a mano e che probabilmente alla fine non
funzionerebbe lo stesso (basta che DotNet 3.x usi chiamate a funzioni
di sistema che nelle DLL di 2000 non ci sono e sei fregato)
dawn
> MS ha deciso (dal 2006/7 in poi circa) di spingere sulla morte
> anticipata di Windows 2000 (Prof. e Server) evitando di rilasciare i
> suoi nuovi prodotti anche per quell'OS ed in questo modo ha fatto
> indirettamente pressioni per l'upgrade a minimo WIndows XP (o 2003
> Server).
Capito e non lo sapevo proprio... Scusate l'aria di superiorità ;)
p.s. Seven x64 sul portatile mi ha cambiato la vita!
Fabrizio Ramponi
> Io conoscevo i tool :
>
> da linea di comando
> ScriptDB:http://scriptdb.codeplex.com/
>
> o con interfaccia grafica
> ScriptIO:http://scriptio.codeplex.com/
>
> ma con entrambi ho avuto dei problemi (più che altro di autorizzazioni
> DotNet, di cui sono poco pratico) ed allora mi sono messo a provare a
> fare qualcosa io (sia per apprendere meglio l'arte, sia per magari
> customizzarlo meglio alle mie necessità).
Ho risolto i miei problemi con i 2 tool citati.
Colpa mia che non sapevo che una applicazione DotNet non può essere
lanciata (senza modificare certe Security Options) da una cartella di
rete.
Copiati i tool in un disco locale e funzionano (richiedono solo DotNet
2.0).
ScriptIO carino perché ha l'interfaccia grafica e permette la visione
dello script senza bisogno di creare file, però seleziona anche gli
oggetti di sistema (scomodo deselezionarli a mano quando vuoi
scriptare l'intero DB) e soffre degli stessi problemi di dipendenza di
Management Studio (quando usi più file).
Ossia se per esempio la tabella B ha un Foreign Key alla tabella A
quando farei gli script otterrai 2 file TableA.sql e TableB.sql e
nulla che di dice le dipendenze (o l'ordine di esecuzione).
Sarai tu che dovrai sapere (o lo devi scoprire per tentativi) che
devi eseguire prima TableB.sql e solo dopo TableA.sql
Con i DB grandi e molte relazioni diventa un delirio gestire la cosa.
Con ScriptDB invece il problema non si pone perché fa un file per ogni
oggetto principale o sottoggetto.
Quindi diventa semplice fare il rebuild del DB partendo dagli script
(e c'è pure un batch già pronto che lo fa), dato che non non si hanno
problemi con le dipendenze se si segue la sequenza statica:
1 - Esegui tutti i file con le definizioni di Tabelle
2 - Esegui tutti i file con le sequenze di INSERT dati (se tali file
ci sono)
3 - Esegui tutti i file con le definizioni di PKey o Indici
4 - Esegui tutti i file con le definizioni di Foreign Key (che ora non
falliranno dato che esistono già tutte le tabelle)
5 - Esegui tutti i file con le definizioni di Viste
6 - Esegui tutti i file con le definizioni di Assembly
7 - Esegui tutti i file con le definizioni di UDF
8 - Esegui tutti i file con le definizioni di Check Constraint (l'ho
messo qui nel caso qualche Check C. usi delle UDF)
9 - Esegui tutti i file con le definizioni di Stored Procedure
10 - Esegui tutti i file con le definizioni di Trigger
... altro (tipo i permessi)
Consiglio di prendere i sorgenti e farsi il Build (basta anche un C#
Express 2005) perché la versione compilata è del 2008 ed ha delle
feature in meno.
Per contro l'ultima versione ha un paio di bug nei sorgenti che io ho
già eliminato (e se fossi iscritto a CodePlex manderei il sorgente
modificato), nonché sto cercando di modificare per aggiungere alcune
feature tipo
* Una migliore gestione della connessione (invece di passare la
stringa connessione, passare i parametri e far fare a lui la stringa)
* Far funzionare BCP anche in caso di non uso di Trusted Connection
* Vedere se si può inserire una funzionalità tipo "Scripta solo gli
oggetti che risultano modificati dopo una certa data ed ora
Fabrizio Ramponi
> Consiglio di prendere i sorgenti e farsi il Build (basta anche un C#
> Express 2005) perché la versione compilata è del 2008 ed ha delle
> feature in meno.
> Per contro l'ultima versione ha un paio di bug nei sorgenti che io ho
> già eliminato (e se fossi iscritto a CodePlex manderei il sorgente
> modificato), nonché sto cercando di modificare per aggiungere alcune
> feature tipo
>
Purtroppo non posso fare il commit via SVN perché non faccio parte del
progetto, quindi ho mandato i miei sorgenti modificati come patch.
Se qualcuno del progetto li visionerà prima o poi, dubito a breve
visto che gli sviluppatori del progetto sono mesi che non si
collegano, magari saranno aggiunte nei sorgenti ufficiali.
Cmq per ottenere il tutto basta:
1) Scaricarsi gli ultimi sorgenti originali
2) Scaricarsi il mio archivio con i sorgenti modificati (http://
scriptdb.codeplex.com/SourceControl/PatchList.aspx) e sostituire i
file omonimi
3) Compilare il tutto (basta un C# 2005 Express)
Le mie modifiche riguardano:
* Eliminato dei bug presenti negli ultimi sorgenti (l'eseguibile
ottenuto compilando gli ultimi sorgenti non andava)
* Aggiunto un controllo per scriptare i dati solo se la tabella ha dei
record (prima faceva sempre un file, ovviamente vuoto per le tabelle
vuote)
* Riattivato lo scripting degli Assemblies (funzioni DotNet) che negli
ultimi sorgenti era stato spento (mentre in origine c'era)
* Migliorato il codice che gestisce l'esportazione dati tramite
BCP.exe, questa è la parte più debole del progetto che il
programmatore originale ha lasciato abbozzata e nessuno aveva mai
migliorato.
Io per ora mi sono limitato a correggere i bug che la rendevano
praticamente inutilizzabile, ed eliminando anche alcuni limiti (tipo
prima si poteva scriptare i dati solo se si era connessi con
connessione Trusted).
* Aggiunta una opzione per limitare lo scripting ai soli oggetti
modificati dopo una certa data/ora.
Questo permette di ottenere velocemente gli script delle sole
componenti cambiate (purtroppo non tutti gli oggetti espongono una
data di modifica e per gli oggetti che non lo fanno lo script viene
sempre fatto) e memorizzare solo i cambiamenti (versioning del DB) o
anche solo vedere cosa è cambiato sul DB (es. "qualcuno ha modificato
il DB negli ultimi 3gg, e se si cosa ha cambiato ?").
Certamente questa funzionalità la fa già SVN (che anche scriptando
tutto memorizzerebbe solo i file cambiati) ma su DB di una certa
dimensione (come strutture/codice) ci vuole un bel po' di tempo a
scriptare tutto e dover scriptare tutto ogni volta fa perdere troppo
tempo.
Attivando la mia opzione tutti gli oggetti non modificati vengono
saltati e la velocità di creazione script aumenta considerevolmente.