Articoli

Introduzione

Molto del valore informativo di un’azienda è già nei suoi database: dati relazionali, contenuti testuali, documentazione, ticket e knowledge base. Non sempre, però, filtri, relazioni e ricerche testuali sono sufficienti per trovare informazioni simili per significato.

Con SQL Server 2025, Microsoft porta funzionalità di intelligenza artificiale direttamente nel motore database: nuovo tipo di dato VECTOR, funzioni per lavorare con embeddings, vector search, external model e integrazione con servizi come Azure OpenAI. Queste funzionalità permettono di costruire scenari di ricerca semantica usando T-SQL, accanto al dato relazionale e senza dover ripensare completamente l’architettura dati.

Recentemente ho avuto l’occasione di configurare le impostazioni di networking per un database Azure SQL e desidero condividere un aspetto che non avevo considerato durante le scelte iniziali di deployment della soluzione.

La soluzione comprende un database Azure SQL, un’applicazione e una macchina virtuale Azure che ospita l’applicazione la quale necessita della connessione al database.

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.

Introduzione

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.