[펌] MS SQL Server 7.0 성능 조정 가이드

MS SQL Server 7.0 성능 조정 가이드

헨리 라우
Microsoft Corporation

1998년 10월

요약 데이터베이스 관리자와 개발자에게 Microsoft® SQL Server 7.0™ 인덱스 선택, 디스크 I/O 조정 및 SQL Server 7.0 성능 조정 도구에 대한 정보를 제공합니다.

대상

이 성능 조정 가이드는 데이터베이스 관리자가 Microsoft SQL Server가 최대 성능을 발휘하도록 구성하는 데 도움을 주고 SQL Server 환경에서 성능이 낮은 원인을 판단하는 데 도움을 주기 위해 디자인되었습니다. 또한 이 가이드는 SQL Server 응용 프로그램 개발자에게 SQL Server 인덱스와 SQL Server 도구를 사용하여 SQL 쿼리의 I/O 성능 효율을 분석하는 방법에 대한 지침을 제공합니다.

SQL Server 6.x 와 7.0 성능 조정에 대한 비교 정보

SQL 6.x 에 관한 고려 사항	SQL Server 7.0에서 향상된 기능 및 원리
성능 조정 과정에서 고려해야 할 구성 옵션이 많습니다.	SQL Server 7.0에서 향상된 부분 중 하나는 데이터베이스 엔진이 전체적으로 자체 구성, 자체 조정 및 자체 관리 기능을 상당히 갖추게 되었다는 점입니다. LazyWrtier와 미리 읽기 관리자는 자체 조정이 가능합니다.Max Async I/O는 아마 대용량 저장 장치를 갖춘 서버를 사용할 때 처음에 구성해야 할 유일한 sp_configure 옵션일 것입니다. 조정과 관련된 요구 사항이 이렇게 줄어들었기 때문에 소중한 관리 시간을 절약하여 다른 작업에 사용할 수 있습니다. 이 설명서의 이전 버전인 "Microsoft SQL Server 6.5:I/O Performance Tuning Quick Reference"(http://msdn.microsoft.com/developer/news/sqlperftune.htm)에 익숙한 사용자라면 데이터베이스 관리자가 양호한 SQL Server 성능을 얻기 위하여 직접 조정해야 하는 sp_configure 옵션이 그리 많지 않다는 사실을 알 수 있을 것입니다. 이전 버전의 SQL Server에서 사용하던 sp_configure 옵션 중 많은 부분을 아직도 직접 구성하고 조절할 수 있지만, 데이터베이스 관리자는 SQL Server가 기본값으로 제공하는 모든 sp_configure 옵션을 자동으로 구성하고 조정하도록 놓아두는 것이 좋습니다. 이렇게 하면 SQL Server는 데이터베이스 서버 구성을 데이터베이스 서버 변경에 영향을 주는 요인으로서 자동으로 조정하게 됩니다. 이러한 요인으로는 SQL Server 및 기타 데이터베이스 서버에서 실행되는 응용 프로그램용 RAM과 CPU 활용을 들 수 있습니다.
LazyWriter를 수동으로 조정해야 하는 경우가 가끔 있습니다.	SQL Server 7.0은 자동으로 LazyWriter를 구성하고 조정합니다. 이제는 "free buffer"와 "max lazywriter io"를 직접 조정할 필요가 없습니다. 사용 가능한 버퍼와 LazyWriter I/O 작업은 뒤에서 설명하는 새로운 SQL Server 7.0 성능 모니터 개체를 사용하여 모니터할 수 있습니다.
검사점을 수동으로 조정해야 하는 경우가 가끔 있습니다.	SQL Server 7.0 이전 버전에서는 "복구 간격"도 검사점 프로세스를 조정하는 데 사용되었습니다. SQL Server 7.0은 복구 간격 옵션을 자동으로 조정합니다. SQL Server 7.0에서 복구 간격 기본값 0은 SQL Server가 복구 간격을 자동으로 모니터하고 조정한다는 것을 의미합니다. 이 기본값 설정은 시스템에 예외적으로 긴 시간 동안 트랜잭션이 일어나지 않는 한 모든 데이터베이스에 대한 복구 시간을 1분 이내로 유지합니다. 자세한 내용은 SQL Server 온라인 설명서에서 "Checkpoints and the Active Portion of the Log"와 "troubleshooting recovery interval" 문자열을 검색해 보십시오. SQL Server 온라인 설명서 설치에 대한 자세한 내용은 이 설명서 뒷부분에 있는 "추가 정보" 절을 참조하십시오.
이전에는 SQL Server 6.x 로그 페이지가 RAM 캐시를 데이터 페이지와 공유합니다. 로그 관리자를 수동으로 조정해야 하는 경우가 가끔 있습니다.	SQL Server 7.0의 SQL Server 로그 관리자는 이전 버전 SQL Server 로그 관리자에 비해 크게 달라졌습니다. SQL Server 7.0 로그 관리자는 자체 로그 캐시를 관리합니다. 따라서 이전 버전 SQL Server에 있던 SYSLOGS 테이블에 대한 종속성이 이제는 없습니다. 이와 같이 로그 파일 관리를 데이터 캐시 관리와 분리함으로써 양쪽 구성 요소의 성능이 향상됩니다. 또한 SQL Server 로그 관리자는 이전보다 용량이 더 큰 디스크 I/O 성능을 갖추고 있습니다. SQL 서버 로그 작업의 순차적 특성과 결합된 대용량 I/O 크기는 디스크 I/O 성능을 크게 향상시켜 로그 관리자에게 큰 도움이 됩니다. SQL Server 7.0은 SQL Server 로그 관리자의 성능을 자동으로 조정합니다. 이제는 sp_configure 옵션인 logwirte sleep을 직접 조정할 필요가 없습니다. SQL Server 7.0에서는 이 옵션이 제거되었습니다. 자세한 내용은 SQL Server 온라인 설명서에서 "logwrite sleep" 문자열을 검색해 보십시오.

SQL Server 성능 조정 원리

• 조정 작업 대부분을 SQL Server에게 맡기십시오.

  SQL Server 7.0은 많은 부분을 자동으로 구성하고 자체 조정이 가능한 데이터베이스 서버를 만들 수 있을 정도로 현저히 개선되었습니다. SQL Server 자동 조정 설정을 활용하면 시간이 지나면서 사용자 부하와 쿼리가 변화하더라도 SQL Server가 최고 성능을 발휘하는 데 도움이 될 것입니다.

• RAM은 제한된 리소스입니다.

  모든 데이터베이스 서버 환경의 주된 부분은 RAM 버퍼 캐시 관리입니다. 동일한 데이터라도 RAM 캐시에서 액세스하는 것이 디스크에서 액세스하는 것보다 훨씬 빠릅니다. 그러나 RAM은 제한된 리소스입니다. 데이터베이스 I/O(물리적 디스크 하위 시스템에 대한 입출력 작업)를 줄임으로써 필요한 데이터 및 인덱스 페이지 집합을 최소화할 수 있다면 이들 페이지는 RAM에 더 오래 머물게 될 것입니다. 필요하지 않은 데이터와 인덱스 정보가 버퍼 캐시로 너무 많이 들어가면 귀중한 페이지들이 그만큼 빨리 밀려 나오게 됩니다. 성능 조정의 주된 목적은 I/O를 감소시켜 버퍼 캐시를 최대한 활용하는 것입니다.

• 쓸모 있는 인덱스를 만들어 유지하십시오.

  모든 데이터베이스 쿼리에 대해 I/O를 최소한으로 유지하는 중요한 요소는 쓸모 있는 인덱스를 만들어 유지하는 것입니다.

• 디스크 I/O 하위 시스템 성능을 모니터하십시오.

  물리적 디스크 하위 시스템은 반드시 데이터베이스 서버에 충분한 I/O 처리 능력을 제공하여 데이터베이스 서버가 디스크 대기열 없이 실행될 수 있도록 해야 합니다. 디스크 대기열은 성능을 저하시키는 원인이 됩니다. 이 설명서에서는 디스크 I/O 문제를 감지하고 이 문제를 해결하는 방법에 대하여 설명합니다.

• 응용 프로그램 및 쿼리 조정

  데이터베이스 서버가 특정 응용 프로그램을 통한 수많은 연결에서 오는 요청에 서비스를 제공할 때는 응용 프로그램과 쿼리 조정이 특히 중요합니다. 응용 프로그램들은 대개 데이터베이스 서버에서 실행될 SQL 쿼리를 결정하기 때문에, 응용 프로그램 개발자가 SQL Server 구조의 기본 원리를 이해하고 SQL Server 인덱스의 이점을 완전히 활용하여 I/O를 최소화하는 것은 아주 중요한 사항입니다.

• SQL Server 프로파일러와 인덱스 튜닝 마법사 조합의 강력한 이점을 활용하십시오.

  SQL Server 프로파일러를 사용하면 SQL Server의 작업 부하를 모니터하고 로그에 기록할 수 있습니다. 로그에 기록된 작업 부하는 다시 SQL Server 인덱스 튜닝 마법사로 보내져서, 필요한 경우 성능을 높일 수 있게 인덱스가 변경되도록 합니다. SQL 프로파일러와 인덱스 튜닝 마법사를 정기적으로 사용하면, 시간이 가면서 전체적인 쿼리 작업 부하가 달라질 때 SQL Server가 바람직한 성능을 발휘하도록 하는 데 도움이 됩니다.

• SQL Server 성능 모니터의 이점을 활용하여 병목 지점을 찾아내십시오.

  SQL Server 7.0은 개정된 성능 모니터 개체 및 카운터 집합을 제공합니다. 이것들은 SQL Server의 동작을 모니터하고 분석하는 데 유용한 정보를 제공하도록 디자인되었습니다. 이 설명서에서는 주의해야 할 주요 성능 모니터 카운터에 대해 설명합니다.

• SQL Server 쿼리 분석기와 그래픽 표시의 이점을 활용하십시오.

  SQL Server 7.0에는 그래픽 표시가 도입되었습니다. 이는 문제가 있는 SQL 쿼리를 쉽게 분석할 수 있는 메서드입니다. 통계 I/O는 쿼리 분석기의 또 다른 중요한 면으로, 이 문서에서 설명할 것입니다.

SQL Server 구성에 필요한 성능 항목

max async I/O

성능이 낮은 디스크 하위 시스템인 경우에는 기본값 32이면 충분합니다. 디스크 I/O 전송 속도가 매우 높은 데이터베이스 서버에 장착된 고성능 RAID 저장 하위 시스템의 경우, 32라는 설정값은 이 RAID 하위 시스템의 성능을 무시하는 설정입니다. RAID 하위 시스템은 32개 이상의 디스크 전송 요청을 동시에 처리할 수 있기 때문입니다. 이에 더하여 SQL Server 쓰기 동작에 더 큰 디스크 전송 성능이 요구되는 경우에는 max async I/O를 더 높은 값으로 설정해야 합니다.

참고 Microsoft Windows 95/98 플랫폼에서는 비동기 I/O가 지원되지 않으므로 이 옵션은 적용되지 않습니다.

max async I/O값은 검사점이 "충분히 빠르게" 작동될 수 있는 값으로 설정하는 것이 좋습니다. 목표는 다른 검사점이 필요해지기 전에 작업을 마칠 수 있도록 바람직한 복구 특성에 따라 검사점을 충분히 빠르게, 그러나 시스템이 디스크 대기열 같은 이벤트로 인해 지나치게 불안해질 정도로 빠르지는 않게 설정하는 것입니다. 디스크 대기열에 대해서는 이 설명서 뒷부분에서 자세히 설명합니다.

대형 디스크 하위 시스템에서 실행되는 SQL Server에 대해 max async I/O를 설정하는 가장 좋은 방법은 동시 I/O에 사용할 수 있는 물리적 드라이브의 수에 2 또는 3을 곱하는 것입니다. 그런 다음 성능 모니터를 살펴보아 디스크 작동이나 대기열에 문제가 없는지 확인합니다. 이 구성 옵션을 너무 높게 설정하면 검사점이 읽기 같은 다른 SQL Server I/O 작업에 필요한 디스크 하위 시스템 대역폭을 독점하게 되는 부정적인 측면이 있습니다.

이 값을 설정하려면 SQL Server 쿼리 분석기에서 "sp_configure 'max async io', <value>" 명령을 실행합니다. 여기서 <value>는 SQL Server 시스템이 검사점 작업을 수행하면서 Windows에 전달할 수 있는 동시 디스크 I/O 요청의 수를 의미합니다. Windows는 전달된 이 요청을 다시 물리적 디스크 하위 시스템으로 전달합니다.(자세한 내용은 이 설명서 뒷부분에 있는 "디스크 I/O 성능" 절을 참조하십시오.) 이 구성 옵션은 동적입니다. 따라서 구성을 반영하기 위해 SQL 서버를 종료했다가 다시 시작하지 않아도 됩니다.

자세한 내용은 SQL Server 온라인 설명서에서 "I/O architecture"와 "max async I/O option" 문자열을 검색해 보십시오.

CPU와 디스크 I/O 리소스를 소모하는 구성 요소

작업자 스레드

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

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

자세한 내용은 SQL Server 온라인 설명서에서 "max worker threads option", "sql server threads", "Optimizing Server Performance Using Memory Configuration Options", "sql server memory pool", "Transaction Recovery", "write ahead transaction log", "Freeing and Writing Buffer Pages" 등의 문자열을 검색해 보십시오.

LazyWriter

SQL Server LazyWriter는 사용 가능한 버퍼를 생성하는 데 도움이 되는 아무 데이터도 들어 있지 않은 8KB 데이터 캐시 페이지입니다. LazyWriter가 8KB 캐시 버퍼를 디스크로 옮길 때는 캐시 페이지의 ID를 초기화하여 다른 데이터가 사용 가능한 버퍼에 씌어질 수 있도록 해야 합니다. LazyWriter는 디스크 I/O가 적은 시간에 사용 가능한 버퍼를 생성함으로써 디스크 I/O 리소스를 언제든지 사용 가능한 상태로 유지하고 다른 SQL Server 동작에 미치는 영향이 최소화되도록 합니다.

SQL Server 7.0은 사용 가능한 버퍼 수준을 자동으로 구성하고 관리합니다. "SQL Server: Buffer Manager-Free Buffers"를 모니터하여 이 값이 충분한지 확인합니다. LazyWriter는 SQL Server가 동작하는 동안 이 카운터 수준을 최적의 상태로 유지함으로써, 사용 가능한 버퍼에 대한 사용자 요구를 만족시킵니다. 성능 모니터 개체인 "SQL Server: Buffer Manager-Free Buffers"가 0이 되는 것은 좋지 않습니다. 이는 사용 가능한 버퍼에 대한 사용자 부하의 요구가 SQL Server LazyWriter가 제공할 수 있는 수준보다 높은 경우가 많았음을 의미합니다.

LazyWriter가 사용 가능한 버퍼를 안정 수준으로 또는 적어도 0 이상으로 유지하는 데 문제가 있다면, 이는 디스크 하위 시스템이 LazyWriter가 필요로 하는 디스크 I/O 성능을 제공하지 못한다는 뜻일 수 있습니다. 정말로 그런지 확인하려면 다른 디스크 대기열에 비해 사용 가능한 버퍼 수준이 얼마나 낮은지 비교해 보면 됩니다. 해결책은 "스핀들"이라고도 부르는 여분의 물리적 디스크 드라이브를 데이터베이스 서버 디스크 하위 시스템에 추가하여 디스크 I/O 처리 능력을 높이는 것입니다. "SQL Server: Buffer Manager-Lazy Writes/sec"는 디스크에 물리적으로 기록되는 8KB 페이지의 수를 나타냅니다.

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

max async I/O를 사용하여 LazyWriter 디스크 I/O 요청 동작을 조절합니다. sp_configure 옵션인 max async I/O는 SQL Server가 Windows에 이어 디스크 I/O 하위 시스템으로 동시에 전달할 수 있는 8KB 디스크 쓰기 요청(LazyWriter, 검사점 및 작업자 스레드에서 들어오는 요청 포함) 수를 제어합니다.디스크 대기열이 허용할 수 없는 수준으로 발생하면 max async I/O를 줄입니다. SQL Server가 현재 구성된 max async I/O의 수준을 반드시 유지해야 하는 경우에는, 디스크 대기열이 허용 가능한 수준이 될 때까지 디스크 하위 시스템에 디스크를 추가합니다.

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

검사점

검사점은 커밋되지 않은 데이터 페이지를 SQL Server 데이터 파일로 기록합니다. 커밋되지 않은 데이터 페이지는 버퍼 캐시로 들어온 이후에 변경된 버퍼 캐시 페이지를 말합니다. 검사점이 디스크에 쓴 버퍼는 여전히 해당 페이지를 포함하고 있으며 사용자는 이 페이지를 디스크에서 다시 읽지 않고도 읽거나 갱신할 수 있습니다. 이는 LazyWriter가 만든 사용 가능한 버퍼와는 다른 경우입니다.

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

캐시에서 제거해야 할 페이지 수가 많을 때 검사점을 더욱 효율적으로 만들기 위하여 SQL Server는 삭제될 데이터 페이지를 디스크에 나타나는 순서대로 정렬합니다. 이렇게 하면 캐시 플러시 과정에서 디스크 암의 움직임을 최소화하는 데 도움이 되며 순차적 디스크 I/O의 이점을 활용할 수도 있습니다. 또한 검사점은 또한 8KB 디스크 I/O 요청을 비동기적으로 디스크 하위 시스템에 전달합니다. 이렇게 되면 SQL Server는 필요한 디스크 I/O 요청을 더 빨리 전달할 수 있습니다. 이는 검사점이 해당 데이터가 실제로 디스크에 기록되었음을 디스크 하위 시스템이 보고할 때까지 기다리지 않기 때문입니다.

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

max async I/O를 사용하여 검사점의 커밋되지 않은 데이터 페이지 플러시 동작을 조절합니다. sp_configure 옵션인 max async I/O는 검사점이 Windows에 이어 디스크 I/O 하위 시스템으로 동시에 전달할 수 있는 8KB 캐시 플러시 수를 제어합니다. 디스크 대기열이 허용할 수 없는 수준으로 발생하면 max async I/O를 줄입니다. SQL Server가 현재 구성된 max async I/O의 수준을 반드시 유지해야 하는 경우에는, 디스크 대기열이 허용 가능한 수준이 될 때까지 디스크 하위 시스템에 디스크를 추가합니다.

한편, SQL Server가 검사점을 실행하는 속도를 높일 필요가 있고 디스크 하위 시스템은 디스크 대기열을 발생시키지 않으면서도 증가된 디스크 I/O를 처리할 수 있을 정도로 충분히 강력한 경우에는 max async I/O를 높여 SQL Server가 보다 많은 디스크 I/O 요청을 동시에 보낼 수 있도록 해서 I/O 성능을 향상시킬 수 있습니다. max async I/O를 변경한 후에는 디스크 대기열 카운터를 신중히 살펴보아야 합니다. 디스크 쓰기 대기열 이외에 디스크 읽기 대기열도 살펴보아야 합니다. 주어진 디스크 하위 시스템에 max async I/O가 너무 높게 설정되면 검사점은 많은 수의 디스크 쓰기 I/O 요청을 대기열에 집어넣게 되므로 SQL Server 읽기 동작이 차단되는 원인이 될 수 있습니다. 출력 데이터의 하나로 Reads Outstanding을 제공하는 DBCC PERFMON은 성능 모니터를 관찰하여 대기열에 있는 SQL Server 읽기를 살펴보는 데 적합한 카운터입니다. 성능 모니터의 Physical Disk와 Logical Disk 개체는 Average Disk Read Queue Length 카운터를 제공하는데, 이 카운터 역시 대기열에 있는 디스크 읽기 I/O 요청을 모니터하는 데 사용할 수 있습니다. 검사점에 의해 디스크 읽기 대기열이 발생하면 max async I/O를 줄이거나 하드 드라이브를 추가하여 검사점과 읽기 요청이 동시에 처리될 수 있도록 해야 합니다.

로그 관리자

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

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

SQL Server 로그 파일과 연관된 디스크 대기열을 확인하는 방법은 SQL Server 데이터베이스 파일마다 다릅니다. "SQL Server: Databases <데이터베이스 인스턴스>: Log Flush Waits Times"와 "SQL Server:Databases <데이터베이스 인스턴스>: Log Flush Waits/sec" 등의 성능 모니터 카운터를 사용하여 데이터 하위 시스템에 처리를 기다리는 로그 작성자 요청이 있는지 확인합니다.

정전 같은 상황에서도 맡겨진 데이터가 결국은 디스크에 씌어질 것이 확실하다면 AQL Server 로그 파일용 캐시 컨트롤러를 사용해도 좋습니다. 사실 이것은 최고의 성능을 위해 필요합니다. 캐시 컨트롤러에 대한 자세한 내용은 뒤에 나오는 "하드웨어 RAID 컨트롤러에 내장된 캐시의 효과" 절을 참조하십시오.

자세한 내용은 SQL Server 온라인 설명서에서 "Transaction Recovery", "SQL Server: Log Manager Object" 및 "optimizing transaction log performance" 문자열을 검색해 보십시오.

미리 읽기 관리자

SQL Server 7.0 미리 읽기 관리자는 완전한 자체 구성 및 자체 조정이 가능합니다. 미리 읽기 관리자는 SQL Server 쿼리 처리기의 동작과 완전히 통합되어 있습니다. 쿼리 처리기는 미리 읽기 스캔을 활용할 수 있는 상황에 대하여 미리 읽기 관리자와 정보를 주고 받습니다. 미리 읽기를 활용할 수 있는 상황으로는 대형 테이블 스캔, 대형 인덱스 범위 스캔 그리고 클러스터된 인덱스 B-트리와 클러스터되지 않은 인덱스 B-트리 등을 들 수 있습니다. 이것은 미리 읽기가 8KB I/O에 비해 더 많은 디스크 처리량을 제공하는 64KB I/O로 발생하기 때문입니다. SQL Server에서 많은 양의 데이터를 복구해야 하는 경우에는 미리 읽기가 가장 좋은 방법입니다.

미리 읽기 관리자는 보다 간단하고 효율적인 인덱스 할당 맵(IAM) 저장 구조를 활용합니다. IAM은 SQL Server 7.0에 새로 도입한 확장 영역 위치 기록용 메서드입니다(확장 영역 한 개당 총 64KB의 정보에 해당하는 SQL Server 데이터 또는 인덱스 정보 8페이지 분량). IAM은 IAM이 포함하는 확장 영역 범위 내에서 어떤 확장 영역이 필요한 데이터를 포함하는지에 정보를 비트맵으로 빽빽이 집어넣은 8KB 분량의 페이지입니다. IAM 페이지는 압축된 형식이기 때문에, 읽기가 빠를 뿐만 아니라 자주 사용되는 IAM 페이지는 늘 버퍼 캐시에 유지합니다.

미리 읽기 관리자는 쿼리 처리기의 쿼리 정보를 결합하고 IAM 페이지에서 읽혀져야 할 모든 확장 영역의 위치를 빠르게 검색함으로써 순차적 읽기 요청을 여러 개 구성할 수 있습니다. 순차적 64KB 디스크 읽기는 극히 양호한 디스크 I/O 성능을 제공합니다.

"SQL Server: Buffer Manager—Read-Ahead Pages"는 SQL Server 미리 읽기 관리자와 관련하여 관찰해야 할 중요한 성능 모니터 카운터입니다. 자세한 내용을 보려면 DBCC PERFMON (IOSTATS) 명령어를 실행합니다. "RA Pages Found in Cache"와 "RA Pages Placed in Cache"에 관한 정보가 포함되어 있습니다. 페이지가 이미 해시되었으면(즉, 응용 프로그램이 페이지를 먼저 읽어 미리 읽기 기능이 이미 사용되었으면) 이것은 "캐시에서 발견된 페이지"로 간주됩니다. 페이지가 이미 해시되지 않았으면(즉, 미리 읽기가 성공적이면) 이것은 "캐시에 있는 페이지"로 간주됩.

미리 읽기 관리자의 한가지 단점은, 미리 읽기가 너무 많은 경우 전체적인 성능에 나쁜 영향을 미칠 수 있다는 것입니다. 이는 미리 읽기 관리자가 필요하지 않은 페이지로 캐시를 채우게 됨에 따라 다른 용도로 사용할 수 있을 추가 I/O와 CPU를 요구할 수 있기 때문입니다. 해결책은 전체적인 성능 조정 목표를 세우는 것입니다. 다시 말해서, 최소한의 페이지가 버퍼 캐시에 들어가도록 모든 SQL 쿼리를 조정하는 것입니다. 여기에는 꼭 필요한 작업에 꼭 알맞은 인덱스를 사용하는 것이 포함됩니다. 클러스터된 인덱스를 저장하여 효율적인 범위 스캔이 되도록 하고, 클러스터되지 않은 인덱스를 단일 행이나 그보다 더 작은 행 집합의 위치를 신속하게 찾는 데 도움이 되도록 정의하는 것도 포함됩니다. 한 테이블에 하나의 인덱스만 만들고 이 인덱스를 단일 행 또는 그보다 더 작은 행 집합을 반입하는 용도로 사용하는 경우에는 인덱스에 클러스터 설정을 해야 합니다. 이는 클러스터된 인덱스의 처리 속도가 클러스터되지 않은 인덱스보다 빠르기 때문입니다. 그러나 범위 스캔의 경우처럼 큰 차이는 없습니다.

자세한 내용은 SQL Server 온라인 설명서에서 "reading pages", "DBCC PERFMON", "Table and Index Architecture", "Heap Structures" 및 "read-ahead pages" 문자열을 검색해 보십시오.

디스크 I/O 성능

단 몇 기가바이트(GB) 정도의 데이터만을 포함하며 읽기나 쓰기 작업도 그리 과중하지 않은 SQL Server를 구성하는 경우에는, 디스크 I/O 문제와 최대 성능을 위해 하드 드라이브들 간에 SQL Server I/O 동작 균형을 조절하는 문제는 그리 중요하지 않습니다. 그러나 수백 기가바이트의 데이터를 포함하고 읽기 및 쓰기 작업도 과중한 대용량 SQL Server 데이터베이스를 구축할 때에는 여러 하드 드라이브 사이에서 로드 균형을 조절하여 SQL Server 디스크 I/O 성능이 극대화되도록 구성해야 합니다.

알려진 디스크 전송 속도와 SQL Server와의 관계

데이터베이스 성능 조정에 있어 가장 중요한 것 중 하나는 I/O 성능 조정입니다. SQL Server도 이러한 측면에서 예외가 될 수 없습니다. SQL Server가 실행되는 컴퓨터에 전체 데이터베이스를 유지할 수 있을 정도로 RAM이 충분하지 않은 한, I/O 성능은 디스크 I/O 하위 시스템이 SQL Server 데이터 읽기와 쓰기를 얼마나 빨리 처리할 수 있는가에 따라 결정됩니다.

기억해 둘 만한 점은, 일반적인 Wide Ultra SCSI-3 하드 드라이브가 Windows와 SQL Server에 대하여 1초에 약 75번의 비순차(임의) I/O 작업과 150번의 순차 I/O 작업을 제공한다는 사실입니다. 이 하드 드라이브의 알려진 전송 속도는 1초에 약 40MB입니다. 알아 두어야 할 것은, 데이터베이스 서버가 1초에 40MB의 전송 속도보다는 1초에 75/150 I/O 전송에 의해 제한될 가능성이 훨씬 크다는 점입니다. 이를 수식으로 표현하면 아래와 같습니다.

(75 임의 I/O 작업/초) X (8KB 전송 속도) = 600 KB/초

위 계산은 특정 하드 드라이브에서 전적인 임의 읽기 및 쓰기 SQL Server 작업(단일 페이지 읽기 및 쓰기)을 하는 경우로서, 이 하드 드라이브에서는 1초에 최대 600KB(0.6MB)가 처리되는 것으로 보면 됩니다. 이것은 알려진 드라이브의 40MB/초 I/O 처리 용량보다 훨씬 낮은 것입니다. SQL Server 작업자 스레드, 검사점 및 LazyWriter는 8KB 전송 단위로 I/O를 수행합니다.

(150 순차 I/O 작업/초) X (8KB 전송 속도) = 1.200 KB/초

위 계산은 특정 하드 드라이브에서 전적인 순차적 읽기 및 쓰기 SQL Server 작업(단일 페이지 읽기 및 쓰기)을 하는 경우로서, 이 하드 드라이브에서는 1초에 최대 1.200KB(1.2MB)가 처리되는 것으로 보면 됩니다.

(75 임의 I/O 작업/초) X (64KB 전송 속도) = 4.800 KB(4.8MB)/초

위 계산은 전적인 임의 I/O를 한다고 가정할 때 미리 읽기에 가장 부적합한 시나리오를 보여줍니다. 완전한 임의 I/O라 하더라도 64KB 전송 크기는 단일 페이지 전송 속도(1초에 0.6MB 및 1.2MB)보다 디스크 I/O 전송 속도가 1초에 4.8MB로 훨씬 빠릅니다.

(150 순차 I/O 작업/초) X (64KB 전송 속도) = 9,600 KB(9.6MB)/초

위 계산은 특정 하드 드라이브에서 전적인 순차적 읽기 또는 쓰기 SQL Server 작업을 하는 경우로서, 이 하드 드라이브에서는 1초에 최대 9.6MB가 처리되는 것으로 보면 됩니다. 이것은 임의 I/O인 경우보다 훨씬 낫습니다. SQL Server 미리 읽기 관리자는 64KB 전송 속도로 디스크 I/O를 수행하며 미리 읽기 스캔이 순차적으로("일렬로" 또는 "디스크 순서대로"라고 표현하기도 합니다) 수행되도록 읽기 작업을 조절합니다. 미리 읽기 관리자는 I/O 작업을 순차적으로 수행하려고 하지만, 페이지 분할로 인해 확장 영역이 순차적 방식보다는 비순차적 방식으로 읽혀지는 경향이 있습니다. 따라서 페이지 분할을 제거하고 방지하는 것이 중요합니다.

로그 관리자는 최대 32KB 범위의 크기로 순차적인 로그 파일을 작성합니다.

순차적 디스크 I/O 작업과 비순차적 디스크 I/O 작업

순차와 비순차(임의)라는 용어는 하드 디스크 작업을 설명하는 데 많이 사용됩니다. 디스크 드라이브가 관련된 경우에 이 용어가 어떤 의미를 가지는지 알아보는 것도 좋을 것입니다. 하드 드라이브 하나에는 드라이브 플래터가 여러 개 있습니다. 각 드라이브 플래터는 플래터 위를 움직일 수 있고 드라이브 플래터 정보를 읽거나 데이터를 플래터로 쓸 수 있는 읽기/쓰기 헤드가 부착된 암에 읽기/쓰기 작업을 위한 서비스를 제공합니다. SQL Server에서는 하드 드라이브에 대해 기억해야 할 중요한 점이 두 가지 있습니다.

• 읽기/쓰기 헤드와 관련 디스크 암이 SQL Server와 Windows가 요구한 하드 드라이브 위치를 찾아 그 위치에서 동작하려면 움직일 수 있어야 합니다. 데이터가 하드 드라이브 플래터에서 비순차적 위치에 있으면, 하드 드라이브가 디스크 암과 읽기/쓰기 헤드를 필요한 모든 하드 드라이브 플래터 위치로 움직이는 데 더 많은 시간이 걸립니다. 이는 순차적인 경우와는 반대되는 것으로, 필요한 데이터가 모두 하드 드라이브 플래터에서 하나의 연속적인 물리적 섹션에 위치하므로 필요한 디스크 I/O 작업을 수행할 때 디스크 암과 읽기/쓰기 헤드의 움직임이 최소화됩니다. 비순차적인 경우와 순차적인 경우의 시간 차이는 상당한 정도여서, 비순차 검색의 경우는 약 50밀리초인데 비해 순차 검색의 경우는 약 2-3 밀리초입니다. 이 시간은 대략적인 값으로서, 디스크 상에서 비순차적 데이터의 확산 범위, 하드 디스크 플래터의 회전 속도(RPM 단위) 그리고 하드 드라이브의 기타 물리적 속성에 따라 달라집니다. 기억해야 할 것은 SQL Server 성능에는 순차적 I/O가 바람직하다는 점입니다.
• 이 설명서에서는 일반 하드 드라이브가 1초에 약 75번의 비순차 I/O와 150번의 순차 I/O를 지원한다고 언급한 바 있습니다. 8KB를 읽거나 쓰는 작업에 64KB를 읽거나 쓰는 작업과 거의 같은 시간이 걸린다는 점을 기억해 두시기 바랍니다. 8KB에서 약 64KB 범위일 때는, 디스크 암과 읽기/쓰기 헤드가 움직이는 시간이 단일 디스크 I/O 전송 작업에 소요되는 대부분의 시간을 차지합니다. 따라서 수학적으로 말하자면, 64KB 전송이 실제로 8KB 전송만큼 빠르고 각 전송마다 SQL Server 데이터를 여덟 배나 더 처리할 수 있으므로 64KB 이상의 SQL 데이터를 전송하는 경우에는 가능한 64KB 디스크 전송을 수행하는 것이 좋습니다. 미리 읽기 관리자는 64KB 단위로 디스크 작업을 수행하며, 이것을 SQL Server 확장 영역이라고 합니다. 로그 관리자는 이보다 더 큰 I/O 크기로도 순차 쓰기를 수행합니다. 중요한 점은, 미리 읽기 관리자를 합리적으로 사용하고 비순차적으로 액세스한 파일과 SQL Server 로그 파일을 분리해서 처리하는 것이 SQL Server 성능에 좋다는 사실입니다.

물리적 하드 드라이브에 대한 자세한 내용은 Compaq 백서 "Disk Subsystem Performance and Scalability"를 참조하십시오. 이 백서의 위치는 이 설명서의 끝에 있는 "추가 정보" 절에 나와 있습니다.

디스크 I/O 전송 속도, RAID 컨트롤러 전송 속도, PCI 버스 대역폭

일반적인 하드 디스크의 최대 전송 속도는 1초에 약 40MB이며 1초에 75번의 비순차적 디스크 전송/150번의 순차적 디스크 전송을 수행합니다. 일반적인 RAID 컨트롤러의 전송 속도는 1초에 약 40MB이며 초당 2,000번(근사값)의 디스크 전송을 수행하는 것으로 알려져 있습니다. PCI 버스의 전송 속도는 1초에 약 133MB 이상인 것으로 알려져 있습니다. 장치의 실제 최고 전송 속도는 알려진 속도와는 다르겠지만, 이 설명서에서 논의할 문제는 아닙니다. 중요한 것은, 이 전송 속도를 각 RAID 컨트롤러에 연결할 하드 드라이브 수를 결정하기 위한 기준점으로 사용하는 방법과 I/O 병목 현상을 일으키지 않고 PCI 버스 하나에 얼마나 많은 드라이브와 RAID 컨트롤러를 장착할 수 있는가 하는 점입니다.

앞의 "알려진 디스크 전송 속도와 SQL Server와의 관계" 절에서, 1초 동안 하드 드라이브에서 읽거나 하드 드라이브로 쓸 수 있는 SQL Server 데이터의 최고 크기는 9.6MB였습니다. RAID 컨트롤러가 1초에 40MB를 처리할 수 있다고 가정할 때, RAID 컨트롤러 하나에 하드 드라이브를 몇 개나 연결해야 하는지 대략적으로 계산하려면 40을 9.6으로 나누어야 합니다. 여기서 나온 값 4는, SQL Server가 64KB의 순차 I/O만 수행하는 경우 해당 컨트롤러 하나에 드라이브를 적어도 4개는 연결해야 한다는 뜻입니다. 마찬가지로 앞에서 계산한 것과 같이 전적으로 64KB 비순차 I/O인 경우, 하드 드라이브에서 컨트롤러로 보낼 수 있는 최대 데이터 양은 1초에 4.8MB입니다. 40을 4.8로 나누면 약 8이 됩니다. 따라서 비순차 64KB I/O인 경우 컨트롤러 하나에 하드 드라이브를 적어도 8는 연결해야 합니다. 임의 8KB 데이터 전송인 경우에는 드라이브가 가장 많이 필요합니다. 40을 0.6으로 나누면 약 66이 됩니다. 따라서 적어도 66개의 드라이브를 연결해야 RAID 컨트롤러가 8KB 읽기와 쓰기를 완전하게 수행할 수 있습니다. 미리 읽기 와 로그 작성에서는 8KB 이상의 전송 크기가 사용되며 SQL Server가 임의 I/O만 전적으로 수행하는 일은 아주 드물기 때문에 이 방법은 현실적이지 않습니다.

RAID 하나에 몇 개의 드라이브를 연결해야 하는지 계산할 수 있는 또 다른 방법은, 1초 동안 이루어지는 MB 수가 아니라 1초 동안 이루어지는 전송 횟수를 계산하는 것입니다. 하드 드라이브가 1초에 75번의 비순차(임의) I/O를 처리할 수 있는 경우, 약 26개의 하드 드라이브를 동시에 가동할 때 이론적으로 1초에 2,000번의 비순차적 I/O를 처리할 수 있으며 이는 단일 RAID 컨트롤러가 처리할 수 있는 최대 I/O 성능입니다. 한편, 하드 드라이브 하나는 1초에 150번의 순차 I/O를 처리할 수 있으므로 1초에 2,000번의 순차 I/O를 실행하고 RAID 컨트롤러의 처리량을 최대로 유지하려면 약 13개의 하드 드라이브가 필요합니다.

PCI 버스에 관해 살펴봅니다. RAID 커트롤러와 PCI 버스 병목 현상은 하드 드라이브와 관련된 I/O 병목 현상처럼 흔하지는 않습니다. 그러나 이해하기 쉽게 설명하기 위하여, RAID 컨트롤러에 연결된 하드 드라이브 일체가 컨트롤러를 통해서 1초에 40MB를 처리할 수 있다고 가정해 봅시다. 다음 문제는 "PCI 버스 I/O 병목 현상이 생기지 않도록 하려면 PCI 버스에 RAID 컨트롤러를 몇 개나 부착할 수 있는가" 하는 점일 것입니다. 대략적인 계산 방법은 PCI 버스의 I/O 처리 용량을 RAID 컨트롤러의 I/O 처리 용량으로 나누는 것입니다. 따라서 133을 40으로 나누면 PCI 버스 하나에 장착할 수 있는 RAID 컨트롤러 수는 약 3개입니다. 대부분의 대형 서버에는 PCI 버스가 하나 이상 제공되므로 단일 서버에 설치할 수 있는 RAID 컨트롤러 수는 더 많아질 수 있습니다.

이 계산은 하드 드라이브, RAID 컨트롤러, PCI 버스 같이 디스크 I/O 하위 시스템을 구성하는 여러 가지 구성 요소의 전송 속도 관계를 예시하기 위한 것이므로 있는 그대로 받아들여서는 안됩니다. 이는 실제 데이터베이스 서버 환경에서 일어날 가능성이 거의 없는 전적인 순차적 데이터 액세스 또는 전적인 비순차적 데이터 액세스를 가정하고 있기 때문입니다. 실제로는 순차와 비순차, 8KB와 64KB I/O가 복합적으로 이루어집니다. 그 이외의 요소들도 있기 때문에, 정확히 얼마나 많은 I/O 작업을 한 번에 일련의 하드 드라이브를 통해 수행할 수 있는지를 계산하기는 어렵습니다. RAID 컨트롤러에 사용할 수 있는 읽기/쓰기용 내장 캐시는 일련의 드라이브가 효과적으로 처리할 수 있는 I/O 수를 늘립니다. 같은 이유로, SQL Server 환경이 필요로 하는 8KB 및 64KB I/O 수를 정확히 계산하기는 더더욱 어렵습니다.

그러나 알려진 전송 속도가 실제로 SQL Server에 어떤 의미가 있는지를 이 절을 통해 알게 되기를 바랍니다.

RAID

데이터베이스 크기가 수 기가바이트를 넘게 되면서 최소한 RAID의 기본을 이해하고 이것이 데이터베이스의 성능과 어떤 관계가 있는지 아는 것이 중요합니다.

RAID의 이점은 아래와 같습니다.

• 성능. 하드웨어 RAID 컨트롤러는 Windows를 비롯하여 SQL Server 같은 응용 프로그램의 모든 데이터 쓰기/읽기를 16-128KB 크기의 조각으로 나누어 RAID 어레이에 포함되는 모든 하드 디스크로 분산합니다. 이와 같이 물리적 드라이브 전체에 데이터를 분할하면 RAID 어레이에 포함된 모든 물리적 하드 드라이브로 읽기/쓰기 I/O 작업 부하를 고루 분산하는 효과가 있습니다. 이렇게 하면 I/O 요청의 불균등한 분산으로 인해 병목 현상이 발생하지 않고 RAID 어레이에 포함된 모든 하드 디스크의 작업량이 균등해지기 때문에 디스크 I/O 성능이 향상됩니다.
• 내결함성. RAID는 하드 디스크 장애 및 이와 관련된 데이터 손실을 방지할 수 있는 미러링과 패리티 기능을 제공합니다.

미러링은 두 세트의 드라이브에 정보를 쓰는 것으로, 미러링된 드라이브 쌍의 한쪽 위에 다른 한쪽이 있는 형태입니다. 미러링이 적용된 상태에서 드라이브 하나가 손실되면 장애가 생긴 드라이브를 교체하고 그 장애 드라이브와 일치하는 드라이브의 데이터를 상대 미러 드라이브에 다시 빌드함으로써 손실된 드라이브의 데이터를 다시 구축할 수 있습니다. 대부분의 RAID 컨트롤러는 Windows와 SQL Server가 온라인 상태일 때 상대 미러 드라이브에서 손실된 드라이브 교체 및 재구축을 수행할 수 있는 기능을 제공합니다. 일반적으로 이것을 "핫플러그"가 가능한 드라이브라고 합니다. 미러링의 장점 중 하나는 내결함성이 요구되는 경우에 최고 성능을 발휘하는 RAID 옵션이라는 점입니다. 미러링 상황에서 각 SQL Server를 작성하려면 미러 세트 드라이브 하나에 한 번씩 두 번의 디스크 I/O 작업을 해야 합니다. 다른 장점은 미러링이 패리티 RAID 구현에 비해 내결함성이 뛰어나다는 것입니다. 미러링은 한 드라이브에 장애가 발생하더라도 유지될 수 있으며, 시스템 관리자가 서버를 종료하고 파일 백업에서 복구하지 않아도 미러 세트에 속하는 드라이브 중 적어도 절반은 정상 상태로 작동될 수 있습니다. 미러링의 단점은 비용입니다. 한 드라이브 분량의 데이터에 드라이브 하나씩이 필요합니다. RAID 1과 그 하이브리드인 RAID 0+1(RAID 10 또는 0/1이라고도 함)은 미러링을 통하여 구현되었습니다.

패리티는 디스크에 씌어지는 데이터에 대한 복구 정보를 계산하고 이 패리티 정보를 RAID 어레이를 구성하는 다른 드라이브에 기록하는 것입니다. 드라이브에 장애가 발생하면, 새 드라이브가 RAID에 추가되고 그 장애 드라이브의 데이터는 다른 드라이브에 기록된 복구 정보(패리티)를 가져오고 이 정보를 사용하여 장애 드라이브에서 데이터를 다시 생성함으로써 복구됩니다. RAID 5와 그 하이브리드는 패리티를 통하여 구현되었습니다. 패리티의 장점은 비용입니다. RAID 5로 보호할 드라이브 수가 몇 개이든 드라이브 하나만 추가하면 됩니다. 패리티 정보는 RAID 5 어레이에 있는 모든 드라이브에 균등하게 분산됩니다. 패리티의 단점은 성능과 내결함성입니다. 미러링이 디스크 I/O 작업을 두 번 하는 데 비해, RAID 5는 패리티를 계산하고 기록하는 추가 작업으로 인하여 각 Windows NT/SQL Server 작성마다 디스크 I/O를 네 번 수행해야 합니다. 읽기 I/O 작업 비용은 미러링과 패리티 모두 같습니다 또한 RAID 5는 단 하나의 장애 드라이브만 유지할 수 있기 때문에, 어레이를 오프라인시키고 백업 미디어에서 복구 작업을 수행하여 데이터를 복구해야 합니다.

일반적으로 바람직한 방법은 안정된 디스크 I/O 성능을 얻는 데 필요한 수의 디스크에 스트라이프하는 것입니다. 성능 모니터는 특정 RAID 어레이에 디스크 I/O 병목 현상이 발생하는 경우 이를 표시합니다. 이런 경우에는 바로 디스크를 추가하고 데이터를 RAID 어레이에 다시 분산하거나, 소형 컴퓨터 시스템 인터페이스(SCSI) 채널을 필요한 만큼 추가하여 디스크 I/O 균형을 조정하고 성능을 최대화합니다.

하드웨어 RAID 컨트롤러에 내장된 캐시의 효과

하드웨어 RAID 컨트롤러들은 대부분 어떤 형태로든 읽기 및 쓰기 캐시를 갖추고 있습니다. 캐시는 디스크 하위 시스템의 효과적인 I/O 처리 성능을 크게 향상시키므로 SQL Server에서 사용할 수 있는 캐시의 이점을 최대한 활용하십시오. 이 컨트롤러 기반 캐시 메커니즘의 원리는, 호스트 서버(즉, SQL Server)에서 들어오는 작고 어쩌면 비순차적인 I/O 요청들을 모은 뒤 다른 I/O 요청들과 함께 수 밀리초 이내에 일괄 처리함으로써 더 크고(32-128KB) 아마 순차적일 I/O 요청으로 만들어 하드 드라이브에 전달되도록 하는 것입니다. 순차적이고 더 큰 I/O일수록 처리하기가 쉬우므로, 하드 디스크가 RAID 컨트롤러에 제공할 수 있는 I/O 수가 정해져 있는 경우 디스크 I/O 처리량은 더 늘어날 것입니다. RAID 컨트롤러의 캐싱 기능이 마술처럼 하드 디스크로 하여금 1초에 보다 많은 I/O를 처리하도록 만드는 것이 아니라, RAID 컨트롤러 캐시가 들어오는 I/O 요청을 정리하는 조직적인 작업을 사용함으로써 하드 디스크의 정해진 I/O 처리 능력을 최선의 방식으로 활용하는 것입니다.

이 RAID 컨트롤러는 일반적으로 특정 형태의 백업 기능을 사용하여 자체의 캐싱 메커니즘을 보호합니다. 백업 기능은 정전이 되는 경우 일정한 시간(대개는 며칠) 동안 캐시에 씌어진 데이터를 보존하는 데 도움을 줍니다. 작업 환경에서는 서버에 적절한 무정전 전원 공급 장치(UPS)를 제공하여 데이터베이스 서버에 대한 보호를 강화함으로써 RAID 컨트롤러가 더 많은 보호 및 배터리 백업 시간을 가질 수 있도록 합니다. RAID 컨트롤러는 이를 활용하여 서버 전원에 장애가 발생했을 때 데이터를 디스크로 풀러시할 수 있습니다.

RAID 수준

RAID 1과 RAID 0+1은 RAID 수준 중 최상의 데이터 보호와 성능을 제공하지만, 디스크 요구량은 그만큼 많아집니다. 하드 디스크에 더 많은 투자를 할 수 있는 경우에는 성능과 내결함성 측면에서 RAID 1이나 RAID 0+1이 최선의 선택입니다.

RAID 5는 내결함성 비용은 가장 낮지만 패리티 정보를 디스크에 읽고 쓰기 위한 추가 I/O로 인해 쓰기 성능은 RAID 1과 RAID0+1의 절반입니다. RAID 5는 RAID 1과 RAID 0+1만큼 내결함성을 갖추지 못했습니다.

RAID 0은 내결함성 보호 없이 디스크 스트라이핑을 하기 때문에 디스크 I/O 성능은 가장 좋지만, 내결함성이 전혀 없기 때문에 이 RAID 수준은 대개 개발 데이터베이스 서버나 기타 시험 환경에서만 사용할 수 있습니다.

많은 RAID 어레이 컨트롤러가 물리적 하드 드라이브에 RAID 0+1(RAID 1/0 및 RAID 10이라고도 함) 옵션을 제공합니다. RAID 0+1은 하이브리드 RAID 솔루션입니다. 이 컨트롤러는 하위 수준에서는 정상적인 RAID 1처럼 모든 데이터를 미러링하고, 상위 수준에서는 RAID 0처럼 컨트롤러가 모든 드라이브의 데이터를 스트라이핑합니다. 따라서 RAID 0+1은 최대의 보호(미러링)와 높은 성능(스트라이핑)을 제공합니다. 이 스트라이핑과 미러링 작업은 RAID 컨트롤러가 제어하므로 Windows와 SQL Server에는 영향을 미치지 않습니다. RAID 1과 RAID 0+1의 차이점은 하드웨어 컨트롤러 수준입니다. RAID 1과 RAID 0+1은 특정 저장 용량에 대하여 같은 수의 드라이브를 필요로 합니다. 특정 RAID 컨트롤러의 RAID 0+1 구현에 대한 자세한 내용은 해당 컨트롤러를 생산하는 하드웨어 공급업체로 문의하십시오.

그림1은 RAID 0, RAID 1, RAID 5, RAID 0+1의 차이점을 나타낸 것입니다. 참고로, 디스크 네 개 분량의 데이터를 저장하려면 RAID 1과 RAID 0+1에는 8개의 디스크가 필요한 반면 RAID 5에는 5개가 필요합니다 데이터베이스 서버를 구동하는 하드웨어 특유의 RAID 구현에 대한 자세한 내용은 해당 하드웨어 공급업체로 문의하십시오.

그림 1 일반적인 RAID 수준

온라인 RAID 확장

이것은 사용 가능한 핫플러그 슬롯이 있는 경우 SQL Server가 온라인 상태일 때 물리적 RAID 어레이에 디스크를 동적으로 추가할 수 있는 편리한 기능입니다. 많은 하드웨어 공급업체들은 이 기능을 갖춘 하드웨어 RAID 컨트롤러를 제공합니다. 데이터는 새로 추가한 드라이브를 포함한 모든 드라이브에 자동으로 균등하게 스트라이프되므로 SQL Server나 Windows를 종료할 필요가 없습니다. 디스크 어레이 케이지에 핫플러그 하드 드라이브 슬롯을 남겨 두어 이 기능을 활용하는 것이 좋습니다. 따라서 SQL Server가 정기적으로 RAID 어레이에 과도한 I/O 요청을 하는 경우에는(해당 RAID 어레이와 연관된 Windows 논리 드라이브 문자에 해당하는 디스크 대기열 길이로 확인), SQL Server가 실행되는 상태에서 핫플러그 슬롯에 새 하드 드라이브를 하나 또는 여러 개 장착할 수 있습니다. 이렇게 하면 RAID 컨트롤러는 기존 SQL 데이터 일부를 새로 설치한 드라이브에 다시 분산하여 SQL 데이터가 RAID 어레이의 모든 드라이브에 균등하게 분산되도록 합니다. 그런 다음 새 드라이브의 I/O 처리 성능(드라이브마다 1초에 75번의 비순차/150번의 순차 I/O)이 RAID 어레이의 전체 I/O 처리 성능과 더해집니다.

성능 모니터와 RAID

성능 모니터에서는 논리 디스크 개체와 물리적 디스크 개체가 사실상 동일한 정보를 제공합니다. 차이점은 성능 모니터의 논리 디스크는 Windows가 어떤 것을 논리 드라이브 문자로 인식하느냐 하는 점과 관련이 있습니다. 성능 모니터의 물리적 디스크는 Windows가 어떤 것을 단일 물리적 하드 디스크로 인식하느냐 하는 점과 관련이 있습니다.

성능 모니터 카운터를 사용하려면 Windows의 명령 프롬프트 창에 있는 명령줄에서 diskperf.exe 명령을 사용합니다. "diskperf -y"를 사용하여 성능 모니터가 논리 및 물리적 디스크 카운터를 보고하도록 합니다. 이는 Windows NT 소프트웨어 RAID를 사용하지 않고 하드 드라이브 또는 하드 드라이브 세트와 RAID 컨트롤러를 사용할 때 좋습니다.

Windows NT 소프트웨어 RAID를 활용할 때에는 "diskperf -ye"를 사용하여 성능 모니터가 Windows NT 스트라이프 세트 전체의 물리적 카운터를 정확히 보고하도록 합니다. Windows NT 스트라이프 세트와 연결하여 "diskperf -ye"를 사용하면 논리 카운터는 정확한 정보를 보고하지 않으므로 이는 무시해야 합니다. Winnows NT 스트라이프 세트와 연결하여 논리 디스크 카운터 정보가 필요한 경우에는 "diskperf -y"를 사용합니다. "diskperf -y"와 Windows NT 스트라이프 세트를 사용하면 논리 디스크 카운터는 정확히 보고되지만 물리적 디스크 카운터는 정확한 정보를 보고하지 않을 것이므로 무시해야 합니다.

diskperf 명령을 실행하려면 Windows NT를 다시 실행해야 합니다.

또한 하드웨어 RAID 컨트롤러는 단일 RAID 미러 세트 또는 스트라이프 세트를 구성하는 여러 개의 물리적 하드 드라이브를 단일 물리적 디스크로 Windows에 제시합니다. 디스크 관리자는 논리 드라이브 문자를 단일 물리적 디스크와 연결하는 데 사용되며, 몇 개의 하드 디스크가 RAID 컨트롤러가 제시한 단일 물리적 디스크에 실제로 연결되어 있는지는 상관할 필요가 없습니다.

그러나 성능 조정이라는 면에서 RAID 어레이 하나에 물리적 하드 드라이브가 몇 개나 연결되어 있는지 아는 것이 아주 중요한데, 이는 이 정보가 Windows와 SQL Server가 각 물리적 하드 드라이브로 보내는 디스크 I/O요청의 수를 결정하는 데 필요하기 때문입니다. 하드 드라이브에 연관되는 있다고 성능 모니터가 보고하는 디스크 I/O 요청 수를 해당 RAID 어레이에 있는 것으로 알려진 실제 물리적 하드 드라이브 수로 나눕니다.

RAID 어레이에 있는 각 하드 드라이브의 I/O 동작을 대략 계산하려면 성능 모니터가 보고한 디스크 쓰기 I/O 수에 2(RAID 1과 0+1) 또는 4(RAID 5)를 곱하는 것이 중요합니다. 하드 드라이브의 I/O 용량에 해당하는 숫자(75 비순차 및 150 순차/드라이브)가 적용되는 것은 이 물리적 수준이므로, 이 방법으로 물리적 하드 드라이브에 보내지는 실제 I/O 요청의 수에 대한 더 정확한 값을 구할 수 있습니다. 그러나 이 방법으로 정확히 얼마나 많은 I/O가 하드 드라이브에 보내지는지를 계산할 수 있을 것으로 기대할 수는 없습니다. 이는 하드웨어 RAID 컨트롤러가 캐시를 사용할 때 방금 설명한 이유로 인해 캐시가 실제로 하드 드라이브에 전달되는 I/O의 양을 크게 변경시킬 수 있기 때문입니다.

어쨌거나 디스크 당 실제 I/O보다는 디스크 대기열에 초점을 두는 것이 가장 좋으며, 문제가 발생하지 않는 I/O를 걱정할 필요는 없습니다. Windows는 RAID 어레이에 있는 물리적 드라이브 수를 알지 못하므로, 각 물리적 디스크에 대한 디스크 대기열을 정확히 계산하려면 디스크 대기열 길이를 관찰 대상인 물리적 드라이브를 포함하는 하드웨어 RAID 디스크 어레이에 포함되는 물리적 드라이브 수로 나누는 것이 중요합니다. SQL Server 파일을 포함하는 하드 드라이브인 경우에는 이 숫자를 2 이하로 유지하십시오.

SQL Server와 RAID에 대한 자세한 내용은 SQL Server 온라인 설명서에서 "RAID Levels and SQL Server", "Comparing Different Implementations of RAID Levels", "Monitoring Disk Activity", "Performance Monitoring Example: Identifying Bottlenecks", "About Hardware-based Solutions", "RAID" 등의 문자열을 검색해 보십시오.

Windows NT 소프트웨어 RAID

Windows NT는 하드웨어 RAID 컨트롤러 대신에 Windows NT 운영 체제를 통하여 내결함성을 이미 갖고 있든 갖고 있지 않든 관계 없이 미러 세트와 스트라이프 세트를 제공함으로써 하드 디스크 장애에 대한 내결함성을 제공합니다. Windows NT 디스크 관리자를 사용하여 미러 세트(RAID 1) 또는 패리티가 있는 스트라이프 세트(RAID 5)를 정의합니다. 또한 Windows NT 디스크 관리자는 내결함성이 없는 스트라이프 세트(RAID 0)를 정의할 수도 있습니다.

소프트웨어 RAID는 더 많은 CPU 리소스를 사용하는데, 이는 Windows NT가 하드웨어 RAID 컨트롤러라기보다는 RAID 동작을 관리하는 구성 요소이기 때문입됩니다. 따라서 시스템 프로세서가 거의 100% 활용된다고 가정할 때 디스크 드라이브 수가 동일하면 Windows NT 소프트웨어 RAID가 하드웨어 RAID 솔루션에 비해 성능 면에서 몇 % 정도 낮습니다. 그러나 일반적으로 Windows NT 소프트웨어 RAID 솔루션을 사용하면 드라이브가 개별적으로 SQL Server I/O 서비스를 제공하는 것보다 드라이브 세트 일체가 함께 서비스를 제공하는 효율을 더 높일 수 있습니다. 이로써 병목 현상이 발생할 가능성을 낮추어 SQL Server가 CPU를 보다 효율적으로 활용하고 보다 많은 I/O를 처리할 수 있게 됩니다. 또한 소프트웨어 RAID는 일련의 하드 드라이브에 내결함성을 제공하는 데 있어서 비용 면에서도 더 좋은 해결책입니다.

Windows NT 소프트웨어 RAID를 구성하는 데 대한 자세한 내용은 Windows NT Server 온라인 도움말 4장 "Planning a Reliable Configuration"을 참조하십시오. 또한 SQL Server 온라인 설명서에서 "About Windows NT-based Disk Mirroring and Duplexing"과 "About Windows NT-based Disk Striping and Striping with Parity" 문자열을 검색해 보십시오.

디스크 I/O 병렬 처리

적은 수의 디스크 드라이브에 위치한 소규모 SQL Server를 처리할 때에는 디스크 I/O 병렬 처리를 실행할 가능성은 없을 것입니다. 그러나 많은 디스크 드라이브에 저장된 대형 SQL Server 데이터베이스를 처리하는 경우에는 디스크 I/O 병렬 처리를 사용하여 디스크 하위 시스템의 I/O 처리 능력을 최대한 사용함으로써 성능을 향상시킬 수 있습니다.

디스크 I/O 병렬 처리를 만드는 가장 간단한 방법은 트랜잭션 로그 파일을 제외한 모든 SQL Server 데이터베이스 파일을 서비스할 수 있는 단일 "드라이브 풀"을 만드는 것입니다. 이 풀은 Windows NT에 단일 물리적 드라이브로 표시된 단일 RAID 어레이일 수 있습니다. 이보다 큰 풀인 경우에는 여러 개의 RAID 어레이와 SQL Server 파일/파일 그룹을 사용하여 설정할 수 있습니다. SQL Server 파일 하나를 각 RAID 어레이에 연결할 수 있으며, 파일 여러 개를 SQL Server 파일 그룹으로 결합할 수 있습니다. 그런 다음 파일 그룹에서 데이터베이스를 구축하면 데이터가 모든 드라이브와 RAID 컨트롤러에 골고루 분산됩니다. "드라이브 풀" 방식은 RAID에 따라 데이터를 모든 물리적 드라이브에 분산하여 데이터베이스 서버가 동작하는 동안 그 데이터에 병렬 액세스할 수 있도록 합니다.

데이터베이스 관리자는 단 하나의 물리적 장소에 데이터베이스 개체를 만들 수 있다는 것을 알고 있으므로 이 풀 방식을 사용하면 SQL Server I/O 성능 조정이 쉬워집니다. 단일 드라이브 풀을 감시하여 디스크 대기열을 확인하고, 필요한 경우에는 풀에 하드 드라이브를 추가하여 디스크 대기를 방지할 수 있습니다. 이 기술은 데이터베이스에서 어느 부분이 가장 많이 사용되는지 알 수 없는 일반적인 경우를 최적화하는 데 도움이 됩니다. 사용 가능한 전체 I/O 용량의 일부가 다른 디스크 파티션으로 격리되지 않도록 하는 것이 좋은데, 이는 SQL server 작동 시간의 5%가 이 디스크로의 I/O에 할당되어 버리기 때문입니다. "단일 드라이브 풀" 방법을 사용하면 사용 가능한 모든 I/O 용량을 항상 SQL Server 작업에 사용할 수 있습니다 .

SQL Server 로그 파일은 항상 다른 모든 SQL Server 데이터베이스 파일과 분리되어 별도의 물리적 하드 드라이브에 저장되어야 합니다. 매우 자주 사용되는 데이터베이스가 있는 SQL Server의 경우 트랜잭션 로그 파일은 각각 물리적으로 분리되어 있어야 합니다. 트랜잭션 로그 작업은 주로 순차 쓰기 I/O입니다. 트랜잭션 로그 작업을 다른 비순차 디스크 I/O 작업과 분리하면 I/O 성능에 많은 장점을 가져올 수 있습니다. 이는 로그 파일을 포함하는 하드 드라이브가 순차 I/O에만 집중할 수 있도록 합니다. 트랜잭션 로그를 복제, 롤백 및 지연 업데이트 같은 SQL Server 작업의 일부분으로 읽어야 할 때가 있습니다. 복제를 수행하는 SQL Server에서는 읽기 작업 발생할 것이므로 모든 트랜잭션 로그 파일이 충분한 디스크 I/O 처리 능력을 가지고 있는지 특별히 주의를 기울여야 합니다.

SQL Server 파일과 파일 그룹을 통하여 SQL Server 개체를 나머지 관련 데이터베이스와 물리적으로 분리하는 데에는 또 다른 관리가 필요합니다. 활동이 아주 많은 테이블이나 인덱스를 조사하는 목적을 위해서는 이 관리가 아주 유용할 것입니다. 테이블이나 인덱스를 다른 모든 데이터베이스 개체와 분리함으로써 그 개체의 I/O 요구 사항에 대한 정확한 평가가 가능합니다. 데이터베이스 개체들이 커다란 드라이브 풀 하나에 전부 모여 있을 때에는 이러한 평가가 쉽지 않습니다. 이런 종류의 물리적 I/O 분리는 데이터베이스 개발과 벤치마킹에 적합할 수 있습니다. 즉, 데이터베이스 I/O 정보를 모아 실제 데이터베이스 서버 환경을 위한 용량 계획을 수립하는 데 적용할 수 있습니다.

여러 하드 드라이브, RAID 컨트롤러, PCI 채널(또는 이 세 가지의 조합)에 분리할 수 있는 SQL Server 작업 영역은 아래와 같습니다.

• 트랜잭션 로그 파일
• Tempdb
• 데이터베이스 파일
• 많은 수의 쿼리 또는 쓰기 작업에 관련된 테이블
• 많은 수의 쿼리 또는 쓰기 작업에 관련된 클러스터되지 않은 인덱스

하드웨어 RAID 컨트롤러, RAID 핫플러그 드라이브 및 온라인 RAID 확장을 사용하면 SQL Server I/O 작업을 매우 편리하게 물리적으로 분리할 수 있습니다. 가장 융통성이 큰 접근 방법은, 개별적인 RAID SCSI 채널이 위에서 설명한 각 분리 SQL 작업 용으로 제공되도록 RAID 컨트롤러를 배열하는 것입니다. 각 RAID SCSI 채널을 별도의 RAID 핫플러그 캐비닛에 부착하여, RAID 컨트롤러를 통해 사용 가능한 경우 온라인 RAID 확장을 최대한 활용할 수 있도록 해야 합니다. Windows 논리 드라이브 문자는 각 RAID 어레이에 연결되며, SQL Server 파일은 알려진 I/O 사용 패턴을 기반으로 별개의 RAID 어레이들 사이에서 분리될 수도 있습니다.

이러한 구성을 사용하면, 성능 모니터가 로드 테스트를 수행하는 동안 또는 작업 로드가 과중한 상황에서 대기열 상태를 보고하는 경우에 디스크 대기열을 별개의 RAID SCSI 채널과 해당 드라이브 캐비닛에 연관시킬 수 있습니다. RAID 컨트롤러와 드라이브 어레이 캐비닛이 온라인 RAID 확장을 지원하고 사용 가능한 핫플러그 하드 드라이브용 슬롯이 캐비닛에 있는 경우, 이 RAID 어레이에 대한 디스크 대기열은 성능 모니터가 그 RAID 어레이에 대한 디스크 대기열이 허용 가능한 수준(SQL Server 파일의 경우 2 미만)에 도달했다고 보고할 때까지 그 RAID 어레이에 드라이브를 추가하는 것으로 간단히 해결됩니다. 이 작업은 SQL Server가 온라인 상태일 때 가능합니다.

Tempdb는 SQL Server가 만든 데이터베이스로서, 임시 테이블, 정렬, 하위 쿼리를 포함한 다양한 활동을 위한 공유 작업 영역으로 사용되며, DISTINCT, 커서 및 해시 조인 등을 사용하는 쿼리 GROUP BY 또는 ORDER BY 쿼리와 집계됩니다. 이 때 DISTINCT를 사용하는 쿼리의 경우에는 임시 작업 테이블을 만들어 중복 행을 제거해야 합니다. tempdb I/O 작업이 관련 트랜잭션의 I/O 작업과 나란히 이루어지도록 하는 것이 좋습니다. tempdb는 임시 영역이며 매우 자주 업데이트되므로 RAID 5는 RAID 1이나 0+1보다 tempdb 용으로 좋지 않습니다. tempdb는 데이터베이스 서버가 다시 시작할 때마다 다시 구축되므로, 프로덕션 SQL Server 컴퓨터의 경우에는 RAID 0을 tempdb 용으로 선택하는 것이 좋습니다. RAID 0은 최소의 물리적 하드 드라이브 수로 최고의 tempdb RAID 성능을 제공합니다. 제작 환경에서 tempdb 용으로 RAID 0을 사용하는 경우 고려해야 할 사항은 RAID 0 어레이에서 물리적 드라이브 장애가 발생하는 경우 SQAL Server를 종료했다가 다시 실행해야 한다는 점이며, tempdb가 RAID 1이나 0+1 어레이에 있을 때에는 반드시 그럴 필요가 없습니다.

temdb 데이터베이스를 이동하려면 ALTER DATABASE 명령을 사용하여 tempdb에 연결된 SQL Server 논리 파일 이름의 물리적 파일 위치를 변경합니다. 예를 들어, tempdb 및 관련 로그를 새 파일 위치인 e:\mssql7와 c:\temp로 이동하려면 아래 명령을 사용합니다.

alter database tempdb modify file (name='tempdev',filename= 'e:\mssql7\tempnew_location.mDF')
alter database tempdb modify file (name='templog',filename= 'c:\temp\tempnew_loglocation.mDF')

제작 환경에서는 사용자 데이터베이스에 비하여 마스터 데이터베이스인 msdb와 모델 데이터베이스가 그리 자주 사용되지 않으므로 I/O 성능 조정을 고려할 때 이를 염두에 둘 필요가 없습니다. 마스터 데이터베이스는 보통 새로운 로그인, 데이터베이스, 장치 및 기타 시스템 개체를 추가할 때에만 사용합니다.

클러스터되지 않은 인덱스는 B-트리 구조에 상주하며, ALTER DATABASE 명령을 사용하여 관련 데이터베이스 테이블에서 분리될 수 있습니다. 아래 예제에서 첫째 ALTER DATABASE는 파일 그룹을 만듭니다. 둘째 ALTER DATABASE는 파일 그룹에 연결된 별도의 물리적 위치를 가진 파일을 만듭니다. 이 시점에서 인덱스는 아래 코드에 예시된 바와 같이 파일 그룹에 만들어지고 동시에 index1이라는 인덱스도 만들어질 수 있습니다. SP_HELPFILE는 특정 데이터베이스에 파일과 파일 그룹이 있음을 보고합니다. SP_HELP <tablename> 출력에는 테이블의 인덱스와 그 파일 그룹 관계에 대한 정보를 제공하는 섹션이 있습니다. 자세한 내용은 SQL Server 온라인 설명서에서 "ALTER DATABASE"와 "sp_helpfile" 문자열을 검색해 보십시오.

alter database testdb add filegroup testgroup1
alter database testdb add file (name = 'testfile',
filename = 'e:\mssql7\test1.ndf') to filegroup testgroup1
create table test1(col1 char(8))
create index index1 on test1(col1) on testgroup1

sp_helpfile
sp_help test1

자세한 내용은 SQL Server 온라인 설명서에서 "Files and Filegroups", "Placing Indexes on Filegroups", " Monitoring Disk Activity", "Physical Database Files and Filegroups" 및 "Adding and Deleting Data and Transaction Log Files" 문자열을 검색해 보십시오.

SQL Server 인덱스

서버에 설치된 하드웨어 장치의 I/O 특성에 대해서는 이미 설명하였습니다. 이제는 SQL Server 데이터와 인덱스 구조를 어떻게 물리적으로 디스크 드라이브에 배치할 것인지 설명하겠습니다. 이 지식을 디스크 I/O 성능에 적용할 수 있을 정도로 이 구조에 대해 충분히 설명할 것입니다.

SQL Server 데이터와 인덱스 페이지 크기는 모두 8KB입니다. SQL Server 데이터 페이지에는 텍스트와 이미지 데이터를 제외하고 테이블 행에 관련된 모든 데이터가 들어 있습니다. 텍스트와 이미지 데이터의 경우, 텍스트/이미지 열에 관련된 행을 포함하는 SQL Server 데이터 페이지는 텍스트/이미지 데이터를 포함하는 8KB 페이지가 두 개 이상 있는 B-트리 구조를 가리키는 포인터를 포함합니다.

SQL Server 인덱스 페이지에는 특정 인덱스를 구성하는 열의 데이터만 포함됩니다. 따라서 인덱스 페이지는 8KB 데이터 페이지보다 더 많은 열과 관련된 정보를 8KB 페이지에 효과적으로 압축할 수 있습니다. 알아둘 필요가 있는 중요한 I/O 성능 개념은, 인덱스의 I/O 성능 이익이 이러한 정보 압축에서 비롯된다는 것입니다. 이는 특히 인덱스의 일부분으로 선택된 열이 비교적 낮은 비율의 테이블 행 크기를 이루는 경우에 그러합니다. SQL 쿼리가 그 쿼리의 열이 행의 특정 값과 일치되는 테이블에서 행 집합을 요구하는 경우, SQL Server는 I/O 작업을 저장하고 그 값을 찾는 인덱스 페이지를 읽어 시간을 측정한 후, 쿼리된 행을 찾기 위하여 테이블의 모든 행을 스캔하는 I/O 작업을 수행하는 대신에 그 쿼리를 만족하는 테이블의 행만 액세스합니다. 이 작업은 정의된 인덱스가 제대로 선택된 경우에 해당됩니다.

SQL Server 인덱스에는 두 가지 유형이 있으며, 이 두 유형은 8KB 인덱스 페이지로 구성되는 B-트리 구조에 만들어집니다. 이 두 유형에서 SQL Server 문서에서 잎 수준이라고 하는 B-트리 구조의 하단은 서로 다릅니다. B-트리 구조 위 부분은 인덱스의 잎이 아닌 수준이라고 합니다. 모든 단일 인덱스 용으로 만들어진 B-트리 구조는 SQL Server 테이블에 정의됩니다.

그림 2는 클러스터되지 않은 인덱스와 클러스터된 인덱스의 구조적 차이를 보여줍니다. 기억해야 할 요점은, 클러스터되지 않은 인덱스인 경우 잎 수준 노드에는 관련 데이터 페이지의 나머지 열 데이터를 빨리 찾을 수 있는 포인터와 함께 이 인덱스에 해당하는 데이터만 포함된다는 점입니다. 최악의 경우, 클러스터되지 않은 인덱스에서 각 행으로의 액세스는 열 데이터를 검색하기 위한 비순차 디스크 I/O를 추가로 필요로 합니다. 최선의 경우, 필요한 열 대부분이 같은 데이터 페이지에 있어 반입된 각 데이터 페이지와 함께 필요한 행을 여러 개 검색할 수 있습니다. 클러스터된 인덱스인 경우 인덱스의 잎 수준 노드는 테이블의 실제 데이터 행입니다. 따라서 테이블 데이터를 검색하기 위한 포인터 점프가 필요하지 않습니다. 클러스터된 인덱스를 기반으로 하는 범위 스캔은 원활하게 이루어질 것입니다. 이는 클러스터된 인덱스의 잎 수준(즉, 해당 테이블의 모든 행)이 클러스터된 인덱스를 구성하는 열 단위로 디스크에 물리적으로 정렬되어 있어 64KB 확장 영역으로 I/O를 수행하기 때문입니다. 그리고 클러스터된 인덱스 B-트리(잎 수준이 아닌 수준과 잎 수준)에 페이지 분할이 많지 않다면 이 64KB I/O가 물리적으로 순차적이 될 것입니다. 점선은 B-트리 구조에 다른 8KB 페이지가 있지만 보이지는 않음을 의미합니다.

그림 2 클러스터된 인덱스 및 클러스터되지 않은 인덱스의 B-트리 구조

클러스터된 인덱스

테이블 하나에는 클러스터된 인덱스가 하나만 있을 수 있습니다. 이는 단순히 물리적인 이유 때문입니다. 클러스터된 인덱스 B-트리 구조의 위 부분(SQL Server 문서에서는 보통 잎이 아닌 수준으로 표시)은 클러스터되지 않은 B-트리 구조와 마찬가지로 구성된 반면, 클러스터된 인덱스 B-트리의 아래 부분은 테이블과 연결된 실제 8KB 페이지입니다. 성능에 관련된 사항은 아래 두 가지입니다.

1. 클러스터된 인덱스에서 키 검색으로 SQL 데이터를 가져오는 경우에는 하드 디스크에서의 비순차적 변경을 통해 관련 데이터 페이지로 가기 위한 포인터 점프가 필요치 않은데, 이는 클러스터된 인덱스의 잎 수준이 이미 데이터 페이지에 연결되어 있기 때문입니다.
2. 클러스터된 인덱스의 잎 수준은 클러스터된 인덱스를 구성하는 열 별로 정렬됩니다. 클러스터된 인덱스의 잎 수준에 테이블의 실제 8KB 데이터 페이지가 포함되어 있으므로, 이는 전체 테이블의 행 데이터가 클러스터된 인덱스에 의해 결정된 순서로 하드 드라이브에 물리적으로 정렬되어 있다는 뜻입니다. 순차 디스크 I/O가 사용되므로, 이 방법은 클러스터된 인덱스의 값을 기준으로 이 테이블에서 최소 64KB가 넘는 많은 행을 반입할 때 잠재적으로 뛰어난 I/O 성능을 제공합니다.(테이블에서 페이지 분할이 이루어지는 경우는 제외되는데, 이에 대해서는 뒤의 "Importance of FILFACTOR and PAD_INDEX" 절에서 설명합니다.) 이 때문에 많은 수의 열을 검색하기 위하여 범위 스캔을 하는 데 사용되는 열을 기반으로 하는 테이블에서 클러스터된 인덱스를 선택하는 것이 중요합니다.

클러스터되지 않은 인덱스

클러스터되지 않은 인덱스는 키 값을 기반으로 하여 대형 SQL Server에서 선택이 용이한 열을 몇 개만 반입하는 데 가장 유용합니다. 앞에서 설명한 것과 같이 클러스터되지 않은 인덱스는 8KB 인덱스 페이지로 형성된 B-트리입니다. 인덱스 페이지의 B-트리 아래 부분 또는 잎 수준에는 이 인덱스를 구성하는 열의 모든 데이터가 포함되어 있습니다. 키 값에 일치하는 정보를 테이블에서 검색하기 위하여 클러스터되지 않은 인덱스를 사용하는 경우, 인덱스의 잎 수준에서 키와 일치하는 값을 찾을 때까지 B-트리가 검색됩니다. 인덱스를 구성하지 않는 테이블의 열이 필요한 경우에는 포인터 점프가 이루어집니다. 포인터 점프에는 디스크에 대한 비순차 I/O 작업이 필요할 것입니다. 테이블 및 이에 딸린 인덱스 B-트리가 큰 경우에는 다른 디스크에서 데이터를 읽어야 할 경우도 있을 것입니다. 동일한 8KB 데이터 페이지에 포인터가 여러 개 연결되어 있으면 해당 페이지를 데이터 캐시로 읽기만 하면 되므로 I/O 성능에 미치는 부정적인 영향이 줄어들 것입니다. 클러스터되지 않은 인덱스를 사용하는 검색에 관련된 SQL 쿼리에 대해 반환되는 모든 열에 한 번의 포인터 점프가 필요합니다. 이 때문에 테이블에서 열을 하나 또는 몇 개만 반환하는 SQL 쿼리에는 클러스터되지 않은 인덱스가 더 적합한 것입니다. 많은 행을 반환해야 하는 쿼리인 경우에는 클러스터된 인덱스가 더 좋습니다.

자세한 내용은 SQL Server 온라인 설명서에서 "nonclustered index" 문자열을 검색해 보십시오.

포함 인덱스

클러스터되지 않은 인덱스의 특수한 경우로 포함 인덱스가 있습니다. 포함 인덱스는 선택 기준 및 WHERE 조건자에서 SQL 쿼리를 만족하는 데 필요한 모든 컬럼에 구축된 클러스터되지 않은 인덱스를 말합니다. 포함 인덱스는 I/O의 작업을 크게 줄일 수 있으므로 쿼리 성능을 크게 향상시킬 수 있습니다. 그러나 관련 B-트리 인덱스 구조 유지 관리를 포함하여 새 인덱스를 만드는 비용과 포함 인덱스가 제공할 I/O 성능 이득 사이에 균형을 유지해야 합니다. 포함 인덱스가 SQL Server에서 자주 실행되는 쿼리나 쿼리 집합에 많은 이익을 준다면 포함 인덱스는 만들 만한 가치가 있습니다.

포함 인덱스 예제

1. col2 값이 'value'인 경우 table1에서 col1, col3을 선택합니다.
2. table1(col2,col1,col3)에 indexname1 인덱스를 만듭니다.

   또는

   SQL Server 엔터프라이즈 관리자에 있는 인덱스 만들기 마법사를 사용하여 인덱스를 만듭니다. SQL Server 엔터프라이즈 관리자 메뉴 표시줄에서 Tools/Wizards를 선택하고 Database 옆의 + 아이콘을 눌러 데이터베이스 마법사를 연 다음 Create Index Wizard를 두 번 눌러 마법사를 시작합니다.

이 예제에서 만들어진 "indexname1" 인덱스는 SELECT 문과 WHERE 조건자의 모든 열을 포함하고 있으므로 포함 인덱스입니다. 이는 쿼리 실행 과정에서 SQL Server가 table1에 연결된 데이터 페이지에 액세스할 필요가 없다는 뜻입니다. SQL Server는 indexname1 인덱스를 사용하여 쿼리를 만족하는 모든 정보를 얻을 수 있습니다. 일단 SQL Server가 indexname1에 연결된 B-트리를 검색하여 col2가 "value"와 일치하는 인덱스 키 범위를 발견하면, SQL Server는 포함 인덱스의 잎 수준(아래 수준)에서 필요한 데이터(col1, col2, col3)를 모두 반입할 수 있는 것으로 판단합니다. 이것은 아래 두 가지 방식으로 I/O 작업을 수행합니다.

• SQL Server가 데이터 페이지가 아닌 인덱스 페이지에서 필요한 데이터를 모두 가져오므로 데이터는 더욱 압축되며 SQL Server는 디스크 I/O 작업을 줄일 수 있습니다.
• 포함 인덱스는 col2가 필요로 하는 모든 데이터를 디스크에 물리적으로 구성합니다. 이로써 하드 드라이브는 WHERE 조건자(col2 = "value")에 연결된 모든 인덱스 열을 순차적으로 반환할 수 있습니다. 결과적으로 I/O 성능이 향상됩니다. 디스크 I/O의 관점에서 볼 때 본질적으로 포함 인덱스는 이 쿼리와 다른 쿼리에 대해 포함 인덱스의 열이 완전히 만족할 만한 클러스터된 인덱스가 됩니다.

일반적으로 해당 테이블에 있는 단일 열의 바이트 수에 비교할 때 포함 인덱스에 있는 모든 열의 바이트 수가 적고 쿼리가 포함 인덱스의 장점을 활용하는 것이 확실한 경우에는 포함 인덱스를 사용하는 것이 좋습니다. 그러나 포함 인덱스를 많이 만들기 전에, SQL Server 7.0이 쿼리 용으로 포함된 인덱스를 어떻게 지능적이며 자동적으로 만드는지 설명한 다음 절을 참조하십시오.

자동 포함 인덱스 또는 포함된 인덱스

SQL Server 7.0의 새 쿼리 프로세서는 인덱스 공통 영역을 제공합니다. 인덱스 공통 영역은 쿼리 프로세서가 주어진 테이블에서 여러 개의 인덱스를 고려하여 이 여러 개의 인덱스를 기반으로 해시 테이블을 만들고 이 해시 테이블을 활용하여 주어진 쿼리를 위한 I/O를 줄일 수 있도록 합니다. 인덱스 공통 영역에서 만들어진 해시 테이블은 실제로 포함 인덱스가 되며 포함 인덱스가 제공하는 것과 동일한 I/O 성능 이점을 제공합니다. 인덱스 공통 영역은 데이터베이스에서 실행될 모든 쿼리를 미리 결정하기가 어려운 데이터베이스 사용자 환경에 커다란 융통성을 제공합니다.이 경우에는 자주 쿼리되는 모든 열에 단일 열의 클러스터되지 않은 인덱스를 정의하고 인덱스 공통 영역이 포함된 인덱스가 필요한 상황을 처리하도록 하는 것이 좋습니다.

자세한 내용은 SQL Server 온라인 설명서에서 "query tuning recommendations"와 "designing an index" 문자열을 검색해 보십시오.

인덱스 공통 영역을 활용하는 예제

1. col2의 값이 'value'일 때 table1에서 col3을 선택합니다.
2. table1(col2)에서 indexname1 인덱스를 만듭니다.
3. table1(col3)에서 indexname2 인덱스를 만듭니다.
4. 또는
5. SQL Server 엔터프라이즈 관리자에 있는 인덱스 만들기 마법사를 사용하여 인덱스를 만듭니다. SQL Server 엔터프라이즈 관리자 메뉴 표시줄에서 Tools/Wizards를 선택하고 Database 옆의 + 아이콘을 눌러 데이터베이스 마법사를 연 다음 Create Index Wizard를 두 번 눌러 마법사를 시작합니다.

앞의 예제에서 "indexname1"과 "indexname2"는 클러스터되지 않은 단일 열 인덱스로, "table1"이라는 SQL Server 테이블에서 만들어진 것입니다. 쿼리가 실행되면 쿼리 프로세서는 이 두 인덱스를 사용하는 인덱스 공통 영역이 유리한 상황을 재구성합니다. 쿼리 최적화 프로그램은 자동으로 두 인덱스를 하나로 해시하여 쿼리를 실행하는 I/O를 절약합니다. 이 작업을 위하여 쿼리 힌트가 필요하지는 않습니다. 포함 인덱스가 처리하는 쿼리는 명시적으로 선언된 포함 인덱스이든 인덱스 공통 영역이든 모두 "포함된 쿼리"라고 합니다.

인덱스 선택

인덱스가 어떻게 선택되는가는 생성되는 디스크 I/O에 상당한 영향을 미치며 결과적으로 성능에도 영향을 미칩니다. 앞 부분에서는 어째서 클러스터되지 않은 인덱스가 적은 수의 열을 검색하는 데 좋으며 클러스터된 인덱스가 영역 스캔에 좋은지에 대하여 설명했습니다. 다음은 몇 가지 추가 정보입니다.

• 인덱스를 가능한 최소한으로(열과 바이트 수를 최소한으로) 유지하십시오. 클러스터된 인덱스인 경우에는 특히 그렇게 해야 합니다. 이는 클러스터되지 않은 인덱스가 클러스터된 인덱스를 행 데이터를 찾는 수단으로 사용할 것이기 때문입니다. 자세한 내용은 SQL Server 온라인 설명서에서 "using clustered indexes", "Index Tuning Recommendations" 및 "Design an Index" 문자열을 검색해 보십시오.
• 클러스터되지 않은 인덱스인 경우에는 선택성이 중요합니다. 이는 고유 값이 몇 안 되는 대형 테이블에서 클러스터되지 않은 인덱스를 생성될 때 그 클러스터되지 않은 인덱스를 사용하면 데이터 검색 과정에서 I/O를 줄일 수 없기 때문입니다. 사실 인덱스를 사용하면 테이블을 순차적으로 스캔하는 것보다 I/O가 더 많이 발생하게 됩니다. 클러스터되지 않은 인덱스를 사용할 수 있는 예로는 인보이스 번호, 고개 고유 번호, 주민 번호, 전화 번호 등이 있습니다.
• 고유 값이 많지 않은 열 범위를 검색하거나 열에 일치하는 쿼리인 경우에는 클러스터된 인덱스가 클러스터되지 않은 인덱스보다 좋습니다. 이는 클러스터된 인덱스가 물리적으로 테이블 데이터를 정리함으로써 키 값에 대하여 순차 64KB I/O를 허용하기 때문입니다. 클러스터된 인덱스를 사용할 수 있는 예로는 상태, 회사 지점, 판매일, 우편 번호, 고객 지역 등이 있습니다. 시스템에서 많이 사용하는 쿼리가 해당 고유 값에 대한 대형 순차 범위를 반입하지 않는 한, 고유한 값만 가지는 열에 클러스터된 인덱스를 정의하는 것은 낭비인 경우가 많습니다. 각 테이블에서 클러스터된 인덱스를 만들기 위한 최선의 열을 선택할 때 고려해야 할 것은 "이 열 순서를 기반으로 많은 행을 반입해야 할 쿼리가 많은가" 하는 점입니다. 이에 대한 답은 각 사용자 환경마다 아주 다를 것입니다. 어떤 회사는 날짜 범위에 대해 많은 쿼리를 수행해야 하는 반면에 다른 회사는 은행 지점의 범위에 따른 쿼리를 많이 수행해야 하는 경우가 있을 것입니다.

클러스터된 인덱스를 활용하는 WHERE 조건자 예제

WHERE <column_name> > some_value WHERE <column_name> BETWEEN some_value AND some_value WHERE <column_name> < some_value

클러스터된 인덱스 선택, 순차 키 데이터, 핫스폿 감시 방법

클러스터된 인덱스 선택에는 실제로 두 가지 중요한 결정이 포함됩니다. 첫째, 영역 스캔을 위해 순차 I/O를 제공한다는 측면에서 어떤 테이블 열이 클러스터된 인덱스를 최대한 활용하게 될 것인지에 대한 결정입니다. 핫스폿을 피하면서 테이블 데이터의 물리적 배치에 영향을 주기 위해 클러스터된 인덱스를 사용할 것인지에 대한 결정입니다. 핫스폿은 데이터가 하드 드라이브에 들어간 뒤 많은 쿼리가 동시에 디스크의 같은 영역에서 데이터 쓰기/읽기를 시도할 때 발생합니다. 이 때 디스크 I/O 병목 현상이 발생하는데, 이는 하드 디스크가 처리 할 수 있는 것 보다 더 많은 동시 디스크 I/O 요청이 들어오기 때문입니다. 해결책은 해당 디스크에서 그만큼에 해당하는 데이터 반입을 중지하거나 데이터를 여러 개의 디스크에 분산하여 I/O 요구를 지원할 수 있도록 하는 것입니다. 데이터의 물리적 배치에 대한 이러한 고려 사항은 수많은 SQL Server 사용자들이 동시에 액세스하더라도 성능이 저하되지 않도록 하는 데 중요합니다.

이 두 가지 결정은 때로 서로 상충될 수도 있으므로, 전체적으로 최선의 결정을 위해서는 이 두 가지 사이에 균형을 유지해야 합니다. 사용자 부하가 높은 환경에서는 클러스터된 인덱스를 해당 열에 배치하여 성능을 향상시키는 것보다 핫스폿을 피함으로써 동시성을 향상시키는 것이 유리한 경우가 종종 있습니다.

이전 버전의 SQL Server에서는 클러스터된 인덱스가 없는 테이블의 경우 삽입된 열이 언제나 디스크에서 테이블의 실제 끝부분에 위치하게 됩니다. 이런 테이블을 힙이라고 합니다. 이 때문에 작업량이 많은 테이블 끝에 핫스폿을 발생시켰습니다. SQL Server 7.0이 새로 제공하는 사용 가능한 공간 저장 관리 알고리즘은 이런 현상을 제거합니다. 이제 행이 힙에 삽입될 때 SQL Server는 PFS 페이지를 사용하여 테이블에서 열이 삽입될 수 있는 빈 공간을 신속하게 찾습니다. PFS 페이지는 테이블 전체에서 사용 가능한 공간을 표시합니다. 이에 따라 삽입이 테이블 전체의 물리적 디스크 공간에 분산되기 때문에 삭제된 공간이 복구되고 삽입 핫스폿이 예방됩니다. 사용 가능한 공간 관리는 클러스터된 인덱스 선택에 영향을 줍니다. 클러스터된 인덱스는 물리적 데이터 배치에 영향을 미치므로, 클러스터된 인덱스가 최고 열 값에서 동일한 물리적 디스크 위치에 놓이게 될 동시 삽입이 많이 발생하는 열을 기준으로 물리적으로 나열될 때 핫스폿이 발생합니다. 단조롭게 증가하는 값을 포함하는 열의 경우, 해당 열의 클러스터된 인덱스가 어떻게 해당 컬럼에 의하여 데이터 행을 순차적으로 정렬하는지 주의하고 클러스터된 인덱스를 다른 열에 배치합니다. 그렇기 않으면 테이블의 클러스터된 인덱스를 포함하지 않게 되어 이 순차 데이터 배치가 다른 열로 변경되거나 전혀 이루어지지 않습니다.

클러스터된 인덱스 선택을 설명하는데 도움이 되는 시나리오가 있습니다. 테이블에 인보이스 날짜 열, 고유 인보이스 번호 열 그리고 기타 데이터가 있다고 가정합시다. 이 테이블에 매일 약 10,000개의 새로운 레코드가 삽입되고 한 주일 분의 데이터 용으로 모든 레코드에 대하여 이 테이블을 검색하는 SQL 쿼리가 종종 필요하며, 또한 많은 사용자들이 이 테이블에 동시에 액세스한다고 가정합니다. 여러 가지 이유로 인보이스 번호는 클러스터된 인덱스 용으로 적합하지 않습니다. 우선 인보이스 번호는 고유하며 인보이스 번호 범위로 검색하는 사용자는 많지 않으므로, 인보이스 번호를 물리적으로 디스크에 순차적으로 정리하는 것은 인보이스 번호에 대한 범위 스캔이 발생할 경우가 거의 없기 때문에 그리 도움이 되지 않습니다. 둘째, 인보이스 번호의 값은 단조롭게 증가할 것입니다 (1001, 1002, 1003 등).클러스터된 인덱스가 인보이스 번호에 배치되면 이 테이블로의 새로운 열 삽입은 테이블의 끝에서 발생할 것이며(가장 높은 인보이스 번호 옆으로) 따라서 같은 물리적 디스크 위치이므로 핫스폿이 만들어집니다.

다음으로, 인보이스 날짜 열을 생각해 봅니다. 사용자들은 한 주일만큼의 데이터(약 70,000 행)를 검사하는 경우가 많으므로 순차 I/O를 최대화하려면 인보이스 날짜가 클러스터 인덱스에 적합할 것입니다. 그러나 동시성의 관점에서 인보이스 날짜는 클러스터된 인덱스용으로 적합하지 않을 수 있습니다. 클러스터된 인덱스가 인보이스 날짜에 배치되면 모든 데이터는 테이블의 끝으로 삽입되는 경향이 있으며, 날짜의 속성으로 인하여 테이블의 끝을 포함하는 하드 디스크에 핫스폿이 발생할 수 있습니다. 참고로 삽입이 테이블 끝에서 발생한다는 사실이 어떤 면에서 같은 날짜에 10,000열이 삽입된다는 사실에 대한 상쇄일 수 있으므로 인보이스 날짜는 인보이스 번호보다 핫스폿을 만들 가능성이 훨씬 적을 것입니다. 또한 하드웨어 RAID 컨트롤러는 10,000열을 여러 디스크에 분산하는 데 도움이 될 것이며, 이는 또한 삽입 핫스폿의 가능성을 최소화하는 데 도움이 됩니다.

위의 시나리오에 대해서는 완벽한 답이 없습니다. 핫스폿의 위험을 감수하고 클러스터된 인덱스를 인보이스 날짜에 배치하여 인보이스 날짜 범위에 대한 쿼리 속도를 높이는 것이 가치 있는 것인지 결정해야 합니다. 가치가 있는 경우, 이 테이블에 연결된 디스크의 디스크 대기열을 신중히 살펴보고 삽입이 서로의 뒤에 대기하며 테이블의 뒤에 들어가려고 시도한다는 사실을 명심해야 합니다. 이 시나리오에 대한 저자의 생각은, 인보이스 날짜를 기준으로 하는 범위 스캔에는 나름대로 장점이 있으므로 클러스터된 인덱스를 인보이스 날짜에 정의하여 인보이스 번호가 디스크에 물리적으로 나열되지 않도록 하는 것이 좋습니다.

작업하기 더 편안한 다른 예를 살펴보겠습니다. 인보이스 번호, 인보이스 날짜, 인보이스 금액, 판매가 발생한 영업소 및 기타 데이터로 구성된 테이블을 가정합니다. 매일 이 테이블에 10,000개의 레코드가 삽입된다고 가정합니다. 이 경우, 사용자는 영업소 기준으로 인보이스 금액을 쿼리하는 일이 대부분입니다. 따라서 스캔이 실행되는 영역이 영업소이므로 이 열을 기준으로 클러스터된 인덱스가 만들어져야 할 것입니다. 또한 새롭게 삽입되는 행이 서로 다른 영업소가 뒤섞인 형태이므로 삽입은 테이블 전체에 균등히 분산되며 테이블이 위치한 디스크들 전체에 균등하게 분산될 것입니다.

어떤 경우 범위 스캔은 중요한 문제가 아닐 수 있습니다. 아주 큰 고용인 테이블에 사원 번호, 주민 번호 및 기타 데이터가 있는 것으로 가정합니다. 열이 삽입되면 사원 번호는 증가할 것입니다. 매일 이 테이블에 대해 검색이 100,000번 이루어지며 매번 검색마다 단일 레코드가 주민 번호를 기준으로 반입된다고 가정합니다. 이 시나리오에서는 주민 번호에 만들어진 클러스터되지 않은 인덱스가 뛰어난 쿼리 성능을 제공할 것입니다. 주민 번호에 대한 클러스터된 인덱스는 클러스터되지 않은 인덱스보다 약간 좋은 쿼리 성능을 제공할 수 있지만 범위 스캔이 포함되지 않으므로 과도한 것이 될 수 있습니다. 이 경우의 문제는 테이블에 클러스터된 인덱스를 정의할 필요가 있는가 하는 것입니다. 이전 버전의 SQL Server에서는 삭제된 공간 복구에 도움이 되므로 쿼리에 필요하지 않더라도 항상 클러스터된 인덱스를 정의하는 것이 중요했습니다. 이는 SQL Server 7.0의 새로운 공간 할당 알고리즘과 저장 구조에서는 문제되지 않습니다. 이 예에서는 주민 번호에 대해 클러스터된 인덱스를 만들 것을 권장합니다. 그 이유는 사원 번호의 순차적 패턴을 따르지 않는 방식으로 배포된 데이터가 있는 열을 찾는 것이 좋으며 주민 번호가 아주 균등하게 배포되어 있기 때문입니다. 이렇게 균등히 배포된 열 데이터에 클러스터된 인덱스가 만들어지면 사원 기록이 디스크에 균등히 배포됩니다. 다음 절에서 설명할 FILLFACTOR와 PAD_INDEX와 관련하여 이러한 배포는 데이터를 삽입할 테이블 전체에 개방 데이터 영역을 제공합니다. 새로 삽입된 사원 기록에서 주민 번호가 균등하게 배포된다고 가정하면 사원 테이블은 균등하게 채워질 것이고 페이지 분할을 피할 수 있습니다.균등하게 배포된 열이 테이블에 존재하지 않으면 테이블에 정수 열을 만들고 이 열에 균등히 배포된 값을 집어 넣은 후 클러스터된 인덱스가 이 열에 만들어지도록 하는 것이 좋습니다. 클러스터된 인덱스가 정의되어 있는 "충전용" 또는 "가짜" 열이 쿼리에 사용되는 것은 아니지만, 데이터 I/O를 디스크 드라이브 전체에 균등히 배포하여 테이블 액세스 동시성을 향상하고 전체 I/O 성능을 향상시키는 데 사용할 수 있습니다. 이는 액세스가 빈도가 높은 SQL 테이블에 아주 효과적인 방법이 될 수 있습니다. 이 예제에서 또 다른 해결책은 이 테이블에 클러스터된 인덱스를 만들지 않는 것입니다. 이 경우 SQL Server 7.0은 공간 관리의 모든 면을 관리합니다. SQL Server는 열을 삽입할 사용 가능한 공간을 찾고, 삭제된 열에서 공간을 복구하고, 자동으로 가능한 경우 더 많은 순차 I/O를 가능하게 하기 위하여 데이터 페이지의 물리적 순서를 인지합니다. 데이터 페이지에 대한 인지는 데이터베이스 파일 autoshrink 작업 과정에서 이루어집니다. 자세한 내용은 SQL Server 온라인 설명서에서 "Managing Space Used by Objects"와 "Space Allocation and Reuse" 문자열을 검색해 보십시오.

핫스폿은 선택의 맥락에서 다르게 생각해 볼 수 있습니다. 많은 사용자들이 아주 가깝지만 실제로는 서로 같은 행에 있지 않은 키 값을 가진 데이터를 선택하는 경우 디스크 I/O 작업의 대부분은 디스크 I/O 하위 시스템의 같은 물리적 영역 안에서 발생하는 경향이 있습니다. 이 디스크 I/O 작업은 이 테이블의 열에 클러스터된 인덱스를 정의하여 이 키 값을 디스크 전체에 균등하게 분산시킴으로써 더 골고루 분할되도록 할 수 있습니다. 모든 선택이 동일한 고유 키 값을 사용하는 경우에는 클러스터된 인덱스를 사용하더라도 이 테이블에서의 디스크 I/O 작업의 균형에 도움이 되지 않을 것입니다. RAID(하드웨어이건 소프트웨어이건)를 사용하는 것이 이 문제를 완화시키고 I/O를 많은 디스크 드라이브로 분산시키는 데 도움이 될 것입니다. 여기에 설명한 동작 형태는 디스크 액세스 경합으로 볼 수 있습니다. 그러나 잠금 경합은 아닙니다.

FILLFACTOR와 PAD_INDEX의 중요성

SQL Server 데이터베이스에 삽입 작업이 많이 일어나는 경우, 인덱스와 데이터 페이지에 개방 공간을 제공하고 유지하여 페이지 분할을 방지하도록 계획하는 것이 중요합니다. 페이지 분할은 인덱스 페이지나 데이터 페이지에 더 이상 새로운 페이지를 넣을 수 없으며 해당 페이지에 정의된 데이터의 논리절 순서 때문에 행이 페이지에 삽입되어야 하는 경우 발생합니다. 이 경우가 발생하면 SQL Server는 가득 찬 페이지에서 데이터를 나누어 데이터의 약 절반을 새로운 페이지로 옮겨 양쪽 페이지에 어느 정도 개방 공간이 있도록 합니다.이는 어느 정도 시스템 리소스와 시간을 소모합니다.

인덱스가 처음 구축될 때, SQL Server는 연속적인 물리적 페이지에 인덱스 B-트리 구조를 배치하며, 이는 인덱스 페이지를 순차 I/O로 스캔하는 I/O 성능을 최적으로 만듭니다. 페이지 분할이 발생하고 새로운 페이지가 인덱스의 논리적 B-트리에 삽입되어야 하는 경우, SQL Server는 새로운 8KB 인덱스 페이지를 할당해야 합니다. 이는 하드 드라이브의 다른 위치에서 발생하며 물리적으로 순차적인 인덱스 페이지의 특성을 파괴합니다. 이렇게 되면 I/O 작업이 순차에서 비순차로 전환되며 성능은 반으로 떨어집니다. 과도한 페이지 분할을 없애려면 인덱스를 재구축하여 인덱스 페이지의 물리적으로 순차적인 순서를 복구해야 합니다. 이와 동일한 작업이 클러스터된 인덱스의 잎 수준에서도 발생할 수 있으며, 따라서 테이블의 데이터 페이지에 영향을 미칩니다.

성능 모니터에서 "SQL Server: Access Methods - Page Splits"을 눈 여겨 보십시오. 이 카운터의 값이 0이 아니면 이는 페이지 분할이 일어난다는 뜻이며 DBCC SHOWCDONTIG을 사용하여 추가 분석을 수행하여야 합니다. 이 명령의 사용에 대한 자세한 내용은 SQL Server 온라인 설명서에서 "DBCC SHOWCONTIG" 문자열을 검색해 보십시오.

DBCC SHOWCONTIG는 아주 유용한 명령어로 테이블에 과도한 페이지 분할이 발생하는지 여부를 알아볼 수 있습니다. DBCC SHOWCONTIG가 제공하는 주요 지표는 스캔 밀도입니다. 이 값은 가능한 100%에 가깝도록 하는 것이 좋습니다. 이 값이 100% 아래로 많이 내려가면 DROP-EXISTING 옵션을 사용하여 테이블의 클러스터된 인덱스를 재구축하고 테이블 조각을 모아야 합니다. CREAT INDEX 문의 DROP_EXISTING 옵션을 사용하면 기존 인덱스를 다시 만들 수 있으며 인덱스를 삭제하고 다시 만드는 것보다 더 높은 인덱스 재구축 성능을 제공합니다. 자세한 내용은 SQL Server 온라인 설명서에서 "Create Index"와 "regulding an index" 문자열을 검색해 보십시오.

CREATE INDEX와 DBCC REINDEX 명령에서 FILLFACTOR 옵션을 사용하면 인덱스와 데이터 페이지에 남겨 두어야 할 개방 공간의 비율을 지정할 수 있습니다. CREATE INDEX 메뉴의 PAD_INDEX 옵션은 비잎 수준 인덱스 페이지에서 FILLFACTOR 옵션으로 지정한 값을 적용합니다. PAD_INDEX 옵션을 사용하지 않으면 FILLFACTOR는 주로 클러스터된 인덱스의 잎 수준 인덱스 페이지에만 영향을 미칩니다. FILLFACTROR와 함께 PAD_INDEX 옵션을 사용하는 것이 좋습니다. 자세한 내용은 SQL Server 온라인 설명서에서 "page split"과 "pad_index" 문자열을 검색해 보십시오.

FILLFACTOR에 지정할 최적 값은 주어진 시간 범위 내에 새로운 데이터가 얼마나 8KB 인덱스와 데이터 페이지에 삽입될 것인가에 따라 달라집니다. 인덱스 페이지에는 단지 이 인덱스에 관련된 열에 대한 데이터만 포함되어 있는 반면, 데이터 페이지에는 전체 행에 대한 데이터가 포함되어 있으므로 SQL Server 인덱스 페이지에 보통 더 많은 열이 포함되어 있음을 반드시 염두에 두어야 합니다. 또한 페이지 분할을 방지하기 위하여 인덱스를 재구축할 수 있는 유지 관리 창을 얼마나 자주 사용할 것인지도 염두에 두어야 합니다. 오직 다수의 인덱스와 데이터 페이지가 데이터로 가득 찰 경우에만 인덱스를 재구축해야 합니다. 이 작업이 가능하도록 하려면 주어진 테이블에 대해 클러스터 인덱스를 적절히 선택해야 합니다. 클러스터된 인덱스가 데이터를 균등히 분산하여 테이블에 삽입하는 새로운 열이 테이블에 연관된 모든 데이터 페이지 전체에 걸쳐 발생하면 데이터 페이지의 양은 균등해질 것입니다. 전제적으로 이렇게 하면 페이지 분할이 발생하기 시작하고 클러스터된 인덱스를 재구축해야 하기 전에 더 많은 시간을 벌 수 있습니다. 결정의 다른 부분은 FILLFACTOR에 있습니다. 이는 부분적으로 주어진 시간 동안 8KB 페이지의 키 범위 내에서 삽입될 열의 수와 시스템에서 예정된 인덱스 재구축이 얼마나 자주 일어날지를 추정하여 선택하여야 합니다.

이는 판단을 내려야 하는 또 다른 상황으로서, 페이지에 개방 공간을 많이 남기는 것과 페이지 분할이 이루어지도록 하는 것 중 성능 면에서 유리한 쪽을 선택해야 합니다. FILLFACTOR의 비율이 작은 경우 인덱스와 데이터 페이지에는 개방 공간이 많이 남게 될 것입니다. 이렇게 하면 페이지 분할은 예방되지만 페이지에 데이터를 압축함에 따른 성능 효과가 어느 정도 낮아집니다. SQL Server는 일반적으로 페이지에 데이터가 압축되어 있으면 페이지와 I/O가 적어도 더 많은 데이터를 반입할 수 있으므로 인덱스와 데이터 페이지에 데이터가 더 많이 압축되어 있을수록 성능이 더 빠릅니다. FILLFACTOR를 너무 높게 지정하면 페이지의 개방 공간이 너무 작아지므로 페이지가 더 빠르게 채워지고 페이지 분할의 원인이 됩니다.

FILLFACTOR와 PAD_INDEX를 사용하기 전에, 온라인 트랜잭션 처리(OLTP) 시스템에서도 읽기가 쓰기보다 훨씬 많은 경향이 있다는 사실을 기억해야 합니다. FILLACTOR를 사용하면 테이블이 더 넓은 영역으로 분산되므로(즉, 데이터 압축이 줄어들어) 모든 읽기 작업이 느려집니다. FILLFACTOR와 PAD_INDEX를 사용하기 전에 성능 모니터를 사용하여 SQL Server 읽기와 SQL Server 쓰기를 비교하고 쓰기가 읽기의 상당 부분을 차지하는 경우에만(예를 들면 30% 이상) 이 옵션을 사용합니다.

쓰기가 읽기의 상당 부분을 차지하는 경우, 사용이 아주 많은 OLTP 시스템에서 최선의 접근 방법은 FILLFACTOR를 8KB 페이지당 최소한의 사용 가능한 공간을 유지하지만 여전히 페이지 분할을 방지하고 SQL Server가 인덱스 재구축을 위해서 다음에 사용할 수 있는 시간 창에 도달하도록 가능한 높게 설정하는 것입니다. 이 방법은 I/O 성능(페이지가 가능한 가득 차도록 유지)과 페이지 분할 방지(페이지 오버플로 방지) 사이에 균형을 유지합니다. 이를 위해서는 여러 가지 FILLFACTOR 수준으로 인덱스를 재구축하고 테이블에 모의 부하 작업을 적용하여 FILLFACATOR의 최적 값을 확인하는 실험이 필요합니다. 일단 최적의 FILLFACTOR 값이 결정되면 예정된 인덱스 재구축 작업을 SQL Server 작업 계획으로 자동화합니다. 작업 자동화에 대한 자세한 내용은 SQL Server 온라인 설명서에서 "creating a task" 문자열을 검색해 보십시오.

SQL Server 데이터베이스로 쓰기 작업이 전혀 없는 상황에서는 FILLFACTOR를 100%로 설정하여 인덱스와 페이지가 모두 완전히 채워져서 최대한의 I/O 성능을 발휘하도록 해야 합니다.

SQL Server 성능 조정 도구

데이터 예제 및 작업 부하

SQL Server 성능 도구 사용 방법을 설명하기 위해 다음과 같은 예제를 사용할 것입니다. 첫째, 아래와 같이 테이블을 만듭니다.

create table testtable (nkey1 int identity, col2 char(300) default 'abc', ckey1 char(1))

다음 테이블에 테스트 데이터 10,000행을 넣습니다. nkey1 열에 들어가는 데이터는 클러스터되지 않은 인덱스가 됩니다. ckey1 열의 데이터는 클러스터된 인덱스가 되며 col2의 데이터는 단순히 각 열의 크기를 300바이트 늘리기 위한 채우기입니다.

declare @counter int

set @counter = 1

while (@counter <= 2000)

시작

insert testtable (ckey1) values ('a') insert testtable (ckey1) values ('b') insert testtable (ckey1) values ('c') insert testtable (ckey1) values ('d') insert testtable (ckey1) values ('e') set @counter = @counter + 1

end

아래 두 쿼리는 데이터베이스 서버 작업 로드를 만듭니다.

select ckey1,col2 from testtable where ckey1 = 'a' select nley1,col2 from testtable where nkey1 = 5000

프로파일러

SQL Server 프로파일러는 데이터베이스 서버에서 발생하는 작업에 대한 정보를 자세히 기록합니다. 프로파일러는 광범위하게 구성할 수 있는 양의 성능 정보로 SQL Server에서 퀴리를 수행하는 단일 또는 다수 사용자를 감시하고 기록하도록 구성될 수 있습니다. 프로파일러에 기록할 수 있는 성능 정보에는 I/O 통계, CPU 통계, 잠금 요청, T-SQL 및 RPC 통계, 인덱스 및 테이블 스캔, 제기된 경고 및 오류, 데이터베이스 개체 만들기/삭제, 연결/연결 해제, 저장된 프로시저 작업, 커서 작업 등이 포함됩니다. SQL 프로파일러가 기록할 수 있는 사항에 대한 자세한 내용은 SQL Server 온라인 설명서에서 "Profiler" 문자열을 검색해 보십시오.

.trc 파일의 프로파일러 정보를 로드하여 인덱스 튜닝 마법사와 함께 사용

프로파일러와 인덱스 튜닝 마법사는 데이터베이스 관리자가 테이블에 적절한 인덱스를 만드는 데 도움이 되는 강력한 도구 조합입니다. 프로파일러는 쿼리용 리소스 소모량을 .trc 파일에 기록합니다. 인덱스 튜닝 마법사는 이 .trc 파일을 읽어 .trc 정보와 데이터베이스 테이블을 모두 고려하고, 이후 만들어져야 할 인덱스에 대한 권장 사항을 제공합니다. 인덱스 튜닝 마법사에서는 데이터베이스에 적합한 인덱스를 자동으로 만들거나, 나중에 자동으로 인덱스를 만들도록 예정하거나, 나중에 검토하고 실행할 수 있는 T-SQL 스크립트를 생성할 수 있는 선택 사항을 제공합니다.

쿼리 부하를 분석하는 단계는 아래와 같습니다.

프로파일러 설정

1. 메뉴에서 Tools/SQL Server Profiler를 선택하여 SQL Server 엔터프라이즈 관리자에서 프로파일러를 시작합니다.
2. CRTL+N을 눌러 새로운 프로파일러 추적을 만듭니다.
3. 추적의 이름을 입력합니다.
4. Capture to File: 확인란을 선택하고 프로파일러 정보를 출력할 .trc 파일을 선택합니다.
5. OK를 누릅니다.

작업 부하 실행

1. 쿼리 분석기를 시작합니다. 메뉴에서 Tools/SQL Server Query Analyzer를 선택하여 SQL Server 엔터프라이즈 관리자에서 시작하거나, Start메뉴에서 Start\Programs\Microsoft SQL Server 7.0\Query Analyzer를 선택하여 시작하면 됩니다.
2. SQL Server에 연결하고 현재 데이터베이스를 테이블이 만들어진 곳으로 설정합니다.
3. 쿼리 분석기의 쿼리 창에 아래 쿼리를 입력하거나 복사하여 붙여넣습니다.

   select ckey1,col2 from testtable where ckey1 = 'a'

   select nkey1,col2 from testtable where nkey1 = 5000

4. CTRL+E를 눌러 두 가지 쿼리를 실행합니다.

프로파일러 중지

• 빨간색 사각형을 눌러 프로파일러 추적을 중지합니다.

인덱스 튜닝 마법사에 .trc 파일 로드

1. 메뉴에서 Tools\Index Tuning Wizards를 선택하여 프로파일러에서 인덱스 튜닝 마법사를 시작합니다.Next를 누릅니다.
2. 분석할 데이터베이스를 선택합니다.Next를 누릅니다.
3. I have a saved workload file 옵션 버튼이 선택된 상태에서 Next를 누릅니다.
4. My workload file 옵션 버튼을 선택하고 프로파일러에서 만든 .trc 파일을 찾은 후 Next를 누릅니다.
5. Select Tables to Tune 대화 상자에서 분석할 테이블을 선택하고 Next를 누릅니다.
6. 인덱스 튜닝 마법사는 Index Recommendations 대화 상자에 만들 적절한 인덱스를 표시합니다. Next를 누릅니다.
7. 마법사는 인덱스를 즉각 만들거나, 인덱스 작성 일정을 세우거나, 나중을 위하여 작업을 자동화하거나, 인덱스를 만드는 명령어를 사용하여 T-SQL 스크립트를 만들 수 있는 옵션을 제공합니다. 원하는 옵션을 선택하고 Next를 누릅니다.
8. Finish를 누릅니다.

인덱스 튜닝 마법사에서 만든 데이터베이스 예제 및 작업 부하용 T-SQL

/* Created by:Index Tuning Wizard */ /* Date: 9/7/98 */ /* Time:6:42:00 PM */ /* Server:HENRYLNT2 */ /* Database :test */ /* Workload file :E:\mssql7\Binn\profiler_load.sql */ USE [test] BEGIN TRANSACTION CREATE CLUSTERED INDEX [testtable2] ON [dbo].[testtable] ([ckey1]) if (@@error <> 0) rollback transaction CREATE NONCLUSTERED INDEX [testtable1] ON [dbo].[testtable] ([nkey1]) if (@@error <> 0) rollback transaction COMMIT TRANSACTION

예제 테이블과 데이터용으로 인덱스 튜닝 마법사가 권장하는 인덱스는 우리가 예상했던 것과 같습니다. ckey1에는 단지 다섯 개의 고유한 값이 있으며 각 값에는 2,000개의 행이 있습니다. 예제 쿼리 중 하나(select ckey1, col2 from testtable where ckey = 'a')가 ckey1의 값들 중 하나를 기준으로 한 테이블에서의 검색을 요구하는 경우, ckey1 열에 클러스터된 인덱스를 만드는 것이 좋습니다. 둘째 쿼리(select nkey1, col2 from testtable where nkey1 = 5000)는 nkey1 열의 값을 기준으로 행 하나를 반입합니다. nkey1은 고유하며 10,000개의 행이 있으므로 이 열에는 클러스터되지 않은 인덱스를 만드는 것이 좋습니다.

프로파일러/인덱스 튜닝 마법사 조합은 많은 테이블과 많은 쿼리가 뒤얽힌 실제 데이터 서버 환경에서 아주 강한 위력을 발휘합니다. 데이터베이스 서버에 대표적인 쿼리 집합이 발생하는 경우에는 프로파일러를 사용하여 .trc 파일을 기록합니다. 그런 다음 .trc 파일을 인덱스 튜닝 마법사에 로드하여 구축해야 할 적절한 인덱스를 결정합니다. 인덱스 튜닝 마법사의 안내에 따라 자동으로 인덱스를 생성하고 인덱스 작성 작업이 바쁘지 않은 시간에 수행되도록 일정을 세웁니다. 프로파일러/인덱스 튜닝 마법사를 정기적으로(아마도 매주) 실행하여 데이터베이스에서 실행되는 쿼리가 많이 변화하였는지 확인하고 이로 인해 다른 인덱스가 필요하지 않은지 확인하십시오. 프로파일러/인덱스 튜닝 마법사를 정기적으로 사용하면 시간이 지나면서 따라 쿼리 작업 부하가 변화하고 데이터베이스의 크기가 증가함에 따라 데이터베이스 관리자가 SQL Server를 최적의 상태로 운영하는 데 도움이 됩니다.

자세한 내용은 SQL Server 온라인 설명서에서 "Index Tuning Wizard"와 "Index Tuning Recommendations" 문자열을 검색해 보십시오.

분석을 위해 SQL Server 테이블로 프로파일러 정보 로드

프로파일러에서 사용할 수 있는 또 다른 옵션은 정보를 SQL Server 테이블에 기록하는 것입니다. 일단 이 작업이 완료되면 테이블을 쿼리하여 어떤 쿼리가 리소스를 과도하게 사용하고 있는지 판단할 수 있습니다.

SQL Server 테이블에 프로파일러 정보 기록

1. 메뉴에서 Tools/SQL Server Profiler를 선택하여 SQL Server 엔터프라이즈 관리자에서 프로파일러를 시작합니다.
2. CRTL+N을 눌러 새로운 프로파일러 추적을 만듭니다.
3. 추적의 이름을 입력합니다.
4. Capture to Table: 확인란을 누르고 프로파일러 정보를 출력할 대상 SQL Server 테이블을 선택합니다.
5. OK를 누릅니다.
6. 작업이 끝났으면 빨간색 사각형을 눌러 프로파일러 추적을 중지합니다.

쿼리 분석기로 프로파일러에 기록된 정보 분석

정보가 SQL Server 테이블에 기록되면 쿼리 분석기를 사용하여 시스템의 어떤 쿼리가 가장 많은 리소스를 소비하는지 알 수 있습니다. 이 방법으로 데이터베이스 관리자는 가장 도움이 많이 필요한 쿼리를 개선하는 데 시간을 집중할 수 있습니다. 예를 들어, 아래 쿼리는 프로파일러에서 SQL Server로 기록된 데이터를 분석한 전형적인 형태일 것입니다. 이 쿼리는 데이터베이스 서버에서 CPU 리소스를 가장 많이 소비하는 상위 세가지 쿼리를 검색합니다. 쿼리 지속 시간(밀리초 단위)과 함께 읽기 및 쓰기 I/O 정보도 반환됩니다. 프로파일러로 기록한 정보의 양이 많은 경우에는 테이블에 인덱스를 만들어 분석 쿼리 속도를 높이는 것이 좋습니다. 예를 들어, 아래 테이블을 분석하는 데 CPU가 중요한 기준이 된다면 CPU 열에 클러스터되지 않은 인덱스를 만들면 좋을 것입니다.

select top 3 TextData,CPU,Reads,Writes,Duration from profiler_out_table order by cpu desc

자세한 내용은 SQL Server 온라인 설명서에서 "Viewing and Analyzing Traces", "Troubleshooting SQL Server Profiler", "Tips for Using SQL Server", "Common SQL Server Profiler Scenarios", "Starting SQL Server Profiler", "Monitoring with SQL Server Profiler" 등의 문자열을 검색해 보십시오.

쿼리 분석기

통계 I/O

쿼리 분석기에서 Connections Options 대화 상자의 General 탭에서 Show stats I/O 옵션을 사용할 수 있습니다. 이 확인란을 선택하면 쿼리 분석기에서 방금 실행한 쿼리에 I/O가 어느 정도 소비되었는지에 대한 정보를 구할 수 있습니다.

예를 들어, "select ckey1, col2 from testtable where ckey1 = 'a'" 쿼리는 Show stats I/O 옵션이 선택되었을 때 아래 I/O 정보와 resultset를 반환합니다.

Table ‘testtable'.Scan count 1, logical reads 400, physical reads 382, read-ahead reads 400.

마찬가지로 "select nkey1, col2 from testtable where nkey1 = 5000" 쿼리는 Show stats I/O 옵션이 선택되었을 때 아래 I/O 정보와 resultset를 반환합니다.

Table ‘testtable'.Scan count 1, logical reads 400, physical reads 282, read-ahead reads 400.

통계 I/O를 사용하는 것은 쿼리 조정 효과를 모니터하는 데 아주 좋은 방법입니다. 예를 들어, 인덱스 튜닝 마법사로 위에서 권장한 것과 같이 이 예제 테이블에서 두 개의 인덱스를 만들고 쿼리를 다시 실행합니다.

"select ckey1,col2 from testtable where ckey1 = 'a'" 쿼리의 경우 클러스터된 인덱스는 아래와 같이 성능을 향상시킵니다. 쿼리가 테이블의 20%를 반입해야 한다고 할 때, 성능 향상은 합리적인 것으로 보입니다.

Table ‘testtable'.Scan count 1, logical reads 91, physical reads 5, read-ahead reads 32.

"select nkey1,col2 from testtable where nkey1 = 5000" 쿼리의 경우, 클러스터되지 않은 인덱스를 만들면 쿼리의 성능에 아주 극적인 영향을 미칩니다. 이 쿼리에 대하여 10,000행으로 이루어진 테이블 중 오직 하나의 행만이 검색된다고 할 때, 클러스터되지 않은 인덱스에 의한 성능 향상은 합리적으로 보입니다.

Table ‘testtable'.Scan count 1, logical reads 5, physical reads 0, read-ahead reads 0.

실행 계획

실행 계획은 쿼리 최적화 프로그램이 수행하는 작업에 대한 정보를 자세히 표시하여 문제가 있는 SQL 쿼리에 주의를 집중하는 데 사용할 수 있습니다. SQL Server 7.0에는 텍스트 및 그래픽 버전의 실행 계획이 모두 제공됩니다. 그래픽 실행 계획은 CTRL+L 키로 SQL 쿼리를 실행하여 쿼리 분석기의 결과 창에 표시할 수 있습니다. 아이콘은 쿼리 최적화 프로그램이 쿼리를 실행한 경우 수행했을 작업을 표시합니다. 화살표는 쿼리에 대한 데이터 흐름 방향을 표시합니다. 마우스 포인터를 작업 아이콘 위에 놓으면 각 작업에 대한 세부 사항이 표시됩니다. "set showplan_all on" 명령을 실행하면 같은 정보를 텍스트 기반의 실행 계획으로 표시할 수 있습니다. 텍스트 기반 실행 계획을 축소하여 쿼리 최적화 프로그램의 작업은 표시하지만 작업 세부 사항은 표시하지 않으려면 "set shoplan_text on" 명령을 실행합니다.

자세한 내용은 SQL Server 온라인 설명서에서 "Graphical ShowPlan", "Using ShowPlan to Monitor a Database Query", "worktables", "Understanding Nested Loops Joins" 등의 문자열을 검색해 보십시오.

실행 계획 출력 예제

앞에서 정의한 쿼리 예제와 쿼리 분석기에서 실행한 "set shoplan_text on"을 사용합니다.

쿼리:

select ckey1,col2 from testtable where ckey1 = 'a'

텍스트 기반의 실행 계획 출력

|--Clustered Index Seek(OBJECT:([test].[dbo].[testtable].[testtable2]), SEEK:([testtable].[ckey1]='a') ORDERED)

"Clustered Index Seek"에서 볼 수 있는 것처럼 앞의 쿼리는 ckey1 열에서 클러스터된 인덱스를 활용합니다.

같은 결과의 그래픽 실행 계획 출력:

그림 3 클러스터 인덱스를 활용하는 쿼리에 대한 그래픽 실행 계획 출력

클러스터된 인덱스가 테이블에서 제거된 경우, 쿼리는 테이블 스캔을 사용해야 합니다. 아래 실행 계획 출력은 작업 변경 사항을 보여줍니다.

텍스트 기반의 실행 계획 출력

|--Table Scan(OBJECT:([test].[dbo].[testtable]), WHERE:([testtable].[ckey1]='a'))

같은 결과의 그래픽 실행 계획 출력:

그림 4 테이블 스캔을 수행하는 쿼리에 대한 그래픽 실행 계획 출력

작은 테이블에 대한 테이블 스캔은 걱정할 것이 없습니다. 작은 테이블에서 정보를 검색하는 데에는 테이블 스캔이 가장 효율적인 방법입니다. 그러나 더 큰 테이블의 경우 실행 계획이 보여주는 테이블 스캔은 테이블에 더 좋은 인덱스가 필요하거나 또는 기존 인덱스의 통계를 업데이트할 필요가 있다는 경고입니다. 업데이트에는 UPDATE STATISTICS 명령을 사용합니다. SQL Server 7.0에서는 자동으로 인덱스를 업데이트할 수 있습니다. SQL Server가 인덱스 통계를 자동으로 유지 관리하도록 하는 것이 좋은데, 이는 쿼리가 항상 양호한 인덱스를 사용할 수 있도록 하는 데 도움이 되기 때문입니다.

쿼리

select nkey1,col2 from testtable where nkey1 = 5000

텍스트 기반의 실행 계획 출력

|--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([test].[dbo].[testtable])) |--Index Seek(OBJECT:([test].[dbo].[testtable].[testtable1]), SEEK:([testtable].[nkey1]=5000) ORDERED)

같은 결과의 그래픽 실행 계획 출력

그림 5 클러스터된 인덱스의 장점을 활용하는 쿼리에 대한 그래픽 실행 계획 출력, 부분 1

그림 6 클러스터된 인덱스의 장점을 활용하는 쿼리에 대한 그래픽 실행 계획 출력, 부분 2

앞의 쿼리는 nkey1 열에서 클러스터되지 않은 인덱스를 사용합니다. 이는 nkey1 열에 대한 "Index Seek" 작업으로 알 수 있습니다. "Bookmark Lookup" 작업은 SQL Server가 인덱스 페이지에서 데이터 페이지로 포인터 점프하여 요청된 데이터를 검색해야 했다는 사실을 보여줍니다. 쿼리가 col1 열을 요청했으며 이는 클러스터되지 않은 인덱스의 부분이 아니기 때문에 포인터 점프가 필요했습니다.

쿼리

select nkey1 from testtable where nkey1 = 5000

텍스트 기반의 실행 계획 출력

|--Index Seek(OBJECT:([test].[dbo].[testtable].[testtable1]), SEEK:([testtable].[nkey1]=[@1]) ORDERED)

같은 결과의 그래픽 실행 계획 출력

그림 7 포함된 쿼리에 대한 그래픽 실행 계획 출력

앞의 쿼리는 nkey1에서 클러스터되지 않은 인덱스를 포함 인덱스로 사용합니다. 이 쿼리에는 "Bookmark Lookup" 작업이 필요했습니다. 이는 쿼리에 필요한 모든 정보(SELECT 및 WHERE절 모두)가 클러스터되지 않은 인덱스에 의하여 제공되기 때문입니다. 다시 말하면, 데이터 페이지로의 포인터 점프가 클러스터되지 않은 페이지에서 필요하지 않았다는 의미입니다. 책갈피 조회가 필요한 경우에 비해 I/O는 줄어듭니다.

성능 모니터

성능 모니터는 Windows와 SQL Server 운영이라는 측면에서 데이터베이스 서버에 어떤 일이 발생하는지에 대해 풍부한 정보를 제공합니다. SQL Server 고유의 카운터에 대해서는 SQL Server 온라인 설명서에서 "SQL Server:" 와 "object" 문자열 조합을 검색해 보십시오.

성능 모니터 그래프 모드에서는 최대값과 최소값에 주목해야 합니다. 평균값을 지나치게 강조해서는 안됩니다. 이는 아주 편향된 데이터 포인트인 경우에는 아무런 의미도 없기 때문입니다. 그래프 모양을 살펴보고 최소/최대를 비교하여 동작에 대해 정확히 판단해 보십시오. <백스페이스> 키를 사용하여 카운터를 흰색으로 강조 표시합니다.

성능 모니터를 대화형으로 살펴보면서 동시에 성능 모니터를 사용하여 모든 사용 가능한 Windows NT 및 SQL Server 성능 모니터 개체/카운터를 로그 파일에 기록할 수 있습니다. 샘플링 간격 설정에 따라 로그 파일의 크기가 얼마나 빨리 커질 것인지 결정됩니다. 로그 파일은 매우 빠른 속도로 상당히 커질 수 있습니다.(예를 들어, 모든 카운터를 사용하고 샘플링 간격이 15초인 경우 한 시간만에 100MB가 될 수 있습니다.) 이러한 유형의 파일을 저장할 수 있도록 시험 서버에 2GB 정도 여유가 있는 것이 좋습니다. 그러나 공간을 절약하는 것이 중요하다면 로그 간격을 크게 하여 성능 모니터가 자주 시스템을 샘플링하지 않도록 하십시오. 30에서 60초로 샘플링을 시도해 봅니다. 이렇게 하면 모든 카운터가 적당한 빈도로 다시 샘플링되지만 로그 파일의 크기는 작게 유지됩니다.

성능 모니터는 또한 적은 양의 CPU와 디스크 I/O 리소스를 소비합니다. 시스템에 여분의 디스크 I/O 및 CPU가 많지 않다면 성능 모니터를 다른 컴퓨터에서 실행하고 네트워크를 통하여 SQL Server를 모니터하거나 또는 가장 중요한 카운터에만 로그 작업을 국한시키는 방법을 생각해 볼 수 있습니다. 네트워크를 통한 모니터는 그래픽 모드 전용으로서, 근거리 통신망(LAN)을 통하여 정보를 보내는 것에 비해 SQL Server에 성능 정보를 로컬로 로그하는 것이 더 효율적일 것입니다.

성능 테스트를 수행하는 동안 사용 가능한 카운터를 모두 기록하여 나중에 분석할 수 있도록 하는 것이 좋습니다. 이렇게 하면 나중에 모든 카운터를 검사할 수 있습니다. 성능 모니터가 모든 카운터를 로그 파일에 기록하도록 동시에 가장 관심 있는 카운터를 그래프 모드 같은 다른 모드에서 모니터할 수 있도록 구성합니다. 이렇게 하면 성능 실행이 이루어지는 동안 모든 정보가 기록되지만 가장 관심 있는 카운터는 산만하지 않은 성능 모니터에 표시할 수 있습니다.

로그 기능 시작

1. 성능 모니터를 시작합니다.
2. 메뉴에서 View/Log를 선택합니다.
3. + 기호가 있는 버튼을 누릅니다.
4. 간단히 모든 카운터를 로그 하려면 Add to Log 대화 상자에서 첫째 개체를 마우스 왼쪽 버튼으로 누릅니다.
5. SHIFT 키를 누른 상태에서 PAGE DOWN 키를 눌러 모든 카운터를 선택합니다.
6. Add를 누릅니다.
7. Done을 누릅니다.
8. 메뉴에서 Options/Log를 선택합니다.
9. File Name: 난에서 성능 정보를 로그할 파일 이름을 선택하거나 새로이 입력합니다.
10. Log Start를 누릅니다.

로그 기능 중지

1. 메뉴에서 Options/Log를 선택합니다.
2. Stop Log를 누릅니다.

분석을 위해 기록된 정보를 성능 모니터로 로드

1. 메뉴에서 View/Log를 선택합니다.
2. 메뉴에서 Options/Data From을 선택합니다.
3. Log File: 옵션 버튼을 누릅니다.
4. "U"가 표시된 버튼을 누르고 Open Input Log File 파일 찾아보기 창을 사용하여 로그 파일을 찾아 엽니다. 파일 이름을 두 번 누릅니다.
5. OK를 누릅니다.
6. + 기호가 있는 버튼을 누릅니다.
7. Add to Chart 대화 상자를 사용하여 원하는 카운터를 그래픽 표시에 추가합니다. 추가할 개체/카운터 조합을 선택하고 Add 버튼을 누릅니다.

성능 모니터 로그 이벤트를 적절한 지점으로 연결

이 기능은 데이터베이스 서버가 특정 시간 동안 어떤 작업을 했는지 관찰하는 데 편리한 기능입니다.

1. 앞의 설명과 같이 원하는 개체/카운터 선택하여 성능 모니터 차트 모드에 표시합니다.
2. 메뉴에서 Edit/Time Window를 선택합니다.
3. Input Log File Timeframe 대화 상자가 나타날 것입니다. 제공된 시간 창 슬라이드 바를 마우스 왼쪽 버튼으로 누른 채로 성능 모니터 차트에 표시할 기록된 데이터의 시작 및 정지 시간 창을 조절할 수 있습니다.
4. OK를 눌러 선택한 시간 창에 기록된 데이터만 표시되도록 차트를 다시 설정합니다.

주목해야 할 주요 성능 모니터 카운터

• (물리적 또는 논리적) 디스크 대기열 > 2

  이 부분에서는 여러 가지 성능 모니터 디스크 카운터를 관찰해야 합니다. 이 카운터를 사용하려면 Windows NT 명령 창에서 "diskperf -y" 명령을 실행하고 Windows NT를 다시 시작합니다.

  디스크 대기열이 발생하는 물리적 하드 드라이브에서는 I/O 요청을 보유하면서 I/O 처리를 방해할 것입니다. 이들 드라이브에서는 SQL Server 응답 속도가 느려질 것입니다. 이는 쿼리 실행 속도를 늦춥니다.

  RAID를 사용하는 경우 각 물리적 드라이브에 대한 디스크 대기열을 계산하려면 Windows NT가 단일 물리적 드라이브로 인식하는 각 드라이브 어레이에 연결된 물리적 하드 드라이브의 수를 알아야 합니다. 하드웨어 전문가에게 SCSI 채널과 물리적 드라이브 분산에 대한 설명을 요청하여 SQL Server 데이터가 각 물리적 드라이브에 보관되는 방법과 각 SCSI에 분산된 SQL Server 데이터의 양을 이해해야 합니다.

  성능 모니터를 통하여 디스크 대기열을 보는 방법은 여러 가지입니다. 논리적 디스크 카운터는 디스크 관리자를 통하여 지정된 물리적 드라이브 문자에 연결되는 데 반해, 물리적 디스크 카운터는 디스크 관리자가 단일 물리적 디스크 장치로 인식하는 것과 연결되어 있습니다. 디스크 관리자에게 단일 물리적 장치로 보이는 것은 단일 하드 드라이브일 수도 있고 여러 하드 드라이브로 구성된 RAID 어레이일 수도 있습니다. 현재 디스크 대기열은 디스크 대기열에 대한 즉각적인 측정인 데 반해, 평균 디스크 대기열은 성능 모니터 샘플링 기간 동안의 대기열 측정을 평균적으로 계산한 것입니다. 논리적 디스크: 평균 디스크 대기열 > 2, 물리적 디스크: 평균 디스크 대기열 > 2, 논리적 디스크: 현재 디스크 대기열 > 2, 또는 물리적 디스크: 평균 디스크 대기열 > 2인 모든 카운터를 살펴보십시오.

  이 권장 측정은 물리적 하드 드라이브별로 지정된 것입니다. RAID 어레이가 디스크 대기 측정에 관련된 경우, 측정값을 해당 RAID 어레이에 있는 물리적 하드 드라이브 수로 나누어 각 물리적 하드 드라이브의 디스크 대기열을 확인합니다.

  참고 SQL Server 로그 파일을 유지하는 물리적 하드 드라이브 또는 RAID 어레이의 경우, 디스크 대기열은 유용한 방법이 아닙니다. 이는 SQL Server 로그 관리자가 SQL Server 로그 파일에 하나 이상의 I/O 요청을 대기열로 보내지 않기 때문입니다.

  자세한 내용은 SQL Server 온라인 설명서에서 "monitoring disk activity" 문자열을 검색해 보십시오.

• 시스템:Processor Queue Length > 2 (/CPU)

  이것은 서버의 프로세서가 집합적인 그룹으로서 처리할 수 있는 것보다 더 많은 작업 요청을 받는다는 의미입니다. 따라서, Windows는 이 요청을 대기열에 넣어야 합니다.

  어떤 프로세서 대기열은 실제로 SQL Server I/O 성능이 전체적으로 양호함을 나타내는 것입니다. 프로세서 대기열이 없으며 CPU 활용도가 낮은 경우, 이는 시스템의 다른 곳에 성능 병목 현상이 있다는 표시일 수 있으며, 가장 가능성이 많은 곳은 디스크 하위 시스템입니다. 프로세서에 적당한 정도의 작업 대기가 있는 것은 CPU가 유휴 상태에 있지 않으며 시스템의 나머지 부분이 CPU와 보조를 맞추고 있다는 표시가 됩니다.

  양호한 프로세서 대기 수를 계산하는 가장 좋은 방법은 데이터베이스 서버의 CPU 수를 2로 나누는 것 입니다.

  이 수치를 상당히 초과하는 프로세서 대기열은 조사해 보아야 합니다. 프로세서 대기열이 과도하면 쿼리 실행 시간이 나빠집니다. 프로세서 대기열이 발생하는 데에는 여러 가지 다른 작업이 원인이 될 수 있습니다. 하드 및 소프트 페이징을 제거하는 것이 CPU 리소스를 절약하는 데 도움이 될 것입니다. 프로세서 대기열을 줄이는 데 도움이 되는 다른 방법으로는 SQL 쿼리 조정, 디스크 I/O(따라서 CPU까지) 감소를 위해 보다 나은 SQL 인덱스 선택 또는 시스템에 CPU(프로세서) 추가 등이 있습니다.

• 하드 페이징-Memory:Pages/sec > 0 or Memory:Page Reads/sec > 5

  Memory:Pages/sec > 0 or Memory:Page Reads/sec > 5는 Windows가 메모리 참조(하드 페이지 결함)를 해결하기 위하여 디스크로 간다는 의미입니다. 이 과정에서 디스크 I/O + CPU 리소스를 낭비합니다. Memory:Pages/sec는 Windows가 수행하는 페이징의 양과 데이터베이스 서버의 현재 RAM 구성이 적절한지를 보여주는 좋은 지표입니다. 성능 모니터 내의 하드 페이징 정보 중 한 가지 하위 집합은 Windows가 메모리 참조를 해결하기 위하여 1초에 페이징 파일에서 읽어야 하는 횟수로 이는 Memory:Pages Reads/sec로 표시됩니다. Memory:Pages Reads/sec가 > 5 이면 성능에 좋지 않습니다.

  자동 SQL Server 메모리 조정은 SQL Server 메모리 활용을 동적으로 조정함으로써 페이징을 예방하기 위하여 최선을 다 합니다. 초당 페이지 수가 적은 것은 정상이나 페이징이 과도하면 교정 작업이 필요합니다.

  SQL Server가 자동으로 메모리를 조정하는 경우, RAM을 추가하거나 데이터베이스 서버에서 다른 응용 프로그램을 제거하는 것이 Memory:Pages/sec를 합리적인 수준으로 만드는 데 도움이 될 수 있는 방법입니다.

  SQL Server 메모리를 데이터베이스 서버에서 직접 구성하는 경우, SQL Server에 주어진 메모리를 줄이고 데이터베이스 서버에서 다른 응용 프로그램을 제거하거나 데이터베이스 서버에 RAM을 추가해야 할 것입니다

  Memory:Pages/sec를 0에 가깝게 유지하는 것이 데이터베이스 서버 성능에 도움이 됩니다. 이는 Windows와 SQL Server를 포함한 모든 Windows 응용 프로그램이 메모리 요청의 데이터를 만족시키기 위해 페이징 파일로 가지 않는다는 의미이며, 따라서 서버의 RAM이 충분한 것입니다. Pages/sec가 0보다 약간 정도 큰 경우는 상관이 없지만, RAM과 비교할 때 페이징 파일에서 데이터를 검색할 때마다 상대적으로 성능(디스크 I/O)이 나빠진다는 점을 기억해야 합니다.

  "Memory:Pages Input/sec"와 "Memory:Pages Reads/sec"의 차이를 이해하고 넘어가는 것도 좋을 것입니다. "Memory:Pages Input/sec"는 페이지 결함을 해소하기 위하여 디스크에서 가져오는 실제 Windows 4KB 페이지 수를 표시합니다. "Memory: Pages Reads/sec"는 페이지 결함을 해소하기 위하여 1초에 발생한 디스크 I/O 요청의 수로, 이는 발생하는 결함에 대하여 약간 다른 시각을 제공합니다. 따라서 단일 페이지 읽기 하나에는 Windows 4KB 페이지가 여러 개 포함될 수 있습니다. 디스크 I/O 성능은 데이터의 패킷 크기가 클수록(64KB 이상) 좋아지므로 이 두 가지 카운터 모두를 동시에 고려하는 것이 좋습니다. 또한 하드 디스크의 경우 4KB를 한 번 읽거나 쓰는 작업은 소모되는 시간의 측면에서 64KB를 한 번 쓰거나 읽는 것과 같다는 것을 기억해야 합니다. 다음과 같은 상황을 생각해 봅시다. 읽기 한 번에 4KB 페이지로 구성된 200페이지 읽기는 4KB 페이지 하나로 구성된 300페이지 읽기보다 빠르게 완료될 수 있습니다. 또한 4KB로 된 1,600페이지 읽기 완료가 4KB로 된 3300페이지 읽기보다 빠르다는 것에 유의하십시오. 여기에서 중요한 점은 이것을 모든 디스크 I/O 분석에 적용할 수 있는가 하는 것입니다. Disk Bytes/sec 수 뿐만 아니라 Disk Transfers/sec도 주목해야 할 것입니다. 이 두 가지는 서로 관련이 있기 때문입니다. 이에 대해서는 다음의 디스크 I/O 절에서 자세히 설명할 것입니다.

  Windows NT 페이징 파일에 연결된 모든 드라이브에서 "Memory:Page Input/sec"와 "Logical Disk:Disk Reads/sec"를 비교하고 Windows 페이징 파일과 연결된 모둔 드라이브에서 "Memory:Page Output/sec"와 "Logical Disk:Disk Writes/sec"를 비교하는 것이 좋습니다. 이는 페이징과 기타 응용 프로그램(즉, SQL Server)에 전적으로 관련된 디스크 I/O의 양을 측정할 수 있기 때문입니다. 페이징 파일 I/O 작업을 쉽게 분리할 수 있는 또 다른 방법은 페이징 파일을 다른 모든 SQL Server 파일과 분리된 별도의 드라이브 세트에 배치하는 것입니다. SQL Server 파일에서 페이징 파일을 분리하면 페이징에 연결된 디스크 I/O가 SQL Server에 연결된 디스크 I/O와 병렬로 수행될 수 있으므로 디스크 I/O 성능이 향상됩니다.

• 소프트 페이징-Memory:Pages Fault/sec > 0

  Memory:Pages Faults/sec> 0은 Windows NT가 페이징을 하지만 하드 및 소프트 페이징 모두가 카운터 안에 포함된다는 것을 나타냅니다. 앞 절에서는 하드 페이징에 대해 설명했습니다. 소프트 페이징이란 데이터베이스 서버의 응용프로그램이 아직 RAM에 있지만 Windows 작업 집합 밖에 있는 메모리 페이지를 요청한다는 의미입니다. Memory:Page Faults/sec는 소프트 페이징 발생 양을 추정하는 데 도움이 됩니다. Soft Faults/sec라는 카운터는 없습니다. 대신에, 1초에 발생하는 소프트 결함의 수를 아래와 같이 계산합니다.

  "Memory:Pages Faults/sec" - "Memory: Pages Faults/sec" = Soft Page Fault/sec

  다른 프로세스가 아닌 SQL Server가 과도한 페이징을 유발하는지 판단하려면 SQL Server 프로세스에 대해 Process:page Faults/sec 카운터를 모니터하고 sqlserver.exe에 대한 초당 페이지 결함 수가 Memory:Pages/sec 수와 비슷한지 확인합니다.

  성능에 있어서, 소프트 결함은 CPU 리소스를 소모하는 하드 결함만큼 나쁘지 않습니다. 하드 결함은 디스크 I/O 리소스를 소모합니다. 성능을 위한 최선의 환경은 어떤 형태의 결함도 없는 환경입니다.

  SQL Server가 처음으로 모든 데이터 캐시 페이지에 실제로 액세스할 때까지는 각 페이지에 대한 첫째 액세스가 소프트 부재를 유발할 것입니다. 따라서 SQL Server가 처음 시작되고 데이터 캐시가 처음으로 실행되는 동안 발생하는 소프트 결함에 대해서는 신경을 쓸 필요가 없습니다.

  메모리 조정에 대한 자세한 내용은 SQL Server 온라인 설명서에서 "monitoring memory usage" 문자열을 검색해 보십시오.

프로세서 모니터링

서버의 모든 프로세서가 작업중인 상태로 만들어 성능을 최대화해야 하지만 프로세서 병목 현상이 발생할 정도가 되어서는 안됩니다. 성능 조정에서 어려운 점은, CPU에 병목 현상이 없는 경우 다른 곳(주로 디스크 하위 시스템)에서 병목현상이 발생하고 따라서 CPU가 낭비된다는 점입니다. 일반적으로 CPU는 가장 확장하기 어려운 리소스이므로(대부분의 현재 시스템에서 4 또는 8로 구성별 수준보다 높게) CPU 활용도를 95퍼센트 이상으로 하는 것이 좋습니다. 이와 동시에 트랜잭션의 반응 시간이 합당한 수준 내에 있는지 모니터해야 합니다. 그렇지 않다면 95% 이상의 CPU 사용이란 단순히 사용 가능한 CPU 리소스에 대한 작업 부하가 과도하며 CPU를 늘리거나 작업 부하를 감소 또는 조정해 한다는 뜻일 수 있습니다.

"Processor:Processor Time %" 성능 모니터 카운터를 보고 각 CPU에서 모든 프로세서의 활용도가 모두 지속적으로 95% 이하인지 확인합니다. "System:Processor Queue"는 Windows NT 시스템의 모든 CPU용 프로세서 대기열입니다. "System:Processor Queue"가 CPU 하나에 2 이상이면 CPU 병목 현상이 발생한 것입니다. CPU 병목 현상이 감지되면 서버에 프로세서를 추가하거나 시스템 작업 부하를 줄여야 합니다. 작업 부하는 쿼리 조정이나 인덱스를 개선하여 I/O를 줄임으로써 줄일 수 있으며 결과적으로 CPU 사용도 줄일 수 있습니다.

CPU 병목 현상이 의심되는 경우 주목해야 할 또 다른 성능 모니터 카운터는 "System:Context Switches/sec"이며, 이는 Windows NT와 SQL Server가 1초에 한 스레드의 작업을 다른 스레드로 변경해야 한 횟수를 표시합니다. 이는 CPU 리소스를 소모합니다. 컨텍스트 교환은 다중 스레드, 다중 프로세스 환경의 정상적인 구성 요소이지만, 컨텍스트 교환이 과도하면 시스템 성능이 저하됩니다. 필요한 조치는 프로세서 대기열이 있는 경우 컨텍스트 교환에만 신경 쓰는 것입니다. 프로세서 대기열이 있는 경우에는 SQL Server 성능을 조정할 때 컨텍스트 교환 수준을 일종의 게이지처럼 사용합니다. SQL Server가 기본값인 스레드 기반 스케줄링 모델에서 파이버 기반 스케줄링 모델로 전환하는 간편한 풀링 옵션을 사용할 수도 있습니다. 파이버를 가벼운 스레드로 생각하십시오. sp_configure 'lightweight pooling', 1 명령을 사용하여 파이버 기반 스케줄링을 사용 설정합니다. 프로세서 대기열과 컨텍스트 교환을 살펴보고 그 효과를 모니터합니다.

DBCC SQLPERF (THREADS)는 I/O, 메모리 및 spids로 다시 매핑된 CPU 사용에 대해 더 자세한 정보를 제공합니다. "select * from master.sysprocesses order by cpu desc" SQL 쿼리를 실행하여 현재 CPU 시간을 가장 많이 사용하는 것이 무엇인지 조사합니다.

디스크 I/O 카운터

"Disk Write Bytes/sec"와 "Disk Read Bytes/sec" 카운터는 각 논리 드라이브가 1초에 처리할 수 있는 데이터 바이트 수를 표시합니다. "Disk Reads/sec" 및 "Disk Writes/sec"와 함께 이 숫자를 신중히 평가해 보십시오. 초당 바이트 수의 양이 적더라도 I/O 하위 시스템이 작동 중이지 않은 것으로 생각해서는 안됩니다! 단일 하드 드라이브 하나가 1초에 75회의 비순차 및 150번의 순차 디스크 읽기 및 쓰기를 할 수 있다는 점을 기억하십시오.

SQL Server 파일에 연결된 모든 드라이브에 대한 "디스크 대기열 길이"를 모니터하고 어느 파일이 과도한 디스크 대기열에 관련되어 있는지 판단합니다.

성능 모니터가 어떤 드라이브는 다른 드라이브만큼 작업이 활발하지 않다고 표시하면, 병목 현상이 발생한 드라이브에서 SQL Server 파일을 한가한 드라이브로 옮길 수 있습니다. 이렇게 하면 I/O 작업을 하드 드라이브 전체에 더 균등하게 분산할 수 있습니다. SQL Server 파일용으로 대형 드라이브 풀 하나를 사용하는 경우, 발생하는 디스크 대기열에 대한 해결책은 풀에 더 많은 물리적 드라이브를 추가하여 풀의 I/O 용량을 늘리는 것입니다.

디스크 대기열은 SCSI 채널 하나에 I/O 요청이 가득 찬 상태일 수 있습니다. 성능 모니터는 이런 상황을 직접 감지할 수 없습니다. 하드웨어 공급업체는 RAID 콘트롤러가 서비스하는 I/O의 양을 감지하고 컨트롤러에 I/O 요청이 대기하고 있는지 감지하는 데 도움이 되는 도구를 제공할 수도 있습니다. 이 경우는 SCSI 채널에 디스크 드라이브가 많이(10개 이상) 장착되어 있고 이들 드라이브 모두가 최고 속도로 I/O를 수행하는 경우에 발생하기 쉽습니다. 이 경우 해결책은 디스크 드라이브의 반을 다른 SCSI 채널이나 RAID 컨트롤러에 연결하여 I/O 균형을 유지하는 것입니다. 일반적으로 SCSI 채널 전체에 드라이브를 균등하게 분산하려면 RAID 어레이를 다시 구축하고 SQL Server 데이터베이스 파일을 완전히 백업/복원해야 합니다.

성능 모니터 그래프 출력 예제

그림 8은 성능 모니터를 사용하여 관찰할 수 있는 전형적인 카운터를 나타낸 것입니다. Processor Queue Length 카운터를 현재 보고 있습니다. 현재 카운터를 밝은 흰색으로 강조하기 위하여 <백스페이스> 키를 누른 상태입니다. 이렇게 하면 현재 카운터를 다른 관찰되는 카운터와 구분할 수 있으며 특히 성능 모니터로 많은 카운터를 동시에 관찰할 때 도움이 됩니다.

Processor Queue Length의 최대값은 22.000입니다. 성능 모니터 그래프에서 Max, Min, Average 값은 그래프 시간으로 표시되는 그래프의 현재 시간 창에만 해당됩니다. 그래프 시간의 기본값은 100초입니다 더 긴 기간을 모니터하고 이 기간 동안의 대표적인 최대, 최소 및 평균값을 얻으려면 성능 관리자의 로깅 기능을 사용하십시오.

프로세서 대기열 그래프 모양을 보면 최대값 22가 단지 짧은 시간 동안만 발생했다는 것을 알 수 있습니다. 프로세서 대기열 길이가 5보다 큰 경우 최대값 22를 넘는 기간이 있습니다.(이것은 그래프에서 100%는 22이며 그래프가 약 5에 해당하는 25% 이상의 값을 갖는 경우 22 값이 되기 전에 일정 기간이 있다는 사실로 알 수 있습니다.) 이 예에서 \\HENRYLNT2라는 이름의 데이터베이스 서버에는 프로세스가 오직 하나 있으며 프로세서 대기열 길이가 2를 넘어서는 안됩니다. 따라서 성능 모니터는 이 컴퓨터의 프로세서에 때로 과도한 부하가 들어오며 추가 조사를 실시하여 프로세서 부하를 줄이거나 \\HENRYLNT2에 프로세서를 추가하여 이 프로세서 작업 부하가 높은 기간을 적절히 처리해야 한다는 것을 나타냅니다.

그림 8 성능 모니터 그래프 출력

성능에 관한 기타 설명

네트워크 트래픽 및 데이터베이스 서버 리소스 소모 감소

ADL/RDO/DAO 데이터베이스 API 같이 사용하기 쉬운 인터페이스로 SQL 작업을 하는 데이터베이스 프로그래머들은 자신이 구축하는 결과 집합을 확실히 알고 있어야 합니다. ADO/RDO/DAO는 프로그래머들이 SQL 프로그램 작성 경험이 많지 않아도 풍부한 SQL 행 집합 기능을 만들 수 있는 뛰어난 데이터베이스 개발 인터페이스입니다. 그러나 여기에는 대가가 있습니다. 프로그래머는 응용 프로그램이 클라이언트에게 반환하는 데이터의 양을 신중히 고려해야 하며, SQL Server 인덱스가 어디에 위치하고 있으며 SQL Server 데이터가 어떻게 배열되어 있는지 알고 있어야 합니다. SQL 프로파일러, 인덱스 튜닝 마법사 그리고 실행 계획은 이러한 문제 쿼리를 정확히 찾아내는 데 아주 좋은 도구입니다.

선택 리스트에서 반환할 필요가 없는 열을 제거하거나 오직 필요한 행만을 반환함으로써 기회가 있을 때마다 반환되는 결과 집합 크기를 줄여야 합니다. 이렇게 하면 I/O와 CPU 소모를 줄이는 데 도움이 됩니다.

자세한 내용은 SQL Server 온라인 설명서에서 "Optimizing Application Performance Using Efficient Data Retrieval", "Understanding and Avoiding Blocking", "Application Design" 등의 문자열을 검색해 보십시오.

교착 상태

SQL Server에 액세스하는 응용 프로그램을 트랜잭션이 모든 사용자 트랜잭션에 대하여 동일한 연대 순으로 테이블에 액세스하도록 만들면 교착 상태는 방지될 수 있습니다. 이러한 연대순 테이블 액세스에 대하여 가능하면 응용 프로그램 디자인 프로세스 초기에 SQL 응용 프로그램 개발자에게 명확히 설명하는 것이 좋습니다. 이렇게 하면 나중에는 고치기 더 힘든 교착 문제를 예방할 수 있습니다.

SQL 쿼리 I/O를 줄이고 트랜잭션 시간을 단축해야 합니다. 이는 교착 상태를 예방할 수 있는 우회적인 방법으로서 어쨌든 모든 쿼리에 대해 수행되어야 할 것이지만, 쿼리 속도를 빠르게 하여 리소스 잠금 상태를 보다 짧게 만들고 모든 잠금 경쟁(교착 상태 포함)이 줄어들게 하므로 도움이 될 수도 있습니다. SQL 쿼리 분석기의 SHOW STATS I/O를 사용하면 대형 쿼리와 관련된 논리적 페이지 반입 수를 결정할 수 있습니다. SQL 쿼리 분석기의 "Show query plan" 옵션을 선택하여 사용된 인덱스를 고려합니다. 인덱스 교체 또는 보다 효율적이고 I/O를 더 적게 사용하는 SQL 쿼리 디자인을 고려하십시오.

자세한 내용은 SQL Server 온라인 설명서에서 "Avoiding Deadlocks", "Troubleshooting Deadlocking", "Detecting and Ending Deadlocks", "Analogy to Nonserializable Transactions" 등의 문자열을 검색해 보십시오.

IF 연산을 피하기 위한 SQL

SQL 쿼리에서 부등호 연산자를 사용하면 데이터베이스가 부등호를 평가하기 위하여 테이블 스캔을 수행해야 합니다. 이러한 쿼리가 아주 큰 테이블에 대하여 자주 수행되면 I/O가 높아집니다.

예:

WHERE <column_name> != some_value WHERE <>column_name> < some_value Any WHERE expression with NOT in it

이런 형태의 쿼리를 실행해야 하는 경우에는 퀴리 구조를 바꾸어 NOT 키워드를 없애도록 하십시오.

예

원문 select * from tableA where col1 != "value" 대안 select * from tableA where col1 < "value" or col1 > "value"

이렇게 하면 SQL Server는 테이블 스캔을 다시 정렬하는 대신 col1에 대한 인덱스가 구축된 경우 해당 인덱스(이 경우, 클러스터된 인덱스)를 사용합니다.

정규화

아주 많이 사용되는(액세스가 많은) 테이블의 경우, SQL 응용 프로그램이 자주 사용하지 않는 열이 있으면 이 열을 다른 테이블로 옮기는 것이 좋습니다. 더 많은 열을 제거할수록 I/O를 줄이고 성능을 높이는 데 좋습니다. 자세한 내용은 SQL Server 온라인 설명서에서 "Logical Database Design"과 "Normalization" 문자열을 검색해 보십시오.

분할된 뷰

SQL Server 7.0은 뷰를 통해 테이블을 수평으로 분할할 수 있습니다. 이렇게 하면 데이터베이스 사용자가 하나의 테이블 이름을 참조하는 SQL 쿼리를 유지하고자 하지만 데이터 검색은 쿼리가 항상 데이터의 고정된 일부 섹션만을 쿼리하는 속성을 갖고 있는 경우에 I/O 성능을 높일 수 있습니다. 예를 들어, 한 영업 부서의 1년간 실적을 기록하는 아주 큰 테이블이 있고 이 테이블에 대한 검색이 모두 단일 영업 부서를 기준으로 하고 있다고 가정합니다. 이 시나리오에서 분할된 뷰를 사용할 수 있습니다. 영업 테이블은 각 영업 부서에 대하여 정의되어 있을 것이므로, 각 테이블의 영업 부서 열에 대한 제약 조건을 정의한 후 모든 테이블에 대하여 보기를 만들어 분할된 뷰를 구성합니다. 영업 부서 열에 대한 제약 조건은 쿼리 최적화 프로그램에 의해 사용됩니다. 뷰를 쿼리하면 쿼리 최적화 프로그램은 쿼리에서 제공한 영업 부서 값과 일치하지 않는 모든 영업 부서 테이블을 무시하며 이 테이블에 대해서는 어떤 I/O도 수행되지 않습니다. 이는 I/O를 줄임으로써 쿼리 성능을 높입니다.

자세한 내용은 SQL Server 온라인 설명서에서 "Scenarios for Using Views", "Create View", "Using Views with Partitioned Data", "Modifying Data Through a View", "Copying To or From a View", "Partitioning" 등의 문자열을 검색해 보십시오.

복제 및 백업 성능

디스크 I/O 하위 시스템과 CPU 성능을 좋게 하면 모든 SQL Server 작업 성능에 도움이 됩니다. 여기에는 말할 것도 없이 복제와 백업이 포함됩니다. 트랜잭션 복제와 트랜잭션 로그를 백업하려면 트랜잭션 로그 파일을 읽어야 합니다. 스냅샷 복제와 백업 작업에는 일련의 데이터베이스 파일 스캔이 수행됩니다. SQL Server 7.0의 새로운 저장 구조는 이 작업이 아주 빠르고 효율적으로 수행되도록 개선되었으므로 데이터베이스 서버의 CPU 또는 디스크 하위 시스템에 대기열이 발생하지 않습니다.

복제와 백업/복구 성능 조정에 대한 자세한 내용은 SQL Server 온라인 설명서에서 "Replication Performance", "Optimizing Backup and Restore Performance", "Creating and Restoring Differential Database Backups", "Creating and Applying Transaction Log Backups", "Using Multiple Media or Devices", "Minimizing Backup and Recovery Times in Mission-Critical Environments", "Backup/Restore Architecture", "SQL Server 7.0 on Large Servers" 등의 문자열을 검색해 보십시오.

특별한 디스크 I/O 성능 조정 시나리오: EMC Symmetrix 통합 캐시 디스크 어레이

EMC Symmetrix 엔터프라이즈 저장 시스템에 SQL Server 데이터베이스 시스템을 구현하는 경우, 디스크 I/O 병목 현상 문제를 예방하고 성능을 최대화할 수 있는 EMC Symmetrix 저장소의 특성으로 인하여 몇 가지 염두에 두어야 할 디스크 I/O 균형 조정 방법이 있습니다.

Symmetrix 저장 시스템에는 최고 16GB의 RAM 캐시가 포함되며 디스크 어레이에 내장 프로세스가 있어 호스트 서버 CPU 리소스를 사용하지 않고 데이터 I/O 처리 속도를 높입니다. Symmetrix 장치 안에는 디스크 I/O의 균형을 위하여 이해해야 할 네 가지 주요 구성 요소가 있습니다. 하나는 Symmetrix 내의 16GB 캐시입니다. 여기에는 Windows NT 호스트 서버에서 Symmetrix로 SCSI 카드를 최대 32개까지 연결할 수 있는 SA 채널이 32개까지 있으며 이 SA 채널은 모두 16GB 캐시에서 동시에 데이터를 요청할 수 있습니다. 또한 Symmetrix 장치에는 최대 32개의 DA 컨트롤러라는 커넥터가 있으며, 이는 내장 SCSI 컨트롤러로 Symmetrix 안의 모든 내장 디스크 드라이브를 내장 캐시로 연결합니다. 마지막으로, Symmetrix에는 하드 드라이브가 있습니다.

EMC 하드 드라이브에 대한 참고 사항: 이 SCSI 하드 드라이브는 이 설명서에서 설명한 다른 드라이브와 마찬가지의 I/O 용량을 갖추고 있습니다.(여기에도 75/150 규칙이 적용됩니다.) EMC 기술에 일반적으로 사용되는 기능 하나는 "하이퍼 볼륨"이라는 것입니다. 하이퍼 볼륨은 EMC 하드 드라이브의 논리적 부분으로, Windows NT 디스크 관리자에게는 하이퍼 볼륨은 그저 또 다른 물리적 하드 드라이브로 인식됩니다. 따라서 Windows NT 디스크 관리자를 사용하여 다른 디스크 드라이브와 마찬가지로 조작할 수 있습니다. 각 물리적 드라이브에 하이퍼 볼륨을 여러 개 정의할 수 있습니다. EMC 저장소에서 데이터베이스 성능 조정을 할 때에는 EMC 현장 엔지니어와 밀접히 협력하여 하이퍼 볼륨이 어떻게 정의되었는지를 알아야 하는데, 이는 데이터베이스 I/O로 인하여 물리적 드라이브에 과부하가 발생하는 것을 방지하는 데 중요합니다. 이러한 과부하는 둘 이상의 하이퍼 볼륨이 분리된 물리적 드라이브인 것으로 인식되지만 실제로는 이 둘 이상의 하이퍼 볼륨이 동일한 물리적 드라이브에 있을 때 발생하기 쉽습니다.

SQL Server I/O 작업은 개별 DA 컨트롤러에 균등히 분산되어야 합니다. 이는 DA 컨트롤러가 정의된 하드 드라이브 집합에 지정되기 때문입니다. 이 설명서의 앞에서 설명한 것과 같이 SCSI 컨트롤로의 병목 현상은 흔하지 않습니다. DA 컨트롤러에 I/O 병목 현상이 일어날 가능성은 없지만, DA 컨트롤러에 연결된 하드 드라이브 세트의 경우에는 그렇지 않습니다. DA 컨트롤러와 이에 연결된 디스크 드라이브의 경우, SQL Server 디스크 I/O 균형 조정은 기타 공급자 디스크 드라이브 및 컨트롤러의 경우와 마찬가지 방법으로 할 수 있습니다.

DA 채널이나 별도의 물리적 드라이브에서 I/O를 모니터할 때, 이 I/O 작업은 EMC 내장 캐시 아래에서 발생하고 성능 모니터는 이를 인식할 수 없으므로 EMC 기술 지원의 도움이 있어야 합니다. EMC 저장 장치에는 내부 모니터링 도구가 있으므로, EMC 기술 지원 엔지니어는 Symmetrix를 사용하여 I/O 통계를 모니터할 수 있습니다. 성능 모니터는 단지 SA 채널에서 오는 I/O에 따라서 EMC 저장 장치 사이에서 오고 가는 I/O를 인식할 수 있습니다. 이는 특정한 SA 채널에 디스크 I/O 요청 대기열이 있는지 확인하는 데에는 충분한 정보이지만 어떤 디스크가 디스크 대기열의 원인이 되는지는 알 수 없습니다. SA 채널에 대기열이 발생하는 경우, 이 문제를 일으키는 것이 디스크 드라이브일 가능성이 크므로 SA 채널이 병목 현상을 일으킬 가능성은 별로 없습니다. SA 채널과 DA 채널 + 드라이브 사이의 디스크 I/O 병목 현상을 구분하는 한 가지 방법은 호스트 서버에 SCSI 카드를 추가하고 이를 다른 SA 채널에 연결하는 것입니다. 두 SA 채널에 대한 I/O 볼륨이 변화하지 않았고 디스크 대기열은 여전히 발생하고 있다고 성능 모니터에 나타나는 경우, 이는 병목 현상을 발생시키는 것이 SA 채널이 아님을 의미하는 것입니다. I/O 병목 현상을 확인하는 또 다른 방법은, EMC 엔지니어로 하여금 EMC 모니터 도구를 사용하여 어느 드라이브 또는 DA 채널에 병목 현상이 발생하는지 분석하도록 하는 것입니다.

SQL Server 작업을 사용 가능한 디스크 드라이브에 균등하게 분할해야 합니다. I/O 작업이 지속적으로 많은 더 작은 데이터베이스를 사용하는 경우에는, EMC 기술 엔지니어가 정의할 하이퍼 볼륨 크기를 신중히 고려해야 합니다. SQL Server가 30GB 데이터베이스로 구성되는 경우를 가정해 봅시다. EMC 하드 드라이브는 최고 23GB의 용량을 제공할 수 있습니다. 따라서 전체 데이터베이스는 드라이브 두 개에 들어갈 수 있습니다. 관리와 비용 측면에서는 이렇게 하는 것이 좋아 보이지만 I/O 성능 면에서는 좋지 않습니다. EMC 저장 장치 하나는 100개 이상의 내부 드라이브와 함께 작업해야 할 수도 있습니다. SQL Server 드라이브를 단 두 개만 사용하면 I/O 병목 현상이 발생하는 원인이 될 것입니다. 각각 2GB 정도의 더 작은 하이퍼 볼륨을 정의하는 것이 좋을 수 있습니다. 이는 주어진 23GB 하드 드라이브에 약 12개의 하이퍼 볼륨을 연결할 수 있다는 의미입니다. 2GB 하이퍼 볼륨을 사용한다고 할 때, 데이터베이스를 저장하려면 15개의 하이퍼 볼륨이 필요합니다. 각 하이퍼 볼륨이 별도의 물리적 하드 드라이브에 연결되어 있는지 확인합니다. 물리적 드라이브 하나에 12개의 하이퍼 볼륨을 사용한 뒤 다른 물리적 드라이브에 연결된 하이퍼 볼륨 3개를 사용하면 안됩니다. 이는 물리적 드라이브 두 개를 동시에(드라이브 두 개에서 150회의 비순차 I/O/ 300회의 순차 I/O 작업) 사용하는 것과 같기 때문입니다. 그러나 각각 별도의 물리적 드라이브 하나에 연결된 하이퍼 볼륨 15개를 사용하면 SQL Server는 15개의 물리적 드라이브를 활용할 것입니다(드라이브 15개에서 1,125회의 비순차 I/O / 2,250회의 순차 I/O 작업).

또한 호스트 서버에서 여러 개의 SA 채널을 채택하여 I/O 작업을 컨트롤러에 분산하는 방법도 있습니다. 이는 PCI 버스를 하나 이상 지원하는 호스트 서버에 아주 좋습니다. 이 경우, 호스트 서버 PCI 버스 하나에 SA 채널 하나를 사용하여 SA 채널 뿐 아니라 PCI 버스에 I/O 작업을 분산하는 방법을 고려할 수 있습니다. EMC 저장 시스템에서 각 SA 채널은 특정 DA 채널에 연결되어 있으며, 따라서 특정한 물리적 하드 드라이브 세트에 연결되어 있습니다. SA 채널은 EMC 내부 캐시에 데이터를 쓰고 읽기 때문에 SA 채널에 I/O 병목 현상이 일어날 가능성은 없습니다. SCSI 컨트롤러 병목 현상이 흔하지 않다는 점에서 볼 때, SA 채널을 얼마나 많이 사용해야 할지 걱정하는 것보다는 물리적 하드 드라이브 전체에서 SQL Server 작업의 균형을 조정하는 데 시간을 투자하는 것이 좋을 것입니다.

추가 정보

• Microsoft SQL Server 온라인 설명서는 SQL Server 구조와 데이터베이스 조정에 대한 정보는 물론 명령 구문과 관리에 관한 모든 문서에 대한 정보를 제공합니다. SQL Server 온라인 설명서는 모든 SQL Server 클라이언트 또는 서버를 설치할 때 SQL Server 설치 미디어에서 설치할 수 있습니다. SQL Server에서 많은 작업을 하는 사람이 사용하는 모든 컴퓨터에 SQL Server 온라인 설명서를 설치하여 쉽게 찾아볼 수 있도록 하는 것이 좋습니다.
• 자세한 내용을 보려면 Microsoft TechNet을 방문하십시오.
• SQL Server 7.0에 대한 다른 백서들을 포함하여 Microsoft SQL Server에 대한 최신 정보는 Microsoft SQL Server 웹 사이트(http://www.microsoft.com/korea/sql/)를 참조하십시오.
• Compaq이 업데이트한 RAID 백서에는 50페이지에 걸쳐 데이터베이스 서버 성능에 대한 유용한 정보가 들어 있습니다. 이 백서에서 3페이지에 걸친 Microsoft SQL Server 정보는 버전 6.5에 대한 것이며 SQL Server 7.0에는 적용되지 않습니다. 이 백서의 제목은 "Configuring Compaq RAID Technology for Database Servers" 이며, 위치는 http://www.compaq.com/support/techpubs/whitepapers/ecg0110598.html

  

  입니다.
• Compaq의 Windows NT 통합 팀이 작성한 30페이지짜리 백서의 제목은 "Disk Subsystem Performance and Scalability"이며, 위치는 http://www.compaq.com/support/techpubs/whitepapers/ecg0250997.html

  

  입니다. 이 백서에서는 Compaq 하드 드라이브의 하드웨어 성능 특성과 물리적 드라이브 동작에 대해 자세히 설명하고 있습니다. 이 백서에 포함된 정보는 Compaq과 기타 공급업체가 제공하는 SCSI 하드 드라이브에 적용할 수 있습니다.
• Celko, Joe. SQL for Smarties. Morgan Kaufmann Publishers, ISBN 1-55860-323-9.

  이 책에는 매우 유용한 정보가 들어 있습니다. 계층 데이터를 표현하고 쿼리하는 등의 일반적인 문제에 대한 솔루션이 들어 있습니다. 28장은 SQL 쿼리 최적화에 대한 것입니다.

© 1998 Microsoft Corporation.All rights reserved.

이 문서에 포함된 정보는 발행일 현재 논의중인 문제에 대한 Microsoft Corporation의 현재 입장을 대변하는 것입니다. Microsoft는 변화하는 시장 조건에 부응해야 하므로, 이 문서는 Microsoft의 공식적인 약속으로 해석되어서는 안되며 Microsoft는 게시일 이후 제시되는 어떠한 정보에 대해서도 정확성을 보장하지 않습니다.

이 백서는 오직 정보를 제공하기 위한 것입니다. MICROSOFT는 이 설명서에서 어떠한 명시적이거나 묵시적인 보증도 하지 않습니다.

BackOffice 로고, Microsoft, Windows, SQL Server 및 Windows NT 는 Microsoft Corporation의 등록 상표입니다.

여기에 인용된 실제 회사와 제품 이름은 해당 소유자의 상표일 수 있습니다.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
 

최종 수정일 : 2000.4.26
ⓒ2004 Microsoft Corporation. All rights reserved. 사용권에 대한 고지사항 | 개인정보보호정책