OracleHistory2

Backup and Recovery

May, 1999

CloudBox

Jang Kyung Sang

Backup and Recovery http://www.ggola.com

Oracle 7 Admin Review
7

Object

 Schema object(user(owner)가 있는 object) : table, view,
index, sequence, synonym

 Non schema object : Tablespace, Database, Rollback Segment,
User

Transaction procedure

 Transaction procedure example (update case)
datablock 확보 – read data(before image) – lock(exclusive) –
redo log buffer 기록(change상황) – rollback 기록(after image)
– commit – redo log buffer의 data를 write to redo log file
(LGWR) – lock release – return commit result to user –
deferred write로 DB buffer 에서 write dirty block to datafile
(DBWR)

Processes

 Pmon : abnormally 종료된 session의 connection해제,
uncommitted transaction rollback, disconnected session에서
terminated process의 lock 및 SGA resource release,
Dnnn(shared server and dispatcher processes) restart

 Smon : Oracle start시 automatic instance recovery (rollback
segment and redo log file을 사용), pctincrease가 0보다 큰 경
우에 automatic coalescing(merges continuous areas of free
space in the datafiles), 현재 사용하지 않는 temporary segment
회수

 LGWR 발생 : database의 모든 transaction change status가 저
장된 redo log buffer의 내용을 다음과 같은 경우에 disk에 기
록한다. (rollback segment entry를 포함하여 오직 recovery 를
위해서 존재한다) commit, redo log buffer 1/3이상 찰 때,
tiem_out시, DBWR가 checkpoint 발생으로 DB buffer cache 를
clean할 때
[한 instance당 1개씩 존재하고, log file에 다 쓰여지면 commit
이 확인된다. log switch되면 log sequence# 부여 (checkpoint
발생), ‘alter system switch logfile;’ command로 강제 switch가
능, 최초 redo log file의 default는 2개의 group과 group당 1개
의 member(500kb) 소유]

jkspark@hanafos.com -2- 장 경상


 DBWR 발생 : checkpoint event발생시, LRU list에서 free
block을 찾을때 1/3 이상범위에서 못찾는 경우 uncommit
transaction이라도 모든 dirty block을 write to datafile , Dirty
List가 다 찬경우 그 dirty list의 전체 block을 write to datafile
하여 모두 free block으로 전환
(위 4개의 process는 필수 process로 하나라도 fail되면
instance는 비정상 종료된다. 다만, DBWR의 경우만 init.ora
parameter를 통해 1개 이상 띄울수 있고 그 외에는 무조건 1개
씩이다)

 ARCH 발생 : archiver process는 DB mode가 archivelog
mode인 경우에만 사용되며 media failure를 대비하여 online
redo log file을 archive 형태로 copy한다, log switch시에만 발
생하며 option사항이고 tape이나 disk 모두 사용할 수 있다.

 Checkpoint event : log switch(강제 log switch 포함), log
timeout, log interval (log_checkpoint_interval parameter에 정
의된 만큼의 O/S block이 redo log file에 기록되는 경우),
shutdown(except abort option), ‘alter system checkpoint ;’
command by a DBA. 여기까지는 모든 tablespace 에 적용된다.
Tablespace offline(구성 datafile중 하나이상 online 상태인) ,
online tablespace backup. 여기서는 해당 tablespace에 해당
file에만 적용된다.
그럼 이 event가 발생하면?
1. LGWR가 redo log buffer를 redo log file로 내리고
2. DBWR가 all dirty block 을 datafile로 내리고
3. 마지막으로 동기화정보(synchronization information)를
write : headers of datafiles and control files.
동기화 정보란 timestamp, checkpoint sequence #, log
sequence #를 말하는데 보통 LGWR가 이 writing 작업을 하지
만 checkpoint_process = true로 setting 하면
CKPT(checkporint process)가 생기고 동기화작업을 LGWR로
부터 인수받는다.(1개 밖에 없는 LGWR의 부담을 덜어준다)
checkpoint가 빈번해지면 recovery time을 단축시킬 수 있지만
반대로 일반적인 performance의 저하를 가져올 수 있다. [즉,
recovery라 함은 이 synchronization information 불일치를 해
결하는 것이다]



Control file

Recovery의 모든 시작은 control file로 부터라 생각 할 수 있다. 왜
냐하면 일반적으로 control file의 synchronization information과 그
외 headers of datafiles의 그것과 일치하지 않을 때 그 동기화정보
를 일치시키는 작업이 recovery이기 때문이다.

 Control file은 어떤 information을 가지고 있는가?
- All datafiles and redo log files identification(full path로 text
형태로 기억하고있다, 물론 control file 자체는 binary)
– database name
– mount, open, access시 필요하다
– synchronization information needed for recovery

 Control_files = (/…/…ctl, /…./..ctl, /…./…ctl) parameter file
을 이용하여 반드시 2개 이상을 유지하자.
(install default는 1개다)

예) 여러 개의 control file이 만들어져 있는가 확인가능한 file은 ?
parameter file

Control file 재생성을 위한 startup option?
Startup nomount (mount, open, access시 반드시 control file 참조하므로)



Backup

Backup and Recovery 목적 및 필요사항

1. backup방법, 중요성 및 업무요구에 따른 적절한 backup의 유형

2. recovery 목적에 따른 backup의 특성인식

3. recovery 시나리오의 타당성

4. 재해복구관련 결정시 업무요구 분석에 대한 중요성 논의

5. recovery 시나리오의 적절성

6. backup 방법론에 대한 경영자 동의

7. backup and recovery 전략에 대한 실 test
(test를 통해 사용자를 위한 예상시간 파악도 중요한 문제)

cf) DBA의 가장중요한 문제는 DB를 사용 가능한 상태로 항시 유지
하는 것이므로 재해시 최소의 손실과 최소의 downtime을 보장 할
수 있는 유용한 backup and recovery 전략이 필요하다

Backup and Recovery 전략선택

1. 적절한 level의 관리자들의 동의필요 (관리자와의 협의를 통해
데이터손실 가능성에 대한 범위를 회사의 용납수준에서 절충)

2. 데이터의 특성을 고려하여 정적인지 동적인지 구분 (database
activity level : volatile(versatile) or static)

3. 데이터의 중요성 및 backup을 지원할 컴퓨터의 성능확인

4. DBA등 전문가 지원 및 backup and recovery test 가능성 확인

예) Database의 특성이 highly volatile(자주 update되는 동적 DB, high volume activity)인 경우
Backup전략?
자주 Update되는 만큼 자주backup 즉, more frequently backup이 필요

DBA가 recovery 전략을 세운 후 다음 해야하는 것은?
주기적으로 recovery 전략을 test 해야한다. (예상시간 확인 및 restore의 확실성확인)

You are implementing a backup and recovery plan for your company. What is an important
consideration for determining your strategy ? (2)
1.Database size 2.Database activity 3.System H/W capabilities 4.Number of concurrent users
=> backup and recovery plan 결정시 data 특성을 고려해야 한다.



Backup type

physical backup – with archive : archivelog mode
(offline(cold) backup, online(hot) backup)
- without archive : noarhivelog mode
(offline(cold) full backup)
logical backup – export / import utility

cf) read only tablespace는 단 1회만 backup하고 만일의 경우 read
write로 바뀌었다가 다시 read only가 된다면 그 시점에서 다시 한
번만 backup한다. (왜냐하면 read only tablespace는 checkpoint #가
변하지 않기 때문에 control file에서 check하지 않는다)

Offline full backup(archive에 상관없이)

1. backup할 file list 만들기 : v$datafile, v$logfile, v$controlfile + 가
능하면 parameter file까지(init$SID.ora)
2. Shutdown : instance 종료
3. Backup : 위 목록에 해당하는 files을 O/S 상에서 특정 backup
dest로 copy => operating system backups 이라 표현 하기도함.
4. Startup : instance restart
cf) conceptually simple, easy to perform, require little operator
interaction, backup자료에 대한 신뢰성이 높다. 그러나 database is
unavailable during backup, recovery 시점에서 backup date까지의
data loss를 감수 해야하는 치명적인 약점을 갖고있다.

Online full backup(archivelog mode에서만 유효)

1. 먼저 backup할 tablespace를 정리
2. SVR> alter tablespace tablespace_name begin backup ;
$ cp datafile/..dbf /backup/datafile/…dbf
SVR> alter tablespace tablespace_name end backup ;
이 과정을 반복해서 수행하여 모든 data를 backup한다.
(begin backup은 synchronization information을 write 중지 명령을
하고 end backup은 그명령을 해제 시킨다, backup중 발생한
transaction은 고려하지 않는다. 그 사항은 redo log에 남을 것이다.)
3. backup status는 v$backup에서 확인
* 주의 : tablespace당 한번씩 begin과 end를 반복하는 것이 전체를
beging 후 동시에 copy하고 전체를 end 하는것 보다 recovery시
downtime을 더 최소화 할 것이다. (cp 동안 발생하는 transaction 량
만큼 쌓인 log가 recovery시 더 많아질 수 있기 때문에)
4. Begin backup and datafile copy 후 end backup을 하기전 DB
down시에는 V7.2 이상부터 간단한 recovery로 해결된다. mount 상
태에서 작업을 해야하기 때문에 최초 begin backup은 tablespace 단
위로 했지만 여기서는 해당 tablespace에 해당하는 datafile을 찾아



서 end backup을 해야한다.
DB가 open이 되지 않는 상태이므로 datafile 단위로 할 수밖에 없
다.(tablespace정보는 data dictionary에 있기 때문에, 다시 말해서
system tablespace에 있기 때문이다)
SVR> startup mount
SVR> alter database datafile ‘/…/data/..file1.dbf’ end backup ;
SVR> alter database datafile ‘/…/data/..file2.dbf’ end backup ;
(개수만큼 해준다)
이 명령으로 recovery가 수행된다. (즉, begin에서 멈추었던 동기화
정보를 다시 맞추는 명령으로 DB를 open할 수 있다. 즉, mount 상
태에서만 가능하다.)

Control file backup

Database 구조가 바뀌면 항상 control file을 backup 해야한다.
tablespace나 database관련 command중 datafile과 관련된것이 대
부분이다. (즉, tablespace관련 내용은 data dictionary에 있지만
datafile과 관련한 내용은 control file에도 적용이 되기 때문이다)

1. mirroring control file (parameter 이용 ; page 4 참조)
DB down후 여러 path로 copy하고 parameter 등록 후 startup
2. DB down후 copy (offline backup)
3. DB running중 online backup :
똑같은 file을 생성하는 것과 control file 생성 문장(text)
3.1 alter database backup controlfile to
‘$ORACLE_SID/dest/cntl@SID01.ctl’ [reuse] ;
이 경우 위 경로에 동일한 file을 생성, reuse option은 같은 이름의
file이 있는 경우 overwrite를 위해 사용)
3.2 alter database backup controlfile to trace ;
이 경우 udump 밑에 ora_#.trc의 형태로 control file을 만드는 text
file이 생성된다. (위 trace file의 number는 dedicated server인 경우
session을 맺은 client의 child process에 해당하는 server process ID
를 기록한다)

control file과 redo log file 추가시 차이 :
control file은 추가시 shutdown 후 O/S 상에서 기존 control file
copy후 parameter file에 추가하지만(DB 운영중 control file 복사본
생성은 backup 차원이고), redo log file은 DB running 중 추가하면
자동으로 file이 생성된다.
(ex> alter database add logfile member ‘/…/log/log2a.rdo’ to
group 2 ; (여기서 숫자’2’는 redo log group number)



Read only tablespace backup & recovery

Read only tablespace는 synchronization information을 write하지
않으므로 DB running or not O/S 상에서 copy해서 read–only로 바
뀔 때마다 단 일회씩 backup하고 다시 원 위치로 copy해서
recovery 한다. (read-only 구성 후 한번도 read-write로 바뀌지 않으
면 영원히 1회 backup으로 유효하다)

예) 24 Hours operations DB인 경우 Backup전략?
Database downtime이 있으면 안되므로 archive mode에서 online full backup 전략이 유효

Disk가 부족한 상태의 archive mode 운영 DB인 경우 data의 손실이 없는 DB운영 전략?
추가 disk가 없는 상태이므로 archive destination을 바로 tape으로 연결한다

export하고 import한 경우 archive log를 적용 완전하게 recovery 가능하다. => false
(import는 commit된 database를 create 함으로 checkpoint정보 및 기존의 database 변경내역
은 의미가 없어지므로 archive log는 의미가 없어진다.)

Current redo log sequence number가 기록되는 2개의 file은 ? (1, 3)
1. Control file 2. Most recent archived log file 3. System tablespace datafile 4. Parameter file

Which backup method should you use to recover to the point of failure after media failure?2
1. Operating system backup without archiving
2. Operation system backup with archiving
3. Export utility backup
4. Import utility recovery

Which backup strategy should you follow if your company’s data is relatively static? 1
1. Backup less frequently than a company with highly volatile data
2. Backup more frequently than a company with highly volatile data
3. Backup each time data is altered
4. Do not backup at all because it would not be cost effective

Which background process copies online redo log files to tape or disk for use in media failure
recovery ? 3
1. CKPT 2. DBWR 3. ARCH 4.LGWR



Failures

Failure type and solution

1. syntax error : user 해결

2. user process error : PMON의 automatic recovery

3. instance failure : DB restart 후 SMON의 automatic recovery
3.1 nomout : parameter file read and SGA, Background Processes
3.2 mount : control file information read
3.3 rolling-forward : online redo log file 적용 recovery
(Oracle 7.3 부터 system tablespace error가 아니면 DB open)
3.4 rollback : user가 rollback 할 data를 access시마다 rollback 실
행 (즉, warm start 하여 deferred rollback 한다)
3.5 pending 된 transaction의 resource 해제
3.6 RECO의 분산 transaction 문제해결
3.7 SMON의 DB 동기화 (Oracle 7.2 까지는 여기서 DB open)

4. 사용자 오류 : import등을 사용하여 필요한 data 복구 (사용자교
육)

5. media recovery : Backup 전략에 따른 가장 효율적인 recovery 실
행 (반드시 downtime 최소화를 중심으로)

예) Power outage 발생시 recovery 방법은?
Instance failure이므로 database restartup (SMON)

갑작스런 정전으로 connectiion이 끊겼다면 (client side에서)?
Nothing at all (PMON의 역할이 있으므로 할게 없다)



Archive

Noarchivelog mode

Redo log file은 순차적이고, checkpoint 발생후 바로 그 redo log file
을 overwrite 할 수 있다. recovery시 redo log file이 겹쳐지면
backup 받아놓은 시점까지만 recovery된다.
만일 redo log file이 아직 overwrite되지 않은 상태에서 recovery가
필요하게 되면 DB를 다시 start하는 시점에서 smon이 자동
instance recovery를 해주므로 complete recovery가 가능할 수도 있
다.

Offline full backup만 유효하다. 반드시 모든 file을 backup한다.

archive 상태보기
SVR> archive log list
checkpoint number 보기
SVR> select * from v$database ;
여기 checkpoint number가 v$datafile의 number와 동일한
number를 갖는다.(synchronization information) 단, read only
tablespace는 다를 수 있겠다.

Archivelog mode

 Redo log file은 noarchivelog mode와 동일하게 순차적이지만
log switch후 archive가 되어야만 overwrite할 수 있다.
(archive중 문제 발생시 archive가 끝날때까지 Oracle Server는
정지된다. 이를 합법적 DB hang이라 한다)
DB mode를 archivelog mode로 한다. (ARCH 활성화, archive
사용 가능한 resource(destination media)확보)
DB running중일때 backup 가능(online backup)
system tablespace를 제외한 다른 datafile error시 recovery동
안 다른 작업을 위한 DB open 가능(warmstart)
다양한 recovery 전략을 수립할 수 있다. (recovery 유형참조)

Cf) archivelog mode 명령을 위한 alter database archivelog ;
command는 ‘alter system privilege’가 있어야 한다.
Mount 상태에서 위 command후 open하면 된다.
DB mode가 바뀌면 반드시 offline full backup을 하자.

자주나오는 질문 : ‘Alter database archivelog(noarchivelog) ;’
command의 privilege는?
mount 상태에서 alter system privilege

jkspark@hanafos.com - 10 - 장 경상


 Mode 바꾸기
자동 archive : init$SID.ora parameter 수정
1. Log_archive_start = true
(archive 사용)
2. Log_archive_dest = /back/oracle/arch/arch
(/back/oracle/arch directory에 arch로 시작하는 file)
3. Log_archive_format = oracle_%s.arc
(2의 arch + format형태에 extension은 arc)
(%s는 log sequence number 사용을 %S는 log sequence
number를 사용하되 10자리로 맞춘다)
수동 archive :
SVR> alter system archive log start to ‘/u02/../…arc’ ;

 Archivelog mode 만들기 예
1. Shutdown
2. Init$SID.ora parameter 수정 (위 참조)
3. SVR> startup mount
SVR> alter database archivelog;
(archive log list, select * from v$database; 로 확인)
4. Alter database open ;
5. SVR> Shutdown ; offline full backup
6. SVR> startup (확인:alter system switch logfile; )

Cf) Each time a redo log file is reused it is assigned to the next
consecutive sequence number.

Cf) archivelog mode 운영중 강제로 archivelog를 멈추기 위해선
alter system archive log stop;
DB open시 자동으로 archive 멈추기 위해선 init.ora parameter file
에서 log_archive_start = false

예) manually로 모든 online redo log file을 archive하는 command는 ?
alter system archivelog all ;

archive log가 저장될 위치를 나타내는 parameter는 ? 1
1. Log_archive_dest 2.archive_log_dest 3. Log_dest_archvie 4.log_dest_archive

archive log mode로 전환하는 command는 ? 2
(or which command is issued to change the archive mode of the database? Alter database)
1. Alter system archivelog ; 2. Alter database archivelog;



Recovery Type

Noarchivelog mode

Backup data를 full restore (또는 error난 tablespace를 없애도 되면
recovery 하지않고 그 tablespace 재생성한다. 만일, read only
tablespace 문제면 recovery 없이 해당 datafile만 copy 역시
recovery 없음)

Archivelog mode

Complete recovery (error난 datafile만 restore)
full database recovery : mount
tablespace recovery : mount/open
datafile recovery : mount/open

Incomplete recovery (all datafiles restore)
time-base recovery : 주어진 시간까지
cancel-base recovery : DBA가 복구시점판단
SCN-base recovery : 분산 DB에서 SCN number로 복구

Import utility

Export 받은 file을 사용하여 export 받은 시점까지 import 하여
recovery

예) Incomplete recovery 시 사용되는 option 3가지는 ?
cancel-base, time-base, SCN-base

Complete recovery가 가능한 backup 준비 상태는?
Archive mode 상태에서 이전 full backup이 존재하고 failure 시점까지 모든 과거 archived log
file이 존재하는 경우



Recovery Structure

Archivelog mode에서 complete recovery (완벽하게 현시점으로)

1. backup file restore : error난 datafile을 backup본에서 restore

2. roll forward : commit and uncommit transaction이 섞인
database 생성 (redo log file 적용)
redo log file에서 commit된 data는 data tablespace segment에 적
용 (after image)
redo log file에서 uncommit된 data는 rollback segment에 적용
(before image)

3. rollback : rollback segment 적용하여 transaction commit된
database 생성

Archivelog mode 에서 incomplete recovery (과거의 일정 시점으로)

Incomplete recovery는 과거의 어느 시점으로 돌아가는 것이기 때
문에 recovery시 모든 backup file을 restore해야 한다.
즉, control file과 나머지 모든 datafile의 checkpoint를 과거시점에
서 일치하도록 맞추어야 한다.

1. backup file restore : all datafile restore (모두 copy)

2. incomplete recovery : backup 전략에 따른 유효한 log 적용

3. log sequence number 재설정 : synchronization information 맞춘
후 open (open시 resetlogs option)

예) Incomplete recovery 수행 후 database open option은 ?
alter database open resetlogs;

Why is it mandatory the database files be synchronized at all times? 2
1. The database would not be consistent and the control file would have to be recreated
causing database downtime for the users.
2. The database cannot be opened if the file synchronization information does not match.
3. The users might encounter invalid data when querying the database
4. The database cannot be exported unless the database files are synchronized.



Case Study for Noarchivelog mode recovery

Full Recovery (File System 변경이 없는경우)

1. shutdown (abort도 상관이 없다)

2. full restore (모든 backup file restore)

3. startup

cf) 만일 read only tablespace를 구성하는 datafile error시에는
Database를 내릴필요도 없고 단지 그 구성 file만 backup본에서
copy하는것으로 recovery가 완료된다(archive mode에 상관없다)

Full Recovery (File System 변경이나 datafile의 location 변경시)

1. shutdown (option에 상관없다)

2. full restore : parameter file에서 변경된 위치로 control file 지정
변경된 위치로 각각의 datafile restore

3. startup mount

4. alter database rename file ‘../원위치/..dbf’ to ‘../새위치/..dbf’ ;
변경된 위치로 control file내부의 정보를 변경시킨다

5. alter database open ;

버리는 Recovery (error난 특정 datafile을 포기 할 때)

ex) temp tablespace 의 datafile error시 그 것을 포기하고 새로 만드
는 것이 올바른 recovery가 될 수 있다.

1. shutdown

2. startup mount

3. alter database datafile ‘/…/../temp_01.dbf’ offline drop ;

4. drop tablespace temp including contents ; error난 datafile의
tablespace가 포함하는 내용을 모두 버려서 tablespace를 drop

5. Create tablespace temp datafile ‘/…/../temp_01.dbf’ size 1M ;
drop된 tablespace를 대체할 tablespace를 새로 추가



6. Alter database open ; (error난 datafile만 새로 만드는 recovery)

예) 최초 database 생성시 default log mode는 ?
Noarchivelog mode

Database log mode를 확인할 수 있는 방법은 ? 2, 4
1. Log archive list 2. Archive log list 3. List archive log 4. Select * from v$database;

The database is running in NOARCHIVE LOG mode because changes do not occur often.
What is one disadvantage to recover this database ? 1 (2, 3, 4는 advantage)
1. Lost data must be reapplied manually.
2. There is a small margin of error.
3. Recovery time is minimal.
4. The recovery will be simple to perform.

You must recreate the control file and recover the database which contains some read-only
tablespaces. Which command should you issue to create the script necessary to create the conrol
file for this database? 3
1. Alter database rename
2. Create control file
3. Alter database backup controlfile to trace
4. Alter tablespace
cf) 이 문제는 간단한 문제가 아니다. 답은 쉽지만 왜 read-only tablespace에 대한 언급을 했는
가를 알아야 한다. (reference page 7, 24)



Parallel Recovery (Oracle Parallel Query option을 사용하는
Database에서)

Oracle Parallel Query Option

OPQ option은 parallel query나 parallel recovery 를 위해서 사용되
는 것으로 여러 개의 process를 동시에 한 작업을 위해서 사용할 수
있도록 함으로써 performance 해결에 도움을 줄 수 있다. (process
name : P000, P001, P002, P003,……,P00n)

1. parameter file 조정 :
parallel_min_server = 2 : default process 개수(최소값)
parallel_max_server = 6 : 사용 가능한 최대 process 개수
recovery_parallelism = 4 : recovery시 session당 한번에 사용가
능한 default parallel process 개수 (만일 이 값이 0, 1이면 parallel
이 안되므로 parallel 로 사용하지 않겠다는 말이된다) (datafile이
들어있는 disk drive당 하나 또는 두개의 process 정도면 recovery
상황에 충분하며(default는 datfile당 2개), instance recovery시에
도 이 process가 사용된다)
parallel_server_idle_time = 10 (분단위로 이 시간동안 parallel
process가 작업이 없으면 min server만 남기라)

2. recover database parallel (degree 4) ; 4개의 parallel process를 사
용하여 database recovery => This command specifies that 4
recovery processes are to be used when performing full database
recovery.
cf) recover database parallel (instances 2) ; 이 option은 Oracle
Parallel Server 사용시 recovery option)
cf) degree 개수 대신 default 사용시 복구할 datafile 개수의 2배를
사용하도록 지시한다

cf) v$recover_file => change#를 보고 해당 file의 redo log에서
first_change#보다 크면 그대로 recover가 가능하다.



Downtime 최소화 (minimizing downtime)

Warmstart conception

DBA의 주요임무는 Backup and Recovery 시에도 최소의
Downtime을 유지 함으로서 사용자에게 최대의 편의를 봐주어야
한다. 그래서 Oracle V7.3 부터는 warmstart가 가능해졌다. 이 말은
Database를 open한 후 error난 datafile만 복구하면서 사용자는 그
recovery에 상관없는 data는 평소처럼 사용하고 recovery는 따로
진행될 수 있다는 것이다.

warmstart란 Deferred transaction recover, deferred rolling back 개
념을 이용하여 roll-forward(redo log file적용 recovery)후 Database
open 하여 user가 해당 data(recovery 중인 data)를 access시에
rollback(rollback segment적용) 작업을 함으로써 최소의 Downtime
을 보장하는 concept. 즉, 일종의 instance recovery에 속한다.
: during the warmstart the rollback operation does the rollback
operation as an application requests that data.
The undo operation(releasing locks, resources, and so forth) is
done upon a subsequent application request for that data.
따라서 rollback 작업이 지연된 만큼 instant start는 빨라진다.

Server manager를 여러 개 띄워서 사용이 가능하며 명령은 recover
command를 사용하는 것으로 complete recovery 즉, 완전하게
100% recovery(data loss가 없는 recovery) 이다

DB running 중 일때 datafile error시 offline후 recovery
DB down 중 일 때 datafile error시 mount 상태에서 offline 후
recovery

Command : recover database, recover tablespace, recover datafile

불가한 경우 : offline이 안되는 system tablespace나 active rollback
segment를 가지고 있는 datafile등은 DB open후 recovery가 불가하
므로 반드시 mount 상태에서 recovery 한다.

Recovery order for an individual tablespace or datafile :
damaged tablespace offline
restore backup copy of damage file
restore required archive log file
recover tablespace or datafile
recovered tablespace online



Case Study for Archivelog mode recovery

Complete recovery (Full Database, Datafile, Tablespace Recovery)

Database recovery
1. shutdown

2. archive file을 dest에 copy

3. error난 datafile 또는 전체 datafile restore

4. startup mount

5. recover database (선행 작업으로 set autorecovery on 을 해주면
recover시 물어보지 않고 자동으로 recover)


(정상적으로 작업이 종료되면 control file의 동기화 정보가 각각의
datafile과 동일하게 설정된다. Full database recovery는 warmstart
가 아니므로 recovery동안 사용이 불가하다.)

Datafile recovery

- DB running 중이면 error난 datafile offline후 recovery 그렇지 않
으면 mount에서 시작

1. startup mount (손상된 datafile만 offline하고 open하기 위해)

2. alter database datafile ‘/../…../..dbf’ offline ;


4. backup datafile restore (copy backup file to error dest)

5. recover datafile ‘/../…/…./…dbf’

6. alter database datafile ‘/…./…../..dbf’ online ;

Tablespace recovery

1. startup mount (DB running 중이면 해당 tablespace offline 아니
면 mount 상태에서 해당 tablespace의 모든 datafile offline 후
open)

2. DB down 상태였으면 여기서 datafile offline 후 open



3. Alter tablespace tabspc_name offline [normal] ;
[normal] : all datafile checkpoint 수행후 offline
[temporary] : 소속 tablespace의 datafile 중 online된 datafile만
checkpoint 수행후 offline
[immediate] : 무조건 checkpoint 수행치 말고 offline (이 경우에
는 해당 datafile과 관련된 rollback data를 system tablespace 의
deferred rollback segment에 임시저장)

4. error난 tablespace의 해당 datafile restore (필요한 경우 과거의
archive file 도 copy)

5. Recover tablespace tabspc_name ;

6. Alter tablespace tabspc_name online ;
(immediate offline 인경우 이 작업에서 deferred rollback
segment에 있던 rollback data 적용)

예) Which command can be issued for database recovery if the archvied files are in the
LOG_ARCHIVE_DEST location ? 1
1. Set autorecovery on 2. Recover database 3. Recover database using backup control file
4. Alter database archvielog

There is a media failure and you want to recover only the datafiles located on affected disks so
the database remain online. Which tablespace cannot contain any of the datafiles selected for
this type of recovery? 4
1. Users 2. Data 3. Tools 4. System 5. Index

Incomplete recovery (Time-base, Cancel-base, SCN-base Recovery)

불완전 recovery는 전체 Database를 특정 시점으로 back 하는 것이
기 때문에 반드시 모든 datafile을 restore 해야한다.
(왜냐하면 특정 datafile만 back하면 다른 datafile과 control file 사
이의 checkpoint number가 일치하지 않기 때문이다. 그러므로
recovery command는 당연히 ‘recover database’를 사용할 것이다.
상기하면 recovery란 control file과 datafile간의 checkpoint number
가 일치하지 않을 때 그것을 맞추는 작업이다)

archive 적용시에 backup한 archive file의 위치가 다른데 있고 copy
해서 원위치할 수 있는 상황이 안되면 (예를 들어 원 dest의 disk 량
부족등..) recovery 시에 ‘set logsource ‘./…/path/….’로 직접 지정
해서 archive file을 recovery에 적용할 수 있다.

1. cancel base recovery : redo log file의 유실시 그 때까지 (존재하는
redo log file의 log sequence number까지) recovery 후 cancel 하
는경우



2. time base recovery : 특정 시간으로 database를 되돌리는 것으로
recovery시 원하는 시간을 입력하여 그 시점으로 전체 database
를 완전하게 되돌린다.

3. SCN base recovery : 지정된 특정 SCN number 까지 database를
되돌린다. (주로 분산DB에서 사용, 여기서는 논외)

Common causes of incomplete recovery
– user error : drops the wrong table, insert incorrect data (time)
– a bad or missing archive log (cancel)
– loss of all control files, including the mirrors
– loss of all active redo logs, including the mirrors
– loss of a datafile containing active rollback segments
– recovery with a backup of the control file.
– distributed database media failure (SCN)

Incomplete recovery order
1. shutdown

2. offline full backup (만일의 경우를 대비 즉, 다시 recovery 또는
complete recovery가 필요할 수도 있는 경우를 대비)

3. control file restore (필요한 경우)

4. all datafile restore

5. 필요한 archive file restore

6. startup mount
(이 시점에 새로이 필요로 하는 datafile이 있다면 생성하고 그외
모든 offline된 datafile이 있다면 alter database datafile command
를 이용하여 online 시킨다.)

7. recover database

8. alter database open resetlogs ;
(incomplete recovery가 끝나면 반드시 resetlogs option을 사용하
여 database를 open한다. 따라서 log sequence number가 1로 다
시 시작하므로 기존의 archive file들은 필요가 없어지므로 보관하
지말고 지우도록 하자. Archive log list 명령을 통해 그 결과를 확
인할 수 있다.)

cf. ) resetlogs option을 사용해서 open 하는 이유는 checkpoint !
control file의 checkpoint number는 현재이지만 나머지 recovery된
datafile의 그것은 recovery된 과거시점으로 변했을 것이므로 log
sequence number를 처음부터 다시 시작하여 각각의 checkpoint
number를 맞추어야 할 것이다.



Cancel base recovery ( case #1 : inactive redo log group의 유실)

- inactive log group의 유실이라면 현재의 원래 상태로 만드는
recovery 이기 때문에 비록 incomplete recovery 이지만 본래의
databse 자체는 문제가 없으므로 full restore가 필요없고 open시
resetlogs 도 필요치 않다. 즉, 이미 inactive log group이라면 log
switch가 발생했을 것이고 그 정보는 archive로 저장되었으므로 유
실된 log group을 논리적으로 삭제후 다시 만드는것으로 recovery
가 족하다 할 수 있겠다)

1. shutdown abort (immediate option을 줄 경우 유실된 log file에
transaction 발생시 server process가 죽으므로 인해 DB hang이
걸릴 수도 있으므로 추가적인 oracle session이 발생하지 않고
waiting 할 수도 있다. 따라서 hang이 걸린 경우라면 abort를 하
자)

2. startup mount (v$logfile, v$log를 확인하여 유실된 log filename
and log group number 확인)

3. alter database drop log file group grp_no ;
(유실된 log group drop)

4. alter database add logfile group grp_no ‘/././..3a.rdo’ size 150K ;
(유실된 log group을 대체할 log group 생성)

5. alter database add logfile member ‘/../../..3b.rdo’ to group
grp_no ;
(생성된 log group에 원래의 형태를 갖도록 계속적으로 member
추가)
(최초 log file 생성시 status는 invalid 이지만 DB open 후 정상으
로 바뀌게 된다 : v$logfile 에서 확인)


Cancel base recovery ( case #2 : active redo log group의 유실)

- 이 경우는 전형적인 cancel base recovery로서 active log group 외
에 다른 datafile이 함께 유실되어도 상관없이 똑같은 절차를 따른
다. 이런 경우는 어쩔수 없이 current log group의 data는 잃어버리
고 바로 전 까지 상황으로 돌아가는 incomplete recovery 로 cancel
base recovery 외에는 방법이 없기에 당연, full restore datafile을 해
야한다.

- 작업전, alert log나 arch..trc를 확인하여 error난 log sequence
number를 확인해서 recovery 시 이 확인된 번호에서 cancel 해야한
다. (current status의 log file은 drop logfile이 되지 않고 (current
log group이 drop 된다면 그 안에 정보는 어디에도 남아있지 않을
것이므로 current log group의 drop은 있을 수 없다) 당연히 합법적
DB hang이 걸릴 것이다. Log switch가 이루어 져도 archive가 종료



되지 않으므로 다음 log switch시 이전 log의 archive가 완료될 때까
지 계속 waiting 할 것이다.)

1. shutdown immediate

2. datafile full restore

3. startup mount

4. recover database until cancel (alert log나 archive trace file에서
찾아낸 log sequence number가 나올 때까지 recovery 수행 후 그
시점이 되면 즉, 그 log sequence number가 나오면 cancel 한다)

5. alter database open resetlogs ; (유실된 current log file이 자동으
로 생성된다)

6. shutdown and startup (log sequence가 초기화 되었으므로 불필
요한 구 files 즉, archive나 trace file등은 모두 삭제하고 offline
full backup을 실시 한 후 다시 startup 한다)

Time base recovery (실수로 drop한 table의 복구등 특정 시간
으로 되돌아 가기)

예를 들어 어느 시간에 (1999년 5월 3일 12시 30분 40초) 누군가
drop table tab_name cascade constraints ; 를 한 후 다시 되돌려 달
라는 요구가 있다면 time base recovery가 유용할 것이다. 사실 대부
분의 recovery는 disk failure등 잘 일어나지 않는 datafile이 유실되
는 경우가 아닌 한 time base recovery가 주를 이룬다.

되돌아갈 정확한 시간을 아는 것이 중요할 것이다.

1. shutdown immediate

2. datafile full restore

3. startup mount

4. recover database until time ‘1999-05-03:12:30:40’


6. shutdown and offline full backup (불필요한 file들 정리)

7. startup

예) Which situation would require you to perform an incomplete recovery operation ? 1
1. All control files have been lost, including the mirrors
2. One of the mirrored control files has been lost
3. The disk containing the archived redo logs has failed
4. The operation system has crashed



You have recreated the control file for recovery purposes. Which file can you now check to see
how many control files were recreated ? 1
1. Init.ora 2. Alert.log 3. Sys.log 4. Config.ora



Control file recreation and recovery using control file

Control file recreation

Nomount 상태에서 작업 (mount는 control file을 사용하니까)

Control file에 변경을 주는 command :
alter database add logfile , logfile member
alter database rename file
alter database drop logfile group, logfile member
create tablespace
atler tablespace add datafile, rename datafile
alter tablespace read write, read only
drop tablespace
alter database noarchivelog, archivelog

Option : reuse, set database, database, logfile, resetlogs,
noresetlogs, datafile, maxlogfiles, maxlogmembers, maxloghistory,
maxdatafiles, mininstances, archivelog, noarchivelog

Procedure
1. shutdown, offline full backup

2. control file option 편집

3. startup nomount

4. create control file

5. recover database ;


위중 reuse option은 max관련 parameter를 수정한 경우에는 사용
할 수 없다. Max parameter는 변경시 반드시 control file을 새로 만
들기 때문.

DB running 중 control file 생성 script를 자동으로 만든후 all
control file이 유실되어서 control file recovery
1. alter database backup controlfile to trace ;
(udump dest에 trace file로 script 생성)

2. 모든 control file이 삭제 되었다고 가정하면….
Shutdown abort

3. startup nomount



4. SVR> @crt_cont.sql (작업 1에서 만들어진 script를 crt_cont.sql 로
rename 해 두었다고 생각하면)

5. Alter database open ;
(Control file이 새로 만들어졌으니 DB open)

Cf) 생성된 script를 보면 script 안에 작업3, 5의 내용도 함께 들어
있고 만일, read only tablespace가 있었다면 datafile을 규정하는 부
분에는 이 tablespace 관련 내용이 다른 이름으로 사용되며 control
file 재 생성후 alter database rename file command로 원래의
datafile로 rename하는 과정을 거친다)

Control file이 유실된 상태에서 control file script도 없고 단지
backup 된 control file만 존재하는 경우 (archive mode에 상관
없이 적용되는 recovery)

1. shutdown 상태에서

2. cp backup control file to 원래위치의 control file

3. startup mount (당연히 old control file 과 현재 datafile간의
checkpoint number가 일치하지 않으니 open은 안되겠지)

4. read only tablespace가 있는경우 offline 필요
alter database datafile ‘/…/read_only.dbf’ offline ;

5. recover database using backup controlfile ;
(archivelog mode라도 archive 적용할 필요가 없으므로 redo log
file만 적용, recovery시 묻는 redo log file의 위치를 full path로 직
접 입력한다. 이 작업은 redo log file을 가지고 synchronization
information을 맞추는 작업이므로 어떤 redo log member가 적절
할지 알 수가 없으므로 recovery가 complete 될 때까지 계속해서
다른 member로 recover database command를 입력한다.)
(recovery가 끝나면 ‘Media recovery complete’ message가 나올
것이다.)


7. alter tablespace read_only online ;

8. shutdown (구 trace file, archive file 삭제 및 offline full backup)

cf) 이 경우 control file과 함께 특정 datafile이 동시에 유실되어도
동일한 작업과정을 거친다. 다만 error난 datafile에 대한 restore 작
업이 추가되고 작업 5의 command 후 cancel base recovery 처럼 최
종 archive 까지 적용하고 난 후에 종료하지 말고 redo log member
에 대한 full path를 입력해서 동기화 정보를 맞추는 점만 유의하면
된다.



Logical backup and recovery

Export / Import

 DB running 중 특정시점에 data를 offline dump file로 저장
(data + table 정의 + 각종 objects)

 다른 machine 으로 data 이동 (database copy)

 export 받은 date가 import시 recovery date

 export후 import 하면 migrated rows 및 fragmentation 제거

Export

Exp/imp mode -– command line (직접 입력)
interactive (Q and A)

Exp method –- conventional
direct-path

Export username/password…opt1..opt2.. [tables=, owner=, full=]
export로 data를 받는 mode는 table name을 직접 기술하는 table
mode, 한 schema의 object를 받는 usermode 그리고 전체 database
를 다 받는 full database mode 3가지 방식이 있는데 이중 full
database mode는 ‘exp_full_database’ 라는 role을 grant 받아야 한
다)

Option : userid, buffer, compress, file, grants, rows, [full, owner,
tables], indexes, constraints, recordlength, direct, inctype, record,
log, consistent, statistics, indexfile, charset

위 option을 하나의 text file에 기술하고 parfile 명령을 사용하면 한
번에 command line에서 export가 가능하다. 예를 들면 exp_db.par
이라는 file에 각종 필요한 option을 기술했다면 다음과 같이 ‘exp
parfile=exp_db.par’ 한번의 명령으로 export가 진행된다.

Consistent option은 for set of tables that must be synchronized.
(foreign key – primary key relationships) This option could require
large rollback segments.

Buffer option은 default 방식인 conventional path를 사용하는 경우
에만 유효하고 direct-path사용시, direct=y인 경우에는
recordlength를 사용해야 하고 command line에서만 가능하다.

Index option은 export시 definition만 가져오고 나중에 import 시점
에서는 그 definition을 이용하여 새로이 index를 creation 한다.



(indexfile option 은 index definitiion을 file로 받아주고 charset
option은 export시 character set을 지정해 준다)

Export시 inctype은 full=y 를 사용할 수 있는 경우에만 사용되
며 3가지 type이 있다

1. Complete : 전부다 export
2. Cummulative : complete export 또는 마지막 cummulative 이후
에 변경된 사항만 export (incremental export는 무시)
3. Incremental : 어떤 type 이든지 최근 export 이후에 변경된 사항
만 export

변경사항이란 : 변경사항이란 object에 변경이 있는경우 변경된 부
분만 말하는 것이 아니라 변경된 내용을 포함하는 object 전체를
export 한다는 뜻이다. 즉, 어떤 table에 100만건 중 1건만 변경이 있
었어도 100만건을 모두 다 export 한다.
당연히 이를 인지하기 위해서는 sys 소유의 table에(incexp, incfil)
정보를 기록하게 되는데 이것을 가능하게 해주는 script가 보통
install시 작업하게 되는 catexp.sql 이다.

NLS를 이용한 export
NLS_LANG=American_America_US7ASCII
(message) (date fmt) (data and object name)

Direct-path export (direct=y)

DB resource에 대한 다른 process와 경쟁하지 않고 읽는데 필요한
자원은 PGA를 사용한다. Data 전송을 위해서는 TTC buffer를 사용
하므로 불필요하게 일반 buffer option을 사용할 필요가 없다.

The recordlength parameter can be used with direct-path export to
specify the size of export I/O buffer. This operating-system
dependent parameter can be increased to improve performance.
The maximum value of this parameter is 64KB.

또한 export시 최적화된 자신만의 SQL문을 사용하는데 예를 들면
‘select * from table’처럼 where 조건절 없이 사용하여 최소의 시간
을 요하도록 한다. Command line에서만 사용이 가능하므로
interactive한 방식은 사용할 수 없고 작업전 server side 와 client
side의 character set이 반드시 일치해야 한다.

Cf) 이런 export file은 export한 Oracle version 보다 낮은 version으
로의 import가 불가하다.



Import

Order : 1. Create table (new table 이므로 앞으로 archive가 적용될
수 없겠지)
2. Data insert
3. Index creation
4. Trigger creation
5. Constraint creation

Import username/password…opt1..opt2.. [tables=, fromuser=,
touser=, full=]
import시 data를 insert 할때, table name을 직접 기술하는 table
mode, export file에서 한 schema의 object를 받아 특정 schema를
지정하는 usermode 그리고 전체 database를 다 받는 full database
mode 3가지 방식이 있는데 이중 full database mode는
‘imp_full_database’ 라는 role을 grant 받아야 한다)

Option : userid, buffer, file, show, grants, rows, ignore, [full, tables,
(fromuser, touser)], commit …

Ignore option은 기존 object에 대한 import시 duplication error를
발생시키지 말라는 option이고 commit option은 buffer크기 만큼
insert 작업후에는 commit을 수행하라는 option.

export와 마찬가지로 위 option을 하나의 text file에 기술하고
parfile 명령을 사용하면 한번에 command line에서 import가 가능
하다. 예를 들면 imp_db.par 이라는 file에 각종 필요한 option을 기
술했다면 다음과 같이 ‘imp parfile=imp_db.par’ 한번의 명령으로
import가 진행된다.

예) If you the Export Utility for backup purpose and choose incremental as the export type,
which objects will be exported ? 1
1. Only objects that have been updated since the last export of any type
2. Only objects that have been updated since the last incremental export
3. Only objects that have been updated since the last complete export
4. All objects since the last the last incremental export

Solution procedure

1. alert file or 각종 trace file 확인

2. v$recover_file_status, v$recover_file (PGA에 존재하고 사용이 끝
나면 dealloc 된다)

3. online redo log 문제 감지/복구 <- checksum 사용가능

4. backup datafile 에 문제확인 <- dbv 사용가능

cf)v$recover_file_status 구성 : filenum, filename, status
(status : inrecovery, current, not recovered)



checksum : init parameter에서 log_block_checksum = ture 로
setting하면 redo log file에 이상유무를 확인하여 이상이 있는경우
다른 member를 사용해보고 group이 이상이면 archive가 안되므로
DB의 합법적 hang이 걸리게된다. 따라서 더 이상 작업진행이 안될
것이고 이 group은 recovery에 사용이 안되겠다. 해결하기 위해선
‘alter database clear logfile log_name’ command를 사용할 수 있다.
물론 이것은 redo log file에 대한 error를 미연에 방지할 수 있겠지
만 performance의 저하를 가져올 수 있다.(당연, file의 정상유무를
check하는 시간이 필요하니까) 이와 유사한 것으로 datafile을
check하는 db_block_checksum parameter가 있다.

dbv : 이는 하나의 utility로 datafile의 상태를 확인할 수 있는 것으
로 datafile의 online 유무와 상관없이 그리고 backup file이든 아니
든, DB running과 상관없이 사용이 가능하다.
사용은 O/S 상에서 datafile을 verify하고 결과를 return한다.
$ dbv datafile_name.dbf



Standby database

Primary and Standby

disaster를 대비한 일종의 backup and recovery의 일환으로
primary database가 live 상태고 standby database는 primary와 같
은 상태로 유지시켜서(지속적인 archive 적용) primary database가
이상이 생기는 경우 standby database를 primary database로 전환
하는 방법으로 사용하게 된다.

Oracle V7.3 이상에서만 사용이 가능하고 primary와 standby는
version, release and fetch가 동일한 database 이어야 한다. 무조건
적이지는 않지만 가능한 primary와 standby는 동일한 구조 즉,
directory, name, sid등을 똑같이 구성하여 문제발생시 최단시간 내
에 전환할 수 있도록 하는 것이 좋을 것이다.

구성 및 사용

primary에서 archive file을 다른 machine에 존재하는 standby
database로 copy후 archive 적용하는 형태로 구성한다.

생성시 copy후 : standby 적용 및 활성화 절차
alter database create standby controlfile as ‘/u03…../…ctl’ ;
alter system archive log current ;
recover standby database ;
alter database activate standby database

이후 primary에서 archive file을 copy하여 지속적으로 적용시킨다.
즉, recover 한다
recover standby database ;

 A standby database control file cannot be created from a
backup_control file on the primary database.
The standby database must be mounted, but not opened, and
then put into standby recovery mode.

 Standby database는 항상 recovery mode로 있어야 한다.
Standby database는 한번 activate 되면 다시 원 상태로 될 수
없고 따라서 standby database를 활성화 시킨 후에는 standby
database가 primary database가 되므로 다시 새로운 standby
database를 만들어야 한다.



Simple test

Question

1. You are in the process of recovering your database. You have restored the most recent
backup copies of the corrupt datafiles and Oracle7 has completed the roll-forward operation
to the end of the last redo log. What is the next phase of the recovery operation that is
critical for a complete recovery?
a. Nothing the database is now fully restored and ready to be opened to users.
b. Oracle7 automatically rolls back uncommitted transactions
c. Oracle7 synchronizes the database files
d. You must do a full offline backup

2. The production instance has failed an in viewing the alert log you discovered that PMON
process experienced a failure. What will you have to do to bring the database back online?
a. restart the instance
b. reboot the operating system then restart the instance
c. restart the PMON process
d. shutdown and recover process

3. A datafile was lost due to media failure and you are restoring the database. One of the
archive log files is missing and can only restore to the last valid archive log. What is the
result of this incomplete recovery?
a. committed transactions for all database files are lost from the point of recovery and must
be manually re-entered
b. uncommitted transactions for all database files are lost from the point of recovery and
must be rolled back
c. committed transactions for the lost database files are lost from the point of recovery and
must be manually re-entered
d. uncommitted transactions for the lost database file are lost from the point of recovery and
must be defined and re-entered by the users

4. A user attempted an INSERT in the employee table causing an extent to be allocated but
there was insufficient free space left in the tablespace. Which type of failure is this?
a. instance failure b. statement failure c. user process failure d. media failure

5. Which role has the default privileges necessary to export and import the entire database?
a. DBA b. RESOURCE c. CONNECT d. EXP

6. There are so many update transactions in a database when you export. Which option can
you use for this situation?
a. buffer b. compress c. length d. consistent

7. Which command will show you physical structure of present database? (command)

8. You can use arch process automatically by the command ‘alter database archive’. (T or F)

9. Describe import procedure?

10.’alter tablespace tabspc_name begin backup’ command is for physical backup?



11.What kind of files do you have to restore for incomplete recovery?
a. all data file b. redo log file c. control file d. parameter file e. above all files

12.You work for some store. The only price table is important and the table is hardly changed.
If you recover this database, the most important thing is minimizing recovery time and your
boss allows a little data loss. Which backup method will you recommend?
a. online full backup b. offline full backup c. export backup d. archive

13.Which of the following could you do to recover data lost due to user error? (multi)
a. restart the database b. introduce a roll forward at startup c. bring back a table export
d. use a point-in-time recovery e. recover the data from a valid backup

14.Identify some of the common causes of media failure. (multi)
a. a disk head crash b. an accidentally erased file c. a power outage
d. an accidentally dropped table e. an operating system crash

15.What dose your recovery strategy in the event of media failure depend on? (multi)
a. the backup method you chose b. the files that are affected
c. the version of Oracle that you are d. the business rules of your organization

16.During the roll-forward process, only committed transaction change are applied to the data
files. (T or F)

17.Complete the command to manually disable automatic archiving of redo log file groups.
Alter system archive ______ ;
a. start b. stop c. pause d. continue

18.Which variables identify the valid log sequence number? (multi)
a. %s b. %n c. %S d. %N e. %sn f. %SN

19.If files are damaged and an user dropped table incorrectly, but you don’t know when the
damage occurred, you perform a ____ recovery.
a. cancel-based b. time-based c. change-based d. datafile-based

20.Which of the following are the export modes available in the Export utility ? (multi)
a. column b. full database c. grant d. user e. table

21.Identify the correct statements regarding the DBVERIFY utility. (multi)
a. it can only be used on complete data files in the database
b. it is external to the database c. it can verify backups d. it cannot verify online files

22.Which command can be issued for database recovery if archived files are in the
LOG_ARCHIVE_DEST location?
a. set autorecovery on
b. recover database
c. recover database using backup control file
d. alter database archivelog

23.Which situation would require you to perform an incomplete recovery operation?
a. all control files have been lost, including the mirrors
b. one of the mirrored control files has been lost
c. the disk containing the archived redo logs has failed
d. the operating system has crashed



Answer

1.b, 2.a, 3.a, 4.b, 5.a, 6.d
7.alter database backup controlfile to trace
8.False(자동은 init parameter)
9.create table-data insert-index creation-trigger creation-constraints
10.False (physical backup은 이 명령후 O/S상에서 하는 cp 명령이다)
11.e, 12.c, 13.c-d-e, 14.a-b, 15.a-b
16.False, 17.b, 18.a-c, 19.a, 20.b-d-e
21.b-c, 22.a, 23.a


OracleHistory2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie OracleHistory2

Ähnlich wie OracleHistory2 (20)

Mehr von Kyung Sang Jang

Mehr von Kyung Sang Jang (17)

OracleHistory2