Amazon Redshift non supporterà più la creazione di nuove UDF Python a partire dalla Patch 198. Le UDF Python esistenti continueranno a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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à.
# Regole di monitoraggio delle query WLM
Nella gestione del carico di lavoro (WLM) di Amazon Redshift, le regole di monitoraggio delle query definiscono i limiti delle prestazioni basati sui parametri per le code WLM e specificano l'operazione da eseguire quando una query oltrepassa tali limiti. Ad esempio, per una coda dedicata alle query di breve durata, puoi creare una regola che annulla le query eseguite per più di 60 secondi. Per tracciare le query mal progettate, potresti avere un'altra regola che registra le query che contengono cicli annidati.
Le regole di monitoraggio delle query vengono definite come parte della configurazione della gestione del carico di lavoro (WLM). Puoi definire fino a 25 regole per ogni coda, con un limite di 25 regole per tutte le code. Ogni regola include fino a tre condizioni o predicati e un'azione. Un *predicato* è formato da un parametro, una condizione di confronto (=, < o >) e un valore. Se tutti i predicati di una regola sono soddisfatti, viene attivata l'azione di quella regola. Le possibili azioni delle regole sono registrazione, hop e interruzione, come discusso di seguito.
Le regole in una determinata coda si applicano solo alle query in esecuzione in quella coda. Una regola è indipendente dalle altre regole.
WLM calcola i parametri ogni 10 secondi. Amazon Redshift applica le regole di monitoraggio delle query a livello di query secondarie quando le query vengono riscritte automaticamente. Se nello stesso periodo sono attivate più regole, WLM sceglie la regola con l’operazione più severa. Se l’azione per due regole ha la stessa gravità, WLM esegue le regole in ordine alfabetico, in base al nome della regola. Se l'azione è hop o interruzione, viene registrata e la query viene rimossa dalla coda. Se l'azione è registrazione, la query continua l'esecuzione nella coda. WLM avvia una sola azione di registrazione per query per regola. Se la coda contiene altre regole, tali regole rimangono in vigore. Se l'azione è hop e la query viene instradata su un'altra coda, si applicano le regole della nuova coda. Per ulteriori informazioni sul monitoraggio delle query e sulle operazioni di tracciamento effettuate su query specifiche, consulta la raccolta di esempi all'indirizzo [Accelerazione di query brevi](wlm-short-query-acceleration.md).
Quando tutti i predicati di una regola vengono soddisfatti, WLM scrive una riga nella tabella di sistema [STL\_WLM\_RULE\_ACTION](r_STL_WLM_RULE_ACTION.md). Inoltre, Amazon Redshift registra i parametri delle query per le query attualmente in esecuzione su [STV\_QUERY\_METRICS](r_STV_QUERY_METRICS.md). I parametri delle query completate sono archiviati in [STL\_QUERY\_METRICS](r_STL_QUERY_METRICS.md).
**Nota**
Per Amazon Redshift Serverless, puoi configurare code di query e regole di monitoraggio utilizzando il parametro. `wlm_json_configuration` Ciò consente di creare più code con ruoli utente, gruppi di query e regole di monitoraggio diversi. *Per ulteriori informazioni sulla configurazione delle code di query serverless, consulta [Setting query queues](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html) nella Amazon Redshift Management Guide.*
## Definizione di una regola di monitoraggio delle query
Le regole di monitoraggio delle query vengono create come parte della configurazione WLM definita nella definizione del gruppo di parametri del cluster.
Puoi creare regole usando o usando JSON a livello di codice Console di gestione AWS .
**Nota**
Se scegli di creare regole a livello di programmazione, ti consigliamo vivamente di utilizzare la console per generare il JSON da includere nella definizione del gruppo di parametri. Per ulteriori informazioni, consulta [Creazione di una regola di monitoraggio delle query](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) e [Configurazione dei valori di parametro mediante AWS CLI](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html#configure-parameters-using-the-cli) nella *Guida alla gestione di Amazon Redshift*.
Per definire una regola di monitoraggio della query, è necessario specificare i seguenti elementi:
+ Un nome di regola: i nomi delle regole devono essere univoci all'interno della configurazione WLM. Possono essere composti da un massimo di 32 caratteri alfanumerici o caratteri di sottolineatura e non possono contenere spazi o virgolette. Puoi avere fino a 25 regole per coda, che è anche il limite complessivo di tutte le code.
+ Uno o più predicati: ogni regola può avere fino a tre predicati. Se tutti i predicati di una regola sono soddisfatti, viene attivata l'azione associata. Un predicato è definito da un nome parametro, un operatore (=, < o >) e un valore. Un esempio è `query_cpu_time > 100000`. Per un elenco di parametri ed esempi di valori per parametri diversi, vedi [Metriche per il monitoraggio delle query per Amazon Redshift](#cm-c-wlm-query-monitoring-metrics) dopo questa sezione.
+ Un'operazione: se sono attivate più regole, WLM sceglie la regola con l'operazione più severa. Le possibili azioni, in ordine crescente di gravità, sono:
+ Registra: registra le informazioni sulla query nella tabella di sistema STL\_WLM\_RULE\_ACTION. Usa l'azione di registrazione quando vuoi scrivere solo un record di log. WLM crea al massimo una registrazione per query per regola. A seguito di un'azione di registrazione, restano in vigore altre regole e WLM continua a monitorare la query.
+ Hop (disponibile solo con WLM manuale): registra l'azione e passa la query alla coda corrispondente successiva. Se non esiste alcuna coda corrispondente, la query viene annullata. QMR salta solo le istruzioni [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) (CTAS) e le query di sola lettura, ad esempio le istruzioni SELECT. Per ulteriori informazioni, consulta [Hop della coda di query WLM](wlm-queue-hopping.md).
+ Interrompi: registra l'azione e annulla la query. Le istruzioni COPY e le operazioni di manutenzione, come ALTER, ANALYZE e VACUUM, non vengono interrotte da QMR.
+ Modifica priorità (disponibile solo con WLM automatica): modifica la priorità di una query.
Per limitare l'esecuzione di query, ti consigliamo di creare una regola di monitoraggio di query anziché utilizzare un timeout WLM. Ad esempio, puoi impostare `max_execution_time` su 50.000 millisecondi, come illustrato nel seguente frammento di codice JSON.
```
"max_execution_time": 50000
```
Tuttavia consigliamo di definire una regola di monitoraggio delle query equivalente. L’esempio seguente illustra una regola di monitoraggio delle query che imposta `query_execution_time` su 50 secondi:
```
"rules":
[
{
"rule_name": "rule_query_execution",
"predicate": [
{
"metric_name": "query_execution_time",
"operator": ">",
"value": 50
}
],
"action": "abort"
}
]
```
Per le fasi di creazione o modifica di una regola di monitoraggio delle query, consulta [Creazione di una regola di monitoraggio delle query](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) e [Proprietà nel parametro wlm\_json\_configuration](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html#wlm-json-config-properties) nella *Guida alla gestione di Amazon Redshift*.
Ulteriori informazioni sulle regole di monitoraggio delle query sono disponibili nei seguenti argomenti:
+ [Metriche per il monitoraggio delle query per Amazon Redshift](#cm-c-wlm-query-monitoring-metrics)
+ [Modelli di regole di monitoraggio delle query](#cm-c-wlm-query-monitoring-templates)
+ [Creazione di una regola di monitoraggio delle query](https://docs.aws.amazon.com/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)
+ [Configurazione della gestione del carico di lavoro](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)
+ [Tabelle e viste di sistema per le regole di monitoraggio delle query](#cm-c-wlm-qmr-tables-and-views)
## Metriche per il monitoraggio delle query per Amazon Redshift
Nella tabella seguente vengono descritti i parametri usati nelle regole di monitoraggio delle query. Questi parametri sono diversi da quelli memorizzati nelle tabelle di sistema [STV\_QUERY\_METRICS](r_STV_QUERY_METRICS.md) e [STL\_QUERY\_METRICS](r_STL_QUERY_METRICS.md).
Per un determinato parametro, la soglia delle prestazioni viene tracciata a livello di query o di segmento. Per ulteriori informazioni sui segmenti e sulle fasi, consultare [Pianificazione di query e flusso di lavoro di esecuzione](c-query-planning.md).
**Nota**
Il parametro [Timeout WLM](cm-c-defining-query-queues.md#wlm-timeout) è diverso dalle regole di monitoraggio delle query.
| Metrica | Nome | Description |
| --- | --- | --- |
| Tempo CPU query | query\_cpu\_time | Tempo di CPU utilizzato dalla query, in secondi. CPU time è diverso da Query execution time. I valori validi sono compresi nell'intervallo 0-999.999. |
| Blocchi letti | query\_blocks\_read | Numero di blocchi di dati da 1 MB letti dalla query.I valori validi sono compresi nell'intervallo 0-1.048.575. |
| Analizza conteggio righe | scan\_row\_count | Il numero di righe in una fase di scansione. Il conteggio delle righe è il numero totale di righe generate prima di aver applicato filtri alle righe contrassegnate per l'eliminazione (righe fantasma) e prima dell'applicazione di filtri di query definiti dall'utente.
I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Tempo di esecuzione query | query\_execution\_time | Tempo di esecuzione trascorso per una query, in secondi. Il tempo di esecuzione non include il tempo trascorso in attesa in una coda.I valori validi sono compresi nell'intervallo 0-86.399. |
| Tempo nella coda di query | query\_queue\_time | Tempo trascorso in attesa in coda, in secondi. I valori validi sono compresi nell'intervallo 0-86.399. |
| Utilizzo CPU | query\_cpu\_usage\_percent | Percentuale di capacità della CPU utilizzata dalla query.I valori validi sono compresi nell'intervallo 0-6.399. |
| Memoria su disco | query\_temp\_blocks\_to\_disk | Spazio su disco temporaneo utilizzato per scrivere risultati intermedi, in blocchi da 1 MB.I valori validi sono compresi nell'intervallo 0-319.815.679. |
| Differenza CPU | cpu\_skew | Il rapporto tra l'utilizzo di CPU massimo per ogni sezione e l'utilizzo di CPU medio per tutte le sezioni. Questo parametro viene definito a livello di segmento.I valori validi sono compresi nell'intervallo 0-99. |
| I/O inclinare | io\_skew | Il rapporto tra il numero massimo di blocchi read (I/O) per ogni slice e la media dei blocchi letti per tutte le slice. Questo parametro viene definito a livello di segmento.I valori validi sono compresi nell'intervallo 0-99. |
| Righe unite | join\_row\_count | Il numero di righe elaborate in una fase di unione.I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Conteggio righe unione loop nidificati | nested\_loop\_join\_row\_count | Il numero o le righe di un'unione loop nidificate.I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Restituisci conteggio righe | return\_row\_count | Il numero di righe restituite dalla query. I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Tempo di esecuzione segmento | segment\_execution\_time | Tempo di esecuzione trascorso per un singolo segmento, in secondi. Per evitare o ridurre gli errori di campionamento, includi segment\_execution\_time > 10 nelle regole.I valori validi sono compresi nell'intervallo 0-86.388. |
| Analizza conteggio righe Spectrum | spectrum\_scan\_row\_count | Il numero di righe di dati in Amazon S3 scansionate da una query di Amazon Redshift Spectrum. I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Dimensione analisi Spectrum | spectrum\_scan\_size\_mb | La dimensione in MB dei dati in Amazon S3 scansionati da una query Amazon Redshift Spectrum.I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Priorità delle query | query\_priority | La priorità della query. I valori validi sono `HIGHEST`, `HIGH`, `NORMAL`, `LOW` e `LOWEST`. Quando confronti `query_priority` utilizzando gli operator maggiore di (>) e inferiore a (<) operators, `HIGHEST` è maggiore di `HIGH`, `HIGH` è maggiore di `NORMAL` e così via. |
**Nota**
L'operazione hop non è supportata con il predicato `query_queue_time`. Vale a dire che le regole definite per l'hop quando un predicato `query_queue_time` viene soddisfatto vengono ignorate.
I tempi di esecuzione dei segmenti brevi possono causare errori di campionamento con alcuni parametri, ad esempio `io_skew` e `query_cpu_usage_percent`. Per evitare o ridurre gli errori di campionamento, includi il tempo di esecuzione dei segmenti nelle regole. Un buon punto di partenza è `segment_execution_time > 10`.
La vista [SVL\_QUERY\_METRICS](r_SVL_QUERY_METRICS.md) mostra i parametri per le query completate. La vista [SVL\_QUERY\_METRICS\_SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) mostra i valori massimi dei parametri per le query completate. Utilizza i valori in queste viste come aiuto per determinare i valori di soglia per la definizione delle regole di monitoraggio delle query.
## Metriche per il monitoraggio delle query per Amazon Redshift serverless
Nella tabella seguente vengono descritti i parametri utilizzati nelle regole per il monitoraggio delle query per Amazon Redshift serverless.
| Metrica | Nome del predicato WLM | Nome | Description |
| --- | --- | --- | --- |
| Blocchi letti | query\_blocks\_read | max\_query\_blocks\_read | Numero di blocchi di dati da 1 MB letti dalla query.I valori validi sono compresi nell'intervallo 0-1.048.575. |
| Analizza conteggio righe | scan\_row\_count | max\_scan\_row\_count | Il numero di righe in una fase di scansione. Il conteggio delle righe è il numero totale di righe generate prima di aver applicato filtri alle righe contrassegnate per l'eliminazione (righe fantasma) e prima dell'applicazione di filtri di query definiti dall'utente.
I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Tempo di esecuzione query | query\_execution\_time | max\_query\_execution\_time | Tempo di esecuzione trascorso per una query, in secondi. Il tempo di esecuzione non include il tempo trascorso in attesa in una coda. Se una query supera il tempo di esecuzione impostato, Amazon Redshift Serverless la arresta.
I valori validi sono compresi nell'intervallo 0-86.399. |
| Tempo nella coda di query | query\_queue\_time | max\_query\_queue\_time | Tempo trascorso in attesa in coda, in secondi. I valori validi sono compresi nell'intervallo 0-86.399. |
| Memoria su disco | query\_temp\_blocks\_to\_disk | max\_query\_temp\_blocks\_to\_disk | Spazio su disco temporaneo utilizzato per scrivere risultati intermedi, in blocchi da 1 MB.I valori validi sono compresi nell'intervallo 0-319.815.679. |
| Righe unite | join\_row\_count | max\_join\_row\_count | Il numero di righe elaborate in una fase di unione.I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
| Conteggio righe unione loop nidificati | nested\_loop\_join\_row\_count | max\_nested\_loop\_join\_row\_count | Il numero o le righe di un'unione loop nidificate.I valori validi sono compresi nell'intervallo 0-999.999.999.999.999. |
**Nota**
L'operazione hop non è supportata con il predicato `max_query_queue_time`. Vale a dire che le regole definite per l'hop quando un predicato `max_query_queue_time` viene soddisfatto vengono ignorate.
I tempi di esecuzione dei segmenti brevi possono causare errori di campionamento con alcuni parametri, ad esempio `max_io_skew` e `max_query_cpu_usage_percent`.
Per Amazon Redshift Serverless, puoi configurare code di query e regole di monitoraggio utilizzando il parametro. `wlm_json_configuration` Ciò consente di creare più code con ruoli utente, gruppi di query e regole di monitoraggio diversi utilizzando i parametri sopra elencati. *Per ulteriori informazioni sulla configurazione delle code di query serverless, consulta la struttura di [configurazione WLM JSON nella](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-query-queues.html#serverless-wlm-json-configuration) Amazon Redshift Management Guide.*
## Modelli di regole di monitoraggio delle query
Quando si aggiunge una regola tramite la console Amazon Redshift, è possibile scegliere di creare una regola da un modello predefinito. Amazon Redshift crea una nuova regola con un set di predicati e popola i predicati con i valori di default. L'azione predefinita è registrazione. Puoi modificare i predicati e l'azione per soddisfare il tuo caso d'uso.
La tabella seguente elenca i modelli disponibili.
| Nome modello | Predicati | Description |
| --- | --- | --- |
| Nested loop join | nested\_loop\_join\_row\_count > 100 | Un'unione loop nidificata potrebbe indicare un predicato di unione incompleto che spesso determina la restituzione di un set molto grande (un prodotto cartesiano). Utilizza un conteggio di riga basso per trovare in anticipo una query con potenzialmente un eccessivo tempo di esecuzione. |
| La query restituisce un numero elevato di righe | return\_row\_count > 1000000 | Se dedichi una coda a query semplici a esecuzione breve, è possibile includere una regola che trova le query che restituiscono un conteggio elevato di righe. Il modello utilizza un valore predefinito di 1 milione di righe. Per alcuni sistemi, potresti considerare un milione di righe un conteggio elevato oppure in un sistema più grande, un miliardo o più di righe potrebbero essere un conteggio elevato. |
| Esegui l'unione con un numero elevato di righe | join\_row\_count > 1000000000 | Una fase di unione che comporta un numero insolitamente elevato di righe potrebbe indicare la necessità di filtri più restrittivi. Il modello utilizza un valore predefinito di 1 miliardo di righe. Per una coda ad hoc (una tantum) destinata a query semplici e veloci, è possibile utilizzare un numero inferiore. |
| Utilizzo del disco intensivo durante la scrittura di risultati intermedi | query\_temp\_blocks\_to\_disk > 100000 | Quando le query attualmente in esecuzione utilizzano più RAM di sistema di quella disponibile, il motore di esecuzione della query scrive i risultati intermedi sul disco (memoria vuota). In genere, questa condizione è il risultato di una query di tipo rogue che di solito è anche la query che utilizza la maggior parte dello spazio su disco. La soglia accettabile per l'utilizzo del disco varia in base al tipo di nodo del cluster e al numero di nodi. Il modello utilizza un valore predefinito di 100.000 blocchi o 100 GB. Per un piccolo cluster, è possibile utilizzare un numero inferiore. |
| Query di lunga durata con inclinazione elevata I/O | segment\_execution\_time > 120 e io\_skew > 1.30 | I/O l'inclinazione si verifica quando una sezione del nodo ha una I/O velocità molto più elevata rispetto alle altre slice. Come punto di partenza, una differenza di 1,30 (1,3 volte la media) è considerata alta. L' I/O inclinazione elevata non è sempre un problema, ma se combinata con un tempo di interrogazione di lunga durata, potrebbe indicare un problema con lo stile di distribuzione o la chiave di ordinamento. |
## Tabelle e viste di sistema per le regole di monitoraggio delle query
Quando tutti i predicati di una regola vengono soddisfatti, WLM scrive una riga nella tabella di sistema [STL\_WLM\_RULE\_ACTION](r_STL_WLM_RULE_ACTION.md). Questa riga contiene i dettagli della query che ha attivato la regola e l'operazione derivante.
Inoltre, Amazon Redshift registra i parametri per le query per le seguenti tabelle e viste di sistema.
+ La tabella [STV\_QUERY\_METRICS](r_STV_QUERY_METRICS.md) visualizza i parametri per le query attualmente in esecuzione.
+ La tabella [STL\_QUERY\_METRICS](r_STL_QUERY_METRICS.md) registra i parametri per le query completate.
+ La vista [SVL\_QUERY\_METRICS](r_SVL_QUERY_METRICS.md) mostra i parametri per le query completate.
+ La vista [SVL\_QUERY\_METRICS\_SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) mostra i valori massimi dei parametri per le query completate.