db backup guide

haisins

7년 ago

Backup

Database Backup의 중요성

Database Recovery가 가능한 운용

관계형 데이타베이스를 사용하는데 있어 가장 큰 장점 중의 하나는 데이타베이스에 이상 발생시 언제든지 Database Recovery를 수행하여 현재의 상황으로 복구가 가능하다는 점이다.

이러한 복구가 가능하기 위해서는 Database 관리자는 복구가 가능한 상태로 데이타베이스를 운용하여야만 합니다. 예를 들어 사용자가 NO ARCHIVE MODE상태로 운용시는 불행히도 Database를 처음 생성한 시점이나 전체 BACKUP 받은 시점으로 만이 복구가 가능합니다.

또한 BACKUP을 받는다고 할 경우에도 BACKUP을 받는 방법에 따라 현재의 시점까지의 복구가 가능하기도 하지만 그렇지 못한 경우 BACKUP을 받은 시점으로 밖에 복구가 안되는 경우도 있습니다.

일반적인 경우 BACKUP 정책없이 무작정 과다한 양의 BACKUP을 받을 경우 일정 기간이 경과하면 BACKUP에 의미가 희미해 지게 되고 정상적인 작업을 수행하지 않을때, Backup File이 꼭 필요한 경우 작업 할 수 없는 경우가 발생 할 수도 있습니다.

DATABASE 관리자는 BACKUP에 대한 정책을 수립하여 꼭 필요한 DATA를 최소의 양으로 BACKUP을 받고 최소의 시간을 소비 하면서도 항시 복구가 가능한 상태를 유지해야 합니다.

DATABASE 관리자는 BACKUP의 중요성을 확실히 인식하고 필요한 시기에 꼭 정해진 방법으로 BACKUP 작업을 수행하여 언제라도 복구가 가능한 시스템의 운용이 필요하겠습니다.

BACKUP의 효율성과 안전성

데이타베이스는 기존의 FILE SYSTEM과는 달리 전체 사용자 OBJECT를 하나의 TABLESPACE로 관리하므로 BACKUP 뿐 아니라 RECOVERY시에도 상당히 주의를 요한다. 만일 ARCHIVE LOG 상태에서 운용을 하고있는 상태에서 이상 발생시 RECOVERY 작업에 필요한 LOG FILE중 하나의 FILE이 없어지거나 사용 할 수 없는 경우에도 역시 정상적인 복구가 불가능 한 경우가 있다.

이러한 불행한 경우를 방지하기 위해서 DBA는 항시 복구가 가능한 상태로 작업하기 위한 BACKUP 정책을 수립하여 정확하게 작업하여야 할 것이다.

BACKUP 정책에 있어 가장 중요한 점은 아무 문제없이 언제든지 RECOVERY 할 수 있어야 한다는 것이다.

DBA가 어떠한 방법으로 BACKUP을 유지하느냐에 따라 RECOVERY 성공률이나 RECOVERY 속도 등이 결정된다. 물론 매일 작업 종료 후 전체 데이타베이스에 대하여 FULL BACKUP을 한다면 가장 안전한 BACKUP 이라고 볼 수 있으나 실질적으로 BACKUP을 받는데 많은 시간을 요구하므로 현실적으로는 불가능한 작업이라고 볼 수 있다.

어떻게 하면 사용자는 BACKUP에 소요되는 시간을 줄이면서 또한 어떠한 경우에도 복구가 가능한 BACKUP 작업을 하는가가 중요하다.

Database Backup Guideline

정기적으로 Full Backup을 하자.

Recovery를 위해 정기적인 Full Backup은 필수적이다. Backup의 빈도는 Data의 변화에 따라 결정된다. 즉 DML이나 DDL이 많은 Database는 자주 Backup을 받아 둔다.

Database에 구조적인 변화가 생길 때 前,後로 Full Backup을 받도록 하자.

Tablespace가새로Creation되거나 Drop될 경우
기존의Tablespace에Datafile을 Add하거나 Rename할 경우
Redo log Group 또는Member를Add, Drop, Rename할 경우

이처럼 Database의 Structure가 변경될 때 ARCHIVELOG Mode라면 ALTER DATABASE BACKUP CONTROLFILE command를 써서 최소한 Control file만이라도 Backup받는다.

NOARCHIVELOG Mode라면 Full Offline Backup을 받는다.

자주 Read-Write되는 Tablespace는 자주 Online Backup을 받는다.

ARCHIVELOG Mode라면 SYSTEM Tablespace나 Rollback Segment를 가지고 있는 Tablespace와 같이 자주 사용되는 Tablespace에 대해서는 자주 Backup을 받음으로써 Recovery시에 특히 과거 특정 시점까지의 Recovery시에 Recovery Time을 줄일 수 있다.

이전의 Backup본을 최소한 2본 이상 가지고 있을 필요가 있다.

과거 특정 시점까지의 Recovery를 할 경우 과거 특정 시점의 Backup본이 있다면 Recovery시에 Recovery Time을 최소화할 수 있다. 이때 만약 Recovery하고자 하는 시점 이후에 Database에 물리적 구조가 변경되었다면 Recovery하고자 하는 시점의 Datafile과 일치하는 Control file을 같이 Backup받음으로써 Recovery시에 같이 Recovery해야 한다.

EXPORT Utility를 써서 Backup받는다.

Export utility는 현재의 Database를 논리적으로 읽어 새로운 file로 Backup을 받는 것으로 논리적 Backup이라고 한다. Export 받은 file은 datafile이 깨졌을 경우의 Recovery를 위해 수행되는 것은 절대 아니다. 즉 Export를 사용하여 Backup받은 것은 Recovery에는 사용 될 수 없다. Export file은 다음과 같은 경우에 사용될 수 있다.

특정Table들에대한 Data의 입력 오류로 인한 과거 특정 시점으로의 회귀가 필요한 경우
특정Table Data의분실

ª 구체적인 사항은 Export & Import Utility Notes를 참조한다.

분산 Database환경에서의 Backup

분산 Database 환경의 Database는 동일한 Archived log mode에서 운영되어야 한다. 즉 분산 Database 전부가 Archived log mode 이거나 Noarchived log mode이어야 한다.

Archived log mode로 운영된다면 각 Node별로 개별적으로 Backup을 수행할 수 있다.

만약 Noarchived log mode라면 같은 시각에 동시에 Full Offline Backup이 수행되어야 한다. 예를 들어 New York에 있는 Database가 EST 24:00에 Backup을 받는다면 San Francisco에 있는 Database는 PST 21:00에 Backup을 받아야 한다.

UNRECOVERABLE로 Creation된 Object의 Backup

UNRECOVERABLE로 Creation된 Object는 Redo log file에 logging 되지 않는다. Redo log file이 생성 되지 않으므로 Archive Log mode일지라도 이 object들에 대해선 Archive되지 않는다. 고로 이 Object가 속한 Tablespace를 Hot Backup 받아 놓았을지라도 이 Object들에 대한 Recovery는 수행될 수 없다. 그러므로 UNRECOVERABLE로 Creation된 Object들에 대해서는 별도로 Backup을 받는 것이 좋다. 이러한 Object들에 대해서는 EXPORT Utility를 사용하는 것이 효과적이다.

Read-only Tablespace에 대한 Backup

Read-Only Tablespace는 처음 Creation 되었을 때 한 번 Backup을 받아두면 충분하다. 이러한 Read-Only Tablespace를 Backup받을 때 ALTER TABLESPACE BEGIN BACKUP과 END BACKUP같은 command를 쓰지 않는다. 만약 이러한 command를 사용하면 Error를 Return할 것이다. Read-Write Tablespace로 바뀔 경우에는 정상적인 Backup Procedure에 따라 Backup을 수행한다.

Backup을 위한 기본 개념

Database를 Backup을 하거나 Recovery를 하는 것은 시스템 운용 중 가장 중요한 부분이기도 하다. 그러나 기계적인 작업이라고 생각하는 경향이 있다. 결코 Backup이나 Recovery는 기계적인 작업이 아니라 고도의 훈련에 따른 가장 숙련된 작업이어야 한다.

이장에서는 Oracle에 대하여 Backup 과 Recovery 관점에서 정리해 보기로 한다. 다소 설명이 부족한 점이 있더라도 단지 Backup과 Recovery에 관한 부분만을 고려한다고 생각해야 하다.

Oracle Data Base Backup과 관련된 주요 Configuration

SGA – Redo log Buffer

SGA내부를 구성하는 요소 중 하나인 redo log buffer는 database에 변화된 항목을 저장합니다. 리두로그 버퍼에 저장된 리두 항목들은 데이타베이스 복구에 사용되는 online redo log file에 저장됩니다. Background process인 LGWR이 리두로그 버퍼 내용을 온라인 리두로그 파일에 기록한다.

Background Processor – LGWR, ARCH

Log Writer(LGWR) : Log Writer Process(LGWR)은 redo log buffer를 disk의 redo log file에 write한다. LGWR은 LGWR이 write한 마지막 시간 이후로 buffer로 copy되어진 모든redo entry들을 write한다.

Archiver(ARCH) Archiver process(ARCH)는 online redo log file이 채워진 후 지정된 저장 디바이스에 복사한다. ARCH는 redo log가 ARCHIVELOG mode일 때만 존재하며 automatic archiving이 enable된다.

Control File

데이타베이스의 컨트롤 파일에는 물리적인 데이타베이스의 구조가 기록되며 아래와 같은 형태의 정보를 갖습니다.

데이타베이스 이름

데이타베이스의 데이타 파일과 리두로그 파일의 이름과 위치

데이타베이스 생성 시간 (Time Stamp)

Oracle database의 instance가 start될 때, Control file이 사용된다. 또한 물리적인 데이타베이스 구성이 변경된다면 (즉, 새로운 데이타 파일이나 리두로그 파일이 생성되는 경우), 컨트롤 파일은 자동으로 오라클 RDBMS에 의해 변경된 내용이 수정됩니다. 또한 데이타베이스 복구가 필요 할 때도 컨트롤 파일이 사용됩니다.

Redo log File

모든 오라클 데이타베이스는 하나 이상의 리두로그 파일 세트을 갖습니다. 리두로그의 가장 중요한 기능은 모든 데이타베이스 변경 정보를 기록하는 일입니다. 모든 데이타베이스의 변경 사항은 리두로그에 저장됩니다.

만약 수정된 내용을 데이타 파일에 반영하는데 실패하더라도, 변경 사항은 리두로그에서 얻을 수 있기 때문에, 작업 내용은 결코 유실되지 않습니다.

Redo log의 정보는 system 혹은 database를 recovery하는 용도로 사용된다.

Archive File

Archive File은 online redo log file이 채워진 후 Archiver process(ARCH)에 의하여 지정된 저장 디바이스에 복사되어진 file을 말한다. Archive File은 redo log가 ARCHIVELOG mode일 때만 존재하며 system 혹인 database를 recovery하는 용도로 사용된다.

Oracle Data Base Startup

Oracle Startup은 내부적으로 3개의 과정으로 나누어 실행된다. 각각의 과정에서 작업되는 내용 및 사용되는 file은 Backup이나 Recovery시 꼭 필요한 부분이라고 할 수 있다.

SQLDBA> startup

Oracle instance startup.

Database mounted.

Database opened.

1단계 : Nomount

Oracle이 운용하는데 필요한 background process를 실행시키고 system memory내에 SGA ( system global area )를 할당한다

init$ORACLE_SID.ora file을찾는다.

Init$ORACLE_SID.ora file에는 Oracle이 startup하는데 필요한 parameter 값이 정의되어 있으므로 가장 먼저 $ORACLE_HOME/dbs/init$ORACLE_SID.ora file를 찾는다.

background process를기동한다.

init$ORACLE_SID.ora file내에 지정된 config file를 포함하여 parameter 내용을 참조하여 Oracle background process를 startup 한다.

SGA를할당받는다.

init$ORACLE_SID.ora file내에 지정된 parameter 값을 이용하여 system memory내에서 SGA를 할당 받는다.

F backup & recovery시 필요 사항

Backup & recovery시 꼭 필요한 file이 이곳에서 도출 되었다. Init$ORACLE_SID.ora와 config file은 backup시 항시 같이 backup되어야 하고 recovery시에도 유용하게 사용되는 file이다.

2단계 : database mount

init[sid] file에 지정된 control file를 읽어 모든 data file을 mount 시킨다.

control file을찾는다.

control file에는 Datafile 및 redo log file에 대한 정보 및 SCN ( system control number )이 정의되어 있다. 이 정보를 이용하여 모든 자료의 commit 시점이 동일한가를 검증한다. 만일 틀리면 redo log를 이용하여 Recover 한 후 startup한다.

data file을mount 시킨다.

Control 화일에 정의된 모든 data file을 사용하기 위하여 mount시킨다.

redo log 화일을mount 시킨다.

control화일에 정의된 redo log file을 사용하기 위하여 mount시킨다.

F 이 상태에서 중요한 몇 가지 backup, recovery, dba 작업이 가능하다.

1.전체 database의 복구가 가능하다.

2.No archive log mode를 archive log mode로 변경이 가능하다.

3.Data file의 위치나 이름의 변경이 가능하다.

4.리두 로그 파일의 추가, 삭제, 이름 변경

5.불완전한 데이터베이스 복구

3단계 : database open

마운트된 데이타베이스를 User들이 접속할 수 있도록 online log file과 data file을 open한다.

자동recovery 수행

mount된 data file등을 이용하여 비 정상적인 종료 ( shutdown abort ) 등으로 인한 data file의 SCN 불일치시 RECO process가 자동으로(즉시. consistent하게) 해당 transaction을 해결하고 recovery를 수행한다. Redo log와 rollback segment의 정보 만으로 recovery가 불가능 할 경우 media recovery를 요청한다.

data file open

모든 data file이 정상인 경우 data file을 open한다.

user 사용가능

이제부터 모든 사용자의 database access가 가능한 상태로 전환된다.

Oracle Data Base Shutdown

Oracle startup시와 반대로 수행된다.

SQLDBA> shutdown

Database closed.

Database dismounted.

ORACLE instance shutdown.

Closing Database

Database를 close 할 때 Oracle은 모든 SGA 안의 database data와 recovery data를 datafile과 redo log file에 각각 write 한다. 이 작업이 수행된 후 Oracle은 모든 online datafile과 online redo log file을 close 한다. Control file은 database가 close 된 후에도 여전히 mount 되어 open 된 상태로 남아 있는다.

특수한 상황에 open 된 database의 instance를 abort 시키고 database를 즉시 dismount 시킬 수 있다. 이 과정은 SGA buffer를 datafile과 redo log file에 기록하는 과정을 생략하므로 빠르게 수행될 수 있다. (Oracle은database를 reopen 할 때 자동으로 복구한다 – instance recovery)

Dismount database

Database를 dismount 시킨 후에는 memory 안에 instance만이 남아 있게 된다. Database가 dismount 된 후 Oracle은 database의 control file을 close한다.

Shutdown instance

Instance를 shut down 할 때 memory로부터 SGA가 제거되며 background process가 종료된다.

Archive Log

Oracle에서 Online Backup을 받거나 완벽한 Recovery 작업을 수행하기 위해서는 DataBase를 Archive log mode로 운영하여야 한다.

Oracle은 순환적으로 online redo log file을 기록한다.

첫번째 log file을 기입하고 나면 두 번째 것을 기입하기 시작하고 , 그것이 끝나면 세 번째 것을 기입하기 시작한다.

그리고 그 마지막online redo log file을 쓰고 나면 LGWR가 첫번째 log file을 덮어쓰기 시작한다

Oracle archive log mode에서 작동하고 있을 때에는 ARCH는 각각의 redo log file을 덮어쓰기 전에 그에 대한 복사본을 만든다.

이와 같이 archive된 redo log file들은 보통 device에 기록된다.

LOG 1 1 LOG 2 2 LOG 3

ARCHIVE LOG

DEST

Archive log를 활용하기 위해서는 우선 Database가 archive log mode로 설정되어있어야 한다.

NOARCHIVELOG MODE와 ARCHIVELOG MODE 비교

NOARCHIVELOG MODE

Noarchive log Mode에서는 Redo log file은 circular 방식으로 운영되고, Checkpoint가 발생한 후에 즉시 이 Redo log file을 다시 사용한다.

일단 Redo log가 덮어 쓰여지면 Media Recovery는 마지막으로 Full backup 받은 시점으로 밖에 복구가 불가능하다.

NOARCHIVELOG

Redo log file MODE

LGWR

ARCHIVELOG MODE

Checkpoint가 발생할 때 까지는 Redo log file은 재사용되지 않으며 Background process인 ARCH에 의해 물리적으로 Redo log file은 다시 Backup 된다.

Database에 발생한 가장 나중의 변화까지도 Recovery 할 수 있다.

circular fashion

ARCH ARCHIVELOG

Redo log file offline storage MODE

LGWR

ARCHIVE LOG Setting

현재 Database의 Archive 상태 보기.

SVRMGR> archive log list

Database log mode NOARCHIVELOG

Automatic archival DISABLED

Archive destination ?/dbs/arch

Oldest online log sequence 188

Next log sequence to archive 189

Current log sequence 189

Archive Log mode Setting

parameter file ( initORACLE_SID.ora )에다음을추가 정의 한다.

log_archive_start=true

log_archive_dest=/u1/oracle/admin/ORACLE_SID/arch/log

log_archive_format=%s.arc

LOG_ARCHIVE_START =

Oracle Startup시 ARCH process 가 기동한다. log switch 발생시 automatic archive를 수행한다. 만약 이 parameter가 false이면 manual archive를 실시하여야 한다.

LOG_ARCHIVE_DEST =

archive장소의 디렉토리와 확장자를 포함하지 않는 파일명을 지정한다. 여기에서 offline_log까지는 directory이며 마지막에 있는 offline은 archive log의 file initial명이다.

LOG_ARCHIVE_FORMAT=

archive file의 확장자와 log sequence번호의 형식을 지정한다. 이는 위에서 정의된 archive log의 initial file명과 함께 나타난다.

cf) 이경우 일정량의 정보가 쌓이면 /admhome/oracle/admin/ORACLE_SID/arch

directory밑에 log_001.arc, log_002.arc …같은 archive log file이 생성된다.

ORACLE database를archive log mode로변경 후 기동한다.

$ svrmgrl

SVRMGR> connect internal

SVRMGR> startup mount ==>

SVRMGR> alter database archivelog ==>

SVRMGR> archive log list ==>

Database log mode ARCHIVELOG ==>

Automatic archival ENABLED ==>

Archivedestination ?/dbs_ar/offline_log/offline

==>

Oldest online log sequence 1234 ==>

Current log sequence 1236 ==>

SVRMGR>alter database open; ==>

과 같이 DB를 startup mount만 한다.

의 Command를 이용해 archive log mode로 DB를 변경한다.

은 archive log mode로 변경되었는지를 확인하는 것이다.

는 DB가 Archive log mode임을 나타낸다. 만약 NOARCHIVELOG로 되어있으면 변경되지 않은 것을 의미한다.

는 1)의 (1) parameter를 true로 정의하였음을 나타내며 false인 경우에는 DISABLED로 나타난다.

은 1)의 (2) parameter에서 정의한 archive할 장소이다.

은 3개의 redo log중 가장 오래된 redo log의 sequence가 1234임을 의미한다.

은 현재 사용중인 redo log의 sequence가 1236임을 의미한다. 만약 이전부터 archive log mode로 운영중 이었다면 여기에서 archive log file은 log sequence 1235까지 archiving되어 있다는 것을 의미한다.

는 archive mode로 운영 가능하도록 변경 후 DB를 사용 가능하도록 open한 것이다.

archive log mode로 운영 중인 상태를 확인

SVRMGR> select log_mode from v$database;

LOG_MODE

ARCHIVELOG

archive log mode로 운영 시 log_archive_dest directory밑에 archive file은 계속해서 갯 수가 증가하므로 주기적으로 backup받고 OS상에서 삭제할 필요가 있다.

만약 file이 계속 쌓여서 disk상에 영역을 모두 사용한 경우 ORACLE이 더 이상 가동될 수 없는 상태까지 발생할 수 있다.

따라서 주기적인 OS backup을 하여 보관 해야 할 archive file의 수를 줄이는 것이 바람직하며 이는 또한 복구를 필요로 하는 경우에 복구 시간을 단축할 수 있다.

Backup의 수행

Backup을 받아야 할 중요한 file

Datafiles : 실질적인 Data가 저장되는 file이며 다음과 같다.

SQL> select name from v$datafile;

Tablespace 이름 관리 항목

SYSTEM database 레파지토리

ROLLBACK SEGMENT Rollback Segment

TEMP Sort할 임시 영역

TOOL Tool 관련 레파지토리

USER 일반 사용자 영역

기타 User Tablespace 사용자 database 내용

Redo log files : Database에 발생한 모든 변화를 기록하는 file이며 Datafile과는 별도로 적어도 2개 이상의 Redo log file을 가진다. 이 Redo log file이 갖는 가장 큰 의미는 Database의 Recovery시에 Data를 복구하는 데 가장 큰 역할을 한다.

SQL> select member from v$logfile;

Control files : 모든 Oracle Database는 Control file을 가지며 이 Control file은 물리적인 Database의 구조와 LGWR에 의해 쓰여지는 log file의 Sequence number에 관한 정보를 가진다. 이 Control file은 Redo log file처럼 Mirrored control file을 가질 수 있다.

Control file에는 Database의 이름, datafile 과 redo log file의 위치와 이름 , Database Creation 한 Timestamp 같은 내용을 기술한다.

SQL> select name from v$controlfile;

Parameter files : Oracle Instance의 환경 Parameter가 정의 되어 있는 file을 말하며 Instance가 start up 될 때 Oracle은 이 parameter file을 읽는다.

SQL> select name, value, isdefault

from v$parameter ;

Backup의 종류와 장단점

Backup의 종류

Export Backup : 운용중인 datbase의 내용을 Text file형태로 backup을 받는다. 그러나 이 file은 recovery시에는 사용 할 수 없다. 단지 backup받은 시점으로 돌아 가고자 하는 경우 사용이 가능하다. 예를 들어 월 결산 작업 완료 후, 다시 현재의 시점으로 되돌아 가기 위해서 필요한 table에 대하여 export backup을 수행한다. Export Backup의 경우 Database 전체backup뿐만 아니라, user단위, Table 단위의 backup이 가능하다.

Hot Backup : Recovery를 하기 위한 backup이지만 database가 운용중인 상태에서 backup을 수행 할 수 있다. database를 shutdown 할 수 없는 경우 Hot Backup만 충실히 받아도 database에 문제 발생시 복구하는데 전혀 문제가 없다.

Cold Backup : Database를 Shutdown한 상태에서 Database에 관련된 모든 file을 backup 받는다. Archive Log mode로 운용되고 있지 않는 경우에도 Cold backup을 받는 경우 backup 받은 시점으로의 복구가 가능하다.

여기선 간단한 도표로 기술하고 자세한 사항은 후면에서 기술하겠다.

	Backup Type	Archive log 상태	DB 상태	비 고
EXPORT Backup	* datafile, user, table별로 Backup가능	Archive log mode OR Noarchive log mode와는 무관	DB는 open 상태여야 함.	논리적 Backup
HOT Backup (Archive log backup)	* Full Backup, Partial Backup 둘 다 가능	Archive log mode로 설정 되어 있어야 함.	DB는 open 상태여야 함.	물리적 Backup
COLD Backup	* Full Backup, Partial Backup 둘 다 가능	Archive log mode OR Noarchive log mode와는 무관	DB는Shutdown 상태여야 함	물리적 Backup

Backup Type

Database를 Backup함에 있어서 Database 전체를 Backup할 것이냐 아니면 원하는 특정 file만을 Backup할 것인가의 문제가 Backup Type의 문제이다.

이러한 Backup Type에는 Full Backup과 Partial Backup 이 있다.

Full Backup : Full Backup이란 Oracle Database 와 연관된 Parameter file을 포함 하여 모든 Control file, Datafile, Redo log file을 Backup 하는 것을 말한다. 이 Full Backup에는 다시 Full Online Backup으로 하느냐 Full Offline Backup으로 하느냐의 문제가 있다.

Full Online Backup : DB가 running하고 있고 Archive log mode인 database에서 online으로 되어 있는 모든 Tablespace를 Backup 받는다.

Full Offline Backup : Oracle을 Shutdown시킨 상태에서 모든 datafile, control file, redo log file , parameter file을 위에서 열거한 3가지 Backup 방법 중 선택하여 Backup 받는다.

Partial Backup : Archive log Mode로 설정되어 있어야 한다.

Partial online Backup : DB가 running하고 있고 Archive log mode인 database에서 online으로 되어 있는 Tablespace중에서 특정된 datafile , control file을 Backup 받는다.

Partial offline Backup : offline으로 설정된 Tablespace중에서 특정된 datafile , control file을 Backup 받는다.

Cold Backup

Cold Backup (Full Offline Backup) 작업

Full Offline Backup은 Archived log mode이든 Noarchived log mode이든 상관 없이 수행될 수 있지만 주의할 점은 Full Offline Backup을 수행할 때는 반드시 Database를 NORMAL이나 IMMEDIATE Option으로 Shutdown 시켜야 하며 만약 ABORT로 Shutdown 시키고 Backup을 수행했다면 이것은 Full Offline Backup이 수행되었다고 할 수 없다. 왜냐하면 ABORT로 SHUTDOWN한 Database는 Database file들 간에 일관성을 유지하고 있다고 보기 어렵기 때문이다.

Database를IMMEDIATE나NORMAL로 SHUTDOWN한다
Host Command로Backup directory로Copy한다.
Database를STARTUP한다.

l 정상적인 shutdown이 가능한 경우

SQLDBA> connect internal

SQLDBA> shutdown normal

SQLDBA> host

$ 이 상태에서 databasefiles, controlfiles, redo log files 들을 다른 Disk나 tape device로 backup 받는다.

$ exit

SQLDBA> startup

l 정상적인 shutdown이 불가능한 경우 (편법)

SQLDBA> connect internal

SQLDBA> shutdown abort

SQLDBA> startup

SQLDBA> shutdown normal

SQLDBA> host

$ 이 상태에서 databasefiles, controlfiles, redo log files 들을 다른 Disk나 tape device로 backup 받는다.

$ exit

SQLDBA> startup

Partial Backup

Online Tablespace와 Datafile에 대한 Backup 작업

현재 Database가 정상적으로 운영 중이고 Tablespace가 Online으로 사용되고 있을 경우에 Backup 받는 것을 말하며 Hot Backup이라고도 한다. 다음과 같이 수행된다.

Backup받을datafile을V$DATAFILE or DBA_DATA_FILES 에서 확인한다.
ALTER TABLESPACE ~ BEGIN BACKUP command를실행하여 Backup을 시작 할 것임을 알려야 한다. 만약 이 command를 생략하고 Backup받은 Datafile은 Recovery할 때 전혀 도움이 되지 않고 ‘Fuzzy file’이란 Error를 Return 할 것이고 Database는 Open 되지 않을 것이다.
Host Command로Backup directory로Copy한다.
ALTER TABLESPACE ~ END BACKUP command를실행하여 Backup을 끝마쳤음을 알려야 한다.

SQLDBA> connect internal

SQLDBA> ALTER TABLESPACE user_t1 BEGIN BACKUP;

SQLDBA> host

$ 이 상태에서 user_t1에 해당하는 data file을 다른 Disk나 tape device로 backup 받는다.

$ exit

SQLDBA> ALTER TABLESPACE user_t1 END BACKUP;

SQLDBA> ALTER DATABASE BACKUP CONTROLFILE TO

‘/oracle/tmp/cntrSID.ctl’ ;

SQLDBA> ALTER DATABASE SYSTEM SWITCH LOGFILE ;

SQLDBA> EXIT

중요) 완벽한 on-line backup 시작부터 끝까지 생긴 archive log file, off-line archive log file이 동시에 존재해야 한다.

V$BACKUP

이 View는 Online Backup을 수행할 때 유용하다. V$BACKUP은 최종에 Online Backup받은 file들에 대한 정보를 가지고 있다. 즉, Hot Backup이 수행되고 있는 Tablepsace가 아직 Backup Mode로 있는지 아니면 Backup이 완료 된 상태인지 이 View를 통해 확인 할 수 있다. 만약 Online Backup(Hot Backup)을 수행 하면서 ALTER TABLESPACE ~ END BACKUP; 을 수행하지 않았 다면 STATUS가 ACTIVE로 설정되어 있을 것이다. ACTIVE 상태를 확인 했다면 해당 file을 Backup받은 후에 ALTER TABLESPACE ~ END BACKUP command를 실행하지 않은 것이므로 즉시 ALTER TABLESPACE ~ END BACKUP command 를 실행해야 한다. 그리고 STATUS가 INACTIVE라면 정상적으 로 Backup이 이루어진 상태를 의미한다.

Control file의 Backup

Archived log mode로 운영된다면 Database의 물리적인 Structure가 변경된 시점을 前,後로 Controlfile에 대해 Backup을 받는다.

ALTER DATABASE BACKUP CONTROLFILE TO ‘filename’ REUSE;

REUSE option은 기존에 Backup받은 Control file과 이름이 같을 경우 Over-write한다.

‘filename’에는 Control file 이 Backup될 곳의 full path를 기술한 다.

그리고 ALTER DATABASE BACKUP CONTROLFILE TO TRACLE command는 현재의 Database의 Structure를 검토하여 Trace file에 Control file을 새로 Creation하는 SQL command를 기록한다. 그러므로 Control file이 전부 손상된 경우와 같이 Recovery시에 새로 Control file을 Creation해야 하는 경우에 유용하다.

DB_VERIFY Utility

DB_VERIFY Command는 Database file의 유효성을 Check해주는 Utility로서 특히 Backup datafile이 Restore되기 전에 Restore될 Database file이 정상적인가를 Check할 경우에 유효하게 사용할 수 있다. 특히 Data의 Structure Integrity를 Check해 준다.

[selsp2b:/admhome/oracle/product/stage/backup/hot> dbv file=usrBACKUP.dbf blocksize=4096

DBVERIFY: Release 7.3.2.1.0 – Production on Mon Oct 21 04:48:03 1996 DBVERIFY – Verification starting : FILE = ./usrBACKUP.dbf DBVERIFY – Verification complete Total Pages examined : 2560 Total Pages Processed (Data) : 1400 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 1 Total Pages Failing (Index): 0 Total Pages Empty : 1145 Total Pages Marked Corrupt : 0

Verify Check시에 Default로 Block size를 2k로 설정하고 Check하므로 Block size가 4k라면 blocksize=4096으로 명시해야 한다.

Export & Import

EXPORT 는 DATA를 ORACLE DATABASE로부터 ORACLE Binary 형태의 OS FILE로 만들고 IMPORT를 이용하여 DATABASE로 LOADING 한다.

Export

ORACLE DATABASE를 OS file로 만드는 작업이다. 이 작업은 DATABASE가 OPEN 되어있는 동안에 실시 할 수 있다.

EXPORT MODE

Export 작업을 수행 할 수 있는 방법으로는 아래의 3가지 방법으로 작업이 가능하다.

USER 어떤 유저소유의 모든 오브젝트를

TABLES 어떤 유저소유의 모든 혹은 특정 테이블만

FULL DATABASE 데이타베이스의 모든 오브젝트를

사용 예>

TABLES=table_lists 또는

OWNER=owner_lists 또는

FULL=Y

EXPORT TYPE

Export Type은 backup되는 양에 따라 3가지 방법이 유용하다. 그러나 가능하면 많은 시간이 소요되지 않는 경우라면 Complete로 작업하는 것이 바람직하다.

COMPLETE : 전체 데이타베이스를 EXPORT 한다.

CUMULATIVE : 마지막 “COMPLETE” 혹은 “CUMULATIVE” EXPORT 이후에 변경된 정보를 EXPORT 한다.

INCREMENTAL : 마지막 “COMPLETE”,”CUMULATIVE” 혹은 “INCREMENTAL” EXPORT 이후에 변경된 정보를 EXPORT 한다.

BACKUP 방법은 매월 1 일에 “COMPLETE”, 주말에 “CUMULATIVE”, 주중에는 “INCREMENTAL”로 하면 가장 적절하다.

INCREMENTAL DAILY

CUMULATIVE WEEKLY

COMPLETE MONTHLY

Export 하기 전에는 DISK용량이 충분한지를 먼저 CHECK 만약 DISK 가 모자라면 WRITE_FAILURE ERROR가 발생한다. TABLE_SIZE는 USER_SEGMENTS view에서 볼 수 있다

주> Export시에는 CLUSTER DEFINETION이나 ROLLBACK SEGMENT의 OPTIMAL option은 Export되지 않는다.

주> SYS 소유의 object는 Export되지 않기 때문에 어떠한 object라도 SYS의 유저로 만들지 말 것

주> sequence number는 Export 도중엔 access되지 않도록 할 것

EXPORT 작업 수행

Export 작업 방법

$ exp keyword=value 형태

ex> exp SCOTT/TIGER GRANTS=Y TABLES=(EMP, DEPT, MGR)

KEYWORD 내용

USERID username/password

BUFFER size of data buffer

FILE outfile(default 는 EXPDAT.DMP)

COMPRESS import into one exetent (Y)

GRANTS export grants(Y)

INDEXES export indexes(Y)

ROWS export data rows(Y)

CONSTRAINTS export constraints(Y)

LOG log file of screen output

FULL export entire file(N)

OWNER list of owner username

TABLES list of tablename

RECORDLENGTH length of IO record

INCTYPE incremental export type

RECORD track incr.export(Y)

PARFILE parameter file name

CONSISTENT cross-table consistent

STATISTICS analyze objects(ESTIMATE)

Parameter file을 이용하는 경우

$ exp username/password PARFILE=filename

위의 OPTION들을 PARAMETER FILE안에 묶어서 간단히 지정

ex>vi filename

SYSTEM/MANAGER

FULL=Y

FILE=DBA.DMP

GRANTS=Y

INDEXES=Y

Export 작업 Test

전체 데이타베이스 EXPORT (Interactive Method)

$ exp system/manager

Connected to: ORACLE7 Server Release 7.0.16.4.0 – Production

With the procedural and distributed options

PL/SQL Release 2.0.18.1.0 – Production

Enter array fetch buffer size : 4096 >(RETURN)

Export file : expdat.dmp >

(1) E(ntire database), (2) U(sers), (3) T(ables) : (2) U > e

Export grants (Y/N) : Y > y

Export table data (Y/N) : Y > y

Compress extents (Y/N) : Y > y

About to export the entire database….

. exporting tablespace definitions

. exporting profiles

. exporting user definitions

. exporting role

. exporting rollback segment definitions

. exporting database links

. exporting sequence numbers

. exporting cluster definitions

. exporting stored procedures

. about to export SYSTEM’s tables …

. about to export SCOTT’s tables …

. exporting synonyms

. exporting views

. exporting referential integrity constraints

. exporting triggers

Export terminated successfully without warnings.

전체 데이타베이스 EXPORT (Command Line Method)

$ exp userid=system/manager full=y compress=y grants=y rows=y

전체 데이타베이스 EXPORT ( Dynamic Method )

EXPORT PARAMETERS 을 다음과 같은 FILE(tusc.par) 형태로 만든다.

system/manager

full=y

compress=y

grants=y

rows=y

$ exp parfile=tusc.par

USER only EXPORT

$ exp system/manager

Connected to: ORACLE7 Server Release 7.0.16.4.0 – Production

With the procedural and distributed options

PL/SQL Release 2.0.18.1.0 – Production

Enter array fetch buffer size : 4096 >(RETURN)

Export file : expdat.dmp >

(1) E(ntire database), (2) U(sers), (3) T(ables) : (2) U > u

Export grants (Y/N) : Y > y

Export table data (Y/N) : Y > y

Compress extents (Y/N) : Y > y

About to export specified users

User to be exported: (RETURN to quit) > scott

. exporting snapshots

. exporting snapshot log

. exporting database links

. exporting sequence numbers

. exporting cluster definitions

. exporting stored procedures

. about to export SCOTT’s tables …

. exporting synonyms

. exporting views

. exporting referential integrity constraints

. exporting triggers

Export terminated successfully without warnings.

USER only EXPORT (Command Line Method)

$ exp userid=system/manager owner=scott compress=y grants=y rows=y

USER ONLY EXPORT ( Dynamic Method )

EXPORT PARAMETERS 을 다음과 같은 FILE(tusc.par) 형태로 만든다.

system/manager

owner=scott

compress=y

grants=y

rows=y

$ exp parfile=tusc.par

TABLES EXPORT

$ exp scott/tiger tables=emp,dept compress=y grants=y rows=y

INCREMENTAL EXPORT

INCREMENTAL EXPORT 는 SYS 혹은 SYSTEM USER로서 EXPORT 한다.만일 FILE 이름을 “expdat.dmp”에서 다른 이름으로 변경하고자 할 때는 COMMAND LINE에서 FILENAME 만 지정하면 된다.

$ exp system/manager inctype=complete file=com0304.dmp

$ exp system/manager inctype=incremental file=inc0305.dmp

주의: INCREMENTAL EXPORT 데이타양은 “NEW 혹은 UPDATE” 된 TABLE의 갯 수에 따라 크게 다를 수 있다. 즉 하나의 큰 TABLE 이 매일 UPDATE 되면 항상 EXPORT 되고 UPDATE 가 안되면 FULL EXPORT 의 1% 정도 될 수 있다. 따라서 이 방법은 모든 TABLE 이 매일 UPDATE 가 발생하면 비효율적인 방법이 된다.

Export/Import Q & A

RDBMS와 Export, Import의 연관관계는 (catexp.sql 이란) ?

Export, Import시 이미 생성된 오브젝트의 정보를 데이타 딕셔너리에서 쿼리를 하는데 이러한 오브젝트의 정보가 데이타 딕셔너리내의 여러 테이블에 나누어져 있다. 필요한 데이타 딕셔너리 정보를 편리하게 이용하기 위하여 여러 가지의 뷰를 catexp.sql에 Script되어 있다. 이 스크립트화일은 $ORACLE_HOME/rdbms/admin에 있으며 Install시 수행되도록 되어 있다.

Export시 오브젝트의 백업 순서는 있는가 ?

Export하는 오브젝트의 순서는 존재하며 이는 Oracle의 Version Up등에 의한 새로운 오브젝트가 만들어지거나 하면 Export되는 오브젝트의 순서는 변할 수 있다.

오브젝트의 Export순서는 다음과 같다.

Tablespaces

Profiles

Users

Roles

System Privilege Grants

Role Grants

Default Roles

Tablespace Quotas

Resource Costs

Rollback Segments

Database Links

Sequences( includes Grants )

Snapshots ( includes grants, auditing )

Snapshot logs

Job Queues

Refresh Groups

Cluster Definitions

Tables(includes grants,column grants,comments,indexes,constraints,auditing)

Referential Integrity

POSTTABLES actions

Synonyms

Views

Stored Procedures

Triggers

Default and System Auditing

Export시 BUFFER와 RECORDLENGTH는 무엇인가?

BUFFER : Export시 오브젝트내에 있는 여러 개의 Row가 한꺼번에 Fetch된다. 디스크에서 Fetch된 정보는 화일에 Write하기 전에 메모리를 거치게 되며, 이때 할당되는 메모리의 양이 Buffer 파라미터의 값이다.

RECORDLENGTH : 메모리에 있는 Export할 자료를 화일에 Write하기 위해 한번에 운반되는 양을 결정하는 파라미터이다.

[주의] 위의 BUFFER와 RECORDLENGTH는 O/S의 Block Size의 배수가 되도록 하는 것이 효율적이다.

다량의 Row를 Export, Import시 어느 정도의 Row가 처리되었는지 알 수 있는가?

알 수 있다. V 7.1까지는 다량의 Row를 Export, Import시 처리된 정도를 알 수가 없어 현재 작업 중인지 시스템이 Hang인지 파악되지 않았으나 V 7.2부터는 FEEDBACK 이라는 옵션을 이용하여 체크가 가능하다.

Export시 한번에 몇 개의 Row가 Fetch되는가?

한번에 Fetch되는 Row의 수는 Buffer Size와 연관 관계가 있다. 하나의 Row가 Export시 차지하는 양은 각 Column Size의 합 + 4 * (Column의 수)로 구할 수 있다. 한번 Fetch 되는 Row의 수는 Buffer Size / 한 Row의 Export시 Size이다. 이를 이용하면 Export된 Output File의 Size는 대략 한 Row의 Export시 Size * Row 수 이다.

Export, Import의 호환성은 어떻게 되는가?

Export, Import의 호환성은 Oracle의 버전과 직접적인 연관 관계를 갖고 있다.

호환성은 4가지로 나누어 설명할 수 있으며 이를 아래의 가정을 이용해 설명하겠다.

가정 A라는 기계에 Oracle V 7.0, B 라는 기계에는 Oracle V 7.1이 설치되어 운영 중이라 가정하자. Oracle V7.0을 X라 하고 Oracle V7.1을 Y라고 하자.

Base Compatibility : X의exp를 이용해 X DB를 export하여 X의 imp를 이용해 X DB에 import하는 것을 말한다. 이는 당연히 지원한다.
Upward Compatibility : X의exp를 이용해 X DB를 export하여 Y DB에 Y의 imp를 이용해 import하는 것을 말한다. 이도 Oracle에서는 지원한다.
Downward Compatibility : Y exp를이용해 Y DB를 export 하여 X DB에 X의 imp로 import하는 것을 말한다. 이는 지원될 수도 안될 수도 있다.
Cross Compatibility : X exp를이용해 Y DB를 export (SQL*Net 이용)하여 X 또는 Y DB에 import(imp는 적정한 것을 활용)하는 것을 말한다. 이는 지원될 수도 안될 수도 있다.

어떤 경우에 Downward Compatibility가 실패하는가?

V7.2에 hash cluster expressions라는 옵션이 있는데, 이를 이용해서 클러스터를 생성하여 사용 후 export한 것을 V7.0 또는 V7.1로 downward시 create cluster문에 옵션이 맞지않아 실패하게 된다.

EXP-37 에러(export views not compatible with database version) 발생의 원인은 무엇인가 ?

이 에러는 Cross Compatibility에서 발생하는 문제로 이는 Export가 이용하는 View(Catexp.sql에 의해 생성된)가 Oracle Version내에 일치하지 않아 발생한 문제로 이를 해결하기 위해 Exp에서 이용 가능한 View를 설치한다.

Full Export는 Dba 권한을 갖고 있는 유저만 할 수 있는가 ?

Version 6에서는 DBA권한을 갖고 있는 이만 Full Export를 할 수 있으며, V7에서는 DBA가 아니더라도 EXP_FULL_DATABASE Role이 Grant되면 Full Export가 가능하다.

테이블 Import 시에 디폴트 테이블스페이스가 아닌 곳으로 들어가는 경우는 왜 발생하는가?

예를 들어서 scott 유저의 디폴트 테이블 스페이스가 users 인데 임포트를 해보면 tools 테이블 스페이스에 테이블이 만들어졌다고 하자. 그 이유는 다음과 같다. 즉, 임포트 하는 테이블이 원래 tools 테이블 스페이스에 있었고 scott가 현재 tools 테이블스페이스에 대한 Quota 를 가지고 있거나 아니면 Unlimited Tablespace 권한(Resource Role 에 포함)을 부여 받았기 때문이다.

Import시에 테이블을 디폴트 테이블스페이스에 만들려면 디폴트 테이블 스페이스 외의 테이블 스페이스에 대한 모든 Quota를 0로 만들고 Unlimited Tablespace 권한을 Revoke 시킨 다음에 임포트를 수행해야 한다. 그리고, 디폴트 테이블스페이스에 대한 Quota만 Unlimited로 한다. 예를 들면 다음과 같다.

$ sqlplus system/manager

SQL> alter user scott

quota 0 on system

quota 0 on tools

…….

quota 0 on data

quota unlimited on users;

SQL>revoke unlimited tablespace from scott;

이렇게 한 다음 Import를 수행하면 된다. 물론 유저를 만들 때 quota를 주지 않은 테이블스페이스는 상관 없으며 Unlimited Tablespace 권한(또는 Resource Role) 을 주지 않았다면 Revoke 명령도 사용할 필요가 없다.

Import 시에 Core Dump/Segmentation Fault 가 발생하는 경우

오라클에는 Character Set 이라고 하는 부분이 있다. 국내에서는 US7ASCII 또는 KO16KSC5601 을 주로 사용하는데 Export 받은 곳과 Import 하는 곳의 Character Set 이 다르면 Import 시에 Core Dump 가 발생하거나 원인 불명의 에러가 발생하면서 임포트가 중단되는 경우가 발생한다.

이 경우에는 Export 받은 dump file 을 convert 프로그램을 이용하여 Import 하는 곳의 Character Set으로 변환시킨 다음 임포트를 하는 방법이 있고, 아니면 어느 한 쪽 DB 의 Character Set 자체를 바꿔서 동일하게 맞춘 다음 Export/Import 하는 방법이 있다. 이중에서 Convert 프로그램을 이용하는 방법이 간단한데 이 프로그램은 Unix 상에서 cc로 컴파일 하여서 사용하면 된다. 프로그램 소스는 천리안에서 go oracle 하여 정보보물창고에서 구할 수 있다.

IMPORT시 Table과 Index를 분리하여 저장하는 방법

Export/Import를 이용하여 Data를 옮기거나 Space를 정리할 때 Table과 Index를 각각 다른 Tablespace에 분리하여 저장하기도 한다. 그러한 방법은 Oracle의 속도를 향상시키는 데 많은 도움을 준다.

Import할 때 Table과 Index를 생성시켰던 Script를 가지고 있으면 편리하다.

먼저 Import할 때 Indexes=N option을 사용하여 Table만 Import하고, Index는 Script에서 Tablespace를 지정하고 SQL file을 실행시켜서 생성하면 된다. 그러나 Index Script를 가지고 있지 않을 때는 문제가 복잡해진다.

그러한 경우에 Import Option중에서 Index file Option을 사용하여 Index script를 만들어 낼 수가 있다. 이 방법은 Index file만 만들기 때문에 속도가 빠르고, Index 뿐만이 아니라 Table Script도 만들어 지기 때문에 유용하다.

다음 작업은 Scott User의 모든 Data를 Test User로 옮기기 위해서 Export/Import를 이용하려고 한다. Import시에 Table과 Index는 Tablespace를 다르게 하여 저장한다.

다음과같이Scott User를 Export 받는다.

$ exp scott/tiger file=scott.dmp

Export받은File에서Index를 제외한 나머지만 Import한다.

$ imp system/manager file=scott.dmp fromuser=scott touser=test indexes=n commit=y

위와 같이 실행하면 Test User에는 Index를 제외한 나머지 Object만 Import된다.

그리고다음과같이 Indexfile Option을 이용하여 Index Script를 만든다.

$ imp system/manager file=scott.dmp indexfile=index.sql

위와 같이 명령을 실행하면 index.sql이라는 File이 만들어진다. 그리고 그 화일을 VI 등으로 열어서 확인해 보면 create table 문장과 create index문장이 있고 Create Table 문장은 REM으로 막혀 있어서 결과적으로 Create Index문만 실행할 수 있도록 되어 있다.

이 화일에서 Create Index문의 Tablespace만 바꾸어서 다음과 같이 SQL*Plus에서 실행시킨다.

$ sqlplus test/test

SQL> @index

이렇게 하여 Table과 Index를 다른 Tablespace로 분리하여 저장할 수 있다.

이 Indexfile option은 Index만이 아니라 Table 생성 문장이 필요할 때도 유용하게 사용하여 활용할 수 있다.

Export시에 Export File 압축하는 방법

Root에서먼저NAMED PIPE를 생성합니다.

# mknod /dev/PIPE.dmp p

Oracle Home으로login하여Export Script를 생성합니다.

$ vi compress_exp

nohup exp system/manager full=y compress=y file=/dev/PIPE.dmp &

compress < /dev/PIPE.dmp > /user/expfull.z &

Export 실행과Log 확인

$ compress_exp

$ tail – f nohup.out

Import Script 를생성합니다.

$ vi uncompress_exp –

uncompress < /user/expfull.z > /dev/PIPE.dmp &

nohup imp system/manager file=/dev/PIPE.dmp commit=y &

Import 실행과Import Log의확인

$ uncompress_exp 실행

$ tail -f nohup.out

Import

DATA IMPORT 는 EXPORT된 file을 이용하여 database를 복구하는 작업을 말한다. 항상 EXPORT 된 FILE 로만 IMPORTING이 된다.

Import 작업 Test

전체 데이타베이스 EXPORT FILE로부터 SINGLE TABLE 을 IMPORT (INTERACTIVE MODE)

$ imp system/manager

Connected to: ORACLE7 Server Release 7.0.16.4.0 – Production

With the procedural and distributed options

PL/SQL Release 2.0.18.1.0 – Production

Import file: expdat.dmp > (RETURN)

Enter insert buffer size (minimum is 4096) 30720 > (RETURN)

Export file created by EXPORT:V07.00.16

List contents of import file only (yes/no) : no > “yes” 이면 data는 import 되지않고 Display 만 됨

Ignore create errors due to object existence (yes/no) : yes > (“yes” : 만일 table이 존재하면

record 가 추가된다. “no” : 이미 존재한

Object에 대해서 import를 하지않는다.)

Import grants (yes/no) : yes >

Import table data (yes/no) : yes >

Import entire export file (yes/no) : yes > no

User name : SCOTT

Enter table name. Null list name all tables for user

Enter table name or . if done : TEST

importing SCOTT’s objects into SCOTT

importing table TEST 900 rows imported

Import terminated successfully.

주의 : IMPORT 작업은 보통 생성되는 INDEX 수에 따라 1.5 – 4 배의 시간이 걸리는데 EXPORT 는 “CREATE INDEX ….” 문만을 FILE에 쓰고 IMPORT 시에는 INDEX를 생성하기 때문이다.

전체 데이타베이스 EXPORT FILE 로부터 SINGLE TABLE 을 IMPORT (OMMAND LINE MODE)

$ imp system/manager full=n grants=y rows=y tables=test commit=y

주의 : IMPORT 시는 데이타를 DB 에 WRITE 하기 때문에 ROLLBACK SEGMENT가 사용된다. commit=y 는 row 만큼 데이타를 LOAD 하고 나서 COMMIT 을 하기 때문에 ROLLBACK SEGMENT 가 커지는 것을 피할 수 있다. commit=n 이면 TABLE 단위로 IMPORT 하고 나서 COMMIT 이 되기 때문에 ROLLBACK SEGMNET 확장 ERROR 가 발생 할 수 있다.

INCREMENTAL IMPORTING

EXPORT 된 FILE 이 다음과 같다고 하면

F : full C : cumulative I : incremental

F1, I1, I2, C1, I3, I4, C2, I5, I6

데이타베이스를다시생성한다.(CREATE DATABASE 문장을 사용)
IMPORT 하기위해충분한 ROLLBACK SEGMENT를 추가한다.
가장최근KEY 정보를 IMPORT 한다.

$ imp system/manager inctype=SYSTEM full=y file=I6

가장최근COMPLETE로 EXPORT 한 FILE 을 IMPORT 한다.

$ imp system/manager inctype=RESTORE full=y file=F1

모든CUMULATIVE IMPORT를순서적으로 실행한다.

$ imp system/manager inctype=restore full=y file=C1

$ imp system/manager inctype=restore full=y file=C2

INCREMENTAL IMPORT를순서적으로실행한다.

$ imp system/manager inctype=restore full=y file=I5

$ imp system/manager inctype=restore full=y file=I6

EXPORT 실행시 ORA-1403 조치 방법

EXPORT 실행시 ORA-1403이 발생되는 경우가 있는 데, 이 에러는 테이블 혹은 인덱스에 문제가 있는 경우 발생할 수 있다. 여기서는 ROWID를 사용하여 테이블을 복구시키는 방법을 소개한다.

기존테이블과같은 구조를 갖는 테이블을 만든다.

SQL> CREATE TABLE TEMP

AS SELECT *

FROM EMP

WHERE 1=2;

기존테이블에서RECORD를 FETCH하여 새로운 테이블에 입력. 이 때, INDEX가 설정되어 있는 COLUMN을 WHERE 조건에 부여함.

<CREATE.SQL>

declare

row_id char(18);

cursor c1 is

select rowid

from emp

where empno > 0; –empno 에 index

begin

open c1;

loop

fetch c1 into row_id;

insert into temp select * from emp

where rowid=row_id;

exit when c1%notfound;

end loop;

end;

create.sql file실행

sql> @create

Recovery

Database에 이상이 생겨 Error를 Return할 경우 Instance에 발생한 모든 Error는 Trace file로 받히고 Alert에 기록되므로 이상이 발견되면 제일 먼저 Trace file을 Check하여 Error를 확인하고 원인을 파악한다.

Recovery 작업은 발생한 failure type에 따라 다르게 수행된다.

Instance Recovery & Media Recovery

Instance Recovery

Database Instance Failure가 발생했을 때 Instance Recovery는 요구된다. Database Instance Failure는 Oracle Database Instance ( = SGA + Background process)가 작동되지 않는 상황이 발생 했을 경우를 말한다. 구체적으로 정전과 같은 경우나 여러 원인에 의한 hardware적 문제나 Operating system crash와 같은 software적 문제로 인해 발생한다. 이러한 Instance Failure에 대한 Recovery는 Oracle Parallel Server가 사용되지 않는 환경이 라면 SVRMGR>에서 STARTUP command를 수행하면 자동적으 로 복구된다.

Oracle은 Failure 발생 이후 최초로 database를 Startup 시킬 때 자동적으로 Instance를 복구한다. 먼저 Database buffer안에는 저장되어 있으나 아직 Datafile에 기록되지 않은 transaction이 완료된 (즉, commit이나 rollback이 수행된) 정보를 redo log file에 기록된 사항과 rollback segment에 기록된 사항을 참고로 하여 recovery한다. 그리고 아직 transaction을 완료시키지 못한 채 failure가 발생했다면(이 경우 이미 database buffer는 꽉 차서 Datafile에 기록했다.) background process인 SMON은 rollback segment를 뒤져 원래의 상태로 복구한다. 또한 lock이 걸려있는 상태에서 failure된 transaction은 recovery시에 lock을 푼다.

Media Recovery

Media Failure(= Disk Failure) 가 발생했을 때 Media Recovery는 요구된다. Media Failure는 Instance가 정상적으로 작동 중임에 도 file (data files , redo log files, control files)을 읽고 쓰기가 수행되지 않는 상황을 말한다. 이러한 상황은 disk head가 crash 되었을 경우 또는 Disk와는 상관없이 Database file에 이상이 생겼을 때 나타난다. 그러나 이러한 Disk head crash가 발생했 더라도 file type에 따라 (즉, data file이냐, control file이냐, redo log file 이냐에 따라) 정상적으로 read, write가 행해질 수 있다.

Data file에 영향을 미치는 Media failure는 Read error와 Write error의 2가지가 있다.

Read Error : Oracle이read error를발견한 경우에 Oracle은 Error Message를 application에 나타낸다.
Write Error : Oracle이data file에write할 수 없다는 것을 발견하게 되면 DBWR trace file에 Error Message를 보내고 자동으로 그 data file을 offline 시킨다. 그러나 그 Datafile 이 있는 Tablespace는 그대로 online을 유지한다.

그러나 만약 write가 안되는 Datafile이 SYSTEM Tablespace에 속한다면 Oracle은 그 data file을 offline시키지 않는다. 대신에 Oracle은 Error를 보내고 Database를 Shutdown시킨다. 왜냐하면 SYSTEM Tablespace에 있는 모든 Datafile은 Oracle을 운영하는데 필요한 file들이고 Data dictionary가 저장되어 있는 영역이므로 이 중 어느 하나라도 offline 상태로 된다면 Oracle 자체가 구동하지 않을 것이다.

Media Recovery는 위에서 설명했듯이 Media Failure가 발생했을 때 수행된다. Media Recovery를 수행함에 있어서 Failure가 발생하기 바로 이전 시점까지 Recovery 하는 것을 Complete Media Recovery라 하고

Recovery를 위한 기본 Step

SGA안의 Database buffer의 내용은 LRU(least-recently-used) Algorithm에 의해 Datafile에 쓰여진다. 그러므로 어떤 시점에서 보았을 때 Uncommited된 Transaction에 의해 변경된 data가 Datafile에 쓰여졌을 경우도 있고, Commited된 Transaction에 의해 변경된 Data가 아직 Datafile에 쓰여지지 않고 Database buffer에 남아있는 경우도 있다.

l Redo Log & Rolling Forward

Data의 변화를 일으키는 Transaction이 Commit되든 Uncommit되든 Database buffer에 가해진 모든 변화는 Redolog file에 기록된다. Instance failure나 Media Failure로부터 Recovery하는 첫번째 단계는 Roll-forward하는 것이다.

Roll-Forward란 Redo log file에 기록된 모든 변화를 Datafile에 적용하는 것을 말한다. 그러므로 이러한 Roll-Forward가 이루어 진 뒤에는 Datafile은 Redo log file에 기록된 Commit이 안된 변경된 Data뿐만 아니라 모든 Commit된 Data를 가지게 된다.

l Rollback Segment와 Rolling Back

Rollback Segment는 Database를 조작(DML)하는 중에 Undo되어져야 하는 Data를 가진다. Database Recovery시에 Rollback Segment는 Rolling Forward에 의해 Datafile에 적용된 모든 Uncommit된 Transaction을 Rollback시킨다. 이것이 Rolling Back이다.

다시 정리하면 Backup Datafile을 Restore한 후에 Recovery시에 는 먼저 Backup Datafile이후의 Database에 생긴 모든 변화를 기록한 Redo log file과 Archive log file을 이용하여 Rolling-Forward가 수행되고 이때 Redo log file의 Uncommit된 Transaction까지 모두 적용되어 Datafile에 쓰여진다. 그 다음에 Redo log file이 가지고 Rollback될 정보를 Rollback Segment를 가지고 있는 Datafile에 모두 적용한다. 그 다음에 이 적용된 Rollback Segment Tablespace의 Datafile을 적용하여 Datafile에 쓰여진 Undo 되어져야 하는 Uncommit Transaction을 Rollback시키게 된다..

기본적인 Recovery 단계를 그림으로 나타내면,

Redo Log

Database Redo Logs Applied Rollback Segment

Applied

Recovery에필요한2. Redo Log를 적용하여 3. Rollback Segment를

Database의 Backup본 Commit된 Data와 적용하여 Datafile에

Uncommit된 Data 모두 Write된 Uncommit 된

RESTORE Datafile에 Write된다. Transaction 을 모두

Rollback시킨다.

ROLL-FORWARD
ROLLING BACK

Complete Media Recovery & Incomplete Media Recovery

Complete Media Recovery

Complete Media Recovery는 Failure 발생 전까지의 모든 사항을 복구하는 것을 의미하며 다음의 3가지 Type으로 나눌 수 있다.

Closed Database인경우의Complete Media Recovery
Open Database-Offline Tablespace인경우의Complete Media Recovery
Open Database-Offline Tablespace-Individual Datafile인경우의Complete Media Recovery

Closed Database인 경우의 Complete Media Recovery

Closed Database인 경우란 Database에 가해진 Failure로 인해 Database의 Instance가 Terminated된 후 Open되지 않는 상태를 말하며 SYSTEM Tablespace를 구성하는 Datafile이 있는 Disk가 손상된 경우나 Active한 Rollback Segment를 포함하는 Tablespace에 손상이 발생했을 때 Database는 Close되며 이러한 경우에 다음과 같은 Complete Media Recovery 방법에 따라 Recovery한다.

SHUTDOWN ABORT한다. 만약Hardware문제가일시적으 로 발생한 것이라면 Data는 손상되지 않은 것이므로 Recovery를 위한 별도의 작업이 필요하지 않다. 그러므로 Instance를 다시 STARTUP한다.
File이영원히손상된 경우라면 Media Failure로 인해 발생 한 Datafile만 가장 최근에 Backup 받은 file을 이용해 Restore한다. 손상되지 않은 Datafile은 Restore하지 않는다.
STARTUP MOUNT한다.
ALTER DATABASE ~ DATAFILE ONLINE command를수행한다. Recover하고자 하는 Datafile은 Complete Media Recovery하는 동안에 ONLINE이어야 한다.
하나의작업으로모든 손상된 File을 Recovery하기 위해선 RECOVER DATABASE command를 사용한다. 개개의 손상 된 Datafile에 대해 Recovery하기 위해선 RECOVER DATAFILE command를 이용하여 Recovery를 수행한다. 참고로 최대의 Performance를 보장하기 위해선 Parallel Option을 사용할 수 있다.
ALTER DATABASE OPEN command를수행한다.
Recovery가정상적으로수행되었는지 Database를 Check한다.

Open Database-Offline Tablespace인 경우의 Complete Media Recovery

Open Database-Offline Tablespace인 경우란 Failure로 인해 Database에 Error가 발생했음에도 Database는 Open 상태이고 손상되지 않은 Tablespace에 대해선 여전히 Access가 가능 (ONLINE 상태)하며 다만 손상된 Tablepsace만 Offline인 상태를 말한다. Oracle은 Media Failure에 의해 Datafile이 손상을 입으면 자동으로 손상된 Datafile이 속한 Tablespace를 Offline 시킨다. 여기서 손상된 Tabelspace는 SYSTEM Tablespace가 아니며 또한 Active한 Rollback Segment를 포함하는 Tablespace도 아니다. 이러한 경우에는 다음과 같은 Complete Media Recovery 방법에 따라 Recovery한다.

Media Failure가발생한시점에 DBA가 Database를 Shutdown 시켰다면 다시 Database를 OPEN 한다. Database를 Open하면 손상된 Datafile이 속한 Tablespace는 Offline으로 나타날 것이다. Data Dictionary DBA_TABLESPACES, DBA_DATA_FILES, V$DATAFILE 등에서 STATUS를 확인할 수 있다.
손상된Datafile에대한 Backup File을 Restore한다. 손상되지 않은 다른 Datafile이나 Redo log file이나 Control file을 Restore하지 않도록 주의한다.
RECOVER TABLESPACE command를수행한다.
Recovery가완료되었으면 ALTER TABLESPACE ~ ONLINE command로 Tablespace를 ONLINE시킨다.
Recovery가정상적으로수행되었는지 Database를 Check한다.

Open Database-Offline Tablespace-Individual Datafile인 경우의 Complete Media Recovery

Open Database-Offline Tablespace-Individual Datafile인 경우란 위의 경우와 같고 Offline Tablespace 중 특정 Datafile만 손상된 경우를 말한다. Recovery 방법도 Open Database-Offline Tablespace인 경우의 Complete Media Recovery 방법과 거의 비슷하고 단지 RECOVER TABLESPACE command대신에 RECOVER DATAFILE command를 사용하여 손상된 Datafile을 Recovery하는 것이 다를 뿐이다.

Media Failure가발생한시점에 DBA가 Database를 Shutdown 시켰다면 다시 Database를 OPEN 한다. Database를 Open하면 손상된 Datafile이 속한 Tablespace는 Offline으로 나타날 것이다. Data Dictionary DBA_TABLESPACES, DBA_DATA_FILES, V$DATAFILE 등에서 STATUS를 확인할 수 있다.
손상된Datafile에대한 Backup File을 Restore한다. 손상되 지 않은 다른 Datafile이나 Redo log file이나 Control file을 Restore하지 않도록 주의한다.
RECOVER DATAFILE command를수행한다.
Recovery가완료되었으면 ALTER TABLESPACE ~ ONLINE command로 Tablespace를 ONLINE시킨다.
Recovery가정상적으로수행되었는지 Database를 Check한다.

Incomplete Media Recovery

Incomplete Media Recovery란 Media Failure의 발생으로 인한 Media Recovery의 한 방법으로 Failure가 발생하기 바로 직전까지의 복구가 아닌 그 이전의 어느 특정 시점까지 Recovery를 하는 것을 말한다. 이런 의미에서 Incomplete Media Recovery는 Media Recovery의 반대 개념이라고 할 수 있으며 간단한 그림으로 표현하면 아래와 같다.

Complete Media Recovery

Incomplete Media Recovery

Backup File Restore 특정 시점 Media Failure 발생 시점

Incomplete Media Recovery는 Database 전체에 대해서 과거 특정 시점까지 Recovery하는 것을 전제로 한다. 즉 특정 Datafile 이 손상되었다고 해서 그 손상된 Datafile만을 과거 특정 시점으로 Recovery 할 수는 없다.

Incomplete Media Recovery를 수행하는 방법에는 다음의 3가지 방법이 있으며 상황에 따라 선택하여 Incomplete Media Recovery를 수행할 수 있다.

Cancel-Based Recovery
Time-Based Recovery
Change-Based Recovery

Cancel-Based Recovery

Cancel-Based Recovery는 다음과 같이 수행한다.

Failure가발생한시점에 아직 Database가 OPEN되어 있다면 Database를 ABORT로 Shutdown한다.
Recovery하는동안발생할 지 모를 Error에 대비해 Database 전체에 대한 Full Cold Backup을 받는다.
Media Failure를야기한Hardware 문제를 해결한다.
만약현재의Control file이 Recovery하고자 하는 시점의 Database의 Control file과 일치하지 않는다면 (즉, Recovery 하고자 하는 시점 이후에 Datafile을 추가했다면) Recovery 하고자 하는 시점의 Database의 Physical file 구조를 반영 하고 있는 Control file의 Backup file을 Restore한다.
Recovery 하고자하는시점에서 가장 직전에 Backup 받은 모든 Database의 Datafile을 Restore한다. 예를 들면 Log Sequence # 40 까지 Recovery하고자 한다면 Log Sequence # 40 이 발생하기 전에 Backup 받은 Datafile을 Restore한다. 만약 Backup file이 없다면 Empty한 Datafile을 새로 만들어 Recovery할 수 있다.
STARTUP MOUNT 한다.
RECOVER DATABASE UNTIL CANCEL command를수행한다.
Incomplete Media Recovery가완료되었으면 Database를 OPEN 해야 하는 데 이때 Database를 RESETLOGS로 OPEN할 것인가 아니면 NORESETLOGS로 OPEN할 것인가 를 결정해야 한다. 즉 Log Sequence #를 다시 Reset할 것인 지 아닌지를 결정함을 의미한다.
Database를OPEN했으면원하던 시점으로 Recovery 되었는 지 Check한다.

RESETLOGS & NORESETLOGS option의 사용 기준

다음의 기준에 의해 RESETLOGS 또는 NORESETLOGS를 결정하도록 하자.

ü Recovery할 때 Control file의 Backup본을 활용한 경우(예를 들어 RECOVER DATABASE UNTIL TIME ‘………’ USING BACKUP CONTROLFILE command를 수행하여 Recovery한 경우)는 Recovery의 Type이 Complete Media Recovery이든 Incomplete Media Recovery이든 상관 없이 RESETLOGS option으로 Database를 OPEN 한다. RESETLOGS option으로 Database를 OPEN한 경우에 Message가 Alert_SID.log file에 남지만 Incomplete Media Recovery를 수행했느냐 아니면 Complete Media Recovery를 수행했느냐에 따라 Message가 다르게 생성된다.

Incomplete Media Recovery를 수행한 뒤 RESETLOGS한 경우는 다음과 같은 Message가 남는다.

RESETLOGS after incomplete recovery UNTIL CHANGE scn

Complete Media Recovery를 수행한 뒤 RESETLOGS한 경우는 다음과 같은 Message가 남는다.

RESETLOGS after complete recovery UNTIL CHANGE scn

ü 실질적으로 Incomplete Media Recovery가 수행 되었다면 RESETLOGS option으로 Database를 OPEN 한다. Incomplete Media Recovery가 수행된 경우 Alert_SID.log file에는 다음의 Message가 생성된다.

Incomplete recovery done UNTIL CHANGE scn

ü Backup Control file을 사용하지 않고 Complete Media Recovery한 경우라면 NORESETLOGS option으로 Database를 OPEN한다. Complete Media Recovery를 수행 했거나 Incomplete Media Recovery를 수행했지만 실질적으 로 Redo log file안의 모든 변화가 Recovery된 경우 (command상으로는 명시적으로 Incomplete Recovery 이지 만 실질적인 Recovery의 내용은 Complete Recovery를 한 것과 같은 경우)가 이 경우에 해당한다. 이 경우에 Alert_SID.log file에는 다음의 Message가 생성된다.

Incomplete recovery applied all redo ever generated. Recovery completed through change nnnnnnnn

ü Recovery하고자 하는 Database의 Redo log file을 Standby Database가 사용하고 있다면 RESETLOGS하면 안된다. 만약 RESETLOGS로 database를 OPEN했다면 Standby Database 를 다시 Creation해야 한다.

ü RESETLOGS로 Database를 OPEN하여 Redo log file이 reset 되었다면 Database를 NORMAL로 SHUTDOWN한 뒤 Full Offline Backup을 수행하는 것을 잊어서는 안된다. 왜냐하면 Log sequence를 reset한 후 Database가 손상을 입은 경우에 Backup본이 없다면 Reset log 이후에 Database에 발생한 변 화는 Recovery할 수 없기 때문이다. NORESETLOGS로 Database를 OPEN한 경우에는 Full Offline Backup할 필요는 없다.

ü RESETLOGS option을 사용하여 Database를 open한 경우에 는 Data dictionary와 Control file이 불일치 하는가를 확인 하기 위해 Alert_SID.log file을 Check해야 한다. 만일 Datafile이 Data dictionary에는 존재하지만 Recovery 를 거쳐 새로 생성된 Control file에는 존재하지 않을 경우 Datafile (이 경우 Datafile이 Read Only나 Offline이어야 한다.)을 Renaming함으로써 접근 가능하게 할 수 있다. 반대로 Control file에 나타난 Datafile이 Data dictionary에 나타나지 않을 경우에 Oracle은 Control file로부터 그것을 지운다.

Time-Based Recovery

Incomplete Media Recovery는 위에서 언급했듯이 과거 특정 시 점으로 Recovery하고자 할 때 사용되는 Recovery Type이며 Cancel-Based Recovery, Time-Based Recovery, Change-Based Recovery의 3가지 방법이 있고 상황에 따라 적당한 방법으로 Recovery한다. Time-Based Recovery는 다음과 같은 상황이 발생한 경우에 효과적으로 Recovery할 수 있다.

User의실수에의해 Table이 Drop되고 난 뒤 Table이 Drop된 시간을 대략 알고 있다면 DBA는 Time-Based Recovery를 적용 하여 Drop 되기 직전의 시점으로 Database를 Recovery할 수 있다.
현재사용중인 Online Redo log file의 어느 특정 부분이 System Failure로 인해 Log file안의 Data가 손상되었지만 User가 이러한 상황을 인식하지 못한 채 계속 Database를 사용하다가 시간이 어느 정도 흘러 Log Switch가 다시 이 Corrupt Data를 소유하고 있는 Log file로 Switch를 넘기려고 할 때 Instance는 Terminated 된다. 이 경우 Media Recovery가 요구되며 Corrupt data가 발생하기 직전의 시간 까지 Recovery 해야 하므로 Time-Based Recovery가 필요하 다. Corrupt Data가 발생한 이후에 그 Online Redo log file에 기록된 Valid한 Data는 Recovery 되어서는 안되므로 Time-Based Recovery가 필요하다.

위의 2가지 Case의 경우에서 Incomplete Media Recovery를 수행하기 위한 Command에서 특정 시간을 명시하거나 SCN #를 명시하여 원하는 과거 특정 시점까지 Recovery할 수 있다. 특정 시간을 명시해서 Recovery한 경우에 그 시간 바로 이전에 Commit된 Transaction까지 Recovery가 된다. 만약 SCN#를 명시해서 Recovery를 수행한 경우에는 SCN#의 Commit된 Transaction까지 Recovery된다.

Time-Based Recovery는 다음과 같은 순서로 Recovery된다.

Failure가발생한시점에 아직 Database가 OPEN되어 있다면 Database를 ABORT로 Shutdown한다.
Recovery하는동안발생할 지 모를 Error에 대비해 Database 전체에 대한 Full Cold Backup을 받는다.
Media Failure를야기한Hardware 문제를 해결한다.
만약현재의Control file이 Recovery하고자 하는 시점의 Database의 Control file과 일치하지 않는다면 (즉, Recovery 하고자 하는 시점 이후에 Datafile을 추가했다면) Recovery 하고자 하는 시점의 Database의 Physical file 구조를 반영하 고 있는 Control file의 Backup file을 Restore한다.
Recovery 하고자하는시점에서 가장 직전에 Backup 받은 모든 Database의 Datafile을 Restore한다. 예를 들면 Log Sequence # 40 까지 Recovery하고자 한다면 Log Sequence # 40 이 발생하기 전에 Backup 받은 Datafile을 Restore한다. 만약 Backup file이 없다면 Empty한 Datafile을 새로 만들어 Recovery할 수 있다.
STARTUP MOUNT 한다.
Recovery를수행하기이전에 모든 Datafile은 Online 상태 여야 한다. V$DATAFILE에서 Recovery할 Datafile을 확인해 보고 만약 Offline인 Datafile은 Online시킨다.
RECOVER DATABASE UNTIL TIME command를수행한다. Time의형식은 반드시 다음과 같은 형식으로 한다.

‘YYYY-MM-DD:HH24:MI:SS’

Database를OPEN한다. 이때RESETLOG로 OPEN할 것인지 NORESETLOGS로 OPEN할 것인지 결정한 후 이를 Command상에서 명시하여 Database를 OPEN해야 한다.
Database가정상적으로Recovery되었는지 Check한다.

Change-Based Recovery

Change-Based Recovery도 Incomplete Media Recovery의 일종으 로 다음과 같은 상황이 발생한 경우에 효과적으로 Recovery할 수 있다.

User의실수에의해 Table이 Drop되고 난 뒤 Table이 Drop된 시간을 대략 알고 있다면 DBA는 Time-Based Recovery를 적용 하여 Drop 되기 직전의 시점으로 Database를 Recovery할 수 있다.
현재사용중인 Online Redo log file의 어느 특정 부분이 System Failure로 인해 Log file안의 Data가 손상되었지만 User가 이러한 상황을 인식하지 못한 채 계속 Database를 사용하다가 시간이 어느 정도 흘러 Log Switch가 다시 이 Corrupt Data를 소유하고 있는 Log file로 Switch를 넘기려고 할 때 Instance는 Terminated 된다. 이 경우 Media Recovery가 요구되며 Corrupt data가 발생하기 직전의 시간 까지 Recovery 해야 하므로 Time-Based Recovery가 필요하 다. Corrupt Data가 발생한 이후에 그 Online Redo log file에 기록된 Valid한 Data는 Recovery 되어서는 안되므로 Time-Based Recovery가 필요하다.

Change-Based Recovery는 다음과 같은 순서로 Recovery된다.

Failure가발생한시점에 아직 Database가 OPEN되어 있다 면 Database를 ABORT로 Shutdown한다.
Recovery하는동안발생할 지 모를 Error에 대비해 Database 전체에 대한 Full Cold Backup을 받는다.
Media Failure를야기한Hardware 문제를 해결한다.
만약현재의Control file이 Recovery하고자 하는 시점의 Database의 Control file과 일치하지 않는다면 (즉, Recovery 하고자 하는 시점 이후에 Datafile을 추가했다면) Recovery 하고자 하는 시점의 Database의 Physical file 구조를 반영하 고 있는 Control file의 Backup file을 Restore한다.
Recovery 하고자하는시점에서 가장 직전에 Backup 받은 모든 Database의 Datafile을 Restore한다. 예를 들면 Log Sequence # 40 까지 Recovery하고자 한다면 Log Sequence # 40 이 발생하기 전에 Backup 받은 Datafile을 Restore한다. 만약 Backup file이 없다면 Empty한 Datafile을 새로 만들어 Recovery할 수 있다.
STARTUP MOUNT 한다.
Recovery를수행하기이전에 모든 Datafile은 Online 상태 여야 한다. V$DATAFILE에서 Recovery할 Datafile을 확인해 보고 만약 Offline인 Datafile은 Online시킨다.
RECOVER DATABASE UNTIL CHANGE command를수행한다. SCN#는 Quotation mark (‘`) 없이 10진수로 나타낸 다.
Database를OPEN한다. 이때RESETLOG로 OPEN할 것인 지 NORESETLOGS로 OPEN할 것인지 결정한 후 이를 Command상에서 명시하여 Database를 OPEN해야 한다.
Database가정상적으로Recovery되었는지 Check한다.

Incomplete Media Recovery의 Mechanism

Incomplete Media Recovery에 적용되는 Backup file은 Recovery 하고자 하는 시점 이전에 완성된 Backup file로 Restore 되어져 야 한다.

Incomplete Media Recovery를 하는 동안 사용되는 Control file은 복구하고자 하는 시점의 Database의 물리적 구조를 반영하고 있어야 한다. RESETLOGS option을 사용하여 Database를 OPEN 했거나 CREATE CONTROLFILE command를 사용한 후 에 Database를 OPEN했다면 Oracle은 현재의 Database의 Data Dictionary와 Control file을 Check하여 Database의 물리적인 구 조가 일치하지 않으면 Alert_SID.log file에 Error Message를 기록 한다. 만일 Control file에는 없는 Datafile이 Data Dictionary에 추가되어 있거나, Control file에는 Datafile의 정보가 존재하지만 현재 Data Dictionary에는 나타나지 않는다면 Oracle은 서로 일치되게끔 Control file을 수정한다.

Incomplete Media Recovery는 모든 Redo log file을 적용하는 것이 아니라 Redo log file의 일부만을 적용하여 Recovery를 완료하는 것이다. Incomplete Media Recovery는 지정한 Stop Point 까지 Recovery하는 것이며 Stop Point에 도달되었을 때 자동적으로 Recovery는 완료되는 것이다.

Incomplete Media Recovery를 하기 전에는 반드시 Offline인 Datafile은 Online으로 바꾸고 Recovery를 수행해야 한다.

Incomplete Media Recovery가 성공적으로 수행되고 난 후 Database를 OPEN 할 때에는 반드시 RESETLOGS option으로 OPEN해야 한다. RESETLOGS는 모든 Online Redo log file과 Archived Redo log file에서 현재 Redo Entry를 무효로 만들며 Log Sequence가 Reset 되고 난 후 Database의 Redo log file은 마치 방금 Creation된 것처럼 Oracle은 인식하게 되고, Online Redo log file은 어떤 Redo Entry도 포함하지 않는다.

OPS(Oracle Parallel Server)의 Recovery

Recovery from Instance Failure

Single-Node Failure

OPS로 설정된 Database 중에서 하나의 Node에서만 Instance Failure가 발생한 경우이다. 이 경우 하나의 Instance가 Failure 되면 다른 Node의 Instance의 Background Process인 SMON은 Failure가 발생한 Instance의 Redo log file을 이용해 Recovery를 수행한다. 즉 Online Redo log file에서 Instance Failure가 발생 하기 직전까지 Commit된 Transaction을 Database에 반영하는 것이다. 그리고 나서 Failure가 발생한 Instance를 STARTUP PARALLEL 한다.

SVRMGR> startup parallel

Multi-Node Failure

Parallel Server에서는 하나의 Instance라도 정상적으로 작동하고 있으면 나머지 Node에 존재하는 Instance가 모두 Failure로 죽었을지라도 다른 Instance들에 대해 Recovery를 수행한다. 만약 각 Node에 있는 모든 Instance가 Instance Failure로 죽을 경우에는 여러 Instance중에서 하나의 Instance가 Database를 OPEN한 다음에 그 Instance가 다른 Instance 모두를 Recovery한다.

Access to Datafiles for Instance Recovery

하나의 Instance가 다른 Instance를 Recovery하기 위해선 Datafile에 Access하여야 Online Redo log를 적용하여 Transaction에 대한 Recovery가 이루어질 것이다. 그러나 만약 알 수 없는 Hardware적인 문제로 인해 Datafile에 Access를 못한다면 Recovery는 이루어질 수 없고 이 경우에 Oracle은 Error Message를 Alert_SID.log에 기록하게 된다. 그러므로 이런 현상이 발생하게 되면 Datafile에 Access를 하지 못하는 원인을 일단 해결하고 난 뒤에 ALTER SYSTEM CHECK DATAFILES command를 수행한다. ALTER SYSTEM CHECK DATAFILES command를 수행해야만 SMON이 Instance에 대한 Recovery를 할 수 있다.

Recovery from Media Failure

Media Failure로 인해 Database의 구조가 손상을 입었다면 손상을 입은 Datafile들의 Backup 본을 사용하여 Recovery를 해야 한다. EXCLUSIVE Database Mode에서와 마찬가지로 Archived Redo log file을 이용하여 Recovery를 수행하며 필요하다면 Control file의 Backup본을 활용한다.

Complete Media Recovery

OPS(Oracle Parallel Server)에서의 Complete Media Recovery는 다음과 같은 방법으로 수행된다.

l OPS는 Instance는 여러 개가 존재할 수 있지만 Database는 항상 하나인 것을 기본 개념으로 하고 있다. 그러므로 Database 전체를 Recovery하거나 SYSTEM Tablespace에 대한 Recovery를 수행하기 위해선 OPS를 구성하고 있는 모든 Instance를 OPEN 상태가 아닌 MOUNT 상태로 설정해 놓고 Recovery를 수행해야 한다.

l OPS에서 SYSTEM Tablespace가 아닌 Tablespace가 손상을 입었을 경우에는 여러 Instance 중에서 실질적으로 Recovery를 수행하는 Instance에 의해 Database는 OPEN 상태로 설정되어야만 한다. 그리고 그 Recovery가 필요한 Tablespace는 Offline이어야 한다.

l Database를 구성하고 있는 Datafile들 중에서 하나의 Datafile이 손상을 입은 경우에 Recovery를 수행하기 위해서는 Database는 Datafile이 Offline인 채로 OPEN될 수 있고 그리고나서 Recovery를 수행할 수 있다. 이 경우에 하나의 Instance가 Database를 Open했다면 다른 모든 Instance도 ALTER DATABASE OPEN command로 Database를 OPEN 상태로 일치 시켜야 한다.

l 여러 Datafile 또는 여러 Tablespace가 손상을 입었을 경우에 OPS에서는 Instance별로 Datafile이나 Tablespace를 나누어 Recovery할 수 있다.

Incomplete Media Recovery

Database가 Exclusive Mode이든 Parallel Mode이든 Incomplete Media Recovery를 수행하기 위해선 Database는 MOUNT 상태여야 한다. 그리고 나서 Exclusive Database Mode에서 수행하는 것과 같이 Cancel-Based Recovery, Time-Based Recovery, Change-Based Recovery를 수행하면 된다.

Recovery Test

Environment for Test

System에 Backup과 Recovery Test를 위한 Instance를 생성.

Instance name : BACKUP Archived log mode : Archive log Mode Online redo log file은 Mirroring됨

SVRMGR> select * from v$logfile;

GROUP# MEMBER

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

1 /u02/ORACLE/BACKUP/log1BACKUP.dbf

1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf

2 /u02/ORACLE/BACKUP/log2BACKUP.dbf

2 /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf

4 rows selected.

Backup을 위한 Script 작성 (이 script는 단지 Test를 위한 것이다.)

( Hotbackup.sql => Archive log mode에서 Online Full Backup을 위한 script)

conn system/manager

alter tablespace system begin backup;

alter tablespace rbs begin backup;

alter tablespace tools begin backup ;

alter tablespace temp begin backup;

alter tablespace users begin backup;

alter database backup Control file to ‘/$ORACLE_HOME/backup/ctrl/ctrl1BACKUP.ctl’ Reuse;

!cp /u02/ORACLE/BACKUP/*.* /$ORACLE_HOME/stage/backup/hot

!cp $HOME/admin/BACKUP/arch/*.arc /u02/ORACLE/archive

exit

alter tablespace system end backup;

alter tablespace rbs end backup;

alter tablespace tools end backup;

alter tablespace temp end backup;

alter tablespace users end backup;

Physical Database file directory & Backup Directory

l Physical Database file directory

/u02/ORACLE/BACKUP

l Backup directory

/admhome/oracle/product/stage/backup/hot

l Archive log file의 Backup directory

/admhome/oracle/admin/BACKUP/arch

l Archive log file의 Physical directory

/u02/ORACLE/archive

Case 0. Full Database의Recovery

특수한 상황(여러 상황이 있겠으나 Recovery를 수행하면서 DBA의 실수로 Recovery가 실패하고 도저히 Recovery를 수행할 수 없다고 판단될 때 등)이 야기되어 Recovery에 문제가 생기 거나 Datafile 전부가 손상을 입었을 경우에는 Full Database Recovery를 수행한다.

Backup 받은모든file을 Restore한다.

$ cp $ORACLE_HOME/stage/backup/hot/*.* /u02/ORACLE/BACKUP

Database를ABORT로Shutdown한다.

SVRMGR> shutdown abort

ORACLE instance shut down.

STARTUP MOUNT한다.

SVRMGR> startup

ORACLE instance started.

Database mounted.

Database를Recovery한다.

SVRMGR> recover database ;

Media recovery complete.

Database를OPEN한다.

SVRMGR> alter database open;

Statement processed.

Case 1. Datafile의 Recovery

SYSTEM Tablespace가 아닌 Tablespace의 Datafile이 손상되어 Recovery를 수행해야 할 경우에 Error Message가 달리 Return될 경우가 있다. 이 경우에 Error Message에 따라 1-1 ~ 1-4 까지 해당되는 부분을 참조하여 Recovery한다.

1-1. SYSTEM Tablespace Datafile이 아닌 Datafile의 Recovery 1

ORA-1116, ORA-1110, ORA-736 8을 Return하는 경우에는 아래의 Recovery 수행 방법을 통해 Recovery한다.

oerr ora 1116

01116, 00000, “error in opening database file %s”

*Cause: Usually the file is not accessible.

*Action: Restore the database file.

oerr ora 1110

01110, 00000, “data file %s: ‘%s'”

*Cause: Reporting file name for details of another error

*Action: See associated error message

oerr ora 7368

07368, 00000, “sfofi: open error, unable to open database file.”

*Cause: Open system call returned an error.

*Action: Check errno. Verify existence, and permissions on database files.

현상 및 Error 내용

SQL> insert into bonus

values(‘EEEE’,’EEEE’,99999,999);

insert into bonus

ERROR at line 1:

ORA-01116: error in opening database file 5

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

ORA-07368: sfofi: open error, unable to open database file.

IBM AIX RISC System/6000 Error: 2: No such file or directory

위와 같은 Error가 Return 될 것이다. 그러나 위와 같이 Datafile 이 손상을 입었음에도 Error를 바로 Return하지 않고 정상적으 로 DML이나 DDL을 사용할 수 있을 지도 모른다. 왜냐하면 아직 SGA의 Database buffer안에 Object들이 존재하는 경우는 DBWR가 Datafile에 Database buffer의 내용을 write하기 전까지 는 Error 없이 정상적으로 작업을 수행할 것이며 Datafile에 write하려는 순간에야 비로서 Error를 Return 할 것이다.

Recovery 수행 방법

V$DATAFILE에서Datafile을Check한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME —– ——- ——— ——- ————– 1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 0 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

Physical한storage directory를Check해본다.

$ ls

ctrl1BACKUP.ctl log1BACKUP.dbf log2_m_BACKUP.dbf tempBACKUP.dbf

ctrl2BACKUP.ctl log1_m_BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf

ctrl3BACKUP.ctl log2BACKUP.dbf systBACKUP.dbf

ABORT Option으로SHUTDOWN 한다.

SVRMGR> shutdown ABORT

ORACLE instance shut down.

Datafile이손상되었음을확인했으면 Online으로 Backup받은 해당 Datafile을 host command로 COPY한다.

$ cp /admhome/oracle/product/stage/backup/hot/ usrBACKUP.dbf /u02/ORACLE/BACKUP

$ ls -l

-rw-r—– 1 oracle dba 10489856 Oct 17 15:48 usrBACKUP.dbf

STARTUP MOUNT한다. Database를Open까지하려하면 ORA-1113 Error를 Return할 것이다.

SVRMGR> startup

ORACLE instance started.

Database mounted.

ORA-01113: file 5 needs media recovery

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

V$DATAFILE에서Datafile이ONLINE 상태인지 확인한다. 만약 OFFLINE이라면 ALTER DATABASE DATAFILE ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’ ONLINE ; 을 수행한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

손상된Datafile을RECOVER DATAFILE Command로 Recovery한다.

SVRMGR> recover Datafile ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’;

ORA-00279: Change 6716 generated at 10/15/96 15:58:38 needed for thread 1

ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_49.arc

ORA-00280: Change 6716 for thread 1 is in sequence #49

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

auto

Log applied.

Physical directory에 Restore된 Datafile을 Archive log를 적용하여 Error가 발생했던 시점까지 Recovery 한다. 이때 Archive log를 적용함에 있어서 AUTO라고 명시적으로 기술해주면 자동으로 Recovery에 필요한 모든 Archive log를 적용한다.

Database를OPEN한다.

SVRMGR> alter database open;

Statement processed.

V$DATAFILE에서Datafile의상태를 Check한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

마지막으로SQLPLUS로들어가 data가 복구되었는지 확인한다.

1- 2. SYSTEM Tablespace Datafile이 아닌 Datafile의 Recovery 2

ORA-1578, ORA-1110을 Return하는 경우에는 아래의 Recovery 수행 방법을 통해 Recovery한다.

oerr ora 1578

01578, 00000, “ORACLE data block corrupted (file # %s, block # %s)”

*Cause: The data block indicated was corrupted mostly due to software errors.

*Action: Try to restore the segment containing the block indicated. This may involve dropping the segment and recreating it. If there is a trace file, report the errors in it to your ORACLE representative.

oerr ora 1110

01110, 00000, “data file %s: ‘%s'”

*Cause: Reporting file name for details of another error

*Action: See associated error message

현상 및 Error 내용

SQL> select * from bonus;

ERROR:

ORA-01578:ORACLE data block corrupted(file #5, block # 13)

ORA-01110:data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

no rows selected

위에서 알 수 있듯이 Datafile의 1개 Block이 손상되었다. 이 경우에도 Datafile이 손상을 입었음에도 Error(ORA-1578)를 바로 Return하지 않고 정상적으로 DML이나 DDL을 사용할 수 있을 지도 모른다. 아직 SGA안에 있는 Object들이 있기 때문이다. 그러나 손상된 Block(Blocksize=4096)에 있는 Data에 대해 Access 하려하면 위와 같은 Error를 Return 할 것이다.

Recovery 수행 방법

일단V$DATAFILE을확인해본다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

Physical한storage directory를Check해본다.

$ ls -l

rw-r—– 1 oracle dba 52432896 Oct 17 17:53 usrBACKUP.dbf

확인해 보면 Datafile은 그대로 존재한다.

ABORT Option으로Shutdown 한다.

SVRMGR> shutdown ABORT

ORACLE instance shut down.

이 경우에 NORMAL이나 IMMEDIATE로 Shutdown하려하면 다음과 같은 Error가 발생할 것이다.

ORA-01122: database file 5 failed verification check

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

ORA-01208: data file is an old version – not accessing current version

SVRMGR> !oerr ora 1122

01122, 00000, “database file %s failed verification check”

*Cause: The information in this file is inconsistent with information from the control file. See accompanying message for reason.

*Action: Make certain that the db files and control files are the correct files for this database.

Datafile이손상되었음을확인했으면 Online으로 Backup받은 해당 Datafile을 host command로 COPY한다.

$ cp /admhome/oracle/product/stage/backup/hot/ usrBACKUP.dbf /u02/ORACLE/BACKUP

$ ls -l

-rw-r—– 1 oracle dba 10489856 Oct 17 15:48 usrBACKUP.dbf

STARTUP MOUNT한다. Database를Open까지 하려하면 ORA-1113 Error를 Return할 것이다.

SVRMGR> startup

ORACLE instance started.

Database mounted.

ORA-01113: file 5 needs media recovery

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

V$DATAFILE에서Datafile이ONLINE 상태인지 확인한다. 만약 OFFLINE이라면 ALTER DATABASE DATAFILE ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’ ONLINE ; 을 수행한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

손상된Datafile을RECOVER DATAFILE command로 Recovery한다.

SVRMGR> recover Datafile ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’;

ORA-00279: Change 6890 generated at 10/17/96 16:25:37 needed for thread 1

ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_76.arc

ORA-00280: Change 6890 for thread 1 is in sequence #76

ORA-00278: Logfile ‘/admhome/oracle/admin/BACKUP/arch/arch_75.arc’ no longer needed fy

Log applied.

Media recovery complete.

Database를OPEN한다.

SVRMGR> alter database open;

Statement processed.

V$DATAFILE에서Datafile의상태를 Check한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

마지막으로SQL*PLUS로들어가 data가 복구되었는지 확인한다.

1-3. SYSTEM Tablespace Datafile이 아닌 Datafile의 Recovery 3

ORA-376, ORA-1110을 Return 하는 경우에는 아래의 Recovery 절차를 통해 수행한다.

oerr ora 376

00376, 00000, “file %s cannot be read at this time”

*Cause: attempting to read from a file that is not readable. Most likely the file is offline.

*Action: Check the state of the file. Bring it online

oerr ora 1110

01110, 00000, “data file %s: ‘%s'”

*Cause: Reporting file name for details of another error

*Action: See associated error message

현상 및 Error 내용

SQL> insert into bonus

2 values (‘MMMMMM’,’JJJJJJ’,999999,888888);

1 row created.

SQL> /

insert into bonus

ERROR at line 1:

ORA-00376: file 5 cannot be read at this time

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

위 Error를 보면 Datafile이 손상되었음을 알 수 있다. 현재 이 Datafile은 알 수 없는 손상으로 인해 ORACLE에 의해 내부적으로 Offline되었고 V$DATAFILE에서 Datafile의 Status를 보면 RECOVER로 나타남을 보게 될 것이다.

이처럼 ORA-376같은 Error가 발생하면 다음과 같이 복구한다.

Recovery 수행 방법

V$DATAFILE을확인해본다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 RECOVER READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

정상적인Datafile을Restore한다.

$ cp /admhome/oracle/product/stage/backup/hot/ usr* /u02/ORACLE/BACKUP

$ ls -l

-rw-r—– 1 oracle dba 10489856 Oct 17 19:21 usrBACKUP.dbf

Recovery 하기 전에 다른 Datafile의 복구 과정처럼 Shutdown을 하지 않고 OPEN 상태에서 Recovery가 가능하다.

SVRMGR>Recover Tablespace users;

또는 Recover Datafile ‘/u02/ORACLE/BACKUP;

ORA-00279: Change 6716 generated at 10/15/96 15:58:38 needed for thread 1

ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_49.arc

ORA-00280: Change 6716 for thread 1 is in sequence #49

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

auto

Log applied.

Media recovery complete.

Datafile의상태를확인한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 OFFLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

위에서와 같이 Recovery가 성공적으로 끝난 Datafile은 Status가 OFFLINE으로 나타난다. 고로 이 상태에서 Table에 대해 access 하려하면 맨 처음 Datafile이 손상되었을 때에 나타난 Error와 똑같은 Error가 Return될 것이다. 그렇다고 Recovery가 실패한 것은 절대 아니다. 이러한 Error가 나타나는 것은 V$DATAFILE 에서 보듯이 Recovery된 Datafile이 OFFLINE 되어 있기 때문이 다. 그러므로 ALTER DATABASE DATAFILE filename ONLINE command를 사용하여 Tablespace를 ONLINE으로 변경시켜야 Table에 대한 access가 가능할 것이다.

SQL> select * from bonus;

ERROR:

ORA-00376: file 5 cannot be read at this time

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

Tablespace를ONLINE으로변경한다.

SVRMGR> alter database Datafile ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’ online;

Statement processed.

1-4. SYSTEM Tablespace Datafile의 Recovery

SYSTEM Tablespace의 Datafile이 손상을 입었을 경우에는 Error 가 2가지 Type으로 나타난다. ORA-604, ORA-1116, ORA-7368을 Return하는 경우와 ORA-1092가 나타나는 경우이다. 아래의 Recovery 수행 방법을 통해 Recovery한다.

oerr ora 604

00604, 00000, “error occurred at recursive SQL level %s”

*Cause: An error occurred while processing a recursive SQL statement(a statement applying to internal dictionary tables).

*Action: If the situation described in the next error on the stack can be corrected, do so; otherwise contact Oracle Support.

oerr ora 1116

01116, 00000, “error in opening database file %s”

*Cause: Usually the file is not accessible.

*Action: Restore the database file.

oerr ora 1092

01092, 00000, “ORACLE instance terminated. Disconnection forced”

*Cause: The instance this process was connected to was terminated abnormally, probably via a shutdown abort. This process

was forced to disconnect from the instance.

*Action: When instance has been restarted, retry action.

현상 및 Error 내용

SQL> insert into bonus

2 values(‘EEEE’,’EEEE’,99999,999);

1 row created.

SQL> /

insert into bonus

ERROR:

ORA-00604: error occurred at recursive SQL level 1

ORA-01116: error in opening database file 1

ORA-01110: data file 1: ‘/u02/ORACLE/BACKUP/systBACKUP.dbf’

ORA-07368: sfofi: open error, unable to open database file.

IBM AIX RISC System/6000 Error: 2: No such file or directory

위와 같은 Error가 Return 될 것이다. 그러나 위와 같이 SYSTEM Tablespace의 Datafile이 손상을 입었음에도 Error를 바로 Return하지 않고 정상적으로 DML을 사용할 수 있을 지도 모른다. 기본적으로 ORACLE은 Data를 Block단위로 access하 여 SGA의 Database Buffer에 올려 놓고 Data에 대한 변화를 작 업 한다. 현재 Recovery test를 위한 Instance인 BACKUP은 ‘BLOCK_SIZE = 4096’으로 설정되어 Creation 되어 있으므로 하 나의 Table을 Select했을지라도 그 Table이 있는 Block과 그 Table이 참조하는 Data Dictionary를 같이 Database Buffer와 Data Dictionary Cache에 올린다. 그러므로 현재 SGA안에 올려 진 Data Dictionary를 Access하려하면 System Tablespace Datafile이 없음에도 Dictionary를 볼 수 있지만 만약 아직 SGA 의 Dictionary Cache에 올라와 있지 않은 Dictionary를 Access 하려하거나 특정 시점(Dictionary Cache의 것을 SYSTEM Tablespace Datafile에 Write하려 할 때)에 도달하면 위와 같은 Error를 Return 할 것이다. Error Message가 다음과 같이 Return 되더라도 다음의 Action에 따라 Recovery를 수행한다.

SQL> insert into bonus

2 values(‘EEEEEEE’,’EEEEEE’,888888,8888888);

insert into bonus

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-01578: ORACLE data block corrupted (file # 1, block # 259)

ORA-01110: data file 1: ‘/u02/ORACLE/BACKUP/systBACKUP.dbf’

또는

SQL> /

insert into bonus

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

Recovery 수행 방법

V$DATAFILE에서Datafile을Check한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

Physical한Storage directory를Check해본다.

$ ls /u02/ORACLE/BACKUP

ctrl1BACKUP.ctl log1BACKUP.dbf log2_m_BACKUP.dbf tempBACKUP.dbf

ctrl2BACKUP.ctl log1_m_BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf

ctrl3BACKUP.ctl log2BACKUP.dbf

ABORT Option으로Shutdown 한다.

SVRMGR> shutdown

ORACLE instance shut down.

이 경우에 NORMAL이나 IMMEDIATE로 SHUTDOWN하려하면 다음과 같은 Error가 발생할 것이다.

ORA-01122: database file 5 failed verification check

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

ORA-01208: data file is an old version – not accessing current version

SVRMGR> !oerr ora 1122

01122, 00000, “database file %s failed verification check”

*Cause: The information in this file is inconsistent with informationfrom the control file. See accompanying message for reason.

*Action: Make certain that the db files and control files are the correct files for this database.

Datafile이손상되었음을확인했으면 Online으로 Backup받은 해당 Datafile을 host command로 COPY한다.

$ cp /admhome/oracle/product/stage/backup/hot/ systBACKUP.dbf /u02/ORACLE/BACKUP

$ ls -l

-rw-r—– 1 oracle dba 20971520 Oct 17 15:48 systBACKUP.dbf

STARTUP MOUNT한다. Database를Open까지하려하면 ORA-1113 Error를 Return할 것이다.

SVRMGR> startup

ORACLE instance started.

Database mounted.

ORA-01113: file 5 needs media recovery

ORA-01110: data file 5: ‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’

손상된Datafile을RECOVER DATAFILE command로 Recovery한다.

SVRMGR> recover Datafile ‘/u02/ORACLE/BACKUP/systBACKUP.dbf’;

ORA-00279: Change 6716 generated at 10/15/96 15:58:38 needed for thread 1

ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_49.arc

ORA-00280: Change 6716 for thread 1 is in sequence #49

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

auto

Log applied.

Database를OPEN한다.

SVRMGR> alter database open;

Statement processed.

V$DATAFILE에서Datafile의상태를 Check한다.

SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME

2> from v$Datafile;

FILE# STATUS ENABLED BYTES NAME

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

1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf

2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf

3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf

4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf

5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf

5 rows selected.

마지막으로SQLPLUS로들어가 data가 복구되었는지 확인한다.

Case 2. Control file의 Recovery

2-1. Mirrored 되는Control file 전부가 손상된 경우의 Recovery

oerr ora 210

00210, 00000, “cannot open control file ‘%s'”

*Cause: Cannot open the control file

*Action: Check to make sure the control file is there and not locked by some other program

현상 및 Error 내용

SQL> alter tablespace users add Datafile ‘/u02/ORACLE/BACKUP/usr2BACKUP.dbf’;

alter tablespace users add Datafile ‘/u02/ORACLE/BACKUP/usr2BACKUP.dbf’

ERROR at line 1:

ORA-00210: cannot open control file ‘/u02/ORACLE/BACKUP/ctrl1BACKUP.ctl’

ORA-07368: sfofi: open error, unable to open database file.

IBM AIX RISC System/6000 Error: 2: No such file or directory

“Mirroring이 되고 있든 아니든 간에 Control file이 손상을 입었다면 Database는 Background process가 Control file에 처음으로 access 하는 시점까지는 정상적으로 운영된다. 그러나 이 시점( Database의 물리적인 구조를 변경시키는 작업, 즉 Database file을 추가하거나 삭제하는 작업을 하려하는 시점)에 도달하면 ORACLE은 Database와 Instance를 강제로 terminate 시킨다.

일단 Oracle에 의해 강제로 terminated 된 후에는 Control file이 Recovery되기 전까지는 Database를 OPEN 할 수 없으며 MOUNT할 수도 없다. ”라고 ORACLE 7.3 Manual Admin Guide 24-53에는 기술되어 있지만 실제 Test한 바로는 Oracle은 terminate 되지 않았고 단지 아래와 같은 Error만을 Return할 뿐이었다. 참고로 아래의 Recovery 과정은 Test한 결과를 바탕으로 기술한 것이다.

Control file은 Database의 물리적인 구조에 관한 정보를 가지고 있다. 만약 Database의 물리적인 구성요소인 Database Datafile , 즉 Datafile이나 redo log file이 추가될 경우 Database의 변화를 반영하기 위해 ORACLE은 Control file에 Database의 변경된 사항을 기록한다.

그러므로 이 Control file이 손상을 입었을 경우에 특정 Tablespace에 Datafile을 추가하려 하면 ORACLE은 Control file 을 변경하려고 시도하지만 Control file이 사라졌기 때문에 Database 의 변경 사항을 기록할 수 없고 Error(ORA-210)를 Return 할 것 이다.

Recovery 수행 방법

위의Error(ORA-210)에서와같이 Control file에 손상이 가해졌음을 알 수 있듯이 실제 Physical한 Storage directory에서 Control file의 변화를 확인해본다.

$ls /u02/ORACLE/BACKUP

log1_m_BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf

log2BACKUP.dbf systBACKUP.dbf usrBACKUP.dbf

log1BACKUP.dbf log2_m_BACKUP.dbf tempBACKUP.dbf

Control file이전부분실된 경우에는 새로 Control file을 Creation 해야 한다. 이 경우에는 vi editor를 열어 아래와 같이 Control file을 Creation하는 script를 작성한 후에 Control file을 새로 Creation하고 Recovery해야 한다.

STARTUP NOMOUNT

CREATE CONTROL FILE REUSE DATABASE “BACKUP” NORESETLOGS ARCHIVELOG

MAXLOGFILES 32

MAXLOGMEMBERS 2

MAXDATAFILES 30

MAXINSTANCES 8

MAXLOGHISTORY 800

LOGFILE

GROUP 1 (

‘/u02/ORACLE/BACKUP/log1BACKUP.dbf’,

‘/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf’

) SIZE 10K,

GROUP 2 (

‘/u02/ORACLE/BACKUP/log2BACKUP.dbf’,

‘/u02/ORACLE/BACKUP/log2_m_BACKUP.dbf’

) SIZE 10K

DATAFILE

‘/u02/ORACLE/BACKUP/systBACKUP.dbf’,

‘/u02/ORACLE/BACKUP/rbsBACKUP.dbf’,

‘/u02/ORACLE/BACKUP/tempBACKUP.dbf’,

‘/u02/ORACLE/BACKUP/toolBACKUP.dbf’,

‘/u02/ORACLE/BACKUP/usrBACKUP.dbf’ ;

RECOVER DATABASE

ALTER SYSTEM ARCHIVE LOG ALL;

ALTER DATABASE OPEN;

위의script를작성한 후 실행시키기 위해서는 현재 OPEN 되어있는 Database를 NOMOUNT 상태로 만들어야 한다. 현재 Open 되어 있는 Database를 NORMAL이나 IMMEDIATE Option으로 SHUTDOWN하려하면 Error(ORA-1122)가 Return 될 것이다. 왜냐하면 Oracle은 Control file이 가지고 있는 Database Structure에 관한 정보와 실제 Database Structure의 구조를 비교 하여 일치할 경우에만 Database를 SHUTDOWN, STARTUP 할 수 있다. 그러나 현재 Control file이 (Mirroring 되고 있는 Control file까지) 전부 손상되어 있으므로 손상된 Control file이 가지고 있는 손상된 정보와 실제 Database Structure는 일치하지 않으므로 SHUTDOWN을 ABORT 해야 Database는 Shutdown될 것이다. 그러나 이 상태에서 Control file을 다시 Creation할 때 Control file은 생성되지만 Recovery는 수행되지 않고 Database는 OPEN된다. 그러므로 ABORT Option으로 SHUTDOWN 해야 Recovery까지 수행할 수 있다.

만약 Control file이 손상되기 이전에 Backup받아 놓은 Control file이 있고 Backup을 받은 후에도 Database의 물리적인 구조가 변경되지 않았다면 ALTER DATABASE BACKUP CONTROL FILE TO TRACE ; command를 사용하면 Control file을 Creation하는 script를 보다 쉽게 작성할 수 있게 해준다. ALTER DATABASE BACKUP CONTROL FILE TO TRACE ; command를 사용하기 위해선 Backup받은 Control file 모두를 Physical directory로 Copy해야 한다.

왜냐하면 이 Command는 Physical한 Control file을 user_dump_dest(config.ora file에서 정의)인/admhome/ oracle/admin/BACKUP/udump로 ORA_xxxxx.trc라는 trace file을 생성하며 이 trace file에는 Physical한 Control file이 가지고 있는 Database의 Structure에 관한 정보를 토대로 Control file을 Creation하는 Script가 만들어진다.

설령 Control file을 Backup받은 후에 Database의 물리적인 구조가 변경되었다면 Backup받은 Control file을 Copy하고 ALTER DATABASE BACKUP CONTROL FILE TO TRACE ; 를 실 행한 후 /admhome/oracle/admin/BACKUP/udump밑에 생성된 Trace file에 Database의 변경된 부분을 추가 혹은 삭제하여 SHUTDOWN ABORT한 후에 실행시키면 Recovery가 수행될 것이다.

SVRMGR> shutdown abort

ORACLE instance shut down.

위에서작성한script를 실행시켜 Control file을 Creation하고 Recovery를 수행해야 한다.

SVRMGR> @create_contolfile.sql

Statement processed.

Media recovery complete.

Statement processed.

Control file이Creation되었는지physical directory에서 확인해본다.

$ ls -l /u02/ORACLE/BACKUP

-rw-r—– 1 oracle dba 111104 Oct 18 11:34 ctrl1BACKUP.ctl

-rw-r—– 1 oracle dba 111104 Oct 18 11:34 ctrl2BACKUP.ctl

-rw-r—– 1 oracle dba 111104 Oct 18 11:34 ctrl3BACKUP.ctl

Datafile을추가하여Database가 정상적으로 Recovery 되었는지 확인해 볼 수 있다.

2-2. Control file 중 일부가 손상된 경우의 Recovery

oerr ora 210

00210, 00000, “cannot open control file ‘%s'”

*Cause: Cannot open the control file

*Action: Check to make sure the control file is there and not locked by some other program

현상 및 Error 내용

위 CASE 2-1과 같은 Error를 Return 할 것이다.

SQL> alter tablespace users add Datafile ‘/u02/ORACLE/BACKUP/usr2BACKUP.dbf’;

alter tablespace users add Datafile ‘/u02/ORACLE/BACKUP/usr2BACKUP.dbf’

ERROR at line 1:

ORA-00210: cannot open control file ‘/u02/ORACLE/BACKUP/ctrl1BACKUP.ctl’

ORA-07368: sfofi: open error, unable to open database file.

IBM AIX RISC System/6000 Error: 2: No such file or directory

Recovery 수행 방법

Physical directory에서mirroring 되고있는 Control file을 Copy한다.

$ cp /u02/ORACLE/BACKUP/ctrl2BACKUP.ctl ctrl1BACKUP.ctl

IMMEDIATE로Shutdown한다.

SVRMGR> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

STRATUP 한다.

SVRMGR> startup

ORACLE instance started.

Database mounted.

Database opened.

위와 같이 Test결과 Recovery된다. Mirroring되고있는Control file 중 일부가 손상을 입어 Database의 물리적 구조를 변화시키지 못하여 Error를 Return 할 때 Mirroring되고 있는 Control file을 Physical directory에 Copy하고 NORMAL로 SHUTDOWN한 후 다시 STARTUP하면 손상된Control file을 Recovery할 수 있다. 그러나 ORACLE Mannual에는 ABORT로 SHUTDOWN하라고 명시하고 있다. 그리고 Mannual에는 1과 2를 바꿔 수행하라고 기술되어 있지만 두 가지 경우 모두 Recovery는 정상적으로 된다.

다른 Recovery 방법(ORACLE Mannual)

ABORT로SHUTDOWN한다.

SVRMGR> shutdown ABORT

Database closed.

Database dismounted.

ORACLE instance shut down.

Physical directory에서mirroring 되고있는 Control file을 Copy한다.

$ cp /u02/ORACLE/BACKUP/ctrl2BACKUP.ctl ctrl1BACKUP.ctl

STRATUP 한다.

SVRMGR> startup

ORACLE instance started.

Database mounted.

Database opened.

Case 3. RedoLog file 의 Recovery

3-1 Mirrored 되는 Redolog file Group중 특정 member의 Recovery

(Current redo log Group이 아닌 Group의 member가 손상된 경우, Current redo log Group의 member가 손상된 경우 공통)

cf) 현재log file의상태

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 136 10240 2 YES INACTIVE

2 1 137 10240 2 NO CURRENT

2 rows selected.

현상 및 Error 내용

SQL> insert into bonus

2 select * from bonus;

736 rows created.

SQL>select count(*) from bonus

COUNT(*)

———-

1472

SVRMGR> select GROUP#,THREAD#,SEQUENCE#,BYTES, MEMBERS, ARCHIVED,STATUS

2> from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

—— ——– ———– —– ——– —

1 1 146 10240 2 NO CURRENT

2 1 145 10240 2 YES INACTIVE

2 rows selected.

Log Group에서 각 Group에 최소한 1개의 Mirroring되고 있는log file이 있다면 Log 상태가 CURRENT이든 INACTIVE이든 상관없이 log file member가 손상을 입었을지라도 ORACLE의 background process인 LGWR은 손상된 log file이외 의 다른 log file member를 찾아 Write하므로 별도의 Error를 Return하지 않고 정상적으로 Database가 작동하도록 한다. 다만 LGWR Trace file이나 ALERT file에 Error message를 남긴다.

Recovery 수행 방법

V$LOG에서손상된log file member의 상태가 Current가 아닌지를 확인한다. 만약 Current상태라면 인위적으로 Log Switch를 다른 Group으로 넘겨 INACTIVE 상태로 만들어야 손상된 log file을 DROP할 수 있고 다시 ADD할 수 있다.

SVRMGR> alter system switch logfile;

Statement processed.

SVRMGR> select GROUP#,THREAD#,SEQUENCE#,BYTES, MEMBERS,ARCHIVED,STATUS

2> from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 145 10240 2 YES INACTIVE

2 1 146 10240 2 NO CURRENT

손상된log file을DROP한다.

SVRMGR> alter database drop logfile member ‘/u02/ORACLE/BACKUP/log1BACKUP.dbf’;

Statement processed.

SVRMGR> select * from v$logfile;

GROUP# MEMBER

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

2 /u02/ORACLE/BACKUP/log2BACKUP.dbf

2 /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf

1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf

3rows selected.

다시log member를추가한다.

SVRMGR> alter database add logfile member ‘/u02/ORACLE/BACKUP/log1BACKUP.dbf’

2> to group 1;

Statement processed.

SVRMGR> select * from v$logfile;

GROUP# STATUS MEMBER

——— ———————————–

2 /u02/ORACLE/BACKUP/log2BACKUP.dbf

2 /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf

1 INVALID /u02/ORACLE/BACKUP/log1BACKUP.dbf

1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf

4 rows selected.

위와 같이 Log file Group에서 Member일부가 손상을 입었을 경우에는 위와 같이 간단히 Recovery 할 수 있다.

3-2 Mirrored 되는 Redolog file Group중 특정 Group의 Recovery

(Current Online Redolog Group이 아닌 경우)

ORA-1096을 Return하는 경우에는 아래의 Recovery 수행 방법을 통해 Recovery한다.

oerr ora 1092

01092, 00000, “ORACLE instance terminated. Disconnection forced”

*Cause:The instance this process was connected to was terminated abnormally, probably via a shutdown abort. This process was forced to disconnect from the instance.

*Action: When instance has been restarted, retry action.

현상 및 Error 내용

SQL> insert into bonus values(‘wwew’,’qeq’,1122,22222);

1 row created.

SQL> /

1 row created.

SQL> /

insert into bonus

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

Current Log Group이 아닌 다음 Log Switch가 일어날 Group이 손상된 경우 User는 계속해서 DML작업을 계속할 것이다. 일반적으로 SGA안의 Log Buffer가 다 차면 Current Log Group 에 Write하고 Log Switch를 다음 Log Group으로 넘기고 꽉 찬 Current Log file의 내용을 Archive log file에 써야 한다. 그러나 다음 Log Switch가 넘어갈 Group이 손상되어 있으므로 Log Switch가 넘어가지를 못한다. 그리고 Current Log Group은 LGWR이 Log Buffer의 내용을 Write했으므로 꽉찼지만 Archive 는 아직 수행하지 못하고 있는 상태이다.

이처럼 다음 Log Switch가 일어날 Group이 손상된 경우 ORACLE은 Background process인 LGWR를 강제로 terminate 시키고 Trace file에 기록을 남긴다.

$ls -la /admhome/oracle/admin/BACKUP/bdump

-rw-r–r– 1 oracle dba 27107 Oct 19 15:53 alert_BACKUP.log

-rw-r—– 1 oracle dba 1131 Oct 19 15:58 lgwr_44568.trc

-rw-r—– 1 oracle dba 682 Oct 19 15:58 pmon_28172.trc

$ vi /admhome/oracle/admin/BACKUP/bdump/ pmon_28172.trc

Sat Oct 19 15:58:21 1996

*** SESSION ID:(1.1) 1996.10.19.15.58.21.959

error 470 detected in background process

OPIRIP: Uncaught error 447. Error stack:

ORA-00447: fatal error in background process

ORA-00470: LGWR process terminated with error

$ vi /admhome/oracle/admin/BACKUP/bdump/ lgwr_44568.trc

*** SESSION ID:(4.1) 1996.10.19.15.50.06.574

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: ‘/u02/ORACLE/BACKUP/log1BACKUP.dbf’

ORA-07360: sfifi: stat error, unable to obtain information about file.

IBM AIX RISC System/6000 Error: 2: No such file or directory

ORA-00312: online log 1 thread 1: ‘/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf’

ORA-07360: sfifi: stat error, unable to obtain information about file.

IBM AIX RISC System/6000 Error: 2: No such file or directory

Sat Oct 19 15:53:12 1996

ORA-00313: open failed for members of log group 1 of thread 1

Sat Oct 19 15:58:21 1996

error 313 detected in background process

Recovery 수행 방법

PMON은Background process인LGWR를 강제로 kill 시키고 Terminate 시키므로 ABORT Option으로 SHUTDOWN 시킨다.

SVRMGR> shutdown abort

ORACLE instance shut down.

일단NORMAL로STARTUP하여 ERROR를 Check한다.

SVRMGR> startup

ORACLE instance started.

Database mounted.

ORA-00313: open failed for members of log group 2 of thread 1

ORA-00312: online log 2 thread 1: ‘/u02/ORACLE/BACKUP/log2_m_BACKUP.dbf’

ORA-00312: online log 2 thread 1: ‘/u02/ORACLE/BACKUP/log2BACKUP.dbf’

SVRMGR> !oerr ora 313

00313, 00000, “open failed for members of log group %s of thread %s”

*Cause: The online log cannot be opened. May not be able to find file.

*Action: See accompanying errors and make log available.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 156 10240 2 NO CURRENT

2 1 0 10240 2 YES UNUSED

2 rows selected.

SVRMGR> select * from v$logfile;

GROUP# STATUS MEMBER

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

2 STALE /u02/ORACLE/BACKUP/log2BACKUP.dbf

2 STALE /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf

1 /u02/ORACLE/BACKUP/log1BACKUP.dbf

1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf

임의의Log Group을Add한다.

SVRMGR> alter database add logfile ‘/u02/ORACLE/BACKUP/log3.dbf’ size 10k;

Statement processed.

손상된Log Group을DROP한다.

SVRMGR> alter database drop logfile group 2;

Statement processed.

다시손상된Log Group과 같은 Size, Name으로 ADD한다.

SVRMGR> alter database add logfile ‘/u02/ORACLE/BACKUP/log2BACKUP.dbf’ size 10k;

Statement processed.

SVRMGR> alter database add logfile member ‘/u02/ORACLE/BACKUP/log2_m_BACKUP.dbf’

2> to group 2;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 156 10240 2 NO CURRENT

2 1 0 10240 2 YES UNUSED

3 1 0 10240 1 YES UNUSED

3 rows selected.

임의로생성했던Log Group을 DROP한다.

SVRMGR> alter database drop logfile group 3;

Statement processed.

Database를OPEN한다.

SVRMGR> alter database open;

Statement processed.

SVRMGR> alter system switch logfile;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 156 10240 2 NO CURRENT

2 1 157 10240 2 YES INACTIVE

2 rows selected.

SVRMGR> select * from v$logfile;

GROUP# STATUS MEMBER

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

2 /u02/ORACLE/BACKUP/log2BACKUP.dbf

2 /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf

1 /u02/ORACLE/BACKUP/log1BACKUP.dbf

1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf

4 rows selected.

마지막으로임의로생성했던 Physical한 Log file을 Remove한다.

$ rm /u02/ORACLE/BACKUP/log3.dbf

3-3 Mirrored 되는 Redolog file Group중 특정 Group의 Recovery

(Current Online Redo log Group인 경우)

DML(Data Manipulation Language) 즉, Insert, Delete, Update등 을 실행 시켰는데 아무런 결과를 Return하지 않고 계속 묵묵부 답일 때에는 다른 Session을 열어 Alert_ORACLE_SID.ora을 확인 하여 Database에 어떤 문제가 발생한 것은 아닌 지 확인 해보는 자세가 중요하다.

현상 및 Error 내용

SQL> insert into bonus

2 select * from bonus;

10 rows created.

SQL> /

===> 무반응

현재 Current log Group이 전부 손상된 시점에 ORACLE은 특별한 Error Message를 Return하지 않고 다만 /admhome/oracle/admin/BACKUP/bdump에 ALERT file이나 arch_xx.trc file에 Error Message를 남긴다. 여기서 arch_xx.trc file을 보면 ,

ORA-00255: error archiving log 1 of thread 1, sequence # 169

ORA-00312: online log 1 thread 1: ‘/u02/ORACLE/BACKUP/log1BACKUP.dbf’

ORA-00312: online log 1 thread 1: ‘/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf’

ORA-00286: No members available, or no member contains valid data

ORA-00334: archived log: ‘/adhome/oracle/admin/BACKUP/arch/arch_169.arc

위의 Error를 Return 함을 알 수 있다. 특히 ORA-286을 보면 알 수 있듯이 Current log Group이 없음을 알 수 있고 Log file이 없으므로 Archive할 Data가 없다고 Message를 남긴다.

00286, 00000, “No members available, or no member contains valid data”

*Cause: None of the members of a logfile group are available, or the available members do not contain complete data.

*Action: If a member is temporarily offline, attempt to make it available.Make sure that the correct file names are being used, especially if the log is being accessed from a remote location.

SGA안의 Log buffer가 꽉차서 LGWR가 Redo log Buffer안의 내용을 Current Log file에 write하려고 하지만 Log file이 손상되어 있으므로 write하지 못한다. 이때 ORACLE은 내부적 알고리즘에 의해 LGWR가 손상된 Current Log file에 Redo log buffer의 내용을 write하지 못했더라도 다른 정상적인 Log Group으로 Log Switch를 넘긴다. 그러나 현재 손상된 Current log file에 write한 것이 없으므로 Current log file의 것을 Archive file로도 남길 수 없다. 다음의 V$LOG에서 나타나듯이 손상된 Current Group이었던 Group # 1의 STATUS는 INACTIVE이고 Archive는 안되었음을 알 수 있다.

주의할점은 위처럼 Current Log Group이 손상을 입었을 때는 ORACLE은 아무런 Message를 내보내지 않는다는 것이 다. 그러므로 위에서처럼 DML에 아무런 반응이 없을 때는 Current Log Group이 손상되지 않았나 Check해 보는 것이 바람직하다.

Recovery 수행 방법

일단DML에대한 아무런 반응이 없었으므로 Alert file이나 현재시간에 생성된 Trace file을 살펴본다. Trace file의 내용이 Log file과 연관이 있는 것이라면 V$LOG를 확인해 본다.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 158 10240 2 NO INACTIVE

2 1 159 10240 2 NO CURRENT

2 rows selected.

위에서 확인한 것처럼 Group # 1의 ARCHIVE가 안 일어나고 Group 2로 Log Switch가 넘어갔음을 알 수 있다.

임의의Log Group을생성한다. 왜냐하면 손상된 Log Group 을 없애고 새로 만드는 과정에서 ORACLE에서는 반드시 Log Group이 2개 이상(Circular fashion)이어야 한다. 그러므로 GROUP 1을 DROP하는 시점에 Log Group은 2개 이상이 존재 해야 하므로 임의의 Log Group 3를 생성해야 한다.

SVRMGR> alter database add logfile ‘/u02/ORACLE/BACKUP/log3.dbf’ size 10k;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 158 10240 2 NO INACTIVE

2 1 159 10240 2 NO CURRENT

3 1 0 10240 1 YES UNUSED

3 rows selected.

손상될Log Group을DROP해야 한다. 그러나 현재 Database는 ARCHIVELOG Mode로 운영되고 있다. ARCHIVELOG Mode에서는 Archive가 되지않은 Current Log file을 DROP할 수 없다. 그러므로 손상된 Log Group을 DROP하 기에 앞서 Database를 NOARCHIVELOG Mode로 변경시켜주어 야 한다.

SVRMGR> alter database drop logfile group 1;

alter database drop logfile group 1

ORA-00350: log 1 of thread 1 needs to be archived

ORA-00312: online log 1 thread 1: ‘/u02/ORACLE/BACKUP/log1BACKUP.dbf’

ORA-00312: online log 1 thread 1: ‘/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf’

SVRMGR> shutdown immediate

ORACLE instance shut down.

SHUTDOWN 했으면 STARTUP MOUNT한다.

SVRMGR> startup mount

ORACLE instance started.

Database mounted.

SVRMGR> alter database noarchivelog;

Statement processed.

SVRMGR> archive log list

Database log mode No Archive Mode

Automatic archival Enabled

Archive destination /admhome/oracle/admin/BACKUP/arch

Oldest online log sequence 158

Current log sequence 159

손상된Log Group을DROP한다.

SVRMGR> alter database drop logfile group 1;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

2 1 159 10240 2 NO CURRENT

3 1 0 10240 1 YES UNUSED

2 rows selected.

새로Log Group을생성한다.

SVRMGR> alter database add logfile ‘/u02/ORACLE/BACKUP/log1BACKUP.dbf’ size 10k;

Statement processed.

SVRMGR> alter database add logfile member ‘/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf’

2> to group 1;

Statement processed.

SVRMGR> select * from v$logfile;

GROUP# STATUS MEMBER

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

2 STALE /u02/ORACLE/BACKUP/log2BACKUP.dbf

2 STALE /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf

/u02/ORACLE/BACKUP/log1BACKUP.dbf

1 INVALID /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf

/u02/ORACLE/BACKUP/log3.dbf

5 rows selected.

임의로생성했던Log Group 을 DROP 한다.

SVRMGR> alter database drop logfile group 3;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

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

1 1 0 10240 2 YES UNUSED

2 1 159 10240 2 NO CURRENT

2 rows selected.

SVRMGR> select * from v$logfile;

GROUP# STATUS MEMBER

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

2 STALE /u02/ORACLE/BACKUP/log2BACKUP.dbf

2 STALE /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf

/u02/ORACLE/BACKUP/log1BACKUP.dbf

1 INVALID /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf

4 rows selected.

NOARCHIVE Mode를다시ARCHIVELOG Mode로 바꾼다.

SVRMGR> alter database archivelog;

Statement processed.

Database를OPEN한다.

SVRMGR> alter database open;

Statement processed.

Physical Storage directory에서임의로생성했던 log file을 Remove한다.

$ rm /u02/ORACLE/BACKUP/log3.dbf

3-4. Redo log file이 모두 손상된 경우

현상 및 Error 내용

추후 기재

Recovery 수행 방법

System이 Shutdown되기 전에 복구해야 함.

SQL> insert into bonus

2 select * from bonus;

1280 rows created. (총 2560row 존재)

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIR

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

1 1 1 4194304 2 NO CURRENT

2 1 0 4194304 2 YES UNUSED

SVRMGR> alter database add logfile group 3

‘/u01/ORACLE/BACKUP/log3BACKUP.dbf’ size 1m;

Statement processed.

SVRMGR> alter database drop logfile group 2;

Statement processed.

SVRMGR> alter database add logfile group 2

‘/u01/ORACLE/BACKUP/log2BACKUP.dbf’ size 4m;

Statement processed.

SVRMGR> alter database add logfile member

‘/u01/ORACLE/BACKUP/log2_m_BACKUP.dbf’ to group 2;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIR

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

1 1 1 4194304 2 NO CURRENT

2 1 0 4194304 2 YES UNUSED

3 1 0 1048576 1 YES UNUSED

3 rows selected.

SVRMGR> alter database drop logfile group 1;

alter database drop logfile group 1

ORA-01623: log 1 is current log for thread 1 – cannot drop

ORA-00312: online log 1 thread 1: ‘/u01/ORACLE/BACKUP/log1BACKUP.dbf’

ORA-00312: online log 1 thread 1: ‘/u01/ORACLE/BACKUP/log1_m_BACKUP.dbf’

SVRMGR> alter system switch logfile;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIR

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

1 1 1 4194304 2 NO INACTIVE

2 1 2 4194304 2 NO CURRENT

3 1 0 1048576 1 YES UNUSED

3 rows selected.

SVRMGR> alter database drop logfile group 1;

alter database drop logfile group 1

ORA-00350: log 1 of thread 1 needs to be archived

ORA-00312: online log 1 thread 1: ‘/u01/ORACLE/BACKUP/log1BACKUP.dbf’

ORA-00312: online log 1 thread 1: ‘/u01/ORACLE/BACKUP/log1_m_BACKUP.dbf’

SVRMGR> shutdown abort

SVRMGR> startup mount

SVRMGR> alter database noarchivelog;

Statement processed.

SVRMGR> alter database drop logfile group 1;

Statement processed.

SVRMGR> alter database add logfile group 1

2> ‘/u01/ORACLE/BACKUP/log1BACKUP.dbf’ size 4m;

Statement processed.

SVRMGR> alter database add logfile member

2> ‘/u01/ORACLE/BACKUP/log1_m_BACKUP.dbf’ to group 1;

Statement processed.

SVRMGR> alter database drop logfile group 3;

Statement processed.

SVRMGR> alter database open;

SVRMGR> shutdown

SVRMGR> startup mount

SVRMGR> alter database archivelog;

Statement processed.

SVRMGR> alter database open;

Statement processed.

SVRMGR> connect scott/tiger

Connected.

SVRMGR> select count(*) from bonus;

COUNT(*)

———-

2560

1 row selected.

Case 4. Online Tablespace backup 직후 failure가 발생한 경우

(End Backup command를 아직 수행하지 못한 경우)

Recovery 수행 방법

SVRMGR> select * from v$backup;

FILE# STATUS CHANGE# TIME

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

1 ACTIVE 6559 10/12/96 13:53:16

2 ACTIVE 6560 10/12/96 13:53:16

3 ACTIVE 6562 10/12/96 13:53:16

4 ACTIVE 6561 10/12/96 13:53:16

5 ACTIVE 6563 10/12/96 13:53:16

ACTIVE는 backup mode중 임을 뜻한다.

SVRMGR> shutdown abort

ORACLE instance shut down.

SVRMGR> startup

ORACLE instance started.

Total System Global Area 4953044 bytes

Fixed Size 38940 bytes

Variable Size 4078520 bytes

Database Buffers 819200 bytes

Redo Buffers 16384 bytes

Database mounted.

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: ‘/u01/ORACLE/BACKUP/systBACKUP.dbf’

SVRMGR> recover Datafile ‘/u01/ORACLE/BACKUP/systBACKUP.dbf’;

Media recovery complete.

ORA-01113: file 2 needs media recovery

ORA-01110: data file 2: ‘/u01/ORACLE/BACKUP/rbsBACKUP.dbf’

SVRMGR> recover Datafile ‘/u01/ORACLE/BACKUP/rbsBACKUP.dbf’;

Media recovery complete.

SVRMGR> alter database open;

alter database open

ORA-01113: file 3 needs media recovery

ORA-01110: data file 3: ‘/u01/ORACLE/BACKUP/tempBACKUP.dbf’

SVRMGR> recover Datafile ‘/u01/ORACLE/BACKUP/tempBACKUP.dbf’

Media recovery complete.

SVRMGR> alter database open;

ORA-01113: file 4 needs media recovery

ORA-01110: data file 4: ‘/u01/ORACLE/BACKUP/toolBACKUP.dbf’

SVRMGR> recover Datafile ‘/u01/ORACLE/BACKUP/toolBACKUP.dbf’

Media recovery complete.

SVRMGR> alter database open;

alter database open

ORA-01113: file 5 needs media recovery

ORA-01110: data file 5: ‘/u01/ORACLE/BACKUP/usrBACKUP.dbf’

SVRMGR> recover Datafile ‘/u01/ORACLE/BACKUP/usrBACKUP.dbf’;

Media recovery complete.

SVRMGR> alter database open;

Statement processed.

SVRMGR> select * from v$backup;

FILE# STATUS CHANGE# TIME

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

1 NOT ACTIVE 6559 10/12/96 13:53:16

2 NOT ACTIVE 6560 10/12/96 13:53:16

3 NOT ACTIVE 6562 10/12/96 13:53:16

4 NOT ACTIVE 6561 10/12/96 13:53:16

5 NOT ACTIVE 6563 10/12/96 13:53:1

Recovery 수행 방법

SVRMGR> startup mount

ORACLE instance started.

Total System Global Area 4953044 bytes

Fixed Size 38940 bytes

Variable Size 4078520 bytes

Database Buffers 819200 bytes

Redo Buffers 16384 bytes

Database mounted.

SVRMGR> alter database Datafile ‘/u01/ORACLE/BACKUP/systBACKUP.dbf’ end backup;

Statement processed.

SVRMGR> alter database Datafile ‘/u01/ORACLE/BACKUP/rbsBACKUP.dbf’ end backup;

Statement processed.

SVRMGR> alter database Datafile ‘/u01/ORACLE/BACKUP/tempBACKUP.dbf’ end backup;

Statement processed.

SVRMGR> alter database Datafile ‘/u01/ORACLE/BACKUP/toolBACKUP.dbf’ end backup;

Statement processed.

SVRMGR> alter database Datafile ‘/u01/ORACLE/BACKUP/usrBACKUP.dbf’ end backup;

Statement processed.

SVRMGR> alter database open;

Statement processed.

Case 5. Backup본이 없는 Datafile이 손상 된 경우

Recovery 수행 방법

임의의 tablespace test3를 만듦.

그 tablespace에 table을 만든다.

Datafile을 삭제한다.

SQL> create tablespace TEST Datafile

‘/u01/ORACLE/BACKUP/test3.dbf’ size 5m reuse

default storage (

initial 20k

next 20k

pctincrease 50);

SQL> create table chw

2 (a number(2),

3 b varchar2(8),

4 c varchar2(8))

5 tablespace test;

Table created.

SQL> insert into chw

2 values(1,’chw’,’seoul’);

1 row created.

SQL> /

1 row created.

SQL>commit;

$ rm /u01/ORACLE/BACKUP/test3.dbf

Recovery 수행 방법

SQL> select NAME,STATUS from v$Datafile;

NAME STATUS

———————————– ———

/u01/ORACLE/BACKUP/systBACKUP.dbf SYSTEM

/u01/ORACLE/BACKUP/rbsBACKUP.dbf ONLINE

/u01/ORACLE/BACKUP/tempBACKUP.dbf ONLINE

/u01/ORACLE/BACKUP/toolBACKUP.dbf ONLINE

/u01/ORACLE/BACKUP/usrBACKUP.dbf ONLINE

/u01/ORACLE/BACKUP/test.dbf ONLINE

SVRMGR> shutdown abort

ORACLE instance shut down.

SVRMGR> startup

ORACLE instance started.

Database mounted.

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

ORA-01110: data file 6: ‘/u01/ORACLE/BACKUP/test.dbf’

SVRMGR> alter database create Datafile ‘/u01/ORACLE/BACKUP/test.dbf’ as

2> ‘/u01/ORACLE/BACKUP/test2.dbf’;

SVRMGR> recover tablespace test;

ORA-01109: database not open

SVRMGR> alter database open;

alter database open

ORA-01113: file 6 needs media recovery

ORA-01110: data file 6: ‘/u01/ORACLE/BACKUP/test2.dbf’

SVRMGR> recover Datafile ‘/u01/ORACLE/BACKUP/test2.dbf’;

ORA-00279: Change 6583 generated at 10/12/96 14:22:20 needed for thread 1

ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_8.arc

ORA-00280: Change 6583 for thread 1 is in sequence #8

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

Log applied.

ORA-00279: Change 6643 generated at 10/14/96 10:47:40 needed for thread 1

ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_9.arc

ORA-00280: Change 6643 for thread 1 is in sequence #9

ORA-00278: Logfile ‘/admhome/oracle/admin/BACKUP/arch/arch_8.arc’ no longer neey

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

Log applied.

ORA-00279: Change 6659 generated at 10/14/96 10:50:58 needed for thread 1

ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_10.arc

ORA-00280: Change 6659 for thread 1 is in sequence #10

ORA-00278: Logfile ‘/admhome/oracle/admin/BACKUP/arch/arch_9.arc’ no longer neey

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

Log applied.

Media recovery complete.

** set auto recovery on으로 설정한 후 log를 적용하면 적용 시점까지 저절로 apply된다.

SVRMGR> alter database open ;

Statement processed.

Case 6. 특정 시점으로의 Recovery ( Time-Based Recovery)

현상 및 Error 내용

SVRMGR> shutdown

$cp /u01/ORACLE/BACKUP/* /u01/ORACLE/COLD_BACK

SVRMGR> startup

SVRMGR>connect scott/tiger

SVRMGR> insert into bonus

2> select * from bonus;

640 rows processed.

SVRMGR> /

SVRMGR> commit;

Statement processed.

SVRMGR> select count(*) from bonus;

COUNT(*)

———-

1280

1 row selected.

SVRMGR> select to_char(sysdate,’yyyy-mm-dd:hh24:mi:ss’) from dual;

TO_CHAR(SYSDATE,’YYYY-MM-DD:HH24:MI:SS’)

—————————————————————————

1996-10-16:18:37:20

1 row selected.

SVRMGR> truncate table bonus;

Statement processed.

SVRMGR> commit;

Statement processed.

Recovery 수행 방법

SVRMGR>shutdown abort

$ls /u01/ORACLE/COLD_BACK

ctrl1BACKUP.ctl log1_m_BACKUP.dbf systBACKUP.dbf usrBACKUP.dbf

ctrl2BACKUP.ctl log2BACKUP.dbf tempBACKUP.dbf

ctrl3BACKUP.ctl log2_m_BACKUP.dbf test.dbf

log1BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf

Control file과 Redo log file을 제외한 Datafile을 copy한다.

만일 current한 control file이 복구하고자 하는 시점의 database의 물리적 구조와 일치하지 않는다면 incomplete recovery를 끝내고자 하는 시점의 database의 물리적 file 구조를 반영하는 control file의 backup을 restore한다.

Hardware적인 문제로 인해 control file backup을 대체시킬 수 없다면 control_files를 edit할 수 있다.

존재하는 Datafile을 대체하기 위해서 사용되는 모든 backup file은 복구하고자 하는 시점 전의 것이어야 한다.

$cd /u01/ORACLE/COLD_BACK

$cp rbsBACKUP.dbf systBACKUP.dbf tempBACKUP.dbf test.dbf toolBACKUP.dbf usrBACKUP.dbf /u01/ORACLE/BACKUP

SVRMGR> startup mount

database의 모든 Datafile은 time-based or change-based recovery 하는 동안 online이어야 함

SVRMGR> select * from v$Datafile;

FILE# STATUS ENABLED CHECKPOINT BYTES CREATE_BYT NAME

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

1 SYSTEM READ WRITE 6798 52428800 52428800 /u01/ORACLE/BACK

2 ONLINE READ WRITE 6798 41943040 41943040 /u01/ORACLE/BACK

3 ONLINE READ WRITE 6798 52428800 52428800 /u01/ORACLE/BACK

4 ONLINE READ WRITE 6798 10485760 10485760 /u01/ORACLE/BACK

5 ONLINE READ WRITE 6798 10485760 10485760 /u01/ORACLE/BACK

truncate 하기 전의 시간으로 복구한다.

Control file backup을 사용했거나 재 creation된 control file이 restore되었다면 “using backup Control file” parameter를 명시한다.

SVRMGR> recover database until time ‘1996-10-16:18:37:00’;

Media recovery complete.

log를 reset시킨다.

SVRMGR> alter database open resetlogs;

Statement processed.

SVRMGR> connect scott/tiger

Connected.

SVRMGR> select count(*) from bonus;

COUNT(*)

———-

1280

1 row selected. ªª