현재 회사에서 운영중인 서비스의 사용자 접속 로그 테이블 데이터를 따로 관리하지 않아 보존주기만큼을 제외하고 데이터를 삭제한 후 주기적으로 로그를 삭제하는 스케줄링 작업을 진행중이였습니다.
50gb정도 되는 테이블을 작업해야하고, 평소 db를 공부하면서 트랜잭션을 너무 길게 가져가면 undo 로그가 커지고 너무 짧게 가져가면 컨텍스트 스위칭 비용이나 데이터베이스 콜 비용이 크다고 알고 있어 1천건 ~ 10만건 단위로 테스트 해보면서 삭제했습니다.
작업의 80%정도 완료했을 때 db 모니터링 상 문제가 발생해 작업을 지연하게 되었는데 트랜잭션을 커밋해도 아카이브 로그에 데이터가 일정 기간 존재하고, Amazon RDS 환경에서는 아카이브 로그 공간이 한 번 커진 이후에는 줄어들지 않아 비용이 지속적으로 발생하는 문제가 있었습니다. 이에 따라 아카이브 로그의 보존 주기가 지나 로그가 정리된 이후에 다시 작업을 재개하게 되었습니다.
대용량 DML 작업은 단순한 delete 쿼리의 반복이 아니라는 걸 배울 수 있었습니다...
