적용 대상:
SQL ServerAzure SQL Managed InstanceAzure Virtual Machines의 SQL Server
SQL Server 데이터베이스의 주 목적은 데이터 저장 및 검색이므로 데이터베이스 엔진의 핵심 특성은 집중형 디스크 I/O(입출력)입니다. 디스크 I/O 작업은 리소스를 많이 소모하고 완료하는 데 상대적으로 시간이 오래 걸릴 수 있으므로, SQL Server에서는 I/O의 효율성을 높이는 데 중점을 둡니다.
SQL Server 스토리지 하위 시스템은 기계식 드라이브 및 반도체 스토리지를 비롯한 여러 폼 팩터에서 사용할 수 있습니다. 이 문서에서는 드라이브 캐싱 원칙을 사용하여 데이터베이스 엔진 I/O를 개선하는 방법을 자세히 설명합니다.
SQL Server를 사용하려면 시스템이 SQL Server I/O 안정성 프로그램 요구 사항에 설명된 대로 안정적인 미디어로의 전송 보장을 지원해야 합니다.
이 요구 사항은 다음 조건을 포함하지만 이에 국한되지 않습니다.
- Windows 하드웨어 호환성 프로그램
- 쓰기 순서 지정
- 캐싱 안정성
- 데이터 다시 쓰기 없음
이러한 요구 사항을 충족하는 시스템은 SQL Server 데이터베이스 스토리지를 지원합니다. SQL Server 스토리지 솔루션 프로그램에 시스템을 나열할 필요는 없지만 요구 사항이 충족되도록 보장해야 합니다.
디스크 I/O
버퍼 관리자는 데이터베이스에 대한 읽기 및 쓰기만 수행합니다. 열기, 닫기, 확장 및 축소와 같은 다른 파일 및 데이터베이스 작업은 데이터베이스 관리자 및 파일 관리자 구성 요소에 의해 처리됩니다.
버퍼 관리자의 디스크 I/O 작업에는 다음과 같은 특징이 있습니다.
일반적으로 I/O가 비동기적으로 수행되므로 I/O 작업이 백그라운드에서 발생하는 동안 호출 스레드가 처리를 계속할 수 있습니다. 잘못 정렬된 로그 I/O와 같은 일부 상황에서는 동기 I/O가 발생할 수 있습니다.
선호도 I/O 옵션을 사용하지 않는 한, 모든 I/O는 호출 스레드에서 실행됩니다. affinity I/O 마스크 옵션은 SQL Server 디스크 I/O를 지정된 CPU 하위 집합에 바인딩합니다. 고성능 SQL Server OLTP(온라인 트랜잭션 처리) 환경에서 이러한 확장을 통해 I/O를 실행하는 SQL Server 스레드의 성능을 향상시킬 수 있습니다.
다중 페이지 I/O는 분산 수집 I/O로 수행되므로 데이터를 인접하지 않은 메모리 영역으로 또는 이러한 영역 밖으로 전송할 수 있습니다. SQL Server 여러 물리적 I/O 요청을 방지하면서 버퍼 캐시를 빠르게 채우거나 플러시할 수 있습니다.
긴 I/O 요청
버퍼 관리자는 15초 이상 미해결된 모든 I/O 요청을 보고합니다. 이 프로세스를 통해 시스템 관리자는 SQL Server 문제와 I/O 하위 시스템 문제를 구분할 수 있습니다. MSSQLSERVER_833 오류 메시지가 보고되고 다음과 같이 SQL Server 오류 로그에 표시됩니다.
SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.
긴 I/O는 읽기 또는 쓰기 작업일 수 있습니다. 메시지는 현재 어떤 것을 나타내지 않습니다. 긴 I/O 메시지는 오류가 아니라 경고입니다. 이는 SQL Server의 문제가 아니라, 기본 I/O 시스템에 문제가 있음을 나타냅니다. 이 메시지는 시스템 관리자가 SQL Server 응답 시간 저하의 원인을 더 빠르게 찾고 SQL Server의 제어를 벗어난 문제를 구분하는 데 도움이 됩니다. 따라서 아무 작업도 수행할 필요가 없지만, 시스템 관리자는 I/O 요청이 너무 오래 걸린 이유와 시간이 타당한지 여부를 조사해야 합니다.
긴 I/O 요청의 원인
긴 I/O 메시지는 I/O가 영구적으로 차단되고 완료되지 않음(손실된 I/O라고 함) 또는 아직 완료되지 않았음을 나타낼 수 있습니다. 손실된 I/O가 래치 시간 제한으로 이어지는 경우가 많지만 메시지에서 시나리오를 알 수 없습니다.
긴 I/O는 디스크 하위 시스템에 비해 너무 많은 SQL Server 워크로드를 나타내는 경우가 많습니다. 다음과 같은 경우에 디스크 하위 시스템이 부족할 수 있습니다.
- SQL Server 워크로드가 많은 동안 오류 로그에 여러 긴 I/O 메시지가 표시됩니다.
- 성능 모니터링 카운터에 긴 디스크 지연 시간, 긴 디스크 큐 또는 디스크 유휴 시간이 표시됩니다.
I/O 경로의 구성 요소(예: 드라이버, 컨트롤러 또는 펌웨어)는 최신 요청을 서비스하기 위해 이전 I/O 요청의 서비스를 지속적으로 연기하여 긴 I/O를 발생시킬 수 있습니다. 이 문제는 iSCSI 및 파이버 채널 네트워크와 같은 상호 연결된 환경에서 발생할 수 있습니다(잘못된 구성 또는 경로 오류로 인해). 성능 모니터 도구는 대부분의 I/O가 즉시 서비스되기 때문에 이 문제를 확인하기 어렵게 만들 수 있습니다. 백업 및 복원, 테이블 검색, 정렬, 인덱스 만들기, 대량 로드 및 파일 제로와 같은 대량의 순차 I/O를 수행하는 워크로드는 긴 I/O 요청을 악화시킬 수 있습니다.
위에 나열된 어떤 조건과도 관련되지 않은 격리된 긴 I/O는 하드웨어 또는 드라이버 문제로 인해 발생할 수 있습니다. 시스템 이벤트 로그에 문제의 진단에 도움이 되는 관련 이벤트가 포함되어 있을 수 있습니다.
비효율적인 쿼리 또는 필터 드라이버로 인한 I/O 성능 문제
느린 I/O는 효율적으로 작성되지 않거나 인덱스 및 통계로 제대로 조정되지 않은 쿼리로 인해 발생할 수 있습니다. I/O 대기 시간이 발생하는 또 다른 일반적인 요인은 데이터베이스 파일을 검사하는 바이러스 백신 또는 기타 보안 프로그램의 존재입니다. 이 검사 소프트웨어는 네트워크 계층으로 확장되어 네트워크 대기 시간을 늘리고 결과적으로 데이터베이스 대기 시간에 간접적으로 영향을 미칠 수 있습니다. 약 15초 I/O에 대해 설명된 시나리오는 하드웨어 구성 요소에서 더 일반적이지만, 최적이 아닌 쿼리 또는 잘못 구성된 바이러스 백신 프로그램에서 더 짧은 I/O 지연이 더 자주 관찰됩니다.
이러한 문제를 해결하는 방법에 대한 자세한 내용은 I/O 문제로 인한 느린 SQL Server 성능 문제 해결을 참조하세요.
SQL Server에서 바이러스 백신 보호를 구성하는 방법에 대한 자세한 내용은 SQL Server에서 작동하도록 바이러스 백신 소프트웨어 구성을 참조하세요.
스토리지 컨트롤러의 쓰기 캐싱
캐시를 사용하지 않는 I/O 전송은 하드 드라이브 스핀 속도, 드라이브 헤드를 이동하는 데 필요한 기계적 시간 및 기타 제한 요인으로 인해 기계 드라이브에서 훨씬 더 오래 걸릴 수 있습니다. SQL Server 설치는 캐싱 컨트롤러를 제공하는 시스템을 대상으로 합니다. 이러한 컨트롤러는 디스크 내 캐시를 비활성화하고 SQL Server I/O 요구 사항을 충족하기 위해 안정적인 미디어 캐시를 제공합니다. 캐싱 컨트롤러의 다양한 최적화를 사용하여 스토리지 검색 및 쓰기 시간과 관련된 성능 문제를 방지합니다.
참고
일부 스토리지 공급업체는 PMEM(영구 메모리)을 캐시가 아닌 스토리지로 사용하여 전반적인 성능을 높일 수 있습니다. 자세한 내용은 SQL Server on Windows의 PMEM(영구 메모리) 구성 및 SQL Server on Linux의 PMEM(영구 메모리) 구성을 참조하세요.
쓰기 캐싱(쓰기 저장 캐싱이라고도 함) 스토리지 컨트롤러를 사용하면 SQL Server 성능이 향상될 수 있습니다. 쓰기 캐싱 컨트롤러 및 스토리지 하위 시스템은 DBMS(데이터 중요 트랜잭션 데이터베이스 관리 시스템) 환경에서 사용하도록 설계된 경우 SQL Server에 안전합니다. 이러한 설계 기능은 시스템 오류가 발생하는 경우 캐시된 데이터를 유지해야 합니다. 전원과 관련이 없는 오류 모드가 발생할 수 있으므로 이 보호를 위해 외부 UPS(무정전 전원 공급 장치)를 사용하는 것은 일반적으로 충분하지 않습니다.
Important
SQL Server는 트랜잭션 무결성과 복구를 위해 미디어의 안정성을 보장하는 전송에 의존합니다. 오류 간에 데이터를 보존하지 않는 안전하지 않은 캐싱은 트랜잭션 로그 쓰기의 일관성에 관계없이 데이터베이스를 손상할 수 있습니다. 항상 쓰기 캐싱 메커니즘이 완전한 내구성 보장을 제공하는지 확인합니다.
캐싱 컨트롤러 및 스토리지 하위 시스템은 SQL Server에서 사용하기에 안전할 수 있습니다. 이러한 컨트롤러를 통합하는 대부분의 새로운 용도로 빌드된 서버 플랫폼은 안전합니다. 그러나 하드웨어 공급업체에 문의하여 스토리지 하위 시스템이 RDBMS(데이터 중요 트랜잭션 관계형 데이터베이스 관리 시스템) 환경에서 사용하도록 테스트 및 승인되었는지 확인해야 합니다.
캐시 하위 시스템 안전 지침
쓰기 저장 캐싱 컨트롤러는 특정 안전 요구 사항을 충족하는 경우 성능을 향상시킬 수 있습니다.
- 배터리 지원 캐시 또는 NVDIMM 또는 슈퍼 커패시터 지원 플래시와 같은 비휘발성 메모리를 포함합니다.
- 데이터 중요 OLTP 데이터베이스 환경에 대한 공급업체의 인증을 받습니다.
- 전원 손실뿐만 아니라 모든 오류 조건을 포괄하는 보호를 제공합니다.
Important
외부 UPS만 사용하지 마세요. 전원과 관련이 없는 오류(예: 펌웨어 버그 또는 하드웨어 오류)는 여전히 캐시 손실로 이어질 수 있습니다.
미리 쓰기 로깅
SQL Server 데이터 수정 문은 논리적 페이지 쓰기를 생성합니다. 이 쓰기 스트림은 로그와 데이터베이스 자체의 두 위치로 가는 것으로 간주할 수 있습니다. 성능상의 이유로 SQL Server는 자체 캐시 버퍼 시스템을 통해 데이터베이스에 쓰기를 지연합니다. 시스템은 COMMIT 시간이 될 때까지 로그에 쓰기를 일시적으로 연기합니다. 데이터 쓰기와 동일한 방식으로 이러한 쓰기를 캐시하지 않습니다. 지정된 페이지에 대한 로그 쓰기는 항상 페이지의 데이터가 쓰기 전에 제공되므로 로그를 WAL( 미리 쓰기 로그 )이라고도 합니다.
SQL Server WAL 프로토콜을 통해 트랜잭션의
WAL(미리 쓰기 로깅) 프로토콜
프로토콜이라는 용어는 WAL을 설명하는 적절한 용어입니다. SQL Server에서 사용하는 WAL을 ARIES(복구 및 격리 악용 의미 체계 알고리즘)라고 합니다. 자세한 내용은 가속 데이터베이스 복구 관리를 참조하세요.
데이터가 제대로 저장 및 교환되고 오류 발생 시에 알려진 상태로 복구할 수 있도록 하는 데 필요한 특정한 정의된 구현 단계의 세트입니다. 일관되고 보호된 방식으로 데이터를 교환하는 정의된 프로토콜이 네트워크에 포함되어 있는 것처럼 WAL도 데이터를 보호하기 위한 프로토콜을 가리킵니다. 모든 버전의 SQL Server는 Win32 CreateFile 함수를 사용하여 로그 및 데이터 파일을 엽니다.
dwFlagsAndAttributes 멤버는 SQL Server에서 열 때 FILE_FLAG_WRITE_THROUGH 옵션을 포함합니다.
FILE_FLAG_WRITE_THROUGH
SQL Server는 FILE_FLAG_WRITE_THROUGH 플래그를 사용하여 데이터베이스 파일을 만듭니다. 이 옵션은 중간 캐시를 통해 쓰고 스토리지로 직접 이동하도록 시스템에 지시합니다. 시스템은 여전히 쓰기 작업을 캐시할 수 있지만, 이를 지연하여 플러시할 수는 없습니다. 자세한 내용은 CreateFileA를 참조하세요.
이 FILE_FLAG_WRITE_THROUGH 옵션은 쓰기 작업이 성공적인 완료를 반환할 때 데이터가 안정적인 스토리지에 올바르게 저장되도록 합니다. 이 기능은 WAL(Write-Ahead 로깅) 프로토콜 사양과 일치하여 데이터 무결성을 보장합니다. 많은 스토리지 디바이스(NVMe, PCIe, SATA, ATA, SCSI 및 IDE 기반)는 512KB, 1MB 및 그 이상의 온보드 캐시를 포함합니다. 스토리지 캐시는 일반적으로 배터리 지원 솔루션이 아닌 커패시터를 사용합니다. 이러한 캐싱 메커니즘은 전원 주기 또는 유사한 고장 지점에서의 쓰기를 보장할 수 없습니다. 섹터 쓰기 작업의 완료만 보장합니다. 스토리지 디바이스의 크기가 계속 커지면 캐시가 커지고 실패 시 더 많은 양의 데이터가 노출될 수 있습니다.
Linux 배포의 FUA 지원과 SQL Server에 미치는 영향에 대한 자세한 내용은 SQL Server On Linux: FUA(강제 단위 액세스) 내부 항목을 참조하세요.
트랜잭션 무결성 및 SQL Server 복구
트랜잭션 무결성은 관계형 데이터베이스 시스템의 기본 개념 중 하나입니다. 트랜잭션은 완전히 적용되거나 완전히 롤백되는 원자성 작업 단위입니다. SQL Server 미리 쓰기 트랜잭션 로그는 트랜잭션 무결성을 구현하는 데 중요한 역할을 합니다.
또한 관계형 데이터베이스 시스템은 트랜잭션 무결성과 밀접하게 관련된 개념인 계획되지 않은 시스템 오류로부터의 복구를 처리해야 합니다. 몇 가지 비이정적인 실제 효과로 인해 이 오류가 발생할 수 있습니다. 많은 데이터베이스 관리 시스템에서 시스템 오류로 인해 사람이 지정한 수동 복구 프로세스가 길어질 수 있습니다.
반면 SQL Server 복구 메커니즘은 자동으로 이루어지며 사람의 개입 없이 작동합니다. 예를 들어 중요 업무용 프로덕션 애플리케이션을 지원하는 SQL Server에서 순간적인 전력 변동으로 인해 시스템 오류가 발생할 수 있습니다. 전원이 복원되면 서버 하드웨어가 다시 시작되고 네트워킹 소프트웨어가 로드되고 초기화되고 SQL Server가 다시 시작됩니다. SQL Server가 초기화되면 트랜잭션 로그의 데이터를 기반으로 복구 프로세스가 자동으로 실행됩니다. 이 전체 과정은 인간의 개입 없이 발생합니다. 클라이언트 워크스테이션이 다시 시작되면 사용자는 입력한 마지막 트랜잭션까지 모든 데이터가 있는 것을 찾습니다.
자동 복구 및 트랜잭션 무결성은 함께 작동하여 실패 후 작업을 복원하는 데 필요한 시간과 노력을 줄입니다. 쓰기 캐싱 컨트롤러가 데이터 중요 트랜잭션 DBMS 환경에서 사용하도록 제대로 설계되지 않은 경우 SQL Server의 복구 기능이 손상되어 데이터베이스가 손상될 수 있습니다. 이 문제는 컨트롤러가 SQL Server 트랜잭션 로그 쓰기를 가로채 컨트롤러 보드의 하드웨어 캐시에 버퍼링하지만 시스템 오류 발생 시 이러한 기록된 페이지를 유지하지 않는 경우에 발생할 수 있습니다.
Warning
시스템 재설정으로 인해 캐시된 쓰기가 삭제되면 UPS가 있는 경우에도 데이터베이스 손상이 발생할 수 있습니다. 데이터 지속성을 보장하기 위해 항상 쓰기 캐시가 배터리 또는 동등한 기술로 지원되는지 확인합니다.
디스크 내 쓰기 캐싱 위험
대부분의 스토리지 디바이스 캐싱 컨트롤러는 쓰기 캐싱을 수행합니다. 쓰기 캐싱 함수를 항상 사용하지 않도록 설정할 수는 없습니다.
서버가 UPS를 사용하는 경우에도 디바이스는 캐시된 쓰기의 보안을 보장하지 않습니다. UPS에서 해결되지 않는 많은 유형의 시스템 오류가 발생할 수 있습니다. 예를 들어 메모리 패리티 오류, OS(운영 체제) 트랩 또는 시스템 재설정을 유발하는 하드웨어 결함으로 인해 제어되지 않는 시스템 중단이 발생할 수 있습니다. 하드웨어 쓰기 캐시의 메모리 오류로 인해 중요한 로그 정보가 소실될 수도 있습니다.
쓰기 캐싱 컨트롤러와 관련한 또 다른 문제는 시스템 종료 시 발생할 수 있습니다. 구성을 변경하는 동안 OS를 순환 하거나 시스템을 다시 시작하는 것은 드문 일이 아닙니다. 신중한 운영자가 OS 권장 사항에 따라 시스템을 다시 시작하기 전에 모든 스토리지 작업이 중단될 때까지 기다리더라도 캐시된 쓰기는 컨트롤러에 계속 있을 수 있습니다.
Ctrl
+
Alt
+
Del 키 조합을 누르거나 하드웨어 재설정 단추를 누르면 캐시된 쓰기가 삭제되어 데이터베이스가 손상될 수 있습니다.
데이터베이스 서버에서 안전하게 사용할 수 있도록 더티 캐시 데이터를 삭제하는 모든 가능한 원인을 고려하는 하드웨어 쓰기 캐시를 디자인할 수 있습니다. 이러한 디자인 기능 중 일부에는 캐싱 컨트롤러의 제어되지 않는 재설정, 온보드 배터리 백업, 미러 또는 ECC(오류 검사 및 수정) 메모리를 방지하기 위해 RST(재설정) 버스 신호를 가로채는 것이 포함됩니다. 이러한 기능과 데이터 손실을 방지하는 데 필요한 다른 기능이 쓰기 캐시에 포함되어 있는지 하드웨어 공급업체에 문의하세요.
SQL Server에 스토리지 캐시 사용
데이터베이스 시스템은 예기치 않은 시스템 오류 발생 시에도 데이터의 정확한 스토리지 및 검색을 주로 담당합니다.
시스템은 현재 실행, 여러 트랜잭션 및 다양한 오류 지점을 고려하면서 트랜잭션의 원자성 및 내구성을 보장해야 합니다. 이 속성을 ACID(원자성, 일관성, 격리 및 내구성) 속성이라고도 합니다.
이 섹션에서는 스토리지 캐시의 영향을 알아봅니다. 캐싱 및 대체 실패 모드 토론에 대한 자세한 내용은 다음을 참조하세요.
또한 다음과 같은 보관된 콘텐츠를 검토합니다.
이 두 문서의 개념은 현재 버전의 SQL Server에 광범위하게 적용됩니다.
배터리 기반 캐싱 솔루션
향상된 캐싱 컨트롤러 시스템은 디스크 캐시를 비활성화하고 유용한 배터리 지원 캐싱 솔루션을 제공합니다. 이러한 캐시는 며칠 동안 캐시의 데이터를 유지 관리할 수 있으며 캐싱 카드를 두 번째 컴퓨터에 배치할 수도 있습니다. 전원이 제대로 복구되면 모든 미기록 데이터가 완벽히 플러시된 후에야 추가 데이터 액세스가 허용됩니다. 이러한 시스템의 대부분은 최적의 성능을 위해 읽기 및 쓰기 캐시의 비율을 설정할 수 있습니다. 일부 시스템에는 큰 메모리 스토리지 영역이 포함되어 있습니다. 일부 하드웨어 공급업체의 경우 여러 기가바이트 캐시가 있는 고성능 배터리 지원 드라이브 캐싱 시스템을 제공합니다. 이러한 시스템은 데이터베이스 성능을 크게 향상시킬 수 있습니다. 배터리 지원 캐싱 솔루션은 SQL Server에서 기대하는 데이터의 내구성과 일관성을 제공합니다.
스토리지 하위 시스템 구현
스토리지 하위 시스템은 여러 형식으로 존재합니다. 두 가지 일반적인 예로 RAID(독립 디스크의 중복 배열) 및 SAN(스토리지 영역 네트워크)이 있습니다. 이러한 시스템은 일반적으로 SCSI 기반 드라이브를 사용합니다. 다음 섹션에서는 고수준 저장 고려 사항에 대해 설명합니다.
SCSI, SAS 및 NVMe
SCSI, SAS 및 NVMe 스토리지 디바이스:
- 일반적으로 중장비 사용을 위해 설계되었습니다.
- 일반적으로 다중 사용자 서버 기반 구현 환경을 대상으로 합니다.
- 일반적으로 다른 구현보다 실패율 평균 시간이 더 낫습니다.
- 임박한 오류를 예측하는 데 도움이 되는 정교한 추론을 포함합니다.
참고
SQL Server는 Windows 하드웨어 호환성 프로그램의 요구 사항을 충족하는 iSCSI(Internet Small Computer System Interface) 기술 구성 요소를 지원합니다. SQL Server는 iSCSI와 직접 상호 작용하지 않지만 Windows에서 iSCSI 스토리지를 표준 드라이브로 제공하므로 원활하게 작동합니다. 그런 다음 SQL Server는 IP 네트워크를 통해 원격 블록 수준 스토리지에서 읽고 쓸 수 있습니다. iSCSI는 네트워크에 따라 달라지므로 지연 또는 병목 현상이 발생할 수 있습니다. 서버의 캐싱 성능이 최적이고 대기 시간이 최소화되었는지 확인합니다. 자세한 내용은 iSCSI 대상 서버 확장성 제한을 참조하세요.
비SCSI
IDE, ATA 및 SATA와 같은 기타 드라이브 구현 유형:
- 일반적으로 경량에서 중형으로 사용하도록 설계되었습니다.
- 일반적으로 단일 사용자 애플리케이션을 대상으로 합니다.
SCSI가 아닌 데스크톱 기반 컨트롤러에는 더 많은 CPU(주 프로세서) 대역폭이 필요하며 단일 활성 명령으로 제한되는 경우가 많습니다. 예를 들어 SCSI가 아닌 드라이브가 잘못된 블록을 조정하는 경우 드라이브는 호스트 명령이 대기하도록 합니다. ATA 버스는 두 개의 디바이스를 지원하지만 단일 명령만 활성화할 수 있는 또 다른 예입니다. 이 제한으로 인해 한 드라이브는 유휴 상태로 남고 다른 드라이브는 보류 중인 명령을 처리합니다. 데스크톱 기술을 기반으로 하는 RAID 시스템은 모두 이러한 증상을 경험할 수 있으며, 가장 느린 응답자의 영향을 크게 받을 수 있습니다. 이러한 시스템에서 고급 설계를 사용하지 않는 한, SCSI 기반 시스템의 성능만큼 성능이 효율적이지 않습니다.
스토리지 고려 사항
데스크톱 기반 드라이브 또는 배열은 경우에 따라 저렴한 솔루션이 될 수 있습니다. 예를 들어 보고용 읽기 전용 데이터베이스를 설정하는 경우 드라이브 캐싱을 사용하지 않도록 설정하면 OLTP 데이터베이스의 성능 요소가 많이 발생하지 않습니다.
스토리지 디바이스 크기는 계속 증가합니다. 저렴한 대용량 드라이브가 매력적일 수 있습니다. 그러나 SQL Server 및 비즈니스 응답 시간 요구 사항에 맞게 드라이브를 구성하는 경우 다음 문제를 신중하게 고려합니다.
- 액세스 경로 설계
- 디스크 캐시를 비활성화하기 위한 요구 사항
기계식 하드 드라이브
기계식 드라이브는 회전하는 자기 플래터를 사용하여 데이터를 저장합니다. IDE, SATA, SCSI 및 SAS(Serial Attached SCSI)와 같은 여러 용량 및 폼 팩터에서 사용할 수 있습니다. 일부 SATA 드라이브에는 오류 예측 구문이 포함됩니다. SCSI 드라이브는 더 힘든 작업에서 낮은 실패율을 제공하도록 설계되었습니다.
IDE 및 ATA 기반 시스템은 잘못된 블록 조정과 같은 작업을 수행할 때 호스트 명령을 연기할 수 있으며 이로 인해 I/O 작업이 중단됩니다.
SAS 혜택에는 최대 256개 수준까지 고급 큐잉, 큐의 선두, 순서 무시 큐잉이 포함됩니다. SAS 백플레인은 동일한 시스템 내에서 SAS 및 SATA 드라이브를 모두 사용할 수 있도록 설계되었습니다.
SQL Server 설치는 디스크 캐시를 비활성화하고 안정적인 I/O 캐시를 제공하는 컨트롤러의 기능에 따라 달라집니다. 컨트롤러가 올바른 안정적인 미디어 캐싱 기능을 제공하는 한, 다양한 드라이브에 데이터를 순서대로 쓰는 것은 SQL Server에 방해가 되지 않습니다. 미러링과 같은 고급 데이터 보안 기술은 컨트롤러 설계의 복잡성을 높입니다.
반도체 스토리지
반도체 스토리지는 기계식(회전) 하드 드라이브에 비해 장점이 있지만 회전하는 미디어와 동일한 많은 오류 패턴에 취약합니다. NVMe(NVM Express), PCI Express(PCIe) 및 SATA를 비롯한 다양한 인터페이스를 사용하여 서버에 반도체 스토리지를 연결할 수 있습니다. 고체 상태 미디어를 회전식 미디어처럼 주의 깊게 관리하고, 배터리로 지원되는 캐싱 컨트롤러 등과 같은 전원 장애에 대한 적절한 보호 장치가 마련되어 있는지 확인합니다.
전원 오류로 인한 일반적인 문제는 다음과 같습니다.
- 비트 손상: 레코드에 임의 비트 오류가 표시됩니다.
- Flying 쓰기: 잘 작성된 레코드가 잘못된 위치에서 끝납니다.
- Shorn이 작성: 작업이 예상 섹터 크기보다 낮은 레벨에서 일부만 수행됩니다.
- 메타데이터 손상: FTL(플래시 변환 계층)의 메타데이터가 손상되었습니다.
- 응답하지 않는 디바이스: 디바이스가 전혀 작동하지 않거나 대부분 작동하지 않습니다.
- 비직렬성: 스토리지의 최종 상태가 직렬화 가능한 작업 순서로 인해 발생하지 않습니다.
512e
대부분의 반도체 스토리지 디바이스는 512바이트 섹터 크기를 보고하지만 1MB 지우기 블록 내에서 4KB 페이지를 사용합니다. SQL Server 로그 디바이스에 512 바이트 정렬 섹터를 사용하면 RMW(읽기/수정/쓰기) 작업이 더 많이 생성되어 성능이 느려지고 드라이브가 마모될 수 있습니다.
권장 사항: 캐싱 컨트롤러가 스토리지 디바이스의 올바른 페이지 크기를 인식하고 물리적 쓰기를 반도체 스토리지 인프라에 올바르게 맞출 수 있는지 확인하세요.
0xFFFFFFFF
새로 포맷된 드라이브는 일반적으로 모두 0 값만 보유합니다. 반도체 디바이스의 지워진 블록은 모두 1이므로, 지워진 블록을 읽으면 결과적으로 모든 0xFF 문자로 나타납니다. 하지만 사용자가 일반 I/O 작업 중에 지워진 블록을 읽는 것은 드문 일입니다.
패턴 스탬핑
과거에 사용된 기술은 알려진 패턴을 전체 드라이브에 쓰는 것입니다. 그런 다음 동일한 드라이브에 대해 데이터베이스 작업이 실행되면 패턴이 예기치 않게 나타날 때 잘못된 동작(부실 읽기, 쓰기 손실 또는 잘못된 오프셋 읽기)을 검색할 수 있습니다.
이 기법은 반도체 스토리지에서 잘 작동하지 않습니다. 쓰기에 대한 지우기 및 RMW 작업은 패턴을 파괴합니다. GC(반도체 저장장치 가비지 수집) 작업, 마모 균등화, 비례/배제 목록 블록 및 기타 최적화로 인해, 회전 미디어의 섹터 재사용과 달리 쓰기가 다른 물리적 위치를 갖게 되는 경향이 있습니다.
펌웨어
반도체 스토리지에 사용되는 펌웨어는 회전하는 미디어와 비교할 때 대체로 복잡합니다. 많은 드라이브는 들어오는 요청 및 가비지 수집 작업을 처리하기 위해 여러 처리 코어를 사용합니다. 알려진 문제를 방지하려면 반도체 디바이스 펌웨어를 최신 상태로 유지해야 합니다.
읽기 데이터 손상 및 마모 평준화
반도체 스토리지의 일반적인 GC(가비지 수집) 접근 방식은 반복적인 읽기 데이터 손상을 방지하는 데 도움이 됩니다. 동일한 셀을 반복해서 읽을 때 전자 활동이 누출되어 이웃 셀에 손상을 줄 수 있습니다. 반도체 스토리지는 다양한 수준의 ECC(오류 수정 코드) 및 기타 메커니즘으로 데이터를 보호합니다.
이러한 메커니즘 중 하나는 마모 평준화와 관련이 있습니다. 반도체 스토리지는 스토리지 디바이스의 읽기 및 쓰기 작업을 추적합니다. 가비지 수집을 통해 다른 위치보다 빠르게 마모되는 핫 스폿 또는 위치를 확인할 수 있습니다. 예를 들어 GC는 블록이 읽기 전용 상태이며 이동해야 한다고 결정합니다. 이러한 이동은 일반적으로 마모가 더 많은 블록으로 이동하여, 원래 블록을 쓰기 작업에 사용할 수 있게 됩니다. 이 프로세스는 드라이브의 마모 균형을 맞추는 데 도움이 되지만 읽기 전용 데이터를 마모가 더 많은 위치로 이동하고 약간라도 실패 확률을 수학적으로 높입니다.
마모 평준화의 또 다른 부작용은 SQL Server에서 발생할 수 있습니다.
DBCC CHECKDB를 실행하고 오류를 보고한다고 가정합니다. 두 번째로 실행하는 경우 반도체 스토리지 GC 작업이 DBCC CHECKDB 실행 간에 변경될 수 있으므로 DBCC CHECKDB가 추가 또는 다른 오류 패턴을 보고할 가능성이 적습니다.
OS 오류 665 및 디스크 조각 모음
회전식 미디어는 드라이브의 헤드 이동을 줄이고 성능을 높이기 위해 블록을 서로 가깝게 유지해야 합니다. 반도체 스토리지에는 물리적 헤드가 없으므로 검색 시간이 제거됩니다. 많은 반도체 디바이스는 서로 다른 블록에서 병렬 작업을 허용하도록 설계되었습니다. 따라서 반도체 미디어의 조각 모음은 필요하지 않습니다. 직렬 작업은 반도체 스토리지 디바이스에서 I/O 처리량을 최대화하는 최상의 I/O 패턴입니다.
참고
반도체 스토리지는 더 이상 사용되지 않는 것으로 간주되는 블록을 지우는 OS(운영 체제) 수준 명령인 trim 기능의 이점을 누릴 수 있습니다. Windows에서는 드라이브 최적화 도구를 사용하여 드라이브 최적화를 위한 주간 일정을 설정합니다.
권장 사항:
쓰기 작업을 최적화하도록 설계된 적절한 배터리 지원 컨트롤러를 사용합니다. 이 선택은 성능을 향상시키고 드라이브 마모를 줄이며 물리적 조각화 수준을 낮출 수 있습니다.
ReFS 파일 시스템을 사용하여 NTFS 특성 제한을 방지하는 것이 좋습니다.
파일 증가 설정이 적절한지 확인합니다.
조각화와 관련한 OS 오류 665 문제 해결에 대한 자세한 내용은 SQL Server 파일에 대해 OS 오류 665 및 1450이 보고됨을 참조하세요.
압축
드라이브가 안정적인 미디어의 의도를 유지하는 한 압축은 드라이브 수명을 연장하고 성능에 긍정적인 영향을 줄 수 있습니다. 하지만 일부 펌웨어가 이미 데이터를 보이지 않게 압축했을 수 있습니다. 프로덕션 환경에 배포하기 전에 새 스토리지 시나리오를 테스트해야 합니다.
요약
- 적절한 백업 및 재해 복구 절차 및 프로세스를 유지 관리합니다.
- 펌웨어를 최신 상태로 유지합니다.
- 하드웨어 제조업체의 지침을 자세히 들어보세요.
드라이브 캐시 구성
SQL Server에서 드라이브를 사용하려면 드라이브 캐싱을 사용하지 않도록 설정합니다. 드라이브 캐시는 기본적으로 활성화되어 있습니다. Windows Server에서 디스크 속성>하드웨어>정책 탭을 사용하여 OS 수준에서 쓰기 캐싱을 사용하지 않도록 설정합니다.
OS 수준 설정만 사용하지 마세요. 일부 드라이브는 Windows 설정을 무시하고 쓰기 캐싱을 사용하지 않도록 설정하려면 제조업체에서 제공하는 유틸리티 또는 펌웨어 설정이 필요합니다. 공급업체 도구를 통해 쓰기 캐싱이 실제로 비활성화되어 있는지 확인합니다.
참고
쓰기 캐싱을 사용하지 않도록 설정하더라도 드라이브 펌웨어는 플러시 명령을 지연시키는 내부 최적화를 도입할 수 있습니다. SQLIOSim과 같은 테스트 도구를 사용하여 배포 전에 항상 유효 캐시 상태를 확인합니다.
캐시 고려 사항 및 SQLIOSim
트랜잭션 내구성 보장을 확인하려면 프로덕션으로 이동하기 전에 SQLIOSim 을 사용하여 I/O 하위 시스템의 유효성을 검사합니다. 이 유틸리티는 시뮬레이션된 데이터 디바이스 및 로그 디바이스에 대한 무거운 비동기 읽기 및 쓰기 작업을 시뮬레이션합니다. 자세한 내용은 SQLIOSim 유틸리티를 사용하여 디스크 하위 시스템의 SQL Server 작업을 시뮬레이트합니다. 더 광범위한 스토리지 벤치마킹을 위해 diskspd 스토리지 테스트 도구를 사용할 수도 있습니다.
참고
대체 캐싱 메커니즘이 여러 유형의 오류를 제대로 처리할 수 있는지 확인합니다.
대부분의 PC 제조업체는 쓰기 캐시가 비활성화된 드라이브를 주문합니다. 그러나 테스트는 이 조건이 항상 그렇지 않을 수 있음을 보여 주므로 항상 완전히 테스트해야 합니다. 스토리지 디바이스의 캐싱 상태에 대한 질문이 있는 경우 제조업체에 문의하고 적절한 유틸리티를 가져와 쓰기 캐싱 작업을 사용하지 않도록 설정합니다. 이전 스토리지 미디어에서 점퍼 설정이 필요할 수도 있습니다.
SQL Server를 사용하려면 시스템이 SQL Server I/O 안정성 프로그램 요구 사항에 설명된 대로 안정적인 미디어로의 전송 보장을 지원해야 합니다.
쓰기 캐싱의 부적절한 사용 위험
적절한 보호 장치 없이 쓰기 캐싱을 사용하도록 설정하면 일부 스토리지 하위 시스템은 데이터가 지속형 미디어에 안전하게 기록되기 전에 쓰기 작업이 완료된 것으로 인정합니다. 전원 손실 또는 시스템 오류가 발생하면 다음 조건이 발생할 수 있습니다.
- 커밋된 트랜잭션이 지속되지 않는 데이터 손실입니다.
- 보장된 쓰기 순서가 깨지면서 데이터베이스가 손상되었습니다.
Important
하드웨어 공급업체 설명서를 통해 다음을 확인하지 않는 한 SQL Server 데이터 및 로그 드라이브에 대한 쓰기 캐싱을 사용하지 않도록 설정합니다.
- 캐시는 배터리로 지원되거나 영구 플래시 스토리지를 사용합니다.
- 이 드라이브는 정전 및 시스템 충돌에서 내구성을 보장합니다.
외부 UPS 디바이스는 컨트롤러 펌웨어 오류와 같은 모든 오류 모드로부터 보호하지 못할 수 있으므로 충분하지 않습니다.
I/O 문제 지원
Microsoft SQL Server 및 SQL Server 기반 애플리케이션을 완벽하게 지원하지만 I/O 솔루션으로 인해 문제가 발생하는 경우 디바이스 제조업체는 지원을 담당합니다. 증상은 다음을 포함하지만 다음으로 제한되지는 않습니다.
- 데이터베이스 손상
- 백업 손상
- 예기치 않은 데이터 손실
- 누락된 트랜잭션
- 예기치 않은 I/O 성능 차이
참고
Microsoft 타사 하드웨어 또는 소프트웨어 제품이 SQL Server 작동하는지 인증하거나 유효성을 검사하지 않습니다. Microsoft 트랜잭션 의미 체계를 지원하기 위해 I/O 하위 시스템 및 캐싱 시스템 요구 사항을 포함한 환경 요구 사항을 게시합니다. 타사 공급업체는 해당 제품이 이러한 요구 사항을 충족하는지 확인할 책임이 있습니다. 타사 제품을 포함하는 구성에서 문제가 발생하는 경우 조사를 계속하기 전에 SQL Server 지원에서 타사 제품 없이 문제를 재현하도록 요청할 수 있습니다.
자세한 내용은 다음을 참조하세요.
파일 시스템 구성
다음 표에서는 특정 I/O 구성에 대한 추가 정보에 대한 링크를 제공합니다.
| Configuration | 세부 정보 |
|---|---|
| 파일 시스템 기능 | SQL Server 데이터베이스는 읽기 전용 파일을 제외하고 압축된 볼륨에서 지원되지 않습니다. 자세한 내용은 다음을 참조하세요. - 압축된 볼륨에서 SQL Server 데이터베이스에 대한 지원 설명 - EFS를 사용하여 데이터베이스 파일을 암호화할 때 SQL Server 성능 저하 |
| 물리적 레이아웃 및 디자인 |
-
물리적 데이터베이스 스토리지 디자인 - 확장 가능한 공유 데이터베이스 개요 |
tempdb |
tempdb 데이터베이스에 대한 - Microsoft SQL Server I/O 하위 시스템 요구 사항 - SQL Server tempdb 데이터베이스에서 할당 경합을 줄이기 위한 커밋 |
| 진단 | - SQL Server 진단은 부실 읽기 또는 쓰기 손실로 인해 보고되지 않은 I/O 문제를 검색합니다 - MSSQLSERVER 오류 823 |
| NAS(네트워크 연결 스토리지) | |
| Always On AG 및 FCI |
-
Always On 가용성 그룹에 대한 필수 구성 요소, 제한 사항 및 권장 사항 - Always On 장애 조치 클러스터 인스턴스 |