SQL Server 2008 데이터베이스 엔진 기능의 동작 변경 내용

SQL Server 2008에서는 분할된 테이블의 디자인이 향상되어 SQL Server 2005의 분할된 테이블에 비해 쿼리 처리 중 한층 개선된 병렬 처리 성능을 제공합니다. 이와 같은 디자인 변경에 따라 이제 양방향 조인만 배치할 수 있게 되었습니다. SQL Server 2008의 양방향 배치된 조인에 대한 쿼리 계획은 SQL Server 2005와 겉모습은 같으며 SQL Server 2005와 비슷한 성능을 제공합니다. 정렬된 분할이 있는 추가 테이블이 조인에 포함된 경우에는 다른 계획이 선택됩니다. 세 번째 테이블이 있는 해시 조인이 뒤에 나오는 양방향 배치된 조인을 예로 들 수 있습니다. 세 개 이상의 테이블 간에 배치된 조인은 일반적이지 않을 뿐만 아니라 배치된 조인을 통해 SQL Server 2008의 병렬 처리 향상 기능에서 얻을 수 있는 이점이 없습니다. 그러나 SQL Server 2005에서 3방향 이상의 배치된 조인을 수행하는 쿼리가 있는 경우 테이블 크기에 비해 메모리 양이 상대적으로 적다면 SQL Server 2008에서 쿼리 실행 속도가 느려질 수 있습니다. 이 경우 사용 가능한 메모리의 양을 늘리거나 결과를 결합하기 전에 개별 파티션을 별도로 조인하도록 쿼리를 다시 작성하는 등의 방법을 사용하면 성능을 향상시킬 수 있습니다. 배치된 조인에 대한 자세한 내용은 분할된 테이블 및 인덱스에서의 향상된 쿼리 처리를 참조하십시오.

SQL Server에서는 해시 조인과 비트맵 필터를 사용하는 스타 조인을 통해 쿼리를 처리하는 새로운 최적화를 제공합니다. 조인되는 팩트 테이블에서 별모양 스키마의 차원 테이블로 많은 양의 데이터를 처리하는 쿼리의 경우 새로운 최적화를 사용하는 쿼리 계획을 통해 실행 속도가 훨씬 빨라질 수 있습니다. 

따라서 기존 쿼리가 스타 조인 패턴에 맞을 경우 해당 쿼리에 대해 새로운 쿼리 계획이 제공될 수 있습니다. 쿼리 최적화 프로그램에서는 새로운 계획이 쿼리 성능을 향상시킬 것으로 예상되면 해당 계획을 선택합니다. 그러나 비용 예상에 사용된 통계가 정확하지 않을 경우 다른 계획이 더 빠르더라도 쿼리 최적화 프로그램에서는 스타 조인 최적화를 선택할 수 있습니다.

최대 병렬 처리 수준 구성 옵션이나 MAXDOP 인덱스 옵션이 1로 설정되어 있으면 쿼리 최적화 프로그램에서 스타 조인 최적화를 사용하지 않기 때문에 새로운 스타 조인 최적화가 제공하는 이점을 경험할 수 없습니다. 쿼리 실행 시스템에서 스레드가 하나 뿐인 병렬 계획으로 최적화된 쿼리를 디스패치할 경우 일부 비트맵 필터는 다중 비트맵 필터 스타 조인 계획에서 제거될 수 있습니다. 예를 들어 두 개의 스레드에서 한 개의 스레드로 이동할 때 실행 속도가 예상보다 느려질 수 있습니다.

스타 조인 최적화는 SQL Server Enterprise, Developer 및 Evaluation Edition에서만 사용할 수 있습니다. 비트맵 필터링에 대한 자세한 내용은 비트맵 필터링을 통한 데이터 웨어하우스 쿼리 성능 최적화를 참조하십시오. 비트맵 필터가 포함된 쿼리 계획을 해석하는 방법은 비트맵 필터를 포함하는 실행 계획 해석을 참조하십시오. 스타 조인 최적화에 대한 자세한 내용은 TechNet Magazine의 "데이터 웨어하우스 쿼리 성능(Data Warehouse Query Performance)" 기사를 참조하십시오.

SQL Server 2008에서는 조인의 외부 측면에 몇 개의 행만 있는 경우 중첩 루프 조인에 대한 병렬 처리를 지원합니다. SQL Server 2005에서는 사용할 수 있는 스레드가 여러 개인 경우 조인의 외부 측면에서 각 스레드에 행 페이지가 하나씩 할당됩니다. 몇 개의 행만 있는 경우에는 행이 대개 동일한 페이지에 있습니다. 이러한 경우 스레드가 하나만 사용되므로 병렬 처리의 이점이 사라집니다. SQL Server 2008에서는 이러한 경우를 인식하며 사용 가능한 모든 CPU가 사용되도록 스레드당 행을 하나씩 할당하는 교환 연산자가 도입되었습니다. 늘어난 병렬 처리로 인해 SQL Server 2005에 비해 CPU 사용량이 일시적으로 늘어나지만 쿼리 실행 속도는 빨라집니다. 이 새로운 동작은 외부 행의 수가 적고 추가 병렬 처리의 이점을 누릴 만큼 쿼리 비용이 많을 것으로 예상될 경우에만 관찰할 수 있습니다. 쿼리 비용이 적을 것으로 예상되거나 외부 측면에 대한 카디널리티 예측이 1000보다 크면 SQL Server 2005에서와 같이 SQL Server에서 스레드당 한 페이지를 할당합니다. 교환 연산자 및 병렬 쿼리 처리에 대한 자세한 내용은 병렬 쿼리 처리를 참조하십시오.

SQL Server 2008에서는 분할된 테이블 및 인덱스에 대한 쿼리의 처리 방법이 달라졌습니다. USE PLAN 힌트를 사용하는 분할된 개체에 대한 쿼리에는 잘못된 계획이 포함될 수 있습니다. SQL Server 2008로 업그레이드한 후에는 다음 절차를 수행하는 것이 좋습니다.

USE PLAN 힌트가 쿼리에 직접 지정된 경우

1. 쿼리에서 USE PLAN 힌트를 제거합니다.

2. 쿼리를 테스트합니다.

3. 최적화 프로그램에서 적절한 계획을 선택하지 못하는 경우 쿼리를 조정하고 원하는 쿼리 계획에서 USE PLAN 힌트를 지정합니다.

USE PLAN 힌트가 계획 지침에 지정된 경우

1. sys.fn_validate_plan_guide 함수를 사용하여 계획 지침의 유효성을 검사합니다. 또는 SQL Server Profiler에서 Plan Guide Unsuccessful 이벤트를 사용하여 잘못된 계획이 있는지 확인할 수 있습니다.

2. 계획 지침이 잘못된 경우 해당 계획 지침을 삭제합니다. 최적화 프로그램에서 적절한 계획을 선택하지 못하는 경우 쿼리를 조정하고 원하는 쿼리 계획에서 USE PLAN 힌트를 지정합니다.

분할된 개체에서의 쿼리 처리에 대한 자세한 내용은 분할된 테이블 및 인덱스에서의 향상된 쿼리 처리를 참조하십시오.

SQL Server 2005에서 Resource 데이터베이스의 데이터 및 로그 파일은 master 데이터베이스의 데이터 파일 위치에 종속됩니다. 따라서 master 데이터베이스를 이동하려면 Resource 데이터베이스도 동일한 위치로 이동해야 합니다. SQL Server 2008에는 이러한 종속성이 없습니다. Resource 데이터베이스를 이동하지 않아도 master 데이터베이스 파일을 이동할 수 있습니다.

SQL Server 2008에서 Resource 데이터베이스의 기본 위치는 <drive>:\Program Files\Microsoft SQL Server\MSSQL10.<instance_name>\Binn\입니다. Resource 데이터베이스를 이동할 수는 없습니다.

이전 버전의 SQL Server에서는 tempdb 데이터베이스의 PAGE_VERIFY 데이터베이스 옵션이 NONE으로 설정되며 수정할 수 없습니다. SQL Server 2008에서는 새 SQL Server를 새로 설치하는 경우 tempdb 데이터베이스의 기본값은 CHECKSUM입니다. SQL Server 설치를 업그레이드하는 경우는 기본값이 NONE으로 유지됩니다. 이 옵션은 수정할 수 없습니다. tempdb 데이터베이스에는 CHECKSUM을 사용하는 것이 좋습니다.

SQL Server 2008에는 XML 스키마 지원에 대한 몇 가지 확장이 포함되어 있습니다. 여기에는 lax 유효성 검사에 대한 지원, 향상된 xs:date, xs:time 및 xs:dateTime 인스턴스 데이터 처리, list 및 union 유형에 대한 추가 지원이 포함됩니다. 대부분의 경우 변경 사항이 업그레이드에 영향을 주지 않습니다. 그러나 xs:date, xs:time 또는 xs:dateTime 유형이나 하위 유형의 값을 사용할 수 있는 SQL Server 2005의 XML 스키마 컬렉션을 사용할 경우 SQL Server 2005 데이터베이스를 SQL Server 2008로 업그레이드하면 다음 업그레이드 단계가 진행됩니다.

1. 모든 xml 열의 경우 이 열이 xs:anyType, xs:anySimpleType, xs:date 또는 해당 하위 유형, xs:time 또는 해당 하위 유형, xs:dateTime 및 해당 하위 유형으로 형식화되거나 이러한 유형이 포함된 union이나 list 유형으로 형식화된 요소나 특성이 들어 있는 XML 스키마 컬렉션으로 형식화되면 다음과 같은 상황이 발생합니다.

   1. 열의 모든 XML 인덱스를 사용할 수 없게 됩니다.

   2. 모든 SQL Server 2005 값이 Z 표준 시간대로 표준화되었으므로 이 값이 Z 표준 시간대로 계속 표시됩니다.

   3. 일 년 중 1월 1일보다 작은 xs:date 또는 xs:dateTime 값은 인덱스가 다시 작성되거나 XQuery 또는 XML-DML 문이 해당 값을 포함하는 xml 데이터 형식에 대해 실행되면 런타임 오류를 일으킵니다.

2. xs:date 또는 xs:dateTime 패싯의 음수 연도나 XML 스키마 컬렉션의 기본값은 기본 xs:date 또는 xs:dateTime 유형에 의해 허용되는 최소값으로 자동 업데이트됩니다(예: xs:dateTime의 경우 0001-01-01T00:00:00.0000000Z).

간단한 SQL SELECT 문을 계속 사용하면 음수 연도가 포함될 경우에도 전체 xml 데이터 형식을 검색할 수 있습니다. 음수 연도를 새로 지원되는 범위에 있는 연도로 대체하거나 해당 요소나 특성의 유형을 xs:string으로 변경하는 것이 좋습니다. 자세한 내용은 형식화된 XML과 형식화되지 않은 XML을 참조하십시오.

SQL Server 2005에서는 lax 유효성 검사를 지원하지 않으므로 anyType 유형 요소에 엄격한 유효성 검사가 적용됩니다. SQL Server 2008에서는 lax 유효성 검사를 사용하여 anyType 유형 요소의 콘텐츠에 대한 유효성이 검사됩니다. 자세한 내용은 와일드카드 구성 요소 및 콘텐츠 유효성 검사를 참조하십시오.