오늘 마이그레이션 테스트를 하다가 알아낸 사실.
다음과 같은 쿼리가 있다고 하자.
select col1
, col2
, dbo.uf_test_function(col3)
into #temp_table
from VERY_BIG_TABLE a
inner join SMALL_TABLE b on a.col1 = b.col1
inner join BIG_TABLE c on b.col1 = c.col1
inner join BIG_TABLE d on c.col2 = d.col2
option(maxdop 4)
, col2
, dbo.uf_test_function(col3)
into #temp_table
from VERY_BIG_TABLE a
inner join SMALL_TABLE b on a.col1 = b.col1
inner join BIG_TABLE c on b.col1 = c.col1
inner join BIG_TABLE d on c.col2 = d.col2
option(maxdop 4)
VERY_BIG_TABLE 의 데이터 갯수는 1억건, BIG_TABLE 의 갯수는 1천만건이다.
데이터 마이그레이션 중이므로 당연히 CPU 4개를 써서 한꺼번에 읽어서 hash join 으로 처리하기를 기대하고 위와 같이 만들었다. 그런데 돌려보니 평소에 걸리던 것보다 시간이 엄청 오래 걸린다. 실행계획을 보니 병렬 계획을 세우지 못하는게 아닌가!
도대체 이게 무슨 일인가 하여 테이블을 하나하나 빼가면서 여러 모로 살펴본 결과 원인은 두가지였다.
1. BIG_TABLE 에 대해서 self-join 을 한다.
2. select 문에 dbo.uf_test_function 이 있다.
2. select 문에 dbo.uf_test_function 이 있다.
믿기지가 않겠지만 정말로 일어난 일이다. SQL Server 2000 sp4 에서 발생했다.
1번에 대해서는 그럴수도 있겠다는 생각이 든다. SQL Server 는 아주 가끔 병렬 계획을 세워서 쿼리를 수행하다가 Intra Query Paralleism Deadlock 을 일으킨다. 즉, 복수개의 CPU 들이 쿼리를 처리하다가 지들끼리 데드락을 잡아서 쿼리가 실패하는 경우다. 아무래도 복수개의 CPU가 같은 테이블을 self-join 해야 하는 상황이 되다보니 옵티마이저가 데드락을 우려하여 알아서 병렬 계획을 안세운 것이 아닌가 하는 생각이 든다.
2번에 대해서는... 전혀 알 수 없다. 도대체 function 하고 병렬 계획하고 무슨 상관이람-_-;
function 은 실행계획에 아예 나오지도 않는데 뭐 그런 문제랑 관련이 있는건지.. 흠....
Posted by maceo
