mellowg

01 | 오라클 아키텍처

03 ) 버퍼 Lock

(1) 버퍼 Lock ? 

DB 버퍼 캐시 내에서 버퍼 블록을 찾고, 래치를 빠르게 해제하지 않으면 cache buffers chains 래치에 여러 개의 해시 체인이 달렸으므로 래치에 대한 경합 발생 가능성이 증가하게 된다. 

캐시된 버퍼 블록을 읽거나 변경하려는 프로세스는 먼저 버퍼 헤더로부터 버퍼 Lock(buffer pin) 을 흭득해야 한다. 

버퍼 Lock (buffer pin)을 흭득햇다면 래치를 곧바로 해제해야한다.  

버퍼 내용을 읽기만 할 때는 Share 모드, 변경할 때는 Exclusive 모드로 Lock을 설정한다.

액세스를 직렬화하기 위한 메커니즘이므로 당연히 Exclusive 모드 Lock은 한 시점에 하나의 프로세스만 얻을 수 있다.  Select 문이더라도 Block Cleanout이 필요할 때는 버퍼 내용을 변경하는 작업이므로 Exclusive 모드 Lock을 요구한다.

💡 Block Cleanout → 성능 최적화를 위해 사용

- 트랜잭션 완료정보를 지연해서 처리하는 최적화기법

- 트랜잭션 완료여부를 블록 내에 표시(clean)하지 않고 남겨뒀다가, 이후 누군가 그 블록을 읽을 때 처리(cleanout)하는 메커니즘

- 성능을 위해서 트랜잭션이 커밋되었을때 모든 블록을 즉시 수정하지 않는다. 대신 해당 트랜잭션이 어떤 블록을 변경했는지, undo, redo 로그에만 저장한다. 

- 블록내의 트랜잭션 메타 데이터(Interested Transaction List)는 "나중에" 정리한다. 나중에 정리하는 것이 Block Cleanout이다.

📌 Why 성능 최적화? 

▶️  트랜잭션이 커밋될때마다 모든 관련 블록을 다시 찾아가서 "커밋됨"을 표시하면 디스크 I/O 비용과 latch 경합이 매우 커진다.

 ex) 트랜잭션 A가 1000개의 데이터 블록을 변경 → COMMIT → 1000개의 데이터 블록을 모두 찾아가 "COMMIT됨 표시" ▶️ COST 가 큼

트랜잭션 A가 1000개의 데이터 블록을 변경 (ITL 기록; 이 트랜잭션이 수정 중 표시) + UNDO 생성 → COMMIT(redo 기록, SCN 부여) → 트랜잭션 B가 트랜잭션 A가 변경한 데이터블록 접근(ITL확인) → UNDO에 연결된 트랜잭션 상태를 확인한 후 Block Cleanout  처리

📌 버퍼 Lock 대기모드

- 찾아낸 버퍼 캐시상의 대상 버퍼가 타 프로세스에 의해 exclusive lock이 흭득된 상태인 경우 버퍼 헤더에 있는 버퍼 Lock 대기자 목록에 등록 후 대기 (해당 요청을 했던 프로세스에 할당된 cache buffers chain latch는 이 시정에 해지된다.)

- 이렇게 동작해야 또 다른 프로세스가 해당 버퍼 캐시에 요청을 했을때 latch wait이 발생하지 않고 버퍼 lock 대기자 목록에 자신의 정보를 기록할 수 있다.

- buffer busy waits 대기 이벤트 발생

- 목적한 읽기/쓰기 작업을 완료하면 버퍼 헤더에서 버퍼 Lock 을 해제해야 하는데, 이때도 버퍼 헤더를 액세스하려는 다른 프로세스와 충돌이 생길 수 있으므로 해당 버퍼가 속한 체인 래치를 다시 한번 흭득한다. ▶ 버퍼 Lock 해제의 경우 버퍼헤더에서 해당 버퍼 블록에 대한 상태를 수정하는 작업임(pin count 수정), 다른 프로세스가 버퍼 체인 스캔을 하며 버퍼 헤더에 접근하게 되면 충돌이 발생할 수 있다. 그렇기 때문에 Lock 해지할 때에도 Buffer Chains Latch를 재흭득해야 함.

⭐️ 버퍼 블록을 읽을때 대부분 두번의 래치 흭득을 요구한다. (버퍼 헤더 검색 후 pin / Un-pin)

일부 작업의 경우 래치를 흭득한 상태로 버퍼 블록을 읽기 때문에 래치 흭득이 한번만 일어난다. (v$sysstat 뷰에서 consistent gets - examination 통계항목으로 측정)

버퍼 Lock을 해제하고 Latch Lock을 해제해야 비로소 버퍼 블록 읽기가 완료된다.

(2) 버퍼 핸들

버퍼 Lock을 설정하는 것은 자신이 현재 그 버퍼를 사용중임을 표시해 두는 것으로서, 그 버퍼 헤더에 Pin을 걸었다고도 표현한다.

읽기 작업 : 여러 프로세스가 Pin 설정 가능

변경 작업 : 하나의 프로세스만 Pin 설정 가능

버퍼 헤더에 Pin을 설정하려고 사용하는 오브젝트를 버퍼 핸들(Buffer Handle)이라고 부르며, 버퍼 핸들을 얻어 버퍼 헤더에 있는 소유자 목록(Holder Lost)에 연결시키는 방식으로 Pin을 설정한다.

버퍼 핸들도 공유된 리소스이므로 버퍼 핸들을 얻으려면 또 다른 래치가 필요해지는데, 바로 cache buffer handles 래치이다. 

버퍼를 Pin하는 작업이 많을수록 cache buffer handles 래치가 경합 지점이 될것이므로, 오라클은 각 프로세스마다 _db_handles_cached 개수만큼의 버퍼 핸들을 미리 할당해 주며, 기본값은 5이다. 

각 세션은 이를 캐싱하고 있다가 버퍼를 Pin할때마다 사용하며, 그 이상의 버퍼 핸들이 필요할 때만 cache buffer handles 래치를 얻고 추가로 버퍼 핸들을 할당받는다. 

시스템 전체 버퍼 핸들 개수 (_db_handles) = processes * _db_handles_cached

(3) 버퍼 Lock의 필요성

• 단일 레코드 갱신시의 버퍼 Lock 필요성
  • 단일 레코드를 갱신 → 사용자 데이터 변경 시 DML Lock 을 통해서 정합성을 유지
  • DML Lock 만으로는 정합성 유지에는 불충분하다. → 하나의 레코드를 갱신하더라도 블록 단위로 I/O를 수행하기 때문에 , 블록 안에 저장된 10개의 레코드를 읽는 짧은 순간 동안 다른 프로세스에 의해 변경이 발생하면 잘못된 결과를 얻게 된다.
  • 버퍼 Lock 필요
• Row-Level Lock에서의 버퍼 Lock 필요성
  • row-level lock 설정 자체도 레코드의 속성을 변경한다. 
  • 두 프로세스가 동시에 row-level lock을 설정할 경우 문제가 발생한다. ( 대상 로우가 다르더라도 )
  • 블록 SCN 변경 /  ITL 슬롯 변경도 블록 헤더 내용을 변경하는 작업으로 동시 액세스가 발생하면 Lost Update 문제가 생겨 블록 자체의 정합성이 깨질 수 있다.
  • 블록 진입 자체를 직렬화 해야한다.

(4) 버퍼 Pinning

"버퍼 Pinning" 버퍼를 읽고 나서 버퍼 Pin을 즉각 해제하지 않고 데이터베이스 Call이 진행되는 동안 유지하는 기능

같은 블록을 반복적으로 읽을  때 버퍼 Pinning을 통해 래치 흭득 과정을 생략하면 논리적인 블록 읽기(Logical Reads) 횟수를 획기적으로 줄일 수 있다. 

같은 블록을 재방문할 가능성이 큰 몇몇 작업들을 수행할 때만 사용한다.

v$sysstat, v$sesstat, v$mystat 등을 조회해 보면, 래치 흭득 과정을 통해 블록을 액세스 할 때는 session logical reads 항목이 증가하고, 래치 흭득 과정 없이 버퍼 Pinning 을 통해 블록을 곧바로 액세스 할 때는 buffer is pinned count 항목의 수치가 증가한다.

버퍼 pinning은 하나의 데이터베이스 Call(Parse call, execute call, fetch call) 내에서만 유효하다. 즉 Call이 끝나고 사용자에게 결과를 반환하고 나면 Pin 은 해제되어야 한다.

전통적으로 버퍼 Pinning이 적용되던 지점은 인덱스를 스캔하면서 테이블을 액세스할 때의 인덱스 리프 블록이다. 

Index Range Scan하면서 인덱스와 테이블 블록을 교차 방문할 때 블록 I/O를 보면, 테이블 블록에 대한 I/O만 증가하는 이유가 여기있다. → 클러스터링 팩터가 좋은 인덱스의 경우 효과는 극대화 된다. (= 인덱스 레코드가 가리키는 테이블 rowid 정렬 순서가 인덱스 키 값 정렬 순서와 거의 일치한다면) 

이외에도 DML 수행시 Undo 레코드를 기록하는 Undo 블록도 Pinning 적용

01 | 오라클 아키텍처

02 ) DB 버퍼 캐시

빠른 데이터 입출력을 위하 SGA 공유 메모리를 이용한다. 

사용자가 입력한 데이터를 데이터파일에 저장하고 이를 다시 읽는 과정에서 거쳐 가는 캐시 영역이 SGA 구성 요소 중 하나인 DB 버퍼 캐시이다. 

(1) 블록 단위 I/O

오라클에서 I/O는 블록(block)단위로 이루어진다. 

1. DB buffer Cache → Datafile

2. Datafile → DB buffer Cache 

두 과정 모두 블록 단위로 I/O 가 이루어진다. 

인덱스를 경유한 테이블 액세스 시에는 한 번에 한 블록씩(single block read) 읽어들이지만, Full Scan 시에는 성능 향상을 위해 한 번에 여러 개 블록(multi block)을 읽어들인다. 

DBWR 프로세스는 버퍼 캐시로부터 Dirty block을 주기적으로 데이터파일에 기록하는 작업을 수행하느데, 이때도 성능 향상을 위해서 한 번에 여러 블록을 처리한다. 

▶ DBWR은 주기적으로  DB Buffer Cache에서 변경된 블록을 데이터파일에 기록 (동기화 과정)

블록 단위로 읽는다는 것은 하나의 레코드에서 하나의 컬럼만 읽고자 하는 경우에도, 레코드가 속한 블록 전체를 읽는다는 것이다.

SQL의 성능을 좌우하는 가장 중요한 성능지표는 블록 개수이며, 옵티마이저의 판단에 가장 영향을 미치는 것도 액세스해야 할 블록 개수이다. 옵티마이저가 인덱스를 이용해 테이블을 액세스할지 아니면 Full Table Scan 할지를 결졍하는 데 있어 가장 중요한 판단 기준은, 읽어야 할 레코드 수가 아니라 블록 개수이다.

(2) 버퍼 캐시 구조

DB Buffer Cache 의 가장 직관적인 그림은 바둑판 모양이다. 

SGA 내에서 가장 많이 사용되는 자료구조는 해시 테이블(Hash Table)이다.

DB Buffer Cache 도 Hash Table 구조로 관리된다. 

Hash Key : 데이터 블록 주소(DBA; Data Block Address)

Hash Function : DBA 입력한 해쉬 값 리턴

Hash Bucket : 해시 함수에 의해 리턴 받은 해시 값을 저장

Hash Chain : 동일한 해시 값에 의한 Buffer Header 를 Linked List 로 연력한 구조 (실제 데이터 값은 버퍼 헤더에 있는 포인터에 의해 버퍼 블록을 찾아감)

즉, 사용자가 찾고자하는 데이터 블록 주소를 해시값으로 변환해서 해당 해시 버킷에서 체인을 따라 스캔하여 데이터를 찾고, 찾고자한 데이터블록이 있는 경우 그대로 읽고, 없는 경우 디스크에서 읽어 해시 체인에 연결한 후 읽는다. 

이렇게 체인에 연결된 데이터는 다른 사용자들도 나중에 읽을 수 있도록 캐싱하는 것이다.

▶ Buffer Header만 Hash Chain에 연결되며, 실제 데이터 값이 필요해지면 버퍼 헤더에 있는 포인터를 이용해 버퍼 블록을 찾아가는 구조이다. 

(3) 캐시 버퍼 체인

각 해시 체인은 래치(Latch)에 의해서 보호된다. DB 버퍼 캐시는 공유 메모리 영역인 SGA에 존재하므로 여러 프로세스에 의한 동시 액세스 요청이 일어날 가능성이 높다. 

같은 리소스에 대한 액세스를 반드시 직렬화해야 하고, 이를 위해 구현된 일종의 Lock 매커니즘이 Latch이다.

래치를 흭득한 프로세스만이 그 래치에 의해 보호되는 자료구조로의 진입이 허용된다.

두 개 이상의 프로세스가 같은 해시 체인으로 진입해 새로운 버퍼 블록을 연결하고 해제하는 작업을 동시에 진행한다면 문제가 발생할 수 있다. 이를 방지하기 위해서 사용하는 것이 cach buffers chains 래치이다.

cache buffers cahins : 여러개의 해시 체인을 동시에 관리

Oracle 9i 부터 Shared Mode와 Exclusive Mode로 관리

Shared Mode : 해시 체인을 스캔하여 필요한 블록 검색

Exclusive Mode : 체인 구조 변경(체인 추가, 삭제) 혹은 Buffer Pin 설정

해시 버킷 : 해시 체인 = 1 : 1 을 목표 ▶ 해시 체인을 찾고난 후 추가적인 스캔에 의한 비용 최소화

✔︎ Latch 는 데이터 자체를 보호하는 것이 아닌, SGA에 공유되어 있는 자료구조를 보호하는 것이며, 그 중 cache buffers chains 래치는 버퍼 캐시에 연결된 체인구조를 보호하는 것이다.

(4) 캐시 버퍼 LRU 체인

버퍼 헤더는 해시 체인뿐만 아니라 LRU체인에 의해서도 연결되어 있다.

버퍼 캐시는 한번 읽은 데이터 블록을 캐싱해두지만, 유한한 자원이 아니기 때문에 읽은 모든 데이터를 캐싱할 수 없다.

버퍼 캐시가 사용도가 높은 데이터 블록들 위주로 구성될 수 있도록 LRU(Least Recently Used) 알고리즘을 사용해 관리한다.

모든 버퍼 블록 헤더를 LRU체인에 연결해 사용빈도 순으로 위치를 옮겨가다가, Free 버퍼가 필요해질 때마다 액세스 빈도가 낮은 데이터 블록들을 우선하여 알아냄으로써 자주 액세스 되는 블록들이 캐시에 더 오래 남아 있도록 관리한다.

📌 LRU알고리즘

- 가장 최근에 사용한 버퍼 캐시를 MRU(Most Recently Used) End에 위치

- Free Buffer가 필요할 때 LRU(Least Recently Used) End에 위치한 버퍼 캐시부터 밀어냄

📌 LRU List

- Dirty List : 캐시 내에서 변경되었지만, 아직 디스크에 기록되지 않은 Dirty Buffer Block 관리, LRUW(LRU Write) 리스트라고도 한다.

- LRU List : 아직 Dirty 리스트로 옮겨지지 않은 나머지 버퍼 블록들을 관리 ( Pinned Buffer, Free Buffer, Dirty List에 옮겨 가지 않은 Dirty Buffer)

- 모든 버퍼 블록은 둘 중 하나에 반듯 속해 있다.

- LRU List 를 보호하기 위한 래치 : cache buffers lru chain

⭐️ Buffer 상태

1. Free Buffer : Instance 기동 후 한번도 사용 하지 않은 버퍼 / 데이터를 사용하였으나 변경되지 않은 버퍼 / 변경 후 데이터 파일과 동기화된 버퍼 

2. Dirty Buffer : 캐시된 후 데이터의 변경이 발생 되었으나 데이터파일에 아직 기록되지 않은 버퍼

3. Pinned Buffer : 읽기 혹은 변경을 위해 현재 액세스 되고 있는 버퍼 

01 | 오라클 아키텍처

01 ) 기본 아키텍처

오라클은 데이터베이스와 이를 액세스하는 프로세스 사이에 SGA(System Global Area)라고 하는 메모리 캐시 영역을 두고 있다.

인스턴스 : 메모리 + 프로세스

데이터베이스 : 데이터파일 + redo log file + control file

디스크를 경유하는 I/O는 물리적으로 액세스 암(Arm)이 움직이면서 헤드를 통해 데이터를 읽고 쓴다.

메모리를 통한 I/O는 전기적 신호를 통해 이루어지기 때문에 디스크를 경유하는 경우와 비교할 수 없을 정도로 속도가 빠르다. 

디스크 I/O 속도 < 메모리 I/O 속도 (캐시)

데이터베이스는 많은 사용자들이 동시에 데이터에 액세스하기 때문에 데이터를 보호하기 위해 Lock은 물론 SGA상에 위치한 데이터 구조에 대한 액세스를 직렬화하기 위한 Lock 매커니즘(=래치, Latch)도 필요하다.

트랜잭션의 직렬성 : 여러 트랜잭션이 동시에 병행 수행되더라도 각 트랜잭션이 하나씩 차례대로 수행되는 것과 같은 일관성을 보장하는 수행특성

인스턴스를 구성하는 프로세스에는 서버 프로세스와 백그라운드 프로세스가 존재한다.

서버 프로세스 : 사용자가 던진 명령을 처리

백그라운드 프로세스 : 서버 프로세스가 스스로 처리하지 못하는 작업 (버퍼 캐시로 블록 적재 등)을 처리

오라클에 접속하면 각 클라이언트를 위한 전용 서버 프로세스가 뜨고, 사용자에게 필요한 서비스를 제공한다. SQL을 파싱하고 필요하면 최적화를 수행하며, 커서를 열어 SQL을 실행하면서 블록을 정렬해서 클라이언트가 요청한 결과집합을 만들어 네트워크를 통해 전송하는 일련의 작업들을 모두 서버 프로세스가 처리해 준다. 

 오라클에서 세션이 수립되는 과정은 다음과 같다.

1. 사용자가 오라클 접속 연결 요청

2. 사용자로부터 연결 요청을 받은 리스너가 서버 프로세스를 생성 

3. 서버 프로세스는 PGA를 할당 받음

4. 서버 프로세스 생성 완료에 대한 패킷을 사용자에게 전송

5. 사용자 해당 서버 프로세스로 연결하여 DB접속

▶ 리스너에 연결요청을 하는 순산 하나의 프로세스를 띄우고 (fork) PGA메모리를 할당한다. 

프로세스 하나를 띄우고 PGA를 할당하는 과정은 cost가매우 큰 작업으로 SQL문을 실행할 때마다 연결요청을 받아 프로세스를 할당받아 실행하는 것은 성능적은 측면에서 좋지 않다. 그래서 반드시 Connection Pool 기능이 필요하다.

Connection Pool ▶ 한번 커넥션을 맺으면 작업을 완료하더라도 이를 해제하지 않고 애플리케이션 서버에 Pooling 하고 있다가 세션을 반복 재사용을 한다. 

Tibero Backup & Recovery 

Backup & Recovery 개요

• 백업과 복구는 여러 가지 유형의 장애(시스템 장애, 미디어 장애, 사용자 실수 등)로부터 데이터베이스를 보호하는 핵심적인 기능이다.
  • 보호 대상 장애 유형
    1. 하드웨어 장애 : 디스크 손상, 서버 다운 등
    2. 소프트웨어 장애 : DBMS오류 등
    3. 사용자 오류 : 실수로 인한 데이터 삭제, 잘못된 UPDATE/DELETE 실행 등
    4. 재해 상황 : 화재, 정전, 천재지변 같은 예기치 못한 사건
• 백업의 역할
  • 데이터 복원 지점 확보 : 특정 시점의 데이터 상태를 보관
  • 서비스 연속성 보장 : 장애 발생 시 신속한 복구 가능
  • 데이터 손실 최소화 : 장애 발생 이후 손실되는 데이터를 최소화
• 복구의 역할
  • 장애 직전 시점으로 데이터 회복 : Redo/Undo 로그를 이용해 트랜잭션 적용/취소
  • 업무 중단 시간 단축 : 백업 및 복구 전략에 따라 다운타임 최소화
  • 데이터 무결설 보장 : 복구 과정에서 트랜잭션의 일관성과 무결성을 유지
• 관리자는 시스템 장애 시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야 한다.
  • 최소한 한 달에 한번 데이터베이스 전체 백업
  • 하루에 한번씩 Export 백업 권장
• 데이터베이스 관리자는 백업에 대한 정책을 수립하고, 꼭 필요한 데이터를 최소한의 양으로 백업
  • 백업은 DBA의 주요 역할 중 하나로, 가장 주의가 필요하다.
• "RECOVERY에 실패한 DBA는 용서할 수 있지만, BACKUP을 실패한 DBA는 용서할 수 없다."
• 백업이 정상적으로 수행되었는지 주기적인 검증 권장

▶️ 백업은 예방(사전 대비)이고, 복구는 대응(사후 처리)의 개념이라고 할 수 있다.

여러가지 유형의 장애

#1 명령문의 실패 

명령문의 실패 원인에는 다음과 같은 것들이 있다.

• 테이블의 제약 조건에 위배되는 데이터 INSERT
• 권한의 부족
• 테이블 생성 시 또는 데이터 변경 시 테이블스페이스의 공간이 부족한 경우

이러한 장애는 데이터 유실과는 관련이 없는 에러이다.

#2 사용자 프로세스의 실패

• 비정상적인 종료로 인한 사용자 프로세스의 실패가 대부분
• Tibero 의 monitor process가 비정상적인 종료를 감지하고 수행중인 트랜잭션 등은 롤백시킨다.

#3 사용자로 인한 장애

• 장애 발생 상황
  • DROP TABLE
  • TRUNCATE TABLE
  • DELETE FROM & COMMIT
  • 잘못된 UPDATE & COMMIT
• 해결 방안
  • 사용자에 대한 교육 실시
  • 백업에서 복구
  • Export 받은 파일에서 테이블을 Import
  • Time-based 불완전 복구

#4 Instance Fail

• 정전, CPU나 Memory Fault, Background Process의 비정상적인 종류가 대부분이다.
• 복구
  • 특별한 복구 작업이 필요하지 않음
  • tbboot을 통해 DBMS를 기동하면 자동으로 복구됨
  • 로그 등을 참고하여 원인 분석

#5 Media Fail

• 데이터파일이 저장된 하드 디스크의 장애
• 데이터 파일의 삭제
• 정해진 복구 전략에 따라 복구 절차가 필요
• Media Fail은 반드시 발생할 수 밖에 없다. 하드디스크에도 수명이 존재하기 때문에 24시간 계속 모터가 돌아가다 보면 언젠가 문제가 발생하여 데이터 유실이 발생할 수 있다.

Backup & Recovery 전략 수립

1. 업무적인 요구 사항
   • MTBF(Mean Time Between Failure)를 증가시키고, MTTR(Mean Time To Recover)를 감소
   • MTBF: 평균 고장 간격
     • 시스템이나 장비가 고장 없이 정상적으로 동작하는 평균 시간
     • 얼마나 신뢰성이 높은지를 나타낸다.
     • MTBF = 총 가동 시간 / 고장 횟수 
       • ex) 서버가 1년동안 (8760시간) 4번 다운되었다면 -> MTBF = 8760 / 4 = 2190 시간 → 약 3개월에 한 번꼴로 고장 발생
   • MTTR : 평균 복구 시간
     • 장애가 발생했을 때 복구하여 정상 기동까지 걸리는 평균 시간
     • 얼마나 빨리 가용성을 회복할 수 있는지를 나타냄
     • MTTR = 총 복구 시간 / 고장 횟수
       • ex) 장애 4번 동안 복구에 총 20시간이 걸렸다면 → MTTR = 20 / 4 = 5시간 → 한 번 장애 발생 시 평균 5시간 다운타임
   • MTBF vs MTTR
     • MTBF → 얼마나 자주 고장이 나는가 (신뢰성 지표)
     • MTTR → 고장이 났을 때 얼마나 빨리 고치는가 (유지보수성 지표)
     • 두 지표는 시스템 가용성(Availability) 계산에 활용된다.
     • Availability = MTBF / MTBF + MTTR
2. 운영 요구 사항
   • 24*365 운영, 백업 테스트 및 검증, 데이터베이스의 변경, 백업 데이터의 보관 장소 등
3. 기술적 고려 사항
   • 하드웨어, 소프트웨어의 구성, 백업 주기 결정을 위한 트랜잭션 주기, 데이터의 양 등
4. 경영진 합의
   • 경영진에서 기대하는 시스템의 가용성, 백업 및 복구 절차에 대한 이해, 백업을 위한 리소스 확보 등

💡 백업 - 파일 변경이 잘 되지 않는 시간대에 백업 전략을 수립해야 한다. 

Tibero 동작 방식의 이해

Transaction Durability

• Committed Transaction MUST Survive failures (Recoverable)
• 데이터 입력/수정 작업은 COMMIT을 수행하면 변경된 내용이 확정되어 Durability를 확보하게 된다.
• 데이터는 Durability가 확보가 안되어 있으면 유실될 수 있다.
• 데이터가 어떻게 하면 날아가지 안혹 안전하게 보관할 수 있을까?
  • 메모리에만 반영되면 장애 시 데이터가 유실 될 수 있기 때문에 영속 저장 장치에 반드시 기록해야 한다. 이때 사용되는 것이 Redo Log(로그 기록)이다.
• Commit이 되는 시점에 데이터 변경이력을 파일에 기록함으로써 Durability를 확보한다.

Logging

• Redo Log Buffer : TSM에 redo 데이터를 저장하기 위한 영역 → 데이터베이스의 모든 변경이력을 메모리에 저장
• Redo Log File : Recovery를 위해 가장 중요한 파일 → 메모리에 저장된 변경 이력을 사라지지 않도록 파일로 저장
• Archive : archive log mode 시 redo logfile을 별도의 위치에 backup

관련 background process

• DBWR, RCWP ( tibero 6 FS07 ~ )
• DBWR, RECO ( tibero6 ~ tibero6 FS06 )
• LGWR, DBWR, CKPT, LARC ( ~ tibero5 )

⭐️ Redo 저장 대상 범위

1) Physical Logging (물리적 로깅)

데이터 변경이 일어날 때마다 해당 Block 전체를 Redo Log에 남긴다.

변경 작업이 발생할 때마다 Block Size 만큼의 로그가 남아 많은 양 유지가 필요하다.

실제 데이터 블록의 변경된 내용(변경 전/후 이미지나 REDO 정보)을 로그에 기록

장점 : Recovery시 단순히 블록에 그대로 반영하면 되기 때문에 복구가 빠르고 간단하다는 장점이 있다.

단점 : 로그 사이즈가 크다.

2) Logical Logging (논리적 로깅)

UPDATE, DELETE 같은 OPERATION 을 LOG에 남기는 방법으로, 여러 Physical Block들에 대한 수정을 하더라도 OPERATION만 기록되어 Logging 양이 적다.

반드시 순서대로 Change Apply (Recovery때 Log Apply 어려움)

▶️ 논리적 로깅에는, '어느 블록(Block) 몇 번째 Row Slot이 바뀌었다.' 같은 물리적 위치 정보가 들어있지 않고, '이 연산 그대로 다시 실행하라' 는 의미마 남는다. Logical Log는 Opertaion만 기록되어 있기 때문에, 장애가 발생시 DBMS SQL을 모두 순차적으로 실행해야 한다. 

장점 : 로그 양이 적다( Operation 하나로 여러 블록 변경을 커버할 수 있다. )

단점 : 복구 시 반드시 순서대로 재적용해야 하며, 인덱스/트리 구조가 변하면 복잡해진다. 또한, 동시에 다른 트랜잭션이 섞여 있으면 복구가 어렵다.

3) Physiological Logging

Physical Logging과 Logical Logging의 장점을 합친 형태

Block의 Physical Change를 기록하는 Change Vector 들로 구성된 REDO RECORD

Change Vector는 Atomic Block Change로, Redo Record는 Atomic Database Change

블록에 대해서는 Physical 하게, 블록 내부 변경 내역은 Logical 하게 기록

Redo Log는 항상 특정 Block을 지정하며, 그 Block 안에서 어떤 Row/Slot/Column을 어떻게 바꿨는지는 논리적 연산으로 기록한다.

💡 Change Vector / Redo Record 

Change Vector

• Redo Log의 최소 단위
• 하나의 Atomic Block Change(블록 내에서 더 쪼갤 수 없는 단일 변경)
• 예 : Block #100의 Row Slot 3 → SAL 값을 800 →900으로 바꿈

Redo Record

• 하나 이상의 Change Vector를 모아 놓은 것
• Atomic Database Change (트랜잭션의 한 DB변경 단위)
• 예 : UPDATE문 하나가 여러 블록 (Row/Index 블록 등)에 영향을 줄 수 있는데,
  • Data Block 변경 Change Vector
  • Index Block 변경 Change Vector
  • Undo Block 변경 Change Vector
  •  → 이들을 합친 것이 하나의 Redo Record

※ 티베로는 Physiological Logging 방식으로 동작한다.
데이터는 커밋할 때 Durability를 확보한다. 이것과 관련있는 것이 Redo Log - Redo Log가 기록될 때는 변경 이력만 기록하는 Logical, Block 전체를 기록하는 Physical Logging 이 있다.
기본적으로 Physiological Logging을 하며, 특정 상황에서 Physical Logging을 한다. 
특정상황 예시 ) Begin Backup ~ End Backup 사이 시점에서 대상 테이블스페이스의 특정 데이터 블록을 변경하는 경우 Physical Logging 방식으로 로깅한다.

Redo 저장 시 발생

Page fix rule

데이터 블록을 수정하기 전에 반드시 블록에 대한 LOCK을 설정하고, 실제 데이터 버퍼 (Data Buffer)를 수정하기 전에 Redo Record를 먼저 생성한다는 규칙이다.

Redo Log는 복구를 위한 최소 단위이기 때문에, 블록이 변경되면 그 변경 이력이 Redo에 반드시 남아야 Durability를 보장할 수 있다.

✅ Redo Record를 먼저 생성하지 않고 데이터 블록을 수정하게 되면, 장애가 발생했을 때 Redo에 기록이 남아있지 않아 복구가 불가능 할 수 있기 때문에 데이터 블록 수정 전에 Redo Record를 생성하는 것이다.

WAL(Write Ahread Logging)

DB의 핵심 규칙 중 하나이다.

데이터 블록이 변경되기 전에 Redo Record가 먼저 Log Buffer에 기록되어야 한다.

예시 :

    사용자가 UPDATE 실행 → DB Buffer에 변경 예정

    하지만 DBWR이 Dirty Buffer를 디스크에 Write하기 전에, 해당 변경 Redo가 Log Buffer → Log File에 먼저 기록된다.

이유 : 장애가 발생해도 Log에 기록된 변경 사항으로 복구할 수 있도록 하기 위함이다. 데이터 블록을 디스크에 반영하기 전에, 반드시 그 변경 이력을 먼저 로그(Redo)에 기록해야 하낟.

데이터베이스에서 트랜잭션이 UPDATE/INSERT/DELTE 같은 작업을 하면, 먼저 메모리(Buffer Cache)의 블록이 수정된다. 나중에 DBWR이 Dirty Block을 디스크(Datafile)에 Write한다. 만약 메모리에만 반영된 상태에서 DB가 다운되게 되면, 데이터파일에는 반영이 되어 있지 않았기 때문에 데이터가 유실되게 된다. 따라서 장애 복구를 위해 Redo Log(변경이력)을 먼저 기록해 둬야 한다. DB가 재기동되면, Redo Log를 읽어서 Datafile에 적용(Redo Apply)하면 복구가 가능하다. 

Redo Log도 Memory에만 기록되어 있으면 안되고, Redo Log File로 디스크에 기록되어 있어야 한다. Commit을 하게 되면 Redo Log Buffer의 내용이 Redo Log File로 저장된다.

Log force at commit

Commit 발생 시 Log Buffer의 Redo entry를 모두 Log file에 Write

Commit 된 데이터의 보장

Online log switch

Online Log 중 다음의 조건을 만족하는 Log file 로 Switching

Database (Controlfile, Redolog file, Datafile) 동기화 방식

1. TSN

• Database의 version 또는 commit version
• Data Concurrency Control, Redo Ordering, Recovery 등에 사용
• Transaction이 commit 될 때 TSN이 generate 된다.

2. Checkpoint

• 주기적으로 또는 사용자의 요청에 따라 메모리에 있는 모든 변경된(dirty) block을 디스크에 쓰는 작업
• 복구에 필요한 logfile의 양을 줄인다.
• Checkpoint 발생 상황
  • 모든 로그 스위치 발생시
  • 인스턴스가 NORMAL, POST_TX, IMMEDIATE 옵션으로 종료
  • 사용자 요청에 따라 수동으로 발생 (ALTER SYSTEM CEHCKPOINT;)
• ALTER TABLESPACE [BEGIN BACKUP | END BACKUP];
• Checkpoint 발생 시, DBWR가 작동하기 전 먼저 LGWR 이 현재 log buffer의 내용을 online log file에 write하여 해당 dirty buffer 에 mark 가 되면, 이 정보를 DBWR이 받아서 모든 marked dirty buffer를 disk에 기록
• Checkpoint는 Checkpoint TSN 이전에 발생한 Online log file내의 모든 변경 사항이 Disk 에 저장되었음을 의미

변경이 필요한 블록이 buffer cache에 그대로 있다가 dirty block들을 모아서 한번에 데이터파일에 작성한다. => checkpoint

이렇게 한번에 데이터파일에 작성하는 것이 효율이 더 좋기 때문이다. 데이터 블록을 데이터파일에 계속 즉시즉시 변경이 있을때마다 쓰게 된다면 변경때마다 Disk I/O가 발생하여 효율적이지 못하기 때문이다. 

Backup 개요

시스템 장애 발생시 복원을 하거나, 시스템 작동을 유지하기 위한 절차 또는 기법

관리자는 시스템 장애 시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야 한다. 

• 최소 한달에 한 번 데이터베이스 전체 백업(Full Backup)
• 하루에 한번씩 Export 백업 권장

데이터베이스 관리자는 백업에 대한 정책을 수립하고 꼭 필요한 데이터를 최소한의 양으로 백업

Backup 종류

1. 논리적 백업 ➡️ 나중에 복구할 때 쉽고 빠르게 진행할 수 있음 / 장애 범위가 어떠냐에 따라서 백업본도 문제가 발생할 수 있음
   • 데이터베이스의 논리적인 단위 백업 
   • Table, Index, Constraint, Sequence 등
   • Export 툴로 백업
2. 물리적 백업 ➡️ 복구할 때 다시 로컬 서버로 가져와야 해서 네트워크 속도에 따라 오래걸릴 수 있음
   • 데이터베이스르르 구성하는 파일을 운영체제 레벨에서 COPY 명령으로 백업
   • datafile, controlfile, archive logfile

✅ 각 하나의 백업만 하는 것이 아니라 둘 다 섞어서 백업해도 된다.

속도 : 파일을 그냥 OS 레벨에서 COPY하는 것이기 때문에 물리적 백업이 더 빠름, 논리적 백업은 파일내에서 논리적인 데이터를 뽑아내서 백업하는 것이기 때문에 물리적 백업보다 느리다.

COPY는 티베로 DBMS가 주체가 아니다. 파일을 가지고 있는 주체는 티베로지만, 복사하는 것은 백업을 작업하는 사람이 하는것이다. (보통 백업 소프트웨어를 사용) 논리적 백업 진행하는 작업자가 tbExport를 통해서 선택적으로 백업할 수 있다. (특정 테이블만 백업)

Backup 대상(Controlfile & Redo logfile)

Controlfile 기능

• 데이터베이스의 구조를 이진 파일 형태로 저장
• 데이터베이스를 mount할 때 반드시 필요
• 파일이 없으면 복구를 하거나 재생성
• 두 개 이상의 contolfile 로 구성 하는 것을 권장, 서로 다른 디스크에 위치

동적뷰

• v$controlfile

다중화 방법

• 데이터베이스를 down(tbdown)
• Controlfile 을 다른 위치로 copy
• $TB_SID.tip 파일에서 CONTROL_FILES 파라미터에 추가
• 데이터베이스를 기동(tbboot)

Redo logfile

• 데이터베이스의 모든 변경 사항을 저장
• 최소한 2개 이상의 redo log group으로 구성
• 각 log group 은 하나 이상의 redo logfile로 구성

동적뷰

• V$LOG, V$LOGFILE

다중화

• Logfile의 손실을 대비하여 각각의 redo log group은 2개 이상의 logfile로 구성할 것을 권장
• Log group의 logfile들은 별도의 disk로 분리
• Log group의 추가
  • ALTER DATABASE ADD LOGFILE GROUP 4 ('/home/tibero6/tbdata/redo41.log', '/home/tibero6/tbdata/redo42.log') SIZE 10m;
• Log group에 member 추가
  • ALTER DATABASE ADD LOGFILE MEMBER '/home/tibero6/tbdata/redo43.log' TO GROUP 4;

Contolfile 백업

• Offline backup : O/S 의 COPY 명령을 통해 별도의 위치에 copy (티베로 종료하고 백업) 
• Online backup : 다음과 같이 controlfile 구문을 생성해 copy (티베로 종료하지 않고 백업)
  • 💡 Online 중에는 티베로 인스턴스(프로세스)가 컨트롤 파일을 읽고, 쓰고 있기 때문에, 온라인 중 파일을 COPY하게 되면 컨트롤 파일이 변경되는 와중에 복사하게 된다. 파일의 내용이 깨진채로 COPY가 될 수 있다. 그래서 Online 백업을 하는 방법은 단순 파일 카피가 아닌 구문을 통해서 진행해야 한다.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS [백업할 파일 경로 및 이름] REUSE NORESETLOGS;

예) 아래와 같은 Controlfile 구문이 담긴 파일 생성

CREATE CONTROLFILE REUSE DATABASE "tibero"
LOGFILE
NORESETLOGS
	GROUP 0 ('/home/tibero6/tbdata/log01.log', '/home/tibero6/tbdata/log02.log') SIZE 3M,
    GROUP 1 ('/home/tibero6/tbdata/log11.log', '/home/tibero6/tbdata/log12.log') SIZE 3M,
    GROUP 2 ('/home/tibero6/tbdata/log21.log', '/home/tibero6/tbdata/log22.log') SIZE 3M
DATAFILE
	'/home/tibero6/tbdata/system001.dtf',
    '/home/tibero6/tbdata/undo001.dtf'
NOARCHIVELOG
MAXLOGFILES 100
MAXLOGMEMBERS 8
MAXDATAFILES 256;

Backup 방식 차이 (NOARCHIVELOG VS ARCHIVELOG)

NOARCHIVELOG MODE

• 기본적으로 데이터베이스는 NOARCHIVELOG MODE이다.
• Redo logfile은 순환하여 사용되고 log switch가 발생하면 이전의 logfile을 overwrite한다. 이전의 log가 없으므로 트랜잭션 기록 중 최근의 부분만 사용가능하다.
• 백업은 반드시 데이터베이스가 정상 종료된 상태에서 해야 하며 이로 인해 서비스의 중지가 발생한다.

ARCHIVELOG MODE

• Redo logfile은 LOGA(LOG Archiver)에 의해 백업이 완료되기 전에는 사용 불가능하다.
• Archive logfile은 media recovery에 사용가능하다.
• 데이터베이스가 기동 중 백업 가능하다.

ARCHIVELOG Mode의 Backup 방식

Archive log mode

• Log switch시 Redo logfile을 별도의 분리된 위치로 복사하여 저장하여 운영하는 방법
• Archive logfile은 recovery 시 사용되는 매우 중요한 파일
• Online Backup 시 반드시 archive log mode로 운영

관련 Background process / initial parameter

• LOGA(Log Archiver Process) :
  • Redo Log 파일을 Archive log 파일로 복사하는 프로세스
  • ARCHIVELOG Mode에서만 의미가 있다.
  • 일반적으로 DB 기동 시 자동으로 실행되며, Archive log를 지정된 위치에 생성
  • 만약 ARCHIVELOG Mode가 아니면, LOGA는 필요하지 않으므로 자동으로 종료된다.
  • ARCHIVELOG Mode → LOGA 기동 유지
  • NOARCHIVELOG Mode → LOGA 기동했다가 곧바로 종료됨 (아무 할 일이 없기 때문)
• LOG_ARCHIVE_DEST : 
  • archive logfile이 저장되는 위치

변경 방법

• 데이터베이스 down (tbdown)
• 데이터베이스를 mount 모드까지 기동
  • $ tbboot mount
• SYS 유저로 접속하여 archive log mode 로 변경
  • $ tbsql sys/tibero
  • SQL > ALTER DATABASE ARCHIVELOG;
• 데이터베이스 종료 후 재기동

Archive log mode 확인

• V$DATABASE : LOG_MODE 컬럼 조회

Archive log 정보

• 아카이브 대상 상태 이해
• V$ARCHIVE_DEST_FILES : LOG_ARCHIVE_DEST 내의 archive log files의 정보 표시
• V$ARCHIVED_LOG : Archive log 정보 표시

Archive log 대상 지정($TB_SID.tip)

• LOG_ARCHIVE_DEST

✅ Archive Logfile도 백업 대상임으로, Archive Logfile 저장 사이즈는 하루 발생하는 Redo log 발생량을 고려하여 설정해야 한다.