Articoli

Introduzione

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.

I deadlock in SQL Server e Azure SQL possono rappresentare un problema significativo per le prestazioni e quando si presentano diventano presto motivo di discordia tra chi fornisce la soluzione database e chi la personalizza.

Prima di dare la definizione di deadlock esaminiamo le differenze tra lock e deadlock; quest’ultimo viene spesso confuso con il normale lock, ma sono due concetti distinti.

Nel panorama delle applicazioni moderne, dove scalabilità e concorrenza sono elementi fondamentali, mantenere prestazioni elevate senza compromettere la consistenza dei dati è una sfida costante. Azure SQL Database rappresenta spesso il punto di partenza per l’introduzione di nuove funzionalità destinate ad arricchire tutte le versioni di SQL Server. Seguendo questa tendenza, Microsoft ha annunciato una funzionalità dal nome magico: Optimized Locking!

In questo articolo tratteremo i task fondamentali che un piano di manutenzione per database SQL Server deve avere. Esploreremo il significato di alcune impostazioni di default e la possibilità di arricchire il task di backup database con un task di tipo T-SQL script in grado di testare il ripristino del database archiviato. Dettagli aggiuntivi sono disponibili nella documentazione SQL Server Maintenance plans.

Recentemente mi sono imbattuto nell’errore SQL 8115:

Arithmetic overflow error converting IDENTITY to data type int.

Un errore di overflow su una colonna IDENTITY si verifica ogni volta che proviamo a inserire in una colonna un valore superiore al limite previsto per il tipo di dato. Nel caso che ho seguito si trattava di una colonna di tipo integer con proprietà IDENTITY(1, 1), valorizzata automaticamente da SQL Server ad ogni inserimento di dati. L’overflow può avvenire su colonne di tipo integer (come in questo caso) ma anche su colonne di tipo tinyint, smallint e bigint.

Nel precedente articolo Automazione delle attività di manutenzione in Azure SQL Database (2 Parte) abbiamo descritto la prima implementazione (preview) di Azure Elastic Job Agents, attraverso cui è possibile creare e pianificare processi su uno o più database Azure SQL per eseguire query o attività di manutenzione.

Lo scorso novembre, Microsoft ha annunciato un refresh di questa tecnologia con importanti implementazioni in ambito sicurezza, portale di gestione, scalabilità e molto altro; ecco elencate le principali novità: