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가지가 있다.
1. Read Error : Oracle이 read error를 발견한 경우에 Oracle은 Error Message를 application에 나타낸다.
2. 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 단계를 그림으로 나타내면,
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한다.
1. SHUTDOWN ABORT한다. 만약 Hardware문제가 일시적으 로 발생한 것이라면 Data는 손상되지 않은 것이므로 Recovery를 위한 별도의 작업이 필요하지 않다. 그러므로 Instance를 다시 STARTUP한다.
2. File이 영원히 손상된 경우라면 Media Failure로 인해 발생 한 Datafile만 가장 최근에 Backup 받은 file을 이용해 Restore한다. 손상되지 않은 Datafile은 Restore하지 않는다.
3. STARTUP MOUNT한다.
4. ALTER DATABASE ~ DATAFILE ONLINE command를 수 행한다. Recover하고자 하는 Datafile은 Complete Media Recovery하는 동안에 ONLINE이어야 한다.
5. 하나의 작업으로 모든 손상된 File을 Recovery하기 위해선 RECOVER DATABASE command를 사용한다. 개개의 손상 된 Datafile에 대해 Recovery하기 위해선 RECOVER DATAFILE command를 이용하여 Recovery를 수행한다. 참고로 최대의 Performance를 보장하기 위해선 Parallel Option을 사용할 수 있다.
6. ALTER DATABASE OPEN command를 수행한다.
7. 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를 확인할 수 있다.
2. 손상된 Datafile에 대한 Backup File을 Restore한다. 손상되지 않은 다른 Datafile이나 Redo log file이나 Control file을 Restore하지 않도록 주의한다.
3. RECOVER TABLESPACE command를 수행한다.
4. Recovery가 완료 되었으면 ALTER TABLESPACE ~ ONLINE command로 Tablespace를 ONLINE시킨다.
5. 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하는 것이 다를 뿐이다.
1. Media Failure가 발생한 시점에 DBA가 Database를 Shutdown 시켰다면 다시 Database를 OPEN 한다. Database를 Open하면 손상된 Datafile이 속한 Tablespace는 Offline으로 나타날 것이다. Data Dictionary DBA_TABLESPACES, DBA_DATA_FILES, V$DATAFILE 등에서 STATUS를 확인할 수 있다.
2. 손상된 Datafile에 대한 Backup File을 Restore한다. 손상되 지 않은 다른 Datafile이나 Redo log file이나 Control file을 Restore하지 않도록 주의한다.
3. RECOVER DATAFILE command를 수행한다.
4. Recovery가 완료 되었으면 ALTER TABLESPACE ~ ONLINE command로 Tablespace를 ONLINE시킨다.
5. Recovery가 정상적으로 수행되었는지 Database를 Check한다.
Incomplete Media Recovery
Incomplete Media Recovery란 Media Failure의 발생으로 인한 Media Recovery의 한 방법으로 Failure가 발생하기 바로 직전까지의 복구가 아닌 그 이전의 어느 특정 시점까지 Recovery를 하는 것을 말한다. 이런 의미에서 Incomplete Media Recovery는 Media Recovery의 반대 개념이라고 할 수 있으며 간단한 그림으로 표현하면 아래와 같다.
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는 다음과 같이 수행한다.
1. Failure가 발생한 시점에 아직 Database가 OPEN되어 있다면 Database를 ABORT로 Shutdown한다.
2. Recovery하는 동안 발생할 지 모를 Error에 대비해 Database 전체에 대한 Full Cold Backup을 받는다.
3. Media Failure를 야기한 Hardware 문제를 해결한다.
4. 만약 현재의 Control file이 Recovery하고자 하는 시점의 Database의 Control file과 일치하지 않는다면 (즉, Recovery 하고자 하는 시점 이후에 Datafile을 추가했다면) Recovery 하고자 하는 시점의 Database의 Physical file 구조를 반영 하고 있는 Control file의 Backup file을 Restore한다.
5. Recovery 하고자 하는 시점에서 가장 직전에 Backup 받은 모든 Database의 Datafile을 Restore한다. 예를 들면 Log Sequence # 40 까지 Recovery하고자 한다면 Log Sequence # 40 이 발생하기 전에 Backup 받은 Datafile을 Restore한다. 만약 Backup file이 없다면 Empty한 Datafile을 새로 만들어 Recovery할 수 있다.
6. STARTUP MOUNT 한다.
7. RECOVER DATABASE UNTIL CANCEL command를 수행한다.
8. Incomplete Media Recovery가 완료 되었으면 Database를 OPEN 해야 하는 데 이때 Database를 RESETLOGS로 OPEN할 것인가 아니면 NORESETLOGS로 OPEN할 것인가 를 결정해야 한다. 즉 Log Sequence #를 다시 Reset할 것인 지 아닌지를 결정함을 의미한다.
9. 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할 수 있다.
1. User의 실수에 의해 Table이 Drop되고 난 뒤 Table이 Drop된 시간을 대략 알고 있다면 DBA는 Time-Based Recovery를 적용 하여 Drop 되기 직전의 시점으로 Database를 Recovery할 수 있다.
2. 현재 사용 중인 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된다.
1. Failure가 발생한 시점에 아직 Database가 OPEN되어 있다면 Database를 ABORT로 Shutdown한다.
2. Recovery하는 동안 발생할 지 모를 Error에 대비해 Database 전체에 대한 Full Cold Backup을 받는다.
3. Media Failure를 야기한 Hardware 문제를 해결한다.
4. 만약 현재의 Control file이 Recovery하고자 하는 시점의 Database의 Control file과 일치하지 않는다면 (즉, Recovery 하고자 하는 시점 이후에 Datafile을 추가했다면) Recovery 하고자 하는 시점의 Database의 Physical file 구조를 반영하 고 있는 Control file의 Backup file을 Restore한다.
5. Recovery 하고자 하는 시점에서 가장 직전에 Backup 받은 모든 Database의 Datafile을 Restore한다. 예를 들면 Log Sequence # 40 까지 Recovery하고자 한다면 Log Sequence # 40 이 발생하기 전에 Backup 받은 Datafile을 Restore한다. 만약 Backup file이 없다면 Empty한 Datafile을 새로 만들어 Recovery할 수 있다.
6. STARTUP MOUNT 한다.
7. Recovery를 수행하기 이전에 모든 Datafile은 Online 상태 여야 한다. V$DATAFILE에서 Recovery할 Datafile을 확인해 보고 만약 Offline인 Datafile은 Online시킨다.
8. RECOVER DATABASE UNTIL TIME command를 수행한다. Time의 형식은 반드시 다음과 같은 형식으로 한다. ‘YYYY-MM-DD:HH24:MI:SS’
9. Database를 OPEN한다. 이때 RESETLOG로 OPEN할 것인지 NORESETLOGS로 OPEN할 것인지 결정한 후 이를 Command상에서 명시하여 Database를 OPEN해야 한다.
10. Database가 정상적으로 Recovery되었는지 Check한다.
Change-Based Recovery
Change-Based Recovery도 Incomplete Media Recovery의 일종으 로 다음과 같은 상황이 발생한 경우에 효과적으로 Recovery할 수 있다.
1. User의 실수에 의해 Table이 Drop되고 난 뒤 Table이 Drop된 시간을 대략 알고 있다면 DBA는 Time-Based Recovery를 적용 하여 Drop 되기 직전의 시점으로 Database를 Recovery할 수 있다.
2. 현재 사용 중인 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된다.
Change-Based Recovery는 다음과 같은 순서로 Recovery된다.
1. Failure가 발생한 시점에 아직 Database가 OPEN되어 있다 면 Database를 ABORT로 Shutdown한다.
2. Recovery하는 동안 발생할 지 모를 Error에 대비해 Database 전체에 대한 Full Cold Backup을 받는다.
3. Media Failure를 야기한 Hardware 문제를 해결한다.
4. 만약 현재의 Control file이 Recovery하고자 하는 시점의 Database의 Control file과 일치하지 않는다면 (즉, Recovery 하고자 하는 시점 이후에 Datafile을 추가했다면) Recovery 하고자 하는 시점의 Database의 Physical file 구조를 반영하 고 있는 Control file의 Backup file을 Restore한다.
5. Recovery 하고자 하는 시점에서 가장 직전에 Backup 받은 모든 Database의 Datafile을 Restore한다. 예를 들면 Log Sequence # 40 까지 Recovery하고자 한다면 Log Sequence # 40 이 발생하기 전에 Backup 받은 Datafile을 Restore한다. 만약 Backup file이 없다면 Empty한 Datafile을 새로 만들어 Recovery할 수 있다.
6. STARTUP MOUNT 한다.
7. Recovery를 수행하기 이전에 모든 Datafile은 Online 상태 여야 한다. V$DATAFILE에서 Recovery할 Datafile을 확인해 보고 만약 Offline인 Datafile은 Online시킨다.
8. RECOVER DATABASE UNTIL CHANGE command를 수행 한다. SCN#는 Quotation mark (‘`) 없이 10진수로 나타낸 다.
9. Database를 OPEN한다. 이때 RESETLOG로 OPEN할 것인 지 NORESETLOGS로 OPEN할 것인지 결정한 후 이를 Command상에서 명시하여 Database를 OPEN해야 한다.
10. 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도 포함하지 않는다.