Oracle DB (36) 썸네일형 리스트형 인덱스 구조 및 종류의 이해(1) 1. 인덱스의 구조 - 인덱스 탐색 순서 1) 수직적 탐색 : Root - Branch - Leaf. 읽고자 하는 시작점 검색. Random I/O 2) 수평적 탐색 : Leaf Block의 시작점부터 종료점 까지. Sequential I/O 3) 테이블 Random Access : Data 블록을 읽는 경우 * 비용 : 테이블 Radom Access >수직적 탐색 > 수평적 탐색 - 기본 구조 : Root Node, Branch Node, Leaf Node - Root Node : 가장 상위노드로 하위 Branch Node 수만큼의 Row - Branch Node : Root와 Leaf의 연결고리로 자기 하위 Leaf Node 수만큼의 Row - Leaf Node : Key + Row ID로 구성. 2.. SQL 파싱 부하 1. 사용자가 SQL을 실행시 SQL PARSE - SYNTAX, SEMANTIC검사, LIBRARY CACHE에 실행계획 있는지 점검 - SOFT / HARD PARSING : SOFT는 LIBRARY CACHE에 찾아서 실행. HARD는 최적화 과정을 거치고 실행. (실행계획을 찾지 못했으므로) -> 최적화 과정은 엄청난 비용이 듦. 2. 캐싱된 SQL 공유 1) 실행계획 공유 조건 - 문법, 의미 오류 없는지 찾은 후 해쉬 함수로부터 반환된 해쉬 값으로 LIBRARY CACHE 내 HASH BUCKET 검색 후 HASH CAHIN 엔트리를 차례로 SCAN. 찾으면 저장된 계획으로 실행하고 없으면 최적화 수행 후 방금 탐색한 버켓의 체인에 연결 후 SQL 실행 2) 실행계획을 공유하지 못하는 경우 -.. 옵티마이저 원리 1) 옵티마이저 소개 (가) 옵티마이저란? - 쿼리 실행을 위해 후보군이 될 실행 계획을 찾는다 - 오브젝트 통계 및 시스템 통계 정보를 이용해 실행 계획의 예상비용 산정 - 각 실행 계획을 비교하여 최저 비용의 실행 계획 선택 (나) 옵티마이저 종류 - 옵티마이저 종류로는 규칙 / 비용 기반 옵티마이저가 있다 - 규칙기반 옵티마이저 : 미리 정해 높은 규칙에 따라 액세스 경로 평가 및 실행계획 선택 - 비용기반 옵티마이저 : 쿼리를 수행하는데 소요되는 일량 또는 시간을 비용으로 산정 -> 비용은 테이블, 인덱스에 대한 통계 정보를 기초하여 산정 (다) SQL 최적화 과정 PARSER(문법, 의미 오류 체크) -> OPTIMIZER (QUERY TRANSFORMER-표준 형태로, ESTIMATOR –통계.. 튜닝 기본 원칙 튜닝을 위한 3가지 기본 원칙 1. Library Cache 최적화 - Application 커서 캐싱 - Bind 변수 활용 2. DBMS Call 최소화 - Parse Call : Application 커서 캐싱 - Execute Call - Fetch Call ㅡ Array Processing 3. I/O 성능 효율화 - 수직적 탐색 효율화 -> Random I/O -> Index Rebuild - 수평적 탐색 선택율 ↑ -> Sequential I/O -> Index Matching degree Up! - 테이블 랜덤 I/O 최소화 -> Random I/O -> Where절 Column이 모두 Index에 있는지 실행계획 읽는 법 1) 위에서 아래로 2) 안에서 밖으로 읽기 옵티마이저 힌트 - 조.. 아키텍처 기반 튜닝 원리 1. 데이터베이스 아키텍처 Oracle Database Instance SGA Data Buffer Cache, Redo Log Buffer Shared Area Library Cache Dictionary Cache Java Pool, Large Pool Background Process PMON(프로세스), SMON(Ins 리커버리) DBWR, LGWR CKPT(체크포인트) Database Data Files Control Files Redo Log Files 1. 프로세스 – 백그라운드 프로세서 ORACLE SQL SERVER SMON DATABASE CLEAN UP/ SHRINKING THREAD PMON OPEN DATA SERVICE DBWR LAZYWRITER THREAD LGWR LOG W.. 네트워크에서의 대기 이벤트들 - 네트워크 관련 대기 이벤트들 1) SQL*Net message from/to client 2) SQL*Net more data from/to client 3) SQL*Net message from/to dblink 4) SQL*Net more data from/to dblink 이들 이벤트가 성능문제가 연관되는 경우는 네트워크 속도가 느린 경우, SQL 실행횟수가 불필요하게 높은 경우, 어플리케이션의 구현방식에 문제가 있는 경우이다. - 네트워크 속도가 느린 경우 만일 위 이벤트를 대기하는 시간이 불필요하게 높다면 네트워크 속도를 의심해볼 수 있다. 클라이언트와 DBMS 간의 문제가 있다면 1번과 2번의 문제이며, DBMS와 DBMS간의 네트워크 문제가 있다면 3번과 4번에 대한 대기시간이 증가할 수.. 리두(Redo)에서의 대기 이벤트들 - latch: redo writing, latch: redo allocation, latch: redo copy 1) redo writing 래치: 리두 버퍼내의 공간을 확보하기 위해 LGWR에게 쓰기 요청을 하려는 프로세스는 redo writing 래치를 획득해야 한다. LGWR에 의한 쓰기 작업은 동시에 수행될 수 없으므로, 자연스럽게 이 래치는 전체 인스턴스에 하나만 존재한다. redo writing 래치는 Willing-to-wait 모드로 획득된다. redo writing 래치를 획득하는 과정에서 경합이 발생하면 latch: redo writing 이벤트를 대기하게 된다. 2) redo copy 래치: PGA내의 체인지 벡터를 리두 버퍼로 복사하려는 프로세스는 작업의 전체과정 동안 redo c.. I/O에서의 대기 이벤트들 - db file scattered read 멀티 블록 I/O를 한번 수행할 때마다 물리적인 I/O가 끝나기를 기다리게 되며, db file scattered read 이벤트를 대기하게 된다. 오라클은 DB_FILE_MULTIBLOCK_READ_COUNT (MBRC) 파라미터로 지정된 값만큼 멀티 블록 I/O를 수행한다. 풀 테이블 스캔(FTS)에서 싱글 블록 I/O를 수행하거나, MBRC보다 작은 수의 블록을 읽어 들이는 경우는 다음과 같다. 1) 익스텐트 경계에 도달한 경우 2) 스캔 도중에 캐시된 블록이 있을 경우 3) Chained Row가 있는 경우 - 오라클의 I/O 레이어를 기준으로 db file scattered read 대기 문제에 대한 해결책 1) 어플리케이션 레이어: 대기가 주로 발생.. 이전 1 2 3 4 5 다음
