Senza baseline non esiste diagnosi

“La CPU è all’80%” non è una diagnosi: è un numero. Diventa informazione solo quando lo si confronta con il comportamento normale di quel database, in quel giorno della settimana, a quella fascia oraria. Un carico OLTP che sta stabilmente sopra il 70% può essere perfettamente sano; lo stesso valore su un database che di solito viaggia al 15% è un incidente in corso.

La baseline è quindi la raccolta sistematica degli indicatori su un periodo rappresentativo, che includa i picchi ricorrenti (chiusure mensili, batch notturni, campagne). Serve a tre cose che l’esame dà per scontate: riconoscere una regressione, dimensionare correttamente lo scale up o lo scale down di un service tier, e dimostrare che un intervento di tuning ha funzionato confrontando il prima e il dopo. Senza baseline ogni azione correttiva è una scommessa, e negli scenari d’esame la risposta giusta è quasi sempre quella che confronta con uno storico, non quella che guarda solo l’istante presente.

Le fonti dei dati e il loro raggio d’azione

Azure Monitor è la vista dall’esterno, a livello di risorsa Azure. Le platform metrics (percentuale di DTU o di vCore, CPU, data IO, log IO, workers, sessions, deadlock, storage) sono disponibili senza configurazione, ma la loro storia nel portale è breve. Per conservarle e per raccogliere i log di diagnostica serve un diagnostic setting che instradi i dati verso un Log Analytics workspace, uno storage account o un event hub; da lì si costruiscono alert, workbook e query KQL. È il livello giusto per allarmi, trend e reportistica multi-risorsa.

Le dynamic management view sono la vista dall’interno, in T-SQL, e raccontano lo stato corrente: sessioni e richieste attive, catene di blocking, statistiche di attesa, consumo recente di risorse, IO sui file di dati e di log, statistiche aggregate delle query. Sono il primo strumento quando il problema è in corso adesso. Il loro limite è strutturale: molte sono volatili e il contenuto si azzera a un riavvio o a un failover, quindi non sostituiscono una baseline. Su Azure SQL Database quelle a livello di istanza non sono disponibili o hanno visibilità ridotta, mentre su Managed Instance e su SQL Server su VM la superficie è quella completa.

Gli Extended Events sono il meccanismo di tracciamento attuale: leggero, filtrabile, orientato all’evento singolo. Si crea una event session, si scelgono eventi, azioni e predicati e si scrive su un target (ring buffer per il volatile, event file su Azure Blob Storage per la persistenza). Hanno sostituito SQL Trace e SQL Server Profiler, deprecati e non disponibili su Azure SQL Database. Vanno usati in modo chirurgico e temporaneo — catturare un deadlock graph, un errore specifico, le query oltre una certa durata — non come monitoraggio permanente.

database watcher è il monitoraggio gestito per Azure SQL Database e Azure SQL Managed Instance: raccoglie ad alta frequenza dai dati di sistema, li conserva in un data store dedicato e li presenta in dashboard già pronte. È la risposta quando lo scenario chiede monitoraggio continuo, storicizzato e centralizzato su molte risorse senza costruire una pipeline propria.

Leggere gli indicatori: limite di risorsa o problema di query?

La percentuale di DTU è un valore composito e nasconde il collo di bottiglia; nel modello vCore i contatori sono separati e vanno letti singolarmente. La regola di lettura è questa: se tutto rallenta insieme e un contatore è saturo in modo continuativo, si è contro un limite del service tier e la leva è lo scale up o la riduzione del carico. Se invece i contatori di risorsa sono tranquilli ma la durata cresce, il problema è nelle attese — blocking, IO, scrittura del log — e va inseguito con le wait statistics e con il Query Store.

Alcuni casi ricorrenti: log IO saturo durante insert massivi indica log rate governance, non lentezza dei dischi; percentuale di worker o di sessioni vicina al limite è quasi sempre il sintomo di una catena di blocking, non la causa; i deadlock non sono un problema di capacità e non si risolvono scalando, perché dipendono dall’ordine di accesso agli oggetti.

Trappole tipiche d’esame

  • Serve capire se un rallentamento è anomalo → confronta con la baseline, non con una soglia assoluta: le risposte che fissano un valore fisso di CPU come “critico” sono distrattori; la soglia sensata nasce dallo storico di quella risorsa.
  • Serve tracciare un evento specifico e transitorio → Extended Events, non SQL Profiler o SQL Trace: gli strumenti di traccia legacy sono deprecati e su Azure SQL Database non esistono proprio.
  • Serve monitoraggio continuo e storicizzato su più istanze Azure SQL → database watcher: le DMV danno solo l’istante e perdono tutto a un failover, e le platform metrics senza diagnostic setting hanno una finestra breve.
  • Serve conservare metriche e log oltre la finestra del portale → diagnostic setting verso Log Analytics: i backup automatici si configurano, i log di diagnostica si attivano; non arrivano da soli in un workspace.
  • Una sola query è regredita dopo un deploy → Query Store, non scale up: aggiungere risorse maschera il piano sbagliato e alza il costo; il confronto dei piani nel tempo è il percorso corretto.
  • Serve schedulare una raccolta periodica su Azure SQL Database → elastic job, Azure Automation o Azure Functions: SQL Server Agent non esiste su Azure SQL Database, esiste su Managed Instance e su SQL Server su VM.