혦's STACK
[SQLp]과목 3 - 1 데이터베이스 아키텍처 본문
SQLp - 국가공인 SQL 전문가
INDEX
3과목은 튜닝에 대한 이해와 실습 병행이 필요할 것 같아 주제별로 정리를 할 계획입니다.
과목 3 - SQL 고급 활용 및 튜닝
1 . 아키텍처 기반 튜닝 원리
데이터베이스 성능 튜닝의 3대 핵심 요소로서 SQL 파싱 부하 해소, 데이터베이스 call 최소화, I/O 효율화를 뽑을 수 있다. 이번 포스팅에서는 성능튜닝의 핵심 요소들을 이해하기 위한 기본 지식과 요소들을 소개할 것 입니다.
아키텍처 기본
Oracle 아키텍처
- Oracle 에서는 디스크에 저장된 데이터 집합(Datafile, Redo Log File, Control file 등)을 데이터베이스라고 한다.
- SGA(System Global Area) 공유 메모리 영역과 이를 액세스하는 프로세스 집합을 인스턴스라고 한다.
- 기본적으로 하나의 인스턴스가 하나의 데이터베이스를 액세스하지만, RAC(Real Application Cluster) 환경에서는 여러 인스턴스가 하나의 데이터베이스를 액세스할 수 있다. 그러나 하나의 인스턴스가 여러 데이터베이스를 액세스 할 수는 없다.
sql server 아키텍처
- 하나의 인스턴스 당 최고 32,767 개의 데이터베이스 정의 가능하다.
- 기본적으로 시스템 데이터베이스(master, model, msdb, tempdb)가 생성되며, 사용자 데이터베이스를 추가하는 구조이다.
- 데이터베이스를 만들 때마다 주 데이터파일(확장자 : mdf)과 트랜잭션 로그 파일(확장자 : ldf)이 하나씩 생기며 저장할 데이터가 많으면 보조 데이터 파일(확장자 : ndf)을 추가할 수 있다.
프로세스
SQL Server 는 쓰레드 기반 아키텍처이며 Windows 버전의 Oracle 도 쓰레드를 사용하지만, 본 단원에서는 모두 '프로세스'로 통칭하고자 한다.
프로세스는 서버 프로세스와 백그라운드 프로세스 집합으로 나뉜다. 서버 프로세스는 사용자가 던지는 각종 명령을 처리하고, 백그라운드 프로세스는 뒤에서 주어진 역할을 수행한다.
서버 프로세스
사용자 프로세스와 통신하면서 각종 명령을 처리하며 SQL Server 에서는 Worker 쓰레드가 같은 역할을 담당한다. (SQL 파싱과 최적화 수행, 커서를 열어 SQL 을 실행하고 블록 읽기, 데이터 정렬 및 결과 집합 전송)
시스템 Call 을 통해 데이터 파일로부터 DB 버퍼 캐시로 블록을 적재하거나, Dirty 블록을 캐시에서 밀어내서 Free 블록을 확보하고, Redo 로그 버퍼를 비우라고 OS, I/O 서브 시스템, 백그라운드 프로세스에 요청합니다.
클라이언트가 서버 프로세스와 연결하는 방식에 따라 전용서버방식(Dedicated Server), 공유서버방식(Shared Server)으로 분류 할 수 있다.
전용서버 방식
1) 리스너(Client =>Listener)에 연결 요청
2) 서버(Listenr => server)에 프로세스 생성 및 연결요청 상속
3) 클라이언트(Server => Client)에게 RESEND 패킷 전송
4) 서버(Client => Server)에 연결 후 작업 요청
5) 처리 후 클라이언트(Server => Client)에게 결과 전송
연결 요청을 받은 리스너는 서버 프로세스를 생성해 주고, 서버 프로세스가 하나의 사용자 프로세스를 위해 전용(Dedicated) 서비스를 제공한다. 만약, 연결 요청을 SQL 수행시마다 반복하면 성능을 크게 떨어트린다. 그러므로 전용 서버 방식을 사용하는 OLTP 성 애플리케이션에선 Connection Pooling 기법을 필수로 사용해야만 한다.
공유서버 방식
1) 리스너(Client =>Listener)에 연결 요청
2) 이용 가능한 Dispatcher 포트 번호를 클라이언트에 전송(Listener => Client)
3) 디스패쳐에 연결 후 작업 요청(Client => Dispatcher)
4) SGA-Request Queue에 요청 등록 (Dispatcher => Request Queue)
5) 서버(Request Queue => Server)가 요청 접수
6) Request Queue에 결과 등록 (Server => Request Queue)
7) Dispatcher 가 결과 수령(Request Queue => Dispatcher)
8) Client에 결과 전송 (Dispatcher => Client)
하나의 서버 프로세스를 여러 사용제 세션이 공유하는 방식으로, Connection Pooling 기법을 DBMS 내부에 구현해 놓은 것이다. 즉, 여러 개의 서버 프로세스를 공유해서 반복 재사용한다. 공유 서버 방식은 사용자 프로세스가 Dispatcher 프로세스를 거쳐 서버 프로세스와 통신한다. 사용자 명령이 디스패쳐에 전달 되면 이를 요청큐에 등록하고, 사용 가능한 서버 프로세스가 요총 큐에 있는 사용자 명령을 처리한다. 이 결과를 응답 큐에 등록하면 응답 큐를 모니터링하는 디스패쳐가 이를 발견하고, 사용자 프로세스에 전달해 준다.
백그라운드 프로세스
시스템을 재기동 할 때 인스턴스를 복구하고 임시 세그먼트와 익스텐트를 모니터링
- Oracle : System Montor (SMON)
- SQL Server : Database cleanup / shrinking thread
이상이 생긴 프로세스가 사용하던 리소스를 복구
- Oracle : Process Monitor (PMON)
- SQL Server : Open Data Services (OPS)
버퍼 캐시에 있는 Dirty 버퍼를 데이터 파일에 기록
- Oracle : Database Writers (DBWn)
- SQL Server : Lazywriter thread
로그 버퍼 엔트리를 Redo 로그 파일에 기록
- Oracle : Log writer (LGWR)
- SQL Server : Log writer thread
Redo 로그가 덮어 쓰여지기 전에 Archive 로그 디렉토리로 백업
- Oracle : Archiver (ARCn)
- SQL Server : N/A
이전 Checkpoint 바로 직후의 데이터 베이스 변경 사항을 데이터 파일에 기록하도록 트리거링하고 기록이 완료되면 현재 위치를 컨드롤 파일과 데이터 파일 헤더에 저장한다. 데이터 변경 전에 로그부터 남기는 매커니즘 (Write Ahead Logging 방식)을 사용하는 DBMS 는 Redo 로그에 기록해 둔 버퍼 블록에 대한 변경 사항 중 어디까지를 데이터 파일에 기록했는지 체크 포인트 정보를 관리해야 한다. 이는 버퍼캐시와 데이터 파일이 동기화된 시점을 가리킨다. 장애가 발생할 때 마지막 체크포인트 이후 로그 데이터만 디스크에 기록함으로써 인스턴스를 복구할 수 있도록 하는 용도로 사용된다. 이 정보를 갱신하는 주기가 길수록 장애 발생 시 인스턴스 복구 시간도 길어진다.
즉, 마지막 체크 포인트의 정보와 Redo 로그에 대한 정보를 데이터 파일에 저장함으로써 장애시 인스턴스를 복구하는 데 이용한다.
- Oracle : Checkpoint (CKPT)
- SQL Server :Database Checkpoint thread
분산 트랜잭션 과정에 발생한 문제 해결
- Oracle : Recoverer (RECO)
- SQL Server : Distributed Transaction Coordinator (DTC)
파일 구조
물리적 : 데이터 파일
그러나 논리적인 공간 할당과 관리 구조는 조금 다르다.
Oracle : Tablespace -> Segment -> extent(다양) -> Blocks (2KB, 4KB, 8KB, 16KB)
SQL Server : File Group -> Heap/Index -> extent(8개의 페이지, 64KB) -> Pages (8KB 단일 크기)
데이터 파일
- 블록 (= 페이지)
대부분의 DBMS 에서 I/O는 블록(데이터를 읽고 쓰는 논리적 단위) 단위로 이루어 진다. 이는 즉 하나의 레코드에서 하나의 칼럼만을 읽을 때도 레코드의 블록 전체를 읽는다는 것을 의미한다. 블록 갯수는 SQL의 성능을 좌우하고 옵티마이저의 판단에 가장 큰 영향을 준다. 즉, 블록의 갯수는 성능 지표로써 옵티마이저의 판단 기준이 된다.
익스텐트 (Extent)
테이블 스페이스로부터 공간을 할당하는 단위이다. 공간이 부족해지면 정해진 익스텐트 크기의 연속된 블록을 할당 받는다. 익스텐트 내 블록은 연속적이지만 익스텐트 끼리는 연속적이지 않다.
Oracle : 익스텐트가 속한 모든 블록을 단일 오브젝트가 사용
SQL Server : 균일 익스텐트 ( 64KB 이상의 공간을 필요로 하는 테이블과 인덱스를 위해 사용되며, 8개 페이지 단위로 할당된 익스텐트를 단일 오브젝트가 모두 사용한다. ) / 혼합 익스텐트 ( 한 익스텐트를 여러 오브젝트가 나눠서 사용하는 형태로, 모든 테이블이 처음에는 혼합 익스텐트로 시작하지만 64KB가 넘으면 2번째 부터는 균일 익스텐트를 사용한다. )
세그먼트
SQL Server 의 힙 구조 혹은 인덱스 구조의 오브젝트가 여기에 속한다. 테이블, 인덱스, Undo 처럼 저장 공간을 필요로 하는 데이터베이스 오브젝트이다. 저장 공간을 필요로 한다는 것은 한 개 이상의 익스텐트를 사용하는 것을 말한다.
테이블 생성시 : 테이블 세그먼트 생성
인덱스 생성시 : 인덱스 세그먼트 생성
다른 오브젝트는 세그먼트와 1:1 대응관계를 갖지만, 파티션은 1:M관계를 갖는다. 파티션 테이블 혹은 파티션 인덱스가 생성되면 내부적으로는 여러 개의 세그먼트가 생성된다.
한 세그먼트는 자신이 속한 테이블 스페이스 내 여러 데이터 파일에 걸쳐 저장될 수 있다. 즉 , 세그먼트에 할당된 익스텐트가 여러 데이터파일에 흩어져 저장되며 그래야 디스크 경합을 줄이고 I/O분산 효과를 얻을 수 있다.
테이블 스페이스
세그먼트를 담는 컨테이너 로서, 여러 데이터 파일로 구성된다. SQL Server 의 파일그룹과 유사하다.
데이터는 물리적으로 데이터 파일에 저장되는데 사용자가 직접 선택하진 않는다. 사용자는 테이블 스페이스를 지정할 뿐 실제로 데이터 파일을 선택하고 익스텐트를 할당하는 것은 DBMS의 몫이다.
각 세그먼트는 정확히 한 테이블 스페이스에만 속하지만, 한 테이블 스페이스에는 여러 세그먼트가 존재할 수 있다. 특정 세그먼트에 할당된 모든 익스텐트는 해당 세그먼트와 관련된 테이블 스페이스 내에서만 찾아진다.
한 세그먼트가 여러 테이블 스페이스에 걸쳐 저장될 수 없다. 그러나 한 세그먼트가 여러 데이터 파일에 저장될 수는 있다. 한 테이블 스페이스가 여러 데이터 파일로 구성되기 때문에...
임시 데이터 파일
대량의 정렬이나 해시 작업을 수행하다가 메모리 공간이 부족하면 중간 결과 집합을 임시 데이터 파일에 저장한다. 이때의 오브젝트는 임시로 저장했다가 자동으로 삭제하며, Redo 정보를 생성하지 않기 때문에 복구되지 않는다. (백업 필요 ㄴㄴ)
Oracle : 임시 테이블 스페이스를 생성해 두고, 사용자마다 별도의 임시 테이블 스페이스를 지정할 수 있다.
xxxxxxxxxxcreate temporary tablespace a_temptempfile '경로' size 2000m;alter user scott temporary tablespace a_temp;
SQL Server : 단 하나의 tempdb 데이터베이스를 사용한다. tempdb는 전역 리소스로서 시스템에 연결 된 모든 사용자의 임시 데이터를 여기에 저장한다.
로그 파일
DB 버퍼 캐시에 가해지는 모든 변경사항을 기록하는 파일로 오라클에서는 Redo 로그 이며 SQL Server 에서는 트랜잭션 로그라고 부른다. 변경된 메모리 버퍼 블록을 디스크 상의 데이터 블록에 기록하는 작업은 Random I/O방식으로 이루어 지기 때문에 느리다. 반면 로그 기록은 Append 방식으로 이루어지기 때문에 빠르다. 따라서 대부분의 DBMS 는 변경 사항을 로그 파일에 Append 방시으로 빠르게 기록한 후에 버퍼 블록과 데이터 파일간 동기화(DBWR, Checkpoint)를 통해 일괄 처리(Batch)한다.
Fast Commit 매커니즘 : 사용자의 갱신 내용이 디스크에 기록되지 않았더라도 Redo 로그를 믿고 빠르게 커밋을 완료 / 인스턴스에 장애가 발생해도 로그 파일을 통해 언제든 복구 가능
Online Redo 로그(Oracle )
트랜잭션 데이터의 유실에 대비하기 위해 사용
캐시복구 : 마지막 체크포인트 이후부터 사고 발생 직전까지 수행되었던 트랜잭션들을 Redo 로그를 이용해 재현
최소 두개 이상의 파일로 구성된다. 현재 사용 중인 파일이 꽉 차면 다음 파일로 '로그 스위칭 (log switching)'이 발생하며, 계속 로그를 써나가다 모든 파일이 다 차면 다시 처음 파일을 재사용하는 라운드 '로빈 방식(round robin) ' 을 사용한다.
트랜잭션 로그(SQL Server )
Online Redo 로그 파일과 대응
데이터베이스 (주 데이터 파일)마다 트랜잭션 로그 파일이 하나씩 생기며, 확장자는 ldf이다.
트랜잭션 로그 파일은 내부적으로 '가상 로그 파일'이라 불리는 작은 단위의 세그먼트로 나뉘며, 가상 로그 파일이 너무 많아지지 않도록(조각화가 발생하지 않도록) 옵션을 지정하는 것이 좋다. 애초에 넉넉한 크기로 만들거나 증가하는 단위를 크게 지정하여 자동 증가의 빈도를 줄인다.
Archived (=offline) Redo 로그 (Oracle)
Online Redo 로그가 재사용되기 전에 다른 위치로 백업해 둔 파일
SQL Server 에는 이에 대응되는 개념이 없다.
메모리 구조
메모리 구조는 시스템 공유 메모리 영역과 프로세스 전용 메모리 영역으로 구분된다.
시스템 공유 메모리영역
여러 프로세스가 동시에 액세스할 수 있는 메모리 영역으로 Oracle 에서는 'System Global Area (SGA)', SQL Server 에서는 'Memory Pool'이라고 부른다. 공유 메모리를 구성하는 캐시 영역은 매우 다양하지만, 모든 DBMS 가 공통적으로 사용하는 캐시 영역은 DB 버퍼 캐시, 공유 풀, 로그 버퍼가 있다. 공유 메모리 영역은 그 외에 Large Pool, Java Pool 등을 포함하고 시스템 구조와 제어구조를 캐싱하는 영역도 포함한다.
시스템 공유 메모리 영역은 여러 프로세스에 공유되기 때문에 내부적으로 래치, 버퍼 Lock, 라이브러리 캐시 Lock/Pin 같은 액세스 직렬화 메커니즘이 사용된다.
구성요소로는 DB 버퍼 캐시, 공유 풀, 로그 버퍼가 있다.
프로세스 전용 메모리영역
Oracle은 프로세스 기반 아키텍처로 서버 프로세스가 자신만의 전용 메모리 영역을 가질 수 있는데, 이를 'Process Global Area (PGA)'라고 한다. 데이터를 정렬하고 세션과 커서에 대한 상태 정보를 저장하는 용도로 쓰인다. SQL Server 는 쓰레드 기반 아키텍쳐를 사용하기 때문에 프로세스 전용 메모리 영역을 사용하지 않는다. 쓰레드는 전용 메모리 영역을 가질 수 없고, 부모 프로세스의 메모리 영역을 사용하기 때문이다. Windows 버전 Oracle 도 쓰레드를 사용하지만, 프로세스 기반의 인터페이스를 제공하며 구조에 대한 개념과 설명도 구별하지 않는다.
DB 버퍼 캐시
데이커 파일로부터 읽어 들인 데이터 블록을 담는 캐시 영역
버퍼 블록의 상태
1) Free 버퍼 : 인스턴스 기동 후 아직 데이터가 읽히지 않아 비어 있는 상태 이거나, 데이터가 담겼지만 데이터 파일과 서로 동기화 되어 있는 상태(덮어 써도 무방한 버퍼 블록), 데이터 파일로부터 새로운 데이터 블록을 로딩하려면 Free 버퍼를 확보해야한다. 변경이 발생하면 그 순간 Dirty 버퍼로 바뀐다.
2) Dirty 버퍼 : 버퍼에 캐시된 이후 변경이 발생 했지만, 아직 디스크에 기록되지 않아 데이터 파일 블록과 동기화가 필요한 버퍼 블록, 이 블록이 재사용 되려면 디스크에 기록 되어야 하고, 기록되는 순간 Free 버퍼로 상태가 바뀐다.
3) Pinned 버퍼 : 읽기, 쓰기 작업이 현재 진행 중인 버퍼 블록
LRU 알고리즘
버퍼 캐시는 유한한 자원이기 때문에 사용빈도가 높은 데이터 블록 위주로 버퍼 캐시가 구성되도록 LRU (Least Recently used) 알고리즘을 사용한다. 모든 버퍼 블록 헤더를 LRU 체인에 연결해 사용 빈도 순으로 위치를 옮기고 액세스 빈도가 낮은 쪽의 데이터 블록을 빌어내어 Free 버퍼를 만든다.
공유 풀
딕셔너리 캐시
데이터베이스 딕셔너리는 테이블, 인덱스 같은 오브젝트와 테이블 스페이스, 데이터 파일, 세그먼트, 익스텐트, 사용자, 제약에 관한 메타 정보를 저장한다. 딕셔너리 캐시는 딕셔너리 정보를 캐싱하는 메모리 영역이다.
라이브러리 캐시
수행한 SQL 문과 실핼 계획, 저장 프로시저를 저장하는 캐시 영역으로 하드 파싱을 최소화하기 위한 캐시 공간이다. 캐싱된 SQL 과 그 실행 계획의 재사용성을 높여 수행 성능을 높이고 DBMS 부하를 최소화하는 핵심 원리이다.
하드파싱(Hard Parsing) : 쿼리를 분석해서 문법 오류, 실핼 권한을 체크하고 최적화를 거쳐 실핼 계획을 만들고 SQL 실행 엔진이 이해할 수 있는 형태로 포맷팅하는 과정
로그 버퍼
로그 엔트리도 파일에 곧바로 기록하는 것이 아니라 먼저 로그 버퍼에 기록한다. 버퍼 캐시 블록을 갱신하기 전에 변경 사항을 먼저 로그 버퍼에 기록해야 하며, Dirty 버퍼를 디스크에 기록하기 전에 해당 로그 엔트리를 먼저 로그파일에 기록해야 한다. 이를 'Write Ahead Logging'라고 한다. 또한 로그 버퍼를 로그 파일에 기록할 때에는 커밋 시점에는 기록해야 한다. (Log Force at Commit)
PGA(Process Global Area)
각 Oracle 서버 프로세스는 자신만의 PGA 메모리 영역을 할당받고 이를 프로세스에 종속적인 고유 데이터를 저장하는 용도로 사용한다. 다른 프로세스와 공유하지 않으며 래치 매커니즘이 필요없어 SGA 버퍼 캐시에서 읽는 것보다 빠르다.
User Global Area(UGA)
전용 서버 방식으로 연결 할때는 1:1(프로세스:세션), 공유서버 방식으로 연결할 때는 1:M(프로세스:세션) 관계를 갖는다. 하나의 프로세스가 여러 개의 세션을 위해 일할 수 있다. 따라서 세션의 독립 메모리 공간을 위해 'UGA'를 할당한다.
전용 서버 방식에서는 PGA에 할당 되고, 공유 서버 방식에서는 SGA(Large pool이 설정 됐을 때에는 Large pool에 아니면 Shared Pool에 할당) 에 할당 된다.
Call Global Area(CGA)
하나의 DB Call 을 넘어서 다음 Call 까지 참조되어야 하는 정보는 UGA에 저장하고, Call 이 진행하는 동안에만 필요한 데이터는 CGA에 저장한다. Parse Call, Execute Call, Fetch Call 마다 매번 할당 받는다. Call 이 진행되는 동안 Recursive Call 이발생하면 그 안에서도 Parse Call, Execute Call, Fetch Call 단계 별로 CGA 가 할당된다. CGA에 할당된 공간은 Call 이 끝나자 마자 해제돼 PGA 로 반환된다.
Sort Area
소트 오퍼레이션이 진행되는 동안 공간이 부족할 때마자 청크 단위로 조금씩 할당된다. 세션마다 사용할 수 있는 크기는 workarea_size_policy 파라미터를 auto로 설정하면 내부적으로 결정된다. Sort Area 할당 위치는 SQL 문 종류와 수행 단계에 따라 다르다.
DML : CGA 에 할당
SELECT : 중간에 필요하면 CGA, 최종 결과에 필요하면 UGA에 할당
SQL Server 는 데이터 정렬은 메모리 풀의 버퍼캐시에서 수행하며 세젼정보는 Connection Context에저장한다.
대기 이벤트
DBMS 내부의 프로세스 간에는 상호작용이 필요하며 다른 프로세스가 작업을 완료할 때 까지 수면 상태로 대기하는데 이때 대기 유형별 상태와 시간 정보가 공유 메모리 영역에 저장된다. 이러한 대기 정보를 Oracle에서는 '대기 이벤트'라고 부르며, SQL Server 에서는 '대기 유형'이라고 한다.
대기 이벤트가 중요한 이유는 대기 이벤트를 기반으로 'Response Time Analysis' 성능관리 방법론이 데이터베이스 성능 진단 분야에 변혁을 가져왔기 때문이다. 이 방법론은 세션 또는 시스템 전체에서 발생하는 병목 현상과 그 원인을 찾아 문제를 해결하는 방법과 과정을 다룬다.
Response Time = Service Time + Wait Time
= CPU Time + Queue Time
** 'Response Time Analysis' 성능관리 방법론에서의 데이더베이스 서버의 응답시간
이때, 서비스시간은 프로세스가 일을 수행한 시간을 말하며 대기시간은 프로세스가 잠시 수행을 멈추고 대기한 시간이다. CPU Time 은 파싱 작업에 소비한 시간인지 쿼리 오퍼레이션 수행을 위해 소비한 시간인지를 분석하고, Wait Time 은 각각 발생한 대기 이벤트를 분석해 시간을 가장 많이 소비한 이벤트를 중심으로 해결 방안을 모색한다.
Oracle 10g 에서의 대기 이벤트 중 성능 문제와 직결되며 빈번한 것들을 설명하고자 한다.
라이브러리 캐시 부하
라이브러리 캐시에서 SQL 커서를 찾고 최적화 하는 과정에 경합이 발생
- latch: shared pool
- latch: library cache
수행중인 SQL 이 참조하는 오브젝트에 다른 사용자가 DDL 문장을 수행할 때 발생
- library cache lock
- library cache pin
데이터베이스 Call 과 네트워크 부하
애플리케이션과 네트워크 구간에서 소모된 시간
SQL*Net message from client
이 이벤트는 사실 데이터베이스 경합과는 관련이 없다. 클라이언트로부터 다음 명령이 나올 때 까지 Idle 상태로 기다릴 때 발생하기 때문이다. 반면, 나머지 세개는 실제 네트워크 부하가 원인일 수 있다.
SQL*Net message to client
SQL*Net more data to client
위 두개의 이벤트는 클라이언트에게 메세지를 보냈는데 받았다는 신호가 늦게 도착하는 경우나 클라이언트가 너무 바쁜 경우일 수 있다.
SQL*Net more data from client
이 이벤트는 클라이언트로부터 더 받을 데이터가 있는데 지연이 발생하는 경우이다.
디스크 I/O 부하
db file sequential read
Single Block I/O(I/O Call 한번에 하나의 데이터 블록만 읽는 것) 를 수행할 때 나타나는 대기 이벤트이다. 인덱스 블록을 읽을 떄 그리고 인덱스를 거쳐 테이블 블록을 액세스 할 때 이 방식을 사용한다. 이 이벤트는 'db file parallel read'와 중복된다.
db file scatterd read
direct path read
direct path write
direct path write temp
diredt path read temp
db file parallel read
이 이벤트는 Multiblock I/O(I/O Call이 필요한 시점에 인접한 블록들을 같이 읽어 메모리에 적재하는 것)를 수행할 때 나타나며 table full scan 또는 Index Fast Full Scan때 나타난다.
버퍼 캐시 경합
버퍼캐시에서 블록을 읽는 과정에 경합이 발생
latch: cache buffers chains
latch: cache buffers lru chain
buffer busy waits
free buffer waits
버퍼 캐시에서 블록을 읽어도 대기 이벤트가 발생하면 동시성은 현저히 저하된다. 이들을 해소 하는 방법은 디스크 I/O 부하 해소 방안과 유사하다.
Lock 관련 대기 이벤트
enq: TM - contention
enq: TX - row lock contention
enq: TX - index contention
enq: TX - allocate ITL entry
enq: TX cpntention
latch free
latch free 는 특정 자원에 대한 래치를 여러 차례 (약 2000번) 요청했지만 해당 자원이 계속 사용중이어서 잠시 대기 상태로 빠질 때 나타난다.
래치는 락과는 조금 다른데, Lock 은 사용자 데이터를 보호하지만, 래치는 SGA에 공유되어 있는 자료구조를 보호할 목적으로 사용하는 가벼운 Lock이다. 래치도 일종의 Lock이지만 큐잉 메커니즘을 사용하지 않는다. 따라서 프로세스는 래치 획득에 성공할 때 까지 시도를 반복할 뿐 우선권을 부여받지는 못한다. 이는 가장 먼저 래치를 요구했던 프로세스가 가장 늦게 래치를 얻을 수 있음을 뜻한다.
기타 이벤트
- log file sync
- checkpoint completed
- log file switch completion
- log buffer space
'SQLp > SQLp 이론' 카테고리의 다른 글
| [SQLp]과목 3 - 1 데이터베이스 Call과 네트워크 부하 (0) | 2018.06.17 |
|---|---|
| [SQLp]과목 3 - 1 SQL 파싱 부하 (0) | 2018.06.17 |
| [SQLp]과목 3 - SQL 고급 활용 튜닝 (0) | 2018.05.31 |
| [SQLp]과목 2 - SQL 기본 및 활용 (0) | 2018.05.31 |
| [SQLp]과목 1 - 데이터 모델링의 이해 (0) | 2018.05.31 |