https://www.slideshare.net/ienvyou/day-2-mysql-tuning-replication-cluster
[오픈소스컨설팅]Day #2 MySQL Tuning, Replication, Cluster
MySQL 최적화 ㅇ 최적화 간략 소개 ㅇ 파티셔닝 ㅇ Thread pool ㅇ 테이블 유지보수 ㅇ 테이블 검사, 최적화, 복구 MySQL Replication ㅇ Replication 소개 ㅇ Replication 구성방법 ㅇ Replication tuning 방법 …
www.slideshare.net
http://databaser.net/moniwiki/wiki.php/%EC%A0%95%EA%B7%9C%ED%99%94%EC%9D%98%EC%9D%B4%ED%95%B4
3차 정규화
한 엔티티 안의 모든 주식별자가 아닌 속성들은 주식별자에 의존해야 한다. 속성에 종속적인(이전종속) 속성이 있다면 분리해야 한다.
고객번호 --> 수출여부 + 사업자번호+우선순위 종속적이다.
3차 정규화하면
3차 정규화 다른 예
모 프로젝트에서 개발자들로부터 튜닝 요청받은 쿼리 중에서 가장 많은 패턴중 하나가
아래와 같이 select target 절에 사용자 함수를 사용한 경우임.
사용자 함수를 함부로 사용하지 못하도록 프로젝트 시작시 rule 을 만들어야 하는 게 아닌가 할 정도로 SQL 성능 저하의 주요 원인 중 하나였음.
DB : tibero
1. 유형
사용자 함수를 아래와 같이 select 절에 사용하는 경우임.
select
....
, JISA_NAME( A.JISA_code ) 지사이름
....
from 자금지원이력 A
where A.기간 between sysdate -10/24/60 and sysdate
group by A.region
2. 병목 원인
* 사용자 함수는 recursive call 로 느림
* 최종 결과 건수에 상관없이 조건절에 부합하는 전체 레코드 건수 만큼 함수 호출이 발생함.
3. 튜닝방법
1) 최종 결과 집합에서만 함수 호출이 일어나도록 하는 방법
select
...
, JISA_NAME( jisa_code ) 지사이름
from (
select /*+ no_merge */
A.region
, A.jisa_code
....
from 자금지원이력 A
where A.기간 between sysdate -10/24/60 and sysdate
group by A.region
)
2) decode 함수 또는 case 문으로 변환
함수 로직이 계산식이 주일 경우
3) 함수를 풀어서 inner join 또는 outer join 으로 변경
select
B.JISA_NAME
from 자금지원이력 A, 지사이름 B
where A.jisa_code = B.jisa_code
and A.기간 between sysdate -10/24/60 and sysdate
group by A.region
4) 스칼라 서브쿼리 캐싱 효과를 이용
oracle 은 select 함수명 from dual 구문으로 호출하면 서브쿼리 캐싱 효과를 얻을 수 있음.
tibero 의 경우는 from dual 구문을 사용하지 않아도 plan 상으로는 sub쿼리 caching 표시가 되나 실제도 캐싱되는지는 확실하지 않음.
oracle 과 동일하게 구현되었다면 from dual 구문을 사용하면 성능 효과를 볼 수 있을 듯 하다.
함수의 결과값의 종류가 적을 때 사용가능하다.
from (
select /*+ NO_MERGE */
( select JISA_NAME(A.JISA_code ) from dual ) 지사이름
.....
5) Deterministic 함수로 캐싱 효과
오라클에서 지원함.
함수 생성시 deterministic 구문 명시하면 서브쿼리 캐싱 효과를 낼 수 있음.
함수 생성시
create or replace funciton JISA_NAME( p_jisacode varchar ) return varchar DETERMINISTIC
...
| 선택적 검색 조건에 사용할 수 있는 기법 (0) | 2018.05.01 |
|---|
1. 전체적인 lock 대기 상황 모니터링 쿼리
2. 현재 유저의 lock 상태 조회쿼리
| snapshot too old 발생 가능성을 줄이는 법 (0) | 2018.07.27 |
|---|---|
| 오라클 데이타 export script (0) | 2018.07.09 |
| 세션 커서 캐시 히트율(Hit Ratio)을 구하는 쿼리 (0) | 2018.05.01 |
| dictionary table 종류를 검색하는 쿼리 (0) | 2018.05.01 |
| v$sql 을 사용해서 전체 시스템의 쿼리 수행 통계정보를 조회하는 쿼리 (0) | 2018.05.01 |
1. 불필요하게 커멋을 자주 수행하지 않는다.
2. fetch across commit 형태의 프로그램 작성을 피해 다른 방식으로 구현한다. ANSI
표준에 따르면 커맛 이전에 열려 있던 커서는 더는 Fetch 하면 안 된다. 다른 방식으
로 구현하기 어렵다면 커빗 횟수를 줄여본다.
3. 트랜잭션이 몰리는 시간대에 오래 걸리는 쿼리가 같이 수행되지 않도록 시간을 조정
한다.
4. 큰 테이블을 일정 범위로 나누어 읽고 단계적으로 실행할 수 있도록 코딩한다.
Snapshot too old 발생 기능성을 줄일 뿐 아니라 문제가 발생했을 때 특정 부분부
터 다시 시작할 수도 있어 유리하다. 물론 그렇게 해도 읽기 일관성에 문제가 없을
때에만적용해야한다
5. 오랜 시간에 걸쳐 같은 블록을 여러 번 방문하는 Nested Loop 형태의 조인문 또는
인텍스를 경유한 테이블 액세스를 수반하는 프로그램이 있는지 체크하고， 이를 회피
할 수 있는 방법(조인 메소드 변경， F비I Table Scan 등)을 찾는다.
6. 소트 부하를 감수하더라도 order by 등을 강제로 삽입해 소트연산이 발생하도록 한
다. 많은 데이터를 오랜 시간에 걸쳐 Fetch 하는 동안 Undo 정보를 지속적으로 참
조하기 때문에 문제가 발생하는 것이므로， 서버 내에서 빠르게 데이터를 읽어 Temp
세그먼트에 저장하는 데에만 성공하면 이후에는 같은 블록을 아무리 재방문하더라
도 더는 에러가 발생할까 걱정하지 않아도 된다.
7. 만약 delayed 블록 클린아웃에 의해 Snapshot too old가 발생하는 것으로 의심되면
대량 업데이트 후에 곧바로 해당 테이블에 대해 Full Scan 하도록 쿼리를 날리는 것
도 하나의 해결방법이 될 수 있다
sel ect 1*+ ful l(t) *1 count(* ) from table name t
| lock 모니터링 쿼리 (0) | 2018.07.30 |
|---|---|
| 오라클 데이타 export script (0) | 2018.07.09 |
| 세션 커서 캐시 히트율(Hit Ratio)을 구하는 쿼리 (0) | 2018.05.01 |
| dictionary table 종류를 검색하는 쿼리 (0) | 2018.05.01 |
| v$sql 을 사용해서 전체 시스템의 쿼리 수행 통계정보를 조회하는 쿼리 (0) | 2018.05.01 |
| Altibase 용 모니터링 script (0) | 2018.06.06 |
|---|
