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à.
Riferimento di tabelle e viste di sistema
Argomenti
- Tabelle e viste di sistema
- Tipi di tabelle e viste di sistema
- Visibilità dei dati nelle tabelle e nelle viste di sistema
- Migrazione delle interrogazioni basate esclusivamente sul provisioning alle interrogazioni di visualizzazione di monitoraggio SYS
- Miglioramento del tracciamento degli identificatori delle query utilizzando le viste di monitoraggio SYS
- ID di interrogazione, processo e sessione della tabella di sistema
- Viste SVV dei metadati
- SYSmonitoraggio delle visualizzazioni
- Mappatura delle viste di sistema per la migrazione alle viste di monitoraggio SYS
- Monitoraggio del sistema (solo con provisioning)
- Tabelle di catalogo di sistema
Tabelle e viste di sistema
Amazon Redshift include numerose tabelle e viste di sistema che contengono informazioni sul funzionamento del sistema. Puoi eseguire delle query su queste tabelle e viste esattamente come faresti con altre tabelle di database. Questa sezione include alcuni esempi di query di tabella di sistema e descrive:
-
Il modo in cui differenti tipi di tabelle e viste di sistema sono generati
-
Quali tipi di informazioni è possibile ottenere da queste tabelle
-
Come eseguire il join di tabelle di sistema di Amazon Redshift a tabelle di catalogo
-
Come gestire l'aumento delle dimensioni dei file di log relativi alle tabelle di sistema
Alcune tabelle di sistema possono essere utilizzate dal AWS personale solo per scopi diagnostici. Le sezioni seguenti descrivono le tabelle di sistema che gli amministratori di sistema o altri utenti di database possono sottoporre a query allo scopo di ottenere informazioni utili.
Nota
Le tabelle di sistema non sono incluse nei backup automatici o manuali dei cluster (snapshot). STLle visualizzazioni di sistema conservano sette giorni di cronologia dei registri. La conservazione dei log non richiede alcuna azione da parte del cliente, ma se desideri archiviare i dati di log per più di 7 giorni, devi copiarli periodicamente in altre tabelle o scaricarli in Amazon S3.
Tipi di tabelle e viste di sistema
Esistono diversi tipi di tabelle e viste di sistema:
SVVle viste contengono informazioni sugli oggetti del database con riferimenti a tabelle transitorieSTV.
SYSle viste vengono utilizzate per monitorare l'utilizzo delle interrogazioni e del carico di lavoro per i cluster predisposti e i gruppi di lavoro senza server.
STLle visualizzazioni vengono generate dai log che sono stati salvati su disco per fornire una cronologia del sistema.
STVle tabelle sono tabelle di sistema virtuali che contengono istantanee dei dati di sistema correnti. Sono basate su dati in memoria transitori e non sono conservate in tabelle normali o log basati su disco.
SVCSle visualizzazioni forniscono dettagli sulle interrogazioni sui cluster di scalabilità principali e simultanei.
SVLle visualizzazioni forniscono dettagli sulle interrogazioni sui cluster principali.
Le tabelle e le viste di sistema non utilizzano lo stesso modello di consistenza delle tabelle normali. È importante essere consapevoli di questo problema quando si eseguono interrogazioni, in particolare per le STV tabelle e le viste. SVV Ad esempio, nel caso di una tabella normale t1 con una colonna c1, la query seguente non dovrebbe restituire righe:
select * from t1 where c1 > (select max(c1) from t1)
Tuttavia, la query seguente su una tabella di sistema potrebbe restituire delle righe:
select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state)
Il motivo è che currentime è transitorio e i due riferimenti nella query potrebbero non restituire lo stesso valore quando valutati.
D'altra parte, la query seguente potrebbe non restituire delle righe:
select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state)
Visibilità dei dati nelle tabelle e nelle viste di sistema
Vi sono due classi di visibilità dei dati nelle tabelle e nelle viste di sistema: visibili agli utenti e visibili agli utenti con privilegi avanzati.
Soltanto gli utenti con privilegi avanzati possono vedere i dati nelle tabelle della categoria visibile agli utenti con privilegi avanzati. Gli utenti standard possono vedere i dati nella tabelle visibili agli utenti. Per consentire a un utente regolare l'accesso alle tabelle visibili dai superutenti, concedi il SELECT privilegio su quella tabella all'utente normale. Per ulteriori informazioni, consulta GRANT.
Per impostazione predefinita, nella maggior parte delle tabelle visibili agli utenti, le righe generate da un altro utente sono invisibili a un utente standard. Se viene assegnato un utente normale SYSLOGACCESSUNRESTRICTED, quell'utente può vedere tutte le righe nelle tabelle visibili all'utente, incluse le righe generate da un altro utente. Per ulteriori informazioni, consulta ALTER USER o CREATE USER. Tutte le righe in SVV _ TRANSACTIONS sono visibili a tutti gli utenti. Per ulteriori informazioni sulla visibilità dei dati, consulta l'articolo della AWS re:Post knowledge base Come posso consentire agli utenti regolari del database Amazon Redshift l'autorizzazione a visualizzare i dati nelle tabelle di sistema di altri utenti del mio cluster?
Per quanto riguarda le visualizzazioni dei metadati, Amazon Redshift non consente la visibilità concessa agli utenti. SYSLOG ACCESS UNRESTRICTED
Nota
Concedere all'utente un accesso illimitato alle tabelle di sistema offre all'utente la visibilità dei dati generati da altri utenti. Ad esempio, STL _ QUERY e STL _ QUERY _ TEXT contengono il testo completo di e DELETE istruzioni INSERTUPDATE, che potrebbero contenere dati sensibili generati dall'utente.
un utente con privilegi avanzati può vedere tutte le righe in tutte le tabelle. Per consentire a un utente normale l'accesso alle tabelle visibili dai superutenti, assegnate GRANT SELECT i privilegi su quella tabella all'utente normale.
Filtraggio delle query generate dal sistema
Le tabelle e le viste di sistema relative alle query, come SVL _ QUERY _SUMMARY, SVL _ QLOG e altre, in genere contengono un gran numero di istruzioni generate automaticamente che Amazon Redshift utilizza per monitorare lo stato del database. Queste query generate dal sistema sono visibili a un utente con privilegi avanzati, ma sono raramente utili. Per filtrarle quando selezioni da una tabella di sistema o da una vista di sistema che utilizza la userid colonna, aggiungi la condizione userid > 1 alla clausola. WHERE Per esempio:
select * from svl_query_summary where userid > 1
Migrazione delle interrogazioni basate esclusivamente sul provisioning alle interrogazioni di visualizzazione di monitoraggio SYS
Migrazione dai cluster con provisioning ad Amazon Redshift serverless
Se stai migrando un cluster con provisioning su Amazon Redshift Serverless, potresti avere domande utilizzando le seguenti viste di sistema, che memorizzano solo i dati dei cluster forniti.
Tutte le visualizzazioni STL
Tutte le STV visualizzazioni
Tutte le SVCS visualizzazioni
Tutte le SVL visualizzazioni
Alcune SVV visualizzazioni
Per un elenco completo delle SVV visualizzazioni non supportate in Amazon Redshift Serverless, consulta l'elenco in fondo alla pagina Monitoraggio delle query e dei carichi di lavoro con Amazon Redshift Serverless nella Amazon Redshift Management Guide.
Per continuare a utilizzare le tue query, modificale in modo da utilizzare le colonne definite nelle viste di SYS monitoraggio che corrispondono alle colonne delle viste a cui è stato assegnato solo il provisioning. Per vedere la relazione di mappatura tra le viste solo predisposte e le viste di monitoraggio, vai a SYS Mappatura delle viste di sistema per la migrazione alle viste di monitoraggio SYS
Aggiornamento delle query restando in un cluster con provisioning
Se non stai effettuando la migrazione ad Amazon Redshift serverless, potresti comunque voler aggiornare le query esistenti. Le viste di SYS monitoraggio sono progettate per facilitare l'uso e ridurre la complessità e forniscono una gamma completa di metriche per un monitoraggio e una risoluzione dei problemi efficaci. Utilizzando SYS viste come SYS_QUERY_HISTORY e SYS_QUERY_DETAIL che consolidano le informazioni di più viste solo predisposte, è possibile semplificare le query.
Miglioramento del tracciamento degli identificatori delle query utilizzando le viste di monitoraggio SYS
SYSviste di monitoraggio come ad esempio SYS_QUERY_HISTORY e SYS_QUERY_DETAIL contengono la colonna query_id, che contiene l'identificatore per le query degli utenti. Analogamente, anche le viste solo con provisioning, come STL_QUERY e SVL_QLOG, contengono la colonna di query con gli identificatori delle query. Tuttavia, gli identificatori di interrogazione registrati nelle viste di SYS sistema sono diversi da quelli registrati nelle viste di solo provisioning.
La differenza tra i valori delle colonne query_id SYS delle viste e i valori delle colonne di interrogazione delle viste solo fornite è la seguente:
Nelle SYS visualizzazioni, la colonna query_id registra le query inviate dall'utente nel formato originale. Il sistema di ottimizzazione di Amazon Redshift può suddividerle in query figlio per migliorare le prestazioni, ma ogni singola query eseguita avrà comunque una propria riga in SYS_QUERY_HISTORY. Se desideri visualizzare le singole query figlio, sono disponibili in SYS_QUERY_DETAIL.
Nelle viste solo con provisioning, la colonna di query registra le query a livello di query figlio. Se il sistema di ottimizzazione di Amazon Redshift riscrive la query originale in più query figlio, verranno inserite più righe in STL_QUERY con identificatori di query diversi per ogni singola query eseguita.
Quando esegui la migrazione delle interrogazioni di monitoraggio e diagnostica da viste solo predisposte a visualizzazioni, tieni conto di questa differenza e modifica le query di conseguenzaSYS. Per ulteriori informazioni su come Amazon Redshift elabora le query, consulta Pianificazione di query e flusso di lavoro di esecuzione.
Esempio
Per un esempio di come Amazon Redshift registra le query in modo diverso nelle viste di solo provisioning e di SYS monitoraggio, consulta la seguente query di esempio. Questa query è scritta per essere eseguita in Amazon Redshift.
SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.l_suppkey AND o_orderkey = l1.l_orderkey AND o_orderstatus = 'F' AND l1.l_receiptdate > l1.l_commitdate AND EXISTS (SELECT * FROM lineitem l2 WHERE l2.l_orderkey = l1.l_orderkey AND l2.l_suppkey <> l1.l_suppkey ) AND NOT EXISTS (SELECT * FROM lineitem l3 WHERE l3.l_orderkey = l1.l_orderkey AND l3.l_suppkey <> l1.l_suppkey AND l3.l_receiptdate > l3.l_commitdate ) AND s_nationkey = n_nationkey AND n_name = 'UNITED STATES' GROUP BY s_name ORDER BY numwait DESC , s_name LIMIT 100;
Dietro le quinte, il sistema di ottimizzazione di query di Amazon Redshift riscrive la precedente query inviata dall'utente in cinque query figlio.
La prima query figlio crea una tabella temporanea per materializzare una sottoquery.
CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey , l_suppkey , s_name ) AS SELECT l1.l_orderkey , l1.l_suppkey , public.supplier.s_name FROM public.lineitem AS l1, public.nation, public.orders, public.supplier WHERE l1.l_commitdate < l1.l_receiptdate AND l1.l_orderkey = public.orders.o_orderkey AND l1.l_suppkey = public.supplier.s_suppkey AND public.nation.n_name = 'UNITED STATES'::CHAR(8) AND public.nation.n_nationkey = public.supplier.s_nationkey AND public.orders.o_orderstatus = 'F'::CHAR(1);
La seconda query figlio raccoglie le statistiche dalla tabella temporanea.
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
La terza query figlio crea un'altra tabella temporanea per materializzare un'altra sottoquery, facendo riferimento alla tabella temporanea creata in precedenza.
CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey , l_suppkey) AS (SELECT volt_tt_606590308b512.l_orderkey , volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l2, volt_tt_606590308b512 WHERE l2.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l2.l_orderkey = volt_tt_606590308b512.l_orderkey) EXCEPT distinct (SELECT volt_tt_606590308b512.l_orderkey, volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l3, volt_tt_606590308b512 WHERE l3.l_commitdate < l3.l_receiptdate AND l3.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l3.l_orderkey = volt_tt_606590308b512.l_orderkey);
La quarta query figlio raccoglie nuovamente le statistiche dalla tabella temporanea.
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
L'ultima query figlio utilizza le tabelle temporanee create in precedenza per generare l'output.
SELECT volt_tt_606590308b512.s_name AS s_name , COUNT(*) AS numwait FROM volt_tt_606590308b512, volt_tt_606590308c2ef WHERE volt_tt_606590308b512.l_orderkey = volt_tt_606590308c2ef.l_orderkey AND volt_tt_606590308b512.l_suppkey = volt_tt_606590308c2ef.l_suppkey GROUP BY 1 ORDER BY 2 DESC , 1 ASC LIMIT 100;
Nella visualizzazione di sistema di solo provisioning STL _, Amazon QUERY Redshift registra cinque righe a livello di query figlio, come segue:
SELECT userid, xid, pid, query, querytxt::varchar(100); FROM stl_query WHERE xid = 48237350 ORDER BY xid, starttime;userid | xid | pid | query | querytxt --------+----------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058151 | CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey, l_suppkey, s_name) AS SELECT l1.l_orderkey, l1.l 101 | 48237350 | 1073840810 | 12058152 | padb_fetch_sample: select count(*) from volt_tt_606590308b512 101 | 48237350 | 1073840810 | 12058156 | CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey, l_suppkey) AS (SELECT volt_tt_606590308b512.l_or 101 | 48237350 | 1073840810 | 12058168 | padb_fetch_sample: select count(*) from volt_tt_606590308c2ef 101 | 48237350 | 1073840810 | 12058170 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1. (5 rows)
Nella vista di SYS monitoraggio SYS _ QUERY _HISTORY, Amazon Redshift registra la query come segue:
SELECT user_id, transaction_id, session_id, query_id, query_text::varchar(100) FROM sys_query_history WHERE transaction_id = 48237350 ORDER BY start_time;user_id | transaction_id | session_id | query_id | query_text ---------+----------------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058149 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.
In SYS _ QUERY _DETAIL, puoi trovare i dettagli a livello di query secondaria utilizzando il valore query_id di _ _. SYS QUERY HISTORY La colonna child_query_sequence mostra l'ordine in cui vengono eseguite le query figlio. Per ulteriori informazioni sulle colonne in SYS _ _, vedere. QUERY DETAIL SYS_QUERY_DETAIL
select user_id, query_id, child_query_sequence, stream_id, segment_id, step_id, start_time, end_time, duration, blocks_read, blocks_write, local_read_io, remote_read_io, data_skewness, time_skewness, is_active, spilled_block_local_disk, spilled_block_remote_disk from sys_query_detail where query_id = 12058149 and step_id = -1 order by query_id, child_query_sequence, stream_id, segment_id, step_id;user_id | query_id | child_query_sequence | stream_id | segment_id | step_id | start_time | end_time | duration | blocks_read | blocks_write | local_read_io | remote_read_io | data_skewness | time_skewness | is_active | spilled_block_local_disk | spilled_block_remote_disk ---------+----------+----------------------+-----------+------------+---------+----------------------------+----------------------------+----------+-------------+--------------+---------------+----------------+---------------+---------------+-----------+--------------------------+--------------------------- 101 | 12058149 | 1 | 0 | 0 | -1 | 2023-09-27 15:40:38.512415 | 2023-09-27 15:40:38.533333 | 20918 | 0 | 0 | 0 | 0 | 0 | 44 | f | 0 | 0 101 | 12058149 | 1 | 1 | 1 | -1 | 2023-09-27 15:40:39.931437 | 2023-09-27 15:40:39.972826 | 41389 | 12 | 0 | 12 | 0 | 0 | 77 | f | 0 | 0 101 | 12058149 | 1 | 2 | 2 | -1 | 2023-09-27 15:40:40.584412 | 2023-09-27 15:40:40.613982 | 29570 | 32 | 0 | 32 | 0 | 0 | 25 | f | 0 | 0 101 | 12058149 | 1 | 2 | 3 | -1 | 2023-09-27 15:40:40.582038 | 2023-09-27 15:40:40.615758 | 33720 | 0 | 0 | 0 | 0 | 0 | 1 | f | 0 | 0 101 | 12058149 | 1 | 3 | 4 | -1 | 2023-09-27 15:40:46.668766 | 2023-09-27 15:40:46.705456 | 36690 | 24 | 0 | 15 | 0 | 0 | 17 | f | 0 | 0 101 | 12058149 | 1 | 4 | 5 | -1 | 2023-09-27 15:40:46.707209 | 2023-09-27 15:40:46.709176 | 1967 | 0 | 0 | 0 | 0 | 0 | 18 | f | 0 | 0 101 | 12058149 | 1 | 4 | 6 | -1 | 2023-09-27 15:40:46.70656 | 2023-09-27 15:40:46.71289 | 6330 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 1 | 5 | 7 | -1 | 2023-09-27 15:40:46.71405 | 2023-09-27 15:40:46.714343 | 293 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 2 | 0 | 0 | -1 | 2023-09-27 15:40:52.083907 | 2023-09-27 15:40:52.087854 | 3947 | 0 | 0 | 0 | 0 | 0 | 35 | f | 0 | 0 101 | 12058149 | 2 | 1 | 1 | -1 | 2023-09-27 15:40:52.089632 | 2023-09-27 15:40:52.091129 | 1497 | 0 | 0 | 0 | 0 | 0 | 11 | f | 0 | 0 101 | 12058149 | 2 | 1 | 2 | -1 | 2023-09-27 15:40:52.089008 | 2023-09-27 15:40:52.091306 | 2298 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 0 | 0 | -1 | 2023-09-27 15:40:56.882013 | 2023-09-27 15:40:56.897282 | 15269 | 0 | 0 | 0 | 0 | 0 | 29 | f | 0 | 0 101 | 12058149 | 3 | 1 | 1 | -1 | 2023-09-27 15:40:59.718554 | 2023-09-27 15:40:59.722789 | 4235 | 0 | 0 | 0 | 0 | 0 | 13 | f | 0 | 0 101 | 12058149 | 3 | 2 | 2 | -1 | 2023-09-27 15:40:59.800382 | 2023-09-27 15:40:59.807388 | 7006 | 0 | 0 | 0 | 0 | 0 | 58 | f | 0 | 0 101 | 12058149 | 3 | 3 | 3 | -1 | 2023-09-27 15:41:06.488685 | 2023-09-27 15:41:06.493825 | 5140 | 0 | 0 | 0 | 0 | 0 | 56 | f | 0 | 0 101 | 12058149 | 3 | 3 | 4 | -1 | 2023-09-27 15:41:06.486206 | 2023-09-27 15:41:06.497756 | 11550 | 0 | 0 | 0 | 0 | 0 | 2 | f | 0 | 0 101 | 12058149 | 3 | 4 | 5 | -1 | 2023-09-27 15:41:06.499201 | 2023-09-27 15:41:06.500851 | 1650 | 0 | 0 | 0 | 0 | 0 | 15 | f | 0 | 0 101 | 12058149 | 3 | 4 | 6 | -1 | 2023-09-27 15:41:06.498609 | 2023-09-27 15:41:06.500949 | 2340 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 5 | 7 | -1 | 2023-09-27 15:41:06.502945 | 2023-09-27 15:41:06.503282 | 337 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 4 | 0 | 0 | -1 | 2023-09-27 15:41:06.62899 | 2023-09-27 15:41:06.631452 | 2462 | 0 | 0 | 0 | 0 | 0 | 22 | f | 0 | 0 101 | 12058149 | 4 | 1 | 1 | -1 | 2023-09-27 15:41:06.632313 | 2023-09-27 15:41:06.63391 | 1597 | 0 | 0 | 0 | 0 | 0 | 20 | f | 0 | 0 101 | 12058149 | 4 | 1 | 2 | -1 | 2023-09-27 15:41:06.631726 | 2023-09-27 15:41:06.633813 | 2087 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 5 | 0 | 0 | -1 | 2023-09-27 15:41:12.571974 | 2023-09-27 15:41:12.584234 | 12260 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 0 | 1 | -1 | 2023-09-27 15:41:12.569815 | 2023-09-27 15:41:12.585391 | 15576 | 0 | 0 | 0 | 0 | 0 | 4 | f | 0 | 0 101 | 12058149 | 5 | 1 | 2 | -1 | 2023-09-27 15:41:13.758513 | 2023-09-27 15:41:13.76401 | 5497 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 1 | 3 | -1 | 2023-09-27 15:41:13.749 | 2023-09-27 15:41:13.772987 | 23987 | 0 | 0 | 0 | 0 | 0 | 32 | f | 0 | 0 101 | 12058149 | 5 | 2 | 4 | -1 | 2023-09-27 15:41:13.799526 | 2023-09-27 15:41:13.813506 | 13980 | 0 | 0 | 0 | 0 | 0 | 62 | f | 0 | 0 101 | 12058149 | 5 | 2 | 5 | -1 | 2023-09-27 15:41:13.798823 | 2023-09-27 15:41:13.813651 | 14828 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 (28 rows)
ID di interrogazione, processo e sessione della tabella di sistema
Quando analizzate gli ID di interrogazione, processo e sessione visualizzati nelle tabelle di sistema, tenete presente quanto segue:
Il valore dell'ID della query (in colonne come
query_idequery) può essere riutilizzato nel tempo.L'id del processo o il valore dell'id della sessione (in colonne come
process_idpid, esession_id) può essere riutilizzato nel tempo.Il valore dell'ID della transazione (in colonne come
transaction_idexid) è unico.
