Embed Size (px)
Citation preview
오라클 복구 지침(Recovery Scenario)
1998.7이승택
Seuntaek Lee
1. 복구지침 1.1 개요 복구(Recovery)란 말 그래도 장애가 발생한 DB 를 정상운영되도록 하는 것을 말한다. DBA 는 DB에서 발생할 수 있는 여러 가지 유형의 장애에 대하여 정형화하고 각 Case 에 대한 Recovery Plan 을 만들어서 장애에 의한 DB 의 운영중단과 Data 의 손실을 최소화해야 한다. 1.2 장애유형 파악 Flow Chart 1.3 장애유형별 세부 복구 시나리오 ○ SN. #01 - Datafile 손상시 복구 ○ SN. #02 - Online Redo Log 손상시 복구 ○ SN. #03 - Offline Redo Log 손상시 복구 ○ SN. #04 - Controlfile 손상시 복구 ○ SN. #05 - 모든 File 손상시 복구 ○ SN. #06 - Datafile, Online Redo Log, Offline Redo Log 손상시 복구 ○ SN. #07 - Controlfile, Datafile, Offline Redo Log 손상시 복구 ○ SN. #08 - Datafile, Online Redo Log 손상시 복구 ○ SN. #09 - Datafile, Offline Redo Log 손상시 복구 ○ SN, #10 - Datafile, Controlfile 손상시 복구 ○ SN. #11 - Online, Offline Redo Log 손상시 복구 ○ SN. #12 - Online Redo Log, Controlfile 손상시 복구 ○ SN. #13 - Offline Redo Log, Controlfile 손상시 복구 ○ SN. #14 - Online Backup 중 DB Abort 시 복구 ○ SN. #15 - DB StartUp Failure 시 복구 ○ SN. #16 - 기타 유용한 복구 Tip
○ 장애유형 파악 Flow Chart
○ 장애유형별 세부 복구 시나리오
시나리오.#
Recovery 관련 Files
비 고Data file
OnlineRedo Log
OfflineRedo Log
Control file
SN. #01 ●
- 모든 DB 는 Archivelog mode 운영 기준임- 모든 DB 는 Mirred Redo Log 로 운영- 모든 DB 는 Mirred Controlfile 로 운영
SN. #02 ● SN. #03 ● SN. #04 ●
SN. #05 ● ● ● ●
SN. #06 ● ● ● SN. #07 ● ● ●
SN. #08 ● ● SN. #09 ● ● SN. #10 ● ●
SN. #11 ● ● SN. #12 ● ●
SN. #13 ● ●
SN. #14 Online Backup 중 DB Shutdown abort 됨SN. #15 ORACLE Startup 이 불가능할 경우(SGA, Shared Memory, Semaphore 문제)SN. #16 기타 유용한 복구 Tip
● : Damaged file
○ SN. #01 - Datafile 손상시 복구 1. DB Shutdown SVRMGR> shutdown abort; ORACLE instance shut down. 2. DB 를 startup mount 시킴 SVRMGR> startup mount; ORACLE instance started. Database mounted. 3. 손상된 Datafile 확인 SVRMGR> select a.file#,a.error,b.status,b.name from v$recover_file a, v$datafile b where a.file# = b.file#; FILE# ERROR STATUS NAME ---------- -------------- ------- ---------------------- 5 FILE NOT FOUND ONLINE /oracle/PROD/data01/users01.dbf 4. 손상된 Datafile 및 필요한 Archivelog file Restore Networker 등 백업 S/W 를 사용하여 Restore 5. Recover Database 수행 SVRMGR> recover database; ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /ORACLE/PROD/arch/arch_PROD_1_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto Applying suggested logfile... .... Media recovery completed. SVRMGR> alter database open; statement processed. - 복구완료 - ※ recovery option - RET : ORACLE 이 suggest 하는 archivelog file 적용 DB 의 archive destination 에 해당 archivefile 이 존재해야 함. - filename : DBA 가 입력하는 file 을 recovery 에 사용(Full path 로 입력) - auto : ORACLE 이 automatic 하게 recovery 수행. archive destination 에 필요한 archivelog file 이 존재해야 함. - from : archivelog file 이 존재하는 directory 지정. 이후 recovery process 는 archive destination 를 DBA 가 입력한 곳으로 변경하여 작업 수행.
ex) from /oracle/PROD/arch/arch_PROD_%t_%s.dbf %s : log_sequence 번호, %t : log thread 번호 - cancel : recovery 작업 종료. ※ system tablespace 가 아닐경우 해당 TABLESPACE 만 Offline 시키고서 Recovery 가능. 1. 손상된 Datafile 및 필요한 Archivelog file Restore Networker 등 백업 S/W 또는 OS Command 를 사용하여 Restore 2. 해당 TABLESPACE OFFLINE SVRMGR> alter tablespace users offline immediate; statement processed. ※ offline 시 immediate option 을 주지 않으면 해당 datafile 이 crash 되었기 때문에,offline 이 되지 않음. 3. Recover tablespace 수행 SVRMGR> recover tablespace users; ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_1_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto Applying suggested logfile... .... Media recovery completed. SVRMGR> alter database open; statement processed. - 복구완료 -
○ SN. #02 - Online Log File 손상시 복구 ※ Online Redo Log 에 의한 DB 장애에는 여러가지 종류가 있으며 장애유형을 정확히 파악하여 복구 작업을 수행해야 함. ■ Online Redo Loge 의 구성 및 상태 Log Group : 보통 3 개 이상의 Group 이 존재하며, 각 Group 이 2 개 이상의 Member 로 구성되었을 경우 Mirred Log 로 구성 되어 있다고 함. Log Member: 보통 1 개의 Group 에 2 개의 Member 로 구성 되며, 이것은 Online Redo Log의 backup 을 위한 조치임. Member 1 Member 2
Group 1 log_g1_m1_PROD.dbf
log_g1_m2_PROD.dbf
Group 2 log_g2_m1_PROD.dbf
log_g2_m2_PROD.dbf
Group 3 log_g3_m1_PROD.dbf
log_g3_m2_PROD.dbf
ORACLE 은 DB 의 변경 내용을 G1 -> G2 -> G3 -> G1 -> G2 ...의 Cicular 방식으로 Online Redo Log 에 Write 하며 현재 Write 가 되는 Redo Log 은 Current 상태이고, 나머지는 Inactive 상태임. Archivelog Mode 의 경우 Write 된 Redo Log 가 Archive 가 되었는지의 여부에 따라 ARC, No ARC 두개의 상태로 구분된다. ■ Online Redo Log 의 Crash 종류. Online Redo Log 의 Crash 종류는 Crash 된 Online Redo Log 의 status 에 따라 다음과 같이 구분됨. 1. 특정 Group 의 1 개의 Member 가 Crash 된 경우.(SN. #02-1) 2. Inactive, ARC 된 Group 의 모든 Member 가 Crash 된 경우.(SN. #02-2) 3. Inactive, No ARC 된 Group 의 모든 Member 가 Crash 된 경우.(SN. #02-3)
4. Current Group 의 모든 Member 가 Crash 된 경우.(SN. #02-4) ◆ SN. #02-1 DB 사용시 아무런 장애를 일으키지 않으며, alert_<SID>.log File 에 Errors in file /oracle/PROD/admin/PROD/bdump/lgwr_29934.trc: ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1: '/oracle/PROD/log1/log_g3_m1_PROD.dbf' ORA-07360: sfifi: stat error, unable to obtain information about file. 의 error 가 발생함. DB 사용에는 문제 없지만 차후 더 큰 장애의 요인이 될 수 있기 때문에 빠른 조치가 필요함. 1. 장애가 발생한 log file 을 확인한다. SVRMGR> select * from v$logfile; GROUP# STATUS MEMBER ---------- ------- ------------------------------------------------------------- 1 /oracle/PROD/log1/log_g1_m1_PROD.dbf 2 /oracle/PROD/log1/log_g2_m1_PROD.dbf 3 INVALID /oracle/PROD/log1/log_g3_m1_PROD.dbf 1 /oracle/PROD/log2/log_g1_m2_PROD.dbf 2 /oracle/PROD/log2/log_g2_m2_PROD.dbf 3 /oracle/PROD/log2/log_g3_m2_PROD.dbf 2. 장애가 발생한 Redo Log Group 이 Current Redo Log Group(Write 중인 Redo Log Group)인지 확인한다. SVRMGR> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ------------------------------------------------------------------------- 1 1 41 512000 2 YES INACTIVE 2 1 40 512000 2 YES INACTIVE 3 1 42 524288 2 NO CURRENT 3. Current Redo Log Group 일 경우는 다음과 같이 강제로 Log Switch 를 일으킴. SVRMGR> alter system switch logfile; statement processed. 4. 장애가 발생한 Log File Member 를 Drop 한다. SVRMGR> alter database drop logfile member '/oracle/PROD/log1/log_g3_m1_PROD.dbf'; statement processed. 5. 새로운 log file member 를 생성한다. SVRMGR> alter database add logfile member '/oracle/PROD/log1/log_g3_m1_PROD.dbf' to group 3; statement processed. 6. Redo Log File 이 처음 add 되면 최초의 Write 가 발생하기 전까지는 Status 가 Invalid 이므로 Log Switch 를 3-4 회 정도 수행하여 Status 를 다시 확인해 본다. SVRMGR> alter system switch logfile; 3-4 회 수행
SVRMGR> select * from v$logfile; - 복구완료 -
◆ SN. #02-2 DB 가 비정상 종료하고, Startup 시 다음의 error 가 발생함. ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/oracle/PROD/log1/log_g2_m1_PROD.dbf' ORA-00312: online log 2 thread 1: '/oracle/PROD/log2/log_g2_m2_PROD.dbf' 1. DB 를 shutdown abort 로 죽임. SVRMGR> shutdown abort; 2. DB 를 mount 시킴 SVRMGR> startup mount; statement processed. 3. 장애가 발생한 log file 의 status 를 확인한다. SVRMGR> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ---------- ---------- ---------- ---------- ---------- --- ---------------- 1 1 47 512000 2 YES INACTIVE 2 1 0 512000 2 YES UNUSED 3 1 48 524288 2 NO CURRENT 위에서 group 2 의 status 가 unused 로 장애가 발생했고, ARC 는 YES 로 archive 가 된 상태이며 group 3 이 current 인 것으로 보아 group 2 는 INACTIVE 상태였음을 알수 있다. 따라서, INACTIVE, ARC 된 log group 의 전체 member 가 장애가 일어난 것이다. 4. DB 를 No Archive mode 로 변경한다. SVRMGR> alter database noarchivelog; statement processed. 5. 장애가 발생한 log group 을 drop 하고, 다시 group 을 생성한다. SVRMGR> alter database drop logfile group 2; statement processed. SVRMGR> alter database add logfile thread 1 group 2 ('/oracle/PROD/log1/log_g2_m1_PROD.dbf', '/oracle/PROD/log2/log_g2_m2_PROD.dbf') size 20M; statement processed. 6. ARCHIVE LOG 로 변경 후 DB Open. SVRMGR> alter database archivelog; statement processed. SVRMGR> alter database open; statement processed. - 복구완료 - ◆ SN. #02-3 다음의 Error 가 alert_<SID>.log 에 발생하며, DB 는 더 이상의 Archive 가 일어나지 못해 Hang이 걸린 상태로 정지되어 있음.
ORACLE Instance PROD - Archival Error Sat Dec 27 08:36:27 1997 ORA-00255: error archiving log 2 of thread 1, sequence # 49 ORA-00312: online log 2 thread 1: '/oracle/PROD/log1/log_g2_m1_PROD.dbf' ORA-00312: online log 2 thread 1: '/oracle/PROD/log2/log_g2_m2_PROD.dbf' ORA-00286: No members available, or no member contains valid data ORA-00334: archived log: '/oracle/PROD/arch/arch_PROD_40.dbf' 1. DB 를 shutdown abort SVRMGR> shutdown abort; 2. DB 를 mount 시킴 SVRMGR> startup mount; statement processed. 3. 장애가 발생한 log file 의 status 를 확인한다. SVRMGR> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS ---------- ---------- ---------- ---------- ---------- --- ---------------- 1 1 47 512000 2 NO INACTIVE 2 1 46 512000 2 NO INACTIVE 3 1 48 524288 2 NO CURRENT 위에서 어떤 log file 에 장애가 발생했는지 알 수 없으며, alert_<SID>.log 나 DB open 시 발생하는 Error 로 장애 발생 log group 을 파악한다. log 에서 group 2 에 장애가 발생한 것을 확인하고, group 2 의 status 를 확인하여 보면, ARC 는 NO 임을 알수 있다. 이것은 log file 이 Archive 가 되기 전에 삭제되었다는 것이며, 해당 log file 의 내용은 어디에서도 복 구가 불가능함. 4. Cancel based recovery 수행 SVRMGR> recover database until cancel; ※ recovery 에 필요한 archive file 을 요구하면 아무것도 recovery 하지 말고 cancel 시킴 또는 Media recovery completed message 가 나오면 5.를 수행 ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} cancel 5. 장애가 발생한 log group 의 member 를 rename 시킴. SVRMGR> alter database rename file '/oracle/PROD/log1/log_g2_m1_PROD.dbf' to '/oracle/PROD/log1/log_g2_m1_PROD.tmp'; statement processed. SVRMGR> alter database rename file '/oracle/PROD/log2/log_g2_m2_PROD.dbf' to '/oracle/PROD/log2/log_g2_m2_PROD.tmp'; statement processed.
6. DB 를 resetlogs option 으로 open. SVRMGR> alter database open resetlogs; statement processed. - 복구완료 - ※ 주의 : DB 를 resetlogs option 으로 open 했기 때문에 기존의 모든 archivelog file 과 Online 백업은 사용이 불가능하며, 따라서 DB 를 바로 Online 또는 Offline Full 백업 받아야함. ◆ SN. #02-4 만일 current log file 의 모든 member 가 손상된 사실을 파악했다면, 다음 사항에 따라 복구의 형태가 많이 달라짐으로 다음을 우선적으로 수행해 보아야 한다. 1. log file 의 상태를 파악한다. SVRMGR> select * from v$log; 2. current log group 의 모든 member 가 삭제 되었다면, log file 을 switch 해 본다. SVRMGR> alter system switch logfile; 3. DB 를 immediate 로 shutdown 해 본다. SVRMGR> shutdown immediate; 4. shutdown 이 되지 않을 경우 abort 로 down 시킨다. SVRMGR> shutdown abort; 5. SN. #02-3 을 사용하여 recovery 를 수행하여 본다. 6. SN. #02-3 의 방법으로 복구 불가능시 다음을 수행한다. 7. 모든 datafile, archivelog file 을 restore 한다. 8. incomplete media recovery 를 수행하여 corrupt 된 log file 이전까지 recovery 를 수행한다. SVRMGR> recover database until cancel; ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} .. .. ← corrupt log file 이전 까지 recovery 적용 cancel 9. resetlogs option 으로 DB Open 시킴 SVRMGR> alter database open resetlogs; statement processed. - 복구완료 -
○ SN. #03 - Offline Log File 손상시 복구 Offline Log File 이란 Archivelog File 을 말한다. Archivelog File 이 손상을 입으면 DB 사용에는 아무런 문제가 없으나 그 이전의 모든 Online 백업은 복구에 사용될 수 없으므로 즉시 Online 또는 Offline Full 백업을 수행해야 한다.
○ SN. #04 - Controlfile 손상시 복구 ※ Control File 에 의한 장애도 여러가지 유형이 있으며,장애를 최소화하기 위해서는 DB 의 구조에 변경이 일어날시 바로 controlfile 백업을 받아야 한다. Control file 의 백업에는 다음의 2 가지 방법이 있다. 1. controlfile 의 image 를 백업 받는법. SVRMGR> alter database backup controlfile to '/oracle/PROD/backup/contrl.ctl.971212'; 2. controlfile 생성 script 를 백업 받는법. SVRMGR> alter database backup controlfile to trace; DB 의 user_dump_dest 에 ora_pid.trc 로 script 가 생성됨 ◆ SN. #04-1 (Mirred 된 controlfile 중 일부가 손상 되었을 경우) 1. DB 를 shutdown (normal 로 shutdown 되지 않을 경우 abort 로 shutdown) SVRMGR> shutdown [normal|abort]; statement processed. 2. config<SID>.ora file 에서 control_files 정보를 읽어, 삭제된 controlfile 을 복구한다. config<SID>.ora 의 내용 control_files= (/oracle/PROD/data01/control01.ctl, /oracle/PROD/data02/control02.ctl, /oracle/PROD/data03/control03.ctl) 만일 control02.ctl file 이 손상되었다면 control01.ctl 을 copy 한다 $ cp /oracle/PROD/data01/control01.ctl /oracle/PROD/data02/control02.ctl ※ 만일 controlfile 이 있는 disk 의 장애로 복구가 불가능할 경우에는 config<SID>.ora file 에서 해당 controlfile 을 삭제한다 3. DB startup SVRMGR> startup - 복구완료 - ◆ SN. #04-2 (Mirred 된 controlfile 전체가 손상되고, 현재 DB Structure 를 갖고 있는 controlfile 백업이 있을 경우) ※ 현재 DB 의 structure 를 갖고 있는 controlfile controlfile 을 백업 받은 이후로 tablespace 의 변경 작업(추가, 삭제, Datafile 추가 등), log file 의 변경 작업(group 생성/삭제, member 생성/삭제/rename 등)이 수행되지 않은 상태를 말함. alert_<SID>.log file 에서 확인할수 있음. 1. DB 를 shutdown 한다. SVRMGR> shutdown abort;
statement processed 2. 백업 controlfile 을 restore 한다. 반드시 controlfile 백업 이후로 DB 의 structure 에 변경이 발생 했는지를 확인한다. 3. DB 의 config<SID>.ora 에서 control_files 를 restore 된 file 만을 지정하도록 변경한다. control_files=(/oracle/PROD/data01/control01.ctl.bak) 4.DB 를 mount 시킨다 SVRMGR> startup mount 5.DB 를 recover 한다. SVRMGR> recover database using backup controlfile; ORA-00279: Change 4829 generated at 12/29/97 09:51:44 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_6.dbf ORA-00280: Change 4829 for thread 1 is in sequence #6 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} .. Media recovery complete. ※ archivelog 를 적용하다 보면,archivelog file 로 존재하지 않는 archivelog file 을 요구 하는 경우가 존재할수 있다. 이것은 아직 archive 되지 않은 Online Redo log 이며, v$log에서 해당 sequence 번호를 갖는 Online Redo Log file 명을 지정해 주면 된다. (위의 경우 <RET>대신 /oracle/PROD/log1/log_g2_m1_PROD.dbf 를 주면 됨) 위의 경우를 예로 들면, arch_PROD_6.dbf 가 존재하지 않는 file 이라면, SVRMGR> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS 1 1 5 512000 1 YES INACTIVE 2 1 6 512000 1 NO CURRENT 3 1 4 512000 1 YES INACTIVE 에서 sequence# 6 이 아직 archive 가 되지 않았음을 알수 있다. 따라서 recovery 시에는 해당 Online log file 명을 archive file 대신 지정하여 주면 복구가 성공적으로 이루어 질수 있다. 6.DB 를 Open 한다. SVRMGR> alter database open resetlogs; ※ recover 시 backup controlfile 을 사용하면 DB open 시 반드시 resetlogs option 을 사용해야 하며,복구후 반드시 DB 백업을 수행해야 함. 7. DB 를 shutdown 한후 configSID.ora 를 원래대로 편집하고,cp 를 사용하여 controlfile 을 copy 한 후 DB 백업을 수행한다. ※ resetlogs option 을 사용하여 DB 를 open 하면 이전의 모든 online 백업, archivelog file 은 차후에 사용불가함으로 반드시 DB 백업을 수행 해야 함. - 복구완료 -
◆ SN. #04-3 (Mirred 된 controlfile 전체가 손상되고, 현재 DB Structure 를 갖고 있는 controlfile 백업이 존재하지 않을 경우) 0. DB 의 상태를 확인한다. ※ DB 가 Open 되어 있는 상태면 빨리 controlfile 백업을 수행한다. DB 를 shutdown 하면 복구가 무척 어려워지며, 따라서 DB 의 상태를 확인하여 controlfile 백업을 수행하는 것이 가장 중요함. 1-1. DB 가 Open 되어 있을 경우 SVRMGR> alter database backup controlfile to '/oracle/PROD/backup/control01.ctl.bak'; statement processed. SN. #04-2 의 복구 시나리오를 사용하여 복구 수행 backup controlfile 시 error 가 발생하면 DB 를 shutdown 후 1-2 부터 수행한다. 1-2. DB 가 shutdown 되어 있을 경우, 또는 backup controlfile 이 실패했을 경우. 수작업으로 controlfile 생성 script 를 만든다. Missing 된 Datafile 또는 Redo Log File 이 없도록 정확하게 작성한다. controlfile 생성 script 예제 CREATE CONTROLFILE REUSE DATABASE "PROD" NORESETLOGS ARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 2 MAXDATAFILES 30 MAXINSTANCES 8 MAXLOGHISTORY 800 LOGFILE GROUP 1 '/oracle/PROD/log1/log_g1_m1_PROD.dbf' SIZE 20M, GROUP 2 '/oracle/PROD/log1/log_g2_m1_PROD.dbf' SIZE 20M, GROUP 3 '/oracle/PROD/log1/log_g3_m1_PROD.dbf' SIZE 20M DATAFILE '/oracle/PROD/data01/system01.dbf', '/oracle/PROD/data02/rbs01.dbf', '/oracle/PROD/data03/temp01.dbf', '/oracle/PROD/data01/tools01.dbf', '/oracle/PROD/data01/users01.dbf' ; 2. DB 를 nomount 시킨다. SVRMGR> startup nomount; 3. controlfile 생성 script 를 수행하여 control file 을 생성한다. SVRMGR> @cr_ctl.sql statement processed. 4. DB 를 recover 한다. SVRMGR> recover database; Media recovery completed.
5. DB 를 Open 한다. SVRMGR> alter database open; statement processed 6. Missing 된 datafile 이 있는지 확인한다. SVRMGR> select name,status from v$datafile; ---------------------------------------- ------- /oracle/PROD/data01/system01.dbf SYSTEM /oracle/PROD/data02/rbs01.dbf ONLINE /oracle/PROD/data03/temp01.dbf ONLINE /oracle/PROD/data01/users01.dbf ONLINE MISSING0005 RECOVER 7. Missing 된 file 이 발견되면 DB 를 shutdown 한후 missing file 을 찾아내서 controlfile 을 다시 생성한다.(1-2 부터 다시 수행) - 복구완료 -
○ SN. #05 - 모든 File 손상시 복구 ※ Datafile, Online Redo Log File, archive log file, Control file 전체가 장애를 입었을 경우의 복구는 각 장애 시나리오를 참조하여 복구를 수행하며, 복구 순서는 다음과 같다. 1. DB shutdown SVRMGR> shutdown abort; 2. Controlfile 복구 시나리오(SN. #05)를 사용하여 controlfile 복구후 mount 까지 수행 백업된 controlfile 또는 nomount 상태에서 create controlfile 을 사용하여 controlfile 복구 3. 가장 최근의 백업에서 모든 Datafile 및 필요한 Archivelog file 을 restore 함 - 만일 손상된 archive log file 의 sequence 번호가 100 이면 101 이후의 archive log file 은 복 구가 불가능하며 따라서 restore 할 필요가 없음. 4. Incomplete media recovery 를 수행하여 손상된 archive log 이전까지 recover 적용 SVRMGR> recover database until cancel using backup controlfile; ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto .. ← 99 번 archive log 까지 적용하고 cancel 시킴 cancel Media recovery cancelled 5. resetlogs option 으로 DB 를 Open 함 SVRMGR> alter database open resetlogs; statement processed. ※ 손상된 log file 은 특별한 조치 없이 재생성이 되는데,resetlogs option 을 사용하면,기존 log file 의 내용을 무시하고,log file 을 재 생성해주기 때문임. 6. DB 백업 수행. - 복구완료 -
○ SN. #06 - Datafile, Online Redo Log, Offline Redo Log 손상시 복구 1. DB 를 shutdown 한다. SVRMGR> shutdown abort; statement processed. 2. 가장 최근의 백업에서 모든 Datafile 및 필요한 Archive log file 을 restore 함 - 만일 손상된 archive log file 의 sequence 번호가 100 이면 101 이후의 archive log file 은 복 구가 불가능하며,따라서 restore 할 필요가 없음. 3. Incomplete media recovery 를 수행하여,손상된 archive log 이전까지 recover 적용 SVRMGR> recover database until cancel using backup controlfile; ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto .. ← 99 번 archive log 까지 적용하고 cancel 시킴 cancel Media recovery cancelled 4. resetlogs option 으로 DB 를 Open 함 SVRMGR> alter database open resetlogs; statement processed. ※ 손상된 log file 은 특별한 조치 없이 재생성이 되는데,resetlogs option 을 사용하면,기존 log file 의 내용을 무시하고,log file 을 재 생성해주기 때문임. 5. DB 백업 수행. - 복구완료 -
○ SN. #07 - Controlfile, Datafile, Offline Redo Log 손상시 복구 ※ DB 의 복구는 전체 DB 가 손상된 archive log file 이전 상태로 되돌아 가는 형태이므로,DB 복구를 시작하기 전에 현재 DB 의 full backup 또는 필요한 데이타의 export 작업이 선행되 어야 함. 1. DB shutdown SVRMGR> shutdown abort; 2. Controlfile 복구 시나리오(SN. #04)를 사용하여 controlfile 복구후 mount 까지 수행 백업된 controlfile 또는 nomount 상태에서 create controlfile 을 사용하여 controlfile 복구 3. 가장 최근의 백업에서 모든 Datafile 및 필요한 Archive log file 을 restore 함 - 만일 손상된 archive log file 의 sequence 번호가 100 이면 101 이후의 archive log file 은 복구가 불가능하며 따라서 restore 할 필요가 없음. 4. Incomplete media recovery 를 수행하여,손상된 archive log 이전까지 recover 적용 SVRMGR> recover database until cancel using backup controlfile; ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto .. ← 99 번 archive log 까지 적용하고 cancel 시킴 cancel Media recovery cancelled 5. resetlogs option 으로 DB 를 Open 함 SVRMGR> alter database open resetlogs; statement processed. ※ 손상된 log file 은 특별한 조치 없이 재생성이 되는데,resetlogs option 을 사용하면,기존 log file 의 내용을 무시하고,log file 을 재 생성해주기 때문임. 6. DB 백업 수행. - 복구완료 -
○ SN. #08 - Datafile, Online Redo Log 손상시 복구 1. Online Redo Log File 을 먼저 복구한다(SN. #02 참조) 만일 Online log 복구시 전체 Current log file 의 corrupt 로 인해 DB 를 resetlogs 로 Open해야 한다면 손상된 Datafile 은 복구가 불가능함으로 DB 를 resetlogs 로 Open 해야 할 경우는 전체 Datafile 을 restore 하여 Incomplete media recovery 를 수행한후(SN. #02-4 참조) DB 를 resetlogs 로 Open 한다. 2. DB 를 mount 시킨 상태에서 필요한 Datafile 과 Archive File 을 restore 하여 recovery 를 수행한다. (#SN. #01 참조) - 복구완료 -
○ SN. #09- Datafile, Offline Redo Log 손상시 복구 1. DB 를 shutdown 한다. SVRMGR> shutdown abort; statement processed. 2. 가장 최근의 백업에서 모든 Datafile 및 필요한 Archive log file 을 restore 함 - 만일 손상된 archive log file 의 sequence 번호가 100 이면 101 이후의 archive log file 은 복 구가 불가능하며 따라서 restore 할 필요가 없음. 3. Incomplete media recovery 를 수행하여,손상된 archive log 이전까지 recover 적용 SVRMGR> recover database until cancel using backup controlfile; ORA-00279: Change 4783 generated at 12/15/97 10:40:57 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_33.dbf ORA-00280: Change 4783 for thread 1 is in sequence #33 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto .. ← 99 번 archive log 까지 적용하고 cancel 시킴 cancel Media recovery cancelled 4. resetlogs option 으로 DB 를 Open 함 SVRMGR> alter database open resetlogs; statement processed. ※ 손상된 log file 은 특별한 조치 없이 재생성이 되는데 resetlogs option 을 사용하면 기존 log file 의 내용을 무시하고 log file 을 재생성함. 5. DB 백업 수행. - 복구완료 -
○ SN. #10 - Datafile, Offline Redo Log 손상시 복구 1. 먼저 Control file 을 복구한다(SN. #04) DB 는 mount 된 상태로 그대로 둠 2. 필요한 Datafile 및 archive log File restore 3. backup controlfile option 을 사용하여 DB 를 Recover 함 SVRMGR> recover database using backup controlfile; ORA-00279: Change 4829 generated at 12/29/97 09:51:44 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_6.dbf ORA-00280: Change 4829 for thread 1 is in sequence #6 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto .. Media recovery complete. 4. resetlogs option 을 사용하여 DB Open. SVRMGR> alter database open resetlogs; statement processed. 5. DB Full Backup 수행.
○ SN. #11 - Online Redo Log, Offline Redo Log 손상시 복구 1. Online Redo Log 를 복구한다.(SN. #02 참조) 2. Online 또는 Offline DB Full 백업을 수행한다. 3. 복구완료
○ SN. #12 - Online Redo Log, Controlfile 손상시 복구 1. Controlfile 을 복구한다.(SN. #04 참조) DB 는 Mount 상태로 둔다. 2. Resetlog Option 을 사용하여 DB 를 Open 한다. SVRMGR> alter database open resetlogs; statement processed. 3. Online 또는 Offline DB Full 백업을 수행한다. 4. 복구완료
○ SN. #13 - Offline Redo Log, Controlfile 손상시 복구 1. Controlfile 을 복구한다.(SN. #04 참조) DB 는 Mount 상태로 둔다. 2. Resetlog Option 을 사용하여 DB 를 Open 한다. SVRMGR> alter database open resetlogs; statement processed. 3. Online 또는 Offline DB Full 백업을 수행한다. 4. 복구완료
○ SN. #14 - Online 백업 중 DB Abort 시 복구 DB Mount 후 Open 시 need media recovery error 가 발생하면 SVRMGR> select * from v$backup where status = 'ACTIVE'; 를 수행하여 1 개 이상의 row 가 출력되면 Online 백업 중 DB Abort 가 발생한 것이다. 다음과 같이 복구하면 된다. 0. Oracle Version 확인 7.2 이상과 7.1 이하 Version 의 복구방법이 다르다. ◆ Oracle 7.2 이상인 경우 1. DB 를 mount 시킨다. SVRMGR> startup mount; statement processed. 2. 다음을 수행하여 Backup 상태인 Datafile 들에 End Backup 을 수행한다. SVRMGR> set lines 200 SVRMGR> set heading off SVRMGR> spool end_backup.sql SVRMGR> select 'alter database datafile '''||b.name||''' end backup;' from v$backup a, v$datafile b where a.file# = b.file# and a.status = 'ACTIVE'; SVRMGR> spool off SVRMGR> @end_backup statement processed. 3. 전체 Datafile 이 End Backup 상태가 되었는지 확인한다. SVRMGR> select * from v$backup where status='ACTIVE'; 0 rows selected. 4. DB 를 Open 한다. SVRMGR> alter database open; ◆ Oracle 7.1 이하인 경우 1. recovery 에 필요한 archive log file 을 알아낸다. SVRMGR> select * from v$recovery_log; THREAD# SEQUENCE# TIME ARCHIVE_NAME ---------- ---------- -------------------- --------------------------------- 1 5 01/07/98 14:29:30 /oracle/PROD/arch/arch_PROD_5.dbf 2. 필요한 archive log file 을 restore 한다. 3. DB 가 mount 된 상태에서 recovery 를 수행한다. SVRMGR> recover database; ORA-00279: Change 4829 generated at 12/29/97 09:51:44 needed for thread 1 ORA-00289: Suggestion : /oracle/PROD/arch/arch_PROD_6.dbf
ORA-00280: Change 4829 for thread 1 is in sequence #6 Specify log: {<RET>=suggested | filename | AUTO | FROM logsource | CANCEL} auto .. Media recovery complete. 4. DB 를 Open 한다. SVRMGR> alter database open; statement processed. 5. 복구완료
○ SN. #15 - DB Startup Failure 시 조치 DB 가 Startup nomount 가 안될 경우는 주로 OS kernel parameter 에 비해 DB parameter 가 과다하게 설정되어 발생하는 경우가 많으며 특히 Memory 관련 parameter 문제가 대부분임. 각 Error Message 별 처리 방법은 다음과 같음. ◆ ORA-07310 smscre: unable to create sga. 조치방법 1. oracle SGA Size 를 확인한다. SGA ≒ db_block_size * db_block_buffers + shared_pool_size + log_buffers 2. OS Kernel Parameter 중 shmmax(max shared memory segment size)를 확인한다. HP-UX : /stand/system DIGITAL-UNIX : /etc/sysconfigtab 3. shmmax > SGA 여야 하며 그렇지 않은 경우 shmmax 를 늘리든가 DB parameter 중 db_block_buffers, shared_pool_size, log_buffers 를 줄인다. 4. DB 를 start 한다.
○ SN. #16 - 기타 유용한 복구 Tip ◆ DB Online 또는 Offline 백업에서 특정 table 만 복구하는 방법 export 를 이용한 Logical 백업이 없는 경우 DB Online 또는 Offline 백업에서 특정한 Table 을 복구할 필요가 있다. 이 때 최단시간 내에 복구하고자 한다면 다음과 같은 방법이 사용될 수 있다. 1. Restore 할 Machine 을 선정한다. 동일한 Version 의 Oracle 이 설치되어야 하며 동일 Machine 이어도 상관없다. 2. 복구할 Table 이 존재하는 Tablespace 와 Datafile 을 확인한다. SVRMGR> select tablespace_name from dba_tables where table_name = ' table_name '; SVRMGR> select file_name from dba_data_files where tablespace_name = ' tablespace_name '; 3. Online 또는 Offline 백업에서 SYSTEM, RBS, 복구할 Table 이 있는 Tablespace 의 Datafile 만 Restore 한다. 4. DB 를 mount 시킨다. 5. Restore 되지 않은 Tablespace 의 Datafile 들을 모두 offline 시킨다. SVRMGR> alter database datafile '.........' offline; statement processed. 6. DB 를 Recover 한 후 Open 한다.(복구지침 시나리오 참조) 7. 복구할 Table 을 Export 한다. 8. 복구할 DB 에 Import 한다. 9. 복구완료
![세계사 및 지리 - Regents Examinations...Global Hist. & Geo. – June ’15 Korean Edition [3] [다음 장] 7다음중고대그리스에서정치적인통합에는 장애가 되었고](https://img.dokumen.tips/doc/110x75/5f1baed85fd3eb41fb169ed1/e-e-e-regents-examinations-global-hist-geo-a-june.jpg)
