1. 개념

 LOB은 일반 primitive type, varchar 등과 달리 4000 bytes 이상이 되도 문제없이 저장한다. 또한, 오라클 내부적으로 4000 bytes를 넘지 않으면 inline LOB이라고 해서 redo log에도 남고, lob locator 할당 없이 row가 저장된 데이터 블록 또는 다른 데이터 블록을 직접 가리켜서 저장한다.

2. LOB 내부 설계 구조

 out of line LOB(differed LOB)의 경우 lob locator를 가지게되서 같은 column에서 공유하는 LOB index(B* tree)를 타게된다. lob locator는 inode, lob id 등으로 구성되는데, lob id를 키로 LOB index의 특정 leaf node에 접근할 수 있다. 이 leaf node는 한 데이터 블록이고, 데이터가 저장된 데이터 블록을 가리키는 포인터들을 저장하고 있다. 물론 데이터를 저장하는 곳은 할당받은 LOB segment 안이다.

 또한, LOB index는 old key도 저장해서 이전 커밋 버전의 데이터 블록을 가리킬 수 있다. 그러므로 flashback query로 LOB을 조회해도 CR(consistent read)가 가능하다. 예상할 수 있듯이, new key는 현재 LOB을 볼 수 있는 leaf node를 말하고, DBMS_LOB 패키지로 여러 블록을 쓰는 LOB 데이터의 중간 블록만 수정하면 수정되는 데이터 블록만 바꿔서 효율적으로 큰 데이터를 CR로 보여줄 수 있다.

3. 사족

 이러한 특별한 구조로 인해 rollback을 하면 일반 데이터는 undo segment에서 찾아온 UNDO를 적용하고 redo log에 이를 남기지만, LOB은 leaf node의 데이터 블록을 가리키는 포인터를 수정한다거나, leaf node 블록 자체를 되돌리는 작업을 하고 이를 redo log에 남긴다.

 이 설명은 DBMS에 따라 다를 수 있으며, LOB 데이터를 file system에 맡겨서 파일에 저장한다면 LOB index의 leaf node가 데이터 블록이 아닌 파일을 가리킬 수도 있다.

https://www.slideshare.net/tanelp/oracle-lob-internals-and-performance-tuning

기본적으로 DB는 DBWR가 직접 파일에 변경사항을 쓰기 전, LGWR가 redo log에 할 일을 한 레코드 단위로 쓴다. 이 레코드는 redo와 undo redo로 구성된다. undo redo는 redo로 바뀐 사항을 다시 undo하기 위해 redo log에 쓰는 undo의 redo이다. 이는 undo가 꼭 필요하기 때문인데, undo는 다음 세 가지 1. rollback, 2. tx recovery, 3. CR(consistency read)를 위해 필요하다. 아래 설명은 각각의 예시를 말한다.

1. 사용자가 rollback하면 redo 레코드의 redo로 바뀐 부분을, redo 레코드의 undo redo로 되돌린다.

2. DB가 redo를 쓰던 도중에 종료되면 roll forward recovery를 시작한다. 마지막 checkpoint 이후 redo log에 남겨진 내용을 모두 적용시키고, 다시 rollback하여 커밋된 내용만 남긴다.

3. isolation level 중 read committed, repeatable read는 특정 시점의 데이터 블록을 다시 보기 위해 undo를 사용해야한다.

참고

d2.naver.com/helloworld/407507

https://docs.oracle.com/en/database/oracle/oracle-database/18/cncpt/memory-architecture.html#GUID-093B7282-1A44-4E29-9E9A-B8511F4267C9

/* SGA = shared pool + large pool + db buffer cache + redo log buffer + ... */

1. 목적: IO 최적화(redo log buffer 사용), data block 캐싱(flash disk 사용 시 가능)

2. buffer state: 1) Unused: 한 번도 안씀, 2) Clean: 썼다 지움, 3) Dirty: 아직 disk에 안씀(ckpt 되어야 clean 가능)

3. buffer mode: current mode, consistent mode에 따라 캐시의 내용을 undo data 사용해서 주냐 안주냐 차이이다.

4. buffer IO: LRU 알고리즘 or Temperature based, object-level replacement algo. 를 사용해서 data block을 교체하는데, 보통 LRU 씀. pinned 된 버퍼에는 touch count라는 개념을 쓰기도 하는데, 최근 3초내에 한 번 이상 사용되었으면 +1이 된다. touch count가 높은데 cold end에 있는 block이라면 hot end로 옮겨준다. DBWR는 주기적으로 cold, dirty 버퍼를 디스크에 써준다. 새 버퍼 블록이 필요한데 clean block이 없거나, threshold 이하 개수로 떨어지면 쓰고, LRU cold의 끝에 다다른 블록 또한 써준다. 특이한 상황으로는 checkpoint로 instance recovery를 진행해야할 경우, tablespace가 read-only로 되거나 offline으로 전환될 때 버퍼를 디스크에 쓴다.

flash cache를 사용하는 경우 buffer load 방식은 다른건 다 비슷한데, buffer cache, flash cache 둘다 미스나면 디스크에서 가져와서 둘 다에 등록하는 점이 주목할 만 하다.

5. buffer pools: 버퍼들의 집합이다. 또한 DB 버퍼 캐시는 여러 개의 버퍼 풀로 구성된다. 버퍼 풀은 Default pool(보통 블록들이 캐시되는 곳), Keep pool(자주 사용하는 블록들 담을 캐시, 공간 부족으로 block이 aged out이 될 수도 있다.), Recycle pool(한 번만 쓰고 재사용할 블록들을 모아둔 캐시)가 있다.

6. full table scans: 풀 테이블 스캔 시 작은 테이블은 SGA에 로드하고, 큰 테이블은 PGA에 바로 로드시킨다. 중간 사이즈는 SGA에 로드시킬 경우, 블록을 LRU의 마지막 우선순위에 넣어서 캐시 용량을 많이 사용하지 않도록 한다.

/* SGA = shared pool + large pool + db buffer cache + redo log buffer + ... */

1. Large pool = UGA 할당, 메세지 버퍼 할당, I/O 버퍼 할당, shared pool보다 큰 메모리만 할당해서 fragmentation 방지한다. shared pool의 메모리는 LRU로 관리되지만 large pool은 세션이 존재하는 동안 메모리는 계속 유지된다.

  1.1 shared server에서 사용하는 UGA 할당

  1.2 Oracle XA interface

  1.3 statement 병렬 실행(query coordinator)을 위한 메세지 버퍼 할당

  1.4 RMAN I/O slave를 위한 I/O 버퍼 할당

2. Java pool = JVM의 java code, data 올리는 곳.

  2.1 dedicated server: JVM의 session specific한 java code와 data, 그리고 vector같은 read only class를 올리는 메모리이다. 세션 별 java 상태는 안올림.

  2.2 shared server: 클래스끼리 공유되는 부분, 그리고 세션에 사용되는 UGA의 일부분을 메모리에 올린다.

3. fixed SGA = DB 내부 관리구역이다. background process가 알아야하는 DB / instance 상태, lock 정보를 저장한다.

/* SGA = shared pool + large pool + db buffer cache + redo log buffer + ... */

shared pool = Library cache + DD(data dict.) cache + server result cache + reserved pool + other

  1. Library cache = Shared SQL area + Private SQL area (컴파일된 SQL, PL/SQL을 저장하는 곳)

    1.1 Shared SQL area: 썼던 SQL 코드 정보(execution plan)를 재사용할 수 있다면(cache hit) soft parse라고 하고, 새로 실행해야 한다면 SQL area를 새로 할당받아 사용하며 이를 hard parse라고 한다.

    1.2 Private SQL area: shared server를 사용할 때만 쓴다. 메모리를 할당받을 수도 있고, 메모리 재사용을 위해 shared SQL area의 내용을 포인팅할 수도 있다.

    참고: shared pool 메모리의 할당은 모두 LRU에 따라 해제된다.

  2. DD cache = DD를 너무 자주 사용하기 때문에 만들어진 DD만을 위한 메모리 공간.

    2.1 DD: DB tables, views(DB, 구조, 유저에 관련된) 정보. DD는 테이블 로우로 저장되어 있다.

  3. Server result cache = SQL query result cache + PL/SQL function result cache

    3.1 SQL query result cache: 쿼리에 대한 결과를 캐싱한다. select를 여러번 반복하면 첫 실행에 data block을 읽어서 처리하고, 이 캐시에 저장한 뒤 결과를 바로 가져다 줄 것이다. 저장된 결과를 위한 데이터가 변경되면 캐시는 invalidate 된다. + RESULT_CACHE hint를 줘서 이 캐시에 저장시킬 수 있다.

    3.2 PL/SQL function result cache: 주어진 파라미터에 대한 함수의 결과를 캐싱한다. 함수가 자신이 보는 데이터를 변경하면, 캐싱하지 않는다.

 4. Reserved pool = shared pool이 사용할 수 있는 길고 큰 메모리 공간들. 5KB 이상의 큰 object들을 따로 캐싱하여 fragmentation을 방지한다.

오라클 db = SGA + PGA + background process(RECO, PMON, SMON, DBWn, LGWR, ARCn, ...)

1. SGA = DB가 작업을 하기 위한 총체적인 메모리 영역. 사용자의 CRUD를 저장장치에 바로 실행할 수 있다면 필요없다. 그러나 DB에게 요구되는 ACID를 만족하려면, 이러한 작업을 해주는 메모리 영역이 필요할 것이다. 특히, consistent mode / transaction 중도 실패 시 undo / SQL 구문 재사용 / execution plan 생성 등과 같은 유용하고 필수적인 기능을 구현하려면 메모리 공간이 꼭, 많이 필요하다. 이런거 안쓰면 그냥 sqlite 같이 파일 하나 사용하는 DB를 만들 수는 있을 것이다.(sqlite 제작의 고충이나 내부 구조는 모르지만 일단 기능만 따지자면 그렇다는 말이다)

2. PGA = 유저별 개별 할당되는 메모리 공간. PGA도 물론 중요하지만, SGA가 DB의 몸체라고 볼 수 있다. 또한 구현에 따라 달라질 수 있으므로 PGA는 나중에 설명할 예정이다.

3. b.p. = 각자 맡은 역할을 SGA로부터 데이터를 받아서 실행한다. 예를 들어, LGWR는 redo log를 받아 쓴다. 이 또한 나중에 설명 예정.

 - 오라클 DB 공홈 설명자료

https://docs.oracle.com/en/database/

 - 오라클 DB 공홈 12c 버전 설명자료

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/cncpt/index.html

 - 오라클 성능 고도화 원리와 해법, 조시형 지음

 구글링하면 매우 자세하게 잘 설명한 사이트와 블로그가 많으므로 키워드와 간략한 설명만 적을 것이다.