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 mit SYS-Überwachungsansichten
- Verbesserung der Nachverfolgung von Abfrage-IDs mithilfe der SYS-Überwachungsansichten
- Abfrage-, Prozess- und Sitzungs-IDs für Systemtabellen
- SVV-Metadatenansichten
- SYS-Überwachungsansichten
- 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. STL-Systemansichten speichern den Protokollverlauf von sieben Tagen. 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:
SVV-Ansichten enthalten Informationen über Datenbankobjekte mit Verweisen auf transiente STV-Tabellen.
SYS-Ansichten werden zur Überwachung der Abfrage- und Workloadnutzung für bereitgestellte Cluster und Serverless-Arbeitsgruppen verwendet.
STL-Ansichten werden aus Protokollen generiert, die dauerhaft auf der Festplatte gespeichert werden, um einen Systemverlauf bereitzustellen.
STV-Tabellen sind virtuelle Systemtabellen, die Snapshots der aktuellen Systemdaten enthalten. Sie basieren auf flüchtigen Arbeitsspeicherdaten und werden nicht dauerhaft in Protokollen oder regulären Tabellen gespeichert.
SVCS-Ansichten enthalten Details zu Abfragen auf den Haupt- und Nebenläufigkeitsskalierungs-Clustern.
SVL-Ansichten stellen Informationen zu Abfragen auf Haupt-Clustern bereit.
Systemtabellen und Ansichten verwenden nicht dasselbe Konsistenzmodell wie reguläre Tabellen. Dies sollten sich bei ihrer Abfrage stets bewusst machen, besonders für 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 das SELECT-Privileg 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 einem normalen Benutzer SYSLOG ACCESS UNRESTRICTED gewährt wird, 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, denen SYSLOG ACCESS UNRESTRICTED gewährt wurde, keine Sichtbarkeit.
Anmerkung
Wenn Sie einem Benutzer uneingeschränkten Zugriff auf Systemtabellen gewähren, sieht der Benutzer auch Daten, die von anderen Benutzern generiert wurden. STL_QUERY und STL_QUERY_TEXT enthalten beispielsweise den vollständigen Text von INSERT-, UPDATE- und DELETE-Anweisungen, die möglicherweise sensible von Benutzern generierte Daten enthalten.
Ein Superuser kann alle Zeilen in allen Tabellen sehen. Um einem normalen Benutzer Zugriff auf Tabellen zu gewähren, die nur für Superuser sichtbar sind, gewähren Sie dem normalen Benutzer die GRANT SELECT-Berechtigung für diese Tabelle.
Filterung systemgenerierter Abfragen
Die abfragebezogenen Systemtabellen und Ansichten, wie etwa SVL_QUERY_SUMMARY, SVL_QLOG und andere, enthalten normalerweise eine sehr große Zahl automatisch generierter Anweisungen, die Amazon Redshift für die Überwachung des Status der Datenbank verwenden. Diese systemgenerierten Abfragen sind für Superuser sichtbar, jedoch selten wirklich nützlich. Um diese bei der Auswahl aus einer Systemtabelle oder Systemtabelle auszufiltern, die die Spalte userid verwendet, fügen Sie die Bedingung userid > 1 der WHERE-Klausel hinzu. Beispielsweise:
select * from svl_query_summary where userid > 1
Migration von Abfragen, die nur bereitgestellt wurden, zu Abfragen mit SYS-Überwachungsansichten
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 STL-Ansichten
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 zu benutzen, passen Sie sie so an, dass sie Spalten verwenden, die in den SYS-Überwachungsansichten definiert sind und den Spalten in Ihren nur bereitgestellten Ansichten entsprechen. Um die Zuordnungsbeziehung zwischen den nur bereitgestellten Ansichten und den SYS-Überwachungsansichten zu sehen, gehen Sie zu 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 reduzierte Komplexität ausgelegt und bieten eine vollständige Palette von Metriken für eine effektive Überwachung und Fehlerbehebung. Mithilfe von SYS-Ansichten wie SYS_QUERY_HISTORY und SYS_QUERY_DETAIL, die die Informationen mehrerer nur bereitgestellter Ansichten konsolidieren, können Sie Ihre Abfragen optimieren.
Verbesserung der Nachverfolgung von Abfrage-IDs mithilfe der SYS-Überwachungsansichten
SYS-Überwachungsansichten wie SYS_QUERY_HISTORY und SYS_QUERY_DETAIL enthalten die Spalte „query_id“ mit der ID der Abfragen der Benutzer. 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 den IDs, die in den nur bereitgestellten Ansichten aufgezeichnet werden.
Zwischen den Werten der Spalte „query_id“ in den SYS-Ansichten und den Werten der Spalte „query“ in den nur bereitgestellten Ansichten besteht folgender Unterschied:
In SYS-Ansichten werden vom Benutzer eingereichte Abfragen in der Spalte „query_id“ 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 nur bereitgestellten Ansichten 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 den Überwachungsansichten „Nur bereitgestellt“ und „SYS“ 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_QUERY zeichnet Amazon Redshift fünf Zeilen auf Ebene der untergeordneten Abfragen auf, wie im Folgenden dargestellt:
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_DETAIL können Sie unter Verwendung des Wertes für „query_id“ aus SYS_QUERY_HISTORY Details auf Ebene der untergeordneten Abfrage abrufen. Die Spalte „child_query_sequence“ zeigt die Reihenfolge, in der die untergeordneten Abfragen ausgeführt werden. Weitere Informationen zu den Spalten in SYS_QUERY_DETAIL finden Sie unter 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.
