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) 소유]

[email protected] - 2 - 장 경상

http://www.ggola.com/

mailto:[email protected]


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 restartcf) 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 mountSVR> 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 등록 후 startup2. DB down후 copy (offline backup)3. DB running중 online backup : 똑같은 file을 생성하는 것과 control file 생성 문장(text) 3.1 alter database backup controlfile to ‘$ORACLE_SID/dest/[email protected]’ [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 recovery3.1 nomout : parameter file read and SGA, Background Processes3.2 mount : control file information read3.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 listcheckpoint 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




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. Shutdown2. 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 backup6. 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후 recoveryDB 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’

5.alter database open resetlogs ;

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 memberalter database rename filealter database drop logfile group, logfile membercreate tablespaceatler tablespace add datafile, rename datafilealter tablespace read write, read onlydrop tablespacealter 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가 나올 것이다.)

6.alter database open resetlogs ;

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 : 전부다 export2. 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를 이용한 exportNLS_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 transactionsc. Oracle7 synchronizes the database filesd. 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 instanceb. reboot the operating system then restart the instancec. restart the PMON processd. 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-enteredb. uncommitted transactions for all database files are lost from the point of recovery and must be rolled backc. committed transactions for the lost database files are lost from the point of recovery and must be manually re-enteredd. 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 exportd. 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 affectedc. 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 databaseb. 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 databasec. recover database using backup control filed. alter database archivelog

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

Answer

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



OracleHistory2

Education

Transcript of OracleHistory2