초콜릿 파워

aop 가 아래와 같은 상황에서 현실적으로 크게 와닿았기 때문에 이번 기회를 바탕으로 정리해보았습니다. @Transactional 어노테이션을 붙이더라도, 같은 클래스 내부의 다른 함수에서 호출된다면 transactional 이 제대로 일어나지 않는다는 걸 이해햐는 상황logger.log 를 매 메소드에 작성해서 로그를 쓰려니 로깅이 일관적이지 않고 번거로운 문제를 겪을 때.리소스가 private / public 타입 2가지로 달라져서, 각 타입에 따라서 권한 처리 로직이 달라져야하는 상황. Controller 혹은 Service 에서 매번 타입 별로 권한 체크를 해주는게 맞을지 고민되는 상황 Spring AOP(Aspect-Oriented Programming) 에 대해 알아보자! AOP(Aspect-..

소트하거나 추가 저장공간이 필요할 때 Oracle 은 PGA(인메모리), temp 테이블 스페이스(디스크.)를 활용한다. 소트 머지 조인(양쪽 집합을 미리 소트하고 저장.) 해시 조인 (해시 테이블 저장). 추가로 필요하다면 temp 테이블 스페이스 활용.소트, 데이터 그루핑을 할 때도 마찬가지. 5.1.1. 소트 과정소트를 하는 과정에서 Sort Area 만 사용해서 완료할 수 있는지 여부에 따라 2가지 종류로 나뉜다. 메모리 소트, Internal Sort : PGA 의 Sort Area 만 사용해서 소트하는 경우.디스크 소트, External Sort : 용량이 부족해서 디스크까지 사용해서 소트하는 경우. 디스크 소트는 디스크 I/O 가 발생해서 성능저하가 발생하기도 하지만, 부분범위 처리가 불가능..

NL 조인은 인덱스를 활용하기 때문에 논리적 IO 부하를 피할 수 없고, 버퍼 캐시 히트율에 따라 들쭉날쭉한 성능을 보인다. 반면 소트머지조인, 해시 조인은 대용량 데이터 처리가 NL 조인보다 빠르며 인덱스를 활용하지 않기 때문에 성능이 일정하다. 그 중에서도 소트머지 조인은 항상 양쪽 테이블을 정렬해야하는데, 해시 조인은 그런 부담도 없다. 해시 조인이 필요한 상황과 기본 메커니즘, 전체 조인 옵션의 사용하기 좋은 상황에 대해 알아본다. 4.3.1. 기본 메커니즘Build 단계 : 작은 테이블을 읽어서 해시 테이블(해시 맵)을 생성한다. 조인 칼럼을 해시 테이블의 키로 해서 생성한다. 해시 테이블은 PGA 영역의 Hash Area 에 저장한다. (테이블을 읽는 과정은 DB 버퍼 캐시를 경유할 수 밖에..

4.1. NL 조인4.1.1. 기본 메커니즘 4.1. NL 조인NL 조인은 인덱스를 활용하는 방식이고 어떤 자료형을 쓰느냐의 차이로 NL조인, 소트머지조인, 해시 조인이 나뉘게 되므로 한번 이해하게 되면 나머지 조인 방식도 이해하기 쉬워진다. 4.1.1. 기본 메커니즘outer loop, inner loop 에서 모두 인덱스를 활용한다. outer 는 아무리 많아도 table full scan 한번만 하는 효과가 되기 때문에 인덱스를 활용하지 않아도 될 때도 있지만, inner 는 인덱스를 활용해야 한다. 4.1.2.NL 조인 실행 계획 제어힌트 사용ordered use_nl(table)ordered : from 절에 기술한 순서대로 조인할 것. leading(A,B,C,D) : from 절에 기술한 ..

기본적으로는 인덱스 칼럼 추가로 튜닝을 하는데, (랜덤 IO 줄이는 효과인가? ) 인덱스 스캔 효율화는 다양한 방법이 존재한다. 3.3.1. 인덱스 탐색인덱스 탐색 과정 상세인덱스를 구성하는 두 개 칼럼에 대해, 둘다 between 조건 절로 묶여있다면 선두 칼럼은 인덱스의 스캔 범위를 줄이는데 도움이 되지만, 두번째 칼럼은 그렇지 못하다. 3.3.2. 인덱스 스캔 효율성결국 인덱스 선행 컬럼이 조건절에 없거나, '=' 연산이 아니라면 비효율이 발생한다. C1, C2, C3, C4 -> C3 에 대한 조건 없이 C4 에 대한 '=' 조건만 있는 경우, 비효율 발생. '=' 가 아니라 between 조건이라면 비효율 발생. 선두 칼럼가장 앞에 있는 칼럼. 선행 칼럼특정칼럼보다 상대적으로 앞쪽에 있는 칼럼3..

3.2.1 부분범위처리fetch call 의 원리.전체 쿼리 결과집합을 쉽 없이 연속적으로 전송하지 않고 사용자로부터 Fetch Call 이있을 때마다 일정량씩 나누어 전송하는 것을 이른바 ‘부분범위 처리라고 한다.sql 문에서 페이징 마냥 조회를 나누어서 하는 것도 해당될까? -> 맞다. 매우 중요한 부분! 5장에서 또 등장한다. sql 상에서 limit, row num 지정하는 것에도 해당한다.정렬정렬 이슈 때문에 부분범위 처리를 하지 못하는 경우.인덱스 특성 상 정렬을 생략할 수 있는 경우에만 부분범위 처리 또한 가능하다.Array Size 조절을 통한 Fetch Call 최소화네트워크 전송량에 따라 Array size 를 조절하는 것이 좋다.파일 다운로드처럼 어차피 모두 전송해야한다면 최대한 크게..

3.1. 테이블 엑세스 최소화인덱스 ROWID는 물리적 주소? 논리적 주소?ROWID 는 논리적 주소에 가깝다.물론 데이터 파일 번호, 로우 번호 등 물리적인 내용을 담고는 있지만, 물리적으로 직접 연결되지는 않고 실제 테이블에 접근하기 위한 논리적 주소를 저장하고 있기 때문이다.포인터와 같은 역할은 하지만, 실제 포인터와는 다르고 정보를 갖고 데이터에 접근하는데 시간이 걸린다. (물리적으로 연결된 것이 아님. )메인 메모리 DB vs 잘 캐싱된 DB데이터를 모두 메모리에 올려두고 I/O 작업을 수행하는 메인 메모리 DB (MMDB)OLTP 성 DB는 캐시 히트율이 99%이기 때문에 디스크대신 거의 메모리에서 데이터를 읽음.그런데도 둘의 성능의 차이가 꽤 크다. (MMDB 가 빠름).그 이유는 MMDB ..

기본적으로 SGA 테이블 스페이스라는 곳에 저장한다. 세그먼트 단위로 나누어서 테이블, 인덱스, 등에 관한 데이터를 묶어서 저장한다. 데이터는 익스텐트 단위로 확장된다. 실제 데이터가 기록될 때는 블록 단위로 저장된다. (오라클 기준 블록, Mysql 기준 페이지)데이터 파일에 블록이 저장되는데, 한 블록에는 같은 테이블에 대한 정보들이 들어있다.한 테이블에 대한 정보를 담은 블록은 데이터 파일에 분산되어 저장된다. (테이블 엑세스 시에 파일 경합이 벌어지는 것을 줄이기 위해서 그렇다.)따라서 같은 데이터 파일에 저장되었다고 해서 같은 테이블에 대한 정보가 저장되었다고 볼 수는 없다.  sql 의 성능을 끌어올리는 것은 I/O 작업을 줄이는 것에 목표가 있는데, 물리적 I/O 보다도 논리적 I/O 를 줄..

인덱스 튜닝과 설계를 제대로 하기 위해, 인덱스가 수직 탐색, 수평 탐색 단 두 단계만 거친다는 것을 이해하자. 인덱스의 기본 구조와 원리에 대해 숙지하자. 기본적으로 데이터를 찾는 방법은 두가지이다. 테이블 전체를 대상으로 탐색 인덱스를 이용. 인덱스를 튜닝할 때 핵심은 두 가지이다. 인덱스 스캔 효율화 튜닝예시이름이 '홍길동' 이고 시력이 1.0~2.0 사이인 학생을 찾자! 표 3-2 에서는 이름과 시력 순으로 정렬, 표 3-3에서는 시력과 이름 순으로 정렬랜덤 엑세스 최소화 튜닝인덱스 스캔 이후에 테이블 레코드를 엑세스하는 과정은 랜덤 I/O 방식. 테이블 엑세스 횟수 최소화 예시다시 이름이 '홍길동'이고 시력이 1.0~2.0 인 학생을 찾자!이름이 '홍길동' 인 학생은 5명, 시력이 1.0~..

복합인덱스로 구성된 경우, 찾을 때 인덱스 활용은 첫번 째 칼럼만 가능하다. 따라서 인덱스에 등록되어있다고 해도, 복합인덱스라면 모두 인덱스를 탈거라고 생각하면 안된다.