Approfondimenti tecnici e articoli di riferimento su SQL Server e Data Platform, con estensioni su Azure, analytics/BI e Data Engineering. Qui trovi guide operative, best practice, analisi e casi reali dalla community UGISS, pensati per essere utili anche a distanza di tempo.
Per decenni, noi professionisti dei dati abbiamo vissuto in un paradosso. SQL Server è sempre stato un titano per la gestione di grandi moli di dati, ma di fronte a una richiesta semplice come “estrai solo i numeri di telefono validi da questa colonna sporca”, ci costringeva a salti mortali per riuscire ad ottenere delle performance adeguate.
Optimized Locking è una funzionalità dell’Engine di SQL Server 2025, è stata implementata per ridurre l’utilizzo della memoria impiegata per la gestione dei lock, ridurre il fenomeno noto con il nome di lock escalation e aumentare la concorrenza dei carichi di lavoro. Nei precedenti articoli di questa serie: SQL Server 2025 Optimized Locking e Optimized Locking Internals: Gestione dei lock in aggiornamenti concorrenti abbiamo descritto rispettivamente il funzionamento generale di Optimized Locking e come avviene la gestione dei lock negli aggiornamenti concorrenti.
Optimized Locking è una funzionalità dell’Engine di SQL Server 2025, è stata implementata per ridurre l’utilizzo della memoria impiegata per la gestione dei lock, ridurre il fenomeno noto con il nome di lock escalation e aumentare la concorrenza dei carichi di lavoro.
In questo articolo abbiamo descritto il funzionamento generale di Optimized Locking, ora passiamo alla pratica, osservando come l’Engine gestisce aggiornamenti concorrenti con Lock After Qualification. Consideriamo la tabella dbo.SalesOrder in un database SQL Server 2025 con Optimized Locking completamente abilitato. La tabella contiene i seguenti dati di prova.
SQL Server 2025 introduce importanti innovazioni nell’Engine per migliorare performance e scalabilità. In particolare, la famiglia di funzionalità nota come Intelligent Query Processing si arricchisce di nuove feature in grado di ottimizzare i carichi di lavoro esistenti con uno sforzo di implementazione minimo.
Questo articolo descrive il funzionamento di Optimized Halloween Protection che riduce l’uso del tempdb e migliora le prestazioni delle query grazie a un approccio più efficiente alla gestione del problema di Halloween all’interno dell’Engine.
SQL Server 2025 introduce importanti innovazioni nell’Engine per migliorare performance e scalabilità. In particolare, la famiglia di funzionalità nota come Intelligent Query Processing si arricchisce di nuove feature in grado di ottimizzare i carichi di lavoro esistenti con uno sforzo di implementazione minimo.
Questo articolo descrive il funzionamento di Optional Parameter Plan Optimization (OPPO) che risolve una variante del problema che affligge i piani di esecuzione sensibili ai parametri. Parameter Sensitive Plan Optimization (PSPO), a partire da SQL Server 2022, permette di avere nella plan cache più piani di esecuzione attivi per una singola query parametrizzata; Optional Parameter Plan Optimization (OPPO) interviene, nelle query multi-plan, quando il valore sensibile del parametro presente durante l’esecuzione della query determina se è necessario eseguire una ricerca o una scansione di una tabella.
Nel panorama delle applicazioni moderne, in cui scalabilità e concorrenza rappresentano requisiti essenziali, garantire prestazioni elevate senza sacrificare la coerenza dei dati è una sfida sempre più complessa. SQL Server 2025 introduce diverse novità nell’Engine per migliorare performance e scalabilità. In questo articolo, dopo una panoramica iniziale sulle novità introdotte nel database Engine, ci concentreremo su Optimized Locking, una funzionalità dal nome magico che modifica il modo in cui le istruzioni DML acquisiscono i lock. Introdotta inizialmente in Azure SQL, ora è disponibile anche on-premises.
Recentemente mi sono trovato ad affrontare un caso interessante relativo alla gestione di un vincolo UNIQUE con alcune particolarità su una tabella di un database SQL Server. La richiesta è stata quella controllare che i valori inseriti o modificati in una colonna siano unici, permettendo però NULL multipli.
Consideriamo, a titolo di esempio semplificato, lo schema della tabella dbo.EmailTable. La tabella memorizza alcuni attributi di una anagrafica contatti tra cui il Nome, il Cognome e l’Email. L’attributo Email non è obbligatorio ma quando presente deve essere univoco. L’assenza dell’attributo viene gestita con un NULL.
