SQL Server 원리 이해

SQL Server 2000의 원리를 이해하면 데이터베이스의 성능을 관리하는 데 도움이 됩니다.

작업자 스레드

SQL Server는 데이터베이스 서버에 전달되는 SQL Server 명령 배치를 서비스하는 데 사용하는 Windows 스레드의 풀을 유지합니다. 들어오는 모든 명령 배치를 서비스하는 데 사용할 수 있는 전체 스레드(SQL Server 용어로는 "작업자 스레드") 수는 sp_configure 옵션인 max worker threads 설정에 따라 결정됩니다. 배치를 능동적으로 전달하는 연결의 수가 max worker threads에 대해 지정된 수보다 크면, 능동적으로 배치를 전달하는 연결들은 작업자 스레드를 공유하게 됩니다. 대부분의 설치에서는 기본값 255를 적용하면 충분할 것입니다. 연결은 대부분 배치가 클라이언트에서 수신되기를 기다리는 데 대부분의 시간을 소비합니다.

작업자 스레드는 SQL Server 버퍼 캐시에서 8KB 데이터 페이지를 작성하는 대부분의 작업을 맡습니다. 작업자 스레드는 최대 성능을 위해 자체 입/출력 동작 일정을 비동기적으로 작성합니다.

지연 기록기

지연 기록기는 버퍼 관리자 내에서 기능을 수행하는 SQL Server 시스템 프로세스입니다. 지연 기록기는 커밋되지 않고 오래된 버퍼(다른 페이지에 재사용되기 전에 먼저 디스크에 기록해야 할 변경 사항이 포함된 버퍼)를 배치로 플러시하여 사용자 프로세서에 사용될 수 있도록 합니다. 이러한 작업은 사용 가능한 빈 버퍼를 만들고 유지 관리하는 데 도움이 됩니다. 즉, 8KB의 빈 데이터 캐시 페이지를 다시 사용할 수 있게 됩니다. 지연 기록기가 8KB 캐시 버퍼를 플러시할 때마다 캐시 페이지의 ID가 초기화되므로 다른 데이터를 빈 버퍼에 쓸 수 있게 됩니다. 지연 기록기는 디스크 입/출력이 적은 기간에 작동함으로써 이 동작이 기타 SQL Server 작업에 미치는 영향을 최소화합니다.

SQL Server는 사용 가능한 버퍼 수준을 자동으로 구성하고 관리합니다. 성능 카운터 SQL Server: Buffer Manager: Lazy Writes/sec은 실제로 디스크에 기록되는 8KB 페이지 수를 나타냅니다. 이 값이 급격히 떨어지는지 보려면 SQL Server: Buffer Manager: Free Pages를 모니터하십시오. 지연 기록기는 SQL Server 작업 전체에서 이 카운터 수준을 최적으로 유지함으로써 사용 가능한 버퍼에 대한 사용자 요구를 만족시킵니다. 시스템 모니터 개체 SQL Server: Buffer Manager: Free Pages의 값이 0에 도달할 경우, 사용자 로드가 지연 기록기에서 제공할 수 있는 크기 이상의 빈 버퍼를 요구할 때가 있었다는 것입니다.

지연 기록기가 빈 버퍼를 안정 수준으로 또는 적어도 0 이상으로 유지하는 데 문제가 있다면, 이는 디스크 하위 시스템이 충분한 디스크 입/출력 성능을 제공하지 못한다는 뜻일 수 있습니다. 빈 버퍼 수준의 감소를 디스크 대기열과 비교하여 사실을 확인하십시오. 해결책은 추가 물리 디스크 드라이브를 데이터베이스 서버 디스크 하위 시스템에 추가하여 디스크 입/출력 처리 능력을 높이는 것입니다.

시스템 모니터에서 Average Disk Queue Length 또는 Current Disk Queue Length 카운터를 보고 현재 디스크 대기열 수준을 모니터하고, 모든 SQL Server 동작과 연관된 각 물리 드라이브마다 디스크 대기열이 2 미만인지 확인합니다. 하드웨어 RAID 컨트롤러와 디스크 어레이를 채택하는 데이터베이스 서버의 경우, 반드시 논리적 또는 물리 디스크 카운터가 보고하는 수를 디스크 관리자가 보고하는 해당 논리 드라이브 문자와 관련된 실제 하드 드라이브 수 또는 물리 하드 드라이브 수로 나누어야 합니다. 이는 Windows와 SQL Server가 RAID 컨트롤러에 부착된 물리 하드 드라이브 수를 인식하지 못하기 때문입니다. 시스템 모니터가 보고하는 디스크 대기열 수를 적절히 해석하기 위해서는 RAID 어레이 컨트롤러와 연관된 드라이브의 수를 아는 것이 중요합니다.

자세한 내용은 SQL Server 온라인 문서에서 "freeing and writing buffer pages"와 "write-ahead transaction log" 문자열을 검색해 보십시오.

검사점

각 SQL Server 인스턴스는 커밋되지 않은 로그와 데이터 페이지를 주기적으로 디스크에 플러시합니다. 이를 검사점이라고 합니다. 검사점은 SQL Server 인스턴스가 다시 시작될 때 장애 복구에 필요한 시간과 리소스를 줄여줍니다. 검사점 중에 커밋되지 않은 페이지(버퍼 캐시에 놓인 이후 수정된 버퍼 캐시 페이지)는 SQL Server 데이터 파일에 기록됩니다. 검사점에 디스크로 쓰여진 버퍼에는 여전히 페이지가 들어 있으며 사용자는 디스크에서 다시 읽지 않고 읽거나 업데이트할 수 있습니다. 이것은 지연 기록기에 의해 작성된 빈 버퍼에는 해당되지 않습니다.

검사점 논리는 작업자 스레드와 지연 기록기가 커밋되지 않은 페이지를 기록하는 대부분의 작업을 수행하도록 합니다. 이를 위하여 검사점 논리는 가능한 경우 커밋되지 않은 페이지를 쓰기 전에 여분의 검사점 대기를 시도합니다. 이렇게 하면 작업자 스레드와 지연 기록기가 커밋되지 않은 페이지를 쓰는 데 더 많은 시간을 할애할 수 있습니다. 이와 같이 커밋되지 않은 페이지에 여분의 대기 시간이 발생하는 조건에 대한 내용은 SQL Server 온라인 문서의 "Checkpoints and the Active Portion of the log" 절에 자세히 나와 있습니다. 기억해 두어야 할 사항은 검사점 논리가 보다 긴 시간 동안 SQL Server 디스크 입/출력 작업을 안정시키기 위해 여분의 검사점 대기를 사용한다는 사실입니다.

보다 효율적인 검사점 작업을 위해서는 캐시에서 플러시해야 할 페이지가 많을 때 SQL Server가 플러시할 데이터 페이지를 디스크에 나타난 페이지 순서로 정렬합니다. 이렇게 하면 캐시 플러시 도중 디스크 암의 움직임을 최소화하는 데 도움이 되며, 가능한 경우 순차적 디스크 입/출력의 이점을 이용할 수 있습니다. 검사점 프로세스는 또한 8KB 디스크 입/출력 요청을 비동기적으로 디스크 하위 시스템에 전달합니다. 이로 인해 SQL Server는 필요한 디스크 입/출력 요청을 더 빨리 전달할 수 있습니다. 이는 검사점 프로세스가 데이터가 실제로 디스크에 기록되었음을 디스크 하위 시스템이 보고할 때까지 기다리지 않기 때문입니다.

SQL Server 데이터 파일과 연관된 하드 드라이브의 디스크 대기열을 살펴보면서 SQL Server가 디스크가 처리할 수 있는 것보다 더 많은 디스크 입/출력 요청을 보내고 있지 않는지 확인하고, 이러한 경우가 발생하면 디스크 하위 시스템에 디스크 입/출력 용량을 추가하여 하위 시스템이 로드를 처리할 수 있도록 해야 합니다.

로그 관리자

다른 모든 주요 RDBMS 제품과 마찬가지로 SQL Server는 데이터베이스에서 수행된 모든 쓰기 작업(삽입, 업데이트 및 삭제)이 SQL Server의 온라인 상태를 중단시키는 요인(정전, 디스크 드라이브 결함, 데이터 센터 화재 등)으로 인해 손실되지 않도록 보장합니다. SQL Server 로깅 프로세스를 통해 복구 가능 상태를 유지합니다. 로그 관리자가 디스크 하위 시스템으로부터 해당 트랜잭션과 연관된 모든 데이터 변경 사항이 관련 로그 파일에 성공적으로 기록되었다는 신호를 받아야 암시적 트랜잭션(단일 SQL 쿼리) 또는 명시적 트랜잭션(BEGIN TRAN/COMMIT 또는 ROLLBACK 명령 시퀀스를 발행하는 정의된 트랜잭션)이 완료될 수 있습니다. 이 규칙에 따라 SQL Server가 어떤 이유로든 이상 종료되고 데이터 캐시에 기록된 트랜잭션이 검사점과 지연 기록기에 의해 데이터 파일로 아직 플러시되지 않은 경우 SQL Server를 다시 가동할 때 반드시 트랜잭션 로그가 읽혀지고 다시 적용될 수 있습니다. 서버 중단 후에 트랜잭션 로그를 읽고 SQL Server 데이터에 트랜잭션을 적용하는 것을 복구라고 합니다.

SQL Server는 각 트랜잭션이 완료되면서 디스크 하위 시스템이 SQL Server 로그 파일에 대한 입/출력을 완료할 때까지 기다려야 하므로, SQL Server 로그 파일을 포함하는 디스크의 용량은 예상 트랜잭션 로드에 맞는 디스크 입/출력을 처리 능력을 갖고 있어야 합니다.

SQL Server 로그 파일과 관련된 디스크 대기를 살펴보는 방법은 SQL Server 데이터베이스 파일과 다릅니다. 시스템 모니터 카운터 SQL Server: Databases : Log Flush Waits Times 및 SQL Server: Databases : Log Flush Waits/sec를 사용하여 디스크 하위 시스템에서 완료 대기 중인 로그 작성기 요청이 있는지 확인하십시오.

캐시 컨트롤러는 최고 성능을 제공하지만 로그 파일을 포함하는 디스크에는 사용할 수 없습니다. 단, 컨트롤러는 전원 장애가 발생하는 경우에도 마지막에 신뢰할 수 있는 데이터만 디스크에 기록할 것을 보증하는 경우는 예외입니다. 캐시 컨트롤러에 대한 자세한 내용은 뒤에 나오는 "하드웨어 RAID 컨트롤러에 내장된 캐시의 효과" 절을 참조하십시오.

미리 읽기 관리자

SQL Server 2000은 테이블 스캔 등의 작업에 많은 순차적 읽기에 대한 자동 관리를 제공합니다. 미리 읽기 관리는 완전히 자동으로 구성 및 조정되며 SQL Server 쿼리 프로세서의 작업과 밀접하게 통합됩니다. 미리 읽기 관리는 큰 테이블 스캔, 큰 인덱스 범위 스캔, 클러스터링된 인덱스 및 클러스터링되지 않은 인덱스 바이너리 트리 탐색 및 기타 상황에 사용됩니다. 이것은 미리 읽기가 8KB 입/출력에 비해 더 많은 디스크 처리량을 제공하는 64KB 입/출력으로 발생하기 때문입니다. 아주 많은 양의 데이터를 검색해야 하는 경우, SQL Server는 미리 읽기를 사용하여 처리율을 극대화합니다.

SQL Server는 미리 읽기 관리를 지원하는 간단하고 효율적인 IAM(Index Allocation Map) 저장소 구조를 사용합니다. IAM은 일정 범위의 여러 위치를 기록하는 SQL Server 메커니즘입니다. 각각의 64KB 범위에 데이터나 인덱스 정보가 8페이지씩 들어 있습니다. 각 IAM 페이지의 크기는 8KB이며, 이 페이지는 어느 범위에 필요한 데이터가 들어 있는지에 대한 정보(비트맵 형식)를 포함합니다. IAM 페이지의 압축 특성 때문에 빠르게 읽혀지며, 보다 정기적으로 사용되는 IAM 페이지를 버퍼 캐시에 유지 관리할 수 있습니다.

미리 읽기 관리는 쿼리 프로세서의 쿼리 정보를 IAM 페이지에서 읽어야 할 모든 범위의 위치에 대한 정보와 결합하여 여러 순차적 읽기 요청을 구성합니다. 순차적 64KB 디스크 읽기는 극히 양호한 디스크 입/출력 성능을 제공합니다. SQL Server: Buffer Manager: Read-Ahead Pages/sec 성능 카운터는 미리 읽기 관리의 효율과 효과에 대한 정보를 제공합니다.

SQL Server 2000 Enterprise Edition은 미리 읽기 페이지의 최대 수를 존재하는 메모리 크기를 기준으로 동적으로 조정합니다. 다른 모든 SQL Server 2000 버전에서는 값이 고정됩니다. SQL Server 2000 Enterprise Edition의 또 하나의 확장 기능은 흔히 말하는 회전목마(merry-go-round) 스캔으로, 여러 작업이 전체 테이블 스캔을 공유할 수 있도록 하는 기능입니다. SQL 문의 실행 계획이 테이블의 데이터 페이지 스캔을 요청하고 관계형 데이터베이스가 해당 테이블이 이미 다른 실행 계획에 의해 스캔되고 있음을 발견할 경우, 데이터베이스 엔진은 두번째 스캔의 현재 위치에서 스캔을 첫번째 스캔에 조인합니다. 데이터베이스 엔진은 각 페이지를 읽고 페이지의 행을 두 실행 계획 모두로 전달합니다. 이러한 작업은 테이블의 끝에 도달할 때까지 계속됩니다. 테이블의 끝에 도달하면, 첫번째 실행 계획이 완전한 스캔 결과를 갖게 되지만 두번째 실행 계획은 진행 중이던 스캔과 조인된 시점 이전에 발생한 데이터 페이지 검색을 계속해야 합니다. 두번째 실행 계획에 대한 검색은 테이블의 첫 데이터 페이지로 되돌아가서 첫번째 스캔과 조인된 시점으로 계속 진행됩니다. 나머지 추가 스캔도 이와 같은 방법으로 결합할 수 있습니다. 데이터베이스 엔진은 모든 스캔을 완료할 때까지 데이터 페이지 순환을 계속합니다.

미리 읽기 관리에 있어 한 가지 주의할 사항은 너무 많은 미리 읽기는 전반적인 성능을 떨어뜨릴 수 있다는 점입니다. 그 이유는 다른 목적으로 사용될 수도 있는 입/출력 및 CPU를 사용하여 캐시가 불필요한 페이지로 가득찰 수 있기 때문입니다. 솔루션은 최소한의 페이지가 버퍼 캐시로 들어오도록 모든 SQL 쿼리를 조정하는 일반적인 성능 조정입니다. 인덱스가 올바르며 그러한 인덱스를 사용하고 있는지 확인하는 것도 여기에 포함됩니다. 효율적인 범위 스캔을 위해 클러스터링된 인덱스를 사용하고 단일 행이나 그보다 더 작은 행 집합의 위치를 신속하게 찾는 데 도움이 되도록 클러스터링되지 않은 인덱스를 정의합니다. 예를 들어, 테이블에 한 개의 인덱스만 있도록 하거나 해당 인덱스가 단일 행이나 적은 행 집합을 반입하는 것이 목적인 경우, 인덱스를 클러스터링해야 합니다. 클러스터링된 인덱스는 보통 클러스터링되지 않은 인덱스보다 속도가 빠릅니다.

성능에 관한 기타 설명

별모양과 눈송이 스키마를 사용하여 데이터베이스 설계

데이터 웨어하우스는 차원 모델링을 사용하여 분석 용도로 데이터를 구성합니다. 차원 모델링은 별모양과 눈송이 스키마를 만듭니다. 이러한 스키마는 데이터 웨어하우징에서 자주 수행되는 대량의 데이터 읽기 작업에서 성능 효율성을 높여줍니다. 부피가 큰 데이터(종종 수십억 개의 행으로 구성됨)는 길이가 매우 짧은 행들로 구성된 팩트 테이블에 저장됩니다. 이러한 테이블은 저장소 요구와 쿼리 시간을 최소화합니다. 비즈니스 실체의 속성을 비표준 상태로 차원 테이블에 넣어 데이터를 검색할 때 테이블 조인 수를 최소화합니다.

데이터 웨어하우스용 데이터베이스 설계에 대한 자세한 내용은 Microsoft SQL Server 2000 Resource Kit의 "데이터 웨어하우스 설계 고려 사항"을 참조하십시오.

가능한 한 피하는 것이 좋은 SQL

SQL 쿼리에서 부등 연산자를 사용하면 데이터베이스에서 부등 조건을 평가하기 위해 테이블 스캔을 사용하게 됩니다. 아주 큰 테이블에 대해 이러한 쿼리가 자주 수행되면 입/출력 횟수가 많아집니다. "NOT" 연산자(!=, <>, !<, !>)를 포함하는 WHERE 절(예: WHERE != some_value)은 많은 입/출력을 생성하지 않습니다.

이러한 형태의 쿼리를 실행해야 하는 경우에는 쿼리 구조를 바꾸어 NOT 키워드를 없애도록 하십시오. 예를 들면 다음과 같습니다.

다음 쿼리에서

select * from tableA where col1 != "value"

다음 쿼리로

select * from tableA where col1 < "value" and col1 > "value"

행 세트 크기 및 통신 오버헤드 줄이기

SQL로 작업하는 데이터베이스 프로그래머는 구축할 결과 세트를 고려하는 데 ADO(Microsoft ActiveX® Data Objects), RDO(Remote Data Objects) 및 DAO(Data Access Objects) 데이터베이스 API와 같이 손쉬운 인터페이스를 사용합니다. ADO/RDO/DAO는 프로그래머들이 SQL 프로그램 작성 경험이 많지 않아도 풍부한 SQL 행 집합 기능을 만들 수 있는 뛰어난 데이터베이스 개발 인터페이스입니다. 하지만 추가 비용이 듭니다. 프로그래머의 응용 프로그램이 클라이언트로 반환하는 데이터 양을 신중하게 고려하고 인덱스가 놓일 SQL Server에 대한 추적을 유지하고 SQL Server 데이터의 정렬 방법을 고려하여 성능 문제를 피할 수 있습니다. SQL 프로필러, 인덱스 튜닝 마법사 및 그래픽 방식 실행 계획은 이러한 문제 쿼리를 정확히 찾아내 수정하는 데 아주 유용한 도구입니다. 커서 논리를 사용할 때, 수행하려는 처리 유형에 적합한 커서를 선택하십시오. 다양한 유형의 커서가 각기 다른 가격으로 제공됩니다. 반드시 수행할 작업의 종류(읽기 전용, 전송 처리만 등)를 파악한 다음에 해당되는 커서 유형을 선택하십시오. 선택 목록에서 반환할 필요가 없는 열을 제거하거나 오직 필요한 행만을 반환함으로써 기회가 있을 때마다 반환되는 결과 집합 크기를 줄여야 합니다. 이렇게 하면 입/출력과 CPU 소모량을 줄이는 데 도움이 됩니다.

여러 명령문 사용 데이터베이스에서 처리를 수행하여 클라이언트와 데이터베이스 서버 사이의 불필요한 네트워크 통신과 결과 세트의 크기를 줄일 수 있습니다. SQL Server에서 하나의 Transact-SQL 문만으로는 완료할 수 없는 처리를 수행하기 위해 다음과 같은 방법으로 여러 Transact-SQL 문을 그룹으로 묶을 수 있습니다.

다음과 같은 SQL Server 기능을 사용하여 한 번에 여러 개의 Transact-SQL 문을 사용하는 것을 제어할 수 있습니다.

실행 계획 재사용

SQL Server가 이전의 쿼리에서 기존의 실행 계획을 활용할 수 있을 때 성능이 향상될 수 있습니다. 개발자는 여러 가지 방법으로 SQL Server가 실행 계획을 다시 사용하도록 할 수 있습니다. Transact-SQL 문은 다음과 같은 지침에 따라 작성해야 합니다.

·                     테이블이나 뷰 등의 개체에 대해 완전히 규정된 이름을 사용하십시오.

예를 들면 다음 SELECT 문과 같이 코딩하지 마십시오.

SELECT * FROM Shippers WHERE ShipperID = 3

ODBC를 사용하는 대신, 다음과 같은 SQLBindParameter ODBC 함수를 사용하십시오.

SELECT * FROM Northwind.dbo.Shippers WHERE ShipperID = 3

·                     저장 프로시저 매개 변수 값을 지정하거나 검색 조건 조건자에 직접 값을 지정하는 것이 아니라 매개 변수화된 쿼리를 사용하고 매개 변수 값을 제공하십시오. sp_executesql에 매개 변수 대체를 사용하거나 ADO, OLE DB, ODBC 및 DB 라이브러리 API의 매개 변수 바인딩을 사용합니다.

예를 들면 다음 SELECT 문과 같이 코딩하지 마십시오.

SELECT * FROM Northwind.dbo.Shippers WHERE ShipperID = 3

ODBC를 사용하는 대신, 한 예로 SQLBindParameter ODBC 함수를 사용하여 매개 변수 표시(?)를 프로그램 변수에 바인드하고 SELECT 문을 다음과 같이 코딩하십시오.

SELECT * FROM Northwind.dbo.Shippers WHERE ShipperID = ?

·                     Transact-SQL 스크립트, 저장 프로시저 또는 트리거에서 sp_executesql을 사용하여 SELECT 문을 실행하십시오.

DECLARE @IntVariable INT
DECLARE @SQLString NVARCHAR(500)
DECLARE @ParmDefinition NVARCHAR(500)
/* Build the SQL string. */
SET @SQLString =
N'SELECT * FROM Northwind.dbo.Shippers WHERE ShipperID = @ShipID'
/* Specify the parameter format once. */
SET @ParmDefinition = N'@ShipID int'
/* Execute the string. */
SET @IntVariable = 3
EXECUTE sp_executesql @SQLString, @ParmDefinition,
@ShipID = @IntVariable

sp_executesql 은 별도의 저장 프로시저를 작성 및 유지 관리할 때 오버헤드가 생기는 것을 원치 않는 경우에 좋은 대안입니다.

일괄 처리에 대한 실행 계획 재사용

여러 개의 동시 실행 응용 프로그램이 알고 있는 매개 변수 집합이 지정된 동일한 일괄 처리를 실행할 경우, 응용 프로그램에 의해 호출되는 저장 프로시저로 일괄 처리를 구현하십시오.

ADO, OLE DB 또는 ODBC 응용 프로그램이 동일한 일괄 처리를 여러 번 실행할 경우, PREPARE/EXECUTE 모델을 사용하여 일괄 처리를 실행하십시오. 프로그램 변수에 바인드된 매개 변수 표시를 사용하여 필요한 모든 입력 값을 제공하십시오. 예를 들면 UPDATE VALUES 절에 사용되는 식이나 검색 조건의 조건자에 사용되는 식입니다.

열의 통계 관리

SQL Server에서는 열이 인덱스에 속하지 않더라도 열의 값 분산에 사용할 통계 정보를 작성할 수 있습니다. 쿼리 프로세서는 이 통계 정보를 사용하여 쿼리 평가에 가장 적합한 전략을 결정할 수 있습니다. 인덱스를 만들면, SQL Server는 인덱싱된 열에 값을 분산시키는 작업과 관련된 통계 정보를 자동으로 저장합니다. 인덱싱된 열 외에, AUTO_CREATE_STATISTICS 데이터베이스 옵션이 ON(기본값)으로 설정된 경우에도 SQL Server가 조건자에 사용된 열에 대한 통계를 자동으로 생성합니다. 해당 열이 인덱싱된 열이 아닐 경우에도 마찬가지입니다.

열의 데이터가 변경되면, 인덱스와 열 통계가 더 이상 올바르지 않게 되고 쿼리 최적화 프로그램이 쿼리 처리 방법에 대해 최적의 결정을 내릴 수 없게 됩니다. 주기적으로 SQL Server는 테이블의 데이터 변경에 따른 통계 정보를 자동으로 업데이트합니다. 샘플링은 데이터 페이지에서 무작위로 이루어지며, 통계에 필요한 열에 최소 크기의 클러스터링되지 않은 인덱스 또는 테이블로부터 가져옵니다. 디스크에서 읽어온 데이터 페이지의 모든 행을 사용하여 통계 정보를 업데이트합니다. 통계 정보의 업데이트 주기는 열의 데이터 크기나 인덱스 및 변경 데이터의 크기에 따라 결정됩니다.

예를 들어, 10,000개의 행을 포함하는 테이블에 대한 통계는 1,000개의 인덱스 값이 변경된 후 업데이트되어야 할 수 있습니다. 이 테이블에서 10,000개 중 1,000개는 큰 비율이기 때문입니다. 그러나 천만 개의 인덱스 항목이 포함된 테이블에서 1,000개의 변경되는 인덱스 값은 그리 중요하지 않기 때문에 자동으로 통계가 업데이트되지 않을 수도 있습니다. 그러나 SQL Server는 언제나 최소의 행이 샘플링되도록 유지합니다. 즉, 항상 8MB 미만의 테이블이 완전 스캔되어 통계를 수집하도록 합니다.

참고 쿼리의 실행 계획이 SQL 쿼리 분석기를 통해 그래픽으로 표시될 때, 오래되었거나 누락된 통계에는 경고(빨간색 테이블 이름) 표시가 됩니다. 또한 SQL 프로필러를 사용하는 Missing Column Statistics 이벤트 클래스는 통계가 유실될 때 이를 표시해 줍니다.

통계는 sp_createstats 시스템 저장 프로시저를 사용하여 한 명령문으로 현재 데이터베이스의 모든 사용자 테이블에서 적합한 모든 열에 쉽게 생성될 수 있습니다. 통계에 적합하지 않은 열에는 결정적이지 않은 또는 정확하지 않은 계산된 열, 또는 image, text 및 ntext 테이터 형식의 열이 있습니다.

수동으로 통계를 작성하면 여러 행 밀도(열 조합에 대한 평균 중복 수)를 포함하는 통계를 구할 수 있습니다. 예를 들면 쿼리가 다음과 같은 절을 포함합니다.

WHERE a = 7 and b = 9

두 열(a, b) 모두에 대한 통계를 수동으로 작성하면 SQL Server가 쿼리를 더 잘 평가할 수 있는데, 그 이유는 a와 b 열 조합에 대한 고유한 값의 평균도 통계에 포함되기 때문입니다. 이렇게 하면 SQL Server에서 테이블 스캔에 의존할 필요 없이 col1에 만들어진 인덱스를 사용할 수 있습니다(이 경우 클러스터링된 인덱스). 열 통계를 작성하는 방법에 대해서는 SQL Server Books Online의 "CREATE STATISTICS"를 참조하십시오.

추가 정보 찾기

·       SQL Server 온라인 문서는 SQL Server 아키텍처와 데이터베이스 조정에 대한 정보는 물론 명령 구문과 관리에 대한 전체 문서를 제공합니다. SQL Server 온라인 문서는 모든 SQL Server 클라이언트 또는 서버를 설치할 때 SQL Server 설치 미디어에서 설치할 수 있습니다.

·       Microsoft SQL Server에 대한 최신 정보(SQL Server에 대한 기술 백서 포함)를 보려면 다음의 Microsoft SQL Server 웹 사이트를 방문하십시오.

·       http://www.microsoft.com/korea/sql

·       http://www.microsoft.com/korea/technet/sql

·       http://www.microsoft.com/korea/msdn/sqlserver

·       정기적 간행물 형식의 정보를 제공하는 외부 리소스는 http://www.sqlmag.com  에 나와 있습니다. 여기서는 SQL Server의 내부 작업을 개괄적으로 설명하는 많은 최적화 및 조정 힌트, 코드 샘플 및 기타 중요한 정보를 제공합니다. information.

·       Delaney, Kalen & Soukup, Ron. Inside Microsoft SQL Server 2000, Microsoft Press, 2001.

이 책은 이전 버전(Inside Microsoft SQL Server 7.0)을 SQL Server 2000 정보를 이용하여 업데이트한 것으로, 쉽게 구하기 어려운 SQL Server의 본질적 개념에 대해 중점적으로 설명합니다.

·       Kimball, Ralph. Data Warehouse Lifecycle Toolkit, John Wiley & Sons, 1998.

많은 사람들이 최고의 데이터 웨어하우징 입문서 중 하나로 꼽는 책입니다. 데이터 웨어하우스 데이터베이스 설계에 대한 탁월한 통찰력을 제공하고 차원 모델링 개념에 대해 상세하게 설명하고 있습니다.

·       Celko, Joe. SQL for Smarties. Morgan Kaufmann, 1999.

이 책에는 매우 유용한 정보가 들어 있습니다. 계층 데이터를 표현하고 쿼리하는 것과 같은 공통적인 문제에 대한 해결책이 들어 있습니다. 28장은 SQL 쿼리 최적화에 대한 것입니다.

이 문서에 포함된 정보는 문서를 발행할 때 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 나타냅니다. Microsoft는 변화하는 시장 환경에 대처해야 하므로 이를 Microsoft 측의 책임으로 해석해서는 안되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보증하지 않습니다.

이 백서는 정보 제공 목적으로만 제공됩니다. MICROSOFT는 이 문서에서 명시적이든 묵시적이든 막론하고 여하한 보증도 하지 않습니다.

해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권의 권리와 별도로, 이 설명서의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법)으로 또는 어떠한 목적으로도 복제하거나, 검색 시스템에 저장 또는 도입하거나, 전송할 수 없습니다.

Microsoft는 본 설명서 내용과 관련된 특허권, 상표권, 저작권 또는 기타 지적 소유권을 보유할 수 있습니다. 서면 사용권 계약에 따라 Microsoft에서 귀하에게 명시적으로 권리를 제공하지 않으면, 이 설명서 제공으로는 이러한 특허권, 상표권, 저작권 또는 기타 지적 소유권 등에 대한 어떠한 사용권도 귀하에게 부여되지 않습니다.