SQL Server e dintorni

Generare script per ricostruire la sequenza di ripristino

Qualche tempo fa ho pubblicato un post per ricostruire la sequenza di ripristino di un database sulla base dei backup eseguiti.

Quello script si basa sul presupposto che tutti i backup di uno stesso database si trovino all'interno dello stesso file/device. Il presupposto deriva da una mia abitudine che, proprio per non dover cercare tra n file dove sta il backup y eseguito dopo il backup x, prevede l'esecuzione dei backup di diverso tipo (full, differenziale e del t-log) in un unico file. In occasione del backup full provvedo a reinizializzare il device ma, ovviamente, salvaguardandomi quello precedente attraverso una attività di rename (non deve essere piacevole reinizializzare il device e accorgersi che qualcosa è andato storto durante il backup). Pertanto se anche voi preferite mantenere un unico file per ciascun database, oltre ovviamente ad eventuali set precedenti compatibilmente con lo spazio a disposizione, potreste utilizzare il mio script per risparmiare tempo prezioso in situazioni critiche.

Se invece preferite mantenere ogni backup su un file differente all'interno di una data cartella, ho trovato questo script che fa al caso vostro...

Bye

Generare script da un database

Qualche volta capita di voler generare degli script per riprodurre delle tabelle e/o il contenuto di esse. Se i database sono nella stessa lan è possibile, tramite il wizard Import/Export Data, ovvero tramite DTS/SSIS portare a termine l'attività, ma quando gli script devono essere salvati per essere eseguiti successivamente su un altro database, magari non connesso, potrebbe essere sconveniente dover portar via un backup per poi ripristinarlo e procedere al trasferimento dei dati con DTS/SSIS.

In questi casi può essere utile disporre di un tool in grado di generare gli script di inserimento dei dati partendo da una o più tabelle di origine. Ce ne sono diversi, si va da prodotti commerciali come questo di Red-Gate o quest'altro di ApexSQL a prodotti free come SQLScripter o altri.

Anche Andrea Montanari, l'autore dell'arcinoto DbaManager/DbaManager2k, ha fatto la sua parte creando 2 tools utilizzabili allo scopo. Si tratta di amScript e amInsert che possono essere utilizzati per generare, rispettivamente, gli script DDL e quelli DML per una tabella di un database. Entrambi possono essere scaricati da questo link.

Il valore aggiunto di amScript e amInsert è dato dal fatto che Andrea è notoriamente molto disponibile a ricevere feedback da parte degli utilizzatori dei suoi tools, quindi se ritenete che gli stessi possano essere arricchiti di nuove funzionalità fateglielo presente attraverso i mezzi che ritenete più opportuni, magari in occasione di un weekend a Riccione presso il suo Hotel (pubblicità per niente occulta)...

Bye

Errore 2570 e "data purity"

Eseguendo il comando DBCC CHECKDB con l'opzione WITH DATA_PURITY, ho evidenziato degli errori su un database; i messaggi erano una sfilza di errori 2570 come questo qui sotto

Si trattava di ben 126 eventi, tutti sulla stessa tabella, e tutti sul medesimo campo (in realtà erano 63 errori nelle pagine dati ed altrettanti in un indice non clustered dove il campo era nella clausola INCLUDE). Una ricerca nella kb mi portava a questo articolo che dava anche una soluzione per venire a capo del problema. Si trattava quindi di individuare, con una query, quali erano i record fuori dal range ammesso per il tipo dati in questione. Trattandosi di un campo definito come DECIMAL (11, 2), eseguivo l'istruzione

SELECT *
FROM dbo.Tabella
WHERE IMP_MOV_SIN > 999999999.99
    OR IMP_MOV_SIN < 999999999.99

come suggerito dall'articolo stesso. Questa query però non restituiva alcun record ed anche ci fosse stato qualche record "out-of-range" il problema successivo sarebbe stato quello di riportare il valore "in-range". Si, ma come...? Come avrei potuto scegliere arbitrariamente un valore per ciascuna delle 126 occorrenze dell'errore? Si sarebbe reso necessario comunque l'intervento dell'utente per bonificare tali dati con valori esatti e non solo congruenti.

Tuttavia se non c'erano valori "out-of-range" qualcosa doveva essere successo a quei 63 record, ma cosa? Beh, senza pensarci troppo ho fatto qualche tentativo nell'ambiente di test ampliando il datatype da un DECIMAL(11, 2) ad un DECIMAL(38, 20) per poi riportarlo a quello originario. Ho pensato che se il problema fosse dipeso dal fatto che qualcuno di quei 63 record avesse un numero "errato" di decimali avrei così sistemato il problema. Beh, la cosa ha funzionato!

Prove successive, ripristinando nuovamente il database corrotto nel solito ambiente di test, mi hanno fatto trovare una soluzione ancora migliore, ovvero quella di fare un update del genere

UPDATE dbo.Tabella
SET IMP_MOV_SIN = IMP_MOV_SIN * 1

ed anche questa soluzione avrebbe risolto il problema in maniera più efficace rispetto alla modifica del datatype (nel frattempo avevo già corretto con la prima soluzione l'ambiente di produzione).

Spero che possa tornare utile a qualcuno...

Bye

User Instance... la fine è vicina!

Come più volte ho avuto modo di ribadire, nei forum e newsgroup dedicati a SQL Server, avrei preferito che questa "funzionalità" (il virgolettato è d'obbligo) non fosse mai stata introdotta in SQL Server. Purtroppo, però, nella versione 2005 è stata introdotta la possibilità di utilizzare, solo nella versione Express, il motore relazionale come se fosse un database monoutente. Ma la cosa ancora peggiore in tutto questo è che qualcuno usa le User Instance, note anche come RANU (Run As Normal User)...

Pochi minuti fa l'amico Andrea mi ha segnalato questa pagina del BOL di SQL Server 2008 dove compare in bella evidenza la dicitura "Important: This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature."

Evidentemente qualcuno nel team di sviluppo si è reso conto che introdurre le User Instance in SQL Server 2005 ha prodotto più danni che benefici e se qualcuno mi porta un valido motivo per utilizzare le User Instance si faccia avanti... è lo stesso invito che rivolgo nei forum/newsgroup quando si parla di RANU ma finora nessuno è stato in grado di dare motivazioni valide (che è diverso dal dire "condivisibili").

Bye