액세스 조건 인덱스 스캔 범위를 결정하는 조건 인덱스 수직적 탐색을 통해 스캔 시작점을 결정하는 데 영향을 미치고, 인덱스 리프블록을 스캔하다 어디서 멈출지를 결정하는데 영향을 미친다. 필터 조건 인덱스를 사용하든, 테이블 Full Scan을 하든, 테이블 액세스 단계에서 처리되는 조건절을 의미한다. 쿼리 수행 다음 단계로 전달하거나 최종 결과집합에 포함할지를 결정한다. 옵티마이저 비용 계산 원리 인덱스를 이용한 테이블 액세스 비용 비용 = 인덱스 수직적 탐색 비용 + 인덱스 수평적 탐색 비용 + 테이블 랜덤 액세스 비용 = 인덱스 루트와 브랜치 레벨이서 읽는 블록 수 + 인덱스 리프 블록을 스캔하는 과정에서 읽는 블록 수 + 테이블 액세스 과정에서 읽는 블록 수 비교 연산자 종류와 컬럼 순서에 따른 군..
전체 글

부분범위 처리 쿼리 결과 집합을 쉼없이 연속적으로 전송하지 않고, 사용자로부터 Fetch Call이 있을 때마다 일정량씩 나누어 전송하는 것 정렬 조건이 있는 경우 부분범위 처리 DB서버는 모든 데이터를 다 읽어 정렬을 하고 나서 데이터 전송을 시작 할 수 있다 -> 전체 범위 처리 인덱스를 사용해 정렬을 생략 할 수 있는 경우는 부분범위 처리 가능하다. OLTP환경에서 부분범위 처리에 의한 성능 개선 OLTP환경에서 대량의 데이터를 조회해야할 경우, 대부분의 경우에는 모든 데이터를 한번에 보여줄 필요가 없다. 이 경우 인덱스와 부분범위 처리를 활용하면 정렬작업을 생략하고, 앞부분 데이터를 빠르게 보여 줄 수있다. 멈출 수 있어야 의미있는 부분범위 처리 앞쪽 일부만 출력하고 멈출 수 있는가이다. n-Ti..

Index ROWID ROWID는 논리적 주소에 가깝다. ROWID를 통해 디스크 상의 데이터를 찾는 방법은 다음과 같다. 1. 해싱 알고리즘을 이용해 버퍼 헤더를 찾고, 버퍼블록을 찾아간다. 2. 못찾았을 경우는 디스크에서 블록을 읽고 버퍼캐시에 적재한다. 캐싱돼 있더라도 테이블 레코드를 찾기 위해 매번 DBA 해싱 및 래치 획득이 필요하다. 클러스터링 팩터 특정 컬럼을 기준으로 같은 값을 갖는 데이터가 서로 모여있는 정도 클러스터링 팩터가 좋으면 ROWID를 통해 찾는 속도가 빠르다 버퍼 Pinning 인덱스 ROWID로 테이블을 액세스할 때, 래치 획득 및 해시 체인 스캔 과정을 거쳐서 어렵게 찾아간 데이터 테이블 블록에 대한 포인터를 바로 해체하지 않고 일단 유지한다. 이 상태에서 다음 인덱스 레..

Index Range Scan B*Tree 인덱스의 가장 기본적이고 일반적인 사용 형태 루트에서 리프 블록까지 수직적으로 탐색 한 후에 필요한 범위만 스캔한다. 선두 칼럼이 가공하지 않은 상태로 조건절에 사용해야 한다. 성능은 테이블 액세스 횟수를 얼마나 줄일 수 있느냐로 결정된다. Index Full Scan 수직적 탐색 없이 인덱스 리프 블록을 처음부터 끝까지 수평적으로 탐색하는 방식 효용성 인덱스 스캔 과정에서 대부분의 레코드를 필터링하고 일부만 테이블 엑세스 하는 경우라면 효과가 있다. Index Unique Scan 수직적 탐색만으로 데이터를 찾는 스캔방식, Unique인덱스를 "="조건으로 탐색하는 경우 Index Skip Scan 루트 혹은 브랜치블록에서 읽은 컬럼 값 정보를 이용해 조건절에..
테이블 액세스 최소화 Index RowID에 대한 오해 Index ROWID는 포인터가 아니다. DBA(Data Block Address, 데이터 파일 번호 + 로우 번호) + 블록 주소로 구성되어 있다. 이는 포인터만큼 빠르지 않다. 오히려 생각보다 느리다. 메인 메모리 DB의 경우는 인덱스에 포인터가 들어간다.(인스턴스 기동 할 때, 데이터 전부 메모리로 로드) I/O 메커니즘 복습 데이터가 캐싱 되어 있어도 DBA해싱과 래치 획득 과정이 필요하다. 동시 액세스가 심할 경우에는, 캐시 버퍼 체인 래치, 버퍼 Lock 경합이 추가로 발생한다. DBA와 해싱 알고리즘을 이용해 버퍼 헤더를 찾는다. 버퍼헤더에 있는 포인터를 이용해 블록에 찾아간다. 캐시에 없을 경우 디스크에 접근 및 캐시 등록을 한다. 인..
DBMS에서 데이터를 찾는 방법 테이블 전체 스캔 대상 데이터가 많을 경우 좋음 인덱스를 이용하여 스캔 대상 데이터가 적을 경우 좋음 인덱스 튜닝 OLTP(OnLine Transaction Processing)시스템에서는 소량 데이터를 주로 검색하므로 중요하다. 인덱스 스캔 과정에서의 비요율을 줄이는 것, 인덱스 스캔 효율화 튜닝 테이블 액세스 횟수 튜닝, 인덱스 스캔 후 랜덤 I/O 방식을 사용함, 랜덤 액세스 최소화 튜닝 인덱스 탐색 수직적 탐색 인덱스 스캔 시작지점을 찾는 과정 수평적 탐색 데이터를 찾는 과정 성별 = ‘남’ & 고객명 = ‘이재희’ 데이터 찾는 과정 루트 블록 스캔을 통해 찾고자 하는 값보다 큰 첫번째 값을 찾음(’남’ & ‘최’) 해당 레코드가 가리키는 하위 블록으로 갈 경우 찾..

Django에서 인증과 인가는 어떤 과정을 통해서 이루어지는지 살펴보자 Django 3.2와 DRF 및 Session을 기준으로 작성하도록 하겠다. 인증 API요청을 통해 ID/Password등의 검증이 끝나고 django.contrib.auth.login 을 통해 세션을 얻게 된다. 세션 갱신, 유저 Backend확인 및 연결, CSRF Token 갱신(발급) 등을 진행 한다. (일반적으로 django.contrib.auth.backends.ModelBackend를 쓸 것이다.) 끝으로 user_logged_in signal을 보내고 인증이 완료된다. Django에서 기본 구현된 인증 종류중 Cookie를 쓰는 것은 세션이 유일하기 때문에, 세션을 발급 할 경우 CSRFToken을 갱신 해 준다. de..
Setup CACHEOPS_REDIS = { 'host': 'localhost', 'port': 6379, 'db': 1, # connection timeout 'socket_timeout': 3, # 선택 'password': '...', # host, port 대신 사용 할 경우 'unix_socket_path': '' } # URL로도 설정 가능 CACHEOPS_REDIS = "redis://localhost:6379/1" # Unix 소켓도 마찬가지로 URL로 설정 가능 CACHEOPS_REDIS = "unix://path/to/socket?db=1" # Password URL CACHEOPS_REDIS = "redis://:password@localhost:6379/1" # Sentinel 설정..
SQL 병목 원인 디스크 I/O가 일어나는 동안 프로세스는 잠을 자게 된다. 프로세스가 CPU에서 실행 중일 때 디스크에서 데이터를 읽어야 할 경우 waiting 상태에서 I/O가 끝나기를 기다린다. 데이터 저장 구조 - 오라클 기준 Table Space(테이블스페이스) Segment를 담는 Container, 여러 개의 데이터 파일(디스크 상의 물리적인 OS 파일)로 구성된다. Segment(세그먼트) 데이터 저장 공간이 필요한 오브젝트(테이블, 인덱스…), 여러 개의 Extent로 구성 파티션이 아닐 경우 → 하나의 테이블/인덱스는 하나의 Segment 파티션 구조일 경우 → 하나의 파티션이 하나의 Segment Extent(익스텐트) 공간을 확장하는 단위, 데이터를 입력하다가 공간이 부족해지면 해당..