■ 파티셔닝 소개비 네이티브 파티셔닝이 있는 테이블을 사용하면 ER_WARN_DEPRECATED_SYNTAX경고가 발생합니다. MySQL 5.7.17에서 5.7.20까지, 서버는 시작시 비 기본 파티션을 사용하는 테이블을 식별하기 위해 자동으로 검사를 수행합니다. 발견된 파티션은 오류 로그에 메시지를 기록합니다. 이 검사를 비활성화하려면 --disable-partition-engine-check 옵션을 사용합니다. MySQL 5.7.21 이상에서는 이 검사가 수행되지 않습니다. 이 버전에서 서버가 일반 파티셔닝 핸들러를 사용하여 테이블을 확인하려면 --disable-partition-engine-check=false로 서버를 시작해야합니다. MySQL 8.0으로의 마이그레이션을 준비하려면 비 네이티브 파..
■ 쿼리 계획 평가 제어쿼리 옵티마이저의 작업은 SQL 쿼리를 실행하기위한 최적의 계획을 찾는 것입니다. "좋은"계획과 "나쁜"계획 간의 성능 차이는 수십 배 (몇 초에서 몇 시간 또는 며칠)에 달할 수 있으므로 MySQL 쿼리를 포함한 대부분의 쿼리 옵티마이저는 최적의 검색을 위해 다소 철저한 검색을 수행합니다. 가능한 모든 쿼리 평가 계획 중에서 실행 계획을 만듭니다. 조인 쿼리의 경우 MySQL 옵티마이저가 조사한 가능한 계획수가 쿼리에서 참조되는 테이블 수에 따라 기하 급수적으로 증가합니다. 적은 수의 테이블 (일반적으로 7-10 미만)의 경우 문제가되지 않습니다. 그러나 더 큰 쿼리를 제출하면 쿼리 최적화에 소요되는 시간이 서버 성능의 주요 병목이 될 수 있습니다. 보다 유연한 쿼리 최적화 방법..
■ 사전 지식+ IN (or = ANY) 서브 쿼리의 경우 옵티마이저는 다음 선택 사항을 갖습니다.- Semijoin- Materialization(구체화)- EXISTS 전략 + NOT IN (or ALL) 서브 쿼리의 경우 옵티마이저는 다음 선택 사항을 갖습니다.- Materialization(구체화)- EXISTS 전략 파생 테이블의 경우 옵티마이저에는 다음과 같은 선택 사항이 있습니다 (참조보기에도 적용됨).+ 파생 테이블을 외부 쿼리 블록으로 병합+ 파생 테이블을 내부 임시 테이블로 구체화 다음 설명에서는 이전 최적화 전략에 대한 자세한 정보를 제공합니다. 노트서브 쿼리를 사용하여 단일 테이블을 수정하는 UPDATE 및 DELETE 문의 제한 사항은 옵티마이저가 semijoin 또는 mater..
◈ 선수조건DB2 인스턴스와 DB생성 및 제거 그리고 환경설정을 무리없이 할수 있다는 전제하에 진행합니다.또한 Oracle Version 을 알아두어야 합니다. 1. Infosphere Federation Server설치(현제 최신버전은 Infosphere Federation Server 9.7 Fixpack3a)- V9.7 FixPack3a버전은 /opt/IBM/wsii/V9.7이 기본 설치경로- 역시 DB2가 설치된 서버에서 같은 버전의 통칭 WFS(Websphere Federation Server)가 설치되어야 합니다.- DataJoiner 혹은 DB2 II 혹은 WII 혹은 WFS 모두 같은 제품을 가리킴. 즉, DB2가 V8이면 DB2 II V8.x 혹은 DB2 V9 이면 WII 혹은 WFS ..
■ 인덱스 병합 최적화란?인덱스 병합 액세스 방법은 여러 범위 스캔으로 행을 검색하고 결과를 하나로 병합합니다. 이 액세스 방법은 단일 테이블의 인덱스 스캔만 병합하고 여러 테이블의 스캔은 병합하지 않습니다. 병합은 기본 스캔의 결합, 교차 또는 교차 결합을 생성할 수 있습니다. 인덱스 병합을 사용할 수있는 쿼리 예 :SELECT * FROM tbl_name WHERE key1 = 10 OR key2 = 20;SELECT * FROM tbl_name WHERE (key1 = 10 OR key2 = 20) AND non_key = 30;SELECT * FROM t1, t2 WHERE (t1.key1 IN (1,2) OR t1.key2 LIKE 'value%') AND t2.key1 = t1.some_..
InnoDB는 기본키 컬럼을 추가하여 각 보조 인덱스를 자동으로 확장합니다. 예를 들어 다음과 같은 테이블이 있습니다. CREATE TABLE t1 ( i1 INT NOT NULL DEFAULT 0, i2 INT NOT NULL DEFAULT 0, d DATE DEFAULT NULL, PRIMARY KEY (i1, i2), INDEX k_d (d) ) ENGINE = InnoDB; 이 테이블은 열(i1, i2)의 기본 키를 정의합니다. 또한 컬럼(d)에 보조 인덱스 k_d를 정의하지만 내부적으로 InnoDB는이 인덱스를 확장하여 이를 열 (d, i1, i2)로 처리합니다. 옵티마이저는 해당 인덱스 사용 방법 및 사용 여부를 결정할 때 확장 보조 인덱스의 기본 키 컬럼을 고려합니다. 이로 인해 쿼리 실행 ..
1. Federation 을 구성할 DB 가 위치한 인스턴스의 DBM CFG 중 FEDERATED 가 YES 인지 확인한다.아니라면 YES 로 설정 후 db2stop/db2start 를 실행하여 변경값을 적용한다.$ db2 get dbm cfg | grep -i federated$ db2 update dbm cfg using FEDERATED YES$ db2 get dbm cfg | grep -i federated Federated Database System Support (FEDERATED) = YES 2. Federation 을 구성할 DB 를 catalog 한다.◈ 카탈로그한 노드명 과 DB 명은 서버 생성시 사용하게 된다.- DB 카탈로그 구문- 노드 카탈로그 (인스턴..
보조 인덱스에서 범위 스캔을 사용하여 행을 읽으면 테이블이 크고 스토리지 엔진 캐시에 저장되지 않은 경우 기본 테이블에 대한 임의의 디스크 액세스가 많이 발생할 수 있습니다. 디스크 스윕 다중 범위 읽기 (MRR) 최적화를 통해 MySQL은 먼저 인덱스 만 스캔하고 관련 행에 대한 키를 수집하여 범위 스캔에 대한 임의 디스크 액세스 수를 줄입니다. 그런 다음 키가 정렬되고 기본 키 순서대로 기본 테이블에서 행이 검색됩니다. 디스크 스윕 MRR의 동기는 무작위 디스크 액세스 수를 줄이고 대신 기본 테이블 데이터의 순차적 스캔을 달성하는 것입니다. 다중 범위 읽기 최적화는 다음과 같은 이점을 제공합니다.- MRR을 사용하면 인덱스 튜플을 기반으로 임의의 순서가 아닌 순차적으로 데이터 행에 액세스할 수 있습니..
1. Federation 을 구성할 DB 가 위치한 인스턴스의 DBM CFG 중 FEDERATED 가 YES 인지 확인한다. 아니라면 YES 로 설정 후 db2stop/db2start 를 실행하여 변경값을 적용합니다.$ db2 get dbm cfg | grep -i federated$ db2 update dbm cfg using FEDERATED YES$ db2 get dbm cfg | grep -i federated Federated Database System Support (FEDERATED) = YES 2. Federation 을 구성할 DB 를 catalog 한다.◈ 카탈로그한 노드명 과 DB 명은 서버 생성시 사용하게 된다.- DB 카탈로그 구문- 노드 카탈로그 (인..
ICP(Index Condition Pushdown)는 MySQL이 인덱스를 사용하여 테이블에서 행을 검색하는 경우를 위한 최적화입니다. ICP가 없으면 스토리지 엔진은 인덱스를 탐색하여 기본 테이블에서 행을 찾아 행의 WHERE 조건을 평가하는 MySQL 서버로 리턴합니다. ICP가 활성화 된 상태에서 인덱스의 컬럼만 사용하여 WHERE 조건의 일부를 평가할 수 있으면 MySQL 서버는 WHERE 조건의 이 부분을 스토리지 엔진으로 푸시 다운합니다. 그런 다음 스토리지 엔진은 인덱스 항목을 사용하여 푸시된 인덱스 조건을 평가하며, 이 조건을 만족하는 경우에만 테이블에서 읽은 행이 됩니다. ICP는 스토리지 엔진이 기본 테이블에 액세스해야하는 횟수와 MySQL 서버가 스토리지 엔진에 액세스해야하는 횟수를..
이 최적화는 인덱싱되지 않은 열과 상수간 직접 비교의 효율성을 향상시킵니다. 이러한 경우 조건은 평가를 위해 스토리지 엔진에 "밀어 넣어집니다(pushed down)". 이 최적화는 NDB 스토리지 엔진에서만 사용할 수 있습니다. NDB 클러스터의 경우, 이 최적화를 통해 클러스터의 데이터 노드와 쿼리를 실행한 MySQL 서버 간에 네트워크를 통해 비매칭 행을 전송할 필요가 없으며, 조건 푸시다운이 가능하지만 사용되지 않는 경우보다 5~10배 빠른 쿼리를 수행할 수 있습니다. NDB 클러스터 테이블이 다음과 같이 정의되었다고 가정합니다.CREATE TABLE t1 ( a INT, b INT, KEY(a)) ENGINE=NDB; 조건(condition) 푸시 다운은 여기에 표시된 것과 같은..
◈ 기본 디렉토리 위치.Diag Path :DB2 Instance 환경정보(dbm cfg)에 보면 DIAGPATH 라는것이 있는데 이 위치에 로그 파일들이 적재된다.$ db2 get dbm cfg | grep -i diagDiagnostic data directory path (DIAGPATH) = /jhlee/jhlsle/sqllib/db2dump DasHome :Das는 별도의 인스턴스를 생성하므로 별도 디렉토리에 보관된다.DASHOME/das/dump 1. Administration notification log ("instance_name.nfy") : Diag Path▶ 운영체제 : 모두▶ 기본위치 : – Linux 와 UNIX: diagpath 데이터베이스 관리 프..