Condividi tramite


Raccolta di dati e set di dati del database watcher (anteprima)

Si applica a: Database SQL di Azure Istanza gestita di SQL di Azure

Il watcher di database raccoglie i dati di monitoraggio dalle visualizzazioni di sistema SQL e li inserisce nell'archivio dati sotto forma di set di dati. Ogni set di dati viene creato usando i dati di una o più visualizzazioni di sistema SQL. Per ogni set di dati è presente una tabella separata nell'archivio dati.

Raccolta dati

Il watcher di database raccoglie i dati di monitoraggio a intervalli periodici usando query T-SQL. I dati raccolti in ogni esecuzione di una query sono denominati esempio. La frequenza di raccolta degli esempi varia in base al set di dati. Ad esempio, i dati che cambiano di frequente, come i contatori delle prestazioni SQL, possono essere raccolti ogni 10 secondi, mentre la maggior parte dei dati statici, come la configurazione del database, possono essere raccolti ogni cinque minuti. Per altre informazioni, vedere set di dati.

Il watcher di database sfrutta l'inserimento in streaming in Esplora dati di Azure e Analisi in tempo reale in Microsoft Fabric per fornire un monitoraggio near real-time. In genere, i dati di monitoraggio SQL raccolti sono disponibili per la creazione di report e l'analisi in meno di 10 secondi. È possibile monitorare la latenza di inserimento dati sui dashboard del watcher di database usando il collegamento Statistiche di inserimento.

Interazione tra il watcher di database e i carichi di lavoro dell'applicazione

L'abilitazione del watcher di database probabilmente non avrà un impatto osservabile sui carichi di lavoro dell'applicazione. Le query di monitoraggio più frequenti vengono in genere eseguite in un intervallo inferiore al secondo, mentre le query che potrebbero richiedere più tempo, ad esempio per restituire set di dati di grandi dimensioni, vengono eseguite a intervalli non frequenti.

Per ridurre ulteriormente il rischio di un impatto sui carichi di lavoro dell'applicazione, tutte le query del watcher di database in database SQL di Azure sono regolate dalle risorse come carico di lavoro interno. Quando è presente una contesa di risorse, l'utilizzo delle risorse da parte delle query di monitoraggio è limitato a una piccola frazione di risorse totali disponibili per il database. In questo modo i carichi di lavoro delle applicazioni hanno la priorità rispetto alle query di monitoraggio.

Per evitare conflitti di concorrenza, ad esempio blocchi e deadlock tra la raccolta di dati e i carichi di lavoro del database in esecuzione nelle risorse SQL di Azure, le query di monitoraggio usano timeout blocco brevi e priorità deadlock bassa. Se si verifica un conflitto di concorrenza, la priorità viene assegnata alle query del carico di lavoro dell'applicazione. A seconda dei criteri del carico di lavoro dell'applicazione, questo potrebbe causare interruzioni occasionali nei dati raccolti per alcuni set di dati.

Raccolta di dati nei pool elastici

Per monitorare un pool elastico, è necessario designare un database del pool come database di ancoraggio. Il watcher di database si connette al database di ancoraggio. Poiché il watcher dispone dell'autorizzazione VIEW SERVER PERFORMANCE STATE, le visualizzazioni di sistema nel database di ancoraggio forniscono i dati di monitoraggio del pool nel suo complesso.

Suggerimento

È possibile aggiungere un database vuoto a ogni pool elastico che si vuole monitorare e designarlo come database di ancoraggio. In questo modo, è possibile spostare altri database all'interno e all'esterno del pool o tra pool, senza interrompere il monitoraggio del pool elastico.

I dati raccolti dal database di ancoraggio contengono metriche a livello di pool e determinate metriche delle prestazioni a livello di database per ogni database del pool. Ad esempio, sono incluse le metriche relative all'utilizzo delle risorse e alla frequenza delle richieste per ogni database. Per alcuni scenari, il monitoraggio di un pool elastico nel suo complesso rende superfluo il monitoraggio di ogni singolo database del pool.

Alcuni dati di monitoraggio, ad esempio CPU, memoria, utilizzo dell'archiviazione a livello di pool e le statistiche di attesa vengono raccolti solo a livello di pool elastico perché non possono essere attribuite al singolo database di un pool. Al contrario, alcuni altri dati, ad esempio statistiche di runtime delle query, proprietà del database, metadati di indice e tabella, sono disponibili solo a livello di database.

Se si aggiungono singoli database da un pool elastico come destinazioni del watcher di database, è necessario aggiungere come destinazione anche il pool elastico. In questo modo, si ottiene una visualizzazione più completa delle prestazioni del database e del pool.

Monitorare pool elastici densi

Un pool elastico denso contiene un numero elevato di database, ma ha dimensioni di calcolo relativamente ridotte. Questa configurazione consente ai clienti di ottenere un notevole risparmio sui costi mantenendo l'allocazione delle risorse di calcolo al minimo, partendo dal presupposto che solo un numero ridotto di database del pool sia attivo contemporaneamente.

Le risorse di calcolo disponibili per le query del watcher di database in un pool elastico denso sono ulteriormente limitate per evitare che incidano sulle query dell'applicazione. Per questo motivo, Il watcher di database potrebbe non essere in grado di raccogliere dati di monitoraggio da ogni database di un pool elastico denso.

Suggerimento

Per monitorare un pool elastico denso, abilitare il monitoraggio a livello di pool aggiungendo il pool elastico come destinazione.

Non è consigliabile monitorare più di qualche singolo database in un pool elastico denso. Potrebbero verificarsi lacune nei dati raccolti o intervalli superiori a quelli previsti tra i campioni di dati a causa di risorse di calcolo disponibili insufficienti per le query del watcher di database.

Residenza dei dati

I clienti possono scegliere di archiviare i dati di monitoraggio SQL raccolti in uno dei tre tipi di archivio dati:

  • Un database in un cluster di Esplora dati di Azure. Per impostazione predefinita, viene creato un nuovo cluster di Esplora dati di Azure per ogni nuovo watcher e si trova nella stessa area di Azure del watcher.

    I clienti possono scegliere l'area di Azure specifica in dei dati geografici di Azure come posizione del cluster di Esplora dati di Azure e del database. Per altre informazioni sulle funzionalità di replica dei dati in Esplora dati di Azure, vedere Informazioni generali sulla continuità aziendale e ripristino di emergenza.

  • Un database in un cluster gratuito di Esplora dati di Azure.

    I clienti possono scegliere i dati geografici di Azure specifici, ma non l'area di Azure come posizione del cluster gratuito di Esplora dati di Azure e del database. La replica dei dati in un'area o in dati geografici diversi non è supportata.

  • Un database in Analisi in tempo reale in Microsoft Fabric.

    I clienti non possono scegliere la posizione geografica del database.

Per controllare completamente la residenza dei dati per i dati di monitoraggio SQL raccolti, i clienti devono scegliere un database in un cluster di Esplora dati di Azure come archivio dati.

I clienti possono anche allineare i dati geografici e l'area del cluster di Esplora dati di Azure ai dati geografici e all'area delle risorse di Azure SQL monitorate. Quando le risorse di Azure SQL si trovano in più aree, i clienti potrebbero dover creare più watcher e più cluster di Esplora dati di Azure per soddisfare i requisiti di residenza dei dati.

Set di dati

Questa sezione descrive i set di dati disponibili per ogni tipo di destinazione, incluse le frequenze di raccolta e i nomi delle tabelle dell'archivio dati.

Nota

Durante l'anteprima, è possibile aggiungere e rimuovere set di dati. Le proprietà del set di dati, ad esempio nome, descrizione, frequenza di raccolta e colonne disponibili, sono soggette a modifiche.

Nome del set di dati Nome tabella Frequenza di raccolta (hh:mm:ss) Descrizione
Sessioni attive sqldb_database_active_sessions 00:00:30 Ogni riga rappresenta una sessione che esegue una richiesta, è un blocco o ha una transazione aperta.
Cronologia dei backup sqldb_database_sql_backup_history 00:05:00 Ogni riga rappresenta un backup del database completato correttamente.
Elaborazione delle modifiche sqldb_database_change_processing 00:01:00 Ogni riga rappresenta uno snapshot delle statistiche aggregate di analisi dei log per una funzionalità di elaborazione delle modifiche, ad esempio Change Data Capture o Feed di modifiche (Collegamento ad Azure Synapse).
Errori di elaborazione delle modifiche sqldb_database_change_processing_errors 00:01:00 Ogni riga rappresenta un errore che si è verificato durante l'elaborazione delle modifiche quando si usa una funzionalità di elaborazione delle modifiche, ad esempio Change Data Capture o Feed di modifiche (Collegamento ad Azure Synapse).
Connettività sqldb_database_connectivity 00:00:30 Ogni riga rappresenta un probe di connettività (un accesso e una query) di un database.
Repliche geografiche sqldb_database_geo_replicas 00:00:30 Ogni riga rappresenta una replica geografica primaria o secondaria, e include i metadati e le statistiche della replica geografica.
Metadati di indice sqldb_database_index_metadata 00:30:00 Ogni riga rappresenta una partizione di indice e include definizione, proprietà e statistiche operative dell’indice.
Utilizzo memoria sqldb_database_memory_utilization 00:00:10 Ogni riga rappresenta un clerk di memoria e include l'utilizzo della memoria da parte del clerk nell'istanza del motore di database.
Indici mancanti sqldb_database_missing_indexes 00:15:00 Ogni riga rappresenta un indice che, se creato, potrebbe migliorare le prestazioni delle query.
Eventi di memoria insufficiente sqldb_database_oom_events 00:01:00 Ogni riga rappresenta un evento di memoria insufficiente nel motore di database.
Contatori delle prestazioni (comuni) sqldb_database_performance_counters_common 00:00:10 Ogni riga rappresenta un contatore delle prestazioni dell'istanza del motore di database. Questo set di dati include contatori di uso comune.
Contatori delle prestazioni (dettagliati) sqldb_database_performance_counters_detailed 00:01:00 Ogni riga rappresenta un contatore delle prestazioni dell'istanza del motore di database. Questo set di dati include contatori che potrebbero essere necessari per il monitoraggio dettagliato e la risoluzione dei problemi.
Proprietà sqldb_database_properties 00:05:00 Ogni riga rappresenta un database e include opzioni, limiti di governance delle risorse e altri metadati del database.
Statistiche di runtime di query sqldb_database_query_runtime_stats 00:15:00 Ogni riga rappresenta un intervallo di runtime di Query Store e include statistiche di esecuzione delle query.
Statistiche di attesa di query sqldb_database_query_wait_stats 00:15:00 Ogni riga rappresenta un intervallo di runtime di Query Store e include statistiche sulle categorie di attesa.
Repliche sqldb_database_replicas 00:00:10 Ogni riga rappresenta una replica di database, e include i metadati e le statistiche della replica. Include la replica primaria e le repliche geografiche quando queste vengono raccolte nel database primario, e le repliche secondarie quando vengono raccolte in un database secondario.
Utilizzo della risorsa sqldb_database_resource_utilization 00:00:15 Ogni riga rappresenta CPU, I/O dati, I/O log e altre statistiche di utilizzo delle risorse per un database in un determinato intervallo di tempo.
Statistiche di sessione sqldb_database_session_stats 00:01:00 Ogni riga rappresenta un riepilogo delle statistiche di sessione per un database, aggregato da attributi di sessione non additivi, come il nome di accesso, il nome host, il nome dell’applicazione e così via.
Pianificatori SOS sqldb_database_sos_schedulers 00:01:00 Ogni riga rappresenta un pianificatore SOS e include statistiche del pianificatore, del nodo CPU e del nodo di memoria.
I/O archiviazione sqldb_database_storage_io 00:00:10 Ogni riga rappresenta un file di database e include statistiche su operazioni di I/O al secondo, velocità effettiva e latenza cumulative relative al file.
Utilizzo spazio di archiviazione sqldb_database_storage_utilization 00:01:00 Ogni riga rappresenta un database e include l'utilizzo dello spazio di archiviazione, tra cui tempdb, Query Store e Archivio versioni permanenti.
Metadati delle tabelle sqldb_database_table_metadata 00:30:00 Ogni riga rappresenta una tabella o una vista indicizzata e include metadati quali conteggio righe, utilizzo dello spazio, compressione dei dati, colonne e vincoli.
Statistiche di attesa sqldb_database_wait_stats 00:00:10 Ogni riga rappresenta un tipo di attesa e include statistiche di attesa cumulative dell'istanza del motore di database. Per i database di un pool elastico, vengono raccolte solo le statistiche di attesa nell’ambito del database.

Nota

Per i database di un pool elastico, i set di dati del database SQL contenenti dati a livello di pool non vengono raccolti. Sono inclusi i set di dati utilizzo della memoria, eventi di memoria insufficiente, contatori delle prestazioni (comuni) e contatori delle prestazioni (dettagliati). Il set di dati Statistiche di attesa viene raccolto ma contiene solo attese nell’ambito del database. In questo modo si evita la raccolta degli stessi dati da ogni database del pool.

I dati a livello di pool vengono raccolti nei set di dati del pool elastico SQL. Per un determinato pool elastico, i contatori delle prestazioni (comuni) e i contatori delle prestazioni (dettagliati) contengono metriche a livello di pool e alcune metriche a livello di database, come CPU, I/O dati, scrittura log, richieste, transazioni e così via.

Colonne comuni

Per ogni tipo di destinazione, i set di dati hanno colonne comuni, come descritto nelle tabelle seguenti.

Nome colonna Descrizione
subscription_id ID sottoscrizione di Azure del database SQL.
resource_group_name Il nome del gruppo di risorse per il database SQL.
resource_id L’ID della risorsa del database SQL.
sample_time_utc Ora in cui sono stati osservati i valori della riga, in formato UTC.
collection_time_utc Ora in cui è stata raccolta la riga da parte del watcher, in formato UTC. Questa colonna è presente nei set di dati in cui l'ora di raccolta potrebbe essere diversa dall'ora di esempio.
replica_type Uno tra: primario, secondario a disponibilità elevata, server d'inoltro di replica geografica, secondario denominato.
logical_server_name Nome del server logico del database SQL di Azure contenente il database monitorato o il pool elastico.
database_name Nome del database monitorato.
database_id ID database del database monitorato, univoco all'interno del server logico.
logical_database_id Identificatore univoco del database che rimane invariato per tutta la durata del database utente. Rinominare il database o modificarne l'obiettivo di servizio non modifica questo valore.
physical_database_id Identificatore univoco del database fisico corrente che corrisponde al database utente. La modifica dell'obiettivo del servizio del database comporta la modifica di questo valore.
replica_id Identificatore univoco per una replica di calcolo Hyperscale.

Un set di dati dispone di entrambe le colonne sample_time_utc e collection_time_utc se contiene campioni osservati prima che la riga sia stata raccolta dal watcher di database. In caso contrario, l'ora di osservazione e l'ora di raccolta sono uguali e il set di dati contiene solo la colonna sample_time_utc.

Ad esempio, il set di dati sqldb_database_resource_utilization è derivato dalla DMV sys.dm_db_resource_stats. La DMV contiene la colonna end_time, ovvero l’ora di osservazione per ogni riga che segnala le statistiche delle risorse aggregate per un intervallo di 15 secondi. Questa ora viene indicate nella colonna sample_time_utc. Quando il watcher del database esegue una query su questa DMV, il set di risultati potrebbe contenere più righe, ognuna con un diverso end_time. Tutte queste righe hanno lo stesso valore collection_time_utc.