다음을 통해 공유

SQL Server I/O 기본 사항

  • 아티클

적용 대상:SQL ServerAzure SQL Managed InstanceAzure VM의 SQL Server

SQL Server 데이터베이스의 주 목적은 데이터 저장 및 검색이므로 데이터베이스 엔진의 핵심 특성은 집중형 디스크 I/O(입출력)입니다. 디스크 I/O 작업은 리소스를 많이 소모하고 완료하는 데 상대적으로 시간이 오래 걸릴 수 있으므로, SQL Server에서는 I/O의 효율성을 높이는 데 중점을 둡니다.

SQL Server용 스토리지 하위 시스템은 기계식 드라이브와 반도체 스토리지를 비롯한 여러 폼 팩터로 제공됩니다. 이 문서에서는 드라이브 캐싱 원칙을 사용하여 데이터베이스 엔진 I/O를 개선하는 방법을 자세히 설명합니다.

SQL Server를 사용하려면 시스템이 SQL Server I/O 안정성 프로그램 요구 사항에 설명된 대로 안정적인 미디어로의 전송 보장을 지원해야 합니다. SQL Server 데이터베이스 엔진의 입출력 요구 사항에 대한 자세한 내용은 SQL Server 데이터베이스 엔진 I/O(디스크 입출력) 요구 사항을 참조하세요.

디스크 I/O

버퍼 관리자는 데이터베이스에 대한 읽기 및 쓰기만 수행합니다. 열기, 닫기, 확장, 축소와 같은 기타 파일 및 데이터베이스 작업은 데이터베이스 관리자 및 파일 관리자 구성 요소에 의해 수행됩니다.

버퍼 관리자의 디스크 I/O 작업에는 다음과 같은 특징이 있습니다.

  • 일반적으로 I/O가 비동기적으로 수행되므로 I/O 작업이 백그라운드에서 발생하는 동안 호출 스레드가 처리를 계속할 수 있습니다. 일부 상황(예: 잘못 정렬된 로그 I/O)에서 동기 I/O가 발생할 수 있습니다.

  • 선호도 I/O 옵션을 사용하지 않는 한, 모든 I/O는 호출 스레드에서 실행됩니다. 선호도 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 요청은 백업 및 복원, 테이블 검색, 정렬, 인덱스 만들기, 대량 로드 및 파일 0 설정과 같은 대량의 순차 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(외부 무정전 전원 공급 장치)를 사용하는 것은 이를 달성하는 데 일반적으로 충분하지 않습니다.

캐싱 컨트롤러 및 스토리지 하위 시스템은 SQL Server에서 사용하기에 안전할 수 있습니다. 이러한 플랫폼을 통합하는 대부분의 새로운 전용 서버 플랫폼은 안전합니다. 하지만 하드웨어 공급업체에 문의하여 스토리지 하위 시스템이 RDBMS(데이터 중요 트랜잭션 관계형 데이터베이스 관리 시스템) 환경에서 사용하도록 테스트 및 승인되었는지 확인해야 합니다.

미리 쓰기 로깅

SQL Server 데이터 수정 문은 논리적 페이지 쓰기를 생성합니다. 이 쓰기 스트림은 로그와 데이터베이스 자체의 두 위치라고 할 수 있습니다. 성능상의 이유로 SQL Server는 자체 캐시 버퍼 시스템을 통한 데이터베이스로의 쓰기를 지연합니다. 로그에 대한 쓰기는 COMMIT 시간까지 잠시 지연됩니다. 데이터 쓰기와 동일한 방식으로 캐시되지 않습니다. 지정된 페이지에 대한 로그 쓰기는 항상 페이지의 데이터 쓰기보다 우선하기 때문에 로그를 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(미리 쓰기 로깅) 프로토콜 사양과 일치합니다. 많은 스토리지 디바이스(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가 초기화되면 트랜잭션 로그의 데이터를 기반으로 복구 프로세스가 자동으로 실행됩니다. 이 전체 과정은 인간의 개입 없이 발생합니다. 클라이언트 워크스테이션이 다시 시작될 때마다 사용자는 입력한 마지막 트랜잭션까지 모든 데이터가 있는 것을 확인할 수 있습니다.

SQL Server의 트랜잭션 무결성 및 자동 복구는 시간 및 작업을 줄여주는 강력한 기능을 제공합니다. 쓰기 캐싱 컨트롤러가 데이터 크리티컬 트랜잭션 DBMS 환경에서 사용하도록 제대로 설계되지 않은 경우, SQL Server의 복구 기능이 손상되어 데이터베이스가 손상될 수 있습니다. 이 문제는 컨트롤러가 SQL Server 트랜잭션 로그 쓰기를 가로채 컨트롤러 보드의 하드웨어 캐시에 버퍼링하지만, 시스템 오류 발생 시 이러한 기록된 페이지를 유지하지 않는 경우에 발생할 수 있습니다.

쓰기 캐싱 및 스토리지 디바이스 컨트롤러

대부분의 스토리지 디바이스 캐싱 컨트롤러는 쓰기 캐싱을 수행합니다. 쓰기 캐싱 함수를 항상 비활성화할 수는 없습니다.

서버에서 UPS를 사용하더라도 캐시된 쓰기의 보안이 보장되지는 않습니다. UPS에서 해결되지 않는 많은 유형의 시스템 오류가 발생할 수 있습니다. 예를 들어 메모리 패리티 오류, OS(운영 체제) 트랩 또는 시스템 재설정을 유발하는 하드웨어 결함으로 인해 제어되지 않는 시스템 중단이 발생할 수 있습니다. 하드웨어 쓰기 캐시의 메모리 오류로 인해 중요한 로그 정보가 소실될 수도 있습니다.

쓰기 캐싱 컨트롤러와 관련한 또 다른 문제는 시스템 종료 시 발생할 수 있습니다. 구성을 변경하는 동안 OS를 순환하거나 시스템을 다시 시작하는 것은 드문 일이 아닙니다. 신중한 운영자가 OS 권장 사항에 따라 시스템을 다시 시작하기 전에 모든 스토리지 작업이 중단될 때까지 기다리더라도 캐시된 쓰기는 컨트롤러에 계속 있을 수 있습니다. Ctrl+Alt+Del 키 조합을 누르거나 하드웨어 재설정 단추를 누르면 캐시된 쓰기가 삭제되어 데이터베이스가 손상될 수 있습니다.

더티 캐시 데이터를 삭제하는 모든 가능한 원인을 고려하여, 데이터베이스 서버에 사용하기에 안전한 하드웨어 쓰기 캐시를 설계할 수 있습니다. 이러한 설계 기능 중 일부에는 캐싱 컨트롤러의 제어되지 않는 재설정, 온보드 배터리 백업, ECC(미러 또는 오류 검사 및 수정) 메모리를 방지하기 위해 RST 버스 신호를 가로채는 것이 포함됩니다. 이러한 기능과 데이터 손실을 방지하는 데 필요한 다른 기능이 쓰기 캐시에 포함되어 있는지 하드웨어 공급업체에 문의하세요.

SQL Server에 스토리지 캐시 사용

데이터베이스 시스템은 예기치 않은 시스템 오류가 발생하더라도 데이터의 정확한 저장 및 검색을 최우선으로 합니다.

시스템은 현재 실행, 여러 트랜잭션 및 다양한 오류 지점을 고려하는 동시에 트랜잭션의 원자성 및 내구성을 보장해야 합니다. 이를 ACID(원자성, 일관성, 격리 및 내구성) 속성이라고도 합니다.

이 섹션에서는 스토리지 캐시의 영향을 알아봅니다. 캐싱 및 대체 실패 모드와 관련한 자세한 설명을 보려면 Microsoft 기술 자료에서 다음 문서를 읽어보는 것이 좋습니다.

다음 문서도 권장됩니다.

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

배터리 기반 캐싱 솔루션

향상된 캐싱 컨트롤러 시스템은 디스크 캐시를 비활성화하고 유용한 배터리 지원 캐싱 솔루션을 제공합니다. 이러한 캐시는 며칠 동안 캐시의 데이터를 유지 관리할 수 있으며 캐싱 카드를 두 번째 컴퓨터에 배치할 수도 있습니다. 전원이 제대로 복구되면 추가 데이터 액세스가 허용되기 전에 기록되지 않은 데이터가 완전히 플러시됩니다. 대부분의 경우 최적의 성능을 제공하도록 읽기 및 쓰기 캐시의 비율을 설정할 수 있습니다. 일부는 큰 메모리 스토리지 영역을 포함합니다. 일부 하드웨어 공급업체의 경우 여러 기가바이트 캐시가 있는 고성능 배터리 지원 드라이브 캐싱 시스템을 제공합니다. 이 경우 데이터베이스 성능이 크게 향상될 수 있습니다. 배터리 지원 캐싱 솔루션을 사용하면 SQL Server에서 기대하는 데이터의 내구성과 일관성을 얻을 수 있습니다.

스토리지 하위 시스템 구현

하위 시스템 구현에는 여러 가지 유형이 있습니다. RAID(Redundant Array of Independent Disks) 및 SAN(저장 영역 네트워크)은 이러한 하위 시스템 구현 유형의 두 가지 예입니다. 이러한 시스템은 일반적으로 SCSI 기반 드라이브를 사용하여 구축됩니다. 여기에는 여러 가지 이유가 있습니다. 다음 섹션에서는 일반적이고 대략적인 스토리지 고려 사항을 설명합니다.

SCSI, SAS 및 NVMe

SCSI, SAS 및 NVMe 스토리지 디바이스:

  • 일반적으로 산업용으로 제조됩니다.
  • 일반적으로 다중 사용자 서버 기반 구현 환경을 대상으로 합니다.
  • 일반적으로 다른 구현보다 실패 발생률에 대한 더 나은 평규 신간을 제공합니다.
  • 임박한 오류를 예측하는 데 도움이 되는 정교한 추론을 포함합니다.

비SCSI

IDE, ATA 및 SATA와 같은 기타 드라이브 구현 유형:

  • 일반적으로 개인용 및 중간급용으로 제조됩니다.
  • 일반적으로 단일 사용자 기반 애플리케이션을 대상으로 합니다.

비SCSI 데스크톱 기반 컨트롤러에는 더 많은 CPU(주 프로세서) 대역폭이 필요하며 단일 활성 명령으로 제한되는 경우가 많습니다. 예를 들어 SCSI가 아닌 드라이브가 잘못된 블록을 조정하는 경우 드라이브는 호스트 명령이 대기하도록 합니다. ATA 버스는 두 개의 디바이스를 지원하지만 단일 명령만 활성화할 수 있는 또 다른 예입니다. 따라서 한 드라이브가 유휴 상태로 남고 다른 드라이브는 보류 중인 명령을 처리합니다. 데스크톱 기술을 기반으로 하는 RAID 시스템은 모두 이러한 증상을 경험할 수 있으며, 가장 느린 응답자의 영향을 크게 받을 수 있습니다. 이러한 시스템에서 고급 설계를 사용하지 않는 한, SCSI 기반 시스템의 성능만큼 성능이 효율적이지 않습니다.

스토리지 고려 사항

데스크톱 기반 드라이브 또는 배열이 적절한 저비용 솔루션이 될 수도 있습니다. 예를 들어 보고용으로 읽기 전용 데이터베이스를 설정하는 경우, 드라이브 캐싱을 비활성화하더라도 OLTP 데이터베이스의 성능을 저해하는 요인이 많이 발생하지 않습니다.

스토리지 디바이스 크기는 계속 증가합니다. 따라서 저렴한 비용의 대용량 드라이브가 매력적일 수 있습니다. 하지만 SQL Server의 드라이브를 구성하고 비즈니스 응답 시간 요구 사항을 충족해야 하는 경우 다음 문제를 신중하게 고려해야 합니다.

  • 액세스 경로 설계
  • 디스크 캐시를 비활성화하기 위한 요구 사항

기계식 하드 드라이브

기계식 드라이브는 회전하는 자기 플래터를 사용하여 데이터를 저장합니다. IDE, SATA, SCSI 및 SAS(Serial Attached SCSI)와 같은 여러 용량 및 폼 팩터로 제공됩니다. 일부 SATA 드라이브에는 오류 예측 구문이 포함됩니다. SCSI 드라이브는 더 힘든 작업에서 낮은 실패율을 제공하도록 설계되었습니다.

드라이브를 SQL Server와 함께 사용하려면 드라이브 캐싱을 비활성화해야 합니다. 드라이브 캐시는 기본적으로 활성화되어 있습니다. Windows Server에서는 디스크 속성>하드웨어 탭을 사용하여 속성>정책 탭에 액세스한 후 드라이브 캐시 설정을 제어합니다.

참고 항목

일부 드라이브에는 이 설정이 적용되지 않습니다. 이러한 드라이브에는 캐시를 비활성화하는 특정 제조업체 유틸리티가 필요합니다.

IDE 및 ATA 기반 시스템은 잘못된 블록 조정과 같은 작업을 수행할 때 호스트 명령을 연기할 수 있습니다. 이로 인해 I/O 작업이 중단될 수 있습니다.

SAS의 이점에는 최대 256개 수준까지의 고급 큐, 큐 헤드 및 순서가 벗어난 큐가 포함됩니다. SAS 백플레인은 동일한 시스템 내에서 SAS 및 SATA 드라이브를 모두 사용할 수 있도록 설계되었습니다.

SQL Server 설치는 디스크 캐시를 비활성화하고 안정적인 I/O 캐시를 제공하는 컨트롤러의 기능에 따라 달라집니다. 컨트롤러가 올바른 안정적인 미디어 캐싱 기능을 제공하는 한, 다양한 드라이브에 데이터를 순서대로 쓰는 것은 SQL Server에 방해가 되지 않습니다. 미러링과 같은 고급 데이터 보안 기술은 컨트롤러 설계의 복잡성을 높입니다.

반도체 스토리지

반도체 스토리지는 기계식(회전) 하드 드라이브에 비해 장점이 있지만, 회전하는 미디어와 동일하게 많은 오류 패턴에 취약합니다. 반도체 스토리지는 NVMe(NVM Express), PCIe(PCI Express) 및 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이 보고됨을 참조하세요.

압축

드라이브가 안정적인 미디어의 의도를 유지하는 한, 압축은 드라이브 수명을 늘릴 수 있으며 성능에 긍정적인 영향을 줄 수 있습니다. 하지만 일부 펌웨어가 이미 데이터를 보이지 않게 압축했을 수 있습니다. 프로덕션 환경에 배포하기 전에 새 스토리지 시나리오를 테스트해야 합니다.

요약

  • 적절한 백업 및 재해 복구 절차 및 프로세스를 유지 관리합니다.
  • 펌웨어를 최신 상태로 유지합니다.
  • 하드웨어 제조 지침을 자세히 참조합니다.

캐시 고려 사항 및 SQLIOSim

데이터를 완전하게 보호하려면 모든 데이터 캐싱이 제대로 처리되었는지 확인해야 합니다. 대부분의 경우 이는 드라이브의 쓰기 캐싱을 비활성화해야 함을 의미합니다.

참고 항목

대체 캐싱 메커니즘이 여러 유형의 오류를 제대로 처리할 수 있는지 확인합니다.

Microsoft는 SQLIOSim 유틸리티를 사용하여 여러 SCSI 및 IDE 드라이브에서 테스트를 수행했습니다. 이 유틸리티는 시뮬레이션된 데이터 디바이스 및 로그 디바이스에 대한 방대한 비동기 읽기/쓰기 작업을 시뮬레이션합니다. SQLIOSim에 대한 자세한 내용 및 자세한 내용은 SQLIOSim 유틸리티를 사용하여 디스크 하위 시스템의 SQL Server 작업 시뮬레이트를 참조하세요.

대부분의 PC 제조업체는 쓰기 캐시가 비활성화된 드라이브를 주문합니다. 하지만 테스트 결과로 볼 때 항상 그렇지는 않을 수 있으므로, 항상 철저하게 테스트해야 합니다. 스토리지 디바이스의 캐싱 상태와 관련해 궁금한 점이 있는 경우 제조업체에 문의하고 적절한 유틸리티 또는 점퍼 설정을 파악하여 쓰기 캐싱 작업을 비활성화하세요.

SQL Server를 사용하려면 시스템이 SQL Server I/O 안정성 프로그램 요구 사항에 설명된 대로 안정적인 미디어로의 전송 보장을 지원해야 합니다. SQL Server 데이터베이스 엔진의 입출력 요구 사항에 대한 자세한 내용은 SQL Server 데이터베이스 엔진 I/O(디스크 입출력) 요구 사항을 참조하세요.

관련 콘텐츠