Sergio Govoni

Quest Software, il 3 Marzo 2010, erogherà un training gratuito online per imparare ad utilizzare Dynamic Management Views and Function (DMVs) come strumenti per individuare e risolvere problemi, oltre che per migliorare le prestazioni di SQL Server.

Iscrizione e dettagli a questo link: http://www.vconferenceonline.com/shows/spring10/quest/register/multireg.asp

Nel precedente post Recursive CTE and Bill Of Materials problem abbiamo descritto una CTE ricorsiva nel tentativo di risolvere un problema del mondo reale, ovvero l’esplosione scalare a tutti i livelli della distinta materiali di un prodotto fornito in input.

Prima di realizzare la CTE ricorsiva CTE_BillOfMaterials abbiamo ipotizzato che le distinte materiali memorizzate nelle tabelle Production.BillOfMaterialsHeader e Production.BillOfMaterialsDetail avessero tutte una struttura ad albero aciclica (come è nella realtà). Alcune volte, le ipotesti più credibili non vengono verificate sui dati in produzione, ed è stato così, si è semplicemente assunto che l’ipotesi fosse vera. Durante il deploy della CTE, però, ci siamo accorti che questa ipotesi non era verificata per tutte le distinte memorizzate. Accadeva, di tanto in tanto, che gli utenti lamentassero un errore durante il tentativo di esplodere la distinta di un prodotto. Il seguente errore, che si verificava solo per alcuni prodotti, poteva essere il sintomo di un problema nei dati:

CTE, dalla versione 2005 di SQL Server, è l’acronimo di Common Table Expression. Una Table Expression è una tabella derivata, completamente virtuale, originata da una query. Una tabella derivata può essere citata nella clausola FROM come una qualsiasi altra tabella fisica. La visibilità di una tabella derivata è limitata alla query esterna della CTE.

SQLWorkShop ha reso disponibili, per il download gratuito, nuovi webcast.

Questa nuova serie (di tre webcast), spiega come ottimizzare le query in modo che possano scalare su più CPU.

Download disponibile a partire da questo link: http://webcasts.sqlworkshops.com/webcasts.asp

L’articolo Monitoring free space in tempdb transaction log spiega come monitorare lo spazio libero nel transaction log del database di sistema tempdb.

Una delle ragioni che ci spinge a monitorare lo spazio libero sul T-Log è la ricerca delle query che durante la loro esecuzione consumano eccessive risorse.

Il capitolo uno del libro Inside Microsoft SQL Server 2008: T-SQL Querying di Itzik Ben-Gan è davvero ricco di contenuti e dopo aver parlato di uno degli aspetti singolari (che caratterizza il linguaggio SQL) nell’articolo Logical Query Processing, parleremo ora di un altro aspetto altrettanto singolare: I possibili valori che ci possiamo aspettare, in SQL, come risultato della valutazione logica di un’espressione.

Prendendo l’ispirazione dal primo capitolo del libro Inside Microsoft SQL Server 2008: T-SQL Querying di Itzik Ben-Gan, in questo articolo parleremo delle fasi che entrano in gioco durante l’esecuzione logica di una query ed in particolare analizzeremo l’ordine con cui vengono eseguite.

In molti linguaggi di programmazione, il codice viene processato nell’ordine in cui è stato scritto. Potremmo pensare quindi, che in una query, la clausola SELECT sia la prima ad essere processata, ma in realtà non è così. In SQL, la prima clausola ad essere processata è la clausola FROM, mentre la SELECT verrà processata successivamente, moto più tardi.