시간이 점점 흐르고 버전이 올라 가면서 Oracle과 SQL Server가 점점 닮아 가고 있다.
하지만 여전히 다른 점 또한 존재한다.
다른 점 중에 하나인 병렬 처리 방식을 소개하고자 한다.
Oracle과 SQL Server의 병렬 처리 방식은 근본적으로 다르다.
Oracle의 경우 기본적으로 CPU를 1개만 사용한다.
필요에 의해 parallel query가 수행되도록 하려면 다음과 같이 3가지 방법으로 정의할 수 있다.
2. table level, create/alter table 문장에서 정의한다.
3. query level, PARALLEL hint에서 정의한다.
반면에 SQL Server는 기본 값이 병렬처리다.
필요에 의해 병렬 처리를 해제할 수 있다.
Sp_configure 를 통해 수행할 수 있는데 항목 중 max degree of parallelism의 값을 1로 변경하면 CPU를 1개만 사용하게 된다.
다음과 같이 실행하면 된다.
Reconfigure
또는 SQL Server 2000인 경우 엔터프라이즈 매니저(EM)을 통해 2005일 경우에는 SQL Server Management Studio를 통해서도 수정할 수 있다.
위 그림의 최대 병렬 처리 수준 0의 의미는 현 시스템에 있는 모든 CPU개수를 다 사용할 수 있다는 것이다. 물론 전체 CPU를 항상 다 사용하는 것은 아니다.
Max라는 한정자를 보면 알 수 있듯이 최대 사용할 수 있는 CPU개수를 정하는 것이지 실제로 사용할 CPU개수를 지정하는 것이 아니다. 이 또한 Oracle과 SQL Server가 다른 점이다.
Oracle의 경우 지정된 개수를 모두 사용하지만 SQL Server는 Optimizer가 판단해 볼 때 사용 가능한 상황이 되면 모두 사용한다는 것이다.
SQL Server의 기본 마인드는 ‘저에게 모두 맡겨 주세요. 제가 다 알아서 판단해 보고 최적의 값을 찾아 실행하도록 하겠습니다’ 이다.
정말 맡기면 모두 알아서 잘 처리해 주는 것일까? 항상 그렇다면 튜닝이 필요 없을 지도 모른다.
최적의 값을 Optimizer가 항상 알아서 찾아 주기야 한다면야 더 이상 바랄 것이 없겠지만 그럴 수 없기에 최대 병렬 처리 수준을 변경할 수 있도록 만들어 놓은 것이 아닐까 한다.
최대 병렬 처리 수준을 0이 아닌 다른 값으로 변경할 수도 있다. 1은 당연히 1개를 사용하겠다는 의미이고 그 이상의 값은 최대로 지정한 개수만큼 사용해도 된다는 의미로 받아 들이면 된다.
SQL Server 2005의 Sys.dm_os_wait_stats를 활용해 대기 상황을 조회한 결과 wait_type의 값 중 CXPacket의 값이 상대적으로 높다면 병렬처리에 의한 대기를 의심해 볼 수 있다.
이런 경우 최대 병렬 처리 수준을 조정하여 문제를 해결할 수도 있다.
현재 운영되고 있는 시스템이 대부분은 아주 작은 트랜잭션만 발생하고 배치성 작업은 거의 발생하지 않는다면 최대병렬 처리 수준을 1로 셋팅한 후 배치성 작업의 쿼리를 OPTION (MAXDOP 최대로 사용할 CPU개수)로 처리할 수도 있다.
아래와 같이 사용할 수 있다.
Inner JOIN Adventureworks.Sales.SalesOrderHeader AS b ON
a.SalesOrderID=b.SalesOrderID
OPTION(MAXDOP 4)
이와는 반대로 최대 병렬 처리 수준을 1로 셋팅하여 사용하던 어느 사이트에서 이 값을 0으로 셋팅한 후 처리속도가 기존보다 상당히 빨라진 경우도 있다. CPU 활용을 제대로 못하고 있었다고 볼 수 있다. 병렬 처리로 처리하면 훨씬 빠르게 처리할 수 있는 것들이 많았던 것이 그 이유라 할 수 있겠다.
대용량을 처리할 경우는 병렬 처리가 최적의 답일 수 있다.
하지만, 최대 병렬 처리 수준이 0이 최선이냐 아님 1이 최선이냐에 대한 정답은 없다.
각 사이트마다의 상황에 따라 적절히 조절한다가 정답일 것이다.
즉, 상황에 따라 병렬이 유리할 수도 있고 싱글 CPU 처리가 유리할 수도 있다.
DBA 역할을 담당하고 있는 분들이 상황에 맞게 적절히 잘 조정하여 사용한다면 최적의 성능으로 DB서버를 운영할 수 있을 것이다.
모든 DBA들이 시스템 성능 걱정 없이 웃을 수 있는 그 날이 올 때까지 아자아자
파이팅!
'엑셈 기업문화 > 엑셈 사람들' 카테고리의 다른 글
파란만장 ASK.엑셈 탄생기 (4) | 2009.04.15 |
---|---|
[임종민]OutOfMemory 해결 방법론 – 그때 그 시절 (1) | 2009.04.09 |
[이창훈]수많은 생각보다 한 번의 시도를 하자 (1) | 2009.03.26 |
[방기남]진리를 향한 끊임없는 열망 (1) | 2009.03.20 |
[황종필]기본으로부터의 발상의 전환 (5) | 2009.03.10 |
댓글