SGA vs PGA (in Oracle)

현재 DB 스터디의 일환으로 '친절한 SQL 튜닝'을 한번 더 읽고 있다. 이번 파트는 소트 머지 조인 + 해시 조인 인데, 개인적으로 해당 서적을 이미 1회독한 상황이라 두 조인이 대략적으로 어떻게 작동하고, 어떤 상황에서 활용되는지는 이해하고 있다. 

다만 1회독 시 잘 몰라서 그냥 넘어갔던 오라클의 PGA와 SGA의 개념이 있는데, 이번 기회에 이를 공부하고 넘어가면 좋겠다 싶어 공부한 내용들을 기록해두기 위해 이 글을 작성한다. 이 글에서는 책에서 간단하게 다뤄진 데이터 조회 시 SGA와 PGA 접근의 속도 차이에 중점을 두고 다뤄보려한다.

 

각 메모리 공간에 대한 소개

SGA

SGA란 System Global Area의 약자로, DB 내 하나만 존재하면서 모든 세션이 공유하는 메모리 공간이다.

SGA란 오라클에서 이를 지칭하는 방식이고 Mysql은 Global Memory, PG에서는 Shared Memory라고 지칭한다. 

해당 메모리 내에는 버퍼 캐시, 리두 버퍼, 공유 풀, 자바 풀 등이 위치한다.

각 메모리 영역에 대한 설명을 간략하게 하면 아래와 같다.

• 공유 풀(Shared Pool): 주로 쿼리 구문 분석(Parsing)을 위해 활용되는 공간. 동일한 쿼리에 대해서는 미리 Hard Parsing을 수행한 내용을 해당 공간에 저장해두고, 이후 동일한 쿼리에 대해서는 이 결과를 활용하는 Soft Parsing 방식으로 유도함.
• 버퍼 캐시(Buffer Cache): 디스크에서 읽어온 인덱스 블록과 데이터 블록이 캐시되는 공간. DB는 데이터를 찾기 위해 디스크에 접근하기 전에, 해당 공간에서 찾는 데이터가 있는지 확인하는 절차를 가짐.
• 리두 버퍼(Redo Buffer): DB에서 발생한 변경 이력들이 기록되는 리두 로그에 대해 아직 디스크에 반영되지 않은 리두 로그들이 저장되어 있는 공간.
• 자바 풀(Java Pool): Oracle에서는 Java 구문분석도 수행가능한데, 이를 위한 공간이다. 다만 해당 기능을 활용하려면 추가적인 설정이 필요.

해당 글의 최종적인 목적은 데이터 조회 시 SGA와 PGA의 속도 차이이기 때문에, 이를 위해 사용되는 버퍼 캐시 외의 영역에 대해서는 다루지 않겠다.

PGA

PGA란 Process Global Area의 약자로, DB 내 세션 별로 하나씩 존재하는 메모리 공간이다.

PGA란 명칭 역시 오라클에서 사용하는 방식이고 Mysql은 Local Memory, PG는 Backend Memory 등으로 불린다.

해당 메모리는 SQL Work Area, Session Memory, Private SQL Area로 구성되고, 이 중 이번 글에서 다룰 SQL Work Area는 아래 영역들로 구성된다.

Sort Area: 정렬을 위해 사용되는 영역.

Hash Area: 해시 조인에 필요한 해시 테이블 생성 및 활용을 위해 사용되는 영역.

Bitmap Merge Area: 비트맵 조인이나 비트맵 생성 등에 대응하기 위한 영역.

이를 도식화한 그림은 아래와 같다.

출처: https://databaseinternalmechanism.com/oracle-database-internals/oracle-memory-architecture-sga-pga/

 

위에서 설명한 SGA와 PGA를 종합하면 아래의 그림으로 표현할 수 있다.

출처: https://docs.oracle.com/cd/B10500_01/server.920/a96524/c08memor.htm

 

영역 별 접근 속도 차이의 원인

해당 글에서 접근 속도를 비교하려고 하는 두 대상은 각각 SGA의 버퍼 캐시와 PGA의 SQL Work Area이다. 우선 두 영역의 비교를 하는 배경에 대해 설명하자면, 이는 NL 조인과의 비교를 위해서이다. (NL 조인 vs 소트 머지, 해시 조인)

책에서는 아래와 같은 취지로 설명하고 있다.

NL 조인은 조인 시 매번 버퍼 캐시에서 데이터를 가져오는데 반해, 다른 조인들의 경우 사전 작업을 통해 PGA의 Sort Area 혹은 Hash Area에 데이터를 넣어두고 이를 이용하여 조인을 수행하기 때문에 특정 경우에 따라서는 후자의 방식이 더 빠르다.

물론 위 설명이 특정 조건에서 NL 조인말고 다른 조인을 선택해야 하는 이유의 전부는 아니지만, 모든 쿼리가 버퍼 캐시를 경유하는 만큼 이에 대한 이해도를 높이는 것도 도움이 되리라 생각한다.

 

다시 주제로 돌아가서, 두 영역 모두 메모리에 올라가있는 영역인데 어째서 접근 속도의 차이가 있는 것일까?

이는 결국 버퍼 캐시가 모든 세션이 공유하는 공유자원이라는 것에 기인한다.

공유자원이기 때문에 어떤 식으로든 동시성 문제를 제어하는 것은 필수적이다. 오라클은 이를 위해 크게 2가지 안전장치를 통해 이를 제어한다. 

오라클에서 특정 버퍼 캐시에 접근하는 과정은 아래와 같다.

버퍼 캐시 접근 과정

첫번째는 해시 체인 래치 획득 단계이다. 

오라클은 블록 단위로 디스크 IO가 발생하고, 이 단위는 메모리 레벨인 버퍼 캐시에서도 동일하게 활용된다. 따라서 특정 레코드를 찾아가려면 어떤 데이터 파일의 어떤 블록에 해당 레코드가 존재하는지 알 필요가 있다. 이를 위해 오라클은 이 두 정보를 합친 DBA(Data Block Address)라는 개념을 관리하고 레코드를 찾아가기 위한 이정표로 이를 제공한다. 특정 레코드의 DBA를 획득했다면 이를 토대로 버퍼 캐시 내에서 해당 블록이 캐싱되어 있는지 확인하는 절차가 필요하다. 이를 위해 DBA를 내부적으로 해시 처리하고 해시 체인 구조의 키 값으로 활용된다. 해시 체인이란 같은 해시 값을 갖는 버퍼 블록에 접근하기 위한 정보들을 하나의 체인 형태로 연결해 둔 자료 구조이다. 앞서 언급한 해시 키 값으로 해당 체인에 접근하게 된다. 이 때 해시 체인 래치를 획득하게 된다. 해시 체인 래치 획득은 읽기 전용(Shared) 레벨과 쓰기 전용(Exclusive) 레벨이 있는데 읽기 전용일 때는 여러 세션이 래치를 공유할 수 있다.

두번째는 버퍼 락 획득 단계이다.

해시 체인 래치를 획득한 이후에는 체인에 찾고자 하는 버퍼가 존재하는지 확인한다. 만약 버퍼가 존재한다면 해시 체인 래치는 해제하고 곧바로 버퍼 락을 획득하게 된다. 이 때도 읽기 전용(Shared) 레벨과 쓰기 전용(Exclusive) 레벨이 나뉜다. 만약 해시 체인에 버퍼가 존재하지 않는다면, 캐시 버퍼 LRU 체인을 획득하고 디스크 IO를 통해 원하는 버퍼를 적재하고 버퍼 락을 획득한다. (캐시 버퍼 LRU 체인에 대해서는 당장 다루지는 않겠다.)

버퍼 락까지 획득했다면, 이제 해당 버퍼에서 데이터를 읽고 쓸 수 있게 된다.

 

결론

버퍼 캐시에 접근하는 것은 메모리 레벨이라서 굉장히 빠를 것으로 생각하지만 위처럼 꽤나 복잡한 과정을 거치는 일이다. 특히 해시 체인 래치와 버퍼 락을 획득하는 과정에서 경합이 발생할 경우엔 앞서 걸린 락이 해제될 때까지 대기해야하기 때문에 더더욱 오래 걸리는 작업이 된다. 

그렇다면 PGA의 SQL Work Area는 어떨까? 해당 구역은 특정 세션이 단독으로 점유하는 공간이다. 그렇기 때문에 동시성 문제를 해결하기 위한 안전 장치들이 불필요하고, 그렇기 때문에 포인터를 통한 일반적인 메모리 접근이 가능해진다.

이로 인해 SGA의 버퍼 캐시에 접근하는 상황보다는 PGA의 SQL Work Area에 접근하는 상황이 성능면에서 더 뛰어나다고 할 수 있고, 이는 특정 상황에서 NL 조인보다 소트 머지 조인이나 해시 조인이 더 나은 성능을 보이는 이유 중 하나가 된다.

 

참고

'친절한 SQL 튜닝 - 조시형 저'

Latch: cache buffers chains