[Admin] Redo Log File

◆ 리두로그파일
  - 복구 메커니즘을 제공하는 파일
  - 데이터의 모든 변경사항을 기록함
  - 적어도 두개의 그룹, 그룹당 한개의 멤버를 가지고 있어야 한다.
  - 직접 내용을 우리가 볼 수는 없지만 컨트롤파일 안에 MAXLOGFILES항목은 리두로그그룹의 최대갯수를 조정하는 것이고, MAXLOGMEMBERS항목은 그룹당 멤버의 최대갯수를 조정하는 것이다.
  - 한 그룹의 멤버들끼리는 사이즈가 같다. 그룹끼리는 사이즈가 달라도 되나 관리하기가 어려우므로 동일하게 해주는 것이 좋다.
  - 하나의 리두로그파일이 꽉 차면 다음 리두로그파일로 쓰기 시작하는데 이때 발생하는 신호를 로그스위치라 한다. 로그스위치가 일어나면 체크포인트는 자동으로 일어난다.(CKPT가 로그스위치가 일어나는 것을 확인 후 체크포인트 신호를 날림)
  - 컨트롤파일과 데이터파일에 체크포인트SCN 정보를 기록함.
  - 리두로그는 사이즈를 못늘린다. 삭제하고 다시 만들어줘야 한다.


◆ 체크포인트의 두가지 종류
체크포인트 날릴 때마다 무조건 DBWR에게 내려쓰라고 하지는 않는다. 체크포인트 큐라는 곳에 엔트리를 계속 넣다가 일정 조건이 만족하면 내려쓰는 것이다.
  ◇ 증분체크포인트(Incremental Checkpoint)
    - 로그스위치가 일어나면 DBWR이 체크포인트 큐의 가장 아래에 있는 엔트리부터 내려쓰는데 그 일부만 내려씀.
  ◇ 전체체크포인트(Full Checkpoint)
    - alter system checkpoint;명령어를 날리면 체크포인트 큐에 있는 모든 엔트리를 내려씀.


◆ 리두로그의 세가지 상태
  - CURRENT : 현재 쓰고 있는 리두로그파일 상태.
  - ACTIVE : 리두로그파일에 변경된 내용이 아직 데이터파일에는 안내려진 상태.
  - INACTIVE : 리두로그파일의 내용이 데이터파일로 다 내려써진 상태.


◆ 로그스위치 수동으로 일으키기
로그스위치를 일으키면 CURRENT가 ACTIVE로 바뀐다. 하지만 현재 CURRENT가 어느 그룹으로 CURRENT될지는 모른다. 즉, 그룹번호가 부여되도 그게 순차적으로 진행되는 건 아니라는 것이다.

SQL> alter system switch logfile;

◆ 체크포인트 수동으로 일으키기
체크포인트를 일으키면 ACTIVE가 INACTIVE로 바뀐다.

SQL> alter system checkpoint;

◆ 리두로그파일 상태 및 정의 조회 쿼리

SQL> select a.group#, a.member, b.bytes/1024/1024 MB, b.sequence#, b.archived, b.status
   from v$logfile a, v$log b
   where a.group#=b.group#
   order by 1, 2;

◆ 리두로그 그룹 추가

SQL> alter database add logfile group 그룹번호
   '리두로그파일명' size 크기;

SQL> alter database add logfile group 4
   '/home/oracle/oradata/testdb/redo04.log' size 10M;

◆ 리두로그 멤버 추가

SQL> alter database add logfile member
   '리두로그파일명' to group 그룹번호;

SQL> alter database add logfile member
   '/home/oracle/oradata/testdb/redo04_b.log' to group 4;

◆ 리두로그 그룹 삭제
  - 해당 그룹에 멤버가 1개밖에 남지 않았다면 그룹삭제를 해야만 지울 수 있다.
  - 8i까지는 멤버가 2개 이상 들어있는 그룹을 한번에 삭제 불가능했다. 꼭 멤버 하나가 남게 한다음 그룹삭제가 가능했다. 하지만 9i부터는 그룹에 멤버가 여러 개 있어도 그룹을 한방에 삭제 가능하다.
  - INACTIVE만 삭제 가능하다. 
  - 리두로그파일 상태 조회 쿼리를 날려서 리두로그파일의 상태를 확인 후 로그스위치를 날려서 CURRENT는 ACTIVE로 바꾼 후, 체크포인트를 날려서 ACTIVE를 INACTIVE로 바꾼 후 삭제를 하면 된다.
  - OS명령어로 파일 먼저 삭제하고 alter명령을 날리면 에러가 나면서 안지워진다. 왜냐하면 alter명령을 날리면 서버프로세스가 컨트롤파일 안에 있는 리두로그파일의 명단과 위치를 보고 찾아가서 있으면 지우는데, 가보니 이미 OS명령어로 삭제했다면 해당 파일이 없다며 에러를 띄우게 된다.

SQL> alter database drop logfile group 그룹번호;

SQL> alter database drop logfile group 4;

◆ 리두로그 멤버 삭제
  - INACTIVE만 삭제 가능하다.

SQL> alter database drop logfile member
   '리두로그파일명';

SQL> alter database drop logfile member
   '/home/oracle/oradata/testdb/redo04_b.log';

◆ 리두로그 관련 동적성능뷰
  - V$LOG
  - V$LOGFILE


◆ 리두 로그 메커니즘

① insert명령을 이용하여 A를 입력하면 맨 처음 리두로그버퍼에 기록된다.
② 그다음 DB캐시에 A가 입력된다.
③ 커밋 명령이 떨어지면 LGWR은 리두로그버퍼에 있는 A를 리두로그파일로 내려쓴다. 그러고난 후 리두로그버퍼에 있는 A는 지운다. 리두로그파일에 내려써진 A에 고유한 번호를 부여한다. 이를 SCN(System Commit Number)이라고 한다. 모든 커밋은 SCN번호를 다르게 부여한다.(SCN은 각 작업에 대한 고유한 주민번호임)
④ 한쪽 로그파일이 다 차면 다음 파일로 넘어가면서 일종의 신호를 발생시키는데 이를 로그스위치라 한다. 로그스위치가 발생하면 CKPT프로세스는 이전 리두로그파일의 가장 마지막 SCN을 DB캐시의 체크포인트큐라는 공간에 넣는다. 우리는 마지막 SCN번호를 특별히 체크포인트SCN이라고 부른다.
⑤ CKPT프로세스가 DBWR에게 SCN이 1번부터 100번까지인 녀석들을 다 내려쓰라고 체크포인트 신호를 날린다.
⑥ DBWR이 데이터파일로 내용을 내려쓴다.
⑦ CKPT프로세스는 DBWR이 내용을 다 내려쓴 후에 데이터파일과 컨트롤파일의 헤더에 체크포인트SCN을 적는다. 컨트롤파일에는 왜 체크포인트SCN을 기록할까? 이는 몇번까지 내려썼다고 알기 위한 정보이다.

---

앞전에서 우리는 DBWR이 3초에 한번씩 DB캐시의 내용을 데이터파일로 내려쓴다고 했는데, 컨트롤파일에는 가장 최근까지 내려쓴 데이터를 알리는 체크포인트SCN정보가 있어야 한다. 그래서 DBWR은 3초에 한번씩 DB캐시의 내용을 데이터파일로 내려쓸 때, 체크포인트큐에 들어있는 가장 아래쪽의 체크포인트SCN을 컨트롤파일에 내려쓴다.
컨트롤파일에는 로그시퀀스번호 몇번에 SCN이 몇번부터 몇번까지 기록되었는지 그 정보가 들어있다.

● SCN
SCN은 두가지 종류가 있다.
  - System Commit Number : wrap + base 이렇게 두가지로 구성되어 있음. 커밋을 날릴 때마다 순차적으로 번호가 부여된다.
  - System Change Number : wrap + base + sequence 이렇게 세가지로 구성되어 있음.

● Checkpoint SCN
로그스위치가 발생하여 다음 리두로그파일로 LGWR이 작업할 때, 바로 이전 리두로그파일의 가장 마지막 SCN을 부르는 용어.

● LSN(Log Sequence Number)
우리가 책에서 어떤 내용을 찾으려면 페이지를 찾아가듯이, 오라클은 리두로그파일 자체에 번호를 붙였는데 책으로 말하면 책 페이지 번호와 같은 것이다. 이를 로그시퀀스번호라고 한다.

● MTTR(Mean Time To Recovery)
복구하는데 드는 시간을 뜻함.

DBWR이 자주 내려쓸수록 DB전체 속도(성능)가 안좋아지지만, 복구하는데 드는 시간은 짧다.(안정성이 좋다.)
반대로 자주 안내려쓰면 속도(성능)가 좋지만, 복구하는데 드는 시간은 많이 든다.(불안정하다.)

MTTR을 100주는게 500주는 것보다 더 자주 내려쓴다.

---

◆ 리두로그파일 다중화

보통 일반적으로 그룹 3개에 각 그룹당 멤버 2개씩으로 다중화를 해준다.
리두로그파일은 우리 삶에서 보험과 같다. 파일에 문제가 생기면 로그를 보고 복구를 해야 하는데 로그를 잘못 만들어 놓으면 복구가 불가능한 상황이 생길 수 있기 때문이다.

---

◆ 데이터파일 삭제 장애시 리두로그를 이용한 복구

1. A를 입력했을 시점의 데이터파일을 백업해놓은 백업본이 존재하고, 현재 데이터파일에는 C가 내려써진 상태이다.

2. 실수로 데이터파일이 삭제되는 장애가 일어났다.

3. 아래 절차에 따라 복구가 수행됨  

  ① 이전에 백업받아둔 데이터파일 백업본을 복원함.
  ② recover명령 날리면 가장 먼저 파라미터 파일에 있는 컨트롤파일 경로로 컨트롤파일을 찾아간 다음 컨트롤파일에 기록되어있는 체크포인트SCN을 봄. 가장 최근에 120까지 작업했다는 것을 알 수 있다.
  ③ 그다음 데이터파일로 찾아가보니 체크포인트SCN이 100번이다. 작업시점이 맞지 않는 것을 보고는 문제가 있다는 것을 알게 됨.
  ④  리두로그파일로 가서 101번 작업부터 가장 최근까지 작업한 120번까지의 로그를 가지고 복구를 시도함. 복구를 완료하면 데이터파일의 헤더에 체크포인트SCN을 120으로 바꿈.

4. C까지 복구 완료되었음을 확인할 수 있다.

위의 복구과정에서 100번부터 120번까지의 내용을 복구하는데, 중간에 110번 로그가 없다면 어떻게 될까? 결과는 복구가 되지 않는다. 복구를 할 때 100번부터 순차적으로 번호를 올리면서 복구를 해가는데 110번을 건너뛰고 120번까지 복구가 되지는 않는다. 즉, 로그는 중간에 끊기거나 하면 이후의 로그파일은 있으나 마나이다.
결론적으로 로그관리를 잘 해야 한다.

---

리두로그파일 하나를 칠판 하나라고 하고, 내가 첫번째 칠판에 필기를 한다고 가정하자. 마찬가지로 두번째 칠판, 세번째 칠판에도 필기를 한다고 하자. 그러나 아직도 더 쓸 내용이 있어서 첫번째 칠판에 이어서 써야 하는데, 칠판에 쓴 내용을 학생들이 다 적었다면 첫번째 칠판의 내용을 덮어써도 되지만 아직 다 못적었다면 어떻게 해야할까? 그때는 학생들이 내용을 다 받아적기 전까진 내용을 덮어쓰면 안될 것이다.

---

[문제] 20G 백업용 디스크 추가 후
          /data로 마운트시킨 후
          oracle계정 소유주로 만들고,
    /data/disk3/control01.ctl, redo01_a.log, redo02_a.log, redo03_a.log
           /disk4/control02.ctl, redo01_b.log, redo02_b.log, redo03_b.log
           /disk5/control03.ctl, redo01_c.log, redo02_c.log, redo03_c.log
    리두로그 그룹은 각 1, 2, 3으로 하고 크기는 10M로 하세요.

[문제] /data/temp/disk1/control01.ctl, redo01_a.log, redo02_a.log, redo03_a.log
                            disk2/control02.ctl, redo01_b.log, redo02_b.log, redo03_b.log
                            disk3/control03.ctl, redo01_c.log, redo02_c.log, redo03_c.log
    spfile을 이용하여 위와 같이 설정하세요.

[문제] /home/oracle/oradata/testdb/*.ctl, *.log
    pfile을 이용하여 위와 같이 이동시키세요.