SQL Server 2008 데이터베이스 엔진 기능의 동작 변경 내용
이 항목에서는 데이터베이스 엔진의 동작 변경 내용에 대해 설명합니다. 동작 변경 내용은 이전 버전의 SQL Server와 비교해서 SQL Server 2008의 기능이 작동하고 상호 작용하는 방법에 영향을 줍니다.
SQL Server 에이전트
SQL Server 에이전트 태스크의 스크립트 동작에 대한 변경입니다.
SQL Server 2008에서 기존 작업의 스크립트를 복사하여 새 작업을 만들 경우 새 작업이 기존 작업에 의도하지 않은 영향을 줄 수 있습니다. 기존 작업의 스크립트를 사용하여 새 작업을 만들려면 일반적으로 기존 작업에 작업 일정을 만드는 섹션의 마지막 매개 변수인 @schedule\_uid 매개 변수를 수동으로 삭제하십시오. 그러면 기존 작업에 영향을 주지 않고 새 작업에 대한 독립적인 새로운 일정을 만들 수 있습니다.
Access Check Cach 옵션
SQL Server 2005에서는 추적 플래그를 사용하는 방법 외에는 access check result cache 내부 구조를 구성할 수 없습니다. SQL Server 2008에서는 access check cache 옵션을 사용하여 이 구조를 수정할 수 있습니다. 자세한 내용은 access check cache 옵션을 참조하십시오.
전체 텍스트 검색
SQL Server 2008에서는 새로운 전체 텍스트 검색 아키텍처를 도입했습니다. 이제 전체 텍스트 검색 엔진은 별도의 서비스로 제공되지 않고 SQL Server 데이터베이스 엔진에 완전하게 통합되었습니다. 통합된 전체 텍스트 검색은 이전 SQL Server 릴리스와 비교해 관리 효율성, 확장성, 보안 및 성능이 더욱 향상되었습니다. SQL Server 2005와 SQL Server 2008의 전체 텍스트 검색이 지닌 주요 차이점에 대한 자세한 내용 및 새로 통합된 전체 텍스트 검색 엔진과 관련된 최상의 방법을 보려면 MSDN의 "SQL Server 2008 전체 텍스트 검색: 내부 구조 및 향상 기능(SQL Server 2008 Full-Text Search: Internals and Enhancements)" 기술 문서를 참조하십시오.
연결된 서버
SQL Server 2008에서는 루프백 연결된 서버를 대상으로 실행되는 INSERT...EXECUTE 문의 트랜잭션 의미가 변경되었습니다. SQL Server 2005에서는 이 시나리오가 지원되지 않으며 오류가 발생합니다. SQL Server 2008에서는 연결에 MARS(Multiple Active Result Sets)를 설정하지 않은 경우 루프백 연결된 서버에 대해 INSERT...EXECUTE 문을 실행할 수 있습니다. 연결에 MARS가 설정된 경우 동작은 SQL Server 2005와 동일합니다.
병렬 처리
분할된 테이블 쿼리 처리 및 병렬 처리
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에서 스레드당 한 페이지를 할당합니다. 교환 연산자 및 병렬 쿼리 처리에 대한 자세한 내용은 병렬 쿼리 처리를 참조하십시오.
USE PLAN 힌트를 사용하는 분할된 테이블 쿼리
SQL Server 2008에서는 분할된 테이블 및 인덱스에 대한 쿼리의 처리 방법이 달라졌습니다. USE PLAN 힌트를 사용하는 분할된 개체에 대한 쿼리에는 잘못된 계획이 포함될 수 있습니다. SQL Server 2008로 업그레이드한 후에는 다음 절차를 수행하는 것이 좋습니다.
USE PLAN 힌트가 쿼리에 직접 지정된 경우
쿼리에서 USE PLAN 힌트를 제거합니다.
쿼리를 테스트합니다.
최적화 프로그램에서 적절한 계획을 선택하지 못하는 경우 쿼리를 조정하고 원하는 쿼리 계획에서 USE PLAN 힌트를 지정합니다.
USE PLAN 힌트가 계획 지침에 지정된 경우
sys.fn_validate_plan_guide 함수를 사용하여 계획 지침의 유효성을 검사합니다. 또는 SQL Server Profiler에서 Plan Guide Unsuccessful 이벤트를 사용하여 잘못된 계획이 있는지 확인할 수 있습니다.
계획 지침이 잘못된 경우 해당 계획 지침을 삭제합니다. 최적화 프로그램에서 적절한 계획을 선택하지 못하는 경우 쿼리를 조정하고 원하는 쿼리 계획에서 USE PLAN 힌트를 지정합니다.
분할된 개체에서의 쿼리 처리에 대한 자세한 내용은 분할된 테이블 및 인덱스에서의 향상된 쿼리 처리를 참조하십시오.
계획 지침
SQL Server 2008에서는 계획 지침을 적용할 수 없는 경우 다른 계획을 사용하여 쿼리가 컴파일되고 오류가 반환되지 않습니다. 그러나 SQL Server 2005에서는 오류가 발생하고 쿼리가 실패합니다.
SQL Server 2005에서 만든 계획 지침은 SQL Server 2008로 업그레이드한 후 유효하지 않게 될 수 있습니다. 잘못된 계획 지침은 응용 프로그램에서 오류를 발생시키지 않지만 사용되지 않습니다. 새로운 릴리스의 SQL Server로 응용 프로그램을 업그레이드할 때는 계획 지침 정의를 다시 평가하고 테스트하는 것이 좋습니다. 성능 조정 요구 사항과 계획 지침 일치 동작은 변경될 수 있습니다. 데이터베이스를 SQL Server 2008로 업그레이드한 후에는 다음 태스크를 수행하여 sys.fn_validate_plan_guide 함수로 기존 계획 지침의 유효성을 검사해야 합니다. 또는 SQL Server Profiler의 Plan Guide Unsuccessful 이벤트를 사용하여 잘못된 계획 지침이 있는지 모니터링할 수도 있습니다.
쿼리 프로세서 아키텍처
SQL Server 2008에서는 분할된 테이블 및 인덱스에 대한 쿼리의 처리 방법이 달라졌습니다. SQL Server 2005에서 생성된 계획에 대해 USE PLAN 힌트를 사용하는 분할된 개체에 대한 쿼리에는 잘못된 계획이 포함될 수 있습니다. 자세한 내용은 데이터베이스 엔진 업그레이드 시 고려 사항을 참조하십시오. 분할된 개체에서의 쿼리 처리에 대한 자세한 내용은 분할된 테이블 및 인덱스에서의 향상된 쿼리 처리를 참조하십시오.
REPLACE 함수
SQL Server 2005에서는 REPLACE 함수의 첫 번째 입력 매개 변수가 char 형식인 경우 이 매개 변수에 지정된 후행 공백이 잘립니다. 예를 들어 SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>' 문에서 값 'ABC '은 'ABC'로 잘못 평가됩니다.
SQL Server 2008에서는 후행 공백이 항상 유지됩니다. 이 함수의 이전 동작에 의존하는 응용 프로그램의 경우 이 함수의 첫 번째 입력 매개 변수를 지정할 때 RTRIM 함수를 사용합니다. 예를 들어 구문 SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'를 통해 SQL Server 2005의 동작과 같은 결과를 얻을 수 있습니다.
시스템 데이터베이스
리소스 데이터베이스
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 데이터베이스를 이동할 수는 없습니다.
tempdb 데이터베이스
이전 버전의 SQL Server에서는 tempdb 데이터베이스의 PAGE_VERIFY 데이터베이스 옵션이 NONE으로 설정되며 수정할 수 없습니다. SQL Server 2008에서는 새 SQL Server를 새로 설치하는 경우 tempdb 데이터베이스의 기본값은 CHECKSUM입니다. SQL Server 설치를 업그레이드하는 경우는 기본값이 NONE으로 유지됩니다. 이 옵션은 수정할 수 없습니다. tempdb 데이터베이스에는 CHECKSUM을 사용하는 것이 좋습니다.
INSERT…SELECT를 사용하여 최소 로깅으로 데이터 대량 로드
이전 버전의 SQL Server에서 INSERT INTO <target_table> SELECT <columns> FROM <source_table> 문을 사용하여 대상 테이블로 대량 행을 로드하는 작업은 항상 모두 기록되는 작업입니다. SQL Server 2008에서 대상 테이블이 힙이면 이러한 작업은 최소 로깅으로 수행될 수 있으며 데이터베이스의 복구 모델은 단순 또는 대량 로그로 설정되고 대상 테이블에 TABLOCK 힌트가 지정됩니다. 최소 로깅은 문의 효율성을 향상시키며 트랜잭션 작업 중에 사용 가능한 트랜잭션 로그 공간을 꽉 채울 작업의 가능성을 줄여줍니다. 자세한 내용은 INSERT(Transact-SQL)를 참조하십시오.
XML
SQL Server 2005에서 SQL Server 2008로 형식화된 XML 업그레이드
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로 업그레이드하면 다음 업그레이드 단계가 진행됩니다.
모든 xml 열의 경우 이 열이 xs:anyType, xs:anySimpleType, xs:date 또는 해당 하위 유형, xs:time 또는 해당 하위 유형, xs:dateTime 및 해당 하위 유형으로 형식화되거나 이러한 유형이 포함된 union이나 list 유형으로 형식화된 요소나 특성이 들어 있는 XML 스키마 컬렉션으로 형식화되면 다음과 같은 상황이 발생합니다.
열의 모든 XML 인덱스를 사용할 수 없게 됩니다.
모든 SQL Server 2005 값이 Z 표준 시간대로 표준화되었으므로 이 값이 Z 표준 시간대로 계속 표시됩니다.
일 년 중 1월 1일보다 작은 xs:date 또는 xs:dateTime 값은 인덱스가 다시 작성되거나 XQuery 또는 XML-DML 문이 해당 값을 포함하는 xml 데이터 형식에 대해 실행되면 런타임 오류를 일으킵니다.
xs:date 또는 xs:dateTime 패싯의 음수 연도나 XML 스키마 컬렉션의 기본값은 기본 xs:date 또는 xs:dateTime 유형에 의해 허용되는 최소값으로 자동 업데이트됩니다(예: xs:dateTime의 경우 0001-01-01T00:00:00.0000000Z).
간단한 SQL SELECT 문을 계속 사용하면 음수 연도가 포함될 경우에도 전체 xml 데이터 형식을 검색할 수 있습니다. 음수 연도를 새로 지원되는 범위에 있는 연도로 대체하거나 해당 요소나 특성의 유형을 xs:string으로 변경하는 것이 좋습니다. 자세한 내용은 형식화된 XML과 형식화되지 않은 XML을 참조하십시오.
lax 유효성 검사 및 xs:anyType 요소
SQL Server 2005에서는 lax 유효성 검사를 지원하지 않으므로 anyType 유형 요소에 엄격한 유효성 검사가 적용됩니다. SQL Server 2008에서는 lax 유효성 검사를 사용하여 anyType 유형 요소의 콘텐츠에 대한 유효성이 검사됩니다. 자세한 내용은 와일드카드 구성 요소 및 콘텐츠 유효성 검사를 참조하십시오.
참고 항목
참조
관련 자료
변경 내역
업데이트된 내용 |
|---|
"Access Check Cache 옵션", "전체 텍스트 검색", "병렬 처리" 및 "XML" 섹션을 추가했습니다. |
"INSERT…SELECT를 사용하여 최소 로깅으로 데이터 대량 로드" 섹션을 추가했습니다. |
“SQL Server 에이전트 태스크의 스크립트 동작에 대한 변경” 섹션을 추가했습니다. |