aDBanced Team

Cardinality는 집합 안의 원소 개수, 오라클의 경우는 예측 Row 수라고 할 수 있습니다. 옵티마이저가 실행계획을 세우는 데 있어서 가장 중요한 것은 정확한 Cardinality의 계산이며, 동시에 그것은 실행계획이 비효율적인 가장 큰 원인이기도 합니다. 아래 실습은 기본적인 테이블을 생성 후에 ANALYZE TABLE을 하면 통계정보가 생성되며, 이후 Cardinality를 확인하는 방법과 Histogram에 따라서 정확한 값을 예측 불가능 하다는 것을 확인해보도록 하겠습니다. 즉, Histogram을 사용하지 않도록 설정합니다. Cardinality의 기본적인 개념을 먼저 파악하겠습니다. 1. Base Cardinality Base Cardinality란 Table의 전체 Row 수를 의미합..

1. 바인드 변수의 부작용과 해법1.1. 바인드 변수 사용 시 - 최초 수행 시 : 최적화를 거친 실행계획을 캐시에 적재(하드 파싱) - 실행 시점 : 캐시의 실행계획을 그대로 가져와 값을 다르게 바인딩하면서 반복 재사용(소프트파싱) - 바인딩 시점 (최적화 이후인 실행시점) - SQL 최적화 시점에 조건절 컬럼의 데이터 분포도(컬럼 히스토그램) 활용을 못함(부작용) - 옵티마이저는 평균 분포를 가정한 실행계획을 생성 - 컬럼의 데이터 분포가 균일 시 문제가 없음, 그렇지 않을 시 시행 시점에 바인딩 되는 값에 따라 최적이 아닌 실행계획 수행가능(부작용) - 등치(=) 조건이 아닌 부등호나 범위기반 검색 조건 시 고정 된 규칙을 사용하여 더 부정확한 예측의 실행계획 생성가능(부작용) 1.2 바인딩 변수 ..

특정 테이블스페이스 Hot backup 시에는 해당 데이터 파일을 사용하지 못함 따라서 backup 도중 테이블스페이스에 속한 테이블의 데이터 변경이 발생할 경우, SCN을 통해서 변경된 데이터에 대한 작업 확인 1. BEGIN BACKUP - BEGIN BACKUP은 버퍼 캐시에 있는 데이터가 데이터 파일로 내려 써진 이후에 진행된다. 2. 현재 SCN 확인 - 쿼리SELECT CURRENT_SCN FROM V$DATABASE; 3. 데이터파일의 SCN 확인 - 쿼리SELECT A.NAME, B.CHECKPOINT_CHANGE#FROM V$TABLESPACE A,V$DATAFILE BWHERE 1 = 1AND A.NAME = 'TEST_TBS' /*테이블스페이스명*/AND B.TS# = A.TS#; 4..

글로벌 트랜잭션 아이디 글로벌 트랜잭션 아이디란?(GTID) Global Transaction ID의 약자 바이너리 로그 파일명이나 위치는 해당 이벤트가 저장된 물리적인 위치를 가리키지만 글로벌 트랜잭션 아이디는 논리적인 의미 주로 서버의 노드 아이디와 트랜잭션 아이디로 구성되어있어서 마스터와 슬레이브 간에 중복될 가능성이 없음 DML, DDL 이 발생할 때마다 트랜잭션 아이디가 1씩 증가하면서 글로벌 트랜잭션 아이디가 생성되며 바이너리 로그 이벤트와 매핑됨 글로벌 트랜잭션 아이디가 슬레이브로 전달되면 릴레이 로그 파일이나 슬레이브 바이너리 로그 파일로 기록 글로벌 트랜잭션 아이디의 필요성 동기화 시 파일 내의 위치를 찾아서 (물리적) 복제를 수행하기는 어려움 글로벌 트랜잭션을 사용하면 적용된 글로벌 트..

파티션 MariaDB 10.0에서 파티션 최대 개수가 1024개에서 8192개로 확장 명시적 파티션 지정 명시적 파티션 지정 기능으로 대부분의 DML 문장과 SELECT 쿼리에서 사용할 수 있음 명시적 파티션 지정 사용법 테이블 생성 데이터 입력 데이터 입력 – 파티션을 지정해서 데이터를 입력할 수 있음 데이터 입력 – 파티션을 지정하여 데이터를 입력할 때, 범위와 맞지 않으면 에러 발생 데이터 확인 데이터 확인 – 파티션을 지정해서 데이터를 조회할 수 있음 명시적으로 파티션을 지정했을 때 pruning 확인 조건절로 특정 파티션에 있는 데이터를 조회했을 때 pruning 확인 명시적 파티션 지정 기능의 용도 옵티마이저가 파티션 프루닝을 처리하지 못할 때 NOT DETERMINISTIC(함수의 결과를 예..

1.InnoDB 스토리지 엔진 - 멀티스레드 기반의 언두 퍼지(Multi threaded purge) - InnoDB는 MVCC와 롤백을 위해서 언두 영역(언두 스페이스,롤백 세그먼트)를 별도로 관리 한다. 1.1 언두퍼지(Undo purge) - 많은 클라이언트 커넥션에서 데이터를 변경하게 되면 언두 로그 영역에 수많은 변경 전 정보들이 쌓이게 되는데,이렇게 쌓인 언두 로그를 언젠가는 삭제를 하고 빈 공간을 마련해야 이후의 변경 이력을 저장 할 수 있게 한다. InnoDB에서는 언두퍼지를 전담하는 별도의 스레디가 존재하며, Innodb_purge_threads 시스템 설정 변수로 언두 퍼지 개수 설정 가능.값이 0이면 마스터 스레드 사용(5.5 이전 메커니즘), 1이면 1개의 언두 퍼지 , 2이상이면 ..

InnoDB 스토리지 엔진 버퍼 풀 성능 개선 NUMA 버퍼 풀 메모리 초기 할당 리눅스에서는 InnoDB 버퍼 풀에 할당된 메모리를 점유하는 것이 아니라 사용할 것이라고 예약만 해두고 실제 응용 프로그램에서 접근할 때에만 리눅스가 응용 프로그램으로 할당해줌 장점 : 사용자의 실수를 막을 수 있음, 메모리 낭비를 막을 수 있음 단점 : 메모리 할당에 대해서 db 서비스를 시작할 때 관리자가 알 수 없음 -> 잘못된 메모리 할당으로 스왑을 사용하게 되거나 프로세스가 강제 종료 될 수 있음 단점을 보완하기 위해서 XtraDB는 버퍼 풀로 할당된 메모리 공간을 운영체제로부터 미리 모두 할당 받는 기능이 추가됨 -> 메모리 사용량 고정 InnoDB 잠금 세분화 (MySQL 5.6) mutex를 세분화해서 잠금 ..

풀 테이블 스캔 다음과 같은 조건일 때 주로 풀 테이블 스캔 테이블의 레코드 건수가 너무 적어서 풀 테이블 스캔이 빠른 경우 WHERE, ON 절에 인덱스를 이용할 수 있는 조건이 없는 경우 조건에 일치하는 레코드 수가 너무 많은 경우 Read ahead 풀 테이블 스캔 시 대량의 페이지를 한번에 읽어올 수 있는 기능 Innodb나 XtraDB 스토리지 엔진은 테이블의 연속된 데이터 페이지가 읽히면 백그라운드 스레드에 의해서 Read ahead 작업이 자동으로 시작 포그라운드 스레드가 페이지를 읽다가 특정 시점부터는 백그라운드 스레드가 읽기 시작하는데 한번에 4 ~ 8개의 페이지를 읽다가 증가시킴. 최대 64개. innodb_read_ahead_threshold의 시스템 변수가 낮을수록 더 자주 Read..

옵티마이저 힌트 힌트사용법 힌트는 SQL 일부로 해석되기 때문에 잘못 사용할 경우 오류를 발생시킨다. SELECT * FROM employees USE INDEX (PRIMARY) where emp_no=10001; SELECT * FROM employees /*! USE INDEX ( PRIMARY) */ WHERE emp_no=10001; CREATE /*! 32302 TEMPORARY */ TABLE temp_emp_stat … STRAIGHT_JOIN 조인의 순서를 FROM 절에 명시된 테이블 순서대로 고정시키는 힌트 (오라클 ORDERED) 다음 기준일 경우 힌트 사용을 권고함 임시 테이블과 일반 테이블 -> 일반적으로 임시 테이블을 드라이빙 테이블로 선정하는 것이 좋으나, 일반 테이블에 조인 ..

[그림 1] MariaDB 상세 내용 [파일 1] MariaDB Optimizer 상세 내용 [프리젠테이션] MariaDB Other Features from JongJin Lee MariaDB에 대한 내용은 그림 1과 파일 1은 각각 상세하게 설명 되어 있습니다. 마지막으로 프리젠테이션은 MariaDB Other Feature관련된 내용을 상세하게 설명 되어 있습니다.