2004/01/07

성능을 위한 SQL 튜닝 점검사항

1. Application에서 select ... 처럼 직접 쿼리문 대신에 SP를 이용한다.
저장프로시져의 경우 DB에서 컴파일되서 수행되기 때문에 직접쿼리보다 성능효과가 있다.

2. Select * from 테이블 보다는 Select a,b,c,e.... from 테이블 과 같이 필드명을 직접 기입한다. 불필요하게 모든 레코드를 불러올 필요는 없다.

3. 적절한 index를 구축한다.
특히 select 가 많은 OLAP 환경에서는 적절한 index는 많은 성능향샹 효과를 가져온다. 그러나 update가 많은 DB의 경우 잘못된 index구축으로 인해서 오히려 성능 저하를 가져올수 있다.

4. 일부 쿼리문의 경우 강제로 index를 타게 한다.
ex, select a from table (index indexname)
일부 쿼리문의 경우 index를 타지 않을경우 테이블스캔을 한다. 그러나, 특정 index라도 타게하면 테이블스캔을 할 부분이 적어진다. 물론 강제 index에도 없다면 당연히 테이블 전체 스캔을 하겠지만....

5. Application쪽에서 불필요하게 중복쿼리를 하는지 점검한다.
불가피하게 여러번 쿼리가 필요하더라도, SQL서버쪽에서 SP를 통해서 1번만 쿼리를 하는것이 좋다. 특히, DB서버와 Application서버가 네트웍으로 연결된 환경일경우...

6. 되도록이면, join 사용은 자제한다.
정규화와 역정규화시 쿼리비용을 점검하여 쿼리비용이 최소화 되는 방향으로 한다. 무조건 테이블 정규화가 좋은것은 아니다. DB사이즈가 커지더라도 성능위주로 하는 것이 좋다(요즘은 디스크가 저렴하기 때문...)

7. Top을 이용한다.
Application에서 실제 화면에나, 연산에 필요한 레코드외는 쿼리하지 않는 것이 좋다. 일부 레코드를 위해 테이블 전체 레코드를 가져오는 것은 DB서버쪽에 로드도 있긴하지만 Application 서버쪽 메모리를 특히 많이 소비한다.

8. Table 또는 DB의 특정값을 쿼리하는 경우 systemtable에서 제공하는 값을 이용한다.
systemtable의 경우 DB에 대한 시스템값을 저장하는 테이블로서 직접테이블에서 쿼리를 하는 것보다 systemtable에서 쿼리하는 경우가 빠를수 있다. 그러나, MS에서는 이부분에 대해서 권장하지는 않는다고 한다...

9. 쿼리문 작성후, 쿼리분석기에서 staticstics 를 점검해 본다.

10. 최신 MDAC를 이용한다.
DB서버와 Applicaton서버쪽에 안정화된 최신 MDAC으로 업그레이드 한다. 되도록이면 DB와 App서버의 MDAC버젼을 일치시키는 것이 좋다.

11. DB와 LOG저장 I/O를 분리를 하는것이 좋다


위 사항은 일반적인 점검사항이며, 모든 DB에 해당하는 것은 아니다. 특정 DB의 경우 프로필러를 이용해서 DB 및 시스템의 퍼포먼스 카운터를 점검해야 한다.



07-TechNetB_masthead_ltr.gif

댓글 없음:

댓글 쓰기

가장 많이 본 글