Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
為什麼 Amazon Redshift VACUUM 作業沒有回收磁碟空間?
在 Amazon Redshift 資料表上執行的 VACUUM 作業已成功完成。然而,磁碟使用率仍然偏高。
簡短描述
當您刪除資料表資料列時,隱藏的中繼資料身分資料欄 (DELETE_XID) 會標記為已刪除該資料列的交易 ID。
如果長時間執行的作用中交易在刪除之前啟動,那麼 VACUUM 就無法清理資料列,也無法回收磁碟空間。
如需 DELETE_XID 資料欄的相關資訊,請參閱最佳化儲存體以縮小資料表。
解決方法
若要檢查 Amazon Redshift 叢集上是否有長時間執行的交易,請執行下列查詢:
rsdb=# select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' duration from svv_transactions where lockable_object_type='transactionid' and pid<>pg_backend_pid() order by 3;
下列輸出顯示 xid 50341 已經處於作用中狀態 19 分 37 秒:
txn_owner | txn_db | xid | pid | txn_start | lock_mode | lockable_object_type | relation | granted | duration -----------+--------+-------+-------+----------------------------+---------------+----------------------+----------+---------+------------------------------ superuser | rsdb | 50341 | 21612 | 2019-08-19 20:20:33.147622 | ExclusiveLock | transactionid | | t | 0 days 0 hrs 19 mins 37 secs (1 row)
若要確認您是否已從 Amazon Redshift 資料表中刪除資料列,請執行下列查詢:
select a.query, a.xid, trim(c.name) tablename, b.deleted_rows, a.starttime, a.endtime from stl_query a join (select query, tbl, sum(rows) deleted_rows from stl_delete group by 1,2) b on a.query = b.query join (select id, name from stv_tbl_perm group by 1,2) c on c.id = b.tbl where a.xid in (select distinct xid from stl_commit_stats) and trim(c.name) = 'tablename' order by a.starttime;
下列輸出顯示標記為資料列刪除的交易 (xid 50350) 在長時間執行的交易 (xid 50341) 之後啟動:
query | xid | tablename | deleted_rows | starttime | endtime -------+-------+-----------+--------------+----------------------------+---------------------------- 18026 | 50350 | test | 5 | 2019-08-19 20:20:48.137594 | 2019-08-19 20:20:50.125609 (1 rows)
若要允許 VACUUM DELETE 回收這些已刪除的資料列,請選擇下列其中一個選項:
- 等待長時間執行的交易完成。
- 使用 PG_TERMINATE_BACKEND 陳述式來終止保留長時間執行交易的工作階段。
完成上述動作後,重新執行 VACUUM 作業。
調查長時間執行的交易
若要檢查長時間執行交易中的活動,請查詢 SVL_STATEMENTTEXT 檢視:
rsdb=# select pid, xid, trim(label), starttime, endtime, trim(text) from svl_statementtext where xid = 50341 order by starttime , sequence;
輸出範例:
pid | xid | btrim | starttime | endtime | btrim -------+-------+---------+----------------------------+----------------------------+-------------------------- 21612 | 50341 | default | 2019-08-19 20:20:31.733843 | 2019-08-19 20:20:31.733844 | begin; 21612 | 50341 | default | 2019-08-19 20:20:33.146937 | 2019-08-19 20:20:35.020556 | select * from sometable; (2 rows)
若要檢查查詢是否在交易中執行,請查詢 STV_INFLIGHT 檢視:
rsdb=# select query, xid, pid, starttime, trim(text) from stv_inflight where xid = 50341;
輸出範例:
query | xid | pid | starttime | btrim -------+-----+-----+-----------+------- (0 rows)
長時間執行交易的常見原因
下列行為可能會導致長時間執行的交易:
- 使用者從關閉自動認可的用戶端啟動隱式交易。該交易會保持作用中狀態,直到使用者透過 COMMIT 或 ROLLBACK 命令關閉交易,或者工作階段終止為止。
- 使用者啟動交易並使用 BEGIN,但從未透過 COMMIT 或 ROLLBACK 命令關閉該交易。
相關資訊
相關內容
- 已提問 3 年前
- 已提問 3 年前

