Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Referenz zu Systemtabellen und Ansichten
Themen
- Systemtabellen und Ansichten
- Arten von Systemtabellen und Ansichten
- Sichtbarkeit der Daten in Systemtabellen und Ansichten
- Migration von Abfragen, die nur bereitgestellt wurden, zu Abfragen der Überwachungsansicht SYS
- Verbessern Sie die Nachverfolgung von Abfrage-IDs mithilfe der Überwachungsansichten SYS
- Abfrage-, Prozess- und Sitzungs-IDs für Systemtabellen
- SVV-Metadatenansichten
- SYSAnsichten überwachen
- Systemansichtszuordnung für die Migration zu SYS-Überwachungsansichten
- Systemüberwachung (nur bereitgestellt)
- Systemkatalogtabellen
Systemtabellen und Ansichten
Amazon Redshift verfügt über zahlreiche Systemtabellen und Ansichten, die Informationen zur Funktionsweise des Systems enthalten. Sie können diese Systemtabellen und Ansichten genauso abfragen wie andere Datenbanktabellen auch. Dieser Abschnitt illustriert einige Beispiele für Systemtabellenabfragen und erläutert:
-
Wie unterschiedliche Arten von Systemtabellen und Ansichten generiert werden
-
Welche Arten von Informationen Sie aus diesen Tabellen erhalten können
-
Wie Sie Amazon-Redshift-Systemtabellen mit Katalogtabellen verbinden
-
Wie Sie mit der Zunahme der Systemtabellenprotokolldateien umgehen
Einige Systemtabellen können nur von AWS Mitarbeitern zu Diagnosezwecken verwendet werden. Die folgenden Abschnitte behandeln die Systemtabellen, die Systemadministratoren oder andere Datenbankbenutzer abfragen können, um nützliche Informationen zu erhalten.
Anmerkung
Systemtabellen werden in automatisierten oder manuellen Cluster-Backups (Snapshots) nicht berücksichtigt. STLIn Systemansichten wird der Protokollverlauf von sieben Tagen gespeichert. Die Aufbewahrung von Protokollen erfordert keine Maßnahmen des Kunden. Wenn Sie Protokolldaten jedoch länger als 7 Tage aufbewahren möchten, müssen Sie sie regelmäßig in andere Tabellen kopieren oder in Amazon S3 entladen.
Arten von Systemtabellen und Ansichten
Es gibt mehrere Arten von Systemtabellen und Ansichten:
SVVAnsichten enthalten Informationen über Datenbankobjekte mit Verweisen auf transiente STV Tabellen.
SYSAnsichten werden verwendet, um die Abfrage- und Workload-Nutzung für bereitgestellte Cluster und serverlose Arbeitsgruppen zu überwachen.
STLAnsichten werden aus Protokollen generiert, die auf der Festplatte gespeichert wurden, um einen Überblick über den Systemverlauf zu erhalten.
STVTabellen sind virtuelle Systemtabellen, die Schnappschüsse der aktuellen Systemdaten enthalten. Sie basieren auf flüchtigen Arbeitsspeicherdaten und werden nicht dauerhaft in Protokollen oder regulären Tabellen gespeichert.
SVCSAnsichten enthalten Details zu Abfragen sowohl für den Haupt- als auch für den Parallelitäts-Skalierungscluster.
SVLAnsichten enthalten Details zu Abfragen auf Hauptclustern.
Systemtabellen und Ansichten verwenden nicht dasselbe Konsistenzmodell wie reguläre Tabellen. Es ist wichtig, sich dieses Problems bewusst zu sein, wenn Sie sie abfragen, insbesondere bei STV Tabellen und SVV Ansichten. Zum Beispiel: Beim Vorliegen einer regulären Tabelle t1 mit einer Spalte c1 würden Sie erwarten, dass die folgende Abfrage keine Zeilen zurückgibt:
select * from t1 where c1 > (select max(c1) from t1)
Die folgende Abfrage gegen eine Systemtabelle kann aber sehr wohl Zeilen ausgeben:
select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state)
Der Grund dafür ist der, dass currenttime ein temporärer Wert ist und die beiden Referenzen in der Abfrage bei der Evaluierung möglicherweise nicht den gleichen Wert ausgeben.
Andererseits kann die folgende Abfrage möglicherweise auch keine Zeilen ausgeben:
select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state)
Sichtbarkeit der Daten in Systemtabellen und Ansichten
Es gibt zwei Klassen der Sichtbarkeit für Daten in Systemtabellen und Ansichten: für Benutzer sichtbar und für Superuser sichtbar.
Nur Benutzer mit Superuser-Berechtigungen können Daten in Tabellen der Kategorie "sichtbar für Superuser" anzeigen. Normale Benutzer sehen Nur die Daten in für Benutzer sichtbaren Tabellen. Um einem normalen Benutzer Zugriff auf Tabellen zu gewähren, die für Superuser sichtbar sind, gewähren Sie dem normalen Benutzer die SELECT Berechtigung für diese Tabelle. Weitere Informationen finden Sie unter GRANT.
Standardmäßig sind in den meisten für Benutzer sichtbaren Tabellen von einem anderen Benutzer generierte Zeilen für einen normalen Benutzer nicht sichtbar. Wenn ein regulärer Benutzer angegeben ist SYSLOGACCESSUNRESTRICTED, kann dieser Benutzer alle Zeilen in für den Benutzer sichtbaren Tabellen sehen, einschließlich der Zeilen, die von einem anderen Benutzer generiert wurden. Weitere Informationen finden Sie unter ALTER USER oder CREATE USER. Alle Zeilen in SVV _ TRANSACTIONS sind für alle Benutzer sichtbar. Weitere Informationen zur Sichtbarkeit von Daten finden Sie im AWS re:Post Knowledgebase-Artikel Wie kann ich regulären Benutzern der Amazon Redshift Redshift-Datenbank die Erlaubnis erteilen, Daten in Systemtabellen von anderen Benutzern für meinen Cluster anzuzeigen
Für Metadatenansichten gewährt Amazon Redshift Benutzern keine Sichtbarkeit, denen diese Rechte gewährt wurden SYSLOG ACCESSUNRESTRICTED.
Anmerkung
Wenn Sie einem Benutzer uneingeschränkten Zugriff auf Systemtabellen gewähren, sieht der Benutzer auch Daten, die von anderen Benutzern generiert wurden. Zum Beispiel TEXT enthalten STL _ QUERY und STL _ QUERY _ den vollständigen Text vonINSERT, und DELETE -AnweisungenUPDATE, die sensible benutzergenerierte Daten enthalten können.
Ein Superuser kann alle Zeilen in allen Tabellen sehen. Um einem normalen Benutzer Zugriff auf Tabellen zu gewähren, die für Superuser sichtbar sind, erhält GRANT SELECT der normale Benutzer Zugriff auf diese Tabelle.
Filterung systemgenerierter Abfragen
Die abfragebezogenen Systemtabellen und Ansichten, wie SVL _ _SUMMARY, QUERY SVL _ und andereQLOG, enthalten normalerweise eine große Anzahl von automatisch generierten Anweisungen, die Amazon Redshift verwendet, um den Status der Datenbank zu überwachen. Diese systemgenerierten Abfragen sind für Superuser sichtbar, jedoch selten wirklich nützlich. Um sie herauszufiltern, wenn Sie aus einer Systemtabelle oder Systemansicht auswählen, die die userid Spalte verwendet, fügen Sie die Bedingung userid > 1 zur Klausel hinzu. WHERE Beispielsweise:
select * from svl_query_summary where userid > 1
Migration von Abfragen, die nur bereitgestellt wurden, zu Abfragen der Überwachungsansicht SYS
Migrieren von bereitgestellten Clustern zu Amazon Redshift Serverless
Wenn Sie einen bereitgestellten Cluster zu Amazon Redshift Serverless migrieren, haben Sie möglicherweise Abfragen, die die folgenden Systemansichten verwenden, in denen nur Daten aus bereitgestellten Clustern gespeichert werden.
Alle Ansichten STL
Alle STV Ansichten
Alle SVCS Ansichten
Alle SVL Ansichten
Einige SVV Ansichten
Eine vollständige Liste der SVV Ansichten, die in Amazon Redshift Serverless nicht unterstützt werden, finden Sie in der Liste am Ende von Monitoring queries and workloads with Amazon Redshift Serverless im Amazon Redshift Management Guide.
Um Ihre Abfragen weiterhin verwenden zu können, passen Sie sie so an, dass sie in den SYS Überwachungsansichten definierte Spalten verwenden, die den Spalten in Ihren nur bereitgestellten Ansichten entsprechen. Um die Zuordnungsbeziehung zwischen den nur bereitgestellten Ansichten und den Überwachungsansichten zu sehen, gehen Sie zu SYS Systemansichtszuordnung für die Migration zu SYS-Überwachungsansichten
Aktualisieren von Abfragen in einem bereitgestellten Cluster
Wenn Sie nicht zu Amazon Redshift Serverless migrieren, möchten Sie möglicherweise trotzdem Ihre vorhandenen Abfragen aktualisieren. Die SYS Überwachungsansichten sind auf Benutzerfreundlichkeit und geringere Komplexität ausgelegt und bieten eine vollständige Palette von Metriken für eine effektive Überwachung und Problembehebung. Mithilfe von SYS Ansichten wie SYS_QUERY_HISTORY undSYS_QUERY_DETAIL, die die Informationen mehrerer nur bereitgestellter Ansichten konsolidieren, können Sie Ihre Abfragen optimieren.
Verbessern Sie die Nachverfolgung von Abfrage-IDs mithilfe der Überwachungsansichten SYS
SYSÜberwachungsansichten wie diese SYS_QUERY_HISTORY und SYS_QUERY_DETAIL enthalten die Spalte query_id, die den Bezeichner für Benutzeranfragen enthält. In ähnlicher Weise gibt es in nur bereitgestellten Ansichten wie STL_QUERY und SVL_QLOG die Spalte „query“, die ebenfalls die Abfrage-IDs enthält. Die in den SYS Systemansichten aufgezeichneten Abfrage-IDs unterscheiden sich jedoch von denen, die in den nur bereitgestellten Ansichten aufgezeichnet wurden.
Der Unterschied zwischen den Query_ID-Spaltenwerten SYS der Ansichten und den Abfragespaltenwerten der nur bereitgestellten Ansichten ist wie folgt:
In SYS Ansichten werden in der Spalte query_id vom Benutzer eingereichte Abfragen in ihrer ursprünglichen Form aufgezeichnet. Der Amazon-Redshift-Optimierer kann sie zur Verbesserung der Leistung in untergeordnete Abfragen aufteilen, doch für eine einzelne Abfrage, die Sie ausführen, gibt es dennoch nur eine einzige Zeile in SYS_QUERY_HISTORY. Die einzelnen untergeordneten Abfragen können Sie in SYS_QUERY_DETAIL einsehen.
In nur bereitgestellten Ansichten werden Abfragen in der Spalte „query“ auf der Ebene der untergeordneten Abfragen aufgezeichnet. Wenn der Amazon-Redshift-Optimierer Ihre ursprüngliche Abfrage in mehrere untergeordnete Abfragen unterteilt, gibt es in STL_QUERY mehrere Zeilen mit unterschiedlichen Abfrage-ID-Werten für eine einzelne Abfrage, die Sie ausführen.
Wenn Sie Ihre Überwachungs- und Diagnoseabfragen von reinen Bereitstellungsansichten zu SYS Ansichten migrieren, sollten Sie diesen Unterschied berücksichtigen und Ihre Abfragen entsprechend bearbeiten. Weitere Informationen zur Verarbeitung von Abfragen durch Amazon Redshift finden Sie unter Workflow der Abfrageplanung und -ausführung.
Beispiel
Ein Beispiel dafür, wie Amazon Redshift Abfragen in reinen Bereitstellungsansichten und SYS Überwachungsansichten unterschiedlich aufzeichnet, finden Sie in der folgenden Beispielabfrage. Diese Abfrage ist so geschrieben, wie Sie sie in Amazon Redshift ausführen würden.
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;
Im Hintergrund schreibt der Amazon-Redshift-Abfrageoptimierer die oben aufgeführte vom Benutzer eingereichte Abfrage in fünf untergeordnete Abfragen um.
Die erste untergeordnete Abfrage erstellt eine temporäre Tabelle, um eine Unterabfrage zu materialisieren.
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);
Die zweite untergeordnete Abfrage sammelt Statistiken aus der temporären Tabelle.
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
Die dritte untergeordnete Abfrage erstellt eine weitere temporäre Tabelle, um eine weitere Unterabfrage zu materialisieren, die auf die oben erstellte temporäre Tabelle verweist.
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);
Die vierte untergeordnete Abfrage sammelt wiederum Statistiken aus der temporären Tabelle.
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
Die letzte untergeordnete Abfrage verwendet die oben erstellten temporären Tabellen, um die Ausgabe zu generieren.
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;
In der nur bereitgestellten Systemansicht STL _ zeichnet Amazon Redshift fünf Zeilen auf untergeordneter Abfrageebene aufQUERY, und zwar wie folgt:
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)
In der SYS Überwachungsansicht SYS _ QUERY _ HISTORY zeichnet Amazon Redshift die Abfrage wie folgt auf:
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 _ finden Sie Details auf untergeordneter AbfrageebeneDETAIL, indem Sie den Wert query_id aus _ _ verwenden. SYS QUERY HISTORY Die Spalte „child_query_sequence“ zeigt die Reihenfolge, in der die untergeordneten Abfragen ausgeführt werden. Weitere Informationen zu den Spalten in SYS _ _ QUERY finden Sie unter. 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)
Abfrage-, Prozess- und Sitzungs-IDs für Systemtabellen
Beachten Sie bei der Analyse von Abfrage-, Prozess- und Sitzungs-IDs, die in Systemtabellen erscheinen, Folgendes:
Der Wert der Abfrage-ID (in Spalten wie
query_idundquery) kann im Laufe der Zeit wiederverwendet werden.Der Wert für die Prozess-ID oder die Sitzungs-ID (in Spalten wie
process_idpid, undsession_id) kann im Laufe der Zeit wiederverwendet werden.Der Wert der Transaktions-ID (in Spalten wie
transaction_idundxid) ist eindeutig.
