[B/R] Archive log mode와 No Archive log mode

◆ 아카이브 모드의 필요성
아래 그림에서 A~E까지 데이터를 입력할 때, 한건 입력시마다 로그스위치가 일어난다고 가정한다.

1. A~E까지 데이터파일로 내려써진 상태에서 시작한다. A가 내려써지고 난 후 그 상태의 데이터파일을 백업받아 놓았다.

2. E까지 내려써진 데이터파일이 삭제되는 장애가 발생했다.

3. 백업받아놓았던 백업 데이터파일을 복원한 후 컨트롤파일과 데이터파일의 SCN을 비교하고, 리두로그파일에서 복구를 시도하지만, 노아카이브 모드로 인해 SCN2번의 로그정보가 덮어씌여져 버렸다. 결론적으로 E까지의 데이터는 복구 실패 하였다.

4. 3과 같은 상황이지만 DB가 아카이브 모드였다면 SCN2번의 정보가 아카이브된 리두로그파일에 아카이빙 되어 있으므로 복구 가능하다.

5. E까지 복구가 완료됨을 확인 할 수 있다.

위에서 살펴본 상황과 같이 DB가 노아카이브 모드로 운영되었다면 덮어씌여진 기록으로 인해 데이터를 복구하지 못하였으나, 아카이브 모드로 운영되었다면 아카이빙 된 기록으로 인해 데이터를 복구함을 알 수 있다.

백업된 데이터파일을 복원 후 오라클에게 해당 데이터를 고치라고 recover 명령을 날리면 오라클이 이전에 멀쩡했을 때의 것과 비교를 한 후 고장이 났음을 안다. 이때 멀쩡했을 때의 정보를 컨트롤파일의 체크포인트 SCN을 보고 안다.

recover명령을 날리면 컨트롤파일을 먼저 읽어서 가장 마지막에 작업했던 SCN번호를 보는데 5번이다. 그런 후 데이터파일의 SCN번호를 보았는데 1번이다. 이것을 보고 서로 SCN이 맞지 않으니까 장애가 난 사실을 알게 된다.
현재 데이터파일의 SCN은 1번이므로 2~5번까지의 정보를 리두로그파일에서 찾는다.
찾을 때는 가장 최근에 작업한 SCN번호인 컨트롤파일의 5번부터 복원된 데이터파일의 SCN번호인 1번 이후까지 거꾸로 리두로그파일에서 찾는다. (5 → 4 → 3 → 2)

찾을 때는 컨트롤파일 SCN부터 거꾸로 찾는데, 복구 시에는 데이터파일 SCN 다음 번호부터 순차적으로 복구를 시도한다.(2 → 3 → 4 → 5)

그러나 위 상황으로는 2번이 덮어씌여져 버렸으므로 절대로 건너뛰고 3번부터 복구가 될 수 없다. 2번이 없으면 나머지 3, 4, 5번은 있으나 마나한 기록이 되어버린다.

아무리 아카이브모드 상태의 DB에서 아카이브 로그 파일이 많다고 해도 중간에 한 기록이라도 빠져버리면 그 이후의 것은 사용 불가능하다.
이것은 나중에 배울 로그마이너 라는 기술을 통해 아카이브 파일과 온라인 리두로그파일의 내용을 열어보아 해당 데이터를 일일이 입력해주는 방법 밖에 없다.

노아카이브 모드와 아카이브 모드 중 어떤 게 더 안전할까? 당연히 아카이브 모드이다.
그러나 실제 현장에 나가보면 아카이브 모드를 잘 못쓰는 상황도 많이 있다. 오라클을 처음 딱 깔면 기본 모드는 노아카이브 모드이다.

---

◆ ARCn
아카이버(Archiver)라고 하는 이 프로세스는 로그스위치가 발생하면, 이전의 온라인 리두로그파일의 로그정보를 아카이브 리두로그파일로 내려쓰는 역할을 한다.
ARCn은 한번에 여러 개가 띄워질 수 있다. DB를 아카이브 모드로 시작하면 기본적으로 3개가 띄워진다.(ARC0~ARC2)
DB를 아카이브 모드로 운영하면 리두로그의 기본 상태 3가지(CURRENT, ACTIVE, INACTIVE) 외에 온라인 리두로그가 아카이빙이 되었는지 안되었는지를 뜻하는 2가지 상태(ARCHIVING, NOARCHIVING)가 더 추가된다.


◆ Archive Hang 현상
리두로그파일도 다중화를 하듯이 아카이브파일도 다중화를 할 수 있다. 아카이브파일 하나의 크기가 1G라고 하자. 아카이브파일을 저장할 디렉토리를 아카이브 디렉토리라고 하자. 아카이브 디렉토리의 경로는 /data 이고 해당 디렉토리의 용량은 100G라고 한다.
DB를 운영중에 아카이브 디렉토리가 가득 찼다면 로그스위치가 일어나도 아카이버가 온라인 리두로그를 아카이브파일로 내려쓰질 못한다.
비록 온라인 리두로그가 INACTIVE가 되었다 할지라도 내려쓸 아카이브 디렉토리가 꽉 찼기 때문에 아카이빙 작업은 할수가 없고, 온라인 리두로그를 재사용하려 다시 처음 위치로 로그 스위치가 되는 상황에도 아직 내려쓰지 못한 상태이기 때문에 덮어쓸 수가 없다. 앞에 리두로그의 아카이빙을 끝내지 못했으므로 순차적으로 뒤의 것들도 아카이빙을 하지 못한다.
아무리 위에서 커밋을 날린다 치더라도 아카이빙이 되지 않아 결국 DB가 올스톱 되는 사태가 일어난다. 이 현상을 Archive Hang(아카이브 행) 현상이라 한다.
Archive Hang이 일어나면 DB가 뻗어버린다. DB를 껐다 켜면 일시적으로는 문제가 없어 보인다. 이유는 리두로그버퍼의 내용이 서버를 재시작하면서 비었기 때문에 일정량의 로그기록이 리두로그버퍼에 찰 때까지는 괜찮다. 하지만 커밋 후 로그스위치가 일어나면 또다시 아카이버가 온라인 리두로그의 내용을 아카이브로그파일로 내려써야 하는데 그때 또다시 아카이빙이 중지되면서 행이 걸리고 만다.


◆ 아카이브 모드시 주의사항
  - 아카이브 디렉토리 용량은 굉장히 커야 한다.(스토리지 용량이 고용량이어야 함)
  - 주기적으로 아키이브 디렉토리를 조회하여 불필요한 아카이브 리두로그 파일은 지워준다. (용량확보)


◆ ORA-00257 : Archiver error. Connect internal only, until freed.
위 오류는 해당 디스크에 더이상 아카이브로그가 쌓일 공간이 없을 때 발생 가능성이 높은 에러코드이다.
해결 방안은 아카이브로그가 쌓이는 디렉토리의 용량을 확보해주면 된다.
DB운영중에 alter system set 명령어로 아카이브 디렉토리를 잠시 다른 곳으로 변경해주고 아래 로그 지우는 요령대로 지운 후 다시 원래 아카이브 디렉토리로 바꿔주면 되는데, 그래도 안된다면 아카이버(ARCn)를 정지시켰다가 다시 시작시켜주면 해결 가능하다.

SQL> alter system archive log stop;
SQL> alter system archive log start;

단, 이 명령어를 쳤다 해도 바로 적용되는 것이 아니라 몇 분정도 기다려야 한다.


◆ 아카이브 디렉토리 안의 아카이브 리두로그파일 지우는 요령
아카이브 디렉토리 안에 SCN이 1번인 것부터 100번까지의 아카이브파일이 들어있다고 할 때, 백업 데이터파일 SCN은 10번이라고 가정한다. 그러면 1~10번까지의 아카이브파일은 필요가 없으므로 지워주어도 된다.
이유는 복구 시 백업 데이터파일 SCN번호가 10번이므로 11번부터 컨트롤파일의 SCN번호까지의 리두로그를 찾기 때문이다.
그렇다면 어떻게 데이터파일의 SCN과 컨트롤파일의 SCN을 알 수 있을까? 그것을 알아야 아카이브 파일에서 필요없는 것들을 지울 것이 아닌가?
방법은 이렇다. DB가 정상적일 때 체크포인트를 날려주고난 후 풀백업을 받는다. 그럼 풀백업을 받은 시점까지는 아무런 이상이 없다는 증거가 되므로 아카이브 디렉토리 안의 파일들을 지워주면 된다.


◆ 운영중인 서버와 타임서버와의 시간 동기화 방법
운영중인 서버에 시간을 동기화시키면 나중에 심각한 문제가 될 소지가 있다. 시간기반 복구를 할 때 시간이 서로 맞지 않아 복구가 되지 않는 경우 등 여러가지 사태가 발생 가능하다.
절대로 운영중인 서버의 시간은 함부로 동기화 시키지 않도록 주의한다.

$ rdate -s 타임서버IP주소

---

◆ 노아카이브모드 → 아카이브모드 변경방법

① DB 셧다운 된 상태에서 파라미터 파일에 아카이브 디렉토리 경로와 아카이브파일명 포맷을 지정해준다.
  ↓
② DB를 마운트까지 올린다.
  ↓
③ alter 명령으로 아카이브모드로 변경한다.
  ↓
④ DB를 오픈한다.

SQL> shutdown immediate;

$ vi /home/oracle/product/10g/dbs/inittestdb.ora
log_archive_dest_1='location=/data/arc1'     // ARC0이 아카이빙 함. 필요시 더 추가하면 됨.
log_archive_dest_2='location=/data/arc2'     // ARC1이 아카이빙 함.
log_archive_format=%t_%s_%r.arc               // Thread# + Sequence# + Incarnation# (순서는 바껴도 됨)
log_archive_start=true     // 9i전용 파라미터로 9i에서 아카이브모드로 시작하려면 해당 파라미터를 추가해줘야 한다. 단, 10g에서 이 줄을 추가하면 DB가 스타트업이 되지 않으므로 오직 9i에서만 사용할 것.

SQL> startup mount;
SQL> archive log list;     // 현재 DB의 아카이브모드 여부를 조회함. DB가 아카이브모드인지 아닌지의 정보는 컨트롤파일 안에 들어있음.
SQL> alter database archivelog;     // 노아카이브 모드로 하고 싶다면 noarchivelog
SQL> alter database open;

DB를 깔면 기본적으로 아카이브 로그파일과 플래시백, RMAN의 파일은 모두 /home/oracle/flash_recovery_area에 2G까지 저장된다. 이 경로는 파라미터파일 안에 db_recovery_file_dest 값에 적혀있는 경로이다.
문제는 위 경로가 순식간에 2G가 찰 수 있다는 것이다.
그래서 아카이브용도로 스토리지를 추가하여 별도로 아카이브파일을 저장하도록 한다. 이것이 나중에 한쪽 디스크가 나가도 데이터 복구 가능성을 늘리는 방법이다.

또 한가지, 실수를 자주 하는 것은 아카이브용 스토리지 추가시 아카이빙 디렉토리의 소유주를 루트에서 오라클 계정으로 주어야 하는데 그것을 깜박 해버리면, ARCn은 오라클 계정 것인데 아카이브 디렉토리는 루트의 것이기에 역시 아카이빙을 하지 못해 Archive Hang 현상을 유발할 수 있으므로 주의한다.