tempdb 데이터베이스에 대한 Microsoft SQL Server I/O 하위 시스템 요구 사항

이 문서에서는 SQL Server tempdb 데이터베이스에 대한 I/O 하위 시스템 요구 사항을 소개합니다.

원래 제품 버전: Microsoft SQL Server 2005, SQL Server 2008, SQL Server 2012 SQL Server 2014
원본 KB 번호: 917047

요약

Microsoft SQL Server 시스템 및 사용자 데이터베이스를 저장하는 데 사용되는 I/O 하위 시스템이 특정 I/O 보안 주체를 통해 WAL(Write-Ahead 로깅) 요구 사항을 완전히 준수해야 합니다. 이러한 요구 사항은 트랜잭션의 ACID 속성(Atomic, Consistent, Isolated 및 Durable)을 준수하기 위해 필요합니다. I/O 하위 시스템 규정 준수 요구 사항에 대한 자세한 내용은 다음 참조에서 제공합니다.

SQL Server 2000 I/O 기본 사항https://technet.microsoft.com/library/cc966500.aspx

다음 목록은 요구 사항에 대한 빠른 요약입니다.

• 쓰기 순서를 유지 관리해야 합니다.
• 종속 쓰기 일관성을 유지해야 합니다.
• 쓰기는 항상 안정적인 미디어 내/에서 보호되어야 합니다.
• 찢어진 I/O 방지가 발생해야 합니다.

내구성 유지 관리는 다른 모든 데이터베이스에 중요하지만 tempdb 데이터베이스에 대해 완화될 수 있습니다. 다음 표에서는 SQL Server 데이터베이스에 대한 몇 가지 중요한 I/O 요구 사항을 요약합니다.

트랜잭션 섹터 재작성은 하위 시스템에 의해 완전히 기록된 작업을 포함하므로 섹터를 원래 이미지로 완전히 이동, 교체 또는 롤백할 수 있습니다. 이러한 재작성은 일반적으로 이러한 작업을 수행하는 데 필요한 추가 오버헤드 때문에 권장되지 않습니다. 이 defragmentation 예제는 파일 데이터를 이동하는 유틸리티입니다. 파일의 원래 섹터는 새 섹터와 데이터가 보호될 때까지 새 섹터 위치로 바꿀 수 없습니다. 섹터의 다시 매핑은 트랜잭션 방식으로 발생해야 하므로 정전을 포함한 모든 오류로 인해 원래 데이터가 다시 설정됩니다. 잘못된 데이터 액세스를 방지하기 위해 이러한 종류의 프로세스 중에 잠금 메커니즘을 사용할 수 있는지 확인하여 SQL Server I/O의 다른 테넌트도 유지합니다.

중단에 걸친 생존

tempdb 데이터베이스는 SQL Server 위한 스크래치 영역이며 모든 SQL Server 시작 시 다시 빌드됩니다. 초기화는 다시 시작하는 동안 데이터가 필요 없이 대체됩니다.

트랜잭션 섹터 다시 쓰기 작업

롤백 및 크래시 복구와 같은 복구 프로세스의 성공을 보장하려면 데이터 페이지가 저장되기 전에 안정적인 미디어에 로그 레코드를 올바르게 저장해야 하며 트랜잭션 속성을 적용하지 않고는 다시 작성할 수 없습니다. 이렇게 하려면 하위 시스템 및 SQL Server 쓰기 순서 지정, 섹터 정렬 및 크기 쓰기, 앞에서 언급한 문서에 설명된 기타 I/O 안전 특성과 같은 특정 특성을 유지 관리해야 합니다. tempdb 데이터베이스의 경우 SQL Server 시작하는 동안 데이터베이스가 항상 초기화되므로 크래시 복구가 필요하지 않습니다. 그러나 tempdb 데이터베이스에는 롤백 기능이 여전히 필요합니다. 따라서 WAL 프로토콜의 일부 특성을 완화할 수 있습니다.

tempdb 데이터베이스의 스토리지 위치는 설정된 디스크 드라이브 프로토콜에 따라 엄격하게 작동해야 합니다. 모든 면에서 tempdb 데이터베이스가 저장된 디바이스가 나타나고 쓰기 후 읽기 기능을 제공하는 실제 디스크 역할을 해야 합니다. 트랜잭션 섹터 재작성 작업은 특정 구현의 추가 요구 사항일 수 있습니다. 예를 들어 NTFS 압축은 이미 작성되고 강화된 것으로 간주되는 로그의 섹터를 다시 쓸 수 있으므로 SQL Server NTFS 파일 시스템 압축을 사용하여 데이터베이스 수정을 지원하지 않습니다. 이 유형의 재작성 중에 오류가 발생하면 데이터베이스를 사용할 수 없게 되어 이미 안전한 것으로 간주될 SQL Server 있는 데이터가 손상될 수 있습니다.

트랜잭션 섹터 다시 쓰기 작업은 tempdb 데이터베이스를 포함하는 모든 SQL Server 데이터베이스와 관련이 있습니다. 점점 더 다양해지는 확장 스토리지 기술은 SQL Server 안전하다고 간주하는 데이터를 다시 쓸 수 있는 디바이스 및 유틸리티를 사용합니다. 예를 들어 일부 새로운 기술은 메모리 내 캐싱 또는 데이터 압축을 수행합니다. 심각한 데이터베이스 손상을 방지하려면 모든 섹터 재작성에서 오류가 발생할 경우 데이터가 이전 섹터 이미지로 롤백되는 방식으로 완전한 트랜잭션 지원을 받아야 합니다. 이렇게 하면 SQL Server 예기치 않은 중단 또는 데이터 손상 조건에 노출되지 않습니다.

tempdb 데이터베이스를 RAM 디스크, 반도체 상태 또는 다른 데이터베이스에 사용할 수 없는 기타 고속 구현과 같은 특수 하위 시스템에 배치할 수 있습니다. 그러나 이러한 옵션을 평가할 때 추가 정보 섹션에 제시된 주요 요소를 고려해야 합니다.

추가 정보

tempdb 데이터베이스의 스토리지 위치를 평가할 때 몇 가지 요소를 신중하게 연구해야 합니다. 예를 들어 tempdb 데이터베이스 사용은 메모리 공간, 쿼리 계획 및 I/O 결정에 포함되지만 이에 국한되지 않습니다. tempdb 데이터베이스의 적절한 튜닝 및 구현은 시스템의 확장성과 응답성을 향상시킬 수 있습니다. 이 섹션에서는 tempdb 데이터베이스에 대한 스토리지 요구 사항을 결정하는 주요 요인에 대해 설명합니다.

고속 하위 시스템

시장에는 SQL Server I/O 하위 시스템 프로토콜 요구 사항을 제공하지만 미디어의 내구성을 제공하지 않는 다양한 고속 하위 시스템 구현이 있습니다.

RAM 디스크는 이러한 구현의 일반적인 예입니다. RAM 디스크는 필요한 드라이버를 설치하고 기본 RAM 디스크의 일부가 시스템에 연결된 모든 디스크 드라이브처럼 표시되고 작동할 수 있도록 합니다. 모든 I/O 하위 시스템은 SQL Server I/O 요구 사항을 완전히 준수해야 합니다. 그러나 RAM 디스크가 지속형 미디어가 아니라는 것은 분명합니다. 따라서 RAM 디스크와 같은 구현은 tempdb 데이터베이스의 위치로만 사용할 수 있으며 다른 데이터베이스에는 사용할 수 없습니다.

구현 및 배포 전에 고려해야 할 키

이러한 종류의 하위 시스템에 tempdb 데이터베이스를 배포하기 전에 고려해야 할 여러 가지 사항이 있습니다. 이 섹션에서는 토론의 기초로 RAM 디스크를 사용하지만 다른 고속 구현에서도 비슷한 결과가 발생합니다.

I/O 안전

쓰기 및 트랜잭션 섹터 쓰기 후 읽기의 준수는 필수입니다. SQL Server I/O 요구 사항을 완전히 지원하지 않는 시스템에 SQL Server 배포하거나 데이터 손상 및 손실을 초래할 위험이 있습니다.

이미 캐시된 페이지(이중 RAM 캐시)

임시 테이블은 데이터베이스의 다른 모든 테이블과 같습니다. 버퍼 풀에 의해 캐시되고 지연 쓰기 작업으로 처리됩니다. 임시 테이블 페이지를 RAM 디스크에 저장하면 버퍼 풀에 하나씩, RAM 디스크에 하나씩 RAM 캐싱이 두 번 발생합니다. 이렇게 하면 버퍼 풀의 가능한 총 크기에서 직접 제거되고 일반적으로 SQL Server 성능이 저하됩니다.

RAM 포기

RAM 디스크는 이름에서 알 수 있듯이 기본 RAM의 일부를 지정합니다. 사용 가능한 RAM 디스크 및 RAM 기반 파일 캐시의 몇 가지 구현이 있습니다. 일부는 물리적 I/O 백업 작업을 사용하도록 설정합니다. RAM 기반 파일 캐시의 핵심 요소는 SQL Server 사용할 수 있는 실제 메모리에서 직접 제거된다는 것입니다. RAM 기반 파일 캐시를 추가하면 애플리케이션 성능이 향상되고 다른 쿼리 또는 애플리케이션 성능이 저하되지 않는다는 강력한 증거가 항상 있습니다.

먼저 튜닝

애플리케이션은 tempdb 데이터베이스를 사용할 수 있는 불필요하고 원치 않는 정렬 및 해시를 제거하도록 조정해야 합니다. 인덱스가 추가되면 계획에서 정렬 또는 해시의 필요성이 완전히 제거되어 tempdb 데이터베이스를 사용하지 않고도 최적의 성능을 발휘할 수 있습니다.

가능한 혜택 포인트

tempdb 데이터베이스를 고속 시스템에 배치하는 이점은 애플리케이션 워크로드의 엄격한 테스트 및 측정을 통해서만 확인할 수 있습니다. tempdb 데이터베이스가 활용할 수 있는 특성에 대해 워크로드를 신중하게 연구해야 하며 배포 전에 I/O 보안을 확인해야 합니다.

정렬 및 해시 작업은 SQL Server 메모리 관리자와 함께 작동하여 각 정렬 또는 해시 작업에 대한 메모리 내 스크래치 영역의 크기를 결정합니다. 정렬 또는 해시 데이터가 할당된 메모리 내 스크래치 영역을 초과하는 즉시 데이터가 tempdb 데이터베이스에 기록될 수 있습니다. 이 알고리즘은 2005년 SQL Server 확장되어 이전 버전의 SQL Server tempdb 데이터베이스 사용 요구 사항을 줄였습니다.

SQL Server tempdb 데이터베이스를 사용하여 정렬, 해시, 행 버전 저장소 및 임시 테이블과 관련된 다양한 작업을 처리합니다.

• 임시 테이블은 데이터 페이지에 대한 일반적인 버퍼 풀 루틴에 의해 유지 관리되며 일반적으로 특수 하위 시스템 구현의 성능 이점을 나타내지 않습니다.
• tempdb 데이터베이스는 해시 및 정렬에 대한 스크래치 영역으로 사용됩니다. 이러한 작업에 대한 I/O 대기 시간을 줄이는 것이 유용할 수 있습니다. 그러나 해시 또는 정렬을 방지하기 위해 인덱스 추가는 비슷한 이점을 제공할 수 있습니다.

고속 하위 시스템에 저장된 tempdb 데이터베이스를 사용 및 사용하지 않고 기준을 실행하여 이점을 비교합니다. 테스트의 일부는 정렬, 해시 또는 임시 테이블을 포함하지 않는 사용자 데이터베이스에 대한 쿼리를 포함하고 이러한 쿼리가 부정적인 영향을 받지 않는지 확인해야 합니다. 시스템을 평가할 때 다음 성능 지표가 유용할 수 있습니다.

트랜잭션 섹터 다시 쓰기 예제

다음 예제에서는 SQL Server 데이터베이스에 필요한 데이터 보안을 정교하게 설명합니다.

RAM 디스크 공급업체가 메모리 내 압축 구현을 사용한다고 가정합니다. SQL Server 기본 구현에서 인식하지 못하고 올바르게 보호되도록 섹터가 정렬되고 크기가 조정된 것처럼 파일 스트림의 물리적 모양을 제공하여 구현을 올바르게 캡슐화해야 합니다. 압축 예제를 자세히 살펴보십시오.

• 섹터 1은 디바이스에 기록되며 공간을 절약하기 위해 압축됩니다.
• 섹터 2는 디바이스에 기록되며 공간을 절약하기 위해 1섹으로 압축됩니다.

디바이스는 섹터 2의 데이터와 결합된 경우 섹터 1의 데이터를 보호하는 데 도움이 되도록 다음 작업을 수행할 수 있습니다.

• 섹터 1 및 2에 대한 모든 쓰기를 차단합니다.
• 1섹터의 압축을 스크래치 영역으로 압축 해제하고 현재 섹터 1 스토리지를 검색할 활성 데이터로 남깁니다.
• 섹터 1과 2를 새 스토리지 형식으로 압축합니다.
• 섹터 1과 2의 모든 읽기 및 쓰기를 차단합니다.
• 1 및 2 섹터에 대한 이전 스토리지를 새 스토리지와 교환합니다. 교환 시도가 실패하는 경우(롤백):
  • 섹터 1 및 2에 대한 원래 스토리지를 복원합니다.
  • 스크래치 영역에서 섹터 1과 2 결합 데이터를 제거합니다.
  • 섹터 2 쓰기 작업에 실패합니다.
• 섹터 1 및 2에 대한 읽기 및 쓰기 차단을 해제합니다.

섹터 수정에 대한 잠금 메커니즘을 제공하고 섹터 교환 시도가 실패할 때 변경 내용을 롤백하는 기능은 전환적으로 규정을 준수하는 것으로 간주됩니다. 확장된 백업에 실제 스토리지를 사용하는 구현의 경우 디스크 내 구조에 적용된 변경 내용을 보호하고 롤백하여 SQL Server 데이터베이스 파일의 무결성을 유지하는 데 도움이 되는 적절한 트랜잭션 로그 측면이 포함됩니다.

섹터를 다시 쓸 수 있도록 하는 모든 디바이스는 SQL Server 데이터 손실에 노출되지 않도록 트랜잭션 방식으로 재작성을 지원해야 합니다.

tempdb 데이터베이스를 이동할 때는 주의해야 합니다.

tempdb 데이터베이스를 만들 수 없는 경우 SQL Server 시작되지 않으므로 tempdb 데이터베이스를 이동할 때는 주의해야 합니다. tempdb 데이터베이스를 만들 수 없는 경우 (-f) 시작 매개 변수를 사용하여 SQL Server 시작하고 tempdb 데이터베이스를 유효한 위치로 이동합니다.

tempdb 데이터베이스의 물리적 위치를 변경하려면 다음 단계를 수행합니다.

1. 문 및 절을 ALTER DATABASEMODIFY FILE 사용하여 tempdb 데이터베이스에 있는 각 파일의 실제 파일 이름을 변경하여 새 디스크와 같은 새 물리적 위치를 참조합니다.

   ALTER DATABASE tempdb MODIFY FILE 
   (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')
   
   ALTER DATABASE tempdb MODIFY FILE 
   (name = templog, filename = 'C:\MyPath\templog.ldf')
   

2. 중지한 다음 SQL Server 다시 시작합니다.

파트너 제품 인증은 호환성 또는 안전의 보증이 아닙니다.

타사 제품 또는 특정 공급업체는 Microsoft 로고 인증을 받을 수 있습니다. 그러나 파트너 인증 또는 특정 Microsoft 로고는 SQL Server 특정 목적에 대한 호환성 또는 적합성을 인증하지 않습니다.

지원

이 문서에 설명된 대로 트랜잭션 데이터베이스 사용에 대한 I/O 보장을 지원하는 SQL Server 하위 시스템을 사용하는 경우 Microsoft는 SQL Server 및 SQL Server 기반 애플리케이션에 대한 지원을 제공합니다. 그러나 하위 시스템의 문제 또는 원인은 제조업체에 참조됩니다.

tempdb 데이터베이스 관련 문제의 경우 Microsoft 지원 Services에서 tempdb 데이터베이스를 재배치하도록 요청합니다. 디바이스 공급업체에 문의하여 트랜잭션 데이터베이스 사용을 위해 디바이스를 올바르게 배포하고 구성했는지 확인합니다.

Microsoft는 타사 제품이 SQL Server 올바르게 작동하는지 인증하거나 유효성을 검사하지 않습니다. 또한 Microsoft는 SQL Server 사용하기 위한 타사 제품의 적합성을 보증, 보증 또는 진술하지 않습니다.

참조

자세한 내용은 다음 Microsoft 기술 자료 문서를 참조하세요.

• 보고되지 않은 I/O 문제를 검색하기 위해 추가 SQL Server 진단 추가됨

• 오류 메시지 823은 SQL Server 하드웨어 문제 또는 시스템 문제를 나타낼 수 있습니다.

• SQL Server 디스크 드라이브 캐싱 사용

• SQL Server 네트워크 데이터베이스 파일 지원에 대한 설명

• Microsoft는 타사 제품이 Microsoft SQL Server 작동한다는 것을 인증하지 않습니다.

• Azure Virtual Machines SQL Server 대한 성능 지침

• SQL Server 2014 카디널리티 예측 도구를 사용하여 쿼리 계획 최적화

• 쿼리 성능