Troubleshooting

Chi ha visto la mia presentazione Microsoft Virtual Accademy sulle diverse tecniche per fare i backup integrandosi con Azure Blob Storage forse ricorderà il “SQL Server Backup to Windows Azure Tool” che in maniera trasparente intercetta i comandi di BACKUP e RESTORE di SQL Server dirottandone il contenuto da e verso Azure Blob Storage.

Si tratta di un meccanismo interessante perché a partire dalla versione 2005 di SQL Server permette di fare i backup:

Tenere sotto controllo le prestazioni e lo “stato di salute” di un database non è semplice e talvolta richiede parecchio tempo.

Query Performance Insight offre la possibilità di verificare il consumo in DTU del database, individuare le query più costose in termini di DTU che potrebbero quindi influire negativamente sulle prestazioni e infine eseguire “drill down” sulle query per visualizzarne tutti i dettagli.

[highlight color=“yellow”]N.B.: Query Performance Insight è in modalità anteprima ed è attivabile solo tramite Azure Preview Portal[/highlight]

Un po’ di tempo fa, ho avuto l’opportunità di analizzare una situazione in cui si verificava un inaspettato cambiamento dello SPID relativo ad una connessione aperta da un’Applicazione verso un database SQL Server. Lo SPID rappresenta l’identificativo numerico assegnato da SQL Server ad ogni nuova sessione.

Tutto è iniziato con la segnalazione di un cliente, che lamentava rallentamenti nell’Applicazione, blocchi e talvolta errori di lock time-out. I rallentamenti e i blocchi non erano ovviamente sistematici e attribuibili ad un eccezionale carico di lavoro; si verificavano però principalmente su una determinata funzione Applicativa. Dopo svariati tentativi nel cercare di catturare questi tipi di lock, siamo finalmente riusciti a riprodurre il problema.

Sul canale SQLPASS TV è stata pubblicata la sessione Troubleshooting Clusters tenuta da Allan Hirt (@SQLHA) durante lo scorso PASS Summit 2013.

Abstract

Whether you are new to clusters or have years of experience, you may still cross your fingers when implementing a failover cluster instance (FCI) of SQL Server or an availability group (AG). Both require an underlying Windows Server failover cluster (WSFC), but how many DBAs are involved in the planning and deployment of it? What happens if you try to install an FCI or configure an AG and things don’t work? Or worse, what if the implementation fails after going live in production? This session will cover how to diagnose what went wrong and the free tools available to you, as well as demonstrate how to fix common issues that every DBA should know about.