Le performance di una soluzione database sono spesso oggetto di diatriba tra chi fornisce la soluzione e chi la personalizza. Scrivere codice T-SQL ottimizzato, in grado di scalare all’aumentare dei dati e degli utenti, non è affatto semplice e quando la complessità aumenta, le attività di manutenzione del codice diventano difficili da attuare anche per l’autore stesso.
Qualche settimana fa un collega mi ha sottoposto un quesito la cui risposta coinvolge alcuni concetti molto interessanti. La domanda più o meno era:
SQL Server mi dice che manca un indice, l’ho creato. Perchè eseguendo una query su sys.dm_db_missing_index_details trovo ancora l’indice come mancante? Come dico a SQL di aggiornare la DMV?
Il prossimo webinar del PASS Italian Virtual Chapter è programmato per mercoledì 7 dicembre 2016 alle ore 18:00.
Gianluca Sartori (@spaghettidba) ci spiegherà come sia possibile “Rispondere agli Extended Event in tempo reale”.
Questo è l’abstract del webinar:
Gli Extended Event consentono di accedere a informazioni molto dettagliate riguardo il comportamento interno di SQL Server. Tuttavia, confrontate con altre tecnologie come SQL Trace e Event Notifications, sembra mancare un modo per reagire ad un evento non appena si verifica. In questa sessione vedremo come gli Extended Events possono essere processati in tempo reale utilizzando la streaming API. Dimostreremo inoltre come questa tecnologia apre nuovi scenari e nuove possibilità per risolvere problemi comuni, come ad esempio catturare e notificare deadlock e sessioni bloccate.
Il SQL Server Tiger Team si sta occupando, tra le altre cose, di tenere aggiornata la lista di tutti i trace flag disponibili in SQL Server per modificare il funzionamento nel caso sia assolutamente necessario. La lista è disponibile qui:
Occhio, come al solito, che i trace flags non sono da usare alla leggera, quindi usateli se e solo se è strettamente necessario!
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.
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.
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.
