-
데이터베이스 아키텍처데이터베이스 2021. 5. 20. 21:53
DBMS 마다 데이터베이스에 대한 정의가 조금씩 다르다.
Oracle 의 구조
Oracle 에서는 디스크에 저장된 데이터 집합 (Data File, Redo Log File, Control File 등) 을 데이터베이스라고 부른다.
그리고 SGA 공유 메모리 영역과 이를 엑세스하는 프로세스집합을 합쳐서 인스턴스라고 부른다.
기본적으로 하나의 인스턴스가 하나의 데이터베이스만 엑세스하지만,
RAC(Real Application Cluster)환경에서는 여러 인스턴스가 하나의 데이터베이스를 엑세스할 수 있다.
하나의 인스턴스가 여러 데이터베이스를 엑세스 할 수는 없다.
SQL Server 의 구조
SQL Server 는 하나의 인스턴스 당 최고 3만 2767개의 데이터베이스를 정의해 사용할 수 있다.
기본적으로 master, model, msdb,tempdb 등 시스템 데이터베이스가 만들어지며, 여기 사용자 데이터베이스를 추가로 생성하는 구조이다.
데이터베이스를 하나를 만들때마다 주(Primary/Main) 데이터 파일(.mdf)과 트랜젝션 로그 파일(.ldf)이 하나씩 생긴다.
저장할 데이터가 많으면 보조 데이터 파일(Non-Primary)을 추가할 수 있으며, 확장자는 ndf 이다.
프로세스
SQL Server 는 스레드 기반 아키텍처이므로 프로세스 대신 스레드라는 표현을 써야한다.
Oracle 도 윈도우 버전에서는 스레드를 사용하지만, 프로세스와 일일이 구분하면 복잡하니 특별히 스레드로 언급할 경우가 아니면 모두 프로세스로 통칭한다.
주요 스레드의 역할은 Oracle 프로세스와 크게 다르지 않다.
프로세스는 서버 프로세스와 백그라운드 프로세스 집합으로 나뉜다.
서버 프로세스는 전면에서 사용자로부터 전달받은 각종 명령을 처리하고, 백그라운드 프로세스 뒤에서 할당받은 역할을 수행한다.
가. 서버 프로세스
사용자 프로세스와 통신하며 사용자의 각종 명령을 처리하며, SQL Server 에서는 Worker 스레드가 같은 역할을 담당한다. 좀 더 구체적으로 말하면 SQL 을 파싱하고 필요하면 최적화를 수행한다.
커서를 열어 SQL 을 실행하면서 블록을 읽어 데이터를 정렬해 클라이언트가 요청한 결과 집합을 만들어
네트워크를 통해 전송하는 일련의 작업을 모두 서버 프로세스가 수행한다.
스스로 처리하도록 구현되지 않은 기능, 이를테면 데이터 파일로부터 DB 버퍼 캐시로 블록을 적재하거나
Dirty 블록을 캐시에서 밀어냄으로써 Free 블록을 확보하는 일, Redo 로그 버퍼를 비우는 일 등은
OS 와 I/O 서브 시스템, 백그라운드 프로세스가 대신 처리하도록 시스템 Call 을 통해 요청한다.
클라이언트가 서버 프로세스와 연결하는 방식은 DBMS 마다 다르지만 Oracle 에는 전용 서버 방식과 공유 서버 방식 두 가지가 있다.
1. 전용 서버 방식
처음 연결을 받는 리스너가 서버 프로세스(윈도우환경에서는 스레드)를 생성해주고,
이 서버 프로세스가 단 하나의 사용자 프로세스를 위해 전용 서비스를 제공한다는 점이 특징이다.
만약 SQL 을 수행할 때마다 연결 요청을 반복하면 서버 프로세스의 생성과 해제도 반복하게 되므로 DBMS 에 큰 부담을 주고 성능을 크게 떨어뜨린다. 따라서 전용 서버 방식을 사용하는 OLTP(On-Line Transaction Processing)성 애플리케이션에선 Connection Pooling 기능을 필수적으로 사용해야한다. 예를 들어 50개의 서버 프로세스와 연결된 50개의 사용사 프로세스를 공유해 반복 재사용하는 방식이다.
2. 공유 서버 방식
하나의 서버 프로세스를 여러 사용자 세션이 공유하는 방식이다.
Connection Pooling 기법을 DBMS 내부에 구현해 놓은 것으로 생각하면 쉽다. 즉 미리 여거 개의 서버 프로세스를 띄워놓고 이를 공유해 반복 재사용한다.
공유 서버 방식으로 접속하면 사용자 프로세스는 서버 프로세스와 직접 통신하지 않고 Dispatcher 프로세스를 거친다.
Dispatcher 가 사용자 명령을 SGA (System Global Area) 에 있는 큐에 등록하고 응답 큐를 모니터링 하다가 응답이 오면 사용자 프로세스에 전달해준다.
나. 백그라운드 프로세스
Oracle 설명 SQL Server Syetem Monitor
(SMON)장애가 발생한 시스템을 재기동할 때 인스턴스 복구를 수행하고,
임시 세그먼트와 익스텐트를 모니터링한다.Database cleanup/
shrinking threadProcess Monitor
(PMON)이상이 생긴 프로세스가 사용하던 리소스를 복구한다. Open Data Services(OPS) DataBase Writer
(DBWn)버퍼 캐시에 있는 Dirty 버퍼를 데이터 파일에 기록한다. LazyWriter thread Log Writer
(LGWR)로그 버퍼 엔트리를 Redo 로그 파일에 기록한다. Log Writer thread Archiver
(ARCn)꽉 찬 Redo 로드가 덮어쓰여지기 전에 Archive 로그 디렉터리로 백업한다. N/A CheckPoint(CKPT) 이전에 CheckPoint 가 일어났던 마지막 시점 이루의 데이터베이스 변경 사항을 데이터 파일에 기록하도록 Trigger 하고, 기록이 완료되면 현재 어디까지 기록했는지 컨트롤 파일과 데이터 파일 헤더에 저장한다. Database CheckPoint thread Recoverer(RECO) 분산 트랜젝션 과정에서 발생한 문제를 해결한다. Distributed Transaction Coordinator(DTC)
데이터 저장 구조 ( 데이터 파일, 임시 데이터 파일, 로그 파일 )
Oracle 과 SQL Server 모두 물리적으로는 데이터 파일에 데이터를 저장하고 관리한다.
공간을 할당하고 관리하기 위한 논리적인 구조도 비슷하지만 약간의 차이가 있다.
가. 데이터 파일
1. 블록(=페이지)
대부분 DBMS 에서 I/O 는 블록 단위로 이뤄진다. 데이터를 읽고 쓸 때의 논리적인 단위가 블록이다.
오라클은 2KB, 4KB, 8KB, 16KB, 32KB 의 다양한 크기를 사용할 수 있지만 SQL Server 에서는 8KB 단일 크기를 사용한다.
블록 단위로 I/O 한다는 것은, 하나의 레코드에서 하나의 컬럼만 읽을 때도 레코드가 속한 블록 전체를 읽게 됨을 뜻한다. SQL 성능을 좌우하는 가장 중요한 성능지표는 액세스하는 블록 갯수이며,
옵티마이저의 판단에 가장 큰 영향을 미치는 것도 액세스해야할 블록 개수이다.
예를 들어 옵티마이저가 인덱스를 이용해 테이블을 액세스할지 아니면 Full Table Scan할지를 결정하는데 가장 중요한 판단 기준은 읽어야할 레코드 수가 아니라 읽어야 할 블록 개수이다.
2. 익스텐트
데이터를 읽고 쓰는 단위는 블록이지만, 테이블 스페이스로부터 공간을 할당하는 단위는 익스텐스이다.
테이블이나 인덱스에 데이터를 입력하다가 공간이 부족해지면 해당 오브젝트가 속한 테이블스페이스(물리적으로는 데이터파일) 로부터 추가적인 공간을 할당받는다. 이때 정해진 익스텐트 크기의 연속된 블록을 할당받는다.
예를 들면 블록 크기가 8KB 인 상태에서 64KB 단위로 익스텐트를 할당하고록 정의했다면, 공간이 부족할 때마다 테이블 스페이스로부터 8개의 연속된 블록을 찾아(못찾으면 새로운 익스텐스 추가) 세그먼트에 할당해 준다.
익스텐트 내 블록은 논리적으로 인접하지만, 익스텐트끼리 서로 인접하지는 않는다. 예를 들어 어떤 세그먼트에 익스텐트 2개가 할당됐는데, 데이터 파일 내에서 이 둘이 서로 멀리 떨어져 있을 수 있다.
Oracle 은 다양한 크기의 익스텐트를 사용하지만 SQL Server 는 8개 페이지의 익스텐트만 사용한다. (8KB*8=64KB)
또 Oracle은 한 익스텐트에 속한 모든 블록을 단일 오브젝트가 사용하는데, SQL Server 에서는 2개 이상의 오브젝트가 나눠 사용할 수 있다.
3.세그먼트
SQL Server 에서는 세그먼트라는 용어를 사용하지 않지만, 힙 구조 또는 인덱스 구조의 오브젝트가 여기에 속한다.
세그먼트는 테이블, 인덱스, Undo*처럼 저장공간을 필요로 하는 데이터베이스 오브젝트다.
저장공간을 필요로 한다는 것은 한 개 이상의 익스텐트를 사용함을 뜻한다.
테이블을 생성할 때, 내부적으로는 테이블 세그먼트가 생성된다.
인덱스를 생성할 때, 내부적으로 인덱스 세그먼트가 생성된다.
다른 오브젝트는 세그먼트와 1:1 대응 관계를 갖지만 파티션은 1:M 관계를 갖는다.
즉 파티션 테이블(또는 익덱스)을 만들면, 내부적으로 여러 개의 세그먼트가 만들어진다.
한 세그먼트는 자신이 속한 테이블스페이스 내 여러 데이터 파일에 걸쳐 저장될 수 있다.
즉 세그먼트는 할당된 익스텐트가 여러 데이터 파일에 흩어져 저장되는 것이며, 그래야 디스크 경합을 줄이고 I/O 분산 효과를 얻을 수 있다.
- REDO 는 복구의 역할을 한다. 오라클에서 하는 모든 작업은 REDO 에 기록이 된다. - UNDO 는 롤백, 읽기 읽관성, 복구를 한다. - REDO 는 복구 할 때 사용자가 했던 작업을 그대로 다시 한다. - UNDO 는 복구 할 때 사용자가 했던 작업을 반대로 해 작업을 원상태로 되돌린다. - 기록되는 undo 데이터 insert > insert 된 로우의 rowid update> 변경 전 값 delete > 지워진 데이터 - UNDO 구조적으로 테이블세그먼트와 별반 다르지 않습니다. 테이블 세그먼트와 마찬가지로 익스텐트단위로 확장하고 빠른 읽기/쓰기를 위해 undo 블록들을 버퍼 캐시에 캐싱하며, 데이터 유실을 방지하기 위해 그 변경사항을 redo 로그에 로깅하는 점도 같습니다. 다른점이라면 세그먼트에 저장하는 내용인데 각 트랜잭션 별로 undo 세그먼트를 할당해주고 (두 개이상의 트랜잭션이 하나의 undo 세그먼트를 할당받아 같이 사용할 수 있음) 그 트랜잭션이 발생시킨 테이블과 인덱스에 대한 변경사항을 undo 레코드 단위로 undo 세그먼트 블록에 차곡차곡 기록합니다. (AUM[Automatic Undo Management]이 9i부터 도입되어 현재까지 사용되고 있으며, undo 세그먼트마다 하나의 트랜잭션이 할당되는 것을 목표로 세그먼트 개수를 오라클이 자동 관리합니다. 트랜잭션에 독립적으로 할당해 줄 undo 세그먼트가 없을때 (online으로 전환할 수 있는 offline세그먼트가 없고 새로운 undo세그먼트를 생성할 공간도 부족할 때) 가장 적게 사용되는 undo세그먼트 중 하나를 할당합니다. AUM에서는 다른 undo 세그먼트로부터 free undo space를 가져올 수있으며(dynamic extent transfer), undo 테이블스페이스 내에 있는 모든 undo space를 소진했을때 ORA-01562를 발생시킵니다) - UNDO 목적? 1) transaction rollback 트랜잭션에 의한 변경사항을 커밋하지 않고 롤백할때 undo 데이터를 사용합니다. 2) transaction recovery (instance recovery시 rollback 단계) instance crash 발생 후 redo를 이용해 roll forward단계가 완료되면 최종 커밋되지 않은 변경사항까지 모두 복구합니다. 이때 커밋되지 않은 트랜잭션은 모두 롤백해야 하는데 이때 undo 데이터를 사용합니다 3) read consistency 오라클은 undo를 사용하여 읽기 일관성을 유지합니다.(다른 dbms는 lock을 통해 읽기 일관성을 유지함) 이것은 아래에서 자세하게 다루겠습니다. https://bae9086.tistory.com/244. 테이블스페이스
테이블스페이스는 세그먼트를 담는 컨테이너로, 여러 데이터 파일로 구성된다. SQL Server 이 파일 그룹이 Oracle 테이블스페이스에 해당한다.
데이터는 물리적으로 데이터 파일에 저장되지만, 사용자가 데이터 파일을 직접 선택하진 않는다. 사용자는 세그먼트를 위한 테이블스페이스를 지정할 뿐, 실제 값을 저장할 데이터 파일을 선택하고 익스텐트를 할당하는 것을 DBMS 의 몫이다. 각 세그먼트는 정확히 한 테이블스페이스에만 속하지만, 한 테이블스페이스에는 여러 세그먼트가 존재할 수 있다.
(한 테이블스페이스가 여러 테이터 파일로 구성되어 있기 때문)
특정 세그먼트에 할당된 모든 익스텐트는 해당 세스먼트와 관련된 테이블스페이스 내에서만 찾아진다.
나. 임시 데이터 파일
임시 데이터 파일은 대량의 정렬이나 해시 작업을 수행하다가 메모리 공간이 부족해지면 중간 결과 집합을 저장하는 용도이다.
임시 데이터 파일에 저장되는 오브젝트는 말 그대로 임시로 저장했다가 자동으로 삭제된다. Redo 정보를 생성하지 않기 때문에 나중에 파일에 문제가 생겼을 때 복구되지 않는다. 따라서 백업할 필요도 없다.
Oracle 에서는 임시 테이블스페이스를 여러 개 생성해주고, 사용자마다 별도의 임시 테이블스페이스를 지정해 줄 수 있다. SQL Server 는 단 하나의 tempdb 데이터베이스를 사용한다. tempdb 는 전역 리소스로 모든 사용자의 임시 데이터를 저장한다.
다. 로그파일
DB 버퍼 캐시에 가해지는 모든 변경사항을 기록하는 파일을 Oracle 은 'Redo 로그' 라고 부르며, SQL Server 에서는 '트랜젝션 로그'라고 부른다.
변경된 메모리 버퍼 블록을 디스크 상의 데이터 블록에 기록하는 작업은 Random I/O 방식으로 이뤄지기 때문에 느리다. 반면 로그 기록은 Append 방식으로 이뤄지기 때문에 상대적으로 매우 빠르다.
따라서 대부분 DBMS 가 우선 로그 파일에 빠르게 기록하고 버퍼블록과 데이터 파일 간 동기화는 적절한 수단(CheckPoint,DBWR) 을 이용해 나중에 Batch 방식으로 일괄처리한다.
사용자 갱신 내용이 메모리 상의 버퍼 블록에만 기록하고 디스크에 아직 기록되지 않은 상태에서 Redo 로그를 믿고 빠르게 커밋을 완료한다는 의미로 Fast Commit 매커니즘이라고 부른다. 인스턴스 장애가 발생해도 로그 기록을 통해 언제든 복구 가능하다.
- Online Redo 로그
정전 등 인스턴스의 비정상 종료에 대비해 Oracle 이 사용하는 로그이다.
최소 두 개 이상의 파일로 구성된다. 사용중인 파일이 꽉차면 다음 파일로 스위칭하며, 모든 파일이 다 차면 첫번째 파일을 다시 사용하는 라운드 로빈 방식을 사용한다.
- Archive(=OffLine) 로그
Oracle 에서 Online Redo 로그가 재사용되기 전에 다른위치로 백업해 둔 파일을 말한다.
디스크가 깨지는 등 물리적인 저장 매체에 문제가 발생했을 때 데이터베이스 복구를 위해 사용된다.
SQL Server 에는 이와 대응되는 개념이 없다.
- 트랜젝션 로그
Oracle 의 Online Redo 로그와 대응하는 SQL Server 가 사용하는 로그파일이다.
주 데이터 파일마다, 즉 데이터베이스마다 트랜젝션 로그파일이 생성된다.
트랜젝션 로그파일은 내부적으로 '가상 로그 파일' 이라고 불리는 더 작은 단위의 세그먼트로 나뉘며, 이 가상 파일의 개수가 너무 많아지지 않도록(즉 조각화가 발생하지 않도록) 옵션을 지정하는 것이 좋다.
메모리 구조
시스템 공유 메모리 영역
말그대로 여러 프로세스(또는 스레드)가 동시에 엑세스할 수 있는 메모리 영역으로서, Oracle 에선 'SGA' , SQL Server 에서는 Memory Pool 이라고 부른다. 공유 메모리를 구성하는 캐시 영역으로는 DB 버퍼 캐시, 공유 풀, 로그 버퍼가 있다.
공유 메모리 영역은 그 외 Large Pool , JAVA Pool 등을 포함하고, 시스템 구조와 제어 구조를 캐싱하는 영역도 포함한다.
여러 프로세스에서 공유됨으로 내부적으로 래치(Latch),버퍼 Lock, 라이브러리 캐시 Lock/Pin 같은 엑세스 직렬화 매커니즘이 사용된다.
시스템 공유 메모리 영역의 구성요소
가. DB 버퍼 캐시
데이터 파일로부터 읽어 들인 데이터 블록을 담는 캐시 영역이다. 인스턴스에 접속한 모든 사용자 프로세스는 서버 프로세스를 통해 DB 버퍼 캐시의 버퍼 블록을 동시에 (내부적으로 버퍼 Lock 을 통해 직렬화) 액세스할 수 있다.
일부 Direct Path Read 매커니즘이 작동하는 경우를 제외하면, 모든 블록 읽기는 버퍼 캐시를 통해 이뤄진다.
즉 읽고자 하는 블록을 먼저 버퍼 캐시에서 찾아보고 없을 때 디스크에서 읽는다. 디스크에서 읽을 때도 먼저 버퍼 캐시에 적재 후 읽는다.
데이터 변경도 버퍼 캐시에 적재된 블록을 통해 이뤄지며, 변경된 (Dirty 버퍼 블록)을 주기적으로 데이터 파일에 기록하는 작업은 DBWR 프로세스의 몫이다.
디스크 I/O 는 물리적으로 엑세스 arm 이 움직이면서 헤드를 통해 이뤄지는 반면, 메모리 I/O 는 전기적 신호에 불과해 디스크 I/O 보다 비교할 수 없게 빠르다., 디스크에서 읽은 데이터 블록을 메모리 상에서 보관해두는 기능이 모든 데이터베이스 시스템에 필수적인 이유이다.
버퍼 블록의 상태
모든 버퍼 블록은 아래 세가지 상태 중 하나의 상태에 놓인다.
- Free 버퍼 : 인스턴스 기동 후 아직 데이터가 읽히지 않아 비어있는 상태 혹은 데이터가 담겼지만 데이터 파일과 서로 동기화돼 있는 상태여서 언제든지 덮어 써도 무방한 버퍼 블록. 데이터 파일로부터 새로운 데이터 블록을 로딩하려면 먼저 free 버퍼를 확보해야한다. Free 에서 변경이 발생하면 Dirty 로 상태가 변한다.
- Dirty 버퍼 : 버퍼에 캐시된 이후 변경이 발생했지만 아직 디스크에 기록되비 않아 데이터 파일 블록과 동기화가 필요한 버퍼 블록을 말한다. 재사용되려면 디스크에 먼저 기록돼야한다. 기록되는 순간 Free 로 상태가 바뀐다.
- Pinned 버퍼 : 읽기 혹은 쓰기 작업이 현재 진행 중인 버퍼 블록
나. 공유 풀
- 딕셔너리 캐시
딕셔너리는 테이블, 인덱스 같은 오브젝트는 물론 테이블스페이스, 데이터 파일, 세그먼트, 익스텐트, 사용자, 제약에 관한 메타 정보를 저장하는 곳이다. 그리고 딕셔너리 캐시는 말그대로 딕셔너리 정보를 캐싱하는 메모리 영역ㅇ다.
- 라이브러리 캐시
사용자가 수행한 SQL 문과 실행계획, 저장 프로시저를 저장해 두는 캐시영역이다.
쿼리 구문을 분석해 문법 오류 및 실행 권한 체크, 최적화 과정을 거쳐 실행계획 생성, SQL 실행 엔진이 이해할 수 있는 형태로 포매팅하는 전 과정을 하드 파싱이라고 한다.
특히 최적화는 하트 캐싱을 무겁게 만드는 결정적 요인인데, 같은 SQL 을 처리하기 위해 이런 과정을 반복 수행하는 것은 비효율적이기 때문에 이를 최소화 하기 위래 캐시 공간을 따로 둔 것이 라이브러리 캐시 영역이다.
캐싱된 SQL 과 그 실행계획의 재활용은 SQL 수행성능을 높이고 DBMS 의 부하를 최소화하는 핵심 원리 중 한가지다.
다. 로그 버퍼
DB 버퍼 캐시에 가해지는 모든 변경사항은 로그 파일에 기록되는데, 로그 엔트리도 파일에 바로 기록되는 것이 아니라 로그 버퍼에 먼저 기록하고 일정량씩 한번에 디스크에 기록한다.
Redo 로그 버퍼에 먼저 기록하고 LGWR 프로세스가 주기적으로 Redo 로그 파일에 기록한다.
프로세스 전용 메모리 영역
Oracle 은 프로세스 기반 아키텍처이므로 서버 프로세스가 자신만의 전용 메모리 영역을 가질 수 있다.
이를 Process Global Area (PGA) 라고 하며, 데이터를 정렬하고 세션과 커서에 관한 상태 정보를 저장하는 용도로 사용한다.
스레드 기반 아키텍처를 사용하는 SQL Server 는 프로세스 전용 메모리 영역이 없다.
스레드는 전용 메모리 영역을 가질 수 없고, 부모 프로세스의 메모리 영역을 사용한다.
Window 버전 Oracle 도 스레드를 사용하지만 프로세스 기반의 유닉스 버전과 같은 인터페이스를 제공하고 구조에 대한 개념과 설명도 구별하지 않는다.
PGA (Process, Program,Private Global Area)
각 Oracle 서버 프로세스는 자신만의 PGA메모리 영역을 할당받고 이를 프로세스에 종속적인 고유 데이터를 저장하는 용도로 사용한다.
래치 매커니즘이 필요 없어 똑같은 개수의 블록을 읽더라도 SGA 버퍼 캐시에서 읽는 것보다 훨씬 빠르다.
- User Global Area
전용 서버(Dedicated Server) 방식으로 연결할 때는 프로세스와 세션이 1:1 이지만 공유서버에는 1:M 관계를 갖는다.
세션이 프로세스 개수보다 많아질 수 있는 구조로, 하나의 프로세스가 여러 세션을 위해 일한다.
따라서 각 세션을 위한 독립적인 메모리 공간이 필요한데, 이를 UGA 라고 한다.
전용 서버 방식일 때는 PGA 에 UGA 가 할당되고 , 공유 서버 방식에서는 SGA 에 할당된다.
- CGA (Call Global Area)
Oracle 은 하나의 데이터베이스 Call 을 넘어 다음 Call 까지 계속 참조되어야 하는 정보는 UGA 에 담고,
Call 이 진행되는 동안에만 필요한 데이터는 CGA 에 담는다.
CGA 는 Parser Call, Execute Call ,Fetch Call 마다 매번 할당받는다.
Call 이 진행되는 동안 Recursive Call 이 발생하면 그 안에서도 Parse, Execute, Fetch 단계별로 CGA 가 추가로 할당된다.
CGA 에 할당된 공간은 하나의 Call 이 끝나자마자 해제돼 PGA 로 반환된다.
- Sort Area
데이터 정렬을 위해 사용되는 Sort Area는 소트 오퍼레이션이 진행되는 동안 공간이 부족해질 때마다 Chunk 단위로 조금씩 할당된다.
PGA 내에서 Sort Area가 할당되는 위치는 SQL문 종류와 소트 수행 단계에 따라 다르다.
DML 문장은 하나의 Execute Call 내에서 모든 데이터 처리를 완료하므로 Sort Area가 CGA 에 할당된다.
SELECT 문은 수행 중간 단계에 필요한 Sort Area 는 CGA 에,
최종 결과 집합을 출력하기 직전에 필요한 Sort Area는 UGA 에 할당된다.
SQL Server 는 프로세스 전용 메모리가 없어 데이터 정렬을 Memory Pool 내의 버퍼 캐시에서 수행하며,
세션 관련 정보는 Memory Pool 내의 Connection Context 영역에 저장한다.
출처
SQL 전문가 가이드 - 한국데이터산업진흥원
반응형