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)

장기 실행 트랜잭션을 야기하는 일반적인 문제

다음 동작으로 인해 트랜잭션이 장기 실행될 수 있습니다.

  • 사용자는 자동 커밋이 비활성화된 클라이언트에서 암시적 트랜잭션을 시작합니다. 따라서 사용자가 COMMIT 또는 ROLLBACK 명령을 사용하여 트랜잭션을 명시적으로 닫을 때까지 또는 세션이 종료될 때까지 트랜잭션이 활성 상태로 유지됩니다.
  • 사용자가 BEGIN을 사용하여 트랜잭션을 명시적으로 시작했지만 COMMIT 또는 ROLLBACK 명령을 사용하여 트랜잭션을 닫지 않은 경우입니다.

이 문서가 도움이 되었습니까?


결제 또는 기술 지원이 필요합니까?