Utilizzo della vista SVL _ _ QUERY SUMMARY - Amazon Redshift

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à.

Utilizzo della vista SVL _ _ QUERY SUMMARY

Per analizzare le informazioni di riepilogo delle query utilizzando lo streamSVL_QUERY_SUMMARY, procedi come segue:

  1. Esegui la seguente query per determinare l'ID della tua query:

    select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;

    Esamina il testo troncato della query nel campo substring per determinare quale valore query rappresenta la tua query. Se hai eseguito la query più di una volta, utilizza il valore query a partire dalla riga con il valore elapsed più basso. Questa è la riga per la versione compilata. Se sono state eseguite molte query, è possibile aumentare il valore utilizzato dalla LIMIT clausola utilizzata per assicurarsi che la query sia inclusa.

  2. Seleziona le righe da SVL _ QUERY _ SUMMARY per la tua query. Ordina i risultati per flusso, segmento e fase:

    select * from svl_query_summary where query = MyQueryID order by stm, seg, step;

    Di seguito è riportato un risultato di esempio.

    Un esempio di risultato per le righe in SVL _ QUERY _ SUMMARY che corrispondono a una determinata query.

  3. Per mappare le fasi per le operazioni nel piano di query, consultare le informazioni contenute in Mappatura del piano di query sul riepilogo della query. Dovrebbero avere approssimativamente lo stesso valore per righe e byte (righe * larghezza del piano di query). Altrimenti, consultare Statistiche della tabella mancanti o scadute per le soluzioni consigliate.

  4. Verifica che il campo is_diskbased abbia un valore t (true) per ogni fase. Hash, Aggregate e Sort sono gli operatori che, probabilmente, scriveranno dati al disco nel caso in cui il sistema non abbia abbastanza memoria allocata per l'elaborazione della query.

    Se is_diskbased ha il valore "true", consultare Memoria insufficiente allocata alla query per le soluzioni consigliate.

  5. Esamina i valori del label campo e verifica se c'è una AGG-DIST-AGG sequenza in qualche punto dei passaggi. La sua presenza indica l'aggregazione a due fasi, che è molto costosa. Per risolvere questo problema, modifica la clausola GROUP BY in modo da utilizzare la chiave di distribuzione (la prima chiave, se ce ne sono più di una).

  6. Rivedi il valore maxtime per ogni segmento (è lo stesso all'interno di tutte le fasi nel segmento). Identifica il segmento con il valore maxtime più alto e rivedi le fasi in questo segmento per i seguenti operatori.

    Nota

    Un valore maxtime alto non indica necessariamente che ci sia un problema con il segmento. Nonostante abbia un valore alto, il segmento potrebbe non aver impiegato molto tempo per essere elaborato. Tutti i segmenti in un flusso cominciano a programmarsi all'unisono. Tuttavia, è possibile che alcuni segmenti downstream non possano essere eseguiti finché non si ottengono dati da quelli upstream. Questo effetto fa sì che appaia abbiano impiegato più tempo, dato che il loro valore maxtime includerà sia il tempo di attesa che quello di elaborazione.

    • BCASToppure DIST: In questi casi, il maxtime valore più alto potrebbe essere il risultato della ridistribuzione di un gran numero di righe. Per le soluzioni consigliate, consultare Distribuzione dei dati non ottimale.

    • HJOIN(hash join): se il passaggio in questione ha un valore molto alto nel rows campo rispetto al rows valore del RETURN passaggio finale della query, vedi Hash join per le soluzioni consigliate.

    • SCAN/SORT: Cerca unaSCAN, SORTSCAN, MERGE sequenza di passaggi appena prima di un passaggio di unione. Questo modello indica che i dati non ordinati sono stati scansionati e uniti all'area ordinata della tabella.

      Verifica se il valore delle righe per il SCAN passaggio ha un valore molto elevato rispetto al valore delle righe nel RETURN passaggio finale della query. Questo modello indica che il motore di esecuzione sta scansionando le file che verranno eliminate, il che è inefficiente. Per le soluzioni consigliate, consultare Predicato poco restrittivo.

      Se il maxtime valore del SCAN passaggio è elevato, consulta WHEREClausola non ottimale le soluzioni consigliate.

      Se il rows valore del SORT passo è diverso da zero, consulta Righe non ordinate o ordinate in modo errato le soluzioni consigliate.

  7. Esamina bytes i valori rows and per i 5-10 passaggi che precedono il RETURN passaggio finale per avere un'idea della quantità di dati che viene restituita al client. Questo processo può essere un po' un'arte.

    Ad esempio, nel seguente riepilogo della query di esempio, il terzo PROJECT passaggio fornisce un rows valore, ma non un valore. bytes Esaminando i passaggi precedenti per trovarne uno con lo stesso rows valore, si trova il SCAN passaggio che fornisce informazioni sia sulle righe che sui byte.

    Di seguito è riportato un risultato di esempio.

    Una riga del riepilogo dei risultati della query che è un SCAN passaggio con informazioni sia sulle righe che sui byte.

    Se stai restituendo un grande volume insolito dei dati, consultare Insieme di risultati molto grande per le soluzioni consigliate.

  8. Verifica se per ogni fase il valore bytes è alto rispetto al valore rows rispetto alle altre fasi. Questo modello può indicare che stai selezionando molte colonne. Per le soluzioni consigliate, consultare SELECTElenco ampio.