행위

장애 유형별 복구 절차

DB CAFE

Dbcafe (토론 | 기여)님의 2024년 1월 22일 (월) 11:22 판 (→‎[파라미터 파일 장애 복구 절차] (19C + RAC + ASM 환경 ))
thumb_up 추천메뉴 바로가기

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

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

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

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

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

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

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

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

1.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;

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

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

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

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

1.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. 정상 기동 확인
    • 오류없이 정상 기동 확인

1.5 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. 정상 기동 확인
    • 오류없이 정상 기동 확인

1.6 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 확인

1.7 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 확인

1.8 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 정상 오픈 한다

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

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

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

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

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

  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=10876"