Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Carico del database
Il carico del database (carico del database) misura il livello di attività della sessione nel database. DBLoadè la metrica chiave di Database Insights e Database Insights raccoglie il carico del DB ogni secondo.
Sessioni attive
Una sessione database rappresenta il dialogo di un'applicazione con un database relazionale. Una sessione attiva è una connessione che ha inviato lavoro a un motore del database ed è in attesa di una risposta dal motore del database.
Una sessione è attiva quando è in esecuzione sulla CPU o in attesa che una risorsa diventi disponibile in modo che possa proseguire. Ad esempio, una sessione attiva potrebbe attendere la lettura di una pagina (o blocco) in memoria e quindi consumare la CPU mentre legge i dati dalla pagina.
Media delle sessioni attive
La media delle sessioni attive (AAS) è l'unità per la DBLoad metrica in Database Insights. Misura quante sessioni sono attive contemporaneamente nel database.
Ogni secondo, Database Insights campiona il numero di sessioni che eseguono contemporaneamente una query. Per ogni sessione attiva, Database Insights raccoglie i seguenti dati:
-
Istruzione SQL
-
Stato della sessione (in esecuzione sulla CPU o in attesa)
-
Host
-
Utente che esegue SQL
Database Insights calcola l'AAS dividendo il numero totale di sessioni per il numero di campioni per un periodo di tempo specifico. Ad esempio, nella tabella seguente vengono riportati 5 campioni consecutivi di una query in esecuzione, dove ogni campione viene acquisito a intervalli di 1 secondo.
| Project N.E.M.O. | Numero di sessioni che eseguono query | AAS | Calcolo |
|---|---|---|---|
| 1 | 2 | 2 | 2 sessioni totali / 1 campione |
| 2 | 0 | 1 | 2 sessioni totali / 2 campioni |
| 3 | 4 | 2 | 6 sessioni totali / 3 campioni |
| 4 | 0 | 1.5 | 6 sessioni totali / 4 campioni |
| 5 | 4 | 2 | 10 sessioni totali / 5 campioni |
Nell'esempio precedente, il carico DB per l'intervallo di tempo è 2 AAS. Questa misurazione significa che, in media, sono state attive 2 sessioni alla volta durante il periodo in cui sono stati acquisiti i 5 campioni.
Media delle esecuzioni attive
La media delle esecuzioni attive (AAE) al secondo è correlata all'AAS. Per calcolare l'AAE, Database Insights divide il tempo totale di esecuzione di una query per l'intervallo di tempo. Nella tabella seguente viene illustrato il calcolo AAE per la stessa query nella tabella precedente.
| Tempo trascorso (sec) | Tempo di esecuzione totale (sec) | AAE | Calcolo |
|---|---|---|---|
| 60 | 120 | 2 | 120 secondi di esecuzione trascorsi seconds/60 |
| 120 | 120 | 1 | 120 secondi di esecuzione trascorsi seconds/120 |
| 180 | 380 | 2.11 | 380 secondi di esecuzione trascorsi seconds/180 |
| 240 | 380 | 1.58 | 380 secondi di esecuzione trascorsi seconds/240 |
| 300 | 600 | 2 | 600 secondi di esecuzione trascorsi seconds/300 |
Nella maggior parte dei casi, l'AAS e AAE per una query sono quasi uguali. Tuttavia, poiché gli input per i calcoli sono origini dati diverse, i calcoli spesso variano leggermente.
Dimensioni
Il parametro db.load è diverso dagli altri parametri di serie temporali in quanto può essere suddiviso in sottocomponenti detti dimensioni. Le dimensioni possono essere considerate come categorie "slice by" (dividi per) per le diverse caratteristiche del parametro DBLoad.
Quando si diagnosticano problemi di prestazioni, le dimensioni seguenti sono spesso le più utili:
Per un elenco completo delle dimensioni per i Aurora, consulta Database Insights. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.html
Eventi di attesa
Un evento di attesa fa sì che un'istruzione SQL attenda che si verifichi un evento specifico prima che possa continuare l'esecuzione. Gli eventi di attesa sono una dimensione o una categoria importante per il caricamento del database perché indicano dove il lavoro è impedito.
Ogni sessione attiva è in esecuzione sulla CPU o in attesa. Ad esempio, le sessioni consumano la CPU quando cercano in memoria un buffer, eseguono un calcolo o eseguono codice procedurale. Quando le sessioni non consumano la CPU, potrebbero essere in attesa che un buffer di memoria diventi libero, un file di dati da leggere o un registro in cui scrivere. Maggiore è il tempo in cui una sessione attende le risorse, minore è il tempo in cui viene eseguita sulla CPU.
Quando si sintonizza un database, si tenta spesso di scoprire le risorse che le sessioni sono in attesa. Ad esempio, due o tre eventi di attesa potrebbero rappresentare il 90% del carico DB. Questa misura significa che, in media, le sessioni attive trascorrono la maggior parte del tempo in attesa di un numero limitato di risorse. Se riesci a scoprire la causa di queste attese, puoi provare a fornire una soluzione.
Gli eventi di attesa variano in base al motore database:
-
Per informazioni su tutti gli eventi di attesa MariaDB e MySQL, consulta Wait Event Summary Tables
nella documentazione di MySQL. -
Per informazioni su tutti gli eventi di attesa PostgreSQL, consulta la pagina relativa al processo di raccolta delle statistiche e alle tabelle degli eventi di attesa
nella documentazione di PostgreSQL. -
Per informazioni su tutti gli eventi di attesa Oracle, consulta l'argomento con le descrizioni degli eventi di attesa
nella documentazione Oracle. -
Per informazioni su tutti gli eventi di attesa SQL Server, consulta Types of Waits
nella documentazione SQL Server.
Nota
Per Oracle, i processi in background a volte funzionano senza istruzioni SQL associate. In questi casi, Database Insights riporta il tipo di processo in background concatenato con due punti e la classe di attesa associata a quel processo in background. I tipi di processo in background includono LGWR, ARC0, PMON, e così via.
Ad esempio, quando l'archiviatore è in esecuzione I/O, il relativo report di Database Insights è simile a. ARC1:System I/O Occasionalmente, manca anche il tipo di processo in background e Database Insights riporta solo la classe di attesa, ad esempio:System
I/O.
prime istruzioni SQL
Mentre gli eventi di attesa mostrano i colli di bottiglia, il primo SQL mostra quali query stanno contribuendo maggiormente al caricamento del DB. Ad esempio, molte query potrebbero essere attualmente in esecuzione nel database, ma una singola query potrebbe consumare il 99 percento del carico DB. In questo caso, il carico elevato potrebbe indicare un problema con la query.
Per impostazione predefinita, la console Database Insights mostra le principali query SQL che contribuiscono al caricamento del database. La console mostra anche le statistiche pertinenti per ogni istruzione. Per diagnosticare problemi di prestazioni per un'istruzione specifica, è possibile esaminarne il piano di esecuzione.
Piani
Un piano di esecuzione, chiamato anche semplicemente piano, è una sequenza di passaggi che accedono ai dati. Ad esempio, un piano per unire le tabelle t1 e t2 potrebbe scorrere in loop tutte le righe in t1 e confrontare ogni riga con una riga in t2. In un database relazionale, un ottimizzatore è un codice incorporato che determina il piano più efficiente per una query SQL.
Per le istanze DB, Database Insights raccoglie automaticamente i piani di esecuzione. Per diagnosticare i problemi di prestazioni SQL, è possibile esaminare i piani acquisiti per le query SQL con elevato utilizzo di risorse. I piani mostrano come il database ha analizzato ed eseguito le query.
Per informazioni su come analizzare il carico del DB utilizzando i piani, consulta Database Insights.
Acquisizione del piano
Ogni cinque minuti, Database Insights identifica le query che richiedono più risorse e ne acquisisce i piani. Pertanto, non devi raccogliere e gestire manualmente un gran numero di piani. Invece, puoi utilizzare la scheda Top SQL (Prime istruzioni SQL) per concentrarti sui piani per le query più problematiche.
Nota
Database Insights non acquisisce i piani per le query il cui testo supera il limite massimo di testo delle query collezionabili. Per ulteriori informazioni, vedere Database Insights.
Il periodo di conservazione per i piani di esecuzione è lo stesso dei dati di Database Insights. L’impostazione del periodo di conservazione Impostazione predefinita (7 giorni). Per mantenere i dati sulle prestazioni più a lungo, specifica da 1 a 24 mesi. Per altre informazioni sui periodi di conservazione, consulta Prezzi e conservazione dei dati per Database Insights.
Query digest
La scheda Top SQL (Prime istruzioni SQL) mostra le query digest per impostazione predefinita. Una query digest di per sé non ha un piano, ma tutte le query che utilizzano valori letterali hanno piani. Ad esempio, una query digest potrebbe includere il testo WHERE `email`=?. Il digest potrebbe contenere due query, una con il testo WHERE email=user1@example.com e un'altra con WHERE
email=user2@example.com. Ognuna di queste query letterali può includere più piani.
Quando si seleziona una query digest, la console mostra tutti i piani per le istruzioni secondarie del digest selezionato. Pertanto, non devi esaminare tutte le istruzioni figlio per trovare il piano. Potresti vedere piani che non sono inclusi nell'elenco delle prime 10 istruzioni figlio. La console mostra i piani per tutte le query figlio per le quali sono stati raccolti i piani, indipendentemente dal fatto che le query siano tra le prime 10.
