Oracle Database 장애 복구 방법

[1] Archive Mode 운영 중인 DB에서 특정 Table을 Drop 했을 경우.

[현상1] 개발자가 실수로 특정 Table을 Drop 을 했음.(단, 개발자가 장애시점을 알고있다고 가정한다.)

[현상2] Export 받은 데이터가 없음. DB를 shutdown 할 수 없는 상황.

[현상3] DBA는 2004년 07월05일 09:30분경에 개발자로부터mnt_state 테이블을 Drop했다고 연락받음.

[현상4] RAW Device 를 사용하지 않음. DB는 Archvie Mode, Hot Backup 데이터 존재. Archive log 존재.

[복구방법] 백업된 컨트롤 파일을 이용한 불완전 복구 방법을 선택.

DB에서 HRDEV로 백업 받은 데이터를 이관하여 DB를 생성 기동하여 해당 테이블만 복구.

[복구시점] select to_char(sysdate, ‘YYYY-MM-DD:HH24:MI:SS’) Time from dual

TIME : 2004-07-05:09:29:30

[1단계] DB – Object 정보 확인

1) 장애가 발생한 Table이 속한 Tablespace 확인.

SQL> select owner, segment_name, tablespace_name, bytes/1024/1024 from dba_segments where segment_name like ‘MNT%’;

à 장애 관련된 Tablespace 가 DATA_CDP 라는 것을 확인함.

2) 데이터를 복구할 Datafile 확인

SQL> select tablespace_name, file_name, bytes/1024/1024 from dba_data_files where tablespace_name in (‘SYSTEM’,’RBS’) or tablespace_name = ‘DATA_CDP’;

3) Redo log 정보 및 control file 정보 확인

SQL> select * from v$logfile;

SQL> select name from v$controlfile;

[2단계] 백업 받은 데이터 이관 (Media Recovery)

1)시스템 담당자에게 복구할 대상 통보 및 Recovery

– SYSTEM / RBS / DATA_CDP datafile 을 HRDEV DB로 Restore.

– /dbstorage0/hrms/* à /backup/oradata/ORCL/* (경로를 변경하여 Restore 한다.)

2) DB의 오라클 Home Directory를 HRDEV 서버로 copy

3) DB의 control file 정보 얻기

SQL> alter database backup controlfile to trace ;

à udump에서 trace 파일 확인 후 HRDEV 서버로 이관.

4) Trace 파일 이관 후 편집. ( file = recoverdb.trc)

CREATE CONTROLFILE REUSE DATABASE “DB” NORESETLOGS ARCHIVELOG

à
CREATE CONTROLFILE REUSE set DATABASE “ORCL” RESETLOGS ARCHIVELOG

[3단계] ORCL환경 정보 편집.

1) initORCL.ora 파일 변경.

– Controlfile 위치 변경.

/orastorage/DB/system/control01.ctl à /backup/oradata/ORCL/control01.ctl

– Arch Directory 변경

/ora_arch/arc à /backup/ORCL/arc

[4단계] Media Recovery 가 완료되면 Database Recovery를 수행한다.

1) control file 재생성을 통해 instance 를 기동 (Recoverdb.trc)

$sqlplus ‘/as sysdba’

SQL> @recoverdb.trc

SQL> select to_char(sysdate, ‘YYYY-MM-DD:HH24:MI:SS’) Time from dual

SQL> alter session set nls_date_format = ‘YYYY-MM-DD:HH24:MI:SS’ ;

TIME : 2004-07-05:09:29:30

2) Recovery 수행.

[5단계] Database reset logs를 이용한 Open

SQL> alter database open resetlogs;

[6단계] Temp tablespace 생성 및 user temporary tablespace 변경.

1)Temp Tablespace 생성.

SQL> create temporary tablespace TEMP2 tempfile ‘/backup/oradata/ORCL/temp2.dbf’ size 100m;

2) User Temporary Tablespace 변경.

SQL> spool alt_user_temp2.sql

SQL> select ‘alter user ‘||username|| ‘ temporary tablespace TEMP2;’ from dba_users;

SQL> spool off

SQL> @alt_user_temp2.sql

[7단계] Drop 된 테이블이 복구 되었는지 확인하고, 해당 Table만 DB로 복구한다.

SQL> select count(*) from MNT_STATE; à 건수 확인

à export 또는 CTAS 통해 DB로 데이터를 import 한다.

[8단계] Table Recovery 완료.

[2] NOARCHIVE LOG Mode Database 운영 중 Datafile 손실.

1. OFFLINE Full Backup 본이 있는 경우

[발생원인] 특정 Datafile 손실로 인하여 Database Crash.

[장애현상] – Database shutdown 이므로 DB 사용 불가.

Noarchvie Log Mode 이고, 지난 주 Full Backup 데이터가 존재,

이러한 경우는 Full backup 받은 시점으로만 Recovery 가 가능하므로 데이터 손실이 발생함.

[복구방법]

– Cold Backup 으로 Full Backup 받은 백업본으로 Restore 한다.

[1단계] 가장 최근의 Full Backup 본을 Restore 한다.

[2단계] Database Startup 한다.

$sqlplus ‘/as sysdba’

SQL> startup mount

SQL> alter database open;

[3단계] 확인

SQL> select h.tablespace_name, d.name, h.error from v$datafile d , v$datafile_header h

Where d.file# = h.file#;

à 만약된 Datafile 이 손실된 경우 ERROR 항목에 “FILE NOT FOUND” 라고 메시지가 나타남.

2. 손실된 Datafile 이 Temp Tablespace 에 속한 datafile 일 경우

[1단계] DB shutdown 한다.

[2단계] sysdba User connect 해서 mount 단계에서 해당 datafile offline drop 후 DB Open 한다.

$ sqlplus ‘/as sysdba’

SQL> startup mount

SQL> alter databae datafile ‘/data/ORADB/oradbdata/system/temp_01.dbf’ offline drop ;

SQL> alter database open;

[3단계] 손실된 datafile 의 해당 Tablespace 를 drop 한다.

$sqlplus ‘/as sysdba’

SQL> drop tablespace TEMP ;

[4단계] TEMP Tablespace 재생성한다.

$ sqlplus ‘/as sysdba’

SQL> create tablespace TEMP datafile ‘/data/ORADB/oradbdata/system/temp_01.dbf’ size 1000M;

3. Media 에러로 인한 임의 Directory 로의 DB 복구

[장애현상] Media Disk 에러로 인해 장애 디스크 /data/ORADB/oradbdata 접근이 불가됨 (DB shutdown)

No Archive 로그 모드이고, 해당 Datafile이 Corrupt 됨. 매주 일요일에 Offline Full Backup 실시.

장애 Directory에는 system 데이터 파일을 포함 control file 과 redo log file도 존재.

[복구방법] Full Backup 받은 데이터를 임시 디렉토리로 Restore

(/data/ORADB/oradbdata /* à /data2/ORADB/imsy/* 이전)

[1단계] DB shutdown 및 장애 유발.

$ \rm -rf /data/ORADB/oradbdata/* à /data/ORADB/oradbdata/* 데이터 파일 모두 삭제한다.

[2단계] 백업 데이터 Full Restore

à 단, /data/ORADB/oradbdata 쪽은 접근이 불가능하므로 해당 데이터 파일을 임시 디렉토리에 restore.

/data2/ORADB/imsy/* 로 내린다. (나머진 데이터파일은 그대로 Restore)

1)복구 작업이 정상적으로 완료된것이라고 가정.

2)컨트롤 파일 위치 변경.

$ vi init_ORADB.ora (파라미터 파일 수정)

control_files = (/data2/ORADB/imsy/cntrl01.dbf ,

/data2/ORADB/imsy/cntrl02.dbf ,

/data2/ORADB/imsy/cntrl03.dbf )

3) Mount 단계까지 STARTUP

4) 장애 데이터 파일 위치 변경 (반드시 script 로 만들어서 작업을 할 것을 권고)

SQL> @alt_datafile.sql

SQL> @alt_redo.sql

[3단계] Database Open

$ sqlplus ‘/as sysdba’

SQL> alter database open;

[4단계] 확인

[3] ARCHIVELOG Mode DB 에서 Datafile 손실에 따른 Database Recovery 방법

[장애현상] 2004/07/03 (토) 20:00경 Media Fail 로 인한 System Tablespace datafile corrupt 으로

DB shutdown 됨. 백업은 매주 화요일과 금요일 23:00부터 hot backup 실시.

[복구방법] System Tablespace 에 속한 파일의 장애이므로 mount 단계에서 복구시작.

화요일에 Hot Backup 본으로 백업 이후의 생성된 Archive log files로 복구.

[장애복구 시나리오 요약]

1단계> System Tablespace 의 datafile 손실로 DB 접근 불가 발생.

2단계> 손실된 Datafile 및 Raw device 정보 확인 및 Media 백업 복구 요청 및 시작

3단계> DB shutdown (shutdown immediate or abort 종료) DB shutdown 되었다면 다음 단계로.

4단계> Mount 단계까지 Startup

5단계> Datafile 및 Raw Device 복구가 완료되면, Recover 명령으로DB 복구

6단계> Database Open

<장애 복구 세부 시나리오>

[1단계] System Tablespace 의 Datafile 손실로 DB 접근 불가 발생.

[2단계] 손실된 Datafile 및 Raw Device 정보 확인 및 Media 복구 요청 및 복구 준비

– DBA 손실된 system Tablespace 의 Raw Device 를 알고 있다.

– Raw Device name= /dev/rtbl31_4G_001

cf) 손실된 datafile 확인 (mount 단계에서 가능)

à 장애를 일으킨 파일과 Tablespace 에는 FILE NOT FOUND 라는 Message 가 나타남.

[3단계] DB shutdown 확인

– DB shutdown 되었는지 확인 ( DB shutdown 되었다면 다음 단계로 Skip)

[4단계] mount 단계까지 Startup

$sqlplus ‘/as sysdba‘

SQL> startup mount

[5단계] > Datafile 및 Raw Device 복구가 완료되면, Recover 명령으로DB 복구

– Datafile 및 Raw Device 복구 완료가 되면, Recover 명령으로 DB 복구 시작.

– 적용될 로그 파일이 많을 경우 set autorecovery on 명령을 사용한다.

– 백업본 날짜는 7/2(금) 23:00 시 장애 시각은 7/3(토) 20:00 경 이므로 hot backup 시작부터

장애 발생 직전까지 생성한 Archive log file 을 적용한다. Datafile 복구가 완료되었다고 가정함.

[6단계] Database Open

SQL> alter database open;

– 확인

[4] Logical Database Recovery 방법(export/import)

[가정] logical recovery 를 수행하기 위한 전제 조건은

해당 object 에 대한 export dump 파일이 존재해야만 recovery 를 할수있다.

따라서 , 아래 사항은 export dump 파일이 있을 경우의 recovery 방법임.

1. 특정 USER의 Object 를 Full Recovery 해야 할 경우

[1단계] EUL 유저 Export 방법 (매일 밤 수행) : dump 파일이 있다고 가정.

$ exp userid=system/admin owner=eul rows=y file=exp_eul.dmp log=exp_eul.log

[2단계] EUL USER Full Import 수행.

$imp userid=system/admin fromuser=eul touser=eul file=exp_eul.dmp log=imp_eul.log

2. 특정 Table만 Recovery 할 경우

[1단계]특정 Table Export 방법 : 해당 dump 파일이 있다고 가정.

$exp userid=eul/eul rows=y file=exp_eul_user_table.dmp log=exp_eul_user_table.log

[2단계] 특정 Table 복구 하는 방법 : 해당 dump 파일이 있다고 가정.

$imp userid=eul/eul rows=y file=exp_eul_user_table.dmp log=imp_eul_user_table.log