Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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. **Topics** + [Types de tables et de vues système](#c_types-of-system-tables-and-views) + [Visibilité des données dans les tables et vues système](#c_visibility-of-data) + [Migration de requêtes allouées uniquement vers des requêtes de vue de surveillance SYS](#sys_view_migration-use_cases) + [Amélioration du suivi des identificateurs de requêtes à l’aide des vues de surveillance SYS](#sys_view_migration-query-id) + [Identifiants de requête, de processus et de session dans la table système](#system-table-query-process-session-ids) + [Vues de métadonnées SVV](svv_views.md) + [Vues de surveillance SYS](serverless_views-monitoring.md) + [Mappage des vues système pour la migration vers les vues de surveillance SYS](sys_view_migration.md) + [Surveillance système (clusters mis en service uniquement)](c_intro_system_views.md) + [Tables catalogue système](c_intro_catalog_views.md) ## 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 **Note** Amazon Redshift masque automatiquement certaines colonnes de la table système lors de la journalisation des informations relatives aux requêtes effectuées dans les vues du Catalogue de données afin d’empêcher la divulgation de métadonnées sensibles. Pour plus d’informations, consultez [ Journalisation sécurisée](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) dans le *Guide de gestion Amazon Redshift*. 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 permettre à un utilisateur standard d’avoir accès aux tables visibles du super-utilisateur, accordez-lui le privilège SELECT sur cette table. Pour plus d’informations, consultez [GRANT](r_GRANT.md). 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 standard obtient un [SYSLOG ACCESS UNRESTRICTED](r_ALTER_USER.md#alter-user-syslog-access), celui-ci peut voir toutes les lignes des tables visibles par les utilisateurs, y compris les lignes générées par un autre utilisateur. Pour plus d’informations, consultez [ALTER USER](r_ALTER_USER.md) ou [CREATE USER](r_CREATE_USER.md). 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](https://repost.aws/knowledge-center/amazon-redshift-system-tables) ? . Pour les vues de métadonnées, Amazon Redshift n’autorise pas la visibilité aux utilisateurs avec SYSLOG ACCESS UNRESTRICTED. **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](r_GRANT.md)-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 allouées uniquement vers des requêtes de vue de surveillance SYS ### Migration à partir de clusters provisionnés vers Amazon Redshift sans serveur Si vous migrez un cluster alloué vers Amazon Redshift sans serveur, vous pouvez avoir des requêtes utilisant les vues système suivantes, qui ne stockent des données qu’à partir des clusters alloué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 sans serveur, consultez la liste au bas de la section [Surveillance des requêtes et des charges de travail avec Amazon Redshift sans serveur](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-monitoring.html) 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 allouées uniquement et les vues de surveillance SYS, consultez [Mappage des vues système pour la migration vers les vues de surveillance SYS](sys_view_migration.md) ### 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](SYS_QUERY_HISTORY.md) et [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) 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](SYS_QUERY_HISTORY.md) et [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) 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](r_STL_QUERY.md) et [SVL\_QLOG](r_SVL_QLOG.md) 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](SYS_QUERY_HISTORY.md). Si vous souhaitez consulter les requêtes enfant individuelles, elles sont disponibles dans [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md). + 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](r_STL_QUERY.md) 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](c-query-planning.md). ### Exemple Pour un exemple de la façon dont Amazon Redshift enregistre les requêtes différemment dans les vues alloué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](SYS_QUERY_DETAIL.md). ``` 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_id` et `query`) peut être réutilisée au fil du temps. + La valeur de l’identifiant de processus ou de l’identifiant de session (dans des colonnes telles que `process_id`, `pid` et `session_id`) peut être réutilisée au fil du temps. + La valeur de l’identifiant de transaction (dans des colonnes telles que `transaction_id` et `xid`) est unique.