選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

在 RDS for Postgre 中解決無法識別的真空封鎖程式SQL

焦點模式

在本頁面

在 RDS for Postgre 中解決無法識別的真空封鎖程式SQL - Amazon Relational Database Service

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

本節會探索其他原因,以防止清空進展。postgres_get_av_diag() 函數目前無法直接識別這些問題。

無效的頁面

當 PostgreSQL 在存取該頁面時偵測到頁面檢查總和不相符時,會發生無效頁面錯誤。內容無法讀取,防止自動清空凍結元組。這可有效停止清除程序。下列錯誤會寫入 Postgre SQL的日誌:

WARNING: page verification failed, calculated checksum YYYYY but expected XXXX ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX CONTEXT: automatic vacuum of table myschema.mytable

判斷物件類型

ERROR: invalid page in block 4305910 of relation base/16403/186752608 WARNING: page verification failed, calculated checksum 50065 but expected 60033

從錯誤訊息中,路徑base/16403/186752608會提供下列資訊:

  • "base" 是 PostgreSQL 資料目錄下的目錄名稱。

  • "16403" 是資料庫 OID,您可以在pg_database系統目錄中查詢。

  • "186752608" 是 relfilenode,可用來查詢pg_class系統目錄中的結構描述和物件名稱。

透過檢查受影響資料庫中下列查詢的輸出,您可以判斷物件類型。下列查詢會擷取 oid 的物件資訊:186752608。將 取代OID為與您遇到的錯誤相關的 。

SELECT relname AS object_name, relkind AS object_type, nspname AS schema_name FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid WHERE c.oid = 186752608;

如需詳細資訊,請參閱 PostgreSQL 文件pg_class以了解所有支援的物件類型,如 中的 relkind 欄所指出pg_class

指引

此問題最有效的解決方案取決於特定 Amazon RDS執行個體的組態,以及受不一致頁面影響的資料類型。

如果物件類型是索引:

建議重建索引。

  • 使用 CONCURRENTLY選項 – PostgreSQL 第 12 版之前,重建索引需要唯一資料表鎖定,限制對資料表的存取。使用 PostgreSQL 第 12 版和更新版本, CONCURRENTLY選項允許資料列層級鎖定,大幅改善資料表的可用性。以下是 命令:

    REINDEX INDEX ix_name CONCURRENTLY;

    雖然 CONCURRENTLY較不中斷,但忙碌資料表的速度可能會變慢。如果可能,請考慮在低流量期間建立索引。

    如需詳細資訊,請參閱 PostgreSQL REINDEX 文件。

  • 使用 INDEX_CLEANUP FALSE選項 – 如果索引較大且估計需要大量時間才能完成,您可以在排除索引VACUUM FREEZE的同時執行手動來取消封鎖自動清空。此功能可在 PostgreSQL 第 12 版及更新版本中使用。

    略過索引可讓您略過不一致索引的清空程序,並減輕包裝問題。不過,這無法解決基礎的無效頁面問題。若要完全解決和解決無效的頁面問題,您仍然需要重建索引。

如果物件類型是具體化檢視:

如果具體化視觀表上發生無效頁面錯誤,請登入受影響的資料庫並重新整理以解決無效頁面:

重新整理具體化檢視:

REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;

如果重新整理失敗,請嘗試重新建立:

DROP MATERIALIZED VIEW schema_name.materialized_view_name; CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;

重新整理或重新建立具體化視觀表會將其還原,而不會影響基礎資料表資料。

對於所有其他物件類型:

對於所有其他物件類型,請聯絡 AWS 支援。

索引不一致

邏輯上不一致的索引可防止自動清空進行進度。下列錯誤或類似錯誤會在索引的清空階段期間或當 SQL陳述式存取索引時記錄。

ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX CONTEXT: while vacuuming index index_name of relation schema.table

指引

在手動 INDEX_CLEANUP上使用 重建索引或略過索引VACUUM FREEZE。如需如何重建索引的資訊,請參閱如果物件類型是索引

極高的交易率

在 Postgre 中SQL,高交易速率可能會顯著影響自動清理的效能,導致較慢的無效元組清除速度,並增加交易 ID 包裝的風險。您可以透過測量兩個時段max(age(datfrozenxid))之間的差異來監控交易速率,通常是每秒。此外,您可以使用 RDS Performance Insights 中的下列計數器指標來測量交易速率 (xact_commit 和 xact_rollback 的總和),這是交易的總數。

計數器 類型 單位 指標

xact_commit

交易

每秒遞交數

db.Transactions.xact_commit

xact_rollback

交易

每秒轉返數

db.Transactions.xact_rollback

快速增加表示交易負載很高,可能會壓倒自動清空,導致膨脹、鎖定爭用和潛在的效能問題。這可能會在幾個方面對自動清空程序產生負面影響:

  • 資料表活動:正在清空的特定資料表可能遇到大量交易,導致延遲。

  • 系統資源 整體系統可能會過載,使得自動清空難以存取必要的資源以有效率地運作。

請考慮下列策略,以允許自動清空更有效地運作並跟上其任務:

  1. 如果可能,請降低交易速率。在可行的情況下,考慮批次或分組類似的交易。

  2. 以經常更新的資料表為目標,在非尖峰時段內,以每晚、每週或每兩週手動VACUUM FREEZE操作。

  3. 考慮擴展執行個體類別以配置更多系統資源,以處理高交易量和自動清空。

隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。