모든 데이터베이스 관리자에 게는 SQL Server 사용 하 여 디스크 드라이브 캐시 사용에 대 한 정보

요약

데이터베이스 시스템은 우선적인 정확 하 게 저장 및 예기치 않은 시스템 오류가 발생 하는 경우에 데이터를 검색 합니다.

시스템은 원자성 및 현재 실행, 다중 트랜잭션, 다양 한 실패 요소 동시 트랜잭션의 지 속성이 보장 해야 합니다. 이 종종 ACID (원자성, 일관성, 격리성 및 영속성) 속성 이라고 합니다.

이 문서에서는 디스크 드라이브의 의미를 캐시 합니다. 캐싱에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참고 하는 것이 좋습니다 하 고 디스크 드라이브:

86903 SQL Server 및 디스크 컨트롤러 캐시

확장 데이터 안정성을 SQL Server 7.0 및 SQL Server 2000 로깅 및 데이터 저장소 알고리즘 230785

다음 문서는 또한 것이 좋습니다.

• SQL Server 2000 I/O 기본 사항:
  http://technet.microsoft.com/en-us/library/cc966500.aspx

• SQL Server I/O 기본 사항 2 장.
  http://www.microsoft.com/technet/prodtechnol/sql/2005/iobasics.mspx

참고: 이러한 두 문서는 SQL Server 현재 지원 되는 모든 버전에 적용 됩니다.

자세한 내용

Microsoft SQL Server 시장에서 많은 주요 데이터베이스 제품은 오늘날 미리 쓰기 로깅 (WAL) 프로토콜을 사용합니다.

미리 쓰기 로깅 (WAL) 프로토콜
프로토콜 이란 WAL을 잘 설명 하는 훌륭한 방법입니다. 특정 하 고 정의 된 집합이 데이터를 보냈음을 확인 하는 데 필요한 단계를 구현 되어 올바르게 저장 및 교환 오류가 발생할 경우 알려진 상태로 복구할 수 있습니다. 따라서 일관 되 고 보호 된 방식으로 데이터를 교환 하는 정의 된 프로토콜을 포함 하는 네트워크와 마찬가지로 WAL에서는 데이터를 보호 하는 프로토콜 설명 너무.SQL Server 모든 버전은 Win32 CreateFile 함수를 사용 하 여 로그 및 데이터 파일을 엽니다. SQL Server 열 때 FILE_FLAG_WRITE_THROUGH 옵션을 포함 하는 dwFlagsAndAttributes 멤버.

FILE_FLAG_WRITE_THROUGH
이 옵션에는 시스템이 중간 캐시를 통해 쓰고 디스크로 직접 이동 하도록 지시 합니다. 시스템은 쓰기 작업을 계속 캐시할 수 있지만 천천히 플러시할 수 없습니다.

FILE_FLAG_WRITE_THROUGH 옵션 사용 하면 때에 쓰기 작업이 반환 완료 데이터가 제대로 안정적인 저장소에 저장 합니다. 이 데이터는 먼저 로그 쓰기 (WAL) 프로토콜 사양으로 맞춥니다.많은 디스크 드라이브 (SATA, ATA, SCSI 및 IDE를 기반으로)에 512 KB, 1 MB, 및 더 큰 온보드 캐시 포함 되어 있습니다. 드라이브 캐시는 보통 배터리 지원 솔루션이아닌 축전기를 사용 합니다. 이러한 캐싱 메커니즘은 전원 전반에 대해 쓰기 주기 나 이와 유사한 실패 요소 보장할 수 없습니다. 들만 섹터 쓰기 작업의 완료를 보장합니다. 드라이브가 크기가 계속, 캐시 점점 커지게 되 고 오류 발생 시 더 많은 양의 데이터를 노출할 수 있습니다.


향상 된 캐싱 컨트롤러 시스템 디스크 캐시를 사용 하지 않도록 설정 및 배터리 지원 솔루션을 캐싱 기능을 제공 합니다. 이러한 캐시 며칠 동안 캐시에 데이터를 보관할 수 있으며 다른 컴퓨터에 캐싱 카드를 사용할 수도 있습니다. 전원이 제대로 복원 되 면 다른 추가적인 데이터 액세스가 허용 되기 전에 쓰여지지 않은 데이터는 완전히 플러시됩니다. 및 최적의 성능으로 설정 되도록 쓰기 캐시 읽기 비율을 허용 하는 대부분의 일부는 대용량 메모리 저장 영역이 들어 있습니다. 실제로 시장의 특정 분야에서 일부 하드웨어 공급 업체는 첨단 배터리 지원 디스크 캐싱 시스템을 기가바이트의 캐시를 제공 합니다. 이러한 데이터베이스의 성능을 크게 향상 시킬 수 있습니다.

캐시를 사용 하지 않고 수행 하는 I/O 전송 훨씬 길어질 수 있습니다 인해 하드 드라이브 회전율 드라이브 헤드 및 다른 제한 인자로 이동 하는 데 필요한 기계의 시간. 캐싱 컨트롤러를 제공 하는 시스템에서 SQL Server 설치 대상입니다. 이러한 컨트롤러 디스크 캐시를 사용 하지 않도록 설정 하 고 SQL Server I/O 요구 사항을 만족 시키기 위해 안정적인 미디어 캐시를 제공 합니다. 이러한 방지 seek 디스크 캐싱 컨트롤러의 다양 한 최적화 기능을 사용 하 여 시간을 기록 하는 관련 된 성능 문제.

다양 한 하위 시스템 구현이 있습니다. RAID 및 SAN 하위 시스템 구현 이러한 유형의 두 가지 예는. 이러한 시스템 기반 SCSI 드라이브를 사용 하 여 일반적으로 빌드됩니다. 이 오류의 원인은 여러 가지가 있습니다. 다음 섹션에는 일반적으로 높은 수준의 드라이브 고려 사항을 설명 합니다.

SCSI 드라이브:

• 일반적으로 대량의 용도로 제조 된.

• 일반적으로 대상으로 다중 사용자, 서버 기반 구현 합니다.

• 일반적으로 실패율을 그 동안 다른 구현 보다 더 나은.

• 실패 가능성을 예측 하는 데 도움이 복잡 한 추론을 포함 합니다.

IDE, ATA, SATA 등 다른 드라이브 구현:

• 일반적으로 가볍고 보통 의무 사용에 대 한 제조.

• 일반적으로 대상으로 단일 사용자 기반 응용 프로그램입니다.

• 일부 최신 구현 실패 가능성을 예측 하는 데 도움이 복잡 한 추론을 포함 합니다.

SCSI가 아닌, 데스크톱 기반 컨트롤러 많은 주요 프로세서 (CPU) 대역폭을 필요로 하 고 자주 하나의 활성 명령에 의해 제한 됩니다. 등 비 SCSI 드라이브는 불량 블록을 조정할 때 드라이브는 호스트 명령을 때까지 대기 해야 합니다. ATA 버스는 또 다른 예를 제공합니다. ATA 버스 2 장치를 지원 하지만 하나의 명령만 사용할 수 있습니다. 이런 한 드라이브가 유휴 드라이브 다른 보류 중인 명령이 서비스 하는 동안 있습니다. 데스크톱 기술 기반의 raid 시스템 모두 이러한 현상이 발생할 수 있습니다 및 느린 응답자의 영향을 크게 받을 수 있습니다. 이러한 시스템에서 고급 디자인을 사용 하지 않으면 성능을 효율적으로 SCSI 기반 시스템의 성능이 되지 않습니다.

경우에는 드라이브 데스크톱 기반 또는 배열에 적절 한 저가형 솔루션입니다. 예를 들어, 읽기 전용 보고 데이터베이스를 설정 하면 해야 하지 발생 하면 많은 OLTP 데이터베이스의 성능 요소 디스크 캐싱을 비활성화.

드라이브 크기가 계속 증가 합니다. 낮은 비용, 높은 용량의 드라이브를 매우 매력적 수 있습니다. 하지만 SQL Server 및 비즈니스 응답 시간 요구 사항에 대 한 드라이브를 구성할 때 신중 하 게 다음과 같은 문제를 고려해 야 합니다.

• 액세스 경로 설계

• 디스크 캐시를 사용 하지 않도록 설정 하는 요구 사항

다음 표에서 높은 수준의 설명을 제공합니다. 설명 정보가 일반적인 제조 구성을 기반으로 합니다.

직렬 연결 SCSI (SAS) 고급 큐 최대 256 레벨까지 포함 되어 있습니다. SAS에는 순서가 큐 및 큐의 헤드와 같은 기능이 포함 되어 있습니다. SAS 후면판은 하 수 SAS 및 SATA 사용 드라이브 같은 시스템 내에서 방법으로 설계 되었습니다. SAS 디자인의 장점에는 분명 합니다.

SQL Server 설치 디스크 캐시를 사용 하지 않도록 설정 하 고 안정적인 I/O 캐시를 제공 하는 컨트롤러의 기능에 따라 다릅니다. 다양 한 디스크 쓰기 데이터 순서가 아닌 경우 SQL Server는 오히려 장애가으로 안정적 올바른 미디어 캐싱 기능을 제공 하는 컨트롤러 미러링과 같은 고급 데이터 보안 기술로 컨트롤러 설계의 복잡성이 증가합니다.

데이터를 완벽 하 게 보호 하려면 모든 데이터의 캐싱이 올바로 처리를 해야 합니다. 즉 대부분의 경우에서 디스크 드라이브의 쓰기 캐싱을 해제 해야 합니다.

참고 모든 대체 캐싱 메커니즘이 많은 형태의 장애를 올바로 처리할 수 있는지 확인 합니다.

Microsoft는 SQLIOSim 유틸리티를 사용 하 여 여러 개의 SCSI 및 IDE 드라이브에 대해 테스트를 수행 했습니다. 이 유틸리티는 매우 비동기적인 읽기/쓰기 활동을 시뮬레이트된 데이터 장치 및 로그 장치에 시뮬레이션합니다. 테스트 성능 통계에는 평균 쓰기 작업은 50-70 초를 사용할 수 없는 쓰기 캐시 드라이브를 갖고 RPM 범위가 5200-7200 보여 줍니다.

자세한 내용과 SQLIOSim에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조.

231619 디스크 하위 시스템에서 SQL Server 작업을 시뮬레이션 하는 SQLIOSim 유틸리티를 사용 하는 방법많은 PC 제조업체 (예: Compaq, Dell, 게이트웨이 또는 HP) 쓰기 캐시 비활성화를 사용 하 여 드라이브를 주문 합니다. 그러나이 아닐 수도 있다는 항상 경우 항상 있으므로 테스트에서는 테스트 완전히.

참고: 디스크 드라이브의 캐싱 상태에 대 한 어떤 질문이 있으면 제조업체에 문의 하 고 쓰기 캐싱 작업을 사용 하지 않으려면 해당 유틸리티 또는 점퍼 설정을 합니다.

SQL Server 시스템이 SQL Server I/O 안정성 프로그램 요구 사항에 설명 된 대로 설명한 것 처럼 '안정적인 미디어에 배달 보장된'을 지원 하기 위해 필요 합니다. 는 SQL Server 데이터베이스 엔진에 대 한 입력 및 출력 요구 사항에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서 번호를 클릭 합니다.:

967576 Microsoft SQL Server 데이터베이스 엔진이 입력/출력 요구 사항