이제 갓 입사한 신입 사원이라면 누구나 10년 후엔 자신이 몸담은 분야의 최고 전문가가 되길 꿈꿀 것이다. 본인도 그런 마음으로 데이터베이스 분야에서 10년 넘게 근무하고 있다.
10년이 넘는 시간 동안 데이터베이스 관련 많은 프로젝트에 참여했으며, 데이터베이스만을 생각하며 하루를 보낸 적도 많다. 또한 데이터베이스 관련 작업을 수행하면서 또는 데이터베이스 관련 서적을 공부하면서 밤을 샌 적도 많다.
다른 분야도 마찬가지이지만 데이터베이스 업무를 접했거나 공부해 본 사람이라면 데이터베이스가 얼마나 매력적인지를 느낄 수 있었을 것이다.
전문 DBA가 많지 않은 우리나라의 현실을 감안해, 많은 사람들이 해보고 싶어 하는 전문 DBA가 무엇인지 그리고 전문 DBA 가 수행해야 할 일에는 어떤 것들이 있는지 지난 시간에 이어 함께 이야기해 보자.
또한 전문 DBA가 되기 위해 준비해야 할 사항에 대해서도 같이 이야기해 보자.
계속적인 데이터의 증가로 대부분의 시스템들은 대용량화되고있으며 많은 기업에서는 데이터베이스의 성능을 핵심 요소로 인식하게 되었다. 이는 데이터베이스 성능이 고객 불만을 발생시킬수 있어 장기적으로 기업의 성패를 좌우할 수 있기 때문이다.
시스템을 운영하면서 성능 저하를 피부로 느끼지만 실제 무엇이 문제인지를 인식하는 사람이 거의 없다. 비록 문제를 확인했더라도 어떻게 해결해야 하는지를 명확히 말해줄 수 있는 사람은 부족한 것이 현실이다.
오라클은 매우 민감한 데이터베이스이다. 인덱스 또는 SQL 문 하나에 의해 해당 시스템은 천국과 지옥을 넘나들게 된다. 이는 경험해 본 사람이 아니라면 이해가 안 되는 부분일 수도 있다.
우리가 좀더 SQL 튜닝에 대한 중요성을 인식하고 있었다면 이런 성능 저하는 발생하지 않았을 것이다. 그렇다면 SQL 튜닝을 통한 성능 최적화는 왜 필요한 것인가?
SQL에 의한 성능 저하는 해당 시스템의 성능 저하는 물론 기업의 업무를 마비시킬 수도 있는 부분이다. 성능 저하로 인해 해당 시스템에서 업무가 구현되지 않는다면 어찌 기업의 업무를 유지시킬 수 있겠는가?
이와 같은 이유로 담당자들은 해당 시스템에 많은 비용을 투자해 CPU 및 메모리 등을 증설하게 될 것이다. 과연 이러한 조치가 최적의 조치인가?
필자는 이와 같이 무분별한비용의 사용보다는 해당 시스템의 최적화가 먼저 수행되어야 한다고 생각한다. 그 다음에 시스템을 증설해도 늦지 않을 것이다. SQL 성능 저하가 고객의 불만을 야기시키는 것은 두말할 필요가없을 것이다.
이와 같은 이유에서라도 우리는 SQL 최적화를 수행해야 하며 그 중심에는 DBA가 있다는 점을 명심하길 바란다. DBA의 SQL최적화에 대한 능력은 하나의 시스템을 최고로 만들 수도 있고 최악으로 만들 수도 있다.
SQL 튜닝을 통한 성능 최적화를 수행하기 위해서는 자기만의 방법론이 필요할 것이다. 방법론이 존재하지 않는다면 SQL 튜닝을 통한 성능 최적화에 대한 효과를 기대하기는 힘들 것이다.
다음에서 소개하는 SQL 튜닝 방법론은 하나의 예제이며, 이를 참조해 자신만의 SQL 튜닝 방법론을 구축하길 바란다.
첫 번째로 성능 데이터를 수집해야 한다. 성능 데이터는 여러가지 방법으로 수집할 수 있다. 다양한 방법으로 성능 데이터를 수집하는 것이 SQL 최적화 수행의 가장 기본적인 작업일 것이다.
성능 데이터에 대한 수집 없이 무엇을 보고 우리가 어떤 SQL에 문제가 있는지를 말할 수 있겠는가? 이는 병원에서 X-레이 하나없이 환자의 병을 진단하는 것과 같을 것이다.
두 번째로 성능 데이터를 수집했다면 이제는 성능 데이터를 정확히 분석하는 과정이 필요하다. 성능 데이터의 분석은 매우 객관적이며, 이러한 성능 데이터 분석을 통해 문제의 SQL을 도출할 수 있어야 한다.
세 번째로 문제 SQL을 수집했다면 SQL을 세밀하게 분석해 해당 SQL의 문제점을 정확히 도출해야 한다. 또한 도출된 문제점을 기준으로 전문적인 지식을 융합해 비효율을 제거하는 일련의 활동을 수행해야 한다.
네 번째로 최적화된 SQL을 적용하고 그에 따른 효과 분석이 필요하다. 효과 분석은 계속된 SQL 최적화를 수행하기 위해 반드시 필요한 작업이며, 효과 분석에서는 SQL 최적화를 수행한 내용에 대해 문서화를 하는 것도 매우 중요한 일이다.
이러한 SQL 최적화의 단계는 한 번만 수행해서 종료되는 것은아니다. 해당 시스템에 비효율이 전혀 존재하지 않을 때까지 계속 적으로 반복 수행해야 할 것이다.
SQL 최적화는 DBA의 가장 핵심적인 업무 중 하나이다. 또한 한 단계 높은 일을 수행하기 위해서는 한 번은 거쳐야 하는 단계이기도 하다. DBA라면 이제는 SQL 최적화는 DBA의 업무이므로 반드시 도전해야 할 것이다.
모델링하면 매우 어렵게 생각하는 경우가 많다. 하지만 모델링이 마냥 어려운 일만은 아니다. 모델링을 이해하기 위해서는 우선 모델링이 어떤 단계로 구성되는지 이해해야 한다.
위의 단계에서 논리 모델링은 개념적 모델링도 포함한 단계이다. 위와 같이 구분되는 모델링의 단계에서 물리 모델링은 DBA와는 매우 관련이 깊은 단계이므로 물리 모델링에 대해 확인해 보자.
물리 모델링은 논리 모델링을 통해 도출된 엔티티를 테이블로 구성하고 속성을 테이블의 컬럼으로 구현하는 단계를 의미한다. 엔티티를 테이블로 구성하는 과정에 DBA는 많은 역할을 수행해야 한다.
데이터베이스에서 제공하는 테이블에는 여러 종류가 존재하며 어떤 종류의 테이블을 선택하는가에 따라 성능 및 관리에서 많은 차이가 발생하게 된다. 그렇다면 오라클에서 제공하는 테이블의 종류에는 어떤 것이 존재하는가?
여러 종류의 테이블 중 어떤 종류의 것을 선택하는가는 관리 및 성능에 있어 매우 중요한 요소로 작용하게 된다. 이러한 테이블의 선정 과정에서 DBA가 직접 참여해 물리 모델링의 중요한 역할을 수행해야 한다.
테이블의 속성을 테이블의 컬럼으로 변경하는 단계는 어떠한가? 테이블의 속성을 테이블의 컬럼으로 변경하는 단계 또한 많은 항목을 고려해 선정해야 한다. 특히 테이블의 컬럼에는 여러 속성이 존재한다.
하나의 컬럼을 문자 타입으로 선정할 수도 있고 숫자 타입으로 선정할 수도 있다. 이러한 사항은 추후 데이터베이스 의 성능 및 관리에 큰 영향을 미칠 수 있는 사항이므로 아무나 마음대로 선정해서는 안 될 것이다.
반드시 DBA와 협의해 선택해야 하며, DBA 또한 이러한 업무에서 자신의 역할이 중요함을 인식하고 항상 준비해야 한다.
이와 같은 업무가 DBA의 업무가 될 수 있으며, 준비하고 있지 않는다면 이와 같은 업무는 DBA의 업무가 되지 않을 것이다. 논리 모델링과 물리 모델링은 준비된 DBA만이 수행할 수 있는 업무임을 기억하길 바란다.
DBA로 산다는 것은 때로는 재미있고 때로는 힘든 일임에는 틀림없다. 하지만 인생을 살면서 최고의 DBA가 되고자 도전하는 것도 한번 해 볼 만한 일이 아닌가 생각한다.
- 강좌 URL : http://www.gurubee.net/lecture/2272
- 구루비 강좌는 개인의 학습용으로만 사용 할 수 있으며, 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
- 구루비 강좌는 서비스 제공을 위한 목적이나, 학원 홍보, 수익을 얻기 위한 용도로 사용 할 수 없습니다.