Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Informations de référence sur les tables et les vues système
Amazon Redshift comporte de nombreuses tables et vues système contenant des informations sur le fonctionnement du système. Vous pouvez interroger ces tables et vues système de la même manière que vous interrogez toute autre table de base de données. Cette section présente des exemples de requêtes de table système et explique :
-
comment les différents types de tables et de vues système sont générés ;
-
quels types d'informations vous pouvez obtenir à partir de ces tables ;
-
comment joindre des tables système Amazon Redshift à des tables de catalogue ;
-
comment gérer la croissance des fichiers journaux de table système.
Certaines tables système ne peuvent être utilisées que par le AWS personnel à des fins de diagnostic. Les sections suivantes décrivent les tables système qui peuvent être interrogées par les administrateurs système ou d'autres utilisateurs de base de données afin d'obtenir des informations utiles.
Note
Les tables système ne sont pas incluses dans les sauvegardes de cluster automatiques ou manuelles (instantanés). Les vues du système STL conservent sept jours d'historique des journaux. La conservation des journaux ne nécessite aucune intervention du client, mais si vous souhaitez conserver les données du journal pendant plus de 7 jours, vous devrez les copier régulièrement sur d'autres tables ou les décharger sur Amazon S3.
Rubriques
Migration de requêtes provisionnées uniquement vers des requêtes SYS Monitoring View
Amélioration du suivi des identificateurs de requêtes à l’aide des vues de surveillance SYS
Identifiants de requête, de processus et de session dans la table système
Cartographie des vues système pour la migration vers les vues de surveillance SYS
Types de tables et de vues système
Il existe plusieurs types de tables et de vues système :
-
Les vues SVV contiennent des informations sur les objets de base de données faisant référence à des tables STV temporaires.
-
Les vues SYS permettent de surveiller l'utilisation de requêtes et de charges de travail pour les clusters mis en service et les groupes de travail sans serveur.
-
Les vues STL sont générées à partir des journaux stockés durablement sur le disque pour fournir un historique du système.
-
Les tables STV sont des tables système virtuelles contenant les instantanés des données système actuelles. Elles sont basées sur des données en mémoire temporaires et ne sont pas stockées durablement sous forme de journaux sur disque ou de tables standard.
-
Les vues SVCS fournissent des détails sur les requêtes effectuées sur les clusters principaux et les clusters de mise à l'échelle de simultanéité.
-
Les détails fournis par les vues SVL portent sur les requêtes exécutées sur les clusters principaux.
Les tables et les vues système n'utilisent pas le même modèle de cohérence que les tables standard. Il est important d'être conscient de ce problème lors de leur interrogation, surtout pour les tables STV et les vues SVV. Par exemple, prenons une table standard t1 avec une colonne c1. Vous pourriez vous attendre à ce que la requête suivante ne renvoie aucune ligne :
select * from t1 where c1 > (select max(c1) from t1)
Toutefois, la requête suivante sur une table système peut très bien renvoyer des lignes :
select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state)
La raison pour laquelle cette requête peut renvoyer des lignes est que currenttime est temporaire et que les deux références dans la requête peuvent ne pas renvoyer la même valeur lors de l'évaluation.
En revanche, la requête suivante ne peut très bien ne renvoyer aucune ligne :
select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state)
Visibilité des données dans les tables et vues système
Il existe deux classes de visibilité pour les données dans les tables et les vues système : la visibilité des utilisateurs et la visibilité des super-utilisateurs.
Seuls les utilisateurs disposant de privilèges peuvent afficher les données de ces tables qui se trouvent dans la catégorie visible du super-utilisateur. Les utilisateurs standard peuvent afficher les données des tableaux visibles de l'utilisateur. Pour donner à un utilisateur normal l'accès aux tables visibles par les superutilisateurs, accordez le privilège SELECT sur ces tables à l'utilisateur normal. Pour de plus amples informations, veuillez consulter GRANT.
Par défaut, dans la plupart des tableaux visibles des utilisateurs, les lignes générées par un autre utilisateur sont invisibles pour un utilisateur standard. Si un utilisateur normal bénéficie d'un accès SYSLOG ILLIMITÉ, il peut voir toutes les lignes des tables visibles par l'utilisateur, y compris les lignes générées par un autre utilisateur. Pour plus d’informations, consultez ALTER USER ou CREATE USER. Toutes les lignes de SVV_TRANSACTIONS sont visibles de tous les utilisateurs. Pour plus d'informations sur la visibilité des données, consultez l'article de la base de AWS re:Post connaissances Comment autoriser les utilisateurs réguliers de la base de données Amazon Redshift à consulter les données d'autres utilisateurs de mon cluster dans les tables système
Pour les vues de métadonnées, Amazon Redshift n'autorise pas la visibilité aux utilisateurs auxquels un ACCÈS SYSLOG EST ACCORDÉ SANS RESTRICTION.
Note
Accorder à un utilisateur un accès illimité aux tableaux système permet à celui-ci de voir les données générées par d’autres utilisateurs. Par exemple, STL_QUERY et STL_QUERY_TEXT contiennent le texte complet des instructions INSERT, UPDATE et DELETE, qui peuvent contenir des données confidentielles générées par l'utilisateur.
Un super-utilisateur peut afficher toutes les lignes de toutes les tables. Pour permettre à un utilisateur standard d'avoir accès aux tableaux visibles du super-utilisateur, GRANT-lui le privilège SELECT sur ce tableau.
Filtrage des requêtes générées par le système
Les tables et vues système associées à une requête, telles que SVL_QUERY_SUMMARY, SVL_QLOG et d'autres, contiennent généralement un grand nombre d'instructions générées automatiquement qu'Amazon Redshift utilise pour surveiller le statut de la base de données. Ces requêtes générées par le système sont visibles par un super-utilisateur, mais sont rarement utiles. Pour les filtrer lors de la sélection d'une table ou d'une vue système qui utilise la colonne userid, ajoutez la condition userid > 1 à la clause WHERE. Par exemple :
select * from svl_query_summary where userid > 1
Migration de requêtes provisionnées uniquement vers des requêtes SYS Monitoring View
Migration à partir de clusters provisionnés vers Amazon Redshift sans serveur
Si vous migrez un cluster provisionné vers Amazon Redshift Serverless, vous pouvez avoir des requêtes utilisant les vues système suivantes, qui stockent uniquement les données des clusters provisionnés.
-
Toutes les vues STL
-
Toutes les vues STV
-
Toutes les vues SVCS
-
Toutes les vues SVL
-
Certaines vues SVV
-
Pour obtenir la liste complète des vues SVV non prises en charge dans Amazon Redshift Serverless, consultez la liste au bas de la section Surveillance des requêtes et des charges de travail avec Amazon Redshift Serverless dans le guide de gestion Amazon Redshift.
-
Pour continuer à utiliser vos requêtes, réajustez-les pour utiliser les colonnes définies dans les vues de surveillance SYS qui correspondent aux colonnes de vos vues provisionnées uniquement. Pour voir la relation de mappage entre les vues provisionnées uniquement et les vues de surveillance SYS, rendez-vous sur Cartographie des vues système pour la migration vers les vues de surveillance SYS
Mise à jour des requêtes tout en restant sur un cluster provisionné
Si vous ne migrez pas vers Amazon Redshift sans serveur, vous souhaiterez peut-être tout de même mettre à jour vos requêtes existantes. Conçues pour être faciles à utiliser et réduire la complexité, les vues de surveillance SYS fournissent une gamme complète de métriques pour une surveillance et un dépannage efficaces. En utilisant des vues SYS telles que SYS_QUERY_HISTORY et SYS_QUERY_DETAIL qui consolident les informations de plusieurs vues provisionnées uniquement, vous pouvez rationaliser vos requêtes.
Amélioration du suivi des identificateurs de requêtes à l’aide des vues de surveillance SYS
Les vues de surveillance SYS telles que SYS_QUERY_HISTORY et SYS_QUERY_DETAIL comportent la colonne query_id, qui contient l’identifiant des requêtes des utilisateurs. De même, les vues provisionnées uniquement telles que STL_QUERY et SVL_QLOG comportent la colonne de requête, qui contient également les identifiants de requête. Cependant, les identifiants de requête enregistrés dans les vues du système SYS sont différents de ceux enregistrés dans les vues provisionnées uniquement.
La différence entre les valeurs de la colonne query_id des vues SYS et celles de la colonne de requête des vues provisionnées uniquement est la suivante :
-
Dans les vues SYS, la colonne query_id enregistre les requêtes soumises par les utilisateurs dans leur forme d’origine. L’optimiseur Amazon Redshift peut les décomposer en requêtes enfant pour améliorer les performances, mais une requête que vous exécutez ne comportera toujours qu’une seule ligne dans SYS_QUERY_HISTORY. Si vous souhaitez consulter les requêtes enfant individuelles, elles sont disponibles dans SYS_QUERY_DETAIL.
-
Dans les vues provisionnées uniquement, la colonne de requête enregistre les requêtes au niveau enfant. Si l’optimiseur Amazon Redshift réécrit votre requête d’origine en plusieurs requêtes enfant, il existera plusieurs lignes dans STL_QUERY comportant des valeurs d’identifiant de requête différentes pour une seule requête exécutée.
Quand vous migrez vos requêtes de surveillance et de diagnostic des vues provisionnées uniquement vers des vues SYS, tenez compte de cette différence et modifiez vos requêtes en conséquence. Pour plus d’informations sur la façon dont Amazon Redshift traite les requêtes, consultez Workflow d’exécution et de planification de requête.
exemple
Pour voir comment Amazon Redshift enregistre les requêtes différemment dans les vues provisionnées uniquement et dans les vues de surveillance SYS, consultez l'exemple de requête suivant. Il s’agit d’une requête écrite telle que vous l’exécuteriez dans 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;
À l’arrière-plan, l’optimiseur Amazon Redshift réécrit la requête ci-dessus soumise par l’utilisateur en cinq requêtes enfant.
La première requête enfant crée une table temporaire pour matérialiser une sous-requête.
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 deuxième requête enfant collecte des statistiques depuis la table temporaire.
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
La troisième requête enfant crée une autre table temporaire pour matérialiser une autre sous-requête, en référençant la table temporaire créée ci-dessus.
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 quatrième requête enfant collecte les statistiques de la table temporaire.
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
La dernière requête enfant utilise les tables temporaires créées ci-dessus pour générer la sortie.
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;
Dans la vue système provisionnée uniquement STL_QUERY, Amazon Redshift enregistre cinq lignes au niveau de la requête enfant, comme suit :
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)
Dans la vue de surveillance SYS SYS_QUERY_HISTORY, Amazon Redshift enregistre la requête comme suit :
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.
Dans SYS_QUERY_DETAIL, vous pouvez trouver des information de niveau requête enfant à l’aide de la valeur query_id de SYS_QUERY_HISTORY. La colonne child_query_sequence indique l’ordre dans lequel les requêtes enfant sont exécutées. Pour plus d’informations sur les colonnes de SYS_QUERY_DETAIL, consultez 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)
Identifiants de requête, de processus et de session dans la table système
Lorsque vous analysez les identifiants de requête, de processus et de session qui apparaissent dans les tables système, tenez compte des points suivants :
-
La valeur de l'identifiant de requête (dans des colonnes telles que
query_idetquery) peut être réutilisée au fil du temps. -
La valeur de l'identifiant du processus ou de l'identifiant de session (dans des colonnes telles que
process_idpid, etsession_id) peut être réutilisée au fil du temps. -
La valeur de l'identifiant de transaction (dans des colonnes telles que
transaction_idetxid) est unique.
