해결! DB D&A>> 온라인 서비스 기업을 위한 DB 운영 가이드 - 1

“내 DB 시스템에 나도 모르는 비밀이 숨겨져 있다!?”

북토피아는 국내 최대의 e-Book 서비스 업체로 온라인을 통한 고객 서비스가 가장 활발하게 이뤄지고 있다. 북토피아의 김용우 이사는

최근 임계점 이상으로 사용량이 늘거나 갑자기 DB 가 느려지는 현상이 발생함에 따라, 자사의 DB 가 가진 문제점을 전반적으로 점검할

필요성을 느꼈다. 이에 자사 DB 시스템을 전반적으로 점검 받고, 평소 3 가지 이슈사항을 해결하고자 DB D&A 의 문을 두드렸다. 약 5

시간에 걸쳐 진행된 방문 점검 결과, 악성 쿼리로 인한 디스크 병목 현상과 통계 업데이트가 미비했던 점 등을 추가로 파악할 수 있었다.

일시: 2007 년 7 월 20 일(금)

장소: 마포구 서교동 북토피아 본사(www.booktopia.com)

신청자: 기술그룹 김용우 이사(yongwoo@booktopia.com) / 기술본부

여진원(jin1y@booktopia.com)

전문가: 필라넷 성대중 책임 컨설턴트

요청사항

1. Lock 을 거는 SQL 문

- 간혹 lock 이 걸려서 DB 가 거의 정지되다시피 하는 경우 발생, lock 이 걸렸을 때 빠르게 문제가 되는 SQL 문을 찾아내는 노하우가

필요

2. xp_sendmail

- 매일 밤 돌아가는 배치 작업 중 전날 매출 현황 등을 xp_sendmail 시스템 프로시저를 이용해 메일로 보내주는 job 이 있는데,

네트워크에 문제가 생길 경우 xp_sendmail 이 실행되는 SPID 는 죽지도 않고 리소스만 잡아먹는 문제 발생, 네트워크 문제가 발생했을

때 xp_sendmail 이 에러를 내고 종료할 수 있게 하는 방안 필요

3. 사용하지 않는 테이블과 프로시저

- 필요할 때마다 만들다 보니 테이블 개수가 300 개 이상, 프로시저 개수는 800 개에 육박하고 있음, 더 이상 사용하지 않는 테이블이나

프로시저를 걸러 낼 수 있는 방안 필요

연재 순서

1 회 – 시스템 진단(백업 및 시스템 현황, 디스크 및 메모리 현황)

2 회 – 성능카운터 진단

3 회 – 악성 쿼리 튜닝

1 회 | 시스템 진단

자동 통계 업데이트의 허와 실

전문가: 시스템을 확인해보면, 현재 SQL 서버 2000 버전을 사용하고 있고, SP4(2039 버전)을 사용하고 있습니다. CPU 는 4 개를

사용하고 있으며, 메모리는 4GB 를 사용하고 있습니다. 4GB 는 어플리케이션과 OS 영역이 각각 2GB 씩 나눠서 사용할 것이기 때문에,

설정상 특별한 문제는 없을 것이고 향후 메모리를 증설하는 경우에는 2187 패치가 필요한 상황입니다. 현재는 AWE 옵션을 사용하고

있지 않지만, 향후 메모리 증설을 하는 경우, 2039 버전에서 AWE 옵션을 사용하면, 전체 메모리의 50%만 인식하는 버그가 있습니다.

메모리를 증설하실 것이라면, 2187 버전으로 패치해야 합니다.

신청자: 그럼 한참 패치가 안되어 있는 상황이네요?

전문가: 한참은 아닙니다만, 2187 버전으로 패치할 것을 권고합니다.

신청자: 네, 감사합니다. 시스템 신청자를 좀 갈궈야 하겠네요.(웃음)

전문가: SP4 에서는 SQL Server 옵티마이저에 많은 로직이 추가되었고, 그 외의 다른 버그에 대한 수정사항을 적용하기 위해서라도,

최신 패치(2187)를 설치할 것을 권고합니다.

--확인방법

select @@version

--실행결과

Microsoft SQL Server 2000 - 8.00.2039 (Intel X86) May 3 2005 23:18:38

Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition

on Windows NT 5.0 (Build 2195: Service Pack 4)

전문가: 그리고 CPU 4 개 사용하고 계셔서 특별한 이슈는 없는 상황이고요.

신청자: 메모리 추가를 했을 경우에, 성능 향상은 기대해볼 수 있는 상황인가요?

전문가: 만약 메모리가 부족하다면 그랬을 것이고요. 이슈 쿼리가 있기 때문에 메모리 증가를 해주면 디스크 성능의 향상은 있을

것입니다. 디스크 대기가 있고 메모리에도 이슈가 있다면, 근본적인 무거운 쿼리 해결이 급선무가 될 것이고요.

전문가: 데이터베이스 수가 많으시네요. 사전점검 템플릿 점검결과를 보내주신 자료를 보고 깜짝 놀랐는데, 애플리케이션에서 발생하는

에러를 SQL Server 에러 로그에 기록하는 것 같아요.

신청자: 그런 것들도 좀 있을 것입니다.

전문가: 만약 그렇다면 SQL Server 에러 로그 사이즈가 67MB 정도 되는데, 사이클링 하셔서 최소 단위로 줄여놓는 것이 좋지

않을까요? 중복된 에러가 많이 나타나는데, 이것을 굳이 에러 로그에다 기록해야 하는지. 애플리케이션에서 발생한 에러를 SQL Server

에러 로그에 기록하면, 그 양이 너무 많아서, 정말 심각한 오류를 찾기가 곤란할 수도 있어요. 필요한 경우 하루에 한번씩 사이클링을

하시면서 관리하셔도 될 것 같고요.

신청자: 지정해 하루에 한번씩 사이클링이 가능한가요?

전문가: 가능합니다.

신청자: 지금은 딱히 크게 만들려고 그런 건 아니고 그냥 기본 상태로 됐던 것뿐이거든요.

전문가: 4 월 6 일 이후, 지금까지 로그가 누적돼 있다 보니, 사이즈가 무척 커진 것 같아요.

전문가: 그리고 에러 로그에 특별한 이슈들이 있는지 확인하는 절차들은 필요한 것 같습니다. 그리고 각 데이터베이스 별로

데이터베이스가 꽤 많으세요. 데이터베이스 크기로 판단하면 주로 사용하는 데이터베이스는 databaseid 14번 데이터베이스인 것

같습니다.

신청자: 예. 그게 주라고 보시면 되겠습니다.

전문가: 서버 상태 모니터링은 어떻게 하고 계세요?

신청자: 서버 상태 모니터링은 시스템 관리 쪽에서 다른 서버들과 같이 하고 있거든요.

전문가: 지금 TEMPDB 에 대해서는 4 개로 나눠놓으신 것 같아요.

신청자: TEMPDB 는 기존에 C 드라이브에만 있다가 용량도 부족하고 그래서 다른 곳까지 늘려놨어요.

전문가: 늘려놓으신 상태인데, TEMPDB 를 구성하는 각 데이터 파일의 크기가 서로 상이하게 구성되어 있습니다. 이러한 경우에는

데이터파일을 분할한 효과를 제대로 사용할 수 없습니다.

신청자: 전혀 모르고 있었네요.

전문가: TEMPDB 의 데이터 파일을 4 개로만 나누기만 해서 성능에 도움이 되는 건 아니고요. 모두 동일한 크기로 만드셔야 합니다.

현재는 C 드라이브에 있는 첫번째 데이터 파일만 3GB 이고 나머지는 거의 사용이 안되고 있잖아요. 이렇게 되면 계속 첫 번째 데이터

파일만 증가가 될 거에요. 반드시, TEMPDB 의 각 데이터파일에 초기사이즈를 미리 지정해 주셔야 되고, 같은 크기로 4 개(CPU 4

개라면)의 데이터 파일을 만들어 주면 됩니다.

신청자: 근데 동일한 크기로 만들어도 쓰는 거는, 동일하게 쓰는 건가요?

전문가: 예, 4 개가 동시에 사용이 돼요. 근대 데이터가 마찬가지로 이 4 개가 동일한 크기로 사용이 되지 않으면 그때부터는 틀려지게

되거든요.

신청자: 아니면 C 에는 각종 윈도우에서 로그 같은 것들이니까, C 드라이브에 있는 데이터 파일을 다른 드라이브로 이동하는 것도

고려할 수 있겠네요?

전문가: 예, 상관없습니다.

전문가: 이제 TEMPDB 사이즈 사용된 것을 계산해보면, 전체 3GB 중에서 지금은 47MB밖에 사용하지 않고 계세요. 그래서 2번째, 3

번째가 사용될 수 있는 가능성은 없죠. 그래서 미리 4 개로 늘려 놓으면 충분하게 사용하실 수 있고 이게 적절한 사이즈니까 1GB짜리 4

개로 하시는 게 좋을 것 같아요.

전문가: 그 다음에 저희가 사전조사 드린 것 중에서 대용량 테이블 찾는 스크립트가 있었어요. 먼저 데이터베이스 크기부터

살펴보겠습니다.

데이터베이스 크기>

db_name data data_used data_f ree l og l og_used l og_f reewi sebook 28937. 6 28413. 1 524. 5 5662. 7 68 5594. 7wi sebook_ol d_data 21812. 2 21574. 8 237. 4 7. 4 1. 8 5. 6barobook 15440. 6 15162. 7 277. 9 1392. 1 32 1360. 1barobook_data 277. 8 258. 4 19. 4 285. 1 13. 7 271. 4wi sebook_processed 191. 3 174. 3 17 0. 7 0. 4 0. 3barobook_processed 18. 1 17. 3 0. 8 42. 2 7 35. 2webzi ne 6. 6 6. 2 0. 4 42. 2 7. 2 35

대용량 테이블>

tabl e rows(K)2 Reserved(KB) Data(KB) Used(KB) I ndex(KB)customer 4, 094 2, 910, 824 918, 288 2, 682, 368 1, 764, 080 royal t i es 3, 569 1, 549, 672 615, 480 1, 364, 048 748, 568 sel l _par t 7, 460 1, 743, 976 556, 296 1, 743, 784 1, 187, 488 member 4, 090 1, 251, 384 537, 008 1, 245, 792 708, 784 i d 4, 102 543, 760 287, 280 543, 496 256, 216 bookshel f 1, 859 673, 560 270, 128 475, 160 205, 032 mai l _fl ag 2, 970 533, 120 179, 992 530, 920 350, 928 eps_work_detai l 428 130, 344 54, 344 115, 344 61, 000 crm_sel l _hi story 942 92, 992 52, 184 91, 888 39, 704 phone_downl oad_hi story1, 009 134, 496 45, 744 133, 848 88, 104

전문가: 메인 DB 는 28GB 정도 되고, 현재 로그는 한 6GB 정도 사용하고 계시고, 데이터가 큰 사이즈들이 조금 있어요. 이런 부분에

대해서는 수동 통계 업데이트가 필요한 상황입니다. 지금 현재 통계 업데이트는 어떻게 하고 계신가요?

신청자: 따로 작업하는 거는 없는 걸로 알고 있어요

전문가: 백업은? 백업만 하고 계시네요. 트랜잭션 로그 백업은?

신청자: 매일 하루에 한번

전문가: 인덱스 최적화나 통계업데이트에 대한 보정작업이 데이터베이스 유지관리계획에 포함되어 있지 않습니다. 테이블에 저장된

행수가 많아지면 많아질수록 통계 업데이트가 될 수 있는 가능성은 그만큼 적어져요. 왜냐면 통계 업데이트는 전체 테이블에 저장된

행의 20%가 변경되어야지 통계 업데이트가 일어나거든요. 그러면 1000 행이면 20%면 200 행만 바뀌어도 되지만, 100 만행이 되면 20

만행이 업데이트 돼야지 통계 업데이트가 일어나기 때문에 데이터가 커지면 커질수록 통계 업데이트가 일어날 가능성이 적어져요.

그래서 그 부분에 대해서는 계속해서 통계 업데이트를 해줄 수 있도록 교정을 해야 됩니다.

전문가: 업데이트된 행 수를 확인하기 위해서는, ‘sysindexes’라는 시스템뷰의 내용을 살펴보면 됩니다. 예를 들어, customer 테이블의

경우 전체 약 400 만 건 데이터가 있습니다. 전체 이 400 만 건 중에 업데이트 된 게 현재 12 만 건 정도 있습니다. 통계 업데이트가

자동으로 발생하려면, 80 만 행이 업데이트 되어야 합니다. 이러한 문제 때문에, 상당히 오랫동안 통계 업데이트가 되지 않을 수 있고,

이렇게 오랫동안 업데이트되지 않은 통계로 인해 잘못된 실행계획이 수립되는 등의 문제가 발생할 수 있습니다. 통계 업데이트된

날짜를 확인하기 위해서는 STAT_DATE() 함수를 사용하면 됩니다. 확인한 결과, 통계 업데이트가 작년에 수행되고 현재까지 한 번도

업데이트되지 않은 테이블도 발견됩니다. 입력 후에 업데이트가 안 되는 이력 테이블이라면 상관없지만, 자주 사용하시는 테이블

중에서도 통계 업데이트가 안 된다면 분명히 문제가 발생할 가능성이 있습니다.

//

3 회에 나누어 연재됩니다.

앞으로 2 회 성능 카운터 진단 컨텐츠가 이어집니다.

해결! DB D&A>> 온라인 서비스 기업을 위한 DB 운영 가이드 - 2

“내 DB 시스템에 나도 모르는 비밀이 숨겨져 있다!?”

요청사항

1. Lock 을 거는 SQL 문

- 간혹 lock 이 걸려서 DB 가 거의 정지되다시피 하는 경우 발생, lock 이 걸렸을 때 빠르게 문제가 되는 SQL 문을 찾아내는 노하우가

필요

2. xp_sendmail

- 매일 밤 돌아가는 배치 작업 중 전날 매출 현황 등을 xp_sendmail 시스템 프로시저를 이용해 메일로 보내주는 job 이 있는데,

네트워크에 문제가 생길 경우 xp_sendmail 이 실행되는 SPID 는 죽지도 않고 리소스만 잡아먹는 문제 발생, 네트워크 문제가 발생했을

때 xp_sendmail 이 에러를 내고 종료할 수 있게 하는 방안 필요

3. 사용하지 않는 테이블과 프로시저

- 필요할 때마다 만들다 보니 테이블 개수가 300 개 이상, 프로시저 개수는 800 개에 육박하고 있음, 더 이상 사용하지 않는 테이블이나

프로시저를 걸러 낼 수 있는 방안 필요

연재 순서

1 회 – 시스템 진단(백업 및 시스템 현황, 디스크 및 메모리 현황)

2 회 – 성능카운터 진단

3 회 – 악성 쿼리 튜닝

2 회 | 성능 카운터 진단

디스크 병목 현상과 잠금의 상관관계

전문가: 이제 시스템 전반에 대해서 살펴보기 위해서 성능 카운터들을 살펴보려고 해요. 성능카운터 로그를 11 시부터 6 시까지 수집한

결과를 분석한 내용입니다.

전문가: CPU 를 보면 평균이 21%, 최대가 45%입니다. 평균 한 20% 정도 사용하고 계세요. SQL 서버 전용 머신에서 사용하고

계시니까, 전체 CPU 사용률 중 대부분을 SQL 서버에서 사용하는 게 맞고요. 메모리와 관련해서 1.7GB 정도 SQL 서버에서 사용하고

있고, 전체적으로 안정적으로 사용되고 있지만, 중간에 악성 쿼리로 인해서 메모리 중에서 전체가 비워지게 되는 경우가 발생하고

있습니다. PAGE LIFE EXPECTANCY 평균이 118밖에 안 되요. 최소 300 이상이 되어야 되거든요. 그러면 지금 메모리가 많이 모자라단

거에요. PAGE LIFE EXPECTANCY 의 단위는 초인데, 한번 데이터가 올라오면 300초(5분) 정도는 메모리에 머무를 수 있어야

메모리에 대기가 없는 건데, 지금은 애써 데이터를 가져오면 그걸 잠깐 쓰고 다음 번에 또 새로운 쿼리가 디스크로부터 또 다른

데이터를 가져와서 그 데이터를 갖다 퍼놓고 이전 데이터 올린 것은 또 쫓아내고, 그 다음에 또 다른 첫 번째 발생했던 쿼리가 다시

실행하면 두 번째 쿼리를 밀어내는 일들이 반복되는 거에요.

전문가: 디스크와 메모리에 관해서는 이슈가 있으신 상황입니다. 배치를 보면 초당 약 81 개의 쿼리가 실행되고 있어요. 그렇게

트랜잭션이 많은 시스템은 아닌데도 불구하고, 상황이 이렇다면 문제가 있다고 판단됩니다. 한 번 체크를 해보셔야 될 거 같습니다.

전문가: 지금 살펴본 것을 가지고 그래프를 그려보면 좀 더 명확하게 알 수 있는데요. CPU 를 보면 현재 빨간색이 토탈 평균은 20%

정도가 되요. 아침 10 시부터 저녁 6 시까지 하고, 오히려 저녁시간에 더 올라가서 지금은 딱 피크타임이 언제라고는 말하기는 어려운 거

같아요. 여기서 봐야 될 건 제일 중요한 건 CPU 평균 사용률이 50% 미만으로 안정적이지만 평균이 중간에서 계속 왔다갔다 거리고

있어요 이런걸 스파이크 현상이라고 하는데 이런 스파이크 현상이 발생하는 거는 이때 마다 CPU 를 올리게 하는 악성 쿼리들이 계속

발생하는 것이죠. 이런 상황은 계속 체크를 해서 튜닝을 해야 되는 상황이라고 판단됩니다.

<CPU 사용 현황>

전문가: 다음은 메모리와 관련된 성능카운터를 살펴보겠습니다. 버퍼캐치적중률(%) 평균은 99 인데 중간에 급격하게 떨어지는 부분이

문제가 됩니다. 이런 경우는 메모리에 있던 페이지를 모두 다 밀어내고, 새로운 데이터를 디스크로부터 메모리로 업로드해야 하기

때문에, 디스크 사용량과 메모리관련 대기가 발생할 수 있어서 성능에 악영향을 줄 수 있습니다. 역시 근본적인 원인은 이러한 대량의

IO 를 발생시키는 악성쿼리에 있으며, 해당 악성쿼리를 튜닝함으로써 문제를 완화할 수 있습니다.

<메모리 사용 현황>

전문가: 디스크 관련 성능카운터 수치를 살펴보겠습니다. 평균값은 안정적일 수 있지만, 중간중간 높은 값으로 치솟는 부분이 해당

시점에는 문제가 될 수 있습니다. 현재 디스크 시스템은 악성 쿼리 때문에 계속 이슈가 있는 상황이에요. 읽기 쓰기도 마찬가지고, 그

중에서 쓰기 보다는 읽기가 더 문제가 되고 있는 상황이에요.

<디스크 병목 현황>

전문가: 다음은 잠금과 차단에 대한 대한 진단내역입니다 파란색이 잠금이에요, 그리고 배치 요청는 80 회/초로 그리 높지 않은

상황입니다. 사용량이 많이 늘거나 줄거나 이런 건 아니고, 아침 10 시부터 저녁 6 시까지는 점심시간이 조금 줄기는 하지만 상당히 높은

잠금요청이 발생하고 있습니다. 컴파일은 전체 20% 정도 일어나고 있어요. 조금 더 낮출 필요가 있을 거 같고요. 잠금으로 봤을 때는

배치랑 거의 유사하게 진행되고 있지만 배치랑 상관 없이, 배치가 비슷한데도 불구하고 올라가는 경우에는, 악성 쿼리로 인해 문제가

발생하고 있다고 판단할 수 있습니다. 여기까지 살펴보면 될 거 같고요.

<배치 요청과 잠금 요청 현황>

전문가: 사전진단과정에서 수집한 11 시부터 30분간 데이터를 분석한 자료입니다. 30분간 15 만 건 정도에 쿼리가 실행되었습니다.

초당 약 86 회의 쿼리가 실행되었고. 평균 응답시간이 22 ms 이었어요. 이를 아래와 같은 그래프로 표시해 보면 전체 쿼리 중 약 5.25%

에 해당하는 악성쿼리가 논리적 읽기 기준으로 약 전체 리소스의 80.01 %를 점유하고 있는 것을 알 수 있고, 결국, 비교적 소수인

악성쿼리를 튜닝함으로써 전체 시스템의 성능을 개선할 수 있는 상황입니다.

<요청율과 점유율>

전문가: 문제의 원인이 되는 악성쿼리를 찾기 위해, 다음과 같은 쿼리 분포도를 그릴 수 있습니다. Y축은 논리적 읽기 수를 나타내고, X

축은 쿼리의 수행시간을 의미합니다. Y축의 수치가 높은 쿼리는 대량 IO 를 발생시켜서 메모리 및 디스크 리소스를 많이 소비하는

악성쿼리를 의미하고, X축의 수치가 높은 쿼리는 IO 는 많지 않으면서도 잠금 및 차단이슈로 인해 불필요하게 쿼리수행시간이 오래

걸리는 악성쿼리를 의미합니다.

<악성 쿼리 분포도>

전문가: 각 영역에 해당하는 쿼리를 찾아보면, 다음과 같이 정리할 수 있습니다. 각 리소스별로 악성쿼리 15 위가 나타나고 중복을

제거하고 정리해 보면, 아래와 같은 쿼리가 현재 시스템 리소스의 상당부분을 사용하는 악성쿼리로 정리할 수 있습니다.

Executes Avg Duration (ms)Avg CPU (ms)Avg Reads Example Query198 1,345 1,540 33,527 select top 5 MP.mp_m_id, MP.mp_m_nick, MP.mp_point,

I sNull(RI .mr_ id,20) from ssRedbookMemberPoint MP LEFT OUTERJ OIN ssRedbookRankInfo RI ON MP.mp_point betweenRI .mr_start_point and RI .mr_end_point where MP.site_ id='스서레드북' order by mp_point desc, mp_m_nick desc

988 100 46 5,930 exec pBookList NULL, 'registered_day', '신간', 'N'346 129 108 15,218 exec pCategoryI nfo 'A9', 'info', 'N', '북토피아'

9 1,121 977 488,033 exec pCySeriesSearchList '이민', '전체', '전체', '신상품순'38 156 129 43,510 exec pSktOrderI nfo '2007-07-01'80 221 142 19,585 exec pSeriesListByFlag 'PM01', null, '신규', 'Y', 5, 1

133 126 36 11,667 exec pThemeList 'e북메인테마', NULL, 'N'2 23,985 2,688 718,996 exec pCrmGiftTakeList '7C70282C-1659-47B0-A45E-

D5A4450AFBF6', NULL, '2007'53 88 61 24,882 select Top 5 subject, content, category from baroboard where

forum_id=3 and visible = 'Y' order by view_count desc2,579 20 16 477 exec pMdChoiceBookList 'ebook', 'Baro_새내기 ', NULL, NULL

신청자: 고맙습니다.

전문가: 여기까지가 간단하게 분석작업을 한 것입니다. 이제 원인들을 아셨으니까 원인들을 해결하는 작업들을 하면 되겠죠.

신청자: 몇 개 조금 걱정되는 부분들도 있었는데, 괜찮을 거라고 생각했던 부분들까지도 문제가 있었네요 사실은 이런 것 같은 경우는

뭐라고 해야 되나요. 저희가 개발한 부분도 아니고 저희가 건드릴 수 있는 부분도 아니어서, 다소 어려운 점도 있는데, 이런 것들은

저희가 한 건데, 드릴 말씀이 없는 그런 것들도 있네요.

전문가: 문제의 원인을 찾아낸 것만으로도 충분한 의미가 있습니다. 앞으로 계획을 세우셔서 발견된 문제를 하나하나 해결하시면

도움이 되실 것입니다.

//

3 회에 나누어 연재됩니다.

앞으로 3 회 악성 쿼리 튜닝 컨텐츠가 이어집니다.

잠금 및 차단 문제

대량 I/O 문제

해결! DB D&A>> 온라인 서비스 기업을 위한 DB 운영 가이드 - 3

“내 DB 시스템에 나도 모르는 비밀이 숨겨져 있다!?”

요청사항

1. Lock 을 거는 SQL 문

- 간혹 lock 이 걸려서 DB 가 거의 정지되다시피 하는 경우 발생, lock 이 걸렸을 때 빠르게 문제가 되는 SQL 문을 찾아내는 노하우가

필요

2. xp_sendmail

- 매일 밤 돌아가는 배치 작업 중 전날 매출 현황 등을 xp_sendmail 시스템 프로시저를 이용해 메일로 보내주는 job 이 있는데,

네트워크에 문제가 생길 경우 xp_sendmail 이 실행되는 SPID 는 죽지도 않고 리소스만 잡아먹는 문제 발생, 네트워크 문제가 발생했을

때 xp_sendmail 이 에러를 내고 종료할 수 있게 하는 방안 필요

3. 사용하지 않는 테이블과 프로시저

- 필요할 때마다 만들다 보니 테이블 개수가 300 개 이상, 프로시저 개수는 800 개에 육박하고 있음, 더 이상 사용하지 않는 테이블이나

프로시저를 걸러 낼 수 있는 방안 필요

연재 순서

1 회 – 시스템 진단(백업 및 시스템 현황, 디스크 및 메모리 현황)

2 회 – 성능카운터 진단

3 회 – 악성 쿼리 튜닝

3 회 | 악성 쿼리 튜닝

쿼리 수정으로 최대 490%의 성능 향상

신청자: 아까 문제가 되는 SQL 문 찾아내는 것, 무엇으로 하셨나요?

전문가: 예, 분석하는 도구가 있어요. RML 이란 도구가 있고, 저희가 결과 보고서에 같이 드릴 거에요. 저희가 템플릿 드린 걸로 30분간

수집하고 그것을 갖고 돌리면 이런 결과들이 만들어져요.

신청자: 프로필러 때문에 시스템 부하가 많이 늘어나고 그렇지는 않습니까?

전문가: 예, 프로필러가 분명히 영향을 주긴 합니다. 그래서 필터를 잘 해야 되고 아주 사용량이 많은 시스템, 예를 들어 계속 CPU

사용률이 90% 이상인 상태에서 프로필러를 걸면 문제가 될 수 있어요. 특히 프로필러 UI 로 추적을 설정한 경우에는, 분명히 성능에

영향을 주게 되어서, 가능하다면 스크립트 기반으로 추적 작업을 설정할 것을 권고합니다.

#사례 1 – 선택성이 없는 검색조건과 인덱스가 없는 칼럼 기준으로 정렬하는 쿼리

전문가: 전체 30 만 건 정도의 데이터가 있는데 그 중에 보면 사이트 넘버가 딱 2 개 밖에 없어요. 그래서 I/O 가 많이 발생하고 있어요. 3

만 페이지의 I/O 가 발생하네요. Top 5 를 찾기 위해서 결국은 6000페이지 정도의 데이터를 읽어서 처리하고 있기 때문에, 이를 처리할

수 있는 인덱스가 필요한 상황이에요. 지금 만들어 놓은 인덱스는 사용될 수 있는 가능성이 거의 없는 인덱스 같아요. 값이 2 개밖에

없기 때문에 선택성이 없는 거죠.

신청자: 그런 경우에는 안 만드는 게 차라리 낫나요?

전문가: 예, 안 만드는 게 낫죠.

신청자: 데이터가 변경될 때 인덱스까지 같이 변경해야 되는 그런 부담 때문에 그런가요?

전문가: 예, 그런 부담은 없어지겠죠. 그냥 Top 해서 가져오는 것이라면 상관없지만 마찬가지로 적절한 인덱스가 없는 상태에서는

ORDER BY 절의 칼럼을 기준으로 다시 정렬해야 하기 때문에, 과도한 IO 를 발생하게 됩니다. 필요하다면, 정렬조건에 해당 하는

칼럼에 인덱스를 추가하는 것이 도움이 될 수 있습니다.

#사례 2 – 대량 IO(40 만페이지이상)를 발생시키는 쿼리, %% 검색은 검색엔진으로 전환

전문가: 대량 IO 를 발생시키는 pSeriesSearchList 저장 프로시저를 살펴보겠습니다.

신청자: 예

전문가: 문제의 원인은 검색조건이 되는 칼럼에 %% 검색을 하기 때문에 과도한 IO 가 발생하게 됩니다. 가능하다면, %% 검색을 %

검색으로 변경할 수 있는지 여부를 고려하셔야 합니다. 현재 검색엔진을 사용하고 있다면, 이러한 쿼리는 가능한 검색엔진에서

처리하는 것으로 전환하는 것이 필요하다고 판단됩니다.

where (s.title like '%' + @search_word + '%'

or author like '%' + @search_word + '%'

or c.name like '%' + @search_word + '%' )

and class = @class

and sell_flag = 'Y'

전문가: 대량 I/O 를 발생시키는 쿼리에 대해서 분석할 때는, SET STATISTICS IO ON 설정을 한 상태에서, 쿼리를 실행하고, 각 쿼리 중

가장 많은 I/O 가 발생하는 쿼리 부분을 찾아서 점검하는 것이 좋은 방법이 될 수 있습니다.

#사례 3 – 동일한 테이블에 여러 번 액세스하여 집계하는 쿼리

전문가: sell 테이블에 family_site_id 를 기준으로, 각 구분값에 따라 별도의 계산값을 집계하기 위해서, 5번 쿼리하고 있음을 확인할 수

있습니다. 각 쿼리의 실행계획을 점검해 보면 sell 테이블에 대해서 Index Seek 를 제대로 하고 있지만, 문제는 똑같은 테이블에 대해서

여러 번 반복해서 액세스를 하고 반복적인 IO 가 발생하는 것이 문제입니다. SQL Server 2005 에서는 PIVOT 이라는 연산자를 통해

처리할 수 있지만, 현재는 SQL Server 2000 버전을 사용하고 있음으로, SELECT 와 CASE 를 사용하여 PIVOT 을 구현하면, 현재의 약

1/6 수준의 IO 만으로도 동일한 쿼리를 수행할 수 있습니다.

select

sum(case when family_site_id= 'AAA' then paid_amount else 0 end)

,sum(case when family_site_id= 'BBB' then paid_amount else 0 end)

,sum(case when family_site_id= 'CCC' then paid_amount else 0 end)

,sum(case when family_site_id= 'DDD' then paid_amount else 0 end)

,sum(paid_amount)

from sell

where paid_day >= '2007-07-01'

and paid_day < '2007-07-02'

(중간생략)

개선 결과)

신청자: 성능이 정말 개선되네요. 끝난 후에 전체적으로도 한 번 점검해 봐야겠네요.

알아두어야 할 SQL 상식 #1 인덱스를 사용하는 선택성의 범위는?

신청자: 데이터가 많을 경우. 선택성이 있다고 보려면 어느 정도이어야 하는 건가요?

전문가: 일반적으로 업무 특성에 따라서 모두 다른데요. 그 인덱스를 쓰는 경우 통상 2% 정도 밖에 안되거든요. 2% 미만이 되야

하거든요. 물론, 데이터에 따라 다를 수 있고, 커버된 인덱스가 되는 경우는 달라질 수 있지만, 무조건 인덱스를 추가하는 것보다는

의미있는 검색조건이 되는 칼럼에 인덱스를 추가해야 쿼리의 성능에 도움이 될 수 있습니다. 앞에서 언급한 것처럼, 선택성이 없는

검색조건에는 아무리 많은 인덱스를 만들어 놓는다고 하더라도, 성능에 도움이 되지 않고, 오히려 인덱스 유지보수의 비용이 가중되는

악영향을 미칠 수 있습니다.

알아두어야 할 SQL 상식 #2 저장프로시저화와 컴파일 문제

신청자: Adhoc 쿼리를 저장 프로시저로 전환하면 성능에 도움이 되나요?

전문가: 저장 프로시저로 만들면 저장 프로시저에 계획을 재사용할 수 있는 거에는 분명히 성능에 도움이 됩니다. 하지만, 예외적으로,

매개변수에 따라 선택성이 달라지는 경우에는 실행계획을 재사용하는 것이 문제가 될 수 있습니다. 예를 들어, 선택성이 높은

매개변수로 최초 실행된 경우, 저장 프로시저의 실행계획이 해당 매개변수에 최적화되어 프로시저 캐시에 등록되게 됩니다. 이러한

상황에서 선택성이 낮은 매개변수가 입력되면, 프로시저 캐시에 등록되어 있는 해당 저장 프로시저의 실행계획을 재사용하기 때문에,

잘못된 실행계획을 사용하여 오히려 더 문제가 될 수 있습니다.

신청자: 그런 경우는 실행할 때마다 컴파일 계획을 새로 생성하게 하는 옵션도 있던데, 그렇게 하는 게 더 나을 수 있다는 건가요?

전문가: 예, 그런데 이게 얼마만큼 자주 실행되느냐에 따라서 다르죠. 만약 1초에 한번씩 실행된다면 매번 컴파일하게 한다면, 그건 안

좋은 경우라고 볼 수 있고요. 이러한 경우, 프로시저를 매개변수에 따라 하위 프로시저로 분리하거나, 동적 쿼리화를 통해 문제를

해결할 수 있습니다.

알아두어야 할 SQL 상식 #3 통계업데이트의 기준

전문가: 통계 업데이트를 수동으로 보정해 주시거나 데이터베이스 유지관리 계획의 일부로 통계 업데이트 작업을 수행하시나요?

신청자: 데이터베이스 옵션에 자동 통계 업데이트로 설정해 두었는데, 그래도 통계 업데이트를 별도로 수행해 주어야 하나요?

전문가: 예 그렇습니다. 일반적으로 자동 통계 업데이트는 테이블의 데이터 중 20%가 변경되어야만 업데이트됩니다. 테이블이

대용량이 될수록 발생할 가능성은 더욱 낮아지게 됩니다. 예를 들어, 1000건의 데이터 행이 있는 테이블의 경우 200건의 데이터만

변경되어도 통계업데이트가 발생하지만, 1000 만 건의 데이터 행이 있는 테이블의 경우 200 만 건의 데이터가 변경되어야

통계업데이트가 발생합니다. 보시는 것처럼, 대용량 테이블의 인덱스에 대한 통계 중, 2007 년도 2 월 27 일 통계가 업데이트되고

아직까지 수 개월 동안 통계 업데이트되지 않은 상태의 통계도 있음을 확인할 수 있습니다. 이러한 상태에서 최근 데이터를 찾게 되면,

테이블에는 실제로 데이터가 존재함에도 불구하고, SQL Server 에서는 통계에 해당 데이터에 대한 통계가 업데이트되어 있지 않기

때문에, 데이터가 없는 것으로 판단하여 잘못된 실행계획을 생성하게 됩니다.

전문가: 운영자로서 해야 되는 것 중에 ‘SP_Updatestat’이라는 명령이 있어요. 이것을 그냥 데이터베이스마다 야간시간에 사용 안 할 때

한번씩 돌려주면 돼요. 하루에 한번 아니면 일주일에 한번 정도 돌려주면 이런 문제들이 안 생기겠죠. 쿼리를 잘 작성하셨고 잘 되어야

되는데 안 되면 억울하잖아요.

신청자: 통계 업데이트 그런 것은 전에는 그냥 알아서 되겠지 했었는데, 정말 많이 도움이 된 것 같습니다.

전문가 총평

DB D&A 프로그램의 기본취지는 현재 시스템에 대한 상태를 점검하고, 이에 대한 개선방향 및 가이드라인을 제시하는 것에 있습니다.

현장 방문을 통해 권고 드린 튜닝 적용안에 대한 적용 및 어플리케이션 코드 수정 작업이 진행되어야 합니다. 그 외에 추가적인

상세진단을 통해, 어플리케이션, 모델링, 운영 측면에 대한 점검이 필요한 상태로 판단됩니다. 현재 존재하는 악성쿼리에 대한 문제에

대해 좀 더 상세한 수준의 튜닝작업을 위해서는 전문 튜닝 컨설팅을 받는 것도 고려해 보실 수 있겠습니다. 또한 SQL Server 전문교육을

통해 담당 엔지니어에 대한 교육훈련도 고려해 보셔야 합니다.

추가 점검이 필요한 사항

<성능 측면>

- 인덱스 전략의 검토

- 악성쿼리의 튜닝

: 오래된 통계정보로 인한 잘못된 실행계획

: 검색엔진용 쿼리(pCySeriesSearchList)

: 동일한 테이블에 반복적으로 접근하는 쿼리

- 인덱스 전략의 검토

<어플리케이션 측면>

- Data Access Layer 코드의 진단

- 서버측 커서를 사용하는 코드의 진단

<모델링 측면>

- 클러스터형 인덱스의 길이 너무 긴 테이블

- Page Split 현상의 발생

<운영 측면>

- 백업 및 복원 정책

- 인덱스 최적화 정책

- 통계 업데이트 정책

이 문서 포함된 내용에 대한 추가적인 질문이나 의문사항은 필라넷 성대중 책임(djsung@feelanet.com)에게 메일로 연락을 주시기

바랍니다.

주의) 이 문서에 포함된 내역은 DB D&A 프로그램의 고객사의 담당자에게만 제한적으로 공개된 내용입니다. 이 문서에 포함된 내역은

타인 또는 외부에 임의로 배포되거나 게시될 수 없음에 유의하여 주시기 바랍니다.