페이지 쓰기

적용 대상:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics AnalyticsPlatform System(PDW)

데이터베이스 엔진 인스턴스의 I/O에는 논리적 및 물리적 쓰기가 포함됩니다. 논리적 쓰기는 버퍼 캐시의 페이지에서 데이터가 수정될 때 발생합니다. 페이지가 버퍼 캐시에서 디스크로 기록될 때 실제 쓰기가 발생합니다.

페이지가 버퍼 캐시에서 수정될 때 페이지는 디스크에 바로 다시 기록되지 않고 대신 더티로 표시됩니다. 즉, 페이지는 물리적으로 디스크에 기록되기 전에 두 개 이상의 논리적 쓰기를 수행할 수 있습니다. 각 논리적 쓰기에 대해 수정 내용을 기록하는 트랜잭션 로그 레코드가 로그 캐시에 삽입됩니다. 로그 레코드는 관련된 더티 페이지가 버퍼 캐시에서 디스크로 제거되기 전에 디스크에 기록되어야 합니다. SQL Server는 연결된 로그 레코드가 디스크에 기록되기 전에 더티 페이지를 작성하지 못하게 하는 미리 쓰기 로깅이라는 기술을 사용합니다. 이는 복구 관리자가 정확하게 작업하는 데 필수적입니다. 자세한 내용은 미리 쓰기 트랜잭션 로그를 참조 하세요.

다음 그림에서는 수정된 데이터 페이지를 작성하는 프로세스를 보여 줍니다.

버퍼 관리자가 페이지를 쓸 때 단일 수집-쓰기 작업에 포함될 수 있는 인접한 더티 페이지를 검색합니다. 인접한 페이지에는 연속 페이지 ID가 있고 동일한 파일의 페이지 ID입니다. 페이지는 메모리에서 연속될 필요가 없습니다. 다음 이벤트 중 하나가 발생할 때까지 앞뒤로 계속 검색합니다.

• 정리된 페이지가 있습니다.
• 32페이지가 발견되었습니다.
• 로그에서 LSN(로그 시퀀스 번호)이 아직 플러시되지 않은 더티 페이지가 있습니다.
• 즉시 래치할 수 없는 페이지가 있습니다.

이러한 방식으로 전체 페이지 집합을 단일 수집-쓰기 작업으로 디스크에 쓸 수 있습니다.

페이지를 작성하기 직전에 데이터베이스에 지정된 페이지 보호 형식이 페이지에 추가됩니다. 조각난 페이지 보호가 추가되면 I/O에 대해 페이지가 EX(clusively)로 래치되어야 합니다. 이는 조각난 페이지 보호가 페이지를 수정하여 다른 스레드가 읽을 수 없도록 하기 때문입니다. 체크섬 페이지 보호가 추가되거나 데이터베이스에서 페이지 보호를 사용하지 않는 경우 페이지는 I/O에 대한 UP(날짜) 래치로 래치됩니다. 이 래치는 쓰기 중에 다른 사용자가 페이지를 수정할 수 없도록 하지만 독자가 이 페이지를 사용할 수 있도록 허용합니다. 디스크 I/O 페이지 보호 옵션에 대한 자세한 내용은 버퍼 관리를 참조하세요.

더티 페이지는 다음 세 가지 방법 중 하나로 디스크에 기록됩니다.

• 지연 쓰기
  지연 작성기는 버퍼 캐시에서 자주 사용되지 않는 페이지를 제거하여 사용 가능한 버퍼를 유지하는 시스템 프로세스입니다. 더티 페이지는 먼저 디스크에 기록됩니다.

• 열성적인 글쓰기
  즉시 쓰기 프로세스는 대량 삽입 및 선택과 같이 최소 로깅된 작업과 연결된 더티 데이터 페이지를 씁니다. 이 프로세스를 통해 새 페이지를 만들고 작성하여 병렬로 수행할 수 있습니다. 즉, 호출 작업은 디스크에 페이지를 쓰기 전에 전체 작업이 완료될 때까지 기다릴 필요가 없습니다.

• 검사점
  검사점 프로세스는 지정된 데이터베이스의 페이지가 있는 버퍼에 대한 버퍼 캐시를 주기적으로 검사하고 모든 더티 페이지를 디스크에 씁니다. 검사점은 모든 더티 페이지가 디스크에 기록되도록 보장되는 지점을 만들어 나중에 복구하는 동안 시간을 절약합니다. 사용자는 CHECKPOINT 명령을 사용하여 검사점 작업을 요청할 수 있습니다. 또는 데이터베이스 엔진은 사용된 로그 공간의 양과 마지막 검사점 이후 경과된 시간에 따라 자동 검사점을 생성할 수 있습니다. 또한 특정 활동이 발생할 때 검사점이 생성됩니다. 예를 들어 데이터 또는 로그 파일이 데이터베이스에서 추가 또는 제거되거나 SQL Server 인스턴스가 중지된 경우입니다. 자세한 내용은 검사점 및 로그의 활성 부분을 참조하세요.

지연 쓰기, 즉시 쓰기 및 검사점 프로세스는 I/O 작업이 완료되기를 기다리지 않습니다. 항상 비동기(또는 겹치는) I/O를 사용하고 나중에 I/O 성공을 확인하면서 다른 작업을 계속합니다. 이렇게 하면 SQL Server가 적절한 작업에 대한 CPU 및 I/O 리소스를 모두 최대화할 수 있습니다.

참고 항목

페이지 및 익스텐트 아키텍처 가이드
페이지 읽기