백업&복구 7 - Noarchive log mode - 복구방법 2가지

No Archive log mode 장애복구
 : 이 모드는 log switch 일어나도 Archive log file 안만들고 Redo log 덮어쓴다.
 
 

1. DB가 안켜지면 모든 파일을 Restore (왜? SCN 번호 맞추기 위해)
   1일 이후 바뀐 데이터 다 날림 : 사실적으로 데이터 못 살림

2. 하나 포기하고 나머지만 살리자.
   포기한 파일 데이터는 못 살린다 : 사실적으로는 복구가 아님
→ 사실적으로 데이터를 못 살릴 확률이 높다.
Ex) 백업해둔 a.dbf의 SCN이 105번 이었다. Restore해보니 나머지 파일들은 108번
    Redo log의 106,107,108번을 가지고 와서 Recover 할수 있다.
 
 
★ 어느 모드(No Archive mode, Archive mode)인지가 중요한게 아니다.
   살려야 하는 데이터가 로그에 남아 있는가? 이것이 핵심!!
 
 
 
 
 
※ 고치는 (Recover) 명령어 3가지
 
① Recover database;
② Recover tablespace users;
③ Recover datafile '~~~';
 
 
철칙 : 고칠때 그 데이터 파일은 쓰고 있는 상태가 아니어야 한다.
       = select, update, insert, delete 일어나지 않아야 한다.
       고치고 있는 도중에 데이터가 바뀌면 안되기 때문이다.
       안쓰게 만드는방법 : offline, shutdown
 
 
① Recover database;
 : 데이터파일 전체 다 고쳐라 (데이터파일 전체가 사용안함 상태 = shutdown)
 : system, undo는 offline이 안된다.
 : mount 상태에서만 사용해야 한다.
 
 - nomount상태에서 Recover?
   : Recover 할때 먼저 컨트롤파일을 찾아간다.(컨트롤 파일은 mount상태) → 에러난다.
   : mount 나 open 상태에서 recover 명령 해야한다.
 - open 상태에서 recover database?
   : 파일을 쓰고 있어서 에러난다.
 
☆ 에러 만났을때 태도
  : 에러 메세지를 보면서 어느단계에서 어떤일이 일어났는가 차근히 살펴본다.
    '명령어 쳤을때 어느파일 어느곳에 가서 처리하려다가 어느 부분에서 문제가 생겼을까?'
    원리를 생각하며 log 메세지를 본다. → 쭉 보다보면 '이단계에서 이것 해야 하는데.. 못했네?' 그부분이 에러.
 
 
 
 
 
 
② Recover tablespace users;
 : users 테이블 스페이스는 무조건 offline 상태여야 한다.
 : system 테이블 스페이스는 offline 안되므로 shutdown 시켜야 한다.
 : offline되는 테이블스페이스는 offline 시켜두고 명령어를 쓰면된다.
 : mount 나 open 상태에서 다 쓸수있다.
 
 
 
 
 
 
③ Recover datafile '~~~';
 : 특정 데이터파일만 오프라인 시켜두고 작업
 
Ex)
TS_A : a01.dbf  ← 이것만 고장나면 이것만 오프라인 시켜두고 작업
       a02.dbf
          .
          .
       a100.dbf
 
- 설명 : TS_A 테이블스페이스 offline 시켜두고
         SQL> recover tablespace TS_A
         해도 되지만, 문제는 TS_A내의 나머지 DATAFILE들도 다 꺼진다.
         SQL> alter database datafile a01.dbf offline
         해놓고 고친다. 다른 DATAFILE들 쓸수 있다.
 
 
 
 

※ 특정 데이터파일만 포기하는 방법
  : 컨트롤파일에서 특정데이터파일 사용안함 처리함
SQL> alter database datafile '~~~' offline drop;
 
ex) 컨트롤파일 = 출석부
    → offline drop = 출석부에서 삭제시키는 방법
 
Recover datafile 치면 모든 데이터 파일 다 고친다. 문제는 '데이터파일이 어디에 있는지 어떻게 아는가?' 하는것이다.
컨트롤파일을 보고, 컨트롤파일에 있는 데이터파일만 고치는 것이다.
컨트롤파일에서 데이터파일을 지우면 실제파일이 있어도 고칠수 없다.
 
※ 기준 : 컨트롤파일 안에 DATAFILE정보가 없으면, 실제 파일이 있어도 고칠수 없다.




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

1. noarchivelog로 변경하기
SQL> startup mont;
SQL> alter database noarchivelog;
SQL> alter database open;
SQL> archive log list;
 
SQL> set line 200
SQL> col tablespace_name for a10
SQL> col file_name for a50
SQL> select tablespace_name, bytes/1024/1024 MB, file_name
  2  from dba_data_files;
 
 
2. 신규 테이블스페이스 생성
SQL> create tablespace test
  2  datafile '/home/oracle/oradata/testdb/test01.dbf' size 5M;
 
3. 백업
SQL> shutdown imediate;
SQL> !
$ cp /home/oracle/oradata/testdb/*.dbf /data/backup/close/
$ cp /home/oracle/oradata/testdb/*.log /data/backup/close/
$ cp /home/oracle/oradata/testdb/*.ctl /data/backup/close/
$ exit
 
SQL> startup
 
 
 
4. 장애발생시키기 1 : DATAFILE 삭제
SQL> !rm -fr /home/oracle/oradata/testdb/test01.dbf
SQL> shutdown abort;
SQL> startup
→ 해당파일 찾지 못해서 장애남.
 
5. restore 후 recover 시도
SQL> !cp /data/backup/close/test01.dbf /home/oracle/oradata/testdb/
SQL> recover database;  ← 현재 mount 상태
Media recovery complete.
 : 장애복구 완료. 복구하려는 데이터가 online redo log에 있기 때문이다.
 
 
 
 
6. 장애발생시키기 2
 : log switch 수동으로 발생시켜서 복구하려는 데이터를 Archive log에 있게 만들고 다시 시도
SQL> alter database open;
SQL> !rm -fr /home/oracle/oradata/testdb/test01.dbf
SQL> !ls /home/oracle/oradata/testdb/test01.dbf
SQL> alter system switch logfile;
SQL> /
SQL> /
도중에 DB가 강제로 shutdown abort 된다.
SQL> select status from v$instance; → DB shutdown 상태
SQL> exit
 
$ sqlplus / as sysdba;
SQL> startup
파일 없어서 에러남
 
7.  restore 후 recover 시도
SQL> !cp /data/backup/close/test01.dbf /home/oracle/oradata/testdb/
SQL> recover database;  ← 현재 mount 상태
Archive log 찾지만 없음 : log switch가 많이 일어나서 덮어 씌여 버림
Archive 파일 없어서 복구 실패
 
SQL> alter database open;
open 시도 했으나 실패함
 
 : 이유 - DB가 open 되기 위해서는 모든 DATAFILE과 control file, redo log file의 checkpoint SCN 정보가 같아야 하는데
          DATAFILE중 test01.dbf 파일 하나의 scn 정보가 다르기 때문.
 
 
8. 장애 해결하기
2가지 방법
① SCN 번호가 달라서 DB가 시작이 안되는 것이니까, SCN 번호를 같게 만들어 준다.
  : 기존 백업 받았던 모든파일(datafile, redo log file, control file)을 현재로 복원한다.
    → DB는 시작되지만 기존~현재 사이에 변경된 모든 데이터 손실 ::::: 복구가 아님
 
② 문제가 되는 test01.dbf만 포기 → 현실적으로 많이 사용함
  : test01.dbf의 데이터는 모두 손실되지만, 나머지 데이터는 살릴수 있다.
  : 장애가 난 데이터는 복구 할 수 없게 되어서 복구라고 보기엔 무리가 있다.
 
SQL> startup  → mount까지만 올라감
SQL> alter dtabase datafile '/home/oracle/oradata/testdb/test01.dbf' offline drop;
  → 컨트롤파일에있는 test01.dbf 파일의 정보를 지워 버린다.
     이경우 실제 DATAFILE이 존재 하더라도, 해당파일은 없는 것이 된다.
 
SQL> alter database open;
SQL> select status from v$instance;
이상없이 OPEN되었다.