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%’;

OWNER SEGMENT_NAME TABLESPACE BYTES/1024/1024

———- ——————– ———- —————

HRMS MNT_PLAN DATA_CDP .125

HRMS MNT_STATE DATA_CDP .0625

à 장애 관련된 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’;

TABLESPACE_NAME FILE_NAME BYTES/1024/1024

—————- ————————– —————

DATA_CDP /dbstorage0/hrms/data_cdp01.dbf 200

SYSTEM /orastorage/DB/system01.dbf 1000

RBS /dbstorage0/hrms/rbs01.dbf 2048

RBS /dbstorage0/hrms/rbs02.dbf 1024

TEMP /orastorage/DB/temp01.dbf 384

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

SQL> select * from v$logfile;

/orastorage/DB/redo03.log

/orastorage/DB/redo02.log

/orastorage/DB/redo01.log

SQL> select name from v$controlfile;

/orastorage/DB/system/control01.ctl

/dbstorage0/hrms/system/control02.ctl

/dbindex0/hrms/system/control03.ctl

[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

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE set DATABASE “ORCL” RESETLOGS ARCHIVELOG

MAXLOGFILES 5

MAXLOGMEMBERS 3

MAXDATAFILES 2725

MAXINSTANCES 1

MAXLOGHISTORY 8186

LOGFILE

GROUP 1 ‘/backup/oradata/ORCL/redo01.log’ SIZE 100M,

GROUP 2 ‘/backup/oradata/ORCL/redo02.log’ SIZE 100M,

GROUP 3 ‘/backup/oradata/ORCL/redo03.log’ SIZE 100M

DATAFILE

‘/backup/oradata/ORCL/system01.dbf ‘,

‘ /backup/oradata/ORCL/rbs01.dbf ‘,

‘ /backup/oradata/ORCL/rbs02.dbf ‘,

‘/backup/oradata/ORCL/data_cdp01.dbf ‘

CHARACTER SET KO16KSC5601 ;

[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

Total System Global Area 1263498576 bytes

Fixed Size 738640 bytes

Variable Size 1207959552 bytes

Database Buffers 33554432 bytes

Redo Buffers 21245952 bytes

Control file Created .

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 수행.

SQL> alter database mount;

SQL> set autorecovery on

SQL> Recover database until time ‘2004-07-05:09:29:30’ using backup controlfile;

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

AUTO
à AUTO를 선택한다.

[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 가 가능하므로 데이터 손실이 발생함.

ORA-01157 에러가 발생한다. 다음과 같은 에러메시지가 나타난다.

ORA-01157 : cannot identify data file 4 – file not found

ORA-01110 : data file 4 : ‘/data/ORADB/oradbdata/system/temp_01.dbf’

[복구방법]

– 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#;

TABLESPACE_NAME NAME ERROR

————— —————————————- ———-

SYSTEM /data/ORADB/oradbdata/system01.dbf

SYSTEM /data/ORADB/oradbdata/system02.dbf

SYSTEM /data/ORADB/oradbdata/system03.dbf

SYSTEM /data/ORADB/oradbdata/system04.dbf

SYSTEM /data/ORADB/oradbdata/system05.dbf

CTXD /data/ORADB/oradbdata/ctxd01.dbf

OWAPUB /data/ORADB/oradbdata/owad01.dbf

ABMD /data/ORADB/oradbdata/abmd01.dbf

ABMX /data/ORADB/oradbdata/abmx01.dbf

…….

à 만약된 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 및 장애 유발.

$sqlplus ‘/as sysdba’

SQL> col name format a45

SQL> select name, status from v$datafile;
NAME STATUS

————————————– ——-

/data/ORADB/oradbdata/system01.dbf SYSTEM

/data/ORADB/oradbdata/alrd01.dbf ONLINE

/data/ORADB/oradbdata/alrx01.dbf ONLINE

/data/ORADB/oradbdata/amsd01.dbf ONLINE

/data/ORADB/oradbdata/amsx01.dbf ONLINE

SQL> col member format a30

SQL> select member from v$logfile;

/data/ORADB/oradbdata/log01a.ora

/data/ORADB/oradbdata/log02a.ora

/data/ORADB/oradbdata/log03a.ora

SQL> col NAME format a40

SQL> select name from v$controlfile;

/data/ORADB/oradbdata/cntrl01.dbf

/data/ORADB/oradbdata/cntrl02.dbf

/data/ORADB/oradbdata/cntrl03.dbf

$ \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

Total System Global Area 1263498576 bytes

Fixed Size 738640 bytes

Variable Size 1207959552 bytes

Database Buffers 33554432 bytes

Redo Buffers 21245952 bytes

Database Mounted.

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

SQL> @alt_datafile.sql

SQL> @alt_redo.sql

$ vi alt_datafile.sql

alter database rename file ‘/data/ORADB/oradbdata/system01.dbf’ to ‘/data2/ORADB/imsy/system01.dbf’ ;

alter database rename file ‘/data/ORADB/oradbdata/alrd01.dbf’ to /data2/ORADB/imsy/alrd01.dbf’;

alter database rename file ‘/data/ORADB/oradbdata/alrx01.dbf’ to /data2/ORADB/imsy/alrx01.dbf’ ;

alter database rename file ‘/data/ORADB/oradbdata/amsd01.dbf’ to /data2/ORADB/imsy/amsd01.dbf’ ;

alter database rename file ‘/data/ORADB/oradbdata/amsx01.dbf’ to /data2/ORADB/imsy/amsx01.dbf’ ;

$ vi alt_redo.sql

alter database drop logfile ‘/data/ORADB/oradbdata/log01a.ora’

alter database drop logfile ‘/data/ORADB/oradbdata/log02a.ora’

alter database drop logfile ‘/data/ORADB/oradbdata/log03a.ora’

alter database add logfile ‘/data2/ORADB/imsy/log01a.ora’ size 500M

alter database add logfile ‘/data2/ORADB/imsy/log02.ora’ size 500M

alter database add logfile ‘/data2/ORADB/imsy/log03.ora’ size 500M

[3단계] Database Open

$ sqlplus ‘/as sysdba’

SQL> alter database open;

[4단계] 확인

$sqlplus /as sysdba

SQL> col NAME format a40

SQL> select name, status from v$datafile;

NAME STATUS

————————————– ——-

/data2/ORADB/imsy/system01.dbf SYSTEM

/data2/ORADB/imsy/alrd01.dbf ONLINE

/data2/ORADB/imsy/alrx01.dbf ONLINE

/data2/ORADB/imsy/amsd01.dbf ONLINE

/data2/ORADB/imsy/amsx01.dbf ONLINE

SQL> col member format a30

SQL> select member from v$logfile;

/data2/ORADB/imsy/log01a.ora

/data2/ORADB/imsy/log02a.ora

/data2/ORADB/imsy/log03a.ora

SQL> col NAME format a40

SQL> select name from v$controlfile;

/data2/ORADB/imsy/cntrl01.dbf

/data2/ORADB/imsy/cntrl02.dbf

/data2/ORADB/imsy/cntrl03.dbf

[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 단계에서 가능)

$sqlplus ‘/as sysdba’

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

Where d.file#=h.file#;

TABLESPACE_NAME NAME ERROR

————— —————————————- ———-

SYSTEM /dev/rtbl31_4G_001 FILE NOT FOUND

UNDO_KTFINFO /dev/rundo101

TOOLS /dev/rtoolslv

USERS /dev/ruserslv

UNDO_KTFINFO /dev/rundo102

UNDO_INFORDS /dev/rundo202

UNDO_KTFINFO /dev/rundo103

UNDO_INFORDS /dev/rundo203

MINING_01 /dev/rtbl10_4G_008

MINING_01 /dev/rtbl10_4G_009

MINING_01 /dev/rtbl10_4G_010

MINING_01 /dev/rtbl10_4G_011

MINING_01 /dev/rtbl10_4G_012

MINING_01 /dev/rtbl10_4G_013


à 장애를 일으킨 파일과 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 복구가 완료되었다고 가정함.

à 현재 mount 단계

SQL> set autorecovery on

SQL> recover datafile /dev/rtbl31_4G_001′ ;

..

.

로그가 적용되었습니다.

메체복구가 완료되었습니다.

[6단계] Database Open

SQL> alter database open;

– 확인

$sqlplus ‘/as sysdba’

SQL> col tablespace_name format a15

SQL> col name format a40

SQL> col error format a10

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

Where d.file#=h.file#;

TABLESPACE_NAME NAME ERROR

————— —————————————- ———-

SYSTEM /dev/rtbl31_4G_001

UNDO_KTFINFO /dev/rundo101

TOOLS /dev/rtoolslv

USERS /dev/ruserslv

UNDO_KTFINFO /dev/rundo102

UNDO_INFORDS /dev/rundo202

UNDO_KTFINFO /dev/rundo103

UNDO_INFORDS /dev/rundo203

MINING_01 /dev/rtbl10_4G_008

MINING_01 /dev/rtbl10_4G_009

MINING_01 /dev/rtbl10_4G_010

MINING_01 /dev/rtbl10_4G_011

MINING_01 /dev/rtbl10_4G_012

MINING_01 /dev/rtbl10_4G_013

[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


Comments

comments

haisins

오라클 DBA 박용석 입니다. haisins@gmail.com 으로 문의 주세요.

Oracle Database 장애 복구 방법”의 1개의 댓글

  • 2019-06-03 8:29 오전
    Permalink

    I’m glad I recently came across your article about choosing an HVAC contractor.
    I absolutely agree that stability in the flooring buisingess of the contractor is a
    superb sign how the contractor lands on a terrific job.
    Yes, HVAC system is the just about the most expensive
    equipment that my hubby bought for our family, so it can be crucial for individuals to merely start using a reputable HVAC company.

    Our heating system does not produce enough heat
    anymore, all this is bringing about a lot of discomfort while in the house.

    I’m looking to pinpoint a contractor that has been in the business for many years because given our budget, their experience
    of handling repairs are extensive and reliable. I’ll ensure that you
    consider every one of your suggestions about HVAC contractor.

    댓글달기

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다