1. Backup & Recovery 개요 2. Backup 3. Recovery 4. Complete & Incomplete Recovery II - 1
1. Backup & Recovery 개요 Failure 범주 Statement failure - SQL 문수행오류 User Process failure - OS 프로세스의비정상종료 User failure - 사용자실수 Network failure -Network 장애 Instance failure - OS 장애, Database Hang Media failure - Datafile 손상 II - 2
1. Backup & Recovery 개요 Statement failure Statement failure 의원인 Application 의 logic error Table 에 bad data 를입력할경우 권한이없이 operation 을수행할경우 Quota 를초과해서 table 을생성할경우 Insert 나 Update 시 Tablespace 에충분한여유공간이없을경우 Statement failure 가발생하면 Oracle Server 또는운영체제가오류코드및메시지를반환합니다. 예 ) ORA-1653: unable to extend table SMARTUSR.BUSTKSUMH_BACKUP by 256 in tablespace TS_FS_PL $ oerr ora 1653 01653, 00000, "unable to extend table %s.%s by %s in tablespace %s" // *Cause: Failed to allocate an extent for table segment in tablespace. // *Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more files // to the tablespace indicated. Statement failure 해결 Program logic 을변경 SQL statement 수정및재실행 필요한 Database 권한을부여 ALTER USER command 사용하여 user quota 변경 Tablespace 에 data file 추가 II - 3
1. Backup & Recovery 개요 User Process failure User Process failure 의원인 User가세션에서비정상적인연결해제를수행한경우 Client-Server 구성에서 DB에연결한동안터미널창을닫은경우 User 세션이비정상적으로종료된경우 User가 PC를재부팅한경우 OS에서 Oracle user process를 Kill한경우 User 프로그램에서세션을종료하는주소 Exception이발생한경우 프로그램예외발생으로응용프로그램처리에러발생 User Process failure 해결 DBA 는 User procee 오류를해결하기위해조치를취할필요가거의없음. PMON Process 는비정상적으로종료된 User Process 를감지하고 PMON 은비정상종료된 Process 의 Transaction 을 rollback 하여이 Transcation 이보유한자원및잠금을해제함. II - 4
1. Backup & Recovery 개요 User failure 일반적인 User failure 유형 User가실수로테이블을삭제 (drop) 하거나절단 (truncate) 한경우 SQL> drop table employee; SQL> truncate table employee; User가테이블에서모든행을삭제한경우 SQL> delete from employee; SQL> commit; User가 Data를 Commit했지만 Commit한 Data에서오류가발견된경우 SQL> update employee set salary=salary*1.5; SQL> commit; User failure 해결 유효한백업에서복구한다. Export 파일에서테이블을 Import한다. LogMiner를 online/archived logfile을읽고, 분석하고, 해결한다. Point-in-time Recovery를통해 Recovery한다. Oracle 9i의 FlashBack을사용하여 Historical Data를보고 Recovery한다. undo segments를이용 (undo retention 기간안에서돌아갈수있음 ) II - 5
1. Backup & Recovery 개요 Instance failure Instance failure 의원인 정전으로인해서버를사용할수없게되는경우 CPU 고장, 메모리훼손또는 OS 고장같은하드웨어문제로인해서버사용불가시 Oracle Server Backgroun Process(DBWn,LGWR,PMON,SMON,CKPT) 중하나가 Failure 한경우 Instance failure 로부터 Recovery DBA 는특별한 Recovery 가필요없음. startup 명령을사용하여 Instance 를시작하면 Oracle Server 는 roll forward 및 rollback 단계를 모두수행하여자동으로 Recovery 한다. SQL> connect / as sysdba Connected. SQL> startup... Database opened. Database 가 open 되기까지시간이오래걸릴수있음. SMON 은마지막 checkpoing 로부터 online redo logfile 에기록된변경사항을적용하여 roll forward Procee 를수행함. Instance failure 중에생성된 Alert Log file 및 Trace file 을읽어원인을조사한다. II - 6
1. Backup & Recovery 개요 Media failure Media failure 의원인 Database 파일중하나를보유한디스크드라이브에헤드고장이발생한경우 Database 파일에대한읽기및쓰기와관련된물리적문제가발생한경우 파일을실수로지운경우 Media failure 해결 Recovery 전략은선택한 Backup 방식및영향을받는파일에따라결정한다. 사용가능한경우 Archive 된 Redo Log file 을적용하여마지막 Backup 이후 Commit 된 Data 를 Recovery 한다. II - 7
1. Backup & Recovery 개요 Backup 및 Recovery 전략정의 업무요구사항 Mean time to recover (MTTR) : 장애복구시간 Mean time between failures (MTBF) : 장애간평균시간 운영요구사항 24시간운영환경에맞는구성 Backup의유효성을정기적으로테스트및검증 Database 휘발성 ( 테이블의빈번한갱신, Database 구조의빈번한변경 ) 기술적고려사항 자원 : 하드웨어, 소프트웨어, 인력및시간 물리적이미지 (datafile) 혹은논리적객체 (table) 복사본 Database 구성및 transaction 볼륨 Disaster Recovery 문제 자연적손상시영향도 ( 지진, 홍수, 화재 ) 핵심담당자의부재 II - 8
1. Backup & Recovery 개요 Instance 및 Media Recovery 구조 Instance SGA Shared pool User process Server process PGA Locks Data buffer cache Large pool Redo log buffer Shared SQL and PL/SQL Data dict. cache SMON DBWn PMON CKPT LGWR ARCn Data file 1 Control files Redo log file 1 Parameter file Data file 2 Redo log file 2 Password file Data file 3 Database Archived log files II - 9
1. Backup & Recovery 개요 다중화된 Redo log file Group 1 Group 2 Group 3 Disk 1 (Member a) Log1a.rdo Log2a.rdo Log3a.rdo Disk 2 (Member b) Log1b.rdo Log2b.rdo Log3b.rdo Redo log file 구성에는 Group 당최소둘이상의 Redo log Member 가필요하며 Failure 할때를대비해서각 Member 를다른디스크에둡니다. 구성시유의사항 Group 의모든 Member 는동일한정보를포함하며크기도동일함 Group Member 는동시에갱신됨 각 Group 은동일한수및크기의 Member 를포함해야함. II - 10
1. Backup & Recovery 개요 Database Checkpoint 개념 Checkpoint는 Recovery가시작될위치를결정하는데사용됨 Dirty Block Checkpoint Queue Checkpoint Process(CKPT) Checkpoint 유형 전체 Checkpoint 모든 Dirty Buffer 가기록됨 Shutdown normal immediate transactional alter system checkpoint 시 Incremental Checkpoint(Fast-Start Checkpoint) 주기적으로기록됨 가장오래된 Block 만기록 부분 Checkpoint Tablespace 에속하는 Dirty Buffer alter tablespace begin backup 시 alter tablespace.. offline normal 시 II - 11
1. Backup & Recovery 개요 다중화된 Control file Control file 기능 Control file은 Database의구조를설명하는 Binary file Database 마운트에꼭필요 Control file 손상에대비두개이상의 Control file을다른디스크에두는게원칙임 Control file 내용 Database이름 Database가생성된시간기록 Recovery에필요한동기화정보 (Checkpoint 및 Log Sequence 정보 ) Datafile과 Redo log file의이름과위치 Database의 Archive 모드 Control file 다중화방법 initsid.ora 파일내 control_files 파라미터편집또는추가 Database Restart 시적용 SQL> select name from v$controlfile; NAME ----------------------------------------------- /oradata/control01.ctl /oraindx/control02.ctl II - 12
1. Backup & Recovery 개요 Database 동기화 Archive 된 Log file Archive된 Redo log file과결합된 Database Backup은 Commit된모든 Data를 Failure지점까지 Recovery할수있도록보장 Database가 Online인동안에도유요한 Database Backup을할수있음 (Online Backup) Database 동기화 모든Datafile, Redo log 및Control file이동기화되지않으면oracle Database를열수없으며, 이러한경우 Recovery가필요함 Database Open을위해서는모든 Datafile(Offline 또는 Readonly 제외 ) 이동일한 Checkpoint를가져야함 동기화는현재 Redo log Checkpoint 및 Sequence Number를기반으로함 Redo log file에기록된변경사항을적용하면 Datafile이동기화됨 Redo log file은 Recovery 단계중 Oracle Server에의해자동으로요청됨 요청된위치에 Log가존재해야함. II - 13
1. Backup & Recovery 개요 ARCHIVELOG 모드 LGWR Redo history Online Redo Log file 052 054 051 053 051 052 052 054 051 053 053 Archive 된 Log file 모든 Transaction은 Online Redo Log file에기록되어 Database Failure시 Transaction을자동으로 Recovery 할수있도록함 Database를 ARCHIVELOG모드로구성하여 Redo 정보기록이 Archive된파일로유지관리되도록할수있음. Archive된Redo Log file은media Recovery에사용할수있음 Online 상태인 Database를 Backup할수있음 Database를파일손상시 Archive된 Log file을이용하여최신상태로복구가능 (Complete Recovery) Database를특정시점까지 Recovery할수있음 (Incomplete Recovery) II - 14
1. Backup & Recovery 개요 ARCHIVELOG 모드활성화 initsid.ora LOG_ARCHIVE_START = true LOG_ARCHIVE_MAX_PROCESSES = 4 LOG_ARCHIVE_DEST = /ARCH LOG_ARCHIVE_FORMAT = log_%t_%s.arc 명령어 자동활성화 ALTER SYSTEM ARCHVIE LOG START; ALTER SYSTEM ARCHVIE LOG STOP; ALTER SYSTEM ARCHVIE LOG CURRENT; ARCHIVE LOG LIST; SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination /ARCH Oldest online log sequence 832 Next log sequence to archive 836 Current log sequence 836 SQL> II - 15
1. Backup & Recovery 개요 2. Backup 3. Recovery 4. Complete & Incomplete Recovery II - 16
2. Backup 용어 전체 DB 백업 모든 Datafile 및 Control file에대한백업 데이터베이스가열려있거나닫혀있을수있음 부분 DB 백업 Tablespace Datafile Control file 일관성있는백업 일관성없는백업 Data Export 백업 II - 17
2. Backup Backup 종류 구분내용비고 오프라인 데이터베이스 shutdown 후데이터 - 가장안정적이고확실한백업 (Cold) 백업 파일을 OS 에서백업 - 백업중데이터베이스운영중단 Physical 백업 온라인 (Hot) 백업 데이터베이스운영중백업상태표 시후파일을 OS 에서백업 - 아카이브로그모드에서만운영가능 - begin backup, end backup 사이의 OS상백업 - 백업중데이터베이스운영가능 - 백업중변경작업응답속도저하 Logical exp/imp 데이터베이스운영중논리적인테 - 스키마나오브젝트단위의백업 백업 백업 이블을 Flat 파일로백업 - 변경중인데이터는백업받지않음 II - 18
2. Backup Backup 방식 Closed database Closed or Opened database NOARCHIVELOG 모드 ARCHIVELOG 모드 Physical backup 물리적백업방식 Archive 를사용하지않는백업은 Media Failure 후에마지막백업시점까지 Recovery Archive 를사용한백업은 Media Failure 후에실패시점까지 Recovery II - 19
2. Backup 오프라인 (Cold) Database Backup Data files Control files Parameter files Password file Redo log files 일관성있는전체 DB 백업 Oracle Database 가닫혀있는동안 DB 를구성하는모든 Datafile 과 Control file 에대해수행 이백업에는 Online Redo Log file, Parameter file 및 Password file 도포함될수있음 Normal, Transactional 또느 Immediate 옵션을사용하여 Database 를정상적으로종료한경우 Online Redo Log 파일을백업할필요는없으나백업되었으면복구가단순해짐. 장단점 개념적으로단순함 최소한의명령으로백업을수행하기쉬움 운영자상호작용이거의필요하지않음 ( 단순스크립트활용 ) 백업시 DB 를 Shutdown 해야함 II - 20
2. Backup 오프라인 Database Backup 수행 SHUTDOWN IMMEDIATE; HOST cp <files> /backup/ Data files Log files Control files Password file Parameter files 백업수행방법 STARTUP OPEN; 인스턴스정상종료후 OS utility(cp,tar 등 ) 를사용하여백업 Oracle Instance 재시작 백업수행지침 종료명령은 normal, immediate, transactional 을사용 전체 closed backup 을수행할경우초기화 parameter file 과 password file 백업 Read Only Tablespace 에연관된파일은전체백업에포함하지않아도됨 Offline(Cold) Backup 을수행하는동안 DB 가오픈될경우해당백업은유효하지않으며 Recovery 상황에서사용할수없을수있음 II - 21
2. Backup 온라인 (Hot) Database Backup Control files Data files Parameter files Password file Archived redo log files Online redo log files 온라인 Database Backup 의특징 Archive Log모드에서수행되며 Archive Log file을백업해야함 Backup중에 Database를정상적으로사용가능 ( 가용성 ) Tablespace 또는 Datafile 레벨에서수행가능 매일 24시간운영되는업무지원 II - 22
2. Backup 온라인 Database Backup 요구사항 온라인 Database Backup 요구사항 Database가 ARCHIVELOG모드로설정되어있고 Online Redo Log가 Archive 되었을때 Database 사용중에도 Tablespace 또는개별 Datafile을백업할수있음 Datafile이백업모드에있으면 Log Writer가변경된 Block에대한이미지를 Redo Log에기록하므로 Redo Log의크기및 Log Writer의성능에영향을줄수있음 II - 23
2. Backup Online Tablespace Backup 수행방법 SQL> ALTER TABLESPACE users BEGIN BACKUP; SQL>!cp /oradata/users01.dbf /BACKUP/users01.dbf SQL> ALTER TABLESPACE users END BACKUP; Tablespace Backup 을수행하는방법 ALTER TABLESPACE... BEGIN BACKUP 명령을실행하여해당 Datafile이나 Tablespace를 Backup 모드로설정한후 OS Backup 유틸리티를사용하여백업 백업이끝나면 ALTER TABLESPACE... END BACKUP 명령을실행하여일반모드로설정 Recovery에필요한 Redo가 Archive 되도록 Archive시킴 SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 백업수행시간에쌓인 Archive Log file 을백업해야함 II - 24
2. Backup Online Tablespace Backup 실패 Tablespace Backup 실패 백업도중시스템고장, Database 종료들의상황으로백업에실패한경우 OS 에서백업이완료되지않은파일은다시백업해야함 Oracle Server 는파일에백업에서 Restore 되었다고가정하므로 Database Open 실패됨 Database nomount 상태에서 ALTER DATABASE... END BACKUP 명령을사용하면해당 Datafile 은동기화정보를맞추어줌 Online Backup 종료 v$backup 을이용하여 Backup 상태를확인 SQL> select * from v$backup; FILE# STATUS CHANG# TIME ------- ------------------------ ------------ ---------- 1 NOT ACTIVE 0 2 ACTIVE 228596 30-SEP-04 Active 상태인데이터파일을종료 SQL> ALTER DATABASE datafile 2 END BACKUP; Active 상태인모든데이터파일을한번에종료하는방법 (oracle 9i) SQL> ALTER DATABASE END BACKUP; II - 25
2. Backup Control file Backup Binary 이미지생성 alter database backup controlfile to control1.bck ; 이명령을사용하면 Control file 의 Binary 복사본이생성됨 Recovery 시이복사본을이용하여복구할수있음 (using backup controlfile 옵션 ) 텍스트스크립트로생성 alter database backup controlfile to trace; 이명령을사용하면 USER_DUMP_DEST 에지정된디렉토리에 Trace file 로만들어짐 데이터베이스복구시 STARTUP NOMOUNT 후이스크립트를수행하면 Control file 이생성됨 II - 26
2. Backup Online Backup 매커니즘 Alter tablespace ts_name begin backup ; Tablespace 에속하는모든 data file 들은 hot-backup-in-progress 라고 mark 된다 Online-backup mode 에있는모든 data file 들에대해 checkpoint 가발생한다. File header 의 checkpoint SCN 은 begin backup command 를사용한 SCN 으로진행한다. 이후의 checkpoint 는 file header 에쓰여지지않는다 Online-backup mode 에있는 data file 의 block 에대해첫번째변경이일어날경우전체 block 을 logging 하기시작한다 Alter tablespace ts_name end backup ; begin backup checkpoint SCN 을가지는 redo record 를설정한다. block image 의 logging 이종료되고 data file 의 checkpoint 가 database checkpoint 까지진행한다. Online backup 시의주의사항 database 는 archive log mode 로운영중이어야한다 begin backup 과 end backup 사이에발생한모든 archived log file 도 backup 되어야한다. Online backup 이종료되면반드시 end backup 을하여 backup 이끝난 tablespace 의모든 data file 을 nobackup mode 로바꾸어주어야한다. Online backup 중에는 shutdown normal, shutdown immediate 와 backup 중인 tablespace 의 offline 은불가능하다 II - 27
2. Backup HOT backup mechanism Update Update OS block OS block OS block OS block Oracle block (2K) 2K 수 bytes redo record BACKUP mode 시의 redo log NO-BACKUP mode 시의 redo log II - 28
1. Backup & Recovery 개요 2. Backup 3. Recovery 4. Complete & Incomplete Recovery II - 29
3. Recovery Recovery 종류 Object Recovery - Data Export/Import -Index 재생성 Block Level Recovery - Instance Recovery Media Recovery - Database, Tablespace, Datafile - Read-only tablespace -Redolog - Control file II - 30
3. Recovery Block Level Recovery - 오라클의비정상상태로프로세스가강제종료될때발생된비정상적인상태의오라클메모리블록의복구 - Instance Recovery 로오라클데이터베이스에서기본적으로자동처리되는기능중하나임. - 만일오라클이트랜잭션의비정상종료나오라클인스턴스장애등으로손상된버퍼를발견하게되면, 장애발생이전의버퍼상태로복구를자동으로시도 - 운영자의특별한조작이나확인이필요없이오라클이알아서자동으로처리 - 블럭의복구는 kcrabr() 이라는오라클내부펑션이호출되어수행됨 - 프로세스가비정상종료또는취소되었을경우, 메모리상에서블럭의내용이바뀌는중이었다면이펑션의호출을통해복구가수행됨. 보통정상적인경우에는 PMON 이이것을수행하게되지만, SMON 이나서버프로세스에의해서수행될수도있음. - 이작업을위해서오라클은해당버퍼의내용을데이터파일에서읽은후, 온라인리두로그에서마지막체크포인트이후의변경사항정보를찾아서적용하게됨. 따라서블럭의복구를위해서는온라인리두로그파일과데이터파일이필요함. II - 31
3. Recovery Instance Recovery 단계 Instance Failure 후 Oracle 은자동으로 Crash Recovery 및 Instance Recovery 를수행합니다. Recovery 단계 Datafile 이동기화되지않은상태 Rollforward(Redo log 적용 ) Datafile 내 Commit 된 Data 및 Commit 되지않은 Data 상존 Database Open Commit 되지않은 Data Rollback SQL*Plus Server process PGA Locks Data buffer cache SMON DBWn Instance SGA Large pool Redo log buffer PMON CKPT Shared pool Shared SQL and PL/SQL Data dict. cache LGWR ARCn Undo 146.1 146.5 Data File file 1 146.5 146.2 RBS Undo Data Datafile File 146.5 Data file 3 146.5 146.5 Control Redo log file File file 1 Database 145 Redo log file 2 Checkpoint II - 32
3. Recovery Media Recovery 손실되거나손상된 Datafile 또는 Control File 의 Recovery - Datafile 이 Offline Normal 옵션을사용하지않고 Offline 상태가된경우 - Disk 의 H/W 장애로인한경우 명시적호출필요 - 사용자가운영체제명령으로 Backup 본을명시적으로적용시켜야합니다. 작동순서 1) Backup에서파일Restore ( 손실되거나손상된파일을복사본으로대체 ) 2) Archive 된 Redo Log File과 Online Redo Log에서 Redo 데이터를 Recover ( 대체한복사본이후에기록된변경사항을순차적으로적용하는것 ) II - 33
3. Recovery Media Recovery 단계 Online Redo Log File Archive Redo Log File RBS 2 4 DataFile Restore 된 Datafile 1 Commit / UnCommit Transaction 포함하는 Datafile 3 Recover 완성된 Datafile 5 1) 손상된파일이 Backup 에서 Restore 가완성된단계 2) Datafile 이 Backup 된시점이후부터현재까지의 Archive Redo Log File 과 Online Redo Log File 의변경사항이적용됩니다. 이과정을 Roll forward 라고합니다. (Redo 적용 ) 3) 현재이단계에서 Commit 된변경사항과 Commit 되지않은변경사항이동시에포함되어있을수있습니다. 4) Undo Segment 의정보를참조하여실제물리적 Data 는변경되었지만 Log 에는 Commit 되었다는기록이없는변경사항을기존값으로되돌립니다. 이과정을 Rollback 이라합니다. (Undo 적용 ) 5) Recovery 가완료된상태입니다. II - 34
3. Recovery Media Recovery 유형 컨트롤파일복구온라인리두로그파일복구 Datafile 복구 Tablespace 복구 Read-only Tablespace 복구전체 Database 복구 - Noarchivelog 모드에서 Recovery - Archivelog 모드에서 Recovery. Complete Recovery. Incomplete Recovery II - 35
3. Recovery Recover 명령 RECOVER DATABASE Closed Database Recovery 만사용할수있습니다. Oracle Instance는 Mount 단계이어야합니다. System Tablespace 를복구해야하는경우이명령어로만가능합니다. RECOVER DATAFILE /ORADATA/u03/user01.dbf Oracle Instance가 Open 혹은 Mount 상태일때모두가능합니다. Datafile 단위로 Recovery 합니다. RECOVER TABLESPACE USERS Oracle Instance가 Open 단계일때만사용가능합니다. (Mount 단계에서는 Tablespace에대한정보에접근할수가없으므로 ) Tablespace 단위로 Recovery 합니다. II - 36
3. Recovery Resetlogs 명령어 alter database open resetlogs Resetlogs 옵션사용시기 불완전미디어복구 (Incomplete media recovery) 백업받은컨트롤파일을이용한복구 컨트롤파일을새로생성한복구 Resetlogs 를사용시정상오픈조건 1 데이터파일호환모드는데이터베이스자체의호환모드설정보다크면안됨. ( 호환모드설정파라미터예 : compatible = 9.2.0.0.0 ) 2 오프라인 (Offline) 된파일들은온라인 (Online) 되거나 DROP되어야함. 3 파일들은동일한체크포인트 SCN을가지고있어야함. II - 37
3. Recovery Control file Recovery Control file 재생성해야하는경우 오류로인해모든 Control file이손실된경우 Database 이름을변경해야하는경우 Control file의현재설정을변경해야하는경우 Control file Recovery 방법 - 1 ( 현재 Control file 사용 ) Control file 이다중화되어있는경우현재복사본을사용하여손실된파일을 Restore Control file Recovery 방법 - 2 ( 새 Control file 생성 ) Control file 을 Trace File 로변환하여백업해놓은경우이것을이용하여생성 DBA 가직접 CREATE CONTROLFILE 명령을사용하여새파일을생성.( 이작업을수행하려면 Database 의모든파일을알고있어야함 ) Control file Recovery 방법 - 3 (Backup Control file 사용 ) RECOVER DATABASE USING BACKUP CONTROLFILE 명령을사용 ( 이방법은모든 Control file 이손실된경우필요 ) II - 38
3. Recovery Backup Control file 사용 Recovery : 예제 장애상황 - 현재시간은 2004 년 10 월 9 일 12:00 이며오전 11:45 경에 employees 테이블을포함하는 Tablespace 가 Drop 됨 - 지난밤백업본에 Control file 이포함되어있음 Recovery 방법 - 단계 1 : Database 가 Open 상태인경우정상종료시킴 - 단계 2 : 해당 Tablespace 에존재했던시점의모든 Datafile 및 Control file 을 Restore - 단계 3: Database 를 Mount 하고 v$recover_file 조회후 Offline Datafile 이존재하면 Online 전환 - 단계 4: Recovery 수행 SQL> RECOVER DATABASE UNTIL TIME 2004-10-09:11:44:00 using backup controlfile; - 단계 5: RESETLOGS 옵션을사용하여 Database 를 Open(Control file 과 Redo 의 Sync) SQL> ALTER DATABASE open resetlogs; - 단계 6: EMPLOYEES 테이블을존재확인 - 단계 7: 오전 11:44 이후에입력한모든데이터를다시입력하도록함 II - 39
3. Recovery Online Redolog file Recovery Redolog 장애감지 v$log의 invalid 및 stale상태 check alert.log 및 redo log error에관련된 background trace file error 감지 v$archive,v$log,v$logfile을통해서 current log와 archive된 log check Redolog 장애유형및조치 특정 log group내 member의장애 => 해당 log member drop후 add logfile member Inactive 상태의리두로그파일이손상되었을경우 => 해당 log group을삭제하고재생성 (shutdown후 mount 상태에서 ) Current online redo log가손상되었을경우 => 백업본을전체 Restore하고 Recovery 수행 II - 40
3. Recovery Current Redo Log file 손실 : 예제 장애상황 - 현재 Active 한 Online Redo Log file 에문제가발생하여 Background Process 가종료됨 - Database 를 Open 하려고하자 Current Redo Log Group 2 의 Log member 에러메시지가출력됨 - 현재 Active 한 Group 이므로 Archive 명령도불가능하며 CLEAR LOGFILE 명령도실행되지않음 Recovery 방법 - 단계 1 : Database 를 Mount 하고 v$log 를조회하여현재 Log Sequence Number 를기록 (61 번 ) SQL> select * from v$log; GROUP# SEQ# BYTES ARC STATUS FIRST_TIME ------------- --------- ---------- ------ ------------ ----------------- 1 60 153600 NO INACTIVE 2 61 153600 NO CURRENT - 단계 2 : 가장최근 Backup 에서모든 Datafile 을 Restore(Archive Log 도 Restore 해야함 ) - 단계 3: Redo Log 61 번까지 Recovery 수행 SQL> RECOVER DATABASE UNTIL CANCEL; - 단계 4: RESETLOGS 옵션을사용하여 Database 를 Open(Control file 과 Redo 의 Sync) SQL> ALTER DATABASE open resetlogs; II - 41
3. Recovery Recovery 할파일결정 단계 1: V$RECOVER_FILE 을통해 Recovery 가필요한 Datafile 을결정 SQL> SELECT * FROM V$RECOVER_FILE; FILE# ONLINE ONLINE_STATUS ERROR CHANGE# TIME ---- ------ ------------- ------ -------- --------- 2 OFFLINE OFFLINE 299882 22-JUL-02 단계 2: V$ARCHIVED_LOG 를통해 Database 의 Archive 된모든 Redo Log file 목록을확인 단계 3: V$RECOVERY LOG 를통해 Recovery 에필요한 Archive 된모든 Redo Log file 목록을확인 SQL> SELECT * FROM V$RECOVERY_LOG; THREAD# SEQUENCE# TIME ARCHIVE_NAME -------- ---------- -------- ---------------------------- 1 34 02-MAR-01 / /ORADATA/ARCHIVE1/arch_34.arc 1 35 03-MAR-01 / /ORADATA/ARCHIVE1/arch_35.arc 1 36 04-MAR-01 / /ORADATA/ARCHIVE1/arch_36.arc II - 42
3. Recovery Read Only Tablespace Recovery Case 1 Read-only Case 2 Read-only Read-write Case 3 Read-write Read-only Backup 1 Backup 2 Recovery Case 1 Recovery 할 Tablespace 가현재 Read only 이고마지막 Backup 을수행할당시에도 Read Only => 이경우는 Redo 정보를적용할필요없이 Backup 에서 Tablespace 를 Restore 하기만하면됨. Case 2 Recovery 할 Tablespace 가현재 Read write 상태이고마지막 Backup 은 Read Only => 이경우 Backup 에서 Tablespace 를 Restore 하고해당 Tablespace 가 Read-Write 된시점부터 Redo 정보를적용 Case 3 Recovery 할 Tablespace 가현재 Read Only 이지만마지막 Backup 은 Read-Write 상태 => Backup 에서 Tablespace 를 Restore 하고해당 Tablespace 가 Read Only 상태가된시점까지 Recovery 해야함.( 이런경우를방지하기위해 Read-only 적용후엔반드시백업을수행해야함.) II - 43
3. Recovery NOARCHIVELOG 모드에서의 Recovery NOARCHIVELOG 모드에서고려해야할점 Closed Database Backup 을통해서모든 Datafile 들과 Control File 및 Redo Log File 을 Recovery 해야합니다. 만약 Online Redo File 이재사용 (Overwrite) 되지않았다면단순히마지막 Backup 이후의 Online Redo log file 의기록만적용하여 Complete Recovery 할수있습니다. NOARCHIVELOG 모드의장점 보통 Recovery 단계가없음. 운영체제명령의 Restore 만존재하므로수행하기쉽고오류발생위험이적습니다. NOARCHIVELOG 모드의단점 데이터가필수불가결하게손실되므로현실적으로 Complete Recovery 가불가능합니다. 수동으로데이터를재입력하거나, Log Switch 를통해 Online Redo Log File 이재사용되지않았을경우에만 Complete Recovery 가능합니다. 전체 Database 가마지막완전히닫힌시점 (Closed Backup) 로 Restore 됩니다. II - 44
3. Recovery NOARCHIVE LOG 모드에서 Redo Log File Backup 이존재하는경우에따른 Recovery 146 146 146 144 144 143 146 146 Datafile Control file Database 145 Redo Log file 가장최근의 Closed Backup 에서 Restore 144 144 Datafile Control file Backup 142 Redo Log file 시나리오 - 디스크가손상되어 2 번째 Datafile 이손상되었으며, Online Redo Log File 은 2 개존재합니다. - Log Sequence number 143 에서최근 Closed Backup 이수행되었고현재 LSN 은 146 입니다. - Online Redo Log File 144 가재사용되었으므로 Datafile 을 Recovery 할수없습니다. Online Redo Log File 있는경우 - 가장최근의 Closed Backup 인 143 상태로 Datafile/Control File/Online Redo log File 을 Restore 한후 User 가수동으로그이후의현재까지의 Data 를입력해야만합니다. II - 45
3. Recovery NOARCHIVE LOG 모드에서 Redo Log File Backup이존재하지않는경우에따른 Recovery 1 146 1 1 146 146 144 144 143 1 146 1 146 Datafile Control file Database 145 Redo Log file 가장최근의 Closed Backup 에서 Restore 한후 RESETLOG 를통해 LSN 을 1 로설정 144 144 Datafile Control file Backup 142 Redo Log file Online Redo Log File 없는경우 - 가장최근의 Closed Backup 인 143 상태로 Datafile/Control File 을 Restore 한후 Oracle 에서 Online Redo Log 를재설정할수있도록다음과같이 Incomplete Recovery 를모방합니다. SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFIILE ; ( 원래필요없는절차지만 RESETLOG 옵션이 Incomplete Recovery 후만사용할수있으므로 ) - RESETLOG 옵션으로 Current Redo Log Sequence Number 를 1 로재설정합니다. SQL> ALTER DATABASE OEPN RESETLOGS ; II - 46
3. Recovery ARCHIVELOG 모드에서의 Recovery Complete Recovery Redo log 데이터와 Backup 본을사용하여가장최근시점까지갱신합니다. 모든 Redo의변경사항을적용하며데이터가손실되지않습니다. 손실된특정 Datafile만 Restore, Recovery 하면되며, Control file, Redo Log file 등은 Restore 가필요하지않습니다. 과거 Backup 시점부터현재까지의모든 Archive Log file과아직 Archive 되지않은 Transaction을포함하는 Online Redo Log file이필요합니다. Incomplete Recovery - Redo log 데이터와 Backup 본을사용하여 User 가원하는특정시점까지 Database 를갱신합니다. - 전체가아닌일부의 Redo 변경사항만을적용합니다. II - 47
3. Recovery Recover 중 Archive Redo Log File 적용 Archive 위치를변경하려는경우 1) Archive Redo Log File 이 LOG_ARCHIVE_DEST_n 디렉터리에 Restore 되지않은경우그위치를 Oracle 서버에게가르쳐줄필요가있습니다. cf> Datafile 의경우에는 ALTER DATABASE RENAME FILE 명령사용 2) ALTER SYSTEM ARCHIVE LOG 은 Control file 에새로운 Archive log 위치를갱신합니다. 3) Archive 된 Log File 을입력하라는프롬프트에위치및이름을지정합니다. 4) RECOVER FROM <LOCATION> DATABASE 명령사용합니다. SQL> RECOVER FROM <NEW LOCATION> DATABASE Archive Redo Log file 을자동으로적용하려는경우 1) Media Recovery 를시작하기전에 SET AUTORECOVERY ON 명령실행합니다. 2) Archive 된 Log File 을입력하라는프롬프트에 AUTO 입력합니다. SQL> RECOVER DATAFILE 4 ORA-00279: change 308810 07/22/02 17:00:14 needed for thread 1 ORA-00289: suggestion : /ORADATA/ARCHIVE1/arch_35.arc ORA-00280: change 308810 for thread 1 is in sequence #35 Specify log: {<RET>=suggested filename AUTO CANCEL} AUTO log applied. 3) RECOVER AUTOMATIC.. 명령을사용합니다. II - 48
1. Backup & Recovery 개요 2. Backup 3. Recovery 4. Complete & Incomplete Recovery II - 49
4. Complete & Incomplete Recovery Complete Recovery 방식 Close 상태에서 Database Recovery Database가하루 24시간일주일내내운영되는것이아닌경우 Recovery 되는파일이시스템 Tablespace 또는 Undo 세그먼트 Tablespace에속한경우 전체 Database 또는대부분의 Datafile을 Recovery해야하는경우 Open 상태에서 Database Recovery ( 장애시 Close 안된경우 ) 파일손상, 과실로인해파일손실이발생하였으나 Database 가종료되지않은경우 Database 를하루 24 시간일주일내내운영하므로 Database 의 Shutdown 을최소화해야하는경우 Recovery 되는파일이시스템 Tablespace 혹은 Undo 세그먼트 Tablespace 에속하지않은경우 Open 상태에서 Database Recovery ( 장애시 Close 된경우 ) 매체또는하드웨어고장으로인해 Oracle 이강제종료된경우 Database 를하루 24 시간일주일내내운영하므로 Database 의 Shutdown 을최소화해야하는경우 Recovery 되는파일이시스템 Tablespace 혹은 Undo 세그먼트 Tablespace 에속하지않은경우 Backup 을사용하지않는 Datafile Recovery (No Restore exits) Media Failure 또는 User 실수로인해 Backup 되지않은 Datafile 이손실된경우 파일이생성된이후의모든 Archive 된 Log 가있는경우 Recovery 되는파일이시스템 Tablespace 혹은 Undo 세그먼트 Tablespace 에속하지않은경우 II - 50
4. Complete & Incomplete Recovery Close Database Recovery: 예제 장애상황 U01 디렉토리에손상된 Block 이포함되어있고이곳에는 Datafile 1 이저장되어있음. V$DATAFILE 및 V$TABLESPACE 를통해 Datafile 1 이 SYSTEM Tablespace 에속하는파일이라는것을알았음. Recovery 방법 - Instance 가아직종료되지않았다면다음과같이 SHUTDOWN 명령을실행 SQL> SHUTDOWN ABORT - 가능하면가장최근 Backup 에서파일을 Restore UNIX> cp /BACKUP/system01.dbf /ORADATA/u01 - Mount 모드로 Instance 를시작하고 Datafile 을 Recovery SQL> STARTUP MOUNT SQL> RECOVER DATABASE ORA-00279: change 148448 07/23/02 17:04:20 needed for thread ORA-00289 : suggestion : /ORADATA/ARCHIVE1/arch_144.arc ORA-00280: change 148448 for thread 1 is in sequence #144 Log applied. - Recovery 가완료되면모든 Datafile 이동기화됨 SQL> ALTER DATABASE OPEN; II - 51
4. Complete & Incomplete Recovery Open Database Recovery ( 장애시 Open 상태 ): 예제 장애상황 Database 가현재 Open 상태이고실수로운영체제명령을사용하여 Datafile 2 를제거함. 다음명령을사용하여해당 Datafile 이속한 Tablespace 를확인하였음. SQL> SELECT file_id F#, file_name, tablespace_name, status from dba_data_files ; F# FILE_NAME TABLESPACE_NAME STATUS --- --------- ---------------- --------- 1 /disk1/data/system01.dbf SYSTEM AVAILABLE 2 /disk2/data/df2.dbf USER_DATA AVAILABLE 3 /disk1/data/rbs01.dbf RBS AVAILABLE Recovery 방법 - 해당파일을 Restore(Offline 상태가아닐때는임의로 Offline 시켜준후실행 ) UNIX> cp /disk1/backup/df2.dbf /disk2/data/ - Recover 명령을사용하여 Archive 및 Redo Log 를 Restore 된 Datafile 에적용 SQL> RECOVER DATAFILE /disk2/backup/df2.dbf 또는, SQL> RECOVER TABLESPACE user_data - Recovery 가완료되면모든 Datafile 이동기화됨. Datafile 을 Online 상태로만듦. SQL> ALTER DATABSE DATAFILE disk2/data/df2.dbf online; 또는, SQL> ALTER TABLESPACE user_data ONLINE; II - 52
4. Complete & Incomplete Recovery Open Database Recovery ( 장애시 Close 상태 ): 예제 장애상황 Datafile 2 만포함하는디스크제어장치의오류로 Media Failure 가발생하여 DB 가다운됨 Datafile 2 는시스템또는 Undo 세그먼트 Datafile 이아님. 서비스를위해일단 Database 를 Open 한후 Recovery 를하기로결정 Recovery 방법 - Database Mount. Datafile 2 를열수없으므로 Database 가열리지않음. - 해당파일을 Offline 상태로만듦.(V$DATAFILE 을질의하여파일이 Online 상태임을확인 ) SQL> ALTER DATABASE datafile /disk2/data/df2.dbf offline; SQL> ALTER DATABASE OPEN; - 이제파일을 Restore 합니다. 손상된 Disk 2 에 Restore 할수없으므로 Disk 3 을이용또한 Oracle Server 에게새로운파일위치를알려야함 UNIX> cp /disk1/backup/df2.dbf /disk3/data/ SQL> ALTER DATABASE rename file /disk2/data/df2.dbf to /disk3/data/df2.dbf - Recover 명령을사용하여 Archive 및 Redo Log 를 Restore 된 Datafile 에적용. SQL> RECOVER DATAFILE /disk3/data/df2.dbf - Recovery 가완료되면모든 Datafile 이동기화됨. Datafile 을 Online 상태로만듦. SQL> ALTER DATABASE datafile /disk3/data/df2.dbf online; II - 53
4. Complete & Incomplete Recovery Incomplete Recovery 개요 Incomplete Recovery 는장애시점이전으로 Database 를재생성함. - Disk 의 H/W 장애로인한경우이상황에서는 Recovery 시점이후의 Commit 된 Transaction 의데이터가손실되므로필요에따라이데이터를수동으로다시입력해야함 - Incomplete Recovery 는복잡하고시간이많이소요되는작업일수있음 Incomplete Recovery 를수행하려면다음이필요함 - Recovery 시점전에만들어진모든 Datafile 의적합한 Offline 또는 Online Backup - Backup 으로부터지정된 Recovery 시점까지의모든 Archive Redo Log Incomplete Recovery 는일반적으로 Complete Recovery 작업이실패한경우사용 - 최대한 Complete Recovery 를하려고노력한후불가피한상황에서만실행 II - 54
4. Complete & Incomplete Recovery Incomplete Recovery 가필요한상황 Archive Log 가손실되어 Complete Recovery 가실패한경우 - 잘못되었거나손실된 Archive Log 로인해 Complete Recovery 작업이실패한경우, 해당 Archive Log 를적용하기전의시점까지만 Recovery 를완료할수있음 Archive 되지않은모든 Online Redo Log File Datafile 이손실된경우 - Online Redo Log 를이중화하지않은상태에서 Archive 하기전에 Datafile 과함께 Online Redo Log 가손실된경우, 손실된 Redo Log 이후의시점에대해서는 Recovery 를계속할수없음 User 오류 - User 가테이블을잘못삭제했거나잘못된 WHERE 절을사용하여갱신한데이터를 Commit 한경우등. Backup Control file 을사용하여 Database 를열어야하는경우 - Control file 을이중화하지않았고 Trace File 로 Backup 해놓은것도없으며 Database 의구조도모르지만이전의 Control file Binary 복사본 Backup 이있는경우 II - 55
4. Complete & Incomplete Recovery Incomplete Recovery 의유형 Time-based Recovery - 모든변경내용이지정된시간기준의시점까지 Recovery - 데이터에대해원하지않는변경작업을수행했거나중요한테이블을삭제했으며이러한오류가발생한대략적인시간을알고있는경우 - 이중화되지않은 Online Redo Log 가훼손된대략적인시간을알고있는경우 Cancel-based Recovery - Recovery 하는도중뜨는프롬프트에 Log file 이름대신 CANCEL 을입력하면 Recovery 완료 - Recovery 과정중에훼손되지않은모든 Log File 들을최대한적용할경우사용 - Online Redo Log File 을이중화하거나 Archive Log File 을자주 Backup 하고다중화하면이러한유형의 Recovery 가불필요 Change-based Recovery - 모든변경내용이지정된 SCN(System Change Number) 까지적용된후에완료 Backup Control file 을이용한 Recovery - 모든 Control file 이손실되었으며 Control file 을재생성할수없으나 Control file 의 Binary Backup 이있는경우사용 - Database 구조가현재와달라지는시점까지불가피하게 Recovery 를해야하는경우 II - 56
4. Complete & Incomplete Recovery Incomplete Recovery 지침 모든과정을주의하여수행 - Incomplete Recovery 에서발생하는대부분의문제는 Recovery 중 DBA 의실수로인한것이므로모든 Recovery 단계를꼼꼼하게수행하는것이중요 Recovery 전후에완전 Database Backup 수행 - Recovery 실패시재시도또는롤백을위한시간절약 - 예정된다음 Backup 이수행되기전에 Recovery 가필요할경우를대비할수있음 항상 Recovery 의성공여부확인 - Recovery 에실패해서다시수행하는일이없도록하려면 User 가시스템을다시사용할수있도록하기전에문제가모두해결되었지만항상확인해야함 Archive 된 Log 를 Backup 한후제거 - 시스템에서 Archive 된 Log 를제거하여새로운 Archive 가 Recover 전시점의 Archive 와섞이는것을방지해야함 II - 57
4. Complete & Incomplete Recovery Incomplete Recovery Procedure 1) Database 종료및 Backup - Shutdown abort 로 Database 를종료한후 Recovery 시작하기전 Backup 을수행 2) Datafile Restore 3) Database Mount - Database 동기화정보가맞지않기때문에 Open이불가능 4) Datafile을장애시점이전으로 Recovery - Until cancel을사용한 Cancel-based Database Recovery SQL> RECOVER DATABASE until cancel - Until time 을사용한 Time-based Database Recovery SQL> RECOVER DATABASE until time 2004-10-01:14:20:00 - Backup Control file 을사용한 Recovery SQL> RECOVER DATABASE until time 2004-10-01:14:20:00 using backup controlfile 5) RESETLOGS 를사용하여 Database Open SQL> ALTER DATABASE OPEN RESETLOGS 6) Closed Database Backup 수행 7) 혼돈방지를위해기존 Archive log 제거 II - 58
4. Complete & Incomplete Recovery Resetlogs Resetlogs 옵션사용시기 - 불완전미디어복구 (Incomplete Media Recovery) - 백업받은컨트롤파일을이용한복구 - 컨트롤파일을새로생성한복구 Resetlogs 를사용시정상오픈조건 1 데이터파일호환모드는데이터베이스자체의호환모드설정보다크면안됨. ( 호환모드설정파라미터예 : compatible = 9.2.0.0.0 ) 2 오프라인 (Offline) 된파일들은온라인 (Online) 되거나 DROP되어야함. 3 파일들은동일한체크포인트 SCN을가지고있어야함. II - 59
4. Complete & Incomplete Recovery Time-based Recovery : 예제 장애상황 - 현재시간은 2004 년 10 월 9 일 12:00 이며 11:45 경에 emplyees 테이블이삭제됨 - 현재 Database 작업량은최소상태이고테이블을반드시 Recovery 해야함. Recovery 방법 - 단계 1 : Database 구조가오전 11:44 이후로변경되지않았으므로 UNTIL TIME 방식을사용가능 - 단계 2 : Database 가 Open 상태인경우정상종료시킴 - 단계 3 : 가장최근 Backup 에서모든 Datafile 을 Restore(Archive Log 도 Restore 해야함 ) - 단계 4: Database 를 Mount - 단계 5: Database 를 Recovery SQL> RECOVER DATABASE UNTIL TIME 2004-10-09:11:44:00 - 단계 6: RESETLOGS 옵션을사용하여 Database 를 Open(Control file 과 Redo 의 Sync) SQL> ALTER DATABASE open resetlogs; - 단계 7: EMPLOYEES 테이블을존재확인 - 단계 8: 오전 11:44 이후에입력한모든데이터를다시입력하도록함 II - 60
4. Complete & Incomplete Recovery Cancel-based Recovery : 예제 장애상황 - 현재시간은 2004 년 10 월 9 일 12:00 이며오전 11:45 경에디스크오류로 employees 테이블과 Online Redo Log file 하나도손상됨 - v$log 와 v$logfile 을조회한결과손상된 Redo Log 는시퀀스 48 번이며오전 11:34 이후의정보를포함하고있었음 (26 분동안의데이터손실 ) Recovery 방법 - 단계 1 : Database 가 Open 상태인경우정상종료시킴 - 단계 2 : 가장최근 Backup 에서모든 Datafile 을 Restore(Archive Log 도 Restore 해야함 ) - 단계 3: Database 를 Mount - 단계 4: Log Sequence Number 48 까지 Database 를 Recovery SQL> RECOVER DATABASE UNTIL CANCEL - 단계 5: RESETLOGS 옵션을사용하여 Database 를 Open(Control file 과 Redo 의 Sync) SQL> ALTER DATABASE open resetlogs; - 단계 6: EMPLOYEES 테이블을존재확인 - 단계 7: 오전 11:34 이후에입력한모든데이터를다시입력하도록함 II - 61