分區 DML 統計資料

作用中的分區資料操縱語言 (DML) 會即時顯示資料庫中作用中分區 DML 的進度。

Spanner 提供內建資料表 SPANNER_SYS.ACTIVE_PARTITIONED_DMLS，列出正在執行的分區 DML，以及這些 DML 的進度。

本頁面會詳細說明資料表，並顯示使用這個資料表的一些範例查詢，最後說明如何使用這些查詢，協助減輕作用中分區 DML 造成的相關問題。本頁面的資訊適用於 GoogleSQL 方言資料庫和 PostgreSQL 方言資料庫。

存取有效的分區 DML 統計資料

Spanner 會在 SPANNER_SYS 架構中提供作用中的分區 DML 統計資料。您可以透過下列方式存取 SPANNER_SYS 資料：

Spanner 提供的下列單一讀取方法不支援 SPANNER_SYS：

  • 從資料表中的單一資料列或多個資料列執行強式讀取。
  • 從資料表中的單一資料列或多個資料列執行過時讀取。
  • 從次要索引中的單一資料列或多個資料列讀取。

ACTIVE_PARTITIONED_DMLS

SPANNER_SYS.ACTIVE_PARTITIONED_DMLS 會傳回有效分區 DML 的清單，並依開始時間排序。

資料表結構定義

以下顯示 SPANNER_SYS.ACTIVE_PARTITIONED_DMLS 的資料表結構定義。

資料欄名稱 類型 說明
TEXT STRING 分區 DML 查詢陳述式文字。
TEXT_FINGERPRINT INT64 指紋是分區 DML 文字的雜湊值。
SESSION_ID STRING 執行分區 DML 的工作階段 ID。刪除工作階段 ID 會取消查詢。
NUM_PARTITIONS_TOTAL INT64 分區 DML 中的分區總數。
NUM_PARTITIONS_COMPLETE INT64 分區 DML 已完成的分區數量。
NUM_TRIVIAL_PARTITIONS_COMPLETE INT64 未處理任何資料列的完整分割區數量。
PROGRESS DOUBLE 分區 DML 的進度計算方式為：已完成的非微不足道分區數量除以非微不足道分區總數。
ROWS_PROCESSED INT64 目前處理的資料列數，會在每個分區完成後更新。
START_TIMESTAMP。 TIMESTAMP 分區 DML 開始時間的上限。
LAST_UPDATE_TIMESTAMP TIMESTAMP 分區 DML 上次有進展的時間戳記。分區完成後更新。

查詢範例

您可以使用用戶端程式庫、Google Cloud CLI 或 Google Cloud 控制台，執行下列範例 SQL 陳述式。

列出執行時間最長的查詢

下列查詢會傳回正在執行的分區 DML 清單，並依查詢的開始時間排序。

SELECT text,
       session_id,
       num_partitions_total,
       num_partitions_complete,
       num_trivial_partitions_complete,
       progress,
       rows_processed,
       start_timestamp,
       last_update_timestamp
FROM spanner_sys.active_partitioned_dmls
ORDER BY start_timestamp ASC;
文字 session_id num_partitions_total num_partitions_complete num_trivial_partitions_complete progress rows_processed start_timestamp last_update_timestamp
UPDATE Concerts SET VenueId = \'amazing venue\' WHERE SingerId < 900000 5bd37a99-200c-5d2e-9021-15d0dbbd97e6 27 15 3 50.00% 2398654 2024-01-21 15:56:30.498744-08:00 2024-01-22 15:56:39.049799-08:00
UPDATE Singers SET LastName = NULL WHERE LastName = '' 0028284f-0190-52f9-b396-aa588e034806 8 4 4 00.00% 0 2024-01-22 15:55:18.498744-08:00 2024-01-22 15:56:28.049799-08:00
DELETE from Singers WHERE SingerId > 1000000 0071a85e-7e5c-576b-8a17-f9bc3d157eea 8 4 3 20.00% 238654 2024-01-22 15:56:30.498744-08:00 2024-01-22 15:56:19.049799-08:00
UPDATE Singers SET MarketingBudget = 1000 WHERE true 036097a9-91d4-566a-a399-20c754eabdc2 8 5 0 62.50% 238654 2024-01-22 15:57:47.498744-08:00 2024-01-22 15:57:39.049799-08:00

限制

使用 SPANNER_SYS.ACTIVE_PARTITIONED_DMLS 資料表時，有下列限制：

  • PROGRESS、ROWS_PROCESSED 和 LAST_UPDATE_TIMESTAMP 結果會在分區界線完成時遞增，因此分區 DML 可能會持續更新資料列，而這三個欄位的值則維持不變。

  • 如果分割 DML 中有數百萬個分割區，PROGRESS 資料欄中的值可能無法擷取所有增量進度。使用 NUM_PARTITIONS_COMPLETE 和 NUM_TRIVIAL_PARTITIONS_COMPLETE 參照更精細的進度。

  • 如果使用 RPC 要求取消分區 DML，取消的分區 DML 可能仍會顯示在資料表中。如果使用工作階段刪除功能取消分區 DML，系統會立即從資料表中移除該 DML。詳情請參閱「刪除工作階段 ID」。

使用作用中的分區 DML 查詢資料，排解 CPU 使用率偏高的問題

查詢統計資料和交易統計資料可提供實用資訊，協助排解 Spanner 資料庫中的延遲問題。這些工具可提供已完成查詢的相關資訊。不過，有時您需要瞭解系統中正在執行的項目。舉例來說，假設 CPU 使用率偏高，您想回答下列問題。

  • 目前有多少分區 DML 正在執行？
  • 什麼是分區 DML？
  • 有多少分區 DML 執行時間過長？
  • 哪個工作階段正在執行查詢？

如果上述問題的答案為「是」，您可以決定採取下列行動。

  • 刪除執行查詢的工作階段，立即解決問題。
  • 降低分區 DML 的頻率。

在下列逐步說明中，我們會檢查作用中的分割 DML，並判斷是否要採取任何行動。

擷取有效分區 DML 的摘要

在範例情境中，我們發現 CPU 用量高於正常值，因此決定執行下列查詢，傳回作用中分割 DML 的計數。

SELECT count(*) as active_count
FROM spanner_sys.active_partitioned_dmls;

查詢會產生下列結果。

active_count
22

列出執行時間最長的前 2 個分區 DML

接著，我們可以執行查詢，依分區 DML 的開始時間排序，找出前 2 個最舊的分區 DML 執行作業，並取得更多相關資訊。

SELECT text,
       session_id,
       num_partitions_total,
       num_partitions_complete,
       num_trivial_partitions_complete,
       progress,
       rows_processed,
       start_timestamp,
       last_update_timestamp
FROM spanner_sys.active_partitioned_dmls
ORDER BY start_timestamp ASC LIMIT 2;
文字 session_id num_partitions_total num_partitions_complete num_trivial_partitions_complete progress rows_processed start_timestamp last_update_timestamp
UPDATE Concerts SET VenueId = \'amazing venue\' WHERE SingerId < 900000 5bd37a99-200c-5d2e-9021-15d0dbbd97e6 27 15 3 50.00% 2398654 2024-01-21 15:56:30.498744-08:00 2024-01-22 15:56:39.049799-08:00
UPDATE Singers SET LastName = NULL WHERE LastName = '' 0028284f-0190-52f9-b396-aa588e034806 8 4 4 00.00% 0 2024-01-22 15:55:18.498744-08:00 2024-01-22 15:56:28.049799-08:00

取消耗用大量資源的查詢

我們發現分區 DML 已執行多日，但沒有進展。因此，我們可以執行下列 gcloud spanner databases sessions delete 指令，使用工作階段 ID 刪除工作階段，取消分區 DML。

gcloud spanner databases sessions delete\
   5bd37a99-200c-5d2e-9021-15d0dbbd97e6 \
    --database=singer_db --instance=test-instance

後續步驟