为什么 Amazon Redshift VACUUM 操作没有回收磁盘空间?

上次更新时间:2020 年 8 月 17 日

我正在对一个 Amazon Redshift 表运行 VACUUM FULL 或 VACUUM DELETE ONLY 操作,该表包含标记为删除的行。此操作看起来会成功完成。为什么没有任何回收磁盘空间?

简短描述

如果有长时间运行的事务处理仍然保持活动状态,磁盘空间可能不会被回收。删除行时,隐藏的元数据身份列 DELETE_XID 会标记上删除行的事务 ID。如果一个长时间运行的活动事务处理在删除前开始,VACUUM 将无法清理行。因此,磁盘空间无法回收。有关 DELETE_XID 列的更多信息,请参阅针对缩小表优化存储

解决方法

1.    要检查集群上的长时间运行事务处理,请运行以下查询:

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)

2.    运行以下查询以确认是否已从 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 回收这些已删除的行,请选择以下任意一个选项,然后重新运行 VACUUM 操作:

  • 请等待长时间运行的事务处理完成。
  • 使用 PG_TERMINATE_BACKEND 语句来终止保持长时间运行的事务处理的会话。

调查长时间运行的事务处理

查看 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)

导致事务处理长时间运行的常见问题

以下行为可能会导致事务处理长时间运行:

  • 用户从禁用自动提交的客户端开始某个隐式事务处理。该事务处理在用户使用 COMMITROLLBACK 命令显式关闭该事务处理或会话终止前保持活动状态。
  • 用户使用 BEGIN 显式启动了某个事务处理,但从未使用 COMMITROLLBACK 命令关闭该事务处理。

这篇文章对您有帮助吗?


您是否需要账单或技术支持?