Passa al contenuto

Cosa deve comprendere un Health Check di un'istanza SQL Server - Prima parte

I controlli preliminari e i controlli a livello di istanza

Uno dei primi passi da muovere quando un DBA si trova davanti ad un nuovo database, è raccogliere il maggior numero possibile di informazioni sul server, sull’hardware, sul sottosistema di archiviazione, sul sistema operativo e dell’istanza SQL Server. 


Quanto sopra permette di valutare con maggiore granularità il sistema nella sua totalità, evitando di tralasciare dettagli rilevanti, anche se apparentemente non sono direttamente connessi al motore database.


Quello che cercherò di esporre in questo articolo ha a che fare con una serie di query che permettono di prendere familiarità con il sistema che abbiamo in gestione e di estrarre informazioni importanti sullo stato di salute del nostro server e di conseguenza del nostro motore database.


Partiamo con l’affermare che da quando le DMV (Dynamic management views) e le DMF (dynamic management functions) sono state introdotte (con SQL Server 2005), si sono da subito dimostrate degli strumenti utilissimi, permettendo ai DBA di raccogliere facilmente informazioni sull’hardware, sull’istanza SQL Server, fino ad arrivare si singoli Database.


Per eseguire DMVs e DMFs sono necessarie le grant di VIEW SERVER STATE. Se si è amministratori di sistema questi permessi sono già disponibili, ma nel caso di utente creato adhoc, in tal caso occore assegnare le grant sopra, se si vuole abilitarlo all’utilizzo delle viste e funzioni dinamiche.


Consiglio di vedere le query che esporrò in questo articolo non come delle query a sé stanti lanciate in un istanza SQL Server:  immaginate di dover raccogliere informazioni su cento, duecento o più  server o istanze SQL Server. Occorrerà sicuramente utilizzare un sistema centralizzato di raccolta, magari spinto da  Packages di Integration Services (SSIS), in coppia ad un sistema di reportistica come Reporting Services (SSRS) oppure Power BI. Ho fatto questa premessa, poiché parte delle informazioni che otterremo da alcune di queste query potranno sembrare scontate, ma se occorre archiviare tale informazioni per molte istanze, la cosa non è poi così scontata. Ecco come la prima query che sto per proporre assume un significato diverso se immaginata in un contesto in cui sono presenti centinaia di istanze SQL Server.


Controlli preliminari


Molto spesso in un contesto di grandi dimensioni non è sempre vero che tutte le versioni di SQL Server sono uguali, anzi è molto probabile che siano presenti versioni diverse di SQL Server; la seguente query (non si tratta di una DMV in questo caso) ci permette di ottenere informazioni sulla versione di SQL Server installata nel server: 

SELECT @@VERSION

L’output indica che ci troviamo di fronte ad una “RTM 2019 Developer Edition a 64 bit” la buil è la 2000 ed è in esecuzione sul sistema operativo Windows 10 Enterprise 10.0.  

Conoscere la versione di SQL Server permette di essere edotti anche sulle funzionalità proprie della versione che si sta utilizzando.  

Sempre dall’output della query sopra è possibile stabilire anche se la build utilizzata è l’ultima disponibile o no. A tal proposito Microsoft rilascia periodicamente un aggiornamento cumulativo (CU) ed ognuno di questi può comprendere dal 10 ai 40 hotfix per SQL Server; oltre a questo Microsoft rilascia dei Service Pack ed occorre conoscere quali aggiornamenti sono stati già installati, in modo da scaricare ed installare la CU mancante. 

Ulteriore informazione e che si tratta di una RTM, acronimo che sta per “Realease to  Manufactoring”, ossia la versione successiva alla Release Candidate. 

Infine possiamo ricavare anche la data e l’ora di compilazione dell’istanza in questione. Questa informazione ci permette di sapere quanto “vecchia” è la nostra istanza. Aggiornare SQL Server assume particolare importanza, poiché un’istanza non aggiornata (CU, SP, KB)  porta con se tutti bug e difetti corretti con gli aggiornamenti rilasciati: ecco quindi che una semplice query, in realtà, ci dice già tanto sullo stato di salute della nostra istanza. 

Continuamo con la seguente query: 

SELECT windows_release
	,windows_Service_pack_level
	,windows_sku
	,os_language_version
FROM sys.dm_os_windows_info

 

L’output, tra le altre informazioni, mostra: il numero delle CPU logiche e fisiche, la quantità di memoria installata nel server e l’ultima volta che SQL Server è stato avviato.  

Controlli a livello di istanza

Dopo aver raccolto informazioni sul sistema operativo e l’hardware del server, passiamo a quelle query che forniscono informazioni sull’istanza SQL Server. 

Servizi SQL Server

Iniziamo a vedere quali servizi SQL Server sono installati nel server: 

SELECT servicename
	,startup_type_desc
	,status_desc
	,last_startup_time
	,service_account
	,is_clustered
	,cluster_nodename
FROM sys.dm_server_services

 

La query sopra, oltre ai servizi installati, ci dice se essi sono in esecuzione e da quando, l’account utilizzato, se sono in cluster e ed eventualmente su quale nodo sono in esecuzione.  

Cluster SQL Server

Ancora sul cluster, la seguente query mostra informazioni di configurazione sul cluster windows (solo se esiste un cluster): 

ELECT verboselogging
	,sqldumperdumpflags
	,sqldumperdumppath
	,sqldumperdumptimeout
	,failureconditionlevel
	,HealthCheckTimeout
FROM sys.dm_os_cluster_properties

La seguente query completa la precedente con ulteriori informazioni utili del cluster:  

SELECT nodename
	,status_description
	,is_current_owner
	,*
FROM sys.dm_os_cluster_nodes

Configurazione dell'istanza

Informazioni sulla configurazione dell’istanza si ottengono invece tramite la seguente istruzione: 

SELECT name
	,value
	,value_in_use
	,description
FROM sys.configurations

L’esecuzione della query sopra permette di visualizzare un numero elevato di configurazioni di SQL Server; parte di queste configurazioni possono essere modificate tramite la GUI di SSMS, mentre per altre occorre servirsi della procedura memorizzata di sistema xp_configure. 


Per raccogliere informazioni sul listener TCP è possibile utilizzare la query seguente: 

SELECT listener_id
	,ip_address
	,is_ipv4
	,port
	,type_desc
	,state_desc
	,start_time
FROM sys.dm_tcp_listener_states

l’output mostra quali porte TCP vengono utilizzate dal listener TCP, per T-SQL, Service Broker e il mirroring del database. 

SELECT registry_key
	,value_name
	,value_data
FROM sys.dm_server_registry

Dalla query sopra si possono estrarre informazioni sui protocolli di rete abilitati, sull’eseguibile di SQL Server, sull’agent, eccetera.


Se c’è stato un dump della memoria, possiamo utilizzare  la seguente query che ci permette di verificare proprio questa occorrenza: 

SELECT filename
	,creation_time
	,size_in_bytes
FROM sys.dm_server_memory_dumps DATABASE Filenames
	AND Path

SELECT DB_NAME([database_id]) AS database_name
	,file_id
	,name
	,physical_name
	,type_desc
	,state_desc
	,convert(BIGINT, size / 128.0) AS total_size_MB
FROM sys.master_files
WHERE database_id > 4
	AND database_id <> 32767
	OR database_id = 2

Ci aspettiamo che il risultato della query sopra sia nullo, ma se dovesse non esserlo, i log di windows ci torneranno utili, confrontando l’ora in cui è avvenuto il dump, per capire l’evento che ha scatenato quanto riscontrato. 


Per estrarre invece i nomi e i percorsi dei files dei database è possibile usare: 

SELECT DB_NAME([database_id]) AS database_name
	,file_id
	,name
	,physical_name
	,type_desc
	,state_desc
	,convert(BIGINT, size / 128.0) AS total_size_MB
FROM sys.master_files
WHERE database_id > 4
	AND database_id <> 32767
	OR database_id = 2

Tramite la query sopra scopriamo quanti sono grandi i nostri database e quindi a che carico di lavoro potrebbe essere soggetta la nostra istanza, oppure verificare se i file t-log e datafiles si trovano o no su unità diverse o ancora se il tempDB è correttamente allocato su una LUN dedicata o ancora sul tempDB se i datafiles sono alllineati con il numero di core del server. 

Nella seconda parte andremo ad esaminare i controlli da eseguire a livello di database.

di Luciano Maugeri, pubblicato il 24 aprile 2026

Il database cambia. Sai sempre come e quando?
Perché le aziende strutturate non possono più gestire l'evoluzione del database a mano