本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
系統資料表和檢視參考
主題
系統資料表和檢視
Amazon Redshift 具有許多系統資料表和檢視，其中包含系統如何運作的相關資訊。您可以使用查詢任何其他資料庫資料表的方式，來查詢這些系統資料表和檢視。本節示範一些系統資料表查詢的例子並說明：
-
系統如何產生不同類型的資料表和檢視
-
您可以從這些資料表取得什麼類型的資訊
-
如何將 Amazon Redshift 系統資料表聯結至目錄資料表
-
如何管理不斷增多的系統資料表日誌檔案
某些系統表格只能由 AWS 工作人員用於診斷目的。以下章節討論系統管理員或其他資料庫使用者可以查詢實用資訊的系統資料表。
注意
自動或手動叢集備份 (快照) 不包括系統資料表。STL系統檢視會保留 7 天的記錄歷程記錄。保留日誌不需要客戶執行任何動作，但如果您想要儲存日誌資料超過 7 天，則必須定期將其複製到其他資料表或卸載到 Amazon S3。
系統資料表和檢視的類型
系統資料表和檢視有以下幾種類型：
-
SVV視圖包含有關數據庫對象的信息，以及對臨時STV表的引用。
-
SYS檢視用於監視已佈建叢集和無伺服器工作群組的查詢和工作負載使用情況。
-
STL檢視會從已保存至磁碟的記錄檔中產生，以提供系統歷程記錄。
-
STV資料表是包含目前系統資料快照的虛擬系統表格。他們是建基於暫時性記憶體內資料，而不會保存到磁碟型日誌或一般資料表。
-
SVCS檢視提供有關主要和並行擴展叢集上查詢的詳細資料。
-
SVL檢視提供有關主叢集上查詢的詳細資料。
系統資料表和檢視不會使用相同的一致性模型做為一般資料表。查詢這些問題時，特別是對於資料表和SVV檢視STV表而言，請務必注意這個問題。例如一般資料表 t1 (包含欄 c1)，預期以下查詢不會傳回任何列：
select * from t1 where c1 > (select max(c1) from t1)
但是以下對系統資料表的查詢可能會傳回列：
select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state)
此查詢可能會傳回列的原因是 currenttime 為暫時性，而查詢中的兩個參考在評估時可能不會傳回相同的值。
另一方面，下列查詢可能不會傳回任何列：
select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state)
系統資料表和檢視中資料的可見性
系統資料表和檢視中資料的可見性分為兩個類別：使用者可查看和超級使用者可查看。
擁有超級使用者權限的使用者才可以查看「超級使用者可查看」類別裡資料表的資料。一般使用者可以查看「使用者可查看」資料表裡的資料。若要讓一般使用者存取超級使用者可見的資料表，請將該資料表的SELECT權限授與一般使用者。如需詳細資訊，請參閱GRANT。
依預設，在大部份「使用者可查看」資料表中，一般使用者無法查看另一位使用者產生的列。如果指定一般使用者 SYSLOGACCESSUNRESTRICTED，該使用者就可以看到使用者可見資料表中的所有資料列，包括其他使用者產生的資料列。如需詳細資訊，請參閱 ALTER USER 或 CREATE USER。SVV_ TRANSACTIONS 中的所有行對所有用戶都可以看到。如需有關資料可見性的詳細資訊，請參閱 AWS re:Post 知識庫文章如何允許 Amazon Redshift 資料庫一般使用者檢視叢集其他使用者系統資料表中的資料的權
對於中繼資料檢視，Amazon Redshift 不允許對被授予SYSLOGACCESSUNRESTRICTED的使用者能見度。
注意
若使用者擁有不受限制的系統資料表存取權限，該使用者就能查看其他使用者產生的資料。例如，STL_ QUERY 和 STL QUERY _ TEXT 包含、和DELETE陳述式的全文 INSERTUPDATE，其中可能包含使用者產生的敏感資料。
超級使用者可以查看所有資料表中的所有列。為了讓普通用戶訪問超級用戶可見的表，那么普通用戶可以訪問該表的GRANTSELECT權限。
篩選系統產生的查詢
與查詢相關的系統表格和檢視 (例如 SVL QUERY _ _ SUMMARY QLOG、SVL _ 等) 通常包含大量自動產生的陳述式，Amazon Redshift 用來監控資料庫狀態。超級使用者可以看到這些系統產生的查詢，但這些查詢通常作用不大。若要在從使用userid欄的系統表格或系統檢視中進行選取時篩選出來，請將條件新增userid > 1至WHERE子句。例如：
select * from svl_query_summary where userid > 1
將僅佈建的查詢移轉至監視檢視查SYS詢
從已佈建的叢集遷移至 Amazon Redshift Serverless
如果您要將佈建的叢集遷移到 Amazon Redshift 無伺服器，則可能會使用下列系統檢視進行查詢，這些檢視只會儲存來自已佈建叢集的資料。
-
所有STL視圖
-
所有STV視圖
-
所有SVCS視圖
-
所有SVL視圖
-
一些SVV觀點
-
如需 Amazon Redshift 無伺服器中不支援的SVV檢視完整清單，請參閱 Amazon Redshift 管理指南中的使用 Amazon Redshift 無伺服器監控查詢和工作負載底部的清單。
-
若要繼續使用您的查詢，請將它們重新調整為使用SYS監視檢視中定義的資料欄，這些資料行對應於僅供佈建檢視中的欄。若要查看僅佈建檢視與SYS監視檢視之間的對應關係，請移至 用於移轉至 SYS 監視檢視的系統檢視對映
停留在已佈建叢集的同時更新查詢
如果您不是遷移到 Amazon Redshift Serverless，您可能仍想要更新現有的查詢。SYS監視檢視的設計目的是易於使用並降低複雜性，提供完整的指標陣列以進行有效的監控和疑難排解。使用SYS_QUERY_HISTORY和之類的SYS檢視SYS_QUERY_DETAIL合併多個僅供佈建檢視的資訊，您可以簡化查詢。
使用SYS監視檢視改善查詢識別碼追蹤
SYS監視諸如SYS_QUERY_HISTORY並SYS_QUERY_DETAIL包含 query_id 列之類的視圖，該列保存用戶查詢的標識符。同樣地，僅供佈建的檢視 (例如 STL_QUERY 和 SVL_QLOG) 包含查詢欄，此欄也包含查詢識別碼。但是，記錄在SYS系統檢視中的查詢識別碼與僅供佈建檢視中記錄的查詢識別碼不同。
SYS檢視表的 query_id 資料行值與僅供佈建檢視的查詢資料行值之間的差異如下：
-
在SYS檢視中，query_id 欄會以其原始形式記錄使用者提交的查詢。Amazon Redshift 最佳化工具可能會將它們分解為子查詢以提高效能，但是您執行的單一查詢在 SYS_QUERY_HISTORY 中仍只有一列。如果您想查看個別子查詢，可以在SYS_QUERY_DETAIL中找到它們。
-
在僅佈建的檢視中，查詢欄會記錄子查詢層級的查詢。如果 Amazon Redshift 最佳化工具將您的原始查詢重寫為多個子查詢，對於您執行的單一查詢，STL_QUERY 中將有多列具有不同的查詢識別碼值。
將監視和診斷查詢從僅佈建檢視移轉至SYS檢視時，請考慮此差異並相應地編輯您的查詢。如需 Amazon Redshift 如何處理查詢的相關資訊，請參閱查詢計劃和執行工作流程。
範例
如需 Amazon Redshift 如何在僅佈建和SYS監控檢視中以不同方式記錄查詢的範例，請參閱下列查詢範例。這是按照您在 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;
在此之下，Amazon Redshift 查詢最佳化工具會將上述使用者提交的查詢重寫為 5 個子查詢。
第一個子查詢建立一個暫存資料表來實現一個子查詢。
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);
第二個子查詢會從暫存資料表收集統計資料。
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
第三個子查詢建立另一個暫存資料表來具體化另一個子查詢，引用上面建立的暫存資料表。
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);
第四個子查詢再次收集暫存資料表的統計資料。
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
最後一個子查詢使用上面建立的暫存資料表來產生輸出。
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;
在僅佈建的系統檢視 STL _ 中QUERY，Amazon Redshift 會在子查詢層級記錄五個資料列，如下所示：
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)
在SYS監控視圖 SYS _ QUERY _ 中HISTORY，Amazon Redshift 記錄查詢，如下所示：
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.
在 SYS _ QUERY _ 中DETAIL，您可以使用來自 _ _ 的 query_id 值尋找子查詢層級的詳細資訊。SYS QUERY HISTORYchild_query_sequence 欄顯示子查詢的執行順序。如需 SYS _ 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
分析顯示在系統資料表中的查詢、處理程序和工作階段 ID 時，請注意下列事項：
-
查詢 ID 值 (在欄中，如
query_id和query) 可以隨著時間的推移重複使用。 -
進程 ID 或會話 ID 值（在諸如
process_id，pid和的列中session_id）可以隨著時間的推移重複使用。 -
交易 ID 值 (在欄中，如
transaction_id和xid) 是唯一的。
