행위

장애 유형별 복구 절차

DB CAFE

thumb_up 추천메뉴 바로가기

목차

1 DATABASE 장애 복구 절차[편집]

1.1 Spfile Restore[편집]

  1. 장애 유형별 복구 절차#[복구절차] spfile restore 참조

1.2 Control File Restore[편집]

  1. 임시 복구된 spfile을 이용하여 db를 nomount로 기동한다. 
    SQL> startup nomount
  2. 백업된 control file을 확인 
    RMAN> list copy of controlfile
  3. control file을 restore 한다 
    RMAN> restore controlfile from '/ZFS/BACkup/../control_backup.ctl
  4. db를 mount 한다. 
    SQL> alter database mount

1.3 Database Restore[편집]

  1. 백업된 database 확인 
    RMAN> list copy of database;
  2. database를 restore 한다 
    RMAN> restore database;

1.4 Archive Log Restore[편집]

  1. 백업된 archive log 및 sequence를 확인한다. 
    RMAN> list backup of archivelog all by file;
  2. 백업된 모든 archive log를 restore 한다. 
    RMAN> restore archivelog from sequence <LOG SEQ> thread <THREAD#>;
    • <THREAD#>은 db node 번호 , <LOG SEQ>는 thread 별 “SEQ”가 가장 낮은값

1.5 Database Recover[편집]

  1. database 를 복구한다.(장애 발생 직전까지 불완전 복구) 
    SQL> recover database using backup controlfile until cancel;
    • "AUTO" 입력
  2. database를 resetlog 모드로 OPEN 한다. 
    SQL> alter database open resetlogs;
  3. spfile을 재생성한다. 
    SQL> create spfile='+DATA' from memory

2 장애 유형별 복구 절차[편집]

2.1 파라미터 파일 손상,유실 - 디비 기동중 일때[편집]

  1. 장애발생 확인
    • 파라미터 파일이 손상되어 변경정보를 파라미터 파일에 저장 할수 없다.
  2. 파일 복구 실시
    • 메모리 설정값을 이용하여 파라미터 파일을 재생서우한다
  3. 정상 확인
    • 오류 없이 파라미터가 변경되는지 확인

2.2 파라미터 파일 손상,유실 - 디비 중지 상태 일때[편집]

  1. 장애발생 확인
    • 파라미터 파일이 손상되어 DB를 기동 할수 없다.
  2. 파일 복구 실시
    • 백업된 파일에서 파라미터 파일을 찾는다.
    • 백업 piece로 부터 파라미터파일을 restore 한다.
  3. DB 기동
    • DB를 OPEN(force) 한다
  4. 정상 확인
    • 오류 없이 정상 기동 하는지 확인

2.3 [파라미터 파일 장애 - 복구 절차] (19C + RAC + ASM 환경 )[편집]

2.3.1 [복구절차] 장애발생[편집]

  1. 파라미터 파일이 손상되어 DB 기동 불가 확인.

2.3.2 [복구절차] spfile restore[편집]

  1. 백업 영역에서 파라미터파일을 임시영역에 restore 한다 
    RMAN> list backup of spfile
  2. Log directory 에서 Db ID를 검색 한다. 
    cat *.trc|grep 'Db ID='
    cat *.log|grep 'DBID'
  3. 백업파일에서 Db ID 를 식별한다. 
    ls -al /ZFS/BACKUP/DATA_<DB_NAME>_01/DCH1
    ==> data_D-DB_TESTI-123456789_TS-TEST......
    ==> dbid는 123456789 이다
  4. DBID를 설정하고 db를 nomount 상태로 기동한다. 
    RMAN> set dbid 123456789
    RMAN> startup force nomount
  5. 임시영역으로 spfile을 restore 한다 
    RMAN> restore spfile to '/oracle/app/product/19.3.0/dbs/spfile/<ORACLE_SID>.ora'  from '/ZFS/BACKUP/DATA_<DB_NAME>_##/<channel#>/<BACKUPFILE>'
    RMAN> shutdown immediate;

2.3.3 [복구절차] 파라미터 파일이용 DB기동 후 spfile 재생성[편집]

  1. 임시영역의 파라미터 파일을 이용하여 DB를 기동,spfile을 재생성한다. 
    SQL> startup
    SQL> create spfile='+DATA' from memory;
    SQL> shutdown immediate;

2.3.4 [복구절차] DB 정상 기동[편집]

  1. DB를 정상 기동한다. 
    $ srvctl start database -d <DB_NAME>

2.4 control file 손상,유실 - 일부분[편집]

  1. 장애 발생 확인
    • 3중화된 control file 중 하나가 손상되 인스턴스가 비정상 상태임.
  2. DB 종료
    control file 복구를 위해 DB 종료
  3. Control file 복사
    • 파라미터 파일에서 control file 이름 확인
    • nomount 상태로 DB 기동
    • rman 명령어로 정상 control file로 부터 새로운 control file을 복사한다.
  4. DB 파라미터 변경
    • 신규 생성된 control file 이름을 파라미터 파일에 적용한다(ASM)
  5. DB 기동
    • DB(force)를 오픈한다.
  6. 정상 기동 확인
    • 오류없이 정상 기동 확인

2.5 [Control File 장애 , 일부 ] 복구 절차[편집]

2.5.1 [복구 절차] 장애 발생[편집]

  1. 3중화된 Control file 중 하나가 손상되어 DB기동 불가 확인

2.5.2 [복구 절차] DB기동(nomount)[편집]

  1. DB를 nomount 상태로 기동한다. 
    SQL> startup nomount

2.5.3 [복구 절차] Control File 복제[편집]

  1. RMAN을 이용 정상 Control File을 신규 Control File 로 복제한다.
    • asmcmd 명령을 이용하여 정상 Control File의 파일명을 찾는다.
  2. 복제시 output 파일명을 별도로 기록해 둔다. 
    RMAN> restore controlfile to '+ARCH' from '+DATA/<DB_UNIQUENAME>/CONTROLFILE/current.123.123456789'

2.5.4 [복구 절차] DB기동[편집]

  1. 복제된 Control File을 파라미터 파일에 적용한다.
  2. 정상 Control File명과 별도로 기록한 Control File을 파라미터 파일에 적용한다. 
    SQL> alter system set control_files='+DATA/<DB_UNIQUENAME>/CONTROLFILE/current.123.123456789','+DATA/<DB_UNIQUENAME>/CONTROLFILE/current.456.123456789','+ARCH/<DB_UNIQUENAME>/CONTROLFILE/current.789.123456789' scope=spfile;
  3. DB를 force option 으로 기동한다. 
    SQL> startup force;

2.6 control file 손상,유실 - 전체[편집]

  1. 장애 발생 확인
    • 3중화된 control file 전체가 손상되 인스턴스가 비정상 상태임.
  2. DB 종료
    control file 복구를 위해 DB 종료
  3. Control file 복사
    • nomount 상태로 DB 기동
    • 백업된 control file 을 확인.
    • control file을 restore 한다.
  4. 블완전 복구 실시
    • DB를 mount 한다
    • 백업본으로 부터 데이터 파일을 restore 한다.
    • control file을 이용하여 블완전 복구를 수행한다.
    recover database using backup controlfile
  5. DB 기동
    • DB를 OPEN(resetlogs) 한다.
  6. 정상 기동 확인
    • 오류없이 정상 기동 확인

2.7 [Control File 장애 , 전체] 복구 절차[편집]

2.7.1 [복구 절차] 장애 발생[편집]

  1. 3중화된 Control file 전체가 손상되어 DB기동 불가 확인

2.7.2 [복구 절차] DB기동(nomount)[편집]

  1. DB를 nomount 상태로 기동한다. 
    startup nomount

2.7.3 [복구 절차] Control Restore(임시)[편집]

  1. 백업 영역에서 Control File 을 임시로 restore 한다 
    RMAN> list copy of controlfile;
    RMAN> restore controlfile from '/ZFS/BACKUP/DATA_<DB_NAME>_##/controlf_backup.ctl

2.7.4 [복구 절차] Control File 스크립트 추출[편집]

  1. 임시 Control File 로 부터 재생성 스크립트를 추출 한다. 
    SQL> startup mount;
    SQL> alter database backup control file to trace as '/oracle/noreset_crctl.sql'
    alter system set cluster_database=false scope=spfile;
    shutdown immediate;
  2. Control File 생성 스크립트를 생성한다. 
    $ vi /oracle/noreset_ctctl.sql
    • "Set #2. RESETLOGS case" 이하 line을 모두 지우고 파일을 저장한다.

2.7.5 [복구 절차] Control File 생성[편집]

  1. Control File 생성 스크립트를 실행한다. 
    SQL> @/oracle/noreset_ctcrl.sql
  2. Control File 생성되고 DB가 기동 된다 
    select name,open_mode from v$database;

2.7.6 [복구 절차] DB기동[편집]

  1. DB를 정상 기동한다. 
    SQL> alter system set cluster_database=true scope=spfile;
    SQL> shutdown immediate;
    $ srvctl start database -d <DB_NAME>

2.8 Redo log group 손상,유실 - ACTIVE 상태[편집]

  1. 장애발생
    • Active 상태의 redo log group 멤버 전체 파일이 손상되어 log file switch 불가 , 아카이브 hang 발생후 비정상 종료 됨
  2. DB 마운트
    • 복구를 위해 DB를 마운트 한다.
    • 장애가 발생한 redo log group 번호를 alert로그 파일에서 확인 한다.
  3. redo log file 초기화
    • 장애가 발생한 redo log group을 초기화 한다.
    alter database clear unarchived logfile group #
  4. DB 기동
    • DB를 OPEN 한다.
  5. 정상 확인
    • log file 정상 switch 확인

2.9 [Redo Log 파일 장애 ,Active 상태 - 복구 절차 ] (19C + RAC + ASM 환경 )[편집]

2.9.1 [복구절차] 장애 발생[편집]

  1. Active 한 상태의 Redo Log 그룹 전체파일이 손상되어 , DB 기동 불가

2.9.2 [복구절차] DB 기동(Mount)[편집]

  1. DB를 mount 한다 
    SQL> startup mount

2.9.3 [복구절차] Redo Log 복구[편집]

  1. 장애가 발생한 Redo Group을 Drop 한다. 
    SQL> alter database drop logfile group #
  2. DB를 open 한다 
    SQL> alter database open;
  3. Drop된 Redo Group을 생성한다. 
    SQL> alter database add logfile thread # group # ('+DATA','+ARCH') size **MB;

2.10 Redo log group 손상,유실 - CURRENT 상태[편집]

  1. 장애발생
    • CURRENT 상태의 redo log group 전체 파일이 손상되어 log file switch 불가 , 비정상 종료 됨
  2. DB 마운트/데이터파일 restore
    • 복구를 위해 DB를 마운트 한다.
    • 백업파일에서 데이터파일과 control file을 restore 한다.
  3. 블완전 복구
    • 불완전 복구를 수행한다
    • 손상된 redo log group 의 종료전 sequence 이전까지 블완전 복구를 수행한다.
    recover database until cancel
  4. DB 기동
    • DB를 OPEN (resetlogs)한다.
  5. 정상 확인
    • log file 정상 switch 확인

2.11 [Redo log 파일 장애 , CURRENT 상태 - 복구절차] (19C + RAC + ASM 환경 )[편집]

2.11.1 [복구절차] 장애 발생[편집]

  1. Current 상태의 Redo Log 그룹 전체파일이 손상되ㅓ , DB 기동불가 확인

2.11.2 [복구절차] DB 기동(mount)[편집]

  1. DB를 mount 한다 
    SQL> startup mount

2.11.3 [복구절차] DATABASE Restore[편집]

  1. 백업된 DATABASE를 확인 한다. 
    RMAN> list copy of database;
  2. DATABASE를 restore 한다 
    RMAN> restore database;

2.11.4 [복구절차] Archivelog Restore[편집]

  1. 백업된 archivelog 및 Sequence를 확인한다. 
    RMAN> list backup of archivelog all by file;
  2. 백업된 모든 archivelog를 restore 한다 
    RMAN> restore archivelog from sequence <LOGSEQ> thread <THREAD#>;
    • <THREAD#>는 db node 번호 , <LOG_SEQ>는 thread 별 “Seq”가 가장 낮은값

2.11.5 [복구절차] DATABASE Recover[편집]

  1. database를 복구 한다.(장애 발생 직전까지 불완전 복구 실시) 
    SQL> recover database until cancel;
    • "AUTO" 입력
  2. database를 resetlog 모드로 OPEN 한다 
    SQL> alter database open resetlogs;

2.12 UNDO Tablespace 손상,유실[편집]

  1. 장애발생
    • 롤백세그먼트 사용중인 UNDO Tablespace에 손상이 발생하여 UNDO Tablespace사용이 불가하고 신규 Tablespace 생성중 오류 발생
  2. 임시 파라미터 적용
    복구를 위해 임시 파라미터를 적용
  3. UNDO Tablespace 강제로 offline 시킴 
    alter database datafile [...] offline drop
  4. UNDO Tablespace 삭제
    • 기존 UNDO Tablespace를 drop 한다
    drop tablespace [undotbs01] include contents and datafiles
  5. DB 정상 오픈
    • 복구를 위해 임시 적용된 파라미터를 원복한다
    • DB 정상 오픈 한다

2.13 데이터파일 손상,유실[편집]

  1. 장애발생
    데이터파일 손상으로 데이타 읽기,쓰기 오류 발생
  2. 데이터파일 오프라인
    • alert log에서 장애파일 확인
    • 장애가 발생한 데이터파일 오프라인 처리
  3. 데이터파일 복구
    • 백업본에서 장애가 발생한 데이터파일 restore
    • 데이터파일 복구(media recovery)한다
  4. 정상 확인
    • 읽기,쓰기가 정상인지 확인한다

2.14 [데이터파일 삭제,손상 ] 복구 절차[편집]

2.14.1 [복구절차] 장애 발생[편집]

  1. 특정 데이터 파일이 삭제되어 DATA 조회 불가 확인

2.14.2 [복구절차] DATA FILE Restore[편집]

  1. 장애가 발생한 데이터 파일의 file id를 식별한다.
    1. 오류 메시지 또는 alert log 에서 확인
    2. RMAN> report schema 로 확인
  2. 장애가 발생한 datafile의 백업을 확인한다. 
    RMAN> list copy of datafile 111
  3. 백업 영역에서 DATA FILE을 restore 한다. 
    RMAN> restore datafile 111

2.14.3 [복구절차] Archive Log Restore[편집]

  1. DATA FILE 복구를 위한 Archive Log 를 확인한다. 
    RMAN> list copy of datafile 111
    • 복구시점은 "Ckp Time"
  2. DATA FILE 복구를 위한 Archive Log 파일을 restore 한다. 
    RMAN> restore archivelog from time='yyyy-mm-dd hh24miss'

2.14.4 [복구절차] DATA FILE Recover[편집]

  1. DATA FILE 을 Recovery 한다. 
    SQL> recover datafile 111

2.14.5 [복구절차] DATA FILE ONLINE[편집]

  1. 복구된 DATA FILE을 ONLINE 한다. 
    SQL> alter database datafile 111 online;

2.15 사용자 실수에 의한 테이블 삭제 - Flashback[편집]

  1. 장애발생
    • 사용자 실수로 테이블 삭제, 테이블 조회 불가한 상태, flashback은 가능한 상태
  2. 테이블 복구 
    flashback table [테이블명] to before drop
  3. 정상확인
    삭제된 테이블 정상 조회 확인

2.16 사용자 실수에 의한 테이블 삭제 - 복구 환경[편집]

  1. 장애발생
    • 사용자 실수로 테이블 삭제, 테이블 조회 불가한 상태, flashback은 불가능한 상태
  2. 복구DB 환경구성
    • 백업서버등 임시환경에서 복구DB 구성
    • 운영DB spfile,control file,아카이브파일을 복구DB로 전송한다
    • 벡업본으로 데이터파일을 restore 한다
  3. 테이블 복구
    • 테이블 삭제 이전 시점까지 복구 수행
    recover database until time ...
    • 복구된 테이블을 운영 DB로 이관한다
  4. 정상확인
    삭제된 테이블 정상 조회 확인
원본 주소 "http://dbcafe.co.kr/wiki/index.php?title=장애_유형별_복구_절차&oldid=10896"