Home     FreeBSD     Linux     MS-Window     PHP     Data Base     Utility     Phone     Etc  

   
  Category : Data-Base         CHAPTER 24수정   삭제   
CHAPTER 24

Database Recovery




Recovery Procedures
Recovery Features
An Introduction to Database Recovery
Performing Recovery in Parallel
Recovery from Instance Failure
Recovery from Media Failure




Recovery Procedures
어떠한 형태의system failure로 인한 recovery에도 다음을 요구한다.
어떤 data 구조가 손상되지 않고 어떤 구조가 복구를 요구하는지 결정한다.
적절한 복구 과정을 시행한다.
정상적인 운영을 할 수 있도록 database를 재기동 한다.
손실된 작업이 있는지 database 내에 부적절한 data가 있는지 검토한다.

Recovery Features
Oracle은 복구 전략의 유연성을 제공하는 다음의 특징들을 제공한다.
System , software, hardware로부터의 recovery
Database start up시에 자동으로 database instance recovery
Database의 나머지는 선택적인 반면에, 개별적인 offline tablespace나 file들의 recovery
Database administrator에 의해 지정된 transaction-consistent 상태로의 time-based와 change-based recovery
System failure시 recovery 시간에 대한 향상된 control
Recovery 시간을 줄이기 위해 redo log entry들을 병렬적으로 적용하는 능력
물리적 file backup 보다는, 오히려 논리적 data format으로 data를 archiving하고 restoring하는 export/import utility

An Introduction to Database Recovery

Database Buffer and DBWR
SGA내의 database buffer들은 필요할 때에만 least-recently-used algorithm을 사용하여 disk에 쓰여진다.

Instance failure가 발생한다면, 두 가지 잠재적인 문제가 있다.
Transaction에 의해 변경된 data block은 commit시 redo log에만 존재하고 datafile에 쓰여지지 않았을 수도 있다.
Redo log가 아직 commit 되지 않은 data를 포함하고 있을 수 있으므로 redo log의 적용으로 인한 commit 되지 않은 변경은 database에서 삭제되어야 한다.

위의 두 문제점 해결을 위해 Oracle은 redo log를 이용한 rolling forward와 rollback segment를 이용한 rolling backward를 제공한다.

The Redo Log and Rolling Forward
Redo log는 commit의 여부에 관계없이 data, index, rollback segment를 포함하는 database buffer에 가해진 모든 변화를 기록하는 operating system file들의 집합이다. Redo log는 아직 datafile에 쓰여지지 않은 memory상의 database buffer에 가해진 변화를 보호한다.

Instance나 disk failure로부터의 복구 첫 단계는 roll forward 또는 redo log에 기록된 모든 변경을 datafile에 적용하는 것이다. Rollback data 또한 redo log에 기록되어 있으므로 rolling forward는 해당 rollback segment도 재생성 한다.

Rolling forward는 database를 일정 시점으로 돌리기 위해 요구되는 만큼 redo log file을 적용시킨다. Rolling forward는 보통 online redo log file들을 포함하며 archived redo log file들을 포함하기도 한다.

Roll forward 후에, data block은 redo log에 기록된 commit된 data와 commit 되지 않은 data를 모두 포함한다.

Rollback Segment and Rolling Back
Rollback segment는 database 운영 중에 반드시 undo 되어야 할 database action을 기록하고 있다. Database recovery 중에 rollback segment는 rolling forward phase에 의해서 적용된 commit 되지 않은 transaction을 undo한다.

Roll forward 후에, 해당되는 rollback segment가 이용된다. Rollback segment는 commit 되지 않은 그러나 redo log의해 적용된 transaction을 식별하고 undo하는데 이용된다. 이 과정을 Rolling back이라고 부른다.

Oracle release 7.3이 start할 때에 필요하다면 동시에 복수의 transaction들을 roll back 할 수 있다. Failure 시점에 active 된 모든 system 전반에 걸친 transaction들은 DEAD로 표시된다. Dead transaction들을 roll back 하기 위해서 SMON에 대해서 waiting 하는 대신에, 새로운 transaction들은 필요한 row lock들을 얻기 위해서 block하는transaction들을 recover 할 수 있다. 이러한 특징을 fast transaction rollback이라 부른다.

Performing Recovery in Parallel
Serial recovery에서는 하나의 process가 redo log file들의 변경을 순차적으로 적용시킨다. Parallel recovery에서는 몇 개의 process가 redo log file들의 변경을 동시에 적용시킨다.

Parallel recovery의 한 형태는 몇 개의 Server Manager session을 열고 각 session마다 다른 datafile에 대해 RECOVER_DATAFILE command를 지시하는 것이다. 그러나 이 방법은 각 Server Manager가 전체의 redo log file을 읽도록 유발할 수 있다.

Instance와 media recovery는 initialization parameter를 지정하거나 또는 RECOVER command에 command line option들을 지시하여 자동으로 병렬적으로 수행될 수 있다. Oracle Server는 여러 개의 recovery process가 log file 들로부터의 변경을 datafile에 적용시키도록 하나의 process가 순차적으로 log file들을 읽고 dispatch 하게 할 수 있다. Recovery process들은 Oracle에 의해 자동으로 시작되어 복구를 수행하는데 하나 이상의 session을 이용할 필요가 없다.

What Situations Benefit from Parallel Recovery
일반적으로, Parallel recovery는 별도의 disk상의 몇 개의 datafile에 동시에 복구되어야 하는 경우 복구 시간을 줄이는데 가장 효과적인 방법이다. 다른 disk상의 많은 datafile에 대한 Crash recovery(instance failure후의 recovery)와 media recovery는 parallel의 좋은 대상이 된다.

Recovery Process
전형적인 parallel recovery 상황에서, 하나의 process가 redo log file들로부터 redo entry를 읽고 dispatch하는 책임을 수행한다. 이 process는 전형적으로recovery session 또는 Server Manager session이나 ALTER DATABASE RECOVER... command를 이용하는 application을 시작하는 dedicated server process이다.
Redo log file들을 읽는 server process는 두개 이상의 recovery process가 redo entry로부터 datafile에 변화를 적용시키도록 협력한다.
대개의 경우 하나의 recovery session과 복구를 요구하는 datafile을 포함하는 disk 당 하나나 두개의 recovery process로 충분하다.
Recovery는 CPU-집중적인 활동과 반대의 disk-집중적인 활동으로서 recovery process의 개수는 recovery에 관여된 disk drive의 개수에 종속적이다. 일반적으로 parallel recovery가 serial recovery보다 좋은 성능을 보이려면 최소 8개의 recovery process가 요구된다.

Recovery from Instance Failure
Instance가 의도적이건 아니건, abort되면, instance failure가 발생하고 instance recovery가 요구된다. Instance recovery는 database를 instance recovery 직전의 transaction-consistent한 상태로 돌린다.

Online backup 시에 instance failure가 발생하면 media recovery가 요구된다. 모든 경우에 Oracle은 자동으로 database가 재시동 될 때 instance recovery를 수행한다. 필요하다면, Mount된 상태에서 open 상태로의 전이는 자동으로 다음 과정으로 구성되는 instance recovery를 trigger한다.
Rolling forward
Rolling back
Failure 시 진행 중이던 transaction에 의한 lock을 release
Instance failure 시점에 진행 중이던 two-phase commit 하의 distributed transaction을 resolving

Read-Only Tablespaces and Instance Recovery
Instance recovery 후에 read-only datafile에 대한 recovery는 요구되지 않는다. Startup 동안에, recovery는 online read-only file들이 어떤 media recovery도 요구하지 않는지 확인한다. 즉, Read-only가 되기 전의 backup으로부터 file 이 복구되지 않는다. Read-only가 되기 전의 backup으로부터 file들을 복구시키면 media recovery가 완료될 때까지 tablespace를 access 할 수 없다.

Recovery from Media Failure
Media failure로부터의 recovery는 database가 운용되는 archiving mode에 따라 두 가지 형태를 가진다.

만약 database가 그것의 online redo log가 재사용되고 archive되지 않을 때에만 운영된다면(NOARCHIVELOG mode), media failure로부터의 recovery는 최근의 full backup으로부터 단순히 restore하는 것이다. Full backup 이후에 수행된 모든 작업에 대해서는 수동으로 시행해야 한다.
만약 database가 그것의 online redo log가 archive될 때에만 운영된다면(ARCHIVELOG mode), media failure로부터의 recovery가 손상된 database를 media failure전의 특정 transaction-consistent상태로 reconstruct하는 실제 복구 작업이 될 수 있다.

다음 session들은 ARCHIVELOG mode라고 가정하고 진행된다.

Read-Only Tablespaces and Media Recovery
보통 media recovery는 datafile의 read-only 상태를 검토하지 않는다. Read-only tablespace의 media recovery를 수행할 때, tablespace가 read-only로 된 시점과 최근에 backup을 수행한 시점이 대해서 세가지 가능한 option이 있다.

Case 1
마지막 backup을 수행했을 때에 read-only이고, recovery 될 tablespace도 read-only인 경우. 이 경우 단순히 backup으로부터 tablespace를 restore한다. Redo 정보를 적용할 필요가 없다.
Case 2
마지막 backup을 수행했을 때에 read-only이나, recovery 될 tablespace가 writeable인 경우. Tablespace를 backup으로부터 restore하고 tablespace가 writeable인 시점으로부터의 redo 정보를 적용한다.
Case 3
마지막 backup을 수행했을 때에 writeable이나, recovery 될 tablespace가 read-only인 경우. Backup으로부터 tablespace를 restore하고 read-only가 된 시점까지 복구한다.

Writeable datafile과 다르게 read-only datafile은 media failure 발생시 자동으로 offline되지 않는다.

Complete Media Recovery
Complete media recovery는 모든 손실된 변경을 복구한다. Complete media recovery는 모든 필요한 redo log(online 과 archived)들이 사용 가능할 때 가능하다.

손상된 file들과 recovery 시에 요구되는 database의 availability에 따라 다른 종류의 complete media recovery가 있다.

Closed Database Recovery
전체나 개개의 손상된 datafile의 complete media recovery는 database가 mount 될 수 있지만 close되어 일반적인 형태로 완전히 사용할 수 없는 경우 진행될 수 있다. Closed database recovery는 다음 상황에 이용된다.
Database가 open될 필요가 없다.(손상 받지 않은 부분이 사용될 필요가 없다.)
Disk failure에 의해 손상된 file들이 SYSTEM tablespace를 구성하는 file 이나 active rollback segment를 구성하는 file들이다.

Open Database-Offline Tablespace Recovery
Complete database recovery는 database가 open된 상태에서 진행될 수 있다.
Database가 손상 받지 않은 tablespace가 online이고 사용 가능 상태이고, 손상된 tablespace가 offline이고 손상된 tablespace을 구성하는 모든 file들이 하나의 단위로서 복구된다. Offline tablespace recovery는 다음과 같은 상황에 사용된다.
Database의 손상 받지 않은 tablespace들은 정상적인 사용에 대해서 반드시 사용 가능 상태여야 한다.
Disk failure에 의해 손상된 file들이 SYSTEM tablespace 또는 active rollback segment를 포함하는 tablespace들을 구성하는 어떠한 datafile들을 포함하지 않는다.

Open Database-Offline Tablespace-Individual Datafile Recovery
Complete database recovery는 database가 open된 상태에서 진행될 수 있다. Database의 손상 받지 않은 tablespace가 online이고 사용 가능 상태이고, 손상된 tablespace가 offline이고 손상된 tablespace와 관련된 특정 datafile이 복구된다. Individual datafile recovery는 다음과 같은 상황에 사용된다.
Database의 손상 받지 않은 tablespacee들은 정상적인 사용에 대해서 반드시 사용 가능 상태여야 한다.
Disk failure에 의해 손상된 file들이 SYSTEM tablespace 또는 active rollback segment를 포함하는 tablespace들을 구성하는 어떠한 datafile들을 포함하지 않는다.

Complete Media Recovery Using a Backup of the Control File
Complete media recovery는 disk failure로 인해서 심지어 모든 control file의 모든 copy가 손상 받아도 data 손실 없이 진행될 수 있다.
Datafile backup의 media recovery는 심지어 control file들이 backup 이라도 수행될 수 있다. Control file은 media recovery에 의해 복구되지 않는다; Database open시의 RESETLOGS가 control file을 복구한다.

The Mechanisms of Complete Media Recovery
다음은 Database가 open 되어 있고 손상된 tablespace가 offline일 때 손상된 datafile의 complete media recovery의 예이다. 다음을 가정한다.
Database는 세 개의 datafile을 가진다:
USER1과 USER2는 database server의 Disk X에 저장되어 있는, USERS tablespace를 구성하는 datafile들이다.
SYSTEM은 database server의 Disk Y에 저장된 SYSTEM tablespace를 구성하는 datafile들이다
Database server의 Disk X가 crash된다.
Disk failure시 쓰여진 online redo log file은 log sequence number 31을 가진다.
Database는 ARCHIVELOG mode이다.

Disk X가 손상되었으므로 USERS tablespace를 구성하는 두개의 datafile의 복구가 필요하다. System은 자동으로 tablespace를 offline으로 만들었다. 이 경우 SYSTEM tablespace의 datafile은 손상 받지 않았다. 그러므로 database 는 online SYSTEM tablespace를 이용하여 open 될 수 있고 복구를 요하는 offline tablespace에 대해 복구가 완료될 때까지 사용 가능하다.

다음은 complete media recovery의 phase를 기술한다.
Phase 1: Restoration of Backup Datafiles Disk X가 수리된 후 손상 받은 datafile USERS1, USERS2를 restore 하기 위해 가장 최근의 backup file이 이용된다.
각 datafile header는 datafile이 쓰여진 가장 최근의 log sequence number를 포함한다. 복원된 backup file은 Disk failure에 영향받지 않은 datafile보다 작은 log sequence number을 가질 것이다. Control file은 쓰여진 마지막 log sequence number에 대한 pointer를 포함한다.

Phase 2:Rolling Forward with the Redo Redo log를 datafile에 적용시킨다. Oracle은 자동으로 복원될 backup datafile에 대한 redo 정보를 포함하지 않는 redo log file을 감지한다. Oracle은 복원될 datafile에 대해 그런 redo log를 적용하지 않음으로써 복구 과정을 최적화한다.
현재 redo log의 header에는 복원될 datafile에 적용될 가능한 마지막 redo log file 인지를 지시하는 flag가 있다.

Phase 3:Rolling Back Using Rollback Segments 필요한 redo log가 손상된 datafile에 적용된 후 phase 2에 의해 존재하는 모든 commit 되지 않은 data가 제거되어야 한다. 이것은 tablespace가 online되고 지연된 rollback segment가 적용됨으로써 완료된다.
Rollback이 완료되면 USERS1과 USERS2는 Disk 손상 전의 상태로 돌아가게 된다. Tablespace의 모든 data는 consistent하고 사용 가능하다.

Incomplete Media Recovery
특별한 경우(모든 online redo log file 의 손실, 중요한 table을 삭제하는 user error)에 complete media recovery는 사용할 수 없거나 필요 없을 수도 있다. 이 경우 incomplete media recovery가 손상된 database를 media failure나 user error전의 transaction consistent한 상태로 재구성한다.
상황에 따라 다른 종류의 incomplete media recovery가 사용된다.

Cancel-Based Recovery
특정 경우에 database administrator가 특정 시점의 조작을 취소할 수 있도록 incomplete media recovery는 반드시 제어되야 한다. 특히 cancel-based recovery는 하나 이상의 redo log group이 media failure에 의해 손상되어 요구되는 복구 작업을 위해 이용될 수 없을 때 사용된다. 하나 이상의 redo log group이 사용 가능하지 않으면 손실된 redo log group은 복구 과정 중에 적용될 수 없다. 그러므로 media recovery는 복구 작업이 반드시 가장 최근의, 손상 받지 않은 redo log group이 datafile에 적용된 후 종료되도록 제어되어야 한다.

Time-Based and Change-Based Recovery
Database administrator가 과거의 특정 시점으로 복구하고자 할 때 요구된다. 다음의 경우에 이용된다.
User가 실수로 table을 삭제하고 대충 그 시간을 알 때. Database administrator는 즉시 database를 shutdown시키고 user error 발생 전 시점으로 복구한다.
System failure로 인해 online redo log file이 부분적으로 손상 받았을 때. 이때 active online redo log file이 갑자기 사용 불가가 되었으므로 database instance는 abort되고 media recovery가 요구된다. 손상 받지 않은 현재 online redo log file의 일부만이 적용될 수 있다. 이 경우 database administrator는 datafile에 가장 최근의 online redo file의 유효한 부분만을 적용시킨 후 정지시키기 위해 time-based recovery를 이용할 수 있다.

두 경우 모두 incomplete media recovery의 endpoint는 특정 SCN(System Change Number)에 의해 지정될 수 있다. SCN은 transaction이 commit 될 때마다 redo log에 기록된다. 시간이 주어지면 database는 지정된 시간 직전의 transaction consistent한 상태로 복구된다. SCN이 주어지면 database는 지정된 SCN 직전의 commit 된 transaction 까지 복구된다.

The Mechanisms of Incomplete Database Recovery
몇 가지 예외를 제외하고 complete media recovery처럼 진행된다.
모든 datafile은 요구되는 복구 시점 전에 완료된 backup file을 이용하여 복원 되어야 한다.
최적의 결과를 얻기 위해 incomplete media recovery시에 이용되는 control file은 반드시 요구되는 복구 시점의 database의 물리적인 구조를 반영해야 한다. Database를 RESETLOGS option을 이용하여 open하거나 CREATE CONTROLFILE statement를 기동한 후 database를 open하면 Oracle은 현재의 data dictionary를 이용하여 control file을 cross-check한다. Data dictionary에 datafile이 추가되거나 삭제되었다면 Oracle은 순차적으로 control file을 갱신한다. 다른 변경은 error message로 보고된다.
복구는 모든 사용 가능한 redo log가 적용되기 전에 종료될 수 있다. 복구 작업은 수동으로 취소될 수 있고 stop point에 도달했을 때도 자동으로 종료될 수 있다.
Database의 log가 incomplete media recovery의 일환으로 reset되면 offline인 datafile을 포함하는 tablespace는 반드시 삭제되어야 한다.(정상적으로 tablespace이 offline되지 않으면) 그런 이유로 그런 tablespace에 대한 data를 잃지 않으려면 incomplete recovery 전에 control file을 복원하고 offline datafile를 online으로 만들어야 한다.
Incomplete media recovery가 실질적으로 complete recovery를 수행하면(미래의 SCN이 지정되어 모든 사용 가능한 redo log가 모두 적용된 경우) database는 log sequence를 reset하지 않고 open될 수 있다. 그러나 incomplete media recovery가 종료되면(또는 backup control file을 이용하여 복구가 완료된 이후) database에 대한 현재 log sequence number는 반드시 1로 reset되어야 한다. 이 작업은 모든 online redo log와 archived redo log에 존재하는 redo log entry를 invalidate시킨다. Log sequence가 reset된 후 database의 log(online과 archived)는 마치 처음 생성된 것처럼 존재하며 online redo log file은 아직 어떤 redo entry도 포함하지 않는다.


코멘트  

이름 :      비밀번호 :
         자동등록방지
내용 :  
파일 :




금연

  글번호
이름
1 2 3
날짜
  216Data-Base mysql 테이블에 몇가지 필드값 처리 조회수가 1000회 이상이네요. ^0^2015-01-14
  206Data-Base mysql 4.x 5.x 설치후 설정 조회수가 1000회 이상이네요. ^0^2014-12-30
  69Data-Base mysqld_error code 조회수가 1000회 이상이네요. ^0^2017-03-22 10:45
Danielexent
  65Data-Base .RDBMS 개요 -2 조회수가 1000회 이상이네요. ^0^2002-01-12
  64Data-Base .RDBMS 개요 -1 조회수가 1000회 이상이네요. ^0^2002-01-12
  Data-Base CHAPTER 24 조회수가 1000회 이상이네요. ^0^2002-01-12
  61Data-Base CHAPTER 23 조회수가 1000회 이상이네요. ^0^2002-01-12
  60Data-Base CHAPTER 22 조회수가 1000회 이상이네요. ^0^2002-01-12
  59Data-Base CHAPTER 21 조회수가 1000회 이상이네요. ^0^2002-01-12
  58Data-Base CHAPTER 20 조회수가 1000회 이상이네요. ^0^2002-01-12
  57Data-Base CHAPTER 19 조회수가 1000회 이상이네요. ^0^2002-01-12
  56Data-Base CHAPTER 18 조회수가 1000회 이상이네요. ^0^2002-01-12
  55Data-Base CHAPTER 17 조회수가 1000회 이상이네요. ^0^2002-01-12
  54Data-Base CHAPTER 16 조회수가 1000회 이상이네요. ^0^2002-01-12
  53Data-Base CHAPTER 15 조회수가 1000회 이상이네요. ^0^2002-01-12
 
1 2 3
글쓰기    목록   다음   로그인
Since 1998-2020 Chris. BSD LICENSE