SQL Server 7.0, SQL Server 2000 및 SQL Server 2005의 로깅 및 데이터 저장소 알고리즘으로 인해 데이터 안정성이 높아진다

기술 자료 번역 기술 자료 번역
기술 자료: 230785 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

이 페이지에서

요약

SQL Server 7.0, SQL Server 2000 및 SQL Server 2005는 이전 Microsoft SQL Server 릴리스의 로깅 및 데이터 알고리즘을 다시 구성하고 설계하여 데이터 안정성 및 무결성을 향상시킵니다.

SQL Server 7.0 및 SQL Server 2000 엔진의 기본 개념에 대한 자세한 내용은 ACM Transactions on Database Systems의 "ARIES(Algorithm for Recovery and Isolation Exploiting Semantics): Write-Ahead Logging을 사용하여 세분화된 잠금 및 부분 롤백을 지원하는 트랜잭션 복구 방법(영문)"을 참조하십시오. 이 문서의 저자는 Chunder Mohan입니다.

이 문서에서는 오류 발생 시 데이터 안정성 및 무결성을 향상시키는 SQL Server 7.0, SQL Server 2000 및 SQL Server 2005 기술에 대해 설명합니다.

캐싱 및 대체 실패 모드에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
86903 SQL Server의 캐싱 디스크 컨트롤러에 대한 설명
46091 SQL Server에서 하드 디스크 컨트롤러 캐싱 사용
234656 INF: SQL Server에서 디스크 드라이브 캐싱 사용

추가 정보

다음 절에는 자세한 내용을 설명하기에 앞서 이 문서 전체에서 사용되는 일부 용어가 정의되어 있습니다.
표 축소표 확대
용어정의
배터리 지원 데이터 손실을 방지하기 위해 캐싱 메커니즘을 통해 지역화된 별도의 배터리 지원 기능을 직접 사용 및 제어할 수 있습니다.
참고 이것은 UPS(무정전 전원 공급 장치)가 아닙니다. UPS는 쓰기 작업을 보증하지 않으며 캐싱 장치에서 연결이 끊어질 수 있습니다.
캐시 실제 I/O 작업을 최적화하고 성능을 향상시키는 데 사용되는 중간 저장 메커니즘
커밋되지 않은 페이지 안정적인 저장소로 아직 플러시되지 않은 데이터 수정 내용이 들어 있는 페이지. 커밋되지 않은 페이지 버퍼에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.
오류 SQL Server 프로세스를 예기치 않게 정지시킬 수 있는 모든 상황(예: 정전, 컴퓨터 리셋, 메모리 오류, 기타 하드웨어 문제, 불량 섹터, 드라이브 정지, OS 오류 등)
플러시 안정적인 저장소로 캐시 버퍼를 강제로 이동하는 작업
래치 리소스의 물리적 일관성을 보호하는 데 사용되는 동기화 개체
비휘발성 저장소 시스템 오류가 발생한 경우에도 계속 사용할 수 있는 모든 미디어
고정된 페이지 데이터 캐시에 유지되고 연결된 모든 로그 레코드가 안정적인 저장소 위치에서 보호될 때까지 안정적인 저장소로 플러시할 수 없는 페이지
안정적인 저장소 비휘발성 저장소와 같음
휘발성 저장소 오류 발생 시 그대로 유지되지 않는 모든 미디어
SQL Server 2005, SQL Server 2000, SQL Server 7.0, 이전 버전의 SQL Server 및 현재 출시되어 있는 많은 주요 데이터베이스 제품은 WAL(Write-Ahead Logging) 프로토콜을 사용합니다.

WAL(Write-Ahead Logging) 프로토콜

프로토콜이란 말이 WAL을 잘 설명해 줍니다. 이것은 데이터가 올바르게 저장 및 교환되었는지 그리고 장애 발생 시 데이터를 알 수 있는 상태로 복구할 수 있는지 확인하는 데 필요한 특정하게 정의된 수행 단계를 모아놓은 것입니다. 네트워크에 정의된 프로토콜이 일관되고 보호된 방식으로 데이터를 교환하는 것처럼 WAL 역시 프로토콜을 준수하여 데이터를 보호합니다.

ARIES 문서에는 WAL이 다음과 같이 정의되어 있습니다.
WAL 프로토콜에서는 데이터의 변경을 나타내는 로그 레코드가 안정적인 저장소에 있어야 비휘발성 저장소의 변경된 데이터로 이전 버전의 데이터를 대체할 수 있습니다. 즉, 최소한 페이지의 업데이트를 설명하는 로그 레코드의 실행 취소 부분만이라도 안정적인 저장소에 기록될 때까지는 시스템에서 업데이트된 페이지를 비휘발성 저장소 버전의 페이지에 기록할 수 없습니다.
Write-Ahead Logging에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

SQL Server 및 WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 및 이전 SQL Server 릴리스에서는 WAL 프로토콜을 사용합니다. 트랜잭션이 올바로 커밋되도록 하려면 트랜잭션과 연결된 모든 로그 레코드를 안정적인 저장소에서 보호해야 합니다.

이를 명확히 이해하려면 다음과 같은 특정 예제를 참고하십시오. 이 예제에서는 인덱스가 없고 영향을 받는 페이지가 150페이지라고 가정합니다.
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
이제 작업을 다음과 같이 간단한 로깅 단계로 세분화합니다.
표 축소표 확대
수행되는 작업
BEGIN TRANSACTION 로그 캐시 영역에 기록되지만 SQL Server에서 실제로 변경된 내용이 없기 때문에서 안정적인 저장소에 플러시할 필요가 없습니다.
INSERT INTO tblTest1. 아직 사용 가능한 상태가 아닌 경우 데이터 페이지 150이 검색되어 SQL Server 데이터 캐시에 삽입됩니다.

2. 페이지가 래치, 고정커밋되지 않은 것으로 표시되고 적절하게 잠깁니다.

3. 삽입 로그 레코드가 작성되어 로그 캐시에 삽입됩니다.

4. 데이터 페이지에 새 행이 추가됩니다.

5. 래치가 해제됩니다.

6. 이 경우 모든 변경 내용이 휘발성 저장소에 유지되므로 트랜잭션이나 페이지와 연결된 로그 레코드를 플러시할 필요가 없습니다.
COMMIT TRANSACTION1. 커밋 로그 레코드가 작성되며 트랜잭션과 연결된 로그 레코드가 안정적인 저장소에 기록되어야 합니다. 로그 레코드가 안정적인 저장소에 올바로 할당되기 전까지 트랜잭션은 커밋된 것으로 간주되지 않습니다.

2. 데이터 페이지 150이 SQL Server 데이터 캐시에 유지되고 안정적인 저장소로 즉시 플러시되지 않습니다. 로그 레코드가 올바로 보호되면 필요한 경우 복구 작업을 다시 실행할 수 있습니다.

3. 트랜잭션 잠금이 해제됩니다.
잠금과 로깅을 혼동하면 안 됩니다. 둘 다 중요하지만 WAL을 다룰 때 잠금과 로깅은 별개의 항목으로 처리됩니다. 위의 예제에서 SQL Server 7.0, SQL Server 2000 및 SQL Server 2005는 일반적으로 전체 트랜잭션 시간이 아니라 페이지에서 실제로 삽입 작업을 수행하는 데 필요한 시간 동안 150페이지에 대한 래치를 설정합니다. 적절한 잠금 유형은 필요에 따라 행, 범위, 페이지 또는 테이블을 보호하도록 설정됩니다. 잠금 유형에 대한 자세한 내용은 SQL Server 온라인 설명서의 잠금 절을 참조하십시오.

예제를 자세히 살펴보면 LazyWriter 또는 CheckPoint 프로세스의 실행 결과가 궁금할 수 있습니다. SQL Server 7.0, SQL Server 2000 및 SQL Server 2005는 커밋되지 않은 고정된 페이지와 연결된 트랜잭션 로그 레코드를 안정적인 저장소로 플러시하는 모든 명령을 실행합니다. 따라서 연결된 트랜잭션 로그 레코드가 플러시될 때까지 데이터 페이지를 안정적인 저장소에 기록할 수 없는 WAL 프로토콜이 사용됩니다.

SQL Server 및 안정적인 저장소

SQL Server 7.0, SQL Server 2000 및 SQL Server 2005에서는 디스크 섹터 크기(대개 512바이트)에 대한 정보가 포함되어 로그 및 데이터 페이지 작업이 향상되었습니다.

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

SQL Server 7.0, SQL Server 2000 및 SQL Server 2005는 섹터 크기의 배수에 8KB 데이터 페이지 및 로그(플러시된 경우)를 사용합니다. 대부분의 디스크 드라이브는 기본 섹터 크기로 512바이트를 사용합니다. 오류 발생 시 SQL Server는 로그 패리티와 조각난 쓰기 기술을 사용하여 섹터보다 큰 쓰기 작업을 찾아낼 수 있습니다.

조각난 페이지 검색

다음은 조각난 페이지 검색에 대해 설명하는 SQL Server 7.0 온라인 설명서의 내용입니다.
이 옵션을 사용하면 SQL Server에서 정전이나 기타 시스템 정지를 일으키는 불완전한 I/O 작업을 검색할 수 있습니다. 이 경우 디스크에 페이지가 기록될 때마다 8KB 데이터베이스 페이지의 각 512바이트 섹터에 대해 비트가 거꾸로 표시됩니다. 나중에 SQL Server에서 페이지를 읽을 때 비트가 잘못된 상태에 있으면 페이지가 잘못 기록되고 조각난 페이지가 검색됩니다. 잘못 기록된 페이지는 복구 작업에서 읽을 가능성이 많으므로 일반적으로 조각된 페이지도 복구하는 동안 검색됩니다.

SQL Server 데이터베이스 페이지가 8KB인 경우에도 디스크는 512바이트 섹터를 사용하여 I/O 작업을 수행합니다. 따라서 데이터베이스 페이지당 16섹터가 기록됩니다. 운영 체제에서 첫 번째 512바이트 섹터를 디스크에 기록한 후 8KB I/O 작업이 완료되기 전에 정전 등의 이유로 시스템 오류가 발생하면 조각된 페이지가 발생할 수 있습니다. 오류가 발생하기 전에 데이터베이스 페이지의 첫 번째 섹터가 디스크에 성공적으로 기록되면 디스크의 데이터베이스 페이지는 업데이트가 실패한 경우에도 업데이트된 상태로 표시됩니다.

배터리 지원 디스크 컨트롤러 캐시를 사용하면 데이터가 디스크에 성공적으로 기록되도록 하거나 전혀 기록되지 않도록 할 수 있습니다. 이 경우 조각된 페이지 검색을 설정할 필요가 없습니다.
참고 기본적으로 SQL Server 7.0에서는 조각된 페이지 검색이 사용할 수 있도록 설정되지 않습니다. 시스템에서 조각된 페이지 검색을 사용하도록 설정하는 방법에 대해서는 sp_dboption을 참조하십시오.

로그 패리티

로그 패리티 검사는 조각된 페이지 검색과 매우 비슷합니다. 각 512바이트 섹터에는 패리티 비트가 포함되어 있습니다. 이러한 패리티 비트는 항상 로그 레코드와 함께 기록되며 로그 레코드가 검색될 때 계산됩니다. 512바이트 경계에 로그 쓰기를 강제로 적용하면 SQL Server 7.0, SQL Server 2000 및 SQL Server 2005에서 커밋된 작업을 실제 디스크 섹터에 완전히 쓸 수 있습니다.

이러한 변경 사항은 이전 버전의 SQL Server에조차 향상된 데이터 일관성을 제공합니다.

SQL Server 7.0 이전 버전

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

성능 영향

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

FILE_FLAG_WRITE_THROUGH 옵션은 쓰기 작업이 성공적으로 완료되었을 때 데이터가 안정한 저장소에 올바로 저장될 수 있도록 합니다. 이 옵션은 데이터를 보호하기 위해 WAL 프로토콜에 맞게 조정되었습니다.
많은 디스크 드라이브(SCSI 및 IDE)에는 512KB, 1MB 또는 그 이상의 캐시가 내장되어 있습니다. 그러나 드라이브 캐시는 보통 배터리 지원 솔루션이 아닌 축전기를 사용합니다. 이러한 캐싱 메커니즘은 전원 주기나 이와 유사한 실패 요소 전반에 대해 쓰기를 보장할 수는 없습니다. 단지 섹터 단위 쓰기 작업을 완료할 수 있습니다. 바로 이러한 이유 때문에 SQL Server 7.0, SQL Server 2000 및 SQL Server 2005에 조각난 쓰기 및 로그 패리티 검색이 빌드된 것입니다. 드라이브가 계속 커지면서 캐시도 점점 커지게 되고 이에 따라 장애가 발생하게 되면 더욱 많은 양의 데이터를 노출시키게 됩니다.

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

고급 캐싱 구현에서는 시스템 리셋, 정전 또는 기타 오류 지점 발생 시 일정한 다시 쓰기 기능을 제공할 수 있으므로 컨트롤러 캐시를 비활성화하지 않고도 FILE_FLAG_WRITE_THROUGH 요청을 처리합니다.

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

섹터 순서 지정

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

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

쓰기 캐시를 사용하는 경우 데이터는 여전히 휘발성 저장소에 있는 것으로 간주됩니다. 그러나 SQL Server에서 작업을 표시하는 방법을 정확히 보여주는 Win32 API WriteFile 호출을 통해 성공적인 반환 코드를 가져왔습니다. WriteFile API 호출을 사용하는 SQL Server나 다른 모든 프로세스에서는 안정적인 저장소에서 올바로 가져온 데이터만 추론할 수 있습니다.

설명을 위해 데이터 페이지의 모든 섹터는 일치하는 로그 레코드 섹터 앞에 기록되도록 정렬된다고 가정합니다. 이것은 WAL 프로토콜에 대한 직접적인 위반입니다. 캐시는 로그 레코드 앞에 데이터 페이지를 기록합니다. 캐시가 배터리를 완전히 지원하지 않는 경우 치명적인 오류가 발생할 수 있습니다.

데이터베이스 서버에 대한 최적의 성능 요인을 평가할 때는 여러 가지 요인을 고려해야 합니다. 이러한 고려 사항 중 가장 중요한 것은 "시스템에서 올바른 FILE_FLAG_WRITE_THROUGH 기능을 지원하는지 여부"입니다.

참고 사용하고 있는 모든 캐시는 배터리 지원 솔루션을 완전히 지원해야 합니다. 다른 모든 캐싱 메커니즘은 데이터 손상이나 데이터 손실로 의심됩니다. SQL Server는 FILE_FLAG_WRITE_THROUGH를 설정하여 WAL을 보호하기 위해 최선을 다합니다.

테스트 결과 다양한 디스크 드라이브 구성에 올바른 배터리 지원 없이 쓰기 캐싱이 포함될 수 있음을 알 수 있습니다. SCSI, IDE 및 EIDE 드라이브는 쓰기 캐시를 충분히 사용합니다.

다양한 구성에서 IDE 또는 EIDE 드라이브의 쓰기 캐싱을 사용하지 않도록 적절히 설정하는 유일한 방법은 특정 제조업체 유틸리티를 사용하거나 드라이브 자체에 있는 점퍼를 사용하는 것입니다. 드라이브 자체에 대한 쓰기 캐시가 사용할 수 없도록 설정되어 있는지 확인하려면 드라이브 제조업체에 문의하십시오.

SCSI 드라이브에도 쓰기 캐시가 있지만 이러한 캐시는 대개 운영 체제에 의해 사용하지 않도록 설정됩니다. 궁금한 점이 있으면 해당 유틸리티의 드라이브 제조업체에 문의하십시오.

쓰기 캐시 스태킹

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

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

AWR(자동 쓰기 재할당)

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

데이터 안전성

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

드라이브 테스트

데이터의 완전한 안전성을 보장하려면 모든 데이터의 캐싱이 올바로 처리되고 있는지 확인해야 합니다. 대부분 상황에서는 디스크 드라이브의 쓰기 캐싱을 사용하지 않도록 설정해야 합니다.

참고 대체 캐싱 메커니즘은 많은 유형의 장애를 올바로 처리할 수 있어야 합니다.

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

SQLIOStress 유틸리티에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
231619 SQLIOStress 유틸리티를 사용하여 SQL Server와 같은 디스크 하위 시스템의 스트레스를 테스트하는 방법
대부분의 PC 제조업체(예: Compaq, Dell, Gateway, HP 등)에서는 쓰기 캐시가 사용할 수 없도록 설정된 드라이버를 요구합니다. 그러나 테스트 결과에서 알 수 있듯이 항상 이러한 것은 아니기 때문에 항상 끝까지 테스트하십시오.

데이터 장치

거의 모든 로그되지 않은 상황에서 SQL Server는 로그 레코드를 플러시하기만 하면 됩니다. 로그되지 않은 작업을 수행할 때는 데이터 페이지도 안정적인 저장소로 플러시해야 합니다. 이때 오류 발생 시 작업을 다시 생성하는 개별 로그 레코드는 포함되지 않습니다.

데이터 페이지는 LazyWriter 또는 CheckPoint 프로세스에서 안정적인 저장소로 플러시하기 전까지 캐시에 남아 있을 수 있습니다. WAL 프로토콜을 사용하여 로그 레코드가 올바로 저장되도록 하면 복구 작업에서 데이터 페이지를 알 수 있는 상태로 복구할 수 있습니다.

이것은 캐시된 드라이브에 데이터 파일을 보관해야 함을 의미하지는 않습니다. SQL Server에서 데이터 페이지를 안정적인 저장소로 플러시할 경우 트랜잭션 로그에서 로그 데이터가 잘릴 수 있습니다. 데이터 페이지가 휘발성 캐시에 저장되어 있는 경우에는 오류 발생 시 페이지를 복구하는 데 사용되는 로그 레코드가 잘릴 수 있습니다. 데이터 및 로그 장치 모두에서 안정적인 저장소 올바로 수용해야 합니다.

성능 향상

처음 떠오르는 질문은 "캐싱 중인 IDE 드라이브를 사용하지 않도록 설정했는데도 성능이 예상보다 약간 더 저하되는 이유는 무엇일까?"하는 것입니다.

Microsoft에서 테스트한 대부분의 IDE 드라이브와 SCSI 드라이브는 각각 5,200과 7,200의 RPM 속도로 실행됩니다. IDE 드라이브의 쓰기 캐싱을 사용하지 않도록 설정한 경우 기계적 성능이 이러한 성능 저하의 요인일 수 있습니다.

성능 차이를 확인하는 가장 좋은 방법은 "트랜잭션 속도를 확인하는 것"입니다.

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

캐싱 드라이브에 대한 SQL Server의 성능이 크게 변경되도록 하기 위해 작은 트랜잭션을 사용하여 트랜잭션 속도를 높였습니다.

테스트 결과 512KB보다 작거나 2MB보다 큰 버퍼의 고속 쓰기 작업으로 인해 성능이 느려질 수 있음을 알 수 있습니다.
다음 예제를 참고하십시오.
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
다음은 SQL Server의 예제 테스트 결과입니다.
SCSI(7200 RPM) 84 seconds
SCSI(7200 RPM) 15 seconds (Caching controller)

IDE(5200 RPM) 14 seconds (Drive cache enabled)
IDE(5200 RPM) 160 seconds
단일 트랜잭션에서의 전체 INSERT 작업 래핑은 모든 구성에서 약 4초 동안 실행됩니다.

이것은 필요한 로그 플러시의 수와 관련이 있습니다. 트랜잭션이 없으면 각 INSERT가 그 자체로 또는 트랜잭션의 로그 레코드를 플러시해야 할 때마다 트랜잭션이 됩니다. 각 플러시의 크기는 중요한 기계적 드라이브 개입을 필요로 하는 512바이트입니다.

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

경고 트랜잭션 범위는 늘리지 않는 것이 좋습니다. 장기 실행 트랜잭션을 사용하면 오버헤드가 늘어날 뿐 아니라 원하지 않는 과도한 차단이 발생할 수 있습니다. SQL Server 7.0, SQL Server 2000 및 SQL Server 2005 성능 카운터 SQL Server:Databases를 사용하면 트랜잭션 로그 기반 카운터를 볼 수 있습니다. 특히, Log Bytes Flushed/sec는 많은 기계적 디스크 작업을 발생시키는 다양한 작은 트랜잭션을 나타낼 수 있습니다.

로그 플러시와 연결된 문을 보면 로그 플러시의 수를 줄일 수 있는지 여부를 확인할 수 있습니다. 위의 예제에서는 단일 트랜잭션이 구현되었습니다. 그러나 다양한 시나리오에서 이것은 원하지 않는 잠금 동작을 발생시킬 수 있습니다. 트랜잭션의 설계를 보면 작고 빈번한 로그 플러시 작업을 줄일 수 있도록 일괄 작업을 수행하는 다음과 같은 코드가 있을 수 있습니다.
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6.x에서는 작고 빈번한 트랜잭션 로그 쓰기에서 동일한 성능 효과가 발생하지 않을 수 있습니다. SQL Server 6.x는 트랜잭션이 커밋될 때마다 2KB 로그 페이지를 다시 작성합니다. 따라서 SQL Server 7.0, SQL Server 2000 및 SQL Server 2005에서 512바이트 섹터 경계 플러시와 비교하면 로그 크기가 크게 작아질 수 있습니다. 로그 크기를 줄이는 것은 기계적 드라이브 작업의 양과 직접적인 관련이 있습니다. 그러나 위에서 설명한 대로 SQL Server 6.x 알고리즘은 커밋된 트랜잭션을 노출할 수 있습니다.



Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹에 참여하시기 바랍니다.

속성

기술 자료: 230785 - 마지막 검토: 2006년 5월 15일 월요일 - 수정: 5.2
본 문서의 정보는 다음의 제품에 적용됩니다.
  • 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
키워드:?
kbhowto kbinfo KB230785

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com