실무 로그 설계는 네 가지 운영 질문으로 정리됩니다

ARCHIVELOG를 켰다로 끝나지 않습니다. 실제 복구 가능성은 로그를 남기는 구조와 복구 시간을 조정하는 레버에서 결정됩니다.

아래 네 질문을 기준으로 보면, 저장 위치와 보존 정책이 복구 범위를 만들고 로그 버퍼와 체크포인트가 평상시 성능과 재시작 시간을 함께 바꾼다는 점이 한 번에 드러납니다.

운영 질문

설계 판단과 결과

복구 범위

디스크가 고장 나도 로그가 살아남는가?

데이터 파일과 다른 디스크에 두고, 온라인 로그를 멀티플렉싱하거나 아카이브로 복제합니다.

로그 생존 경로가 분리되어야 미디어 장애 뒤에도 백업 복원과 PITR이 계속 이어집니다.

복구 범위

얼마나 오래 과거 시점으로 되돌릴 수 있는가?

아카이브 로그 보존 기간을 업무 기준으로 먼저 정합니다.

보존 기간이 짧으면 저장 비용은 줄지만, 실수 직전 시점이나 감사가 요구하는 시점까지는 되돌아갈 수 없습니다.

운영 성능

평상시 커밋 비용이 과하게 커지지 않는가?

LOG_BUFFER / wal_buffers는 flush 빈도와 메모리 사용의 균형점입니다.

너무 작으면 로그를 자주 밀어내고, 너무 크면 추가 이익 없이 메모리만 더 점유합니다.

운영 성능

장애 후 재시작 복구 시간은 얼마나 허용할 것인가?

체크포인트 간격은 Redo 범위와 평상시 I/O 부담을 서로 맞바꿉니다.

짧으면 재시작은 빨라지지만 쓰기 부담이 늘고, 길면 운영은 가벼워지지만 장애 후 더 많은 로그를 다시 읽어야 합니다.

핵심

좋은 로그 설계는 로그를 잃지 않게 남기는 구조와 로그를 얼마나 자주 디스크 상태로 확정할지를 함께 조정해, 미디어 장애 복구와 일상 성능을 동시에 관리하는 일입니다.