ex) 만약 shutdown immediate, abort했을 때 에러 발생할 경우
- 에러 코드 : ORA-24324, ORA-01041
▶ SYS connection이 끊어져서 발생한 것으로 추정
▶ 다시 SYS 재접속 후 startup 하면 정상적으로 DB가 올라간다.
■ DBA (Database Administrator) 주요 역할
- 항상 DB를 사용할 수 있도록 유지하는 것
- DBA는 시스템 장애를 최소화하기 위해 예방 조치를 취할 수 있어야 한다.
■ Failure 범주
- statement failure
- user process failure
- network failure : 장애 시 시스템 엔지니어에게 요청
- instance failure : SMON이 내부적으로 복구 작업 수행
- media failure : 장애 시 백업 본이 있어야 한다.
■ Backup 용어
- Whole database backup
1) 모든 data file, control file, redo log file, 초기 파라미터 파일(선택)
2) DB가 open 상태이거나 shutdown 되어있을 때 백업을 수행
- Partial database backup
1) 특정한 tablespace에 속한 데이터 파일 백업
2) archive log mode에서만 가능하다.
- 일관성 있는 backup
1) close backup, cold backup, offline backup 이라고도 불린다.
2) DB를 정상적인 종료 후에 백업을 수행
3) 모든 data file, control file, redo log file의 checkpoint 정보가 동일하다.
4) noarchive log mode, archive log mod 다 사용 가능하다.
- 일관성 없는 backup
1) open backup, hot backup, online backup 이라고도 불린다.
2) DB 운영 중에 백업을 수행할 수 있다.
3) archive log mode에서만 수행할 수 있다.
4) DB level, tablespace level
- Full backup : 선택한 File에 속한 모든 Data block 백업
- Incremental backup
1) 이전 Full backup이후에 변경된 block에 대해서만 백업
2) RMAN 백업을 수행해야 한다.
■ User Managed Backup 및 Recovery
- 운영체제 명령으로 파일 백업
- 운영체제 명령으로 백업 파일 Restore
- SQL 명령어로 Recovery수행
■ RMAN Backup 및 Recover
- RMAN 프로그램을 통해서 백업, 복구 작업
■ 백업 대상 파일
- 셋업
# Data file
- 기존 거만 남겨두고 나머지는 삭제 작업해주기
select name from v$datafile;
select name from v$tempfile;
# Control file
- 단일로 가야 좋다.
select name from v$controlfile;
alter system set control_files = '/u01/app/oracle/oradata/ORA19C/control01.ctl' scope = spfile;
# Redo log file (선택)
select member from v$logfile;
select * from v$log;
▶ 단일(1)로 되어있어야 복구 작업할 때 편리하다.
# 초기 파라미터 파일 (선택)
show parameter spfile
# DB mode
# DB 내렸다 올리기
- 백업 시작 전 시스템이 정상적으로 돌아가는지 확인하기 위해 한 것이다.(사전작업)
# noarch 백업 파일 생성
# 데이터 파일 다시 한번 확인
■ NO Archive Log Mode 백업
- 일관성 있는 백업(close, cold, offline backup)
- DB를 정상적으로 종료한 후 백업 수행(shutdown normal | transactional | immediate)
- Whole database backup : 모든 data file, control file, redo log file
- 현재 DB의 마지막 checkpoint 확인
▶ 저 scn 번호 이전에 해당하는 트랜잭션 작업들은 메모리에 디스크로 write가 되어있기 때문에 scn 번호 이후부터만 복구하면 된다.
select * from v$log;
▶ 위의 scn번호들은 거의 CURRENT한 redo log file 범주 안에 있다.
▶ 백업 전에 마지막 checkpoint 정보를 확인하는 게 좋다.
▶ SCN번호 이후에 변경 작업들은 CURRENT한 redo log file 안에 있다 생각하면 된다.
# 백업 수행
- 만약 모르고 shutdown abort할 경우 바로 startup 시키고 정상 종료 시켜야 한다.
▶ *.{} : 모든 파일을 복붙하고 싶은데 특정 확장자만 지정해서 copy하고 싶을 때 사용한다.
▶ 현장에선 데이터 파일 위치가 다 다르니 DB 내리기 전에 위치 먼저 확인하고 작업하는 게 좋다.
▶ 위의 checkpoint 번호와 다르다.
▶ checkpoint가 맞춰줬다.
<< HR session >>
# table 생성
create table hr.emp_temp(id number)
tablespace users;insert into hr.emp_temp(id)
values(1);
commit;▶ 현재 이 정보는 백업 파일 생성 이후에 작업한 것이기 때문에 commit 들어와서 redo에 current한 그룹에 저장이 된다.
<< SYS session >>
select * from v$log▶ create, DML 작업 시 current 그룹 안에 저장이 되기 때문에 복구가 가능하다.
▶ 만약 아무 작업 안 하고 시간이 지나서 scn 번호 확인해 봤는데 번호가 다르면 redo log file에 current한 그룹 안에 공간이 다 차서 log switch가 되어서 scn 번호가 바뀐 것이다.(그렇게 되면 완전 복구 불가능)
# 자주 쓰는 SQL문
select f.file_name
from dba_extents e, dba_data_files f
where e.file_id = f.file_id
and e.segment_name = 'EMP_TEMP'
and e.owner = 'HR';
<< 시나리오 1 >> 특정한 데이터 파일 손상(백업 이후에 redo log file에 정보가 있을 경우)
# 장애 발생
▶ DB내린 후 일부러 데이터 파일 삭제 후 DB 띄울 때 mount 단계에서 control file 안에 데이터 파일을 물리적으로 지워버렸기 때문에 mount 단계에서 에러가 발생한다.
# 현재 어느 단계인지 확인
# 복구 수행해야 할 data file 정보 확인
select * from v$recover_file;
select file#, name, status from v$datafile;
▶ users01이 온라인이라고 떠도 복구 시 에러가 발생하기 때문에 offline으로 변경해줘야 정상적으로 복구가 된다.
# noarchive log mod에서는 특정한 데이터 파일을 offline 모드로 수행할 경우 꼭 offline drop으로 해야 한다.
▶ 에러 발생 시 파일 번호를 적어줘야 한다.
select file#, name, status from v$datafile;
▶ 이제 DB를 정상을 띄울 수 있다.
# DB 띄우기 (alter database open;)
# 정상 작동하는지 확인
▶ 백업 이후 변경 작업을 한 거에 대해서는 에러 발생
# 복구 작업 실행
- 가장 최근에 받은 백업 본을 이용해서 restore
# 백업 이후에 변경된 정보를 가지고 복구 작업 (recover)
▶ Media recovery complete가 뜨면 복구가 제대로 된 것이다.
# offline으로 되어있는 데이터 파일을 online으로 변경 작업
▶ 다시 조회하면 복구가 되어서 살아났다.
▶ redo만 살아있으면 완전 복구가 가능하다.
※ 모든 시나리오 하기 전에 DB 내렸다 올리기
▶ 어차피 이전으로 돌아가는 것이니 abort로 비정상적인 종료해도 상관없다.
<< 시나리오 2 >> 특정한 데이터 파일이 손상 (백업 이후에 redo 정보가 없을 경우)
# 시작 전 미리 확인하기
select name, open_mode, log_mode,checkpoint_change# from v$database;
select name, checkpoint_change#, status from v$datafile;
select * from v$log;
<< SYS session >>
# 샘플 table 생성
create table hr.emp_temp(id number)
tablespace users;
insert into hr.emp_temp(id)
values(1);
commit;
# 장애 유발 대상 파일 확인
select f.file_name
from dba_extents e, dba_data_files f
where e.file_id = f.file_id
and e.segment_name = 'EMP_TEMP'
and e.owner = 'HR';
▶ 샘플 table의 대한 정보는 redo 안에 current한 그룹 안에 저장이 되어있다.
# 인위적으로 log switch 발생시키기
select * from v$log;
▶ 계속 log switch가 발생하다 보니 overwrite가 되어버렸다.
# 장애 발생시키기
▶ 대상 파일을 삭제한 것이다.
# DB 띄우기
▶ open 시점에 에러가 발생한다.
# 장애가 난 파일들 확인
select * from v$recover_file;
# 장애 난 파일 STATUS 상태 확인
select file#, name, status from v$datafile;
# offline으로 떨어뜨려놓는 작업 수행
# DB 현재 상태 확인
# DB를 open 상태로 변경
# 복구 수행해야 할 백업 데이터 파일 찾아서 restore(cp)
# 백업 이후에 redo 정보 작용
▶ 오류 원인 : 마지막 백업 이후에 redo 정보를 이용해서 복구 작업을 시도하려고 하는데 이미 redo log는 log switch가 발생해서 변경된 이력정보들이 전부 없어져있다.
※ noarchive log mod의 단점 : log switch가 발생하면 redo 정보가 overwrite가 되어버리기 때문에 완전복구를 할 수 없다.
▶AUTO를 입력해도 redo가 없으면 복구가 되지 않는다.
# noarchive log mode에서 완전 복구를 할 수 없으면 control file, data file, redo log file 전부를 restore 해야 한다.
- 즉, 마지막 백업 시점으로 DB를 복구해야 한다. (비정상적인 복구)
