SQLServerITA

SQL Server e non solo

  • dicembre: 2017
    L M M G V S D
    « Set    
     123
    45678910
    11121314151617
    18192021222324
    25262728293031
  • Blog Stats

    • 17,242 hits
  • Inserisci il tuo indirizzo e-mail per iscriverti a questo blog e ricevere notifiche di nuovi messaggi per e-mail.

    Segui assieme ad altri 6 follower

Archive for the ‘SQL+Server’ Category

The History of SQL Server

Posted by belthazor78 su 28 febbraio 2012


Tutta la storia di SQL Server, dagli inizi nel lontano 1989 ai prossimi giorni del 2012 quando verrà presentata la nuova versione di SQL Server.
Gustatevi il video di questa bellissima storia 😀

http://www.youtube.com/watch?v=fSN2ihUkSCk

Annunci

Posted in SQL+Server, SQL+Server+2012 | Leave a Comment »

SQL Server Migration Assistant (SSMA) v.5.2

Posted by belthazor78 su 7 febbraio 2012


Un tool importante, un tool molto utile per chi deve affrontare una migrazione da un database non SQL Server a uno, ovviamente, di casa Microsoft. Maggiore potenzialità e dei report molto più dettagliati. Da ricordare come strumento indispensabile, ma non da solo, per effettuare una migrazione con più tranquillità.

Ecco il link per maggiori info: http://blogs.msdn.com/b/dataaccesstechnologies/archive/2012/02/07/announcing-sql-server-migration-assistant-ssma-v-5-2.aspx

 

Posted in SQL+Server | Leave a Comment »

Single VS Multiple Database: i Pro

Posted by belthazor78 su 2 febbraio 2012


Supponiamo di dover tenere circa 3 copie di una stessa struttura dati e ognuna di queste copie ha le sue funzionalità: chi una sorta di snapshot, chi i dati da rendere utilizzabili da report e chi per attività giornaliere per un applicativo web. Tutti con gli stessi identici dati ma con scopi differenti.

Abbiamo due opzioni: ho tre schema all’interno di un Database oppure tre Database distinti sulla stessa istanza SQL Server (separarli fisicamente vorrebbe dire creare o intrudurre problemi di rete che non vorrei avere).

Mi è stato chiesto di fare un piccolo elenco di quelli che potrebbero essere i vantaggi nell’avere tre database distinti anzichè tre schema nello stesso DB.

Vediamo alcuni che sono riuscito ad individuare senza fare troppe ricerche.

1- Maggiore controllo sulla sicurezza degli oggetti del DB e maggiore separazione logica dei dati. In caso di compromissione di sicurezza su un DB gli altri sono più al sicuro. (ipoteticamente ogni DB dovrebbe avere la sua specifica sicurezza in base alla sua funzionalità)

2- Maggiore praticità nella gestione dei backup e loro politche: poter eseguire dei backup separati può, in alcuni casi, risultare molto più pratico. Eseguire il backup di un DB unico da 90GB anzichè tre da 30GB garantisce una flessibilità maggiore.

3- Maggiore praticità nella gestione del RECOVERY MODEL (se praticabile).

Supponiamo che di avere tre schema o tre database e solo uno in realtà richiede in recovery model a FULL (con tutte le criticità del caso…gestione backup full, differenziali, backup dei tlog etc…etc…).

Se abbiamo 3 schema dobbiamo per forza applicare il RECOVERY MODEL a FULL su tutto il DB. In caso di 3 DB separati, il RECOVERY MODEL a FULL potrebbe essere applicato solo al DB più importante mentre agli altri due si potrebbe scegliere un RECOVERY MODEL a SIMPLE.

4- Maggiore praticità nella gestione degli aggiornamenti degli indici e statistiche; tali operazioni sono,  o possono essere, molto onerose in termini di tempi e occupazione del DB. Si potrebbe prevedere, ad esempio, di gestire gli aggiornamenti indici e statistiche in tempi diversi tra i database in modo molto più semplice che nell’utilizzare un unico database.

Anche con con schema separati il discorso è quasi identico: è vero che si può separare a livello schema ma deve essere gestito con maggiore attenzione.

5- Maggiore flessibilità in caso di database corrotti o offline: se tutti i dati stanno su un DB e questo  si corrompe o rimane offline per qualsiasi motivo, tutti i dati rimarranno offline.

Se i dati si trovano  su db diversi il rischio di rimanere senza dati diminuisce.

6- Maggiore flessibilità a sviluppi futuri: si può, in futuro, poter adottare alcune tencologie senza dover intaccare la struttura di un solo database. Supponiamo di dover gestire una Replica o un Mirroring e di doverli applicare solo per alcuni dati.

Avendo 3 database differenti tali operazioni saranno meno invasive.

7- Maggiore flessibilità nel maintenance: in fase di restore di un database (per qualsiasi motivo) si avrà  offline solo quel database mentre gli altri database possono rimanere online senza impatti sulla  usabilità delle applicazioni.

Stesso discorso nella tempistica, ovviamente, di un restore: effettuare il  restore di un singolo DB costa molto meno in termini di tempo CPU e I/O che effettuare il restore di un unico DB (perchè i GB sono “spezzati” su più DB).

8- Magggiore flessibilità, in futuro e se necessario, nella separazione anche fisica a livello di dischi dei database separando i file dati e tlog dei singoli database su dischi differenti.

In fase di test avere dei database differenti contenenti le stesse tabelle può risultare più comoda la  gestione dei test e maggiore sicurezza del passaggio da un database all’altro. Supponiamo di avere una tabella chiamata CAP e di questa dobbiamo avere tre copie: Final, Working e Report.

Supponiamo di avere, per implementare questa tabella, sia un singolo DB che tre database distinti.

Avendo un solo DB e dovendo avere la tabella suddivisa in tre siamo “costretti” ad utilizzare uno schema; le eventuali query di lettura, ad esempio, dovranno essere come segue [NomeSchema.Tabella]:

SELECT * FROM Final.CAP
SELECT * FROM Report.CAP
SELECT * FROM Working.CAP

E’ evidente che in fase di test dovrò crearmi e testare 3 stored diverse tra di loro.

Ora, supponiamo, di dover implementare la stessa cosa ma con tre database differenti:
SELECT * FROM dbo.CAP (non bisognerà cambiare nulla perchè la tabella si troverà fisicamente su 3 database differenti). In questo modo non bisogna dover cambiare la query. Portando tale esempio con query molto più complesse con svariate JOIN il fatto di avere tre DB è evidente.

Direi che ci sono dei bei vantaggi, ma solo in caso in cui i tre database o schema devono presentare sia la stessa struttura che gli stessi identici dati.

 

Posted in SQL+Server | Leave a Comment »

SQL Server 2008 R2: l’intellisense del SSMS non funziona

Posted by belthazor78 su 19 gennaio 2012


Ad un certo punto mi sono ritrovato con il SQL Server Management Studio con l’intellisense fuori uso…eppure era abilitato correttamente da interfaccia:

Girovagando su internet ho constatato che aggiornando Visual Studio 2010 all’ultima Service Pack è un problema che può capitare. La soluzione più veloce, se non comodissima, è stata quella di reinstallare la SP1 di SQL Server 2008 R2 (e non di Visual Studio) e magicamente l’intellisense è tornato operativo!

😀

Qui http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26727 il link per la SP1 di SQL 2008 R2

Posted in SQL+Server, SQL+Server+2008+R2 | Leave a Comment »

SQL Server performance quick tips: TABLOCK

Posted by belthazor78 su 15 gennaio 2012


Un piccolo post a cui ne seguiranno degli altri riguardo a piccoli consigli da applicare ad una vostra query per migliorarne le performance. Non parlerò, come vedrete, dei soliti indici e statistiche (quelli già devono esserci e devono essere già deframmentati e aggiornati) e il database engine preso in considerazione è il 2008 R2.

Supponiamo di avere una semplice query che copia dei dati prelevati da più tabelle su un’unica tabella con un volume di dati pari a 5 milioni di righe.

L’esecuzione delle query allo stato “normale” richiede circa 4 minuti e 32 secondi. Un tempo considerevole anche se la query è stata eseguita su un computer abbastanza lento ma un “moving” di 5 milioni di righe da 4 tabelle in join con 15 milioni di dati su un’altra tabella dovrebbe essere un pò più veloce.

La query preleva e sposta circa 30 colonne di vario tipo e, in linea di massima, è come la seguente:

Ovviamente non ho potuto mettere tutti i campi con i loro reali nomi per sicurezza, ma la sostanza non cambia.

Ora, aggiungendo un semplice HINT come il WITH (TABLOCK) al comando di INSERT (quindi alla tabella dove dovranno essere inseriti i dati) le performance ne hanno risentito in positivo.

In pratica trasformando il comando INSERT INTO CIVICI… in INSERT INTO CIVICI WITH (TABLOCK)… ecco il risultato:

3 minuti e 20 secondi, cioè circa 1 minuto e 10 secondi più veloce con un semplice HINT aggiunto alla query senza dover modificare a livello di database alcun dato.

Un bel risparmio ovviamente, ma c’è da pagare qualche cosa in termini di usabilità della tabella in cui inseriamo i dati; l’Hint “WITH (TABLOCK)” infatti, crea un blocco totale della tabella di tipo “shared” in cui stiamo per copiare dei dati e questo ovviamente facilita gli inserimenti dei dati ma allo stesso tempo blocca eventuali operazioni di altre transazioni su quella tabella.

Maggior info per gli hint: http://msdn.microsoft.com/en-us/library/ms187373.aspx

Nelle prossime “puntate” vi descriverò altri piccole tips da applicare per poter ridurre i tempi di esecuzione di una query.

Posted in SQL+Server | Contrassegnato da tag: , , | Leave a Comment »

SQL Server 2012 Virtual Labs

Posted by belthazor78 su 9 gennaio 2012


Una raccolta di tanto virtual labs anche per SQL Server 2012 che vi permetteranno di vedere le prime novità più importanti di SQL Server oltre ad altri concetti, senza dover installare nulla sul vostro pc (bisogna scaricare solo un piccolo eseguibile da eseguire con IE)

Ecco il link http://www.microsoft.com/sqlserver/en/us/learning-center/virtual-labs.aspx

Posted in SQL+Server, SQL+Server+2012 | Contrassegnato da tag: , , | Leave a Comment »

SQL Server: i backup bloccano i database?

Posted by belthazor78 su 23 novembre 2011


Molte volte capita che un backup notturno fallisca per vari motivi e che si sia costretti ad eseguire il backup anche durante il giorno o comunque durante le ore più stressanti per SQL Server. Molti credono che i backup possano bloccare un intero database durante l’esecuzione degli stessi.

In realtà non è così.

Quello che capita durante l’esecuzione di un backup è la grande quantità di I/O che viene effettuata e che può indurre a pensare che un database e l’accesso allo stesso sia rallentato o quasi bloccato.

I backup sono una parte essenziale della vita di un database e alcune volte è preferibile perdere qualche cosa in performance ma avere la garanzia di poter recuperare i dati in caso di problemi.

Posted in SQL+Server | Contrassegnato da tag: | Leave a Comment »

SQL Server: DBCC FLUSHPROCINDB

Posted by belthazor78 su 17 novembre 2011


Durante le fasi di test di una procedura è necessario eseguire il comando DBCC FREEPROCCACHE che libera la cache dei piani di esecuzione delle query. Questo implica la ricompilazione di tutte le query.

Il comando, come è facile da intuire, può creare inizialmente grossi problemi di performance. Quando questo comando viene eseguito su una intera istanza SQL Server ecco che gli impatti negativi si risentono su tutti i database.

C’è però un altro comando DBCC FLUSHPROCINDB che permette di svuotare la cache dei piani di esecuzione ma di un singolo database.

DECLARE @intDBID INTEGER
SET @intDBID = (SELECT dbid FROM master.dbo.sysdatabases WHERE name = ‘NomeDB’)
DBCC FLUSHPROCINDB (@intDBID)

Semplice e facile da usare con minor problemi di performance rispetto al comando FREEPROCCACHE

Posted in SQL+Server | Contrassegnato da tag: , , | Leave a Comment »

Free eBook: Inside the SQL Server Query Optimizer

Posted by belthazor78 su 16 novembre 2011


Ottimo libro gratuiuto su uno dei “componenti” più importanti di SQL Server: l’elemento che decide come effettuare una query nel modo più ottimale possibile in termini di velocità/risorse e cioè il Query Optimizer.

Link: http://community.ugiss.org/blogs/sgovoni/archive/2011/11/13/free-ebook-inside-the-sql-server-query-optimizer.aspx

Posted in SQL+Server | Contrassegnato da tag: | Leave a Comment »

SQL Release timelines

Posted by belthazor78 su 14 novembre 2011


Piccola ma importante immagine che ci illustra un pò la storia delle versioni di SQL Server e di SQL Azure. Molto interessante 😀

Posted in SQL+Azure, SQL+Server | Contrassegnato da tag: , | Leave a Comment »