지난 글에서 control file에 대해 살펴보며
recovery 시, 컨트롤파일의 어떤 정보를 참고하고,
어떻게 복구의 필요성을 결정하며 복구는 어떻게 진행되는지를
간단히 살펴보았습니다.
이번 글에서는 DB를 복구하기 위한 핵심 데이터인
redo log를 관리하는 두 방법에 대해 알아보겠습니다.
1. Archive log와 no archive log
Oracle 백업 복구의 핵심은 redo log이며 이를 관리하는 방법에 따라
archive log, no archive log로 나뉨
위에서 보듯이 archive log list 명령어로 DB의 아카이브 모드를 확인할 수 있고
아카이브 로그파일들이 어디로 떨어지는지도 확인 할 수 있다.
--1. no archive mode
no archive mode 에서는 꽉 찬 redo log file을 따로 저장하지 않고
그 위에 덮어써버리는 단점이 있음
-->SCN 50이 필요해도 SCN 52가 덮어 써버리고 SCN 50을 따로 아카이빙 하지 않았기 때문에
그대로 손실됨
--2. archive mode
no archive mode와는 달리 redo log file이 꽉차서 log switch가 일어날 경우,
해당 리두파일을 아카이브파일로 옮기기 때문에 데이터 손실의 위험이 없다.
--3. archive mode 시나리오
.png)
1) SCN 100번까지 저장되어 있는 A데이터파일이 삭제되는 장애 발생
2) A 데이터파일에 대한 백업 본은 SCN 95번까지 있음 ->그대로 사용하면 데이터파일 끼리 SCN값이 맞지 않아 사용불가능
3) 백업본을 복사하여 복구 시작
4) control file의 체크포인트 scn은 100이고 백업본은 95이기 때문에 그 차이만큼 복구필요
5) SCN 98,99,100 은 비교적 최근 데이터라서 redo log file에 있지만 96,97 은 archive log file에 있음
6) redo log file과 archive log file에서 해당 데이터 가져와서 복구
*Archive Hang
Archive 저장공간의 부족으로 더 이상 Archive File을 생성하지 못하여 DB가 대기하게 되는 현상
--1. 원인
1) 저장공간 부족
2) 저장공간 경로가 잘못 되었을 경우 (init file에서 지정)
3) 저장공간의 권한 문제
--2. 복구방법
1) alert log 확인 및 상태확인
2) 여유공간 확보
3) archive 재시작
4) full 백업(권장)
1. alert log 확인 및 상태확인
==> 저장공간 부족 등의 이유로 25번부터 archiving 되지 않고 있는 상황
SQL>SELECT * FROM V$LOG;
sequence#의 번호가 26,27,25 로 표시되어 있고 archive 가 모두 NO
==> sequence# 25번부터 저장이 안되어 26,27 모두 archive 가 안된 것 확인
SQL>show parameter log_archive_dest
2. 여유공간 확보 및 장애조치
파일을 삭제, 증설 등 조치를 취하여 여유공간을 확보.
여유공간의 문제가 디렉토리에 대한 권한이 없을 수도 있으니 확인 필요함
3. archive 재시작
SQL> alter system set log_archive_dest_state_1=defer;
SQL> alter system set log_archive_dest_state_1=enable;
SQL> alter system archive log stop;
SQL> alter system archive log start;
