574
yesterday 4,212
visitor 24,395,680
3

몇년 전부터 나의 고민은 DB 성능 향상에 대한 것이였다


인덱스 튜닝을 하고 난 후 3개월 정도(나의 경우에 그랬다)만 지나면 튜닝 전의 문제점들이 도출될 뿐만 아니라 더욱 심각한 사태가 벌어져서 난감하였던 것이다.

 

이제부터 나의 경험담을 담은 DB 튜닝 Tip에 대해서 알려 드리고자 한다.

 

난 DB 컨설턴트는 아니지만 튜닝에 관한 부분에서 우리 회사의 DB에 대해서는 감히 자신있다고 말하고 싶다(그냥 말하고 싶은 것이지 누구보다 잘한다는 의미는 아니다.)

 

우선 DB 튜닝에 대해서는 난 잘 모르겠다고 생각하시는 분들과  인덱스를 어떻게 튜닝하는지는 더욱 모르겠다고 하시는 분들에게 유용할 것으로 생각되는 것에 대해서 말하고자 한다

 

해당 내용은 외부 자료에서 논의되었을 수도 있다

 

나도 예전에 DB 튜닝 세미나에 가보면 이런 이야기를 하는 분들을 보곤 했으니 말이다

 

암튼 이 글은 그런 내용들 뿐만 아니라 내가 직접 경험한 부분에 대해서 감히 말하고자 한다.(주의: 나의 경우에는 맞지만 다른 분들에게는 안 맞을 수도 있음)

 

1. DB 서버 상태 확인 (튜닝 전과 튜닝 후의 성능을 평가하기 위해서)
 - 성능 모니터링을 사용해서 하루치에 대한 CPU 상태 등을 알아봐야 함 

 - 위의 방법 외에 본인이 확인 할 수 있는 자료만 나오면 됨

 - 반드시 아래의 튜닝 전에 하루치를 받으시고 튜닝 후에 하루치를 받아야만 비교가 됨


2-1. DB REINDEX 실시 (방법1)
 - 쿼리 : DBCC DBREINDEX (테이블명,,채우기비율)
   ex) DBCC DBREINDEX (T_table, ,80) - T_table의 모든 인덱스를 채우기 비율(Fillfactor) 80% 로  재작성하라는 의미임

 - 만약 Fillfactor 를 이전에 지정하지 않았다면 채우기비율을 "0"으로 셋팅하면 됩니다. 괜히 채우기 비율 지정했다가 낭패를 보는 수가 있으니깐요..ㅎㅎ

 - 장점 : 경험상 아래 (방법2) 보다 성능상 더 좋음
 - 단점 : 테이블에 LOCK을 발생시키므로 온라인 상에서 하기에는 부담이 온다(최대한 사용자가 적을 때 사용해야 함)


2-2. DB REINDEX 실시 (방법2)
 - 쿼리 : DBCC INDEXDEFRAG (DB명,테이블명,인덱스명)
 - 장점 : 온라인 상태에서 테이블에 LOCK을 발생시키지 않고 실시 가능

 

3. 통계 업데이트 (테이블이 가지고 있는 인덱스 필드의 통계치를 말합니다)
 - 쿼리 : UPDATE STATISTICS 테이블명

 

이상은 간단하게 DB 튜닝하는 방법에 대해서 말씀드렸습니다.

 

이 방법은 가급적이면 야간에 하시는 것이 좋으며 통계 업데이트의 경우 아마도 다른 튜닝을 하지 않으셨다면 DB 속성에 통계 자동 갱신이 "자동"으로 되어져 있을 겁니다.

 

하지만 자동으로 되어져 있다고 해도 하루에 한번 정도는 SP를 작성해서 매일 돌리는 것도 방법일 것으로 생각합니다.(실제로 저희 회사에서는 이렇게 처리를 하고 있습니다 - 새벽에 실시)

 

만약 DB를 생성한 후 한번도 튜닝을 하지 않으셨다면 위의 간단한(?) 작업만으로 성능을 개선할 수 있을 것으로 생각됩니다.

 

아 그리고 위의 튜닝은 튜닝 중에 가장 기본적인 사항을 적어 놓은 것이니 너무 맹신하지 마시고 다른 튜닝(INDEX 및 Query 튜닝)에 대해서도 공부하시고 열심히 적용해보시기 바랍니다.

 

끝까지 읽어주셨어 감사합니다.

 

 

 

 

출처 : http://kin.naver.com/open100/detail.nhn?d1id=1&dirId=10205&docId=809778

 

 

'헬로마켓'과 함께하는 스마트한 중고 아이템 거래

https://www.hellomarket.com

문서 첨부 제한 : 0Byte/ 2.00MB
파일 제한 크기 : 2.00MB (허용 확장자 : *.*)
List of Articles
번호 제목 글쓴이 날짜 조회 수sort

Program Note 로그인 :)