Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 系統資料表和檢視參考
Amazon Redshift 具有許多系統資料表和檢視，其中包含系統如何運作的相關資訊。您可以使用查詢任何其他資料庫資料表的方式，來查詢這些系統資料表和檢視。本節示範一些系統資料表查詢的例子並說明：
+ 系統如何產生不同類型的資料表和檢視
+ 您可以從這些資料表取得什麼類型的資訊
+ 如何將 Amazon Redshift 系統資料表聯結至目錄資料表
+ 如何管理不斷增多的系統資料表日誌檔案
有些系統資料表只能供 AWS 員工用於診斷目的。以下章節討論系統管理員或其他資料庫使用者可以查詢實用資訊的系統資料表。
**注意**
自動或手動叢集備份 (快照) 不包括系統資料表。STL 系統檢視會保留 7 天的日誌歷史記錄。保留日誌不需要客戶執行任何動作，但如果您想要儲存日誌資料超過 7 天，則必須定期將其複製到其他資料表或卸載到 Amazon S3。
**Topics**
+ [系統資料表和檢視的類型](#c_types-of-system-tables-and-views)
+ [系統資料表和檢視中資料的可見性](#c_visibility-of-data)
+ [將僅佈建的查詢移轉至 SYS 監控檢視查詢](#sys_view_migration-use_cases)
+ [使用 SYS 監控檢視改善查詢識別碼追蹤](#sys_view_migration-query-id)
+ [系統資料表查詢、程序和工作階段 ID](#system-table-query-process-session-ids)
+ [SVV 中繼資料檢視](svv_views.md)
+ [SYS 監控檢視](serverless_views-monitoring.md)
+ [移轉至 SYS 監控檢視的系統檢視映射](sys_view_migration.md)
+ [系統監控 (僅限已佈建)](c_intro_system_views.md)
+ [系統目錄資料表](c_intro_catalog_views.md)
## 系統資料表和檢視的類型
系統資料表和檢視有以下幾種類型：
+ SVV 檢視包含有關資料庫物件的資訊，以及對暫時性 STV 資料表的參考。
+ SYS 檢視可用來監控已佈建叢集和無伺服器工作群組的查詢和工作負載使用情況。
+ STL 檢視是從已經保存到磁碟的日誌所產生，提供系統的歷史記錄。
+ STV 資料表是虛擬系統資料表，包含目前系統資料的快照。他們是建基於暫時性記憶體內資料，而不會保存到磁碟型日誌或一般資料表。
+ SVCS 檢視可提供主要叢集與並行擴展叢集查詢的詳細資訊。
+ SVL 檢視提供有關主要叢集上查詢的詳細資料。
系統資料表和檢視不會使用相同的一致性模型做為一般資料表。因此查詢這些資料表和檢視時需要注意此問題，特別是查詢 STV 資料表和 SVV 檢視時。例如一般資料表 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)
```
## 系統資料表和檢視中資料的可見性
**注意**
Amazon Redshift 會在記錄對 Data Catalog 檢視進行之查詢的相關資訊時，自動遮罩特定系統資料表欄，以防止暴露敏感的中繼資料。如需詳細資訊，請參閱《Amazon Redshift 管理指南》**中的[安全記錄](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html)。
系統資料表和檢視中資料的可見性分為兩個類別：使用者可查看和超級使用者可查看。
擁有超級使用者權限的使用者才可以查看「超級使用者可查看」類別裡資料表的資料。一般使用者可以查看「使用者可查看」資料表裡的資料。若要讓一般使用者存取超級使用者可查看的資料表，請將該資料表的 SELECT 權限授予一般使用者。如需詳細資訊，請參閱[GRANT](r_GRANT.md)。
依預設，在大部份「使用者可查看」資料表中，一般使用者無法查看另一位使用者產生的列。如果一般使用者獲得 [SYSLOG ACCESS UNRESTRICTED](r_ALTER_USER.md#alter-user-syslog-access)，該使用者就可以查看使用者可查看的資料表中的所有列，包括另一位使用者產生的列。如需詳細資訊，請參閱 [ALTER USER](r_ALTER_USER.md) 或 [CREATE USER](r_CREATE_USER.md) 。所有使用者皆可看到 SVV\_TRANSACTIONS 中的所有列。如需資料可見性的詳細資訊，請參閱 AWS re:Post 知識庫文章[如何允許 Amazon Redshift 資料庫一般使用者檢視來自其他叢集使用者之系統資料表中的資料？](https://repost.aws/knowledge-center/amazon-redshift-system-tables)。
對於中繼資料檢視，Amazon Redshift 不允許具有 SYSLOG ACCESS UNRESTRICTED 許可的使用者查看。
**注意**
若使用者擁有不受限制的系統資料表存取權限，該使用者就能查看其他使用者產生的資料。例如，STL\_QUERY 和 STL\_QUERY\_TEXT 包含 INSERT、UPDATE 和 DELETE 陳述式的全文，當中可能包含使用者產生的敏感資料。
超級使用者可以查看所有資料表中的所有列。若要讓一般使用者存取「超級使用者可查看」資料表，請在該資料表上將 SELECT 權限授予 [GRANT](r_GRANT.md) 一般使用者。
### 篩選系統產生的查詢
查詢相關的系統資料表和檢視，例如 SVL\_QUERY\_SUMMARY、SVL\_QLOG 等等，通常包含大量自動產生的陳述式，Amazon Redshift 會使用這些陳述式來監控資料庫的狀態。超級使用者可以看到這些系統產生的查詢，但這些查詢通常作用不大。從使用 `userid` 欄的系統資料表或系統檢視選取時，若要把這些查詢篩選掉，請在 WHERE 子句新增 `userid > 1` 條件。例如：
```
select * from svl_query_summary where userid > 1
```
## 將僅佈建的查詢移轉至 SYS 監控檢視查詢
### 從已佈建的叢集遷移至 Amazon Redshift Serverless
如果您要將佈建叢集移轉到 Amazon Redshift Serverless，則可能會使用下列系統檢視進行查詢，這些檢視只會儲存來自佈建叢集的資料。
+ 所有 STL 檢視
+ 所有 STV 檢視
+ 所有 SVCS 檢視
+ 所有 SVL 檢視
+ 一些 SVV 檢視
+ 如需 Amazon Redshift Serverless 中不支援的 SVV 檢視的完整清單，請參閱《Amazon Redshift 管理指南》**中的[使用 Amazon Redshift Serverless 監控查詢和工作負載](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-monitoring.html)底部的清單。
若要繼續使用您的查詢，請重新調整這些查詢，使其使用 SYS 監控檢視中定義的資料欄，這些欄對應於僅供佈建檢視中的欄。若要查看僅限佈建檢視與 SYS 監控檢視之間的映射關係，請前往 [移轉至 SYS 監控檢視的系統檢視映射](sys_view_migration.md)
### 停留在已佈建叢集的同時更新查詢
如果您不是遷移到 Amazon Redshift Serverless，您可能仍想要更新現有的查詢。SYS 監控檢視的設計目的是易於使用和降低複雜性，提供完整的指標陣列以進行有效的監控和疑難排解。使用 SYS 檢視 (例如 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 和 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) ) 合併多個僅供佈建檢視的資訊，您可以簡化查詢。
## 使用 SYS 監控檢視改善查詢識別碼追蹤
SYS 監控檢視 (例如 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 和 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md)) 包含 query\_id 欄，該欄保存使用者查詢的識別碼。同樣地，僅供佈建的檢視 (例如 [STL\_QUERY](r_STL_QUERY.md) 和 [SVL\_QLOG](r_SVL_QLOG.md)) 包含查詢欄，此欄也包含查詢識別碼。不過，SYS 系統檢視中記錄的查詢識別碼與僅供佈建檢視中記錄的查詢識別碼不同。
SYS 檢視表的 query\_id 欄值與僅供佈建檢視的查詢欄值之間的差異如下：
+ 在 SYS 檢視中，query\_id 欄會以其原始形式記錄使用者提交的查詢。Amazon Redshift 最佳化工具可能會將它們分解為子查詢以提高效能，但是您執行的單一查詢在 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 中仍只有一列。如果您想查看個別子查詢，可以在[SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md)中找到它們。
+ 在僅佈建的檢視中，查詢欄會記錄子查詢層級的查詢。如果 Amazon Redshift 最佳化工具將您的原始查詢重寫為多個子查詢，對於您執行的單一查詢，[STL\_QUERY](r_STL_QUERY.md) 中將有多列具有不同的查詢識別碼值。
當您將監控和診斷查詢從僅佈建檢視移轉至 SYS 檢視時，請考慮此差異，然後相應地編輯您的查詢。如需 Amazon Redshift 如何處理查詢的相關資訊，請參閱[查詢計劃和執行工作流程](c-query-planning.md)。
### 範例
如需 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 中，您可以使用來自 SYS\_QUERY\_HISTORY 的 query\_id 值來尋找子項查詢層級的詳細資訊。child\_query\_sequence 欄顯示子查詢的執行順序。如需 SYS\_QUERY\_DETAIL 中欄的相關資訊，請參閱[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)
```
## 系統資料表查詢、程序和工作階段 ID
分析系統資料表中出現的查詢、程序和工作階段 ID 時，請注意下列事項：
+ 查詢 ID 值 (在 `query_id` 和 `query` 等欄中) 可以隨著時間重複使用。
+ 程序 ID 或工作階段 ID 值 (在 `process_id`、`pid` 和 `session_id` 等欄中) 可以隨著時間重複使用。
+ 交易 ID 值 (在 `transaction_id` 和 `xid` 等欄中) 是唯一的。