이것저것

3.1.1 테이블 랜덤 액세스 SQL 튜닝은 랜덤 IO와의 전쟁 인덱스를 스캔하는 이유 : 검색 조건을 만족하는 소량의 데이터를 인덱스에서 빨리 찾고 거기서 테이블 레코드를 찾아가기 위한 주소값 즉, ROWID 를 얻기 위하여 인덱스 ROWID = 물리적 주소보다 테이블 레코드를 찾아가기 위한 논리적 주소 정보를 담고있음 인덱스 = 도서 색인 인덱스 ROWID = 도서 색인에 기록된 페이지 번호 결론 : 인덱스 ROWID = 논리적 주소 (디스크 상에서 테이블 레코드를 찾아가기 위한 위치 정보) 포인터가 아니다! 메인메모리 DB란? 데이터를 메모리에 모두 로드해 놓고 메모리를 통해서만 I/O를 수행하는 DB DBA (=데이터파일번호 + 블록번호)는 디스크 상에서 블록을 찾기 위한 주소 정보 매번 디스크 ..

2.3.1 Index Range Scan Index Range Scan은 B*Tree 인덱스의 가장 일반적인 정상적인 형태의 액세스 방식이다. Index Range Scan을 하려면 선두 컬럼을 가공하지 않은 상태로 조건절에 사용한다. (즉, 선두컬럼을 가공하지 않은 상태로 조건절에 사용하면 Index Range Scan은 무조건 가능하다.) 그러나 인덱스 잘타니까 성능도 OK 는 아니다! 성능은 인덱스 스캔 범위, 테이블 액세스 횟수등을 얼마나 줄일 수 있는가? 에 따라 달라진다. 2.3.2 Index Full Scan Index Full Scan은 수직적 탐색 없이 인덱스 리프 블록을 처음부터 끝까지 수평적으로 탐색한다. 데이터 검색을 위한 최적의 인덱스가 없을 때 차선으로 선택한다. (최적의 인덱스..

2.2.1 인덱스를 사용한다는 것 인덱스 컬럼(선두 컬럼)을 가공하지 않아야 인덱스를 정상적으로 사용 가능 (=리프 블록에서 스캔 시작점을 찾아 스캔하다가 중간에 멈추는 것을 의미) Index Range Scan : 리프 블록 일부만 스캔 (인덱스 컬럼 가공하면 Index Range Scan 불가능) 인덱스 컬럼을 가공해도 인덱스 사용 가능하지만, 스캔 시작점을 찾을 수 없고 멈출 수도 없어 리프 블록 전체를 스캔해야만 한다. Index Full Scan : 리프 블록 전체 스캔 2.2.2 인덱스를 Range Scan 할 수 없는 이유 "인덱스 컬럼을 가공하면 인덱스를 정상적으로 사용 (Range Scan)할 수 없다" 인덱스 컬럼을 가공하면 인덱스 스캔 시작점을 찾을 수 없기 때문 #1 인덱스에는 가공..

2.1.2 인덱스 구조 인덱스를 사용하면 전체 테이블 스캔 필요없이 범위 스캔(range scan) 가능하다. 범위 스캔이 가능한 이유는 인덱스는 항상 정렬돼 있기 때문이다. DBMS는 일반적으로 B+Tree 인덱스 사용한다. (루트+브랜치+리프) 루트와 브랜치 블록에는 키 값을 갖지 않는 특별한 레코드 존재한다. (이를 LMC라고 부른다.) LMC : 자식 노드 중 가장 왼쪽 끝에 위치한 블록 리프 블록에 저장된 각 레코드는 키값 순으로 정렬되어있고, ROWID (테이블 레코드를 가리키는 주소값)을 가짐 인덱스 키 값이 같을시 ROWID 순으로 정렬 2.1.3 인덱스 수직적 탐색, 2.1.4 인덱스 수평적 탐색 인덱스 탐색 과정 (1) 수직적 탐색 : 인덱스 스캔 시작지점을 찾는 과정 가장 처음에 인덱..

1.3.1 SQL이 느린 이유 SQL이 느린이유? 디스크 I/O 때문! I/O = 잠 OS가 I/O를 처리하는 동안 프로세스는 잠을 잔다! 디스크에서 데이터를 읽어야 할 때는 CPU를 OS에 반환하고 잠시 수면 상태에서 I/O가 완료되기를 대기 (I/O Call 하고 CPU 반환 -> SLEEP) 1.3.2 DB 저장구조 데이터를 저장하려면 가장 먼저 테이블 스페이스 가 필요하다 - 테이블 스페이스 : 세그먼트를 담는 컨테이너 (여러 개의 데이터 파일로 구성) - 세그먼트 : 테이블, 인덱스 처럼 데이터 저장 공간이 필요한 오브젝트 (여러 익스텐트로 구성) - 익스텐트 : 공간을 확장하는 단위 (연속된 블록의 집합) - 블록(페이지) : 레코드를 실제로 저장하는 공간 한 블록은 하나의 테이블이 독점 (한..

소프트파싱 vs 하드파싱 소프트파싱 : SQL을 캐시에서 찾아 곧바로 실행단계로 넘어가는 것 하드파싱 : 캐시에서 찾는데 실패해 최적화 및 로우 소스 생성 단계까지 모두 거치는 것 (캐시에서 찾으면 곧바로 실행 단계로 넘어갈 수 있음) Library Cache : SQL 파싱, 최적화, 로우 소스 생성 과정을 거쳐 생성한 내부 프로시저를 반복 재사용할 수 있도록 캐싱해 두는 메모리 공간 바인드 변수 라이브러리 캐시에서 SQL을 찾기 위해 사용하는 키 값은 'SQL문 그 자체' select * from emp where empno=7000; SELECT * FROM EMP WHERE EMPNO=7000; => 모두 다른 SQ 의미적으로는 같지만, 실행할 때 각각 최적화를 진행하고, 라이브러리 캐시에서 별도..