2024년 1월 9일 6교시 시나리오 5. 백업 X + 리두 X + TBS 안 세그먼트 O

 

★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ 시나리오 5 ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★

시나리오 5 = 테이블스페이스의 백업본이 없고 + 테이블스페이스 안에 만들어놓은 세그먼트가 있는데 + 리두가 없을 경우

 

1. 실습용 테이블스페이스 만들기

create tablespace insa_tbs datafile '/u01/app/oracle/oradata/ora11g/insa_tbs01.dbf' size 10m;

insa_tbs 라는 테이블스페이스를 만들어주었다.

 

(QUESTION. 이거 어디서 해야 되는 거야?

SQLD 말고 퍼티에서 할 때는

/u01/app/oracle/oradata/ora11g 이 디렉토리에서 해야 되는 거야?

그냥 아무데서나 해도 상관없나?)

(ANSWER. 퍼티든 d 에서든 sys에서 하기만 하면 됨)

(와... 오늘이 2024년 1월 31일이고 복습하면서 보는데 진짜... 22일 전의 질문 수준 보소... 처참하다.

나 저 때만 해도 엄청 초보적이었구나. 근데 지금도 잘하는 느낌은 아니야... ㅋㅋㅋㅋㅋㅋㅋ

그냥 현쪽이랑 무스랑 만치에가 엄청 옛날에 도달한 수준에 나는 이제서야 겨우겨우 당도한 느낌?

걸어서도 아니고 기어서 아등바등 당도한 느낌.

그것도 있는 영혼 없는 영혼 다 끌어모아서 말이야... ㅠㅠ)

 

select tablespace_name, file_name from dba_data_files;
새로 만든 테이블스페이스 확인하기

 

 

select * from v$log;

커런트한 리두로그 그룹 체크

(커런트한 리두로그 그룹 1번, 시퀀스 번호 28, SCN 번호 1676758 부터 저장)

 

 

create table hr.new(id number) tablespace insa_tbs;

방금 만든 테이블스페이스 insa_tbs 안에 hr.new 라는 테이블 생성

 

insert into hr.new(id) values(1);

테이블 안에 인서트 작업해주기

 

commit;

커밋

 

select * from hr.new;

테이블스페이스 안에 만들어놓은 테이블 확인

 

alter system switch logfile;

/

/

 

인위적으로 로그스위치 발생시키기

이제 리두 안에는 저 테이블스페이스 안에 만들어진 테이블에 대한 정보가 없다.

 

select * from v$log;

리두로그 정보 확인

(커런트한 리두로그 그룹 2번, 시퀀스 번호 32, SCN 번호 1695539 부터 저장)

 

---

 

2. 장애 유발

 

! rm /u01/app/oracle/oradata/ora11g/insa_tbs01.dbf

백업 없고, 리두 없는 상태에서 데이터 파일 일부러 지워서 오류 유발시키기

 

insert into hr.new(id) values(2);

테이블스페이스를 없앴는데도 인서트가 되는 경우도 있다. 꼭 확인해보기

(인서트 되는 경우: 메모리 영역은 남아있는 경우, 메모리까지 없애버리면 더이상 인서트할 수 없다.)

 

commit;

얘도 아무런 문제가 없을 수 있다.

 

alter system switch logfile;

/

/

 

로그 스위치 여러번 발생시키기

 

여기까지 테이블스페이스 만들고 > 그 테이블스페이스 안에 테이블 만들고 > 테이블 안에 데이터 입력하고 조회까지 했는데 > 거기에 대한 리두 정보를 인위적으로 없앤 다음 > 테이블스페이스에 속한 데이터파일 지워서 장애 유발시키는 것까지 해놓은 상태이다.

 

3. 테이블스페이스 상태 확인해보고 온라인이면 오프라인 상태로 내리기

 

select name, status from v$datafile;

문제되는 데이터파일을 확인해보면: 온라인 상태이므로

 

 

alter database datafile '/u01/app/oracle/oradata/ora11g/insa_tbs01.dbf' offline drop;

오프라인으로 내리기

(이 insa_tbs 라는 테이블스페이스는 지금 백업본도 없고 리두도 없는 상태)

 

 

select name, status from v$datafile;

데이터파일 상태 확인: 오프라인으로 떨어져 있다.

 

4. 파일 껍데기 만들기

 

alter database create datafile '/u01/app/oracle/oradata/ora11g/insa_tbs01.dbf';
insa_tbs 데이터파일이 삭제된 상태이므로 아무것도 없는 빈 껍데기 파일 만들어주기

(에러 안나야 정상, 테이블스페이스가 오프라인 상태로 떨어져 있어야

파일 껍데기가 오류 없이 만들어짐)

(백업 없고 리두 없다는 사실을 모르는 상태에서 진행)

 

 

5. 만들어놓은 빈 껍데기에 리두를 부어넣어서 리커버리 시도

하지만 리두가 없으므로 리커버리가 될 리가 없다.

 

alter database recover datafile '/u01/app/oracle/oradata/ora11g/insa_tbs01.dbf';

리두가 없어서 리커버리 안되면 에러가 발생하는데 그게 정상적인 반응

 

(QUESTION. 근데 이 뒤부터 시나리오 돌아가는 꼴이 좀 이상한데...?

그래서 결론이 뭐야? 리두도 없고 백업도 없는 테이블스페이스가 깨져서 장애 발생하면

이 다음에 어떻게 해야 되는데? 그냥 앞의 시나리오에서처럼 데이터파일 오프라인으로 내리고

DB 연 다음에 테이블스페이스 삭제하면 되는 거야? ㅠㅠ)

(ANSWER. 테이블스페이스를 만들어서 복구 시도했는데 백업도 없고 리두도 없다는 사실을 뒤늦게서야 알아차림

> 복구 시도 실패 > 테이블스페이스를 지워버리는 수밖에 없다.)

 

 

drop tablespace insa_tbs including contents and datafiles;

테이블스페이스 및 그 안에 들어있는 세그먼트 지우기

에러 발생 (ORA-01156)

리커버리 시도 작업을 했기 때문에 프로세스가 엉킴 : 드롭할 수 없다.

이럴 때는 DB 를 내렸다 올릴 수밖에 없다.

 

 

SQL>

shutdown immediate

 

DB 내릴 때

startup force

해도 됨

startup force = shutdown abort + startup

shutdown abort 로 내렸다가 올리는 것

(shutdown abort 로 DB 를 내리므로 인스턴스 리커버리가 꼭 필요함

그리고 현장에서는 startup force 는 절대 쓰면 안된다!!!!!!!!!!!!!!!!!!!!!!!!!)

 

 

 

SQL>

startup

만약 위에서 무서워서 shutdown force 를 못쓰고 그냥 shutdown immediate를 썼다면:

여기서 DB 그냥 startup 으로 올리기

 

 

select name, status from v$datafile;

데이터파일 확인하기: 문제되는 파일이 리커버리 상태이므로 내렸다 올릴 수 있다.

 

 

drop tablespace insa_tbs including contents and datafiles;

insa_tbs 지우기

 

select name, status from v$datafile;

데이터파일이 잘 지워졌는지 확인하기