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

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


Recovery Structures




An Introduction to Database Recovery and Recovery Structures
The Online Redo Log
The Archived Redo Log
Control Files
Survivability




An Introduction to Database Recovery and Recovery Structures
Database administrator의 중요한 책무는 hardware, software, network, process, 또는 system failure의 가능성에 대한 대비를 하는 것이다. System failure가 database system의 operation에 영향을 준다면, database administrator는 가능한 빨리 database들을 회복하고 정상적인 운영을 할 수 있도록 해야만 한다.

Recovery process들은 발생된 failure의 type, 영향을 받은 structure, database administrator가 수행하는 recovery의 종류에 따라 다르다. 만약 손상을 받거나 삭제된 file들이 없다면, recovery는 instance를 restart 하는 일 외에 아무것도 하지 않을 것이다. Data가 손실되면, 추가적인 과정을 요구한다.

Errors and Failures
몇 가지 문제들은 Oracle database의 정상적인 운영을 정지시키거나 또는 disk에 대한 database I/O에 영향을 준다. 이러한 문제의 대부분에 대해서, recovery는 자동으로 되며 database user 또는 database administrator들에 대해서 거의 또는 전혀 action을 요구하지 않는다.

User Error
일반적으로, user error는 database와 application principles에 대한 training을 증가시킴으로써 감소될 수 있다. 게다가, 미리 효과적인 recovery scheme을 계획함으로써, administrator는 user error들의 여러 가지 종류들로부터 recovery에 대해서 필요한 작업을 쉽게 할 수 있다.

Statement Failure
Oracle program내에서 statement를 조작하는 과정 중 논리적인 오류가 있을 때 statement failure가 발생한다. 예를 들면, table의 모든 extent들이 할당되고, data로 모두 채워졌다고 가정하자(table이 완전히 가득 찼다). 유효한 INSERT statement가 사용 가능한 공간이 없기 때문에 row를 insert 할 수 없다. 그러므로, INSERT statement가 기동 된다면, 그 statement는 실패한다.

Statement failure가 발생하면, Oracle software나 O/S는 error code나 message를 돌린다. Statement error는 보통 action이나 recovery 단계들을 요구하지 않는다; Oracle은 자동으로 statement의 결과를 rollback시키고(만약 있다면) application에 제어를 넘김으로써 statement failure를 정정한다. User는 error message가 의미하는 문제를 해결한 후 statement를 간단하게 재실행시킬 수 있다.

Process Failure
Process failure는 database instance의 user, server, background process내에서의 failure이다.(예를 들면, 비정상적인 disconnect나 process 종료) Process failure가 발생할 때, 다른 database instance가 작업을 수행할 수 있더라도, 실패 된 하위 process는 작업을 계속 수행할 수 없다.

Oracle background process PMON은 abort된 Oracle process를 감지한다. 만약 abort된 process가 user 또는 server process라면 PMON은 abort된 process의 현재 transaction을 rollback시키고 점유하고 있는 resource를 release함으로서 failure를 해결한다. 실패 된 user 또는 server process의 recovery는 자동으로 진행된다. Abort된 process가 background process이면 instance는 기능을 제대로 수행할 수 없다. 그러므로 user는 instance를 shutdown시키고 restart해야만 한다.

Network Failure
User system이 network을 이용하여(예를 들면, local area networks, phone lines등) client workstation에서 database server에 접속하거나 또는 distributed database system을 형성하기 위하여 database server에 접속하는 경우, Network failure는 database system의 정상 운용을 방해할 수 있다.
Network failure는 client application의 정상 수행을 방해하고 process failure를 유발할 수 있다. 이 경우에 Oracle background process PMON은 disconnect된 user process에 대한 abort된 server process를 해결한다.
Network failure는 distributed transaction의 two-phase commit을 방해할 수 있다. 일단 network 문제가 해결되면, 연관된 각 database의 Oracle background process RECO은 자동으로 distributed database system 의 모든 node들에서 아직 해결되지 못한 distributed transaction을 해결한다.

Database Instance Failure
Database instance failure는 Oracle database instance(SGA and background process)가 작업을 계속 수행하지 못하게 하는 문제가 일어날 때 발생한다. Instance failure는 정전과 같은 hardware 문제나 또는 operating system crash같은 software 문제로 인하여 발생할 수 있다.

Instance failure로부터 recovery는 상대적으로 자동이다. 예를 들면, Oracle Parallel Server를 사용하지 않는 configuration들에서, 다음 instance startup이 자동으로 instance recovery를 수행한다. Oracle Parallel Server를 사용하는 경우에는, 다른 instance들이 instance recovery를 수행한다.

Media(Disk) Failure
Media failure는 Oracle database를 조작하기 위해서 요구되는 file을 읽고 쓰고자 할 때 발생하는 error이다.

Media failure의 고통적인 예는 disk drive에 있는 모든 file들을 잃게 되는disk head crash이다. Database와 관련된 datafile, redo log file, 그리고 control file들을 포함하는 모든 file들은 disk crash에 영향을 받을 확률이 높다. Media failure에 대한 적절한 recovery는 영향을 받은 file들에 따라서 결정된다.

How Media Failure Affect Database Operation Media failure는 Oracle database의 조작에 필요한 datafile, online redo log file, 그리고 control file들을 포함하는 하나 또는 모든 형태의 file들에 영향을 줄 수 있다.

Online redo log file 또는 control file들에 대한 media failure 후에 database operation은 online redo log 또는 control file이 추천된 것처럼 multiplex 되었는지에 따라서 결정된다. multiplex된 online redo log 또는 control file은 간단하게 그 file들의 두 번째 copy가 유지된다는 것을 의미한다. 만약 media failure가 하나의 disk만을 손상시키고, user가 multiplexed online redo log를 가지고 있다면, database는 보통 특별한 방해 없이 계속 운용될 것이다. Non-multiplexed redo log에 대한 손상은 database 운영을 정지시키고 data의 영구적인 손실을 가져올 것이다. Multiplexed 이던지 또는 non-multiplexed 이던지 간에, Control file에 대한 손상은 Oracle이 손상된 control file 을 읽거나 쓰고자 한다면, database 운용을 정지시킬 것이다.

Datafile에 영향을 미치는 Media failure는 두 부류로 나눌 수 있다: Read errors 또는 write errors. Read error시에, Oracle이 datafile을 읽을 수 없다는 것을 발견하고, datafile을 발견할 수 없거나, open 할 수 없거나, 또는 읽을 수 없다는 것을 가리키는 Oracle error와 함께 operating system error가 application에 돌려진다. Oracle은 수행을 계속하지만 실패한 read error가 발생할 때마다 error가 돌려진다. 다음 checkpoint시에, Oracle이 표준 checkpoint process의 일부로서 file header에 쓰고자 할 때, write error가 발생할 것이다.

Oracle이 datafile에 쓸 수 없음을 발견하고 Oracle이 채워진 online redo log file들을 archive 하면, Oracle은DBWR trace file에 error을 돌리고, datafile을 자동으로 offline으로 만든다. Write될 수 없는 datafile만이 offline된다; 해당 datafile을 포함하는 tablespaces는 online으로 남아 있는다.

만약 SYSTEM tablespace내에 datafile이 write될 수 없다면, file은 offline되지 않는다. 대신, Oracle은 error를 돌리고 database를 shutdown 시킨다. 이런 예외에 대한 이유는 Oracle이 정상적으로 동작하기 위해 SYSTEM tablespace내에 존재하는 모든 file들은 반드시 online이어야 하기 때문이다. 같은 이유로, active rollback segment를 포함하는 tablespace의 datafile들은 항상 online 이어야 한다.

Oracle이 datafile에 쓸 수 없다는 것을 발견하고, Oracle이 채워진 online redo log file을 archiving 하지 않는다면, DBWR은 실패하고, 현재의 instance도 실패한다. 만약 문제가 임시적이라면(예를 들면, disk controller가 power off), instance가 재시동할 수 있다는 전제하에, instance recovery는 online redo log file을 이용하여 수행된다. 그러나 datafile이 영구적으로 손상 받고 archiving이 사용되지 않는다면, 전체 database는 가장 최근의 backup을 이용하여 복구되어야만 한다.

Structures Used for Database Recovery

Database backups
Database backup은 Oracle database를 구성하는 물리적인file 들의 Operating System backup으로 구성되어 있다. Media failure로부터 database recovery를 시작하기 위해서, Oracle은 손상 받은 datafile이나 control file을 복구하기 위해 file backup을 이용한다.

The Redo Log
Redo log는 Oracle database내에 만들어진 모든 변화를 기록한다. Database의 Redo log는 datafile(실제 database의 data를 저장하는)로부터 분리된 적어도 두개 이상의 redo log file로 구성되어 있다. Instance나 media failure로부터 database recovery의 일부분으로, database의 data를 failure가 발생한 시점으로 환원하기 위하여, redo log의 변화들을 datafile에 적용시킨다.

Database의 redo log는 두 부분으로 구성될 수 있다: Online redo log and archived redo log

The Online Redo Log 모든 Oracle database는 관련된 online redo log를 가지고 있다. Online redo log는 관련된 instance에 가해진 모든 변화를 기록하기 위하여 Oracle background process LGWR에 의해서 작업을 한다. Online redo log는 계속되는 database의 변화를 기록하기 위하여 순환적으로 재사용되는 두 개 이상의 미리 할당된 file로 구성된다.

The Archived (Offline) Redo Log 선택적으로, 채워진 online redo log의 archive file을 Oracle database에 설정할 수 있다. Archive된 online redo log file은 유일하게 인식되며 archived redo log를 구성한다. 채워진 online redo log file을 archive함으로서, online redo log file이 가장 최근의 database 변화를 저장하는데 계속 재사용되는데 반해, 더 오래된 redo log 정보가 좀 더 완전한 database recovery를 위해 보관된다.

Rollback Segment
Rollback segment는 Oracle database를 운영하는데 여러 가지 역할을 수행한다. 일반적으로 Rollback segment는 진행되는 transaction(즉, uncommitted transactions)에 의해 변경된 data의 old value를 저장하고 있다. Rollback segment의 정보는 database recovery 작업 중에redo log로부터 datafile에 적용된 “uncommitted” 변화를 “undo”하는데 이용된다. 그러므로, Database recovery가 요구되는 경우, rollback segment가 datafile로부터 모든 commit되지 않은 data를 제거하는데 이용된 후에 data가 일관된 상태에 있게 된다.

Control Files
일반적으로, database의 control file은 database의 물리적인 구조 상태를 저장한다. Control file의 상태 정보는 instance나 media failure시 Oracle을 guide한다.(예를 들면, 현재의 online redo log file, datafile의 이름 등..)

The Online Redo log
Online redo log는 database에 가해진 모든 변경들을 저장하기 위하여 두개 이상의 미리 정의된 file들로 구성된다.

Online Redo Log File Contents
Online redo log file들은 redo entry들로 채워진다. Redo entry는 database에 가해진, SGA의 database buffer내에 저장된 rollback segment들을 포함하는, 모든 변경을 재 생성하는데 사용될 수 있는 data를 기록한다. 그러므로, online redo log는 또한 rollback data도 보호한다.
Redo entry는 SGA의 redo log buffer안에 ‘순환적’으로 buffering 되며 Oracle background process Log Writer(LGWR)에 의해서 online redo log file들 중 하나에 쓰여진다. Transaction이 commit될 때마다, LGWR은 SGA의 redo log buffer로부터 online redo log file에 transaction의 redo entry들을 write 하고, system change number(SCN)가 각 commit된 transaction에 대한 redo entry를 인식하기 위해 할당된다.

그러나, redo entry는 해당 transaction이 commit되기 전에도 online redo log file에 쓰여 질 수 있다. 만약 redo log buffer가 채워지거나 다른 transaction이 commit되면, LGWR은 어떤 redo entry는 commit되지 않았을 수도 있는, redo log buffer의 redo log entry들을 online redo log file에 flush한다.

How Online Redo Log Files Are Written
Database의 online redo log는 두개 이상의 online redo log file로 구성되어 있다. Oracle은 하나가 archive되는 동안 다른 하나가 항상 사용 가능 상태임을 보장하기 위해 최소한 두개의 file을 요구한다.

채워진 online redo log file은 archiving이 enable되어 있느냐에 따라 LGWR에게 “사용 가능” 상태이다.
Archiving이 disable이면, 채워진 online redo log file은 online redo log file 이 관련된 checkpoint가 완료된 시점에서만 사용 가능하다.
Archiving이 enable이면, 채워진 online redo log file은 online redo log file 이 관련된 checkpoint가 완료되고 online redo log file이 archive된 시점에서만 사용 가능하다.

Active(Current) and Inactive Online Redo log Files
주어진 시점에, Oracle은 redo log buffer로부터 redo entry들을 저장하기 위하여, online redo log file들 중의 하나만을 이용한다. LGWR에 의해 active하게 기록되고 있는 online redo log file을 current online redo log file이라 부른다.

Instance recovery에 대해서 요구되는 online redo log file들을 active online redo log file이라 부른다. Instance recovery에 대해서 불필요한 online redo log file들을 inactive라 부른다.

Archiving이 enable이면, active online log file은 그 내용이 archive 되기 전까지 재사용되거나 덮어 쓰여질 수 없다. Archiving이 disable이면, 마지막 online redo log file이 다 채워지는 시점에, 첫번째 사용 가능한 active file에 덮어 씀으로써 writing이 계속된다.

Log Switches and Log Sequence Numbers
Oracle이 하나의 online redo log file의 쓰기를 마치고 다음 file에 쓰는 시점을 log switch라 부른다. Log switch는 현재의 online redo log file이 완전히 채워지고, 반드시 다음 online redo log file에 기록이 지속되어야 할 때 반드시 발생한다. Database administrator는 현재의 redo log file이 특정 작업(예를 들면,archiving)을 위해 close 되어 있다면, 강제로 log switch를 수행할 수 있다.

Oracle은 log switch가 발생할 때마다 각 online redo log file에 새로운 log sequence number를 할당하고 LGWR은 그 online redo log file에 기록을 시작한다. Online redo log가 archive되면, archive된 redo log file은 그것의 log sequence number를 유지한다. 재사용을 위해 뒤로 보내진(cycled back) online redo file은 다음 사용 가능한 log sequence number가 배정된다.

Checkpoints
Checkpoint라 부르는 event는 Oracle background process DBWR이 SGA내에서 commit 되거나 commit 되지 않는 data를 포함하는, 변경된 database buffer 모두를 datafile에 기록할 때 발생한다. Checkpoint은 다음과 같은 이유에 의해서 구현된다.

Checkpoint들은 memory상에서 빈번하게 변경되는 data segment block이 datafile에 정기적으로 쓰여지는 것을 보장한다. DBWR이 LRU algorithm을 이용하기 때문에, checkpoint가 발생하지 않는다면 빈번히 변경되는 data segment block은 disk에 기록되지 않을 수도 있다.
Checkpoint까지 모든 database의 변경들이 기록되기 때문에, instance recovery가 요구될 때 checkpoint 이전의 redo log entry들이 더 이상 적용될 필요가 없다. 결국 checkpoint는 instance recovery를 빠르게 수행할 수 있기 때문에 유용하다.

Checkpoint와 연관된 overhead가 있지만 activity를 halt시키거나 또는 현재 transaction에 영향을 미치지 않는다. DBWR이 지속적으로 database buffer들을 disk에 기록하므로, checkpoint는 한번에 많은 data block들을 기록하지 않는다. Checkpoint의 완료는 앞서의 checkpoint가 실제로 disk에 기록한 이후에 변경된 모든 data block들을 보장한다.

Checkpoint는 채워진 online redo log file이 archive되건 안되건 발생한다. Archiving이 disable이면, online redo log file에 영향을 미치는 checkpoint는 LGWR에 의해 online redo log file이 재사용 되기 전에 반드시 완결되어야 한다. Archiving이 enable이면, checkpoint는 반드시 완결되어야 하고 채워진 online redo log file 은 LGWR에 의해 재사용되기 전에 반드시 archive되어야 한다.

Checkpoint는 database의 모든 datafile에 대해서나(database checkpoint라 부름) 특정 datafile에 대해서 발생할 수 있다. 다음은 checkpoint이 발생하는 시점과 각 상황에 발생하는 checkpoint의 형태를 설명한다.
database checkpoint는 모든 log switch 시 자동으로 발생한다. Previous database checkpoint가 진행 중 이라면, log switch에 의한 checkpoint가 현재의 checkpoint를 덮어쓴다.
Initialization parameter LOG_CHECKPOINT_INTERVAL은 지난번의 checkpoint가 발생한 이후로 미리 지정된 개수의 redo log block들이 disk에 쓰여진 후 checkpoint가 발생하도록 한다. LOG_CHECKPOINT_ TIMEOUT은 지난번의 checkpoint가 발생한 이후 특정 시간이 지난 후 checkpoint가 발생하도록 한다. 이 option들은 굉장히 큰 크기의 redo log file이 이용되고 log switch간에 추가적인 checkpoint가 요구될 때 유용하다.
Online tablespace backup 의 시작이 지정될 때, checkpoints는 backup 될 tablespace를 구성하는 datafile에만 행해지게 된다. 이 경우 checkpoint는 진행 중인 previous checkpoint을 덮어쓰게 된다. 또 이 checkpoint는 backup 되는 datafile에만 영향을 미치므로 instance recovery시 요구되는 redo의 양을 줄이지 못한다.
Administrator가 tablespace를 보통 또는 임시 순위로 offline으로 만들 때, checkpoint는 오직 연관된 tablespace의 online datafile에만 행해진다.
Database administrator가 instance를 shutdown시키면(NORMAL 또는 IMMEDIATE), Oracle은 instance가 shutdown 되기 전에 checkpoint를 수행한다. Instance shutdown에 의해 행해진 checkpoint는 어떤 previous running checkpoint도 덮어쓴다.
Database administrator는 필요에 따라 checkpoint를 수행할 수 있다. 수동으로 행해진 checkpoint는 어떤 previous running checkpoint도 덮어쓴다.

The Mechanics of a Checkpoint checkpoint가 발생할 때, checkpoint background porcess(CKPT)는 online redo log file에 기록될 다음 entry의 위치를 기억하고database writer background process(DBWR)에게 SGA내 변경된 database buffer들을 datafile에 기록하도록 신호를 보낸다. 그 후 CKPT는 최근의 checkpoint를 반영하기 위해 모든 control file의 header와 datafile을 갱신한다.

Checkpoint가 발생하지 않으면, DBWR은 least-recently-used database buffer들을 disk에 기록하여 새로운 data를 위해 요구되는 buffer를 free하는 작업만 수행한다. 그러나 checkpoint가 진행되면 DBWR은 checkpoint와 진행되는 database 조작을 위해서 datafile에 data를 기록한다. DBWR은 checkpoint이 완료될 때까지, checkpoint에 대해 변경된 data buffer들을 기록하고 least-recently-used buffer들을 기록하며 checkpoint를 위해 dirty buffer를 기록한다.

Checkpoint에 가해지는 signal에 따라, checkpoint는 “normal” 이거나 “fast”일 수 있다. Normal checkpoint시에, DBWR는 checkpoint에 대해 각각 적은 수의 data buffer들을 기록한다. Fast checkpoint시에, DBWR은 checkpoint에 대해 각각 많은 수의 data buffer들을 기록한다.

Normal checkpoint는 fast checkpoint에 비해 많은 I/O를 요구한다. Fast checkpoint는 적은 I/O를 요구하므로 매우 빠르게 수행된다. 그러나 DBWR이 수행해야 될 많은 양의 다른 database 작업을 가지고 있다면 fast checkpoint는 전반적인 성능을 저하 시킬 수 있다. Normal checkpoint를 trigger시키는 event들은 log switch와 initialization parameter에 의한 check point interval 설정을 포함한다. Fast checkpoint를 trigger 시키는 event는 online tablespace backup , instance shutdown, database administrator-forced checkpoint들이다.

Checkpoint가 완료될 때까지, database failure가 checkpoint를 방해하거나 instance recovery가 필요한 경우 last checkpoint가 필요로 될 때까지 모든 online redo log file이 쓰여진다. 게다가, LGWR이 checkpoint가 완료되지 않아 online redo log file을 기록하지 못하는 경우 checkpoint이 완료되고 online redo log file이 사용 가능 상태가 될 때까지 database 작업은 임시적으로 중지된다. 이 경우 가능한 한 checkpoint을 빠르게 수행하기 위해 normal checkpoint가 fast checkpoint가 된다.

예를 들어 두개의 online redo log file만이 이용되고, LGWR이 다른 log switch를 요구하면 previous log switch에 대한 checkpoint이 완료되기 전까지 처음의 online redo log file이 LGWR에 대해 사용 가능하지 않다.

Checkpoint가 원하는 주기로 발생하는 것을 결정하려면 initialization parameter LOG_CHECK_POINTS_TO_ALERT를 설정할 수 있다. 이 parameter의 기본 값은 NO이다. 이 parameter를 YES로 설정하면 각 checkpoint에 대한 정보가 ALERT file에 기록된다.

Multiplexed Online Redo Log Files
Oracle은 online redo log file이 손상 입을 것에 대비하여 instance의 online redo log file을 multiplex하는 기능을 제공한다. Multiplexed online redo log file을 이용하여, LGWR은 같은 정보를 여러 개의 동일한 redo log file에 동시에 기록하므로, 결국 online redo log failure 확률을 줄인다.

이러한 redo log file들을 group이라 부른다. Group의 각 online redo log file 은 member라 부른다. Group의 모든 member는 동시에 active이며(동시에 LGWR에 의해 쓰여지며), LGWR에 의해 지정된 동일한 log sequence number들로 지시된다. Multiplexed online redo log가 이용되면, group의 각 member는 반드시 같은 크기여야 한다.

The Mechanics of a Multiplexed Online Redo Log LGWR은 group이 하나나 그 이상의 member를 가지더라도 항상 group의 모든 member를 address 한다. 예를 들면, LGWR은 항상 주어진 group의 모든 member를 동시에 쓰려고 시도하며 동시에 다음 group으로 switch하여 기록하려 시도한다. LGWR은 절대로 다른 group의 member를 동시에 기록하지 않는다.

LGWR은 group의 member인 online redo log file이 사용 불가 상태인 이유에 따라 다르게 대응한다.
LGWR이 group의 최소한 하나의 member에 기록할 수 있으면 접근 가능한 member에 대한 기록이 정상적으로 수행된다. LGWR은 group의 가능한 member에 기록하고 불가능한 member는 무시한다.
LGWR이 log switch시 다음 group에 접근하지 못하면(group이 archive 되고 있어서) database 운영은 group이 사용 가능해질 때까지 임시적으로 중단된다.
다음 group의 모든 member가 media failure로 인해 log switch시 LGWR에게 접근 불가 상태이면 error가 돌려지고 database instance가 즉시 shutdown 된다. 이 경우 database는 online redo log file의 손실로 인해 media recovery를 요구할 것이다. 그러나 database checkpoint가 손실된 log를 지나쳤다면(failure된 file이 current log가 아니라면) media failure가 요구되지 않는다. 단순히 접근 불가능한 log group을 삭제한다. Log가 archive되지 않았다면, log를 삭제하기 전에 disable시켜야 한다.
LGWR이 기록 도중 갑자기 group의 모든 member가 사용 불가 상태가 되면 error가 돌려지고 database instance가 즉시 shutdown 된다. 이 경우 database는 online redo log file의 손실로 인해 media recovery를 요구할 것이다. Log를 포함하는 media가 실제로 소실된 - 예를 들면, 일시적으로 전원이 off되었다면 - 것이 아니라면 media recovery가 요구되지 않을 수도 있다. 이 경우에는 drive에 전원을 공급하고 instance recovery를 수행하면 된다.

LGWR이 group의 member에 기록을 할 수 없을 때마다, Oracle은 그 member를 유효하지 않은 것으로 mark하며 error message를 접근 불가능한 file에 대한 문제들을 나타내기 위하여 LGWR trace file과 database의 ALERT file에 기록한다.

Online redo log failure의 한 시점에 대해 항상 대비하려면 multiplexed online redo log가 완전히 대칭이여야 한다: 즉, online redo log의 모든 group은 반드시 같은 수의 member를 가져야 한다. 그러나, Oracle은 대칭일 것을 요구하지는 않는다. Instance의 online redo log에 대한 유일한 요구 사항은 multiplexed이건 non-multiplexed이건 반드시 최소 두개의 group으로 구성되어야 한다는 것이다.

“Threads” of Online Redo Log and the Oracle Parallel Server
각 database instance는 고유의 online redo log group을 보유한다. 이 online redo log group은 multiplexed건 non-multiplexed이건 instance의 online redo의 “thread”라 불린다. 전형적인 구성에서, 유일한 instance가 하나의 Oracle database에 access하며 하나의 thread만이 존재한다. 그러나, Oracle Parallel Server 운영 시에는, 하나 이상의 instance가 하나의 database에 access하며 각 instance는 고유의 thread를 가진다.

The Archived Redo Log
Oracle은 archived(offline) redo log들을 생성하는, 채워진 online redo log file의 group들을 선택적으로 archiving하는 것을 허용한다. 채워진 group들의 archiving하는 것은 database backup과 recovery option들에 관련된 두 가지 장점을 제공한다.
online과archived redo log file들과 함께 database backup이 O/S나 disk failure시 모든 commit된 transaction이 복구되는 것을 보장한다.
Archived log가 영구적으로 이용된다면, database가 open되고 정상적인 system에서 사용되고 있는 동안에, Online backup 이 가능하다.

다 채워진 online redo log file들을 archiving하는 것은 database administrator가 특별한 운용 작업을 하는 것을 요구한다.

The Mechanics of Archiving
Archiving을 어떻게 설정하는가에 따라 선택적인 Oracle background process ARCH(자동 archiving이 사용될 경우)나 수동으로 group을 archive하는 statement를 기동하는 user process에 의해 archiving이 수행된다.

Note : 본 session은 ARCH background process에 의해 archiving이 이루어 진다고 가정한다.

ARCH는 group이 inactive되고 다음 group으로의 log switch가 완료된 후에 그 group을 archive한다. ARCH process는 요구에 따라 group의 archiving을 완료하기 위해 group의 어떤 member에도 access 할 수 있다. ARCH가 group의 접근 불가능한(예를 들면, disk failure등으로) member를 access하려고 시도하면 ARCH는 자동으로 사용 가능한 member를 찾을 때까지 group의 member를 찾으며, 찾게 되면 자동으로 그 member에 archiving을 수행한다.

ARCH가 group을 archive 하기 전까지, 그 group은 LGWR에 의해 기록될 수 없다. 이 제한은 LGWR이 archive 되지 않은 group을 일시적으로 기록하는 일 이 발생하지 않음을 보장하기 때문에, 이 경우 database recovery시 모든 연속된 archived redo log file의 사용을 방해하게 되므로 중요하다.

Archiving이 이용될 때, archiving destination이 지정된다. 이 destination은 보통 datafile, online redo log file, control file들의 disk와 별도의 storage device이다. 전형적으로 archiving destination은 database server와 별도의 disk이다. 이 방법으로 archiving은 instance에 의해 요구되는 다른 file들과 경쟁하지 않으며 group은 빠르게 LGWR에게 사용 가능하게 된다. 이상적으로 archived redo log file들은 영구적으로 tape과 같은 database server와 별도의, 안전한 장소에 저장될 수 있는 offline storage media로 옮겨져야 한다.

Log switch time시 redo log에 더 이상 기록될 정보가 없는 경우, database의 control file에 record가 생성된다. 각 record는 thread number, log sequence number, 그 group에 대한 low SCN, next SCN after the archived log file을 포함하고 있다. 이 정보는 Parallel server 구조의 database recovery시 redo log file의 적용을 자동화하기 위해 이용된다.

Archived Redo Log File Contents
Archived redo log file은 group이 archive되는 시점에 group의 동일한 member에 존재하는 redo log entry들을 포함한다. Archived redo log file은 또한 group의 log sequence number를 보존한다.

Archived redo log는 archiving이 enable된 후 생성된 모든 group(log sequence number에 의해 유일하게 식별되는)의 copy를 포함한다.

Database Archived Modes
Database는 NOARCHIVELOG(media recovery disabled) mode와 ARCHIVE LOG (media recovery enabled) mode에서 수행된다.

NOARCHIVELOG Mode(Media Recovery Disabled)
Database가 NOARCHIVELOG mode에서 사용된다면, Online redo log의 archiving이 disable된다. Database의 control file의 정보가 채워진 group이 archive될 필요가 없음을 지시한다. 채워진 group이 inactive되고 log switch시 checkpoint이 완료되면 group은 LGWR에 의해 사용 가능 상태가 된다.
NOARCHIVEDLOG mode는 media failure에 대해서가 아니라, instance failure에 대해서만 database를 보호한다. Online redo log group에 저장된 database에 가해진 가장 최근의 변경만이 instance recovery로부터 사용 가능하다.

ARCHIVELOG Mode
Oracle database가 ARCHIVELOG mode에서 운영되고 있다면, online redo log의 archiving이 enable된다. Database control file의 정보가 채워진 group이 archive되기 전까지 LGWR에 의해 재사용될 수 없음을 지시한다. 채워진 group은 log switch가 발생하면(group이 inactive되면), 즉시 archiving을 담당하는 process에게 사용 가능 상태가 된다. Archiving을 담당하는 process는 group을 archive하기 전에 log switch의 checkpoint를 기다릴 필요가 없다.

ARCHIVELOG mode는 database에 가해진 모든 변화가 영구적으로 archived redo log에 저장되어 있으므로, instance failure나 disk failure로부터 완전한 복구를 허용한다.

Automatic Archiving and the ARCH(Archiver) Background Process ARCH를 이용한 automatic archiving은 database administrator가 archiving을 수동으로 관리하지 않게 해준다. Archived redo log를 이용하는 system에서 가장 많이 이용되는 방법이다.

Initialization parameter LOG_ARCHIVE_START를 instance startup시에 설정함으로써 Oracle은 instance startup시 ARCH를 자동으로 start한다.

그러나, database administrator는 어떤 시점에서도 automatic archiving을 start/stop할 수 있다.

ARCH는 항상 group을 작은 sequence number로부터 순서대로 archive한다. ARCH는 채워진 group이 inactive되면 archive한다. 모든 자동 archive의 record가 ARCH에 의해 ARCH trace file에 기록된다. 각 entry는 archive의 start/stop시간을 보여 준다.

Manual Archiving ARCHIVELOG mode에서 Automatic archiving이 disable되면 database administrator는 채워진 group을 archiving하는 책임을 가진다. Automatic archiving이 disable되고 수동 archiving이 충분히 빠르게 수행되지 않으면 LGWR이 inactive group이 재사용을 위해 사용 가능 상태가 되는 것을 기다릴 때마다 database 운용은 임시적으로 중지될 것이다. 다음의 이유로 수동 archiving 기능이 제공된다.
문제가 발생하여 automatic archiving이 중지되었을 때 group을 archive하기 위해.(예를 들면, archived redo log destination failure나 공간이 없을 때)
비정규적인 방법으로 group을 archive할 때.(예를 들면, 연속된 group들이 다른 offline storage device에 있을 때)
원래의 archived version이 손실되거나 손상을 입었을 때 group을 다시 archive하기 위해

Group이 수동으로 archive될 때, group을 archive하는 statement를 기동하는 process가 실제로 group을 archiving하는 작업을 수행한다. 연관된 instance에 대해 ARCH가 존재하더라도 online redo log file 을 archive하는 것은 user process이다.

Control Files
Database의 control file은 database를 기동 시키고 성공적으로 수행시키는데 요구되는 작은 크기의 binary file이다. Control file은 database 사용 중에 Oracle에 의해 계속 갱신되므로 database가 open 되어 있는 동안 반드시 기록 가능해야 한다. 만약 control file이 access되지 못하면, database는 기능을 제대로 수행할 수 없다.

각 control file은 오직 하나의 Oracle database과 관련된다.

Control File Contents
Control file의 정보는 Oracle에 의해서만 변경될 수 있다;Database administrator나 end-user는 control file 을 편집할 수 없다.

Control file 은 다음과 같은 정보들을 저장한다.
database name
database 생성의 timestamp
관련된 database와 online redo log file의 이름과 위치
현재 log sequence number
Checkpoint 정보

Database의 name은 initialization parameter DB_NAME 혹은 CREATE DATABASE statement에서 이용된 name 중의 하나에 의해서 결정된다.

Datafile 이나 online redo log file이 추가, 이름 변경, 삭제될 때마다 control file 이 갱신되어 물리적인 구조 변화를 반영한다. 이 정보들은 다음의 이유로 기록된다.
database startup 동안에 datafile과 online redo log file을 open하기 위해 Oracle이 식별할 수 있다.
Oracle이 database recovery시 요구하는 file을 식별할 수 있다.

위의 이유로 database에 물리적인 구조 변경을 가한 경우 즉시 control file의 backup 을 만들어야 한다.

Control file은 checkpoint에 대한 정보도 기록한다. Checkpoint가 시작될 때 online redo log file에 반드시 저장되어야 하는 다음 entry를 기억하기 위한 정보를 기록한다. 이 정보는 database 복구 중에 Oracle에게 이 시점 전에 기록된 모든 redo log entry가 복구를 위해 필요하지 않다는 것을 지시하는데 이용된다.

Multiplexed Control Files
Online redo log file처럼 control file도 동일한 database를 위해 여러 개의 동일한 control file이 open되는 것이 허용된다. Control file을 포함하는 하나의 disk가 crash되면 Oracle이 손상된 control file을 access하려 시도할 때 현재의 instance가 fail 된다. 그러나 현재 control file의 다른 복사본이 다른 disk 상에 존재하므로 instance는 database recovery 필요 없이 쉽게 재기동 될 수 있다.

Database의 모든 control file 복사본이 영구적으로 손상 받는 것은 반드시 피해야 하는 문제이다. 이 경우 instance는 abort되며 media recovery가 요구된다. 현재 복사본이 없어서 오래된 control file의 backup을 이용해야 한다면 media recovery도 수월하지 않을 것이다. Multiplexed control file을 각 database 마다, 각 복사본을 다른 물리적 disk에 복사에 저장하는 것을 강력히 권장한다.


코멘트  

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




금연

  글번호
이름
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
  62Data-Base CHAPTER 24 조회수가 1000회 이상이네요. ^0^2002-01-12
  61Data-Base CHAPTER 23 조회수가 1000회 이상이네요. ^0^2002-01-12
  Data-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