Amazon Redshift VACUUM 작업으로 디스크 공간을 다시 확보하지 못하는 이유는 무엇입니까?

간략한 설명

테이블 행을 삭제하면 숨겨진 메타데이터 ID 열(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 명령으로 트랜잭션을 닫지 않습니다.

관련 정보

테이블 정리

정리 시간 최소화