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à. # Caricamento database L’opzione *Caricamento del database* misura il livello di attività della sessione nel database. `DBLoad` è la metrica chiave di Approfondimenti sulle prestazioni e Approfondimenti sulle prestazioni raccoglie il carico del database ogni secondo. **Topics** + [Sessioni attive](#USER_PerfInsights.Overview.ActiveSessions.active-sessions) + [Media delle sessioni attive](#USER_PerfInsights.Overview.ActiveSessions.AAS) + [Media delle esecuzioni attive](#USER_PerfInsights.Overview.ActiveSessions.AAE) + [Dimensioni](#USER_PerfInsights.Overview.ActiveSessions.dimensions) ## 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 il parametro `DBLoad` in Performance Insights. Misura quante sessioni sono attive contemporaneamente nel database. Ogni secondo, Performance Insights esegue il campionamento del numero di sessioni che eseguono contemporaneamente una query. Per ogni sessione attiva, Performance Insights raccoglie i seguenti dati: + Istruzione SQL + Stato della sessione (in esecuzione sulla CPU o in attesa) + Host + Utente che esegue SQL Performance Insights calcola il valore delle sessioni attive medie (AAS) dividendo il numero totale di sessioni per il numero totale 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.ActiveSessions.html) 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, Performance 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.ActiveSessions.html) 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: **Topics** + [Eventi di attesa](#USER_PerfInsights.Overview.ActiveSessions.waits) + [Prime istruzioni SQL](#USER_PerfInsights.Overview.ActiveSessions.top-sql) + [Piani](#USER_PerfInsights.Overview.ActiveSessions.plans) Per un elenco completo delle dimensioni per i motori Amazon RDS, consulta [Carico del database suddiviso per dimensioni](USER_PerfInsights.UsingDashboard.Components.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.dims). ### 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](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html) 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](https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE) nella documentazione di PostgreSQL. + Per informazioni su tutti gli eventi di attesa Oracle, consulta l'argomento con le [ descrizioni degli eventi di attesa](https://docs.oracle.com/database/121/REFRN/GUID-2FDDFAA4-24D0-4B80-A157-A907AF5C68E2.htm#REFRN-GUID-2FDDFAA4-24D0-4B80-A157-A907AF5C68E2) nella documentazione Oracle. + Per informazioni su tutti gli eventi di attesa SQL Server, consulta [Types of Waits](https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql?view=sql-server-2017#WaitTypes) nella documentazione SQL Server. **Nota** Per Oracle, i processi in background a volte funzionano senza istruzioni SQL associate. In questi casi, Performance Insights segnala il tipo di processo in background concatenato da due punti e la classe di attesa associata al processo in background. I tipi di processo in background includono `LGWR`, `ARC0`, `PMON`, e così via. Ad esempio, quando lo strumento di archiviazione esegue I/O, il report di Performance Insights è simile a `ARC1:System I/O`. A volte manca anche il tipo di processo in background e Performance Insights indica 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 di Performance Insights visualizza le prime 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 database, Approfondimenti sulle prestazioni 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 caricamento del database utilizzando i piani, consultare: + Oracle: [Analisi dei piani di esecuzione di Oracle tramite la dashboard di Approfondimenti sulle prestazioni per Amazon RDS](USER_PerfInsights.UsingDashboard.AccessPlans.md) + SQL Server: [Analisi dei piani di esecuzione di SQL Server utilizzando la dashboard Approfondimenti sulle prestazioni per Amazon RDS](USER_PerfInsights.UsingDashboard.AccessPlansSqlServer.md) #### Acquisizione del piano Approfondimenti sulle prestazioni identifica ogni cinque minuti le query che utilizzano più risorse e 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** Performance Insights non acquisisce piani per le query il cui testo supera il limite massimo di testo della query raccolte. Per ulteriori informazioni, consulta [Accesso a una maggiore quantità di testo SQL nel pannello di controllo di Performance Insights](USER_PerfInsights.UsingDashboard.SQLTextSize.md). Il periodo di conservazione per i piani di esecuzione è lo stesso dei dati di Performance 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 Performance Insights](USER_PerfInsights.Overview.cost.md). #### 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.