SI프로젝트로 시스템을 납품했다. 그런데 고객이 시스템이 느리다고 VOC가 발생한다.
운영시스템의 코드를 열어봤다. 제 3자인 나는 알아보기 힘들었다.
쿼리를 분석해봤다. 쿼리가 테이블 전체를 조회하게 설계되어 있다. 이것 때문에 시스템이 느려졌다.
무언가 이상하지 않은가? 시스템이 느려진 것이 막연하게 쿼리 문제로 치부되는 것은 참 어색한 일이다.
반대로 생각해보면 시스템 구축 진행 시 왜 이런 문제를 예상하지 못했던가?
쿼리 튜닝했음에도 불구하고 동일한 문제가 발생하면 어떻게 이애할 것인가?
아마도 프로젝트 팀 구성이나 수행 전략, 정책 등이 미진하고 제시된 가이드를 준수하지 않았을 것이다.
원론적인 문제로 들어가면 글이 엄청 길어질 것으로 보여 우선 각설한다.;;
여튼 문제 해결을 위해 여러가지 방법을 확인해보았다.
우선 테이블 Full Scan만 잡아내는 도구는 없다. 일반적으로 최적화라는 이름으로 서비스되고 컨설팅되고 있다.
쿼리 무식자들에게는 희망과 같은 이야기겠지만, 이런 비즈니스가 발생한 배경에는 아마도 SI 프로젝트에서 주먹구구로 납품위주로 작업한 것에 대한 한계라고 봐도 무방할 것 같다.
출처: http://dba.stackexchange.com/questions/74261/optimize-the-query-with-big-and-low-cardinality | When the Optimizer Considers a Full Table Scan The most important factor in choosing depends on speed. This means that a full table scan should be used when it is the fastest and cannot use a different access path. Several full table scan examples are as followed.
|
출처: 위키피디아
우선은 시스템 개발을 탓해야 겠지만... 품질 관점에서 분명이 점검이 필요한 상황이다. 하지만, 현실이 따르지 못하는 것은 함정이라고 할 수 있겠다.
Writen By 밤의카사노바
'& Develop > DB 스터디' 카테고리의 다른 글
DMBOK 2.0 정리 (0) | 2017.06.02 |
---|---|
정보시스템 성능관리 - 용어정리 (0) | 2017.04.17 |
댓글