[박상준] Temp, Control, Redo log, Archive Redo log, Trace, Flashback log File

▒ Temporary File Temporary파일은 특별한 형태의 데이터 파일이다. 오라클은 Temporary 데이터 파일 안에 대량의 정렬 작업과 해시 작업의 임시 결과를 저장하며, Global Temporary Table의 데이터를 저장하거나 메모리에 담기에 충분하지 않을 경우 결과집합들을 저장한다. 또한 Temporary Table이나 해당 Table에 생성된 Index 등의 내용들은 Temp File에 저장할 수 있지만, Table이나 Index와 같은 영구적인 Data Object들은 Temp File에 저장할 수 없다. 즉 Application에서 사용하는 Table을 임시 파일에 생성할 수는 없지만, 데이터를 임시 파일에 저장할 수 있다. Temp  File은 오라클이 특별한 방식으로 취급하는데 일반적으론 Object에 발생한 모든 변경은 Redo log에 기록한다. 이런 Transaction log는 나중에 오류 복구할 때 "Transaction을 Redo" 할 목적으로 재 실행될 수 있다. 그런데 Temp File은 이런 프로세스에서 배제되고 Temp File은 절대 Redo를 생성하지 않는 대신 Undo를 생성한다. Undo는 항상 Redo에 의해 보호를 받기 때문에 그에 대해서는 Temporary Table에 대해서도 Redo를 발생시킨다. 위에서 언급한 Global Temporary Table은 오류 프로세싱 데이터 또는 일반적인 Transaction 오류가 일어날 경우를 대비한다. Database에서 사용할 Temporary Tablespace는 LMT(Locally Managed Tablespace)를 권고하는데 LMT는 Extent를 관리 하기위해 각 데이터 파일에 저장된 Bitmap을 사용한다. 하나의 Extent를 얻기 위해 시스템이 할 일은 Bitmap의 한 Bit를 1로 세팅하는 것이 전부이다. 반대로 공간을 반환할 경우에 시스템은 Bit를 0으로 환원한다. DMT에 비해서 월등한 성능을 보여주며 Database 수준에서 공간을 요청하기 위한 관리 부하가 없어진다.   ▒ Control File Control File은 오라클이 필요로 하는 다른 파일들의 위치 정보를 담고 있는 매우 작은 파일이다. Parameter File은 Control File의 위치를 정의하고, Control File은 Database와 Online Redo log의 위치를 제시한다. Control File은 Chkeck Point가 발생한 정보, Database의 이름, Database 생성 시점 정보, Archive Redo log 이력, RMAN 정보 등 오라클의 다른 여러 가지 사항을 다루고 있다. Control File은 RAID 또는 오라클 이중화를 통하여 구성하는 것을 권장한다. 즉, 하나 이상의 복사본이 존재해야 하며 별도로 분리된 디스크에 저장하여 관리해야 한다.   ▒ Redo log File Database의 Transaction log 역활을 담당하며, 시스템 장애 이후 인스턴스 복구 / 백업에서 데이터 파일 Restore이후 미디어복구 / 스탠바이 데이터베이스 프로세싱 / Stream을 이용하여 정보 공유를 위한 리두 로그 마니잉 기능(복잡한 데이터 복제 기능) Redo log의 주 용도는 Instance 혹은 Media 오류 등의 장애를 복구하거나 Failover를 위하여 스탠바이 데이터베이스를 관리하기 위한 용도로 사용된다. Database 서버에 전원 공급이 중단되면, Instance 오류를 말미암아 오라클 전원 공급이 차단된 해당 시점 이전으로 시스템을 Restore하기 위해 Online Redo log를 사용한다. 오라클에서 실행되는 거의 모든 작업은 어느 정도 Redo를 발생시키며, Online Redo log 파일에 기록된다. 예를 들면 하나의 row를 Table에 저장하면 저장 후 결과가 Redo log에 기록된다. row를 삭제하면 삭제 되었다는 내용만 기록 된다. Table을 삭제한다면 삭제가 미치는 영향이 Redo log에 기록된다.   ▒ Online Redo log File 모든 오라클 데이터베이스는 최소한 두 개의 Online Redo log 파일 그룹을 갖는다. 각 Redo log Group은 하나 이상의 Member로 구성되며, 각 Group의 개별 Redo log Member들은 각각에 대해 정확히 미러링을 하는 방식을 취하고 있다. Online Redo log File들은 고정 크기로 생성되어 있고, 순환 방식으로 사용된다. 오라클이 Log File Group 1에 기록하고, 이 File Group을 다 쓰고 나면 Group 2로 스위치할 것이다. Group 2도 다 차면 처음 Log File Group 1로 스위치 하게 된다. 하나의 Log File Group에서 다른 Group의 스위칭 활동을 Log Switch라 하는데, 잘못 설정된 Database에서는 Freezing현상의 원인이 되기도 한다. 만약 어떤 로그 파일의 내용이 필요 없는게 맞는지 확실치 않다면, 오라클은 Database 진행을 잠시 중지하고 Redo를 보호하기 위해 Cache의 데이터가 디스크에 기록되었는지 확인한다. (확인 과정을 Checkpoint라 한다.) 확인이 된 후에 진행을 재개하고, 그 로그 파일을 재사용한다. Database Buffer Cache는 Database Block들을 임시로 저장하는 공간이다. Buffer Cache는 SGA안에 있는 구조의 일부로서, Data Block을 읽으면 Cache에 저장하여 동일한 Block에 대해서는 이후에 물리적으로 읽지 않도록 해준다. 사용자가 Block안에 있는 row를 업데이트하면 Buffer Cache 안에 Block을 변경하는데 변경을 재현할 수 있는 충분한 정보는 Redo log와 SGA 구조에 저장된다. 데이터 변경을 위해 커밋할 때 오라클이 변경된 모든 Block을 SGA에서 찾아 디스크에 쓰는 것은 아니고, 커밋할 때 Redo log Buffer의 내용을 Online Redo log에 쓰기만 한다.  수정된 Block이 Buffer Cache에만 있고 디스크에 저장되지 않으면, Database 장애에 복구하기 위해 Online Redo log 내용이 필요한데 커밋한 직후 전원이 꺼진다면 Database Buffer Cache는 깨끗하게 없어지게 된다. 오라클을 재구동을 하더라도 변경 기록은 Redo log File에 유일하게 남아 있는 정보를 가지고 이전에 했던 것과 똑같이 Block을 갱신하고 커밋하는 Transaction을 재연한다. 같은 방법으로 Block을 수정하고 커밋한다. 그래서 수정한 Block을 Cache에 저장한 상태에서 디스크에 저장하지 않았다면 Redo log File을 재사용할 수는 없게 된다. 위에서 언급한 Buffer Cache의 공간도 꽉차게 되는데 DBWn이라고 하는 백그라운드 프로세서가 Buffer Cache에 공간을 만드는 역활을 하며, Checkpoint를 백그라운드로 발생시키는 기능을 담당한다. Checkpoint란? Dirty Block을 Buffer Cache에서 읽어  디스크에 기록하는 것을 말하며 Checkpoint를 유발하는 많은 원인 중 일반적인 것은 Redo log Switch이다. Log File 1을 다 사용하고 Log File 2로 넘어갈 때, 오라클에서 Checkpoint를 수행한다. 여기서 DBWn이 구동하여 Group 1에 보호되던 모든 Dirty Block들을 디스크에 기록한다. DBWn이 Block을 비우기 전까지 오라클은 Group을 재사용하지 않는다.   ▒ Archive Redo Log Redo log 운영 방식은  Archive log Mode와 No Archive log Mode 두 가지 모드 중 하나로 운영된다. 두 모드의 차이는 Redo log File에 어떤 일이 생기느냐의 차이인데 쉽게 말하면 Redo의 복사본을 유지하는 모드와 Redo를 덮어 써서 영원히 잃어버리는 모드라고 할 수 있다. 시스템 엔지니어의 시선으로 RAID-1이나 RAID-5를 사용하기 때문에 충분히 데이터 손실을 막고 있다고 말하고 있지만 경험상 동시에 두 개 이상의 디스크에 문제가 생겨서 재설치를 한 적도 있다. 물론 하드웨어 컨트롤러가 오류를 제어하지만 오류를 데이터 파일 안에 넣기 때문에 RAID장치가 데이터 깨짐 현상을 막아준다고 생각하는 사람도 있지만 데이터 손실의 가장 일반적인 원인은 사용자의 조작 실수에서 일어난다. 결국 RAID에 있는 데이터가 사라지는건 시간문제일 뿐이다.   ▒ Change Tracking File 10g Ed이상에서 제공하는 부가 파일이며, 마지막 Incremental Backup이후 수정된 Block들을 추적하는 데 있다. 이 파일을 이용하면 RMAN이 전체 Database를 읽지 않고도 실제 수정된 Database Block에 대해서만 백업할 수 있다. 10g 이전에는 Incremental Backup 이후 수정된 Block을 찾기 위해 전체 Database를 읽어야만 했다. 1TB의 DB에서 500MB만 신규로 추가되었어도 전체를 읽어야 하는 비효율이 존재했지만 10g Ed이상에서는 RMAN을 통해 어떤 Block이 수정되었는지를 관리하는 부가적인 파일을 따로 관리한다. 이런 변경 추적 파일을 생성하는 것은 alter database enable block change tracking 명령으로 생성할 수 있다.   ▒ Flashback Log File Flashback log는 오라클 10gEd의 새로운 기능인 Flashback Database 명령을 설명하면서 소개됐다. Flashback log는 특정 시점으로 변경이 일어난 Database를 되돌리기 위해 수정된 Database Block 이전 이미지를 저장하는 기능이다. Flashback Databases는 시간이 오래걸리는 시점별 데이터베이스 복구 프로세스의 성능을 향상시키기 위해서 소개되었고 전체 데이터베이스의 Restore와 Archive log를 이용하여 복구 속도를 향상시키는데 최우선의 목적으로 설계되었다.