SQL Server 데이터 안정성을 확장 하는 로깅 및 데이터 저장소 알고리즘 설명

이 문서는 Microsoft 기계 번역 소프트웨어를 이용하여 번역되었으며 Microsoft Community에 의한 Community Translation Framework(CTF) 기술 혹은 사람이 번역한 내용에 의하여 사후 편집될 수 있습니다. Microsoft는 Knowledge Base에 있는 모든 문서에 다양한 언어로 접근할 수 있도록 하기 위하여 기계 번역, 사람에 의한 번역 및 커뮤니티가 편집한 내용을 모두 제공합니다. 번역된 문서는 어휘, 구문 및/혹은 문법에 오류가 있을 수 있습니다. Microsoft는 번역 오류로 인한 부정확성, 오류 및/또는 손해와 이를 고객이 사용하는 데에 대하여 책임을 지지 않습니다.

이 문서의 영문 버전 보기:230785
요약
Microsoft SQL Server 로깅 및 데이터 알고리즘 데이터 안정성 및 무결성을 확장 하는 방법을 설명 합니다.

ARIES (복구 및 격리 기능을 악용에 대 한 알고리즘)와 엔진의 기본 개념에 대 한 자세한 내용은 다음 ACM 트랜잭션 데이터베이스 시스템 문서 (아래 "볼륨 1, 1992 년 3 월 17) 참조.

이 문서의 리드 작성자 C. Mohan입니다. 문서는 데이터 안정성 및 무결성 오류에 관련 된 SQL Server 기술을 다룹니다.

캐싱에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 읽는 것이 좋습니다 및 대체 실패 모드 설명:
86903 캐싱 디스크 컨트롤러 SQL Server 대 한
234656 모든 데이터베이스 관리자에 게 SQL Server 사용 하 여 디스크 드라이브 캐시 사용에 대 한 정보
추가 정보
깊이 있는 토론을 시작 하기에 앞서이 문서 전체에서 사용 되는 용어에는 다음 표에 정의 됩니다.
용어정의
배터리 지원지역화 된 및 별도 배터리 지원 기능을 직접 사용 및 제어할 캐싱 메커니즘을 통해 데이터 손실을 방지 하기 위해.
참고: 무정전 전원 공급 장치 (UPS)이 아닙니다. UPS는 쓰기 작업을 보증 하지 않습니다 및 캐싱 장치에서 연결이 끊어질 수 있습니다.
캐시실제 I/O 작업을 최적화 하 고 성능을 개선 하는 데 사용 되는 중간 저장 메커니즘입니다.
커밋되지 않은 페이지안정적인 저장소로 플러시해야 할 데이터 수정 내용을 포함 하는 페이지입니다. 커밋되지 않은 페이지 버퍼에 대 한 자세한 내용은 참조 있는 "페이지 작성"SQL Server 온라인 설명서에서 항목입니다.
참고: 콘텐츠는 Microsoft SQL Server 2012 및 이후 버전에도 적용 됩니다.
실패SQL Server 프로세스의 예상치 못한 중단을 유발할 수 있는 것입니다. 예를 들면: 정전, 컴퓨터 리셋, 메모리 오류, 기타 하드웨어 문제, 불량 섹터, 드라이브 정지, 시스템 장애 등에 전원.
플러시안정적인 저장소로 캐시 버퍼를 강제로.
래치리소스의 물리적 일관성을 보호 하는 데 사용 되는 동기화 개체입니다.
비휘발성 저장소시스템 오류가 발생 해도 계속 사용할 수 있는 모든 미디어.
고정 된 페이지캐시 데이터를 유지 하 고 모든 관련 된 로그 레코드가 안정적인 저장소 위치에서 보호 될 때까지 안정적인 저장소로 플러시할 수 없는 페이지.
안정적인 저장소비휘발성 저장소와 같음
휘발성 저장소모든 미디어는 오류가 발생 해도 그대로 유지 되지 것입니다.

미리 쓰기 로깅 (WAL) 프로토콜

프로토콜 이란 WAL을 설명할 수 있는 좋은 방법입니다. 특정 한 데이터를 확인 하는 데 필요한 단계를 구현에 정의 된 집합이 저장 되 고 제대로 교환 오류가 발생할 경우 알려진 상태로 복구할 수 있습니다. 따라서 일관 되 고 보호 된 방식으로 데이터를 교환 하려면 정의 된 프로토콜을 포함 하는 네트워크와 마찬가지로 WAL는 데이터를 보호 하려면 프로토콜 설명 너무.

ARIES 문서 WAL를 다음과 같이 정의합니다.
WAL 프로토콜 변경 된 데이터는 비휘발성 저장소에 있는 데이터의 이전 버전을 바꾸려면 허용 되기 전에 데이터의 변경을 나타내는 로그 레코드가 안정적인 저장소에 수 이미 있어야 가정 합니다. 시스템 업데이트 된 페이지를 비휘발성 저장소 버전의 페이지까지 작성 하도록 허용 되지 않은 즉, 안정적인 저장소에 기록 된 페이지에 대 한 업데이트를 설명 하는 로그 레코드의 실행 취소 부분만.
미리 쓰기 로깅에 대 한 자세한 내용은 참조는 미리 쓰기 트랜잭션 로그 SQL Server 온라인 설명서에서 항목입니다.

SQL Server 및 WAL

SQL Server WAL 프로토콜을 사용합니다. 트랜잭션이 커밋되기 정확 하 관련 된 트랜잭션의 모든 로그 레코드를 안정적인 저장소에서 보호 해야 합니다.

이러한 상황을 명확 하 게 다음과 같은 특정 예제를 살펴보십시오.

참고: 이 예제에서는 인덱스가 없습니다와 영향을 받는 페이지가 150 페이지를 가정해 봅시다.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
간단한 로깅 단계로 활동 분석 다음에 다음 표에 설명 된 것 처럼.
수행 작업
트랜잭션 시작로그 캐시 영역에 기록 합니다. 그러나 SQL Server 실제 변경 하지 않으므로 안정적인 저장소로 플러시할 수 필요는 없습니다.
TblTest 삽입
  1. 이미 사용할 수 있는 경우 데이터 페이지 150이 SQL Server 데이터 캐시에 검색 됩니다.
  2. 페이지는 걸려 있는지 확인, 고정를 하 고 표시 변경및 적절 한 잠금을 가져옵니다.
  3. 삽입 로그 레코드는 빌드 및 로그 캐시에 추가 합니다.
  4. 새 행이 데이터 페이지에 추가 됩니다.
  5. 래치가 해제 됩니다.
  6. 되며 트랜잭션과 연결 된 로그 레코드 또는 페이지에서 모든 변경 내용이 휘발성 저장소에 유지 하기 때문에 시점에서 플러시할 수 필요가 없습니다.
트랜잭션 커밋
  1. 커밋 로그 레코드가 한 트랜잭션과 관련 된 로그 레코드가 안정적인 저장소에 기록 되어야 합니다. 트랜잭션이 커밋 로그 레코드가 안정적인 저장소에 올바로 할당 되기까지 간주 되지 않습니다.
  2. 데이터 페이지 150 SQL Server 데이터 캐시에 유지 하 고 안정적인 저장소로 즉시 플러시되지 않습니다. 로그 레코드가 제대로 보안 하는 경우 복구 해야 하는 경우, 작업을 다시 수 있습니다.
  3. 트랜잭션 잠금이 해제 됩니다.
용어 "잠금" 및 "로그" 혼동 하지 마십시오 중요 한 잠금과 로깅은 별개의 문제는 WAL을 다룰 때. 앞의 예제에서 SQL Server 일반적으로 보유 래치 150 페이지에 시간에 대 한 전체 트랜잭션 시간이 아니라 페이지에서 실제로 삽입 작업을 수행 해야 합니다. 적절 한 잠금 유형은 행, 범위, 페이지 또는 필요에 따라 테이블을 보호 하기 위해 설정 됩니다. 잠금 유형에 대 한 자세한 내용은 SQL Server 온라인 설명서의 잠금 절을 참조 하십시오.

자세한 예제를 살펴보면 하면 검사점 또는 지연 기록기 프로세스는 실행 하는 경우 요청할 수 있습니다. SQL Server 7 안정적인 고정 및 커밋되지 않은 데이터 페이지와 연결 된 트랜잭션 로그 레코드에 대 한 저장소에 적절 한 모든 플러시를 발급 합니다. 이렇게 하면 WAL 프로토콜 데이터 페이지 연결 된 트랜잭션 로그 레코드가 플러시될 때까지 안정적인 저장소에 기록할 수 없는 수 있습니다.

SQL Server 및 안정적인 저장소

SQL Server 디스크 섹터 크기 (일반적으로 4, 096 바이트 또는 512 바이트)의 정보를 포함 하 여 로그 및 데이터 페이지 작업을 향상 시킵니다.

트랜잭션의 ACID 속성을 유지 하려면 SQL Server 오류 지점에 대해 설명 해야 합니다. 오류 발생 시 대부분의 디스크 드라이브 사양은 제한 된 양의 섹터 쓰기 작업만 보장 합니다. 오류 발생 시 대부분의 사양은 단일 섹터 쓰기 작업의 완료를 보장 합니다.

SQL Server 8KB 데이터 페이지와 로그 (플러시)에서 사용 섹터 크기의 배수로. (대부분의 디스크 드라이브를 사용 하 여 512 바이트 기본 섹터 크기로 합니다.) 호출이 실패 하면 SQL Server 있습니다 고려 쓰기 작업 섹터 보다 큰 로그 패리티와 조각난된 쓰기 기술을 사용 하 여.

조각난된 페이지 검색

이 옵션을 사용 하면 정전 또는 기타 시스템 중단으로 인해 발생 한 불완전 한 I/O 작업을 검색 하는 SQL Server입니다. True 인 경우로 서 페이지에 쓸 때마다 8kb 8KB 데이터베이스 페이지의 각 512 바이트 섹터에 대해 대칭 되도록 디스크에. 약간은 부적절 한 상태에 나중에 페이지를 읽을 때 SQL Server, 경우 다음 페이지를 잘못 작성. 조각난된 페이지가 검색 됩니다. 조각난된 페이지는 올바르게 작성 된 모든 페이지는 복구 작업에서 읽을 가능성이 있기 때문에 일반적으로 복구 하는 동안 검색 됩니다.

하지만 SQL Server 데이터베이스 페이지가 8KB 인 경우 디스크는 512 바이트 섹터를 사용 하 여 I/O 작업을 수행 합니다. 따라서 데이터베이스 페이지당 16 섹터가 기록 됩니다. 조각난된 페이지 간에 운영 체제의 첫 번째 512 바이트 섹터를 디스크에 쓰는 시간과 8KB I/O 작업이 완료 시스템 오류 (예: 정전) 때문에 발생할 수 있습니다. 데이터베이스 페이지의 첫 번째 섹터 오류가 발생 하기 전에 성공적으로 기록 된 데이터베이스 페이지가 디스크에 나타납니다 업데이트 성공 가질 수 있지만.

배터리 지원 디스크 컨트롤러 캐시를 사용 하 여 만들 수 있습니다 데이터 또는 디스크에 성공적으로 기록 되는 모든 기록 합니다. 이 상황에서 필요 하지 않습니다 때문에 조각난된 페이지 검색에 "true"를 설정 하지 마십시오.

참고: 조각난된 페이지 검색은 SQL Server 기본적으로 사용할 수 없습니다. 자세한 내용은 다음 MSDN 웹 사이트를 참조 하십시오.

로그 패리티

로그 패리티 검사는 조각난된 페이지 검색과 매우 비슷합니다. 각 512 바이트 섹터에는 패리티 비트가 포함 되어 있습니다. 항상 이러한 패리티 비트 로그 레코드와 함께 기록 되며 로그 레코드가 검색 될 때 계산. 512 바이트 경계에서 로그 기록 함으로써 SQL Server 수 있도록 함 작업 물리적 디스크 섹터를 완전히 쓰여집니다.

SQL Server 7.0 이전 버전

이전 버전의 SQL Server 7.0 제공 하지 않았습니다 로그 패리티 또는 조각난된 비트 검색 기능. 사실, 이러한 버전은 여러 번 동일한 로그 페이지를 작성할 수 있습니다 로그 레코드가 2KB 로그 페이지를 채울 때까지. 성공적으로 커밋된 트랜잭션을 표시할 수 있습니다. 오류 발생 시 로그 페이지가 다시 기록 될를 경우 커밋된 트랜잭션이 있는 섹터는 다시 기록 되지 제대로.

성능 영향

SQL Server 모든 버전은 Win32CreateFile 함수를 사용 하 여 로그 및 데이터 파일을 엽니다. SQL Server 열 때 dwFlagsAndAttributes 구성원 FILE_FLAG_WRITE_THROUGH옵션을 포함 합니다.
FILE_FLAG_WRITE_THROUGH
모든 중간 캐시를 통해 쓰고 디스크로 바로 가도록 시스템에 지시 합니다. 시스템은 쓰기 작업을 계속 캐시할 수 있지만 천천히 플러시할 수 없습니다.

FILE_FLAG_WRITE_THROUGH 옵션은 쓰기 작업이 성공적으로 완료 된 반환 합니다 해당 데이터가 올바르게 저장 되 안정적인 저장소에 있습니다. 이 데이터는 WAL 프로토콜을 사용 하 여 정렬 합니다.
많은 디스크 드라이브 (SCSI 및 IDE)에 512 KB, 1 MB 또는 더 큰 온보드 캐시 포함 되어 있습니다. 그러나 드라이브 캐시는 보통 배터리 지원 솔루션이 아닌 축전기를 사용 합니다. 이러한 캐싱 메커니즘은 전원 전반에 대해 쓰기 주기 나 이와 유사한 실패 요소 보장할 수 없습니다. 들만 섹터 쓰기 작업의 완료를 보장합니다. 특히 조각난된 쓰기 및 로그 패리티 검색 SQL Server 7.0 이상 버전으로 작성 된 이유입니다. 드라이브가 계속 증가 크기, 캐시 점점 커지게 되 고 오류 발생 시 더 많은 양의 데이터를 노출할 수 있습니다.

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

고급 캐싱 구현 됩니다 핸들 FILE_FLAG_WRITE_THROUGH 요청 하지 제공할 수 있으므로 컨트롤러 캐시를 비활성화 하 여 다시 쓰기 기능을 시스템 리셋, 정전 또는 기타 오류 지점.

캐시를 사용 하지 않는 I/O 전송은 드라이브 헤드, 회전율 및 다른 제한 인자로 이동 하는 데 필요한 기계의 시간을 때문에 훨씬 길어질 수 있습니다.

섹터 순서 지정

I/O 성능을 향상 시키기 위해 사용 되는 일반적인 기술은 섹터 순서 지정입니다. 기계적으로 헤드가 움직이는 방지 하기 위해 헤드를 검색 하거나 저장할 데이터의 동작을 보다 일관성 있도록 읽기/쓰기 요청 정렬 됩니다.

캐시 여러 로그를 저장할 수 있습니다 및 동시에 데이터 쓰기 요청을. WAL 프로토콜을 구현 SQL Server WAL 프로토콜 로그 플러시 씁니다 안정적인 저장소 페이지 쓰기를 실행 하기 전에 필요 합니다. 그러나 캐시 데이터를 실제 드라이브 (즉, 안정적인 저장소에 기록)에 기록 하지 않고 로그 쓰기 요청에서 성공을 반환할 수 있습니다. SQL Server 데이터 페이지 쓰기 요청을 실행 될 수 있습니다.

쓰기 캐시 참여와 데이터가 여전히 휘발성 저장소에 있는 것으로 간주 됩니다. 그러나 WriteFileWin32 API 호출에서 SQL Server 작업을 보는 방법을 정확 하 게 성공 반환 코드를 받았습니다. SQL Server 또는WriteFileAPI 호출을 사용 하는 프로세스가 onlythat 데이터의 안정적인 저장소 알아낸 올바르게 결정할 수 있습니다.

설명을 위해 데이터 페이지의 모든 섹터는 일치 하는 로그 레코드 섹터 앞에 기록 정렬 됩니다 가정 합니다. 즉시 WAL 프로토콜을 위반입니다. 캐시는 로그 레코드 앞에 데이터 페이지를 기록 합니다. 완전히 배터리 백업 캐시 않는 오류가 치명적인 결과가 발생할 수 있습니다.

데이터베이스 서버에 대 한 최적의 성능 요인을 평가할 때 고려해 야 할 많은 요소가 있습니다. 이러한 가장 중요 한 것은, "내 시스템에는 유효한 FILE_FLAG_WRITE_THROUGH 기능?"

참고: 완전 하 게 usingmust는 캐시는 배터리 지원 솔루션을 지원 합니다. 다른 모든 캐싱 메커니즘은 데이터 손상이 나 데이터 손실. SQL Server WAL FILE_FLAG_WRITE_THROUGH를 사용 하 여 되도록 모든 노력을 다하고 있습니다.

테스트 결과 다양 한 디스크 드라이브 구성 적절 한 배터리 백업 없이 쓰기 캐싱이 포함 될 수 있습니다. SCSI, IDE 및 EIDE 드라이브 쓰기 캐시를 모두 사용할 수 있습니다. SSDs SQL Server 함께 작동 하는 방법에 대 한 자세한 내용은 다음 SQL Server 엔지니어 블로그 CSS 문서 seethe:


다양 한 구성에서 올바르게 IDE 또는 EIDE 드라이브의 쓰기 캐싱을 사용 하지 않도록 설정 하는 유일한 방법은 특정 제조업체 유틸리티를 사용 하거나 드라이브 자체에 있는 점퍼를 사용 하 여 됩니다. 드라이브 자체에 대 한 쓰기 캐시가 사용할 수 없다는 확인 하려면 드라이브 제조업체에 문의 합니다.

또한 SCSI 드라이브 쓰기 캐시를 보유 합니다. 그러나 이러한 캐시는 운영 체제에서 일반적으로 비활성화할 수 있습니다. 모든 질문 하는 경우 해당 유틸리티에 대 한 드라이브 제조업체에 문의 합니다.

쓰기 캐시 스태킹

쓰기 캐시 스태킹은 섹터 순서 지정과 비슷합니다 합니다. 다음 정의 주요 IDE 드라이브 제조업체 웹 사이트에서 직접 찍은:
일반적으로이 모드가 활성화 됩니다. 캐시 모드는 호스트는 버퍼가 가득 차거나 호스트 전송이 완료 될 때까지 버퍼에 데이터를 쓸 쓰기.

디스크 쓰기 작업은 호스트 데이터를 디스크에 저장 하기 시작 합니다. 허용할 호스트 쓰기 명령은 계속 하 고 쓰기 명령 스택이나 꽉 또는 데이터 버퍼가 가득 때까지 데이터가 버퍼에 전송 합니다. 드라이브는 드라이브 처리량을 최적화 하기 위해 쓰기 명령을 다시 정렬할 수 있습니다.

자동 쓰기 재할당 (AWR)

데이터를 보호 하는 데 사용 되는 또 다른 일반적인 방법은 데이터를 조작할 때 불량 섹터를 검색 하는 것입니다. 다음 설명은 주요 IDE 드라이브 제조업체 웹 사이트에서 가져온:
이 기능은 쓰기 캐시의 일부로 고 지연 된 쓰기 작업 중 데이터 손실의 위험을 줄입니다. 디스크 쓰지 작업 중 디스크 오류가 발생 하면 디스크 작업이 중지 되 고 의심 되는 섹터가 드라이브 끝에 있는 대체 섹터의 풀에 다시 할당 합니다. 재할당 디스크 쓰기 작업이 완료 될 때까지 계속 됩니다.
이 캐시에 대해 배터리 지원이 제공 될 경우 매우 강력한 기능을 수 있습니다. 다시 시작할 때 적절 한 수정을 제공합니다. 디스크 오류를 감지 하는 것이 좋습니다 WAL 프로토콜의 데이터 보안을 다시 필요로 하는 상황은이를 실시간 및 지연된 방식으로 하지 않습니다. WAL 매개 변수 내에서 AWR 기술은 섹터 오류로 인해 로그 쓰기 오류가 발생 하지만 드라이브가 꽉 상황을 고려할 수 없습니다. 데이터베이스 엔진은 즉시 알아야 실패에 대 한 트랜잭션을 제대로 중단 될 수 있으므로 관리자가 알림을 받을 수 있습니다 및 데이터를 보호 하 고 미디어 오류 상황을 해결 하는 데 필요한 단계를 수정 합니다.

데이터 보안

데이터베이스 관리자는 데이터의 안전을 보장 하기 위해 수행 해야 하는 여러 가지 대비책을 가지가 있습니다.
  • 항상 백업 전략에는 치명적인 오류를 복구 하기에 충분 한지 확인 하는 것이 좋습니다. 오프 사이트 저장소 및 기타 예방 조치 됩니다.
  • 보조에서 데이터베이스 복원 작업 또는 테스트 데이터베이스를 정기적으로 테스트 합니다.
  • 모든 캐싱 장치에서 모든 오류 상황 (정전, 불량 섹터, 잘못 된 드라이브, 시스템 정지, 잠김, 전기 스파이크 등에)를 처리할 수 있도록 해야 합니다.
  • 되도록 캐싱 장치:
    • 배터리 지원이 통합 되어
    • 파워-업에서 쓰기를 다시 실행할 수 있습니다.
    • 필요한 경우 완전히 비활성화할 수 있습니다.
    • 실시간으로 불량 섹터 다시 매핑을 처리 합니다.
  • 조각난 페이지 검색을 사용 합니다. (성능에 거의 영향을 주지는.)
  • 가능한 경우 잘못 된 디스크 드라이브를 핫 스왑할 수 있도록 RAID 드라이브를 구성 합니다.
  • 운영 체제를 다시 시작 하지 않고도 디스크 공간을 추가 하는 데 사용할 수 있는 최신 캐싱 컨트롤러를 사용 합니다. 이 이상적인 솔루션을 수 있습니다.

드라이브 테스트

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

참고: 대체 캐싱 메커니즘이 많은 형태의 장애 올바르게 처리할 수 있는지 확인 하십시오.

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

SQLIOSim 유틸리티에 대 한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조 하십시오.
231619 SQLIOSim 유틸리티를 사용 하 여 디스크 하위 시스템에서 SQL Server 작업을 시뮬레이션 하는 방법
많은 컴퓨터 제조업체의 쓰기 캐시를 사용 하지 않도록 설정 하 여 드라이브를 주문 합니다. 그러나, 테스트 결과 이렇게 하지 못할 경우. 따라서 항상 끝까지 테스트 합니다.

데이터 장치

제외한 모든 로그 되지 않은 상황에서 SQL Server 로그 레코드를 플러시해야 할 필요 합니다. 로그 되지 않은 작업을 수행할 때는 데이터 페이지도 플러시해야 할; 안정적인 저장소로 오류 발생 시 작업을 다시 생성 하는 개별 로그 레코드가 없습니다.

검사점 또는 지연 기록기 프로세스 안정적인 저장소에 플러시합니다 때까지 데이터 페이지 캐시에 남아 있습니다. WAL 프로토콜을 사용 하 여 로그 레코드가 올바로 저장 하는 있도록 하면 복구를 알려진된 상태로 데이터 페이지를 복구할 수 있습니다.

캐시 된 드라이브에 데이터 파일을 배치 하는 것은 아닙니다. 때 SQL Server 데이터 페이지를 안정적인 저장소에 플러시 수 트랜잭션 로그에서 로그 레코드가 잘릴 수 있습니다. 데이터 페이지가 휘발성 캐시에 저장 되어 있으면 오류가 발생 한 경우 페이지를 복구 하는 로그 레코드가 잘릴 수 있습니다. 데이터와 로그 장치 안정적인 저장소 올바로 수용 해야 합니다.

성능 향상

발생 하는 첫 번째 질문은: "캐싱 중인 IDE 드라이브를 했습니다. 하지만, 비활성화 하면 성능이 되면서 예상 보다 훨씬 적은. 이유는 무엇입니까? "

5200의 RPM 속도로 실행 하는 많은 Microsoft에서 테스트 한 IDE 드라이브 및 SCSI 드라이브에 RPM 7200의. 쓰기를 사용 하지 않도록 설정 하는 경우 IDE 드라이브의 캐싱을 기계적 성능 요인일 수 있습니다.

성능 차이 해결 하기 위해 명확히 영역: "트랜잭션 속도 해결 합니다."

많은 온라인 트랜잭션 처리 (OLTP) 시스템에는 빠른 트랜잭션 속도가 필요는 있습니다. 이러한 시스템에서는 제대로 쓰기 캐시를 지원 하 고 데이터 무결성을 보장 하면서 성능 향상을 제공할 수 있는 캐싱 컨트롤러의 사용 하는 것이 좋습니다.

캐싱 드라이브에 SQL Server 사용 하 여 성능 변경 발생 크게, 작은 트랜잭션을 사용 하 여 트랜잭션 속도 증가 되었습니다.

테스트에서는 높은 512KB 보다 작거나 2MB 보다 큰 버퍼의 활동을 작성 하는 성능이 저하 될 수 있습니다.
다음 예제를 고려 하십시오.
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
다음은 SQL Server 예제 테스트 결과입니다.
SCSI(7200 RPM) 84 초
SCSI(7200 RPM) 15 초 (캐싱 컨트롤러)

IDE(5200 RPM) 14 초 (드라이브 캐시 사용)
IDE(5200 RPM) 160 초

모든 구성에서 약 4 초 안에 실행 단일 트랜잭션에서 INSERT 작업의 전체 시리즈를 배치 합니다.

때문에 필요한 로그 플러시의 수입니다. 트랜잭션이 없으면 각 INSERT는 자체의 트랜잭션 및 때마다 로그 레코드를 플러시해야 할. 각 플러시의 크기는 중요 한 기계적 드라이브 개입을 필요로 하는 512 바이트입니다.

단일 트랜잭션이 사용 되는 경우 트랜잭션의 로그 레코드 묶을 수 있고 보다 큰 쓰기를 사용 하 여 수집한 로그 데이터를 플러시할 수 있습니다. 이때 기계적 개입은 크게 줄어듭니다.

경고 트랜잭션 범위를 확장 하지 않는 것이 좋습니다. 장기 실행 트랜잭션이 과도 하 고 불필요 한 차단 시킬 수 뿐만 아니라 오버 헤드가 증가 합니다. 트랜잭션 로그 기반 카운터를 보려면 SQL Server: 데이터베이스 의 SQL Server 성능 카운터를 사용 합니다. 특히 초당 바이트 로그 플러시 높은 기계적 디스크 작업에 작은 트랜잭션이 많이 나타낼 수 있습니다.

로그 플러시와 연결 된 문을 살펴보고 결정 하는 경우 로그 플러시의 수를 줄일 수 있습니다. 이전 예제에서는 단일 트랜잭션이 구현 되었습니다. 그러나 대부분의 시나리오에서이 동작이 발생할 수 있습니다 원치 않는 잠금. 트랜잭션의 설계를 검사 합니다. 작고 빈번한 로그 플러시 작업을 줄일 수 있도록 일괄 수행 하는 다음과 유사한 코드를 사용할 수 있습니다.
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server 시스템이 지 원하는 "보장 된 안정적인 미디어에 전달"에 설명 된 대로 필요는 SQL Server I/O 안정성 프로그램 검토 요구 사항 문서를 다운로드 합니다. SQL Server 데이터베이스 엔진에 대 한 입력 및 출력 요구 사항에 대 한 자세한 내용은 Microsoft 기술 자료에 있는 문서를 이동 하려면 다음 문서 번호를 클릭 합니다.
967576 Microsoft SQL Server 데이터베이스 엔진이 입력/출력 요구 사항

경고: 이 문서는 자동으로 번역되었습니다.

속성

문서 ID: 230785 - 마지막 검토: 05/17/2015 07:12:00 - 수정: 1.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbhowto kbinfo kbmt KB230785 KbMtko
피드백