I più importanti linguaggi di programmazione hanno strumenti di debug integrati direttamente nell’IDE. Il debugger ha tipicamente un’interfaccia grafica che consente di esaminare i valori che assumono le variabili durante l’esecuzione, il flusso del programma (step-by-step) e permette di definire punti di interruzione in corrispondenza dei quali fermare l’esecuzione del programma.
Può succedere di avere la necessità di sapere quale sia la tabella più grande (in termini di spazio occupato), nel database su cui si sta lavorando.
Ci sono diversi modi per rispondere a questa domanda, si potrebbe utilizzare il report standard Disk Usage by Top Table fornito da SQL Server Management Studio (SSMS) oppure, se si volesse effettuare l’operazione attraverso T-SQL, si potrebbe eseguire la stored procedure di sistema sp_spaceused per ogni tabella del DB, salvando tutti i risultati parziali in una tabella temporanea per poi ordinarli in funzione della colonna “reserved” o “data”.
Una degli ambiti principali delle consulenze che svolgo è quello di creare soluzioni per Data Warehouse e Business Intelligence ad alte performance. Ed una della cose che ancora, all’alba del 2016, mi trovo a dover affrontare e con la quale devo combattere tutti i giorni è un hardware…inadeguato.
Inadeguato per un Data Warehouse, chiaramente, dove macchine anche molto costose (leggi SAN) hanno delle performance assolutamente basse rispetto al costo che hanno (essendo il più delle volte ottimizzate per altri casi d’uso), e che quindi rendono l’utente finale solitamente molto poco contento.
I trigger sono spesso motivo di discordia tra sviluppatori e DBA, tra chi personalizza una soluzione standard e chi la fornisce, tra clienti e software vendor. Sono spesso i primi imputati quando le performance dell’istanza SQL Server o del database degradano. Sembrano facili da scrivere, ma scrivere trigger efficienti non è affatto semplice e quando la loro complessità aumenta, talvolta possono presentare effetti collaterali in grado di confondere persino l’autore.
Il quarto di una serie di articoli su trucchi, consigli, suggerimenti e best practices per scrivere e gestire in modo efficiente i Trigger DML in SQL Server:
SQL Server DML Triggers - Tips & Tricks - Part 4 (“Statements that each Trigger should have”)
Ricordate, un Trigger è ottimizzato quando la sua durata è breve!
Articolo in due parti di Itzik Ben-Gan che analizza in dettaglio diverse tecniche per identificare sequenze all’interno di altre sequenze in T-SQL.
Microsoft Virtual Accademy ha pubblicato un bel webcast fatto da Itzik Ben-Gan dedicato all’uso dell’operatore APPLY, estremamente potente e tipicamente poco utilizzato. Di seguito il link:
“Boost Your T-SQL with the APPLY Operator”
Need creative solutions to T-SQL issues? Get them from Itzik Ben-Gan, one of the world’s foremost authorities, along with Microsoft Program Manager Umachandar Jayachandran. These experts demonstrate the APPLY operator, a T-SQL feature that can be used to solve a wide variety of problems. What’s especially interesting about APPLY is how it can be used in conjunction with many T-SQL features. To demonstrate this aspect of APPLY, the session tracks the operator through time, discussing features that were initially introduced in different versions of SQL Server (7.0, like TOP, through 2012, like OFFSET-FETCH), some of which are widely used today. For each feature, the session describes its shortcomings and then shows how to use APPLY to overcome it and to improve the feature.
