本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
在 Amazon RDS 上使用後自SQL動真空吸塵器 SQL
強烈建議您使用自動真空功能來維持 Postgre SQL 資料庫執行個體的健康狀態。自動真空可自動執行VACUUM和指令的啟動ANALYZE。此功能會檢查含有大量輸入、更新或刪除元組的資料表。在此檢查之後，它會從 Po SQL stgre 資料庫中移除過時的資料或元組來回收儲存體。
根據預設，您使用任何預設 Postgre 資料庫RDS參數群組建立的 Amazon Postgre SQL 資料庫執行個體會開啟自動吸塵功能。SQL其中包括 default.postgres10、default.postgres11，以及其他版本。所有預設 Postgre SQL 資料庫參數群組都有設定為的rds.adaptive_autovacuum參數1，因此會啟動該功能。預設情況下，還會設定與自動資料清理功能相關聯的其他組態參數。因為這些預設值相當泛用，針對特定的工作負載調校與自動資料清理功能相關聯的某些參數，對您會有所幫助。
接下來，您可以找到有關自動真空以及如何在 Postgre 資SQL料庫執行個體上調整其某些參數的RDS詳細資訊。如需高層級資訊，請參閱 與波斯特格雷合作的最佳做法 SQL。
主題
配置自動資料清理的記憶體
maintenance_work_memmaintenance_work_mem 參數值設得太低，則清理程序可能必須掃描資料表多次才能完成其工作。多次的掃描可能會對效能產生負面影響。
進行計算以決定 maintenance_work_mem 參數值時，請記住兩件事：
此參數的預設單位為 kilobytes (KB)。
-
maintenance_work_mem參數會搭配autovacuum_max_workers參數運作。如果您有許多小型資料表，請配置較多 autovacuum_max_workers和較少maintenance_work_mem。如果您有大型資料表 (假設大於 100 GB)，請配置較多記憶體和較少背景工作程序。您必須配置足夠的記憶體，才能在最大的資料表上順利執行作業。每個autovacuum_max_workers可以使用您配置的記憶體。因此，請確保工作者程序與記憶體的組合等於您想要配置的總記憶體。
一般而言，針對大型主機，將 maintenance_work_mem 參數設定為介於 1 與 2 GB 之間的值 (介於 1,048,576 與 2,097,152 KB 之間)。針對極大型主機，將此參數設定為介於 2 與 4 GB 之間的值 (介於 2,097,152 與 4,194,304 KB 之間)。您為此參數設定的值會視工作負載而定。Amazon RDS 已將此參數的預設值更新為以千位元組計算，如下所示。
GREATEST({DBInstanceClassMemory/63963136*1024},65536).
降低交易 ID 包圍的可能性
在一些狀況中，自動資料清理相關的參數群組設定可能不夠積極以防止交易 ID 包圍。RDS為了解決這個問題，Postgre SQL 提供了一種自動調整自動真空參數值的機制。自適應自動真空參數調諧是 Post SQL gre RDS 的功能。關於 TransactionID 環繞
對於動態參數設定為 ON 的 Postgre SQL 執行個體，預RDSrds.adaptive_autovacuum設情況下會開啟自適應自動真空參數調整。我們強烈建議您開啟此選項。但是，若要關閉自適應自動真空參數調整，請將rds.adaptive_autovacuum參數設定為 0 或OFF。
即使 Amazon RDS 調整了自動真空參數，仍然可以使用交易 ID 環繞。我們建議您為交易 ID 環繞實作 Amazon CloudWatch 警示。有關更多信息，請參閱在RDS上面的 Postgre 實現事務 ID 的預警系統後 SQL
開啟自適應自動真空參數調整後，Amazon 會在 CloudWatch 指標MaximumUsedTransactionIDs達到參數值或 500,000,000 (以較大者為準) 時RDS開始調整自動真空autovacuum_freeze_max_age參數。
如果表格RDS繼續朝著交易 ID 環繞趨勢，Amazon 將繼續調整自動真空的參數。每次調整都提供更多自動資料清理的資源以避免包圍。Amazon RDS 更新下列自動真空相關參數：
RDS只有當新值使得自動真空更具侵略性時，才會修改這些參數。參數在資料庫執行個體上的記憶體中修改。參數群組中的值不會變更。若要檢視目前的記憶體內設定，請使用 Postgre SQL SHOW
Amazon RDS 修改任何這些自動真空參數時，會為受影響的資料庫執行個體產生事件。此事件是可見的 AWS Management Console
並通過 Amazon RDS API。指MaximumUsedTransactionIDs CloudWatch 標返回低於閾值後，Amazon RDS 會將記憶體中的自動真空相關參數重設回參數群組中指定的值。系統隨即會產生與此變更相對應的另一個事件。
判斷資料庫中的資料表是否需要清理
您可以使用以下查詢可用來顯示資料庫中未清理的交易數目。數據庫的行的datfrozenxidpg_database列是IDs出現在該數據庫中的正常事務的下限。此欄位是資料庫內每個資料表 relfrozenxid 最小的值。
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
例如，執行上述查詢的結果可能如下所示。
datname | age mydb | 1771757888 template0 | 1721757888 template1 | 1721757888 rdsadmin | 1694008527 postgres | 1693881061 (5 rows)
當一個數據庫的年齡達到 20 億事務IDs，事務 ID (XID) 環繞發生，數據庫變為只讀。您可使用此查詢來產生指標且一天執行數次。根據預設，自動資料清理已將交易的存留期設定為不超過 200,000,000 (autovacuum_freeze_max_age
範例監視策略可能如下所示：
設定
autovacuum_freeze_max_age值到 2 億交易數目如果資料表達到 5 億的未清理交易，則觸發低安全性警報。這並非不合理的值，但可以表示該自動資料清理並未保持啟動狀態。
如果資料表存留達到 10 億，這應視為採取動作的警報。一般而言，您會基於效能理由，而想讓存留期比較接近
autovacuum_freeze_max_age。我們建議您使用下列建議調查。如果資料表達到 15 億的未清理交易，則觸發高安全性警報。根據資料庫使用交易的速度而定IDs，此警示可能表示系統執行 autovacuum 的時間不足。在此情況下，我們建議您立即解決此問題。
如果資料表不斷違反這些閾值，請進一步修改自動資料清理參數。默認情況下，使用VACUUM手動（已禁用基於成本的延遲）比使用默認自動真空更具侵略性，但它對整個系統也更具侵入性。
我們建議下列作法：
請注意並開啟監控機制，如此您才會注意最舊交易的存留期。
如需建立可向您發出有關交易 ID 環繞警告的程序的資訊，請參閱 AWS 資料庫部落格文章針對 Postgre 在 Amazon RDS 中實作交易 ID 環繞的預警系統
。SQL 對於比較忙碌的資料表，除了依賴自動資料清理以外，請在維護時段定期執行手動清理凍結。如需執行手動清理凍結的資訊，請參閱 執行手動清理凍結。
判斷哪些資料表目前適合進行自動資料清理
通常有一或兩個資料表需要清理。表單中 relfrozenxid 的值大於 autovacuum_freeze_max_age 中交易的值，總是會成為自動資料清理的目標。否則，如果自最後一個以來過時的元組數量VACUUM超過真空閾值，則表將被真空吸塵。
自動資料清理閾值
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
在哪vacuum base threshold裡autovacuum_vacuum_threshold，vacuum scale factor是autovacuum_vacuum_scale_factor，並且number of tuples是pg_class.reltuples。
當您連線到資料庫時，執行以下查詢可查看自動資料清理功能認為符合清理條件的資料表清單。
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold'), vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'), fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'), sto AS (select opt_oid, split_part(setting, '=', 1) as param, split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt) SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation, pg_size_pretty(pg_table_size(c.oid)) as table_size, age(relfrozenxid) as xid_age, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples) AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM pg_class c join pg_namespace ns on ns.oid = c.relnamespace join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1) left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid WHERE c.relkind = 'r' and nspname <> 'pg_catalog' AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float) OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup) ORDER BY age(relfrozenxid) DESC LIMIT 50;
判斷自動資料清理目前是否執行中且執行多久時間
如果您需要手動清理資料表，請判斷目前是否在執行自動資料清理功能。如果是這樣，您可能需要調整參數以使其更有效率地運行，或者暫時關閉 autovacuum 以便您可以手動運行VACUUM。
使用以下查詢來判斷自動資料清理是否執行中、已執行多久時間，以及是否正等待另一個工作階段。
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;
在執行此查詢之後，您應會看到類似底下的輸出：
datname | usename | pid | state | wait_event | xact_runtime | query --------+----------+-------+--------+------------+-------------------------+-------------------------------------------------------------------------------------------------------- mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound) mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound) mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3 mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+ | | | | | | FROM pg_stat_activity + | | | | | | WHERE query like '%VACUUM%' + | | | | | | ORDER BY xact_start; +
有幾個問題可能造成長時間執行自動資料清理階段 (長達數天)。最常見的問題就是資料表大小或更新率的 maintenance_work_mem
建議您依照下列公式來設定 maintenance_work_mem 參數值。
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
短時間執行的自動資料清理工作階段也可以指出問題：
它可指出您的工作負載沒有足夠的
autovacuum_max_workers。在此情況下，您需要指出工作者數目。它可指出有索引損毀 (自動資料清理會當機並以相同的關聯重新啟動，但沒有任何進度)。在這種情況下，請手動執行
vacuum freeze verbose來查看確切原因。table
執行手動清理凍結
您可以在清理程序已在執行中的資料表上執行手動清理。如果您已辨識出表單的交易將近 20 億 (或超出您所監控的任何閾值) 的資料表，此功能將很實用。
下列步驟是準則，而程序會有多種變化。例如，在測試期間，假設您會發現 maintenance_work_memmaintenance_work_mem 參數設定，但您也需要採取立即動作並清理有問題的資料表。以下程序說明在此情況下的處理方式。
手動執行清理凍結
對包含要清理之資料表的資料庫，開啟兩個工作階段。在第二個工作階段中，如果連線中斷，請使用 "screen" 或其他公用程式來維持此工作階段。
在會話一中，獲取表上運行的自動真空會話的進程 ID（PID）。
運行以下查詢以獲取自動真空會話PID的。
SELECT datname, usename, pid, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;在第二個工作階段中，計算您需要用於此作業的記憶體數量。在此範例中，我們判斷我們可以將最多 2 GB 的記憶體使用於此作業，所以將目前工作階段的
maintenance_work_mem設定為 2 GB。 SET maintenance_work_mem='2 GB';SET在第二個工作階段中，對表格發佈
vacuum freeze verbose指令。詳細設置很有用，因為儘管SQL當前 Postgre 中沒有進度報告，但您可以看到活動。\timing onTiming is on.vacuum freeze verbose pgbench_branches;INFO: vacuuming "public.pgbench_branches" INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions in 43 out of 43 pages DETAIL: 0 dead row versions cannot be removed yet. There were 9347 unused item pointers. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 0.00 sec. VACUUM Time: 2.765 ms-
在第一個工作階段，如果自動資料清理封鎖清理工作階段，您會在
pg_stat_activity中看見清理工作階段的等待為 "T"。在此情況下，您需要按如下方式結束自動資料清理程序。SELECT pg_terminate_backend('the_pid');此時，您的工作階段會開始。請特別注意，自動資料清理會立即重新啟動，因為此資料表可能排在其工作清單的最前面。
-
在第二個工作階段中啟動您的
vacuum freeze verbose命令，然後在第一個工作階段中結束自動資料清理程序。
在自動資料清理執行時重新為資料表建立索引
如果索引毀損，自動資料清理會繼續處理資料表並且失敗。如果您在此情況下嘗試手動清理，則會收到如下錯誤訊息。
postgres=>vacuum freeze pgbench_branches;ERROR: index "pgbench_branches_test_index" contains unexpected zero page at block 30521 HINT: Please REINDEX it.
當索引毀損且自動資料清理嘗試在資料表上執行時，您全力應付已在執行中的自動資料清理工作階段。當您發出指REINDEX
在資料表上執行自動資料清理時重新為資料表建立索引
對包含要清理之資料表的資料庫，開啟兩個工作階段。在第二個工作階段中，如果連線中斷，請使用 "screen" 或其他公用程式來維持此工作階段。
在PID第一階段中，取得桌子上執行的自動真空工作階段。
運行以下查詢以獲取自動真空會話PID的。
SELECT datname, usename, pid, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY xact_start;在第二個工作階段中，發出 reindex 命令。
\timing onTiming is on.reindex index pgbench_branches_test_index;REINDEX Time: 9.966 ms在第一個工作階段中，如果自動資料清理封鎖處理程序，您會在
pg_stat_activity中看見清理工作階段的等待為 "T"。在此情況下，您就結束自動資料清理程序。SELECT pg_terminate_backend('the_pid');此時，您的工作階段會開始。請特別注意，自動資料清理會立即重新啟動，因為此資料表可能排在其工作清單的最前面。
在第二個工作階段中啟動您的命令，然後在第一個工作階段中結束自動資料清理程序。
使用大型索引管理自動清空
作為其操作的一部分，自動清空會在資料表上執行時執行數個清空階段
在此程序中，首先檢查整體索引大小。然後，判斷是否有可以移除的潛在未用索引，如下列範例所示。
檢查資料表及其索引的大小
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));pg_size_pretty 6404 MB (1 row)
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));pg_size_pretty 11 GB (1 row)
在此範例中，索引的大小大於資料表。這種差異可能會導致性能問題，因為索引膨脹或未使用，這會影響自動清空以及插入操作。
檢查是否有未使用的索引
使用 pg_stat_user_indexesidx_scan 資料欄搭配使用的頻率。在下列範例中，未使用的索引的 idx_scan 值為 0。
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch -------+------------+------------+------------------+-----------------------+----------+--------------+--------------- 16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0 16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0 16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0 16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0 16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0 16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0 16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0 (7 rows)
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;schemaname | relname | indexrelname | idx_scan ------------+------------------+-----------------------+---------- public | pgbench_accounts | index_f | 6 public | pgbench_accounts | index_b | 3 public | pgbench_accounts | pgbench_accounts_pkey | 0 public | pgbench_accounts | index_d | 0 public | pgbench_accounts | index_e | 0 public | pgbench_accounts | index_c | 0 public | pgbench_accounts | index_a | 0 (7 rows)
注意
這些統計資訊是從統計資訊重設時開始累計的。假設您有僅在營業季度結束時使用的索引，或僅用於特定報告的索引。自統計資訊重設以來，可能尚未使用此索引。如需詳細資訊，請參閱統計資訊函數
若要檢查上次何時重設資料庫的統計資訊，請使用 pg_stat_database
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';datname | stats_reset ----------+------------------------------- postgres | 2022-11-17 08:58:11.427224+00 (1 row)
盡快清空資料表
RDS對於波斯特格雷 SQL 12 及更高版本
如果大型資料表中有太多索引，您的資料庫執行個體可能接近交易 ID wraparound (XID)，也就是當計數XID器換行為零時。若保持取消核取的狀態，此情況可能會導致資料遺失。不過，您可以在不清除索引的情況下快速清空資料表。在RDS後 SQL 12 及更高版本中，您可以使VACUUM用該INDEX_CLEANUP
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;INFO: vacuuming "public.pgbench_accounts" INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517 Skipped 0 pages due to buffer pins, 0 frozen pages. CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
如果自動真空工作階段已在執行中，您必須將其終止才能開始手冊VACUUM。如需執行手動清空凍結的相關資訊，請參閱 執行手動清理凍結。
注意
定期略過索引清除可能會導致索引膨脹，這會影響整體掃描效能。作為最佳實務，只使用上述程序來防止交易 ID 包圍。
RDS對於波斯特格雷 SQL 11 及以上
但是，在 RDS Postgre SQL 11 及更低版本中，允許真空更快地完成的唯一方法是減少表格上的索引數量。捨棄索引可能會影響查詢計畫。我們建議您先刪除未使用的索引，然後在XID環繞非常接近時刪除索引。在清空程序完成之後，您可以重新建立這些索引。
影響自動資料清理的其他參數
以下查詢顯示會直接影響自動資料清理及其行為的某些參數值。自動真空參數
SELECT name, setting, unit, short_desc FROM pg_settings WHERE name IN ( 'autovacuum_max_workers', 'autovacuum_analyze_scale_factor', 'autovacuum_naptime', 'autovacuum_analyze_threshold', 'autovacuum_analyze_scale_factor', 'autovacuum_vacuum_threshold', 'autovacuum_vacuum_scale_factor', 'autovacuum_vacuum_threshold', 'autovacuum_vacuum_cost_delay', 'autovacuum_vacuum_cost_limit', 'vacuum_cost_limit', 'autovacuum_freeze_max_age', 'maintenance_work_mem', 'vacuum_freeze_min_age');
雖然這些全都會影響自動資料清理，其中最重要的參數如下：
設定自動資料清理參數資料表層級
您可以在資料表層級設定自動資料清理相關的儲存參數
以下查詢顯示哪些資料表目前已備妥資料表層級選項。
SELECT relname, reloptions FROM pg_class WHERE reloptions IS NOT null;
在比您其餘的資料表大許多的資料表範例上，此查詢可能很實用。假設您有一個 300 GB 的表單，及 30 個少於 1 GB 的其他表單。在此情況下，您可以為大型資料表設定一些特定參數，您就不會改變整個系統的行為。
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
這麼做會針對此資料表關閉成本型自動資料清理延遲，代價是在您系統上使用更多資源。通常情況下，每次達到 autovacuum_cost_limit 時，自動資料清理都會暫停 autovacuum_vacuum_cost_delay。有關更多詳細信息，請參閱 Postgre SQL 文檔有關基於成本
記錄清理和自動資料清理活動
有關自動資料清理活動的資訊將根據 rds.force_autovacuum_logging_level 參數中指定的層級傳送到 postgresql.log。以下是此參數所允許的值，以及該值為預設設定的 Postgre SQL 版本：
disabled(後排 SQL 10, 波斯特格雷 9.6SQL)debug5,debug4,debug3,debug2,debug1info(後世紀 SQL 12, 波斯特格雷 SQL 11)noticewarning(波斯格雷 SQL 13 及以上)error、日誌、fatal、panic
rds.force_autovacuum_logging_level 使用 log_autovacuum_min_duration 參數。log_autovacuum_min_duration 參數的值是記錄自動資料清理動作的閾值 (以毫秒為單位)。設定為 -1，表示不會記錄任何內容；設定為 0，則會記錄所有動作。如同 rds.force_autovacuum_logging_level，log_autovacuum_min_duration 的預設值取決於版本，如下所示：
10000 ms— 後排 SQL 14, 後格雷 SQL 13, 後格雷 SQL 12, 和波斯特格雷 11 SQL(empty)— 沒有默認值後 SQL 10 和波斯特格雷 9.6 SQL
建議您將 rds.force_autovacuum_logging_level 設定為 WARNING。我們也建議您將 log_autovacuum_min_duration 設定為 1000 到 5000 之間的值。設定為 5000，表示會記錄時間超過 5,000 毫秒的活動。如果鎖定衝突或同時刪除關係導致跳過自動資料清理動作，-1 以外的任何設定也會記錄訊息。如需詳細資訊，請參閱 Postgre 文SQL件中的自動吸塵功
若要解決問題，您可以將 rds.force_autovacuum_logging_level 參數變更為其中一個除錯等級 (從 debug1 至 debug5)，以取得詳盡資訊。我們建議您在短時間內使用除錯設定，並且僅用於疑難排解目的。要了解更多信息，請參閱 Postgre SQL 文檔中的何時登錄
注意
Postgre SQL 允許該rds_superuser帳戶查看中的自動真空會話。pg_stat_activity例如，您可以找出並終止會阻擋命令執行的自動資料清理工作階段，或是執行速度比手動發出的清理命令還要慢的自動資料清理工作階段。
