Indici

Un ottimo articolo pubblicato su Simple Talk che entra nel dettaglio delle statistiche di distribuzione dei dati usate da SQL Server per la generazione dei piani di esecuzione:

http://www.simple-talk.com/sql/t-sql-programming/13-things-you-should-know-about-statistics-and-the-query-optimizer/

Le Dynamic Management Views and Functions recentemente introdotte in SQL Server 2005 forniscono informazioni sullo stato di salute di un’istanza SQL Server. Permettono di diagnosticare i problemi e di verificare se le performance possono essere migliorate, rappresentano uno strumento utilissimo per chi svolge le attività di database administrator e database developer.

Possiamo suddividere le DMV’s in due tipi:

• Server-level

• Database-level

Per interrogare una dynamic management view o una dynamic management function è necessario disporre del permesso di SELECT (sugli oggetti) in aggiunta ai permessi VIEW SERVER STATE e VIEW DATABASE STATE rispettivamente per consultare le DMV’s a livello server e a livello database.

Le tabelle temporanee vengono tipicamente (e largamente) utilizzate per salvare dati e risultati intermedi durante un’elaborazione. In aggiunta, una volta terminata l’elaborazione, i risultati possono essere presentati all’utente attraverso una tabella temporanea. SQL Server fornisce la possibilità di utilizzare due tipi di tabelle temporanee, tutte memorizzate nel database di sistema tempdb:

• Local temporary tables
• Global temporary tables

Le local temporary tables sono visibili solo dall’utente che le ha create e solo all’interno della stessa connessione, vengono eliminate automaticamente da SQL Server quando l’utente si disconnette.

Whitepaper che dettaglia come SQL Server 2008 crea ed utilizza le statistiche di distribuzione dei dati per generare piani di esecuzione ottimali:

http://msdn.microsoft.com/en-us/library/dd535534.aspx

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.

Consideriamo, ad esempio, un indice standard definito su due colonne di una tabella (col_1 e col_2), l’ultimo livello (foglia) contiene la combinazione dei valori presenti nelle due colonne. Diversamente, se specifichiamo un criterio nella clausola WHERE del comando CREATE INDEX, per selezionare solo alcuni valori di una colonna, (ad esempio col_1 > 10) le righe che non soddisfano il criterio verranno ignorate, proprio durante la costruzione dell’indice, a prescindere dal valore contenuto nella seconda colonna. Il risultato è una struttura B-Tree più piccola in cui l’ultimo livello (foglia) contiene soltanto i dati che verificano il criterio specificato. 

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.

;WITH tIndex AS (
SELECT    object_id AS id ,    index_id AS indid ,    type,     name ,    (        SELECT            colid as colPosition        FROM sys.sysindexkeys        WHERE id = I.object_id AND indid = I.index_id            AND keyno > 0        FOR XML PATH      ) AS cols ,    (        SELECT includedCol FROM        (            SELECT                CASE keyno WHEN 0 THEN colid ELSE NULL END AS includedCol            FROM sys.sysindexkeys            WHERE id = I.object_id AND indid = I.index_id        ) T0        order by includedCol        FOR XML PATH    ) AS inc
FROM sys.indexes AS I )
SELECT    object_schema_name ( T1.id ) + ‘.’ + object_name ( T1.id ) as tableName,    T1.name AS indexName,    T2.name AS duplicateIndex,    S.used_page_count * 8 indexSizeKB
FROM tIndex AS T1
JOIN tIndex AS T2 ON     T1.type = T2.type AND    T1.id = T2.id AND     T1.indid < T2.indid AND    T1.cols = T2.cols AND    T1.inc = T2.inc
JOIN sys.dm_db_partition_stats  AS S ON    S.[object_id] = T2.id AND S.index_id = T2.indId
ORDER BY object_schema_name ( T1.id ) + ‘.’ + object_name ( T1.id ), T1.name
go

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.

use [AdventureWorks] go

if object_id(‘usp_drop_double_more_index’) is not null   drop procedure dbo.usp_drop_double_more_index go

create procedure dbo.usp_drop_double_more_index (   @mode tinyint,   @object_name varchar(4000),   @table_type varchar(10),   @index_name_prefix_order varchar(8),   @debug tinyint ) as begin   /*     Descrizione:       Individua ed elimina i casi di doppia (tripla, ecc..)       indicizzazione sui 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.