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.
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à:
L’obiettivo del presente articolo è quello di esporre una nuova metodologia di monitoraggio che ha lo scopo di governare le istanze SQL Server e d’integrare gli strumenti di monitoraggio.
Una delle cose necessarie per governare un’istanza e\o dei database SQL Azure, è quella di essere in grado di sapere quali sono i comandi che girano abitualmente sull’istanza e saper di rispondere ai molti quesiti che emergono ogni giorno in fase di amministrazione: problemi di lentezze applicative che vanno declinati nel comprendere se la componente database è la parte lenta o meno nonché se la causa sono stati i blocchi o il carico di quali comandi; stored procedure che degradano di performance nel tempo per le quali capire quale è lo statement lento e da quando ha iniziato a degradare; esigenze di deploy di nuovi database e scelta dell’istanza; richieste di lavoro in fasce orarie non abituali; comandi che ingrandiscono il TLOG e molte altre richieste.
Recentemente, ho avuto l’occasione di configurare un piano di manutenzione database per un DB in cui sono state create alcune External Table PolyBase che permettono di raggiungere dati archiviati all’esterno dell’istanza SQL Server.
Non si poteva testare la manutenzione database contestualmente alla configurazione del piano e così ho atteso la finestra temporale dedicata a queste attività. All’ora indicata, il piano di manutenzione (configurazione classica) non è stato eseguito correttamente, le verifiche hanno successivamente rilevato un errore nel task di aggiornamento statistiche.