Con SQL Server 2008 fanno il loro debutto gli indici e le statistiche filtrare; sono le strutture che conosciamo già, a cui però viene applicato un criterio di filtro. In questo articolo parleremo degli indici filtrati cercando di capire quando la loro applicazione può migliorare le performance delle query.
Il comando CREATE INDEX può ora accettare la clausola WHERE utilizzata per specificare il criterio di filtro.
L’annuale summit del PASS - Professional Association of SQL Server users, si terrà ancora una volta a Seattle. Il summit è la più importante conferenza su SQL Server a livello mondiale, alla quale partecipano solamente i migliori speaker, offrendo un’opportunità di formazione e di networking assolutamente unica.
Con 168 sessioni suddivise in 5 track - Database Administration, Database and Application Development, BI Platform Architecture, BI Information Delivery, and Professional Development - questa conferenza è indispensabile per tutti coloro che vogliono migliorare e rendere più efficiente il proprio lavoro con SQL Server e tutte le tecnologie ad esso legate, capire in che modo si evolverà il futuro con la release della versione R2, fare networking per espandere la proprio rete di conoscenze e - perchè no - passare una settimana di full-immersion in una città sempre bella come Seattle.
Qual è il rischio in cui si può incorrere quando un progetto viene sviluppato da più persone, ovvero quando un database viene modellato da più mani?
Creare un indice che esiste già! :-(
SQL Server non fa nulla per venirci in aiuto o, almeno, non fa nulla in automatico.
Con questo script è possibile ottenere una lista degli indici identici / duplicati.
Possiamo facilmente immaginare l’inefficienza introdotta dalla doppia indicizzazione (ugualmente ordinata) di un attributo: SQL Server dovrà mantenere aggiornati due indici, organizzati in strutture B-Tree letteralmente identiche, senza trarre alcun beneficio da una delle due.
La stored procedure dbo.usp_drop_double_more_index, definita di seguito, permette di individuare ed eliminare i casi di doppia (tripla, ecc…) indicizzazione dei medesimi attributi.
Come posso conoscere la data e l’ora dell’ultimo UPDATE eseguito su una tabella da parte di un utente ?
Una delle DMVs (Index Related Dynamic Management Views and Functions), disponibili dalla versione 2005 di SQL Server, ci permette di rispondere a questa domanda.
Possiamo infatti utilizzare la DMV sys.dm_db_index_usage_stats che con i sui differenti contatori, basati sulle operazioni eseguite sugli indici, ci permette di conoscere, ad esempio, la data e l’ora dell’ultimo comando UPDATE eseguito su una determinata tabella.
Una relazione tra le tabelle di un database è espressa nei valori dei dati attraverso una chiave primaria (Primary Key) ed una chiave esterna (Foreign Key).
La chiave primaria è rappresenta da una o più colonne di una tabella i cui valori identificano in modo univoco ogni riga della tabella stessa. La chiave esterna è rappresenta da una o più colonne i cui valori sono gli stessi della chiave primaria.
Link al post omonimo del SQL CAT, fondamentale per tutti coloro che vogliono o devono implementare una soluzione basata sul Full Text Search di SQL Server 2008:
