페이지 쓰기

적용 대상: SQL Server Azure SQL 데이터베이스 Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System(PDW)

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

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

다음 예시는 수정된 데이터 페이지를 쓰는 프로세스를 보여줍니다.

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

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

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

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

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

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

• 즉시 쓰기
  즉시 쓰기 프로세스는 대량 삽입 및 선택과 같이 최소한의 로깅이 필요한 작업과 관련된 더티 데이터 페이지를 씁니다. 이 프로세스를 통해 새 페이지 생성과 쓰기를 동시에 수행할 수 있습니다. 즉, 호출 작업은 전체 작업이 완료될 때까지 기다렸다가 페이지를 디스크에 쓸 필요가 없습니다.

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

지연 쓰기, 즉시 쓰기, 검사점 프로세스는 I/O 작업이 완료될 때까지 기다리지 않습니다. 이러한 프로세스는 항상 비동기(또는 중복) I/O를 사용하고 다른 작업을 계속 진행하면서 나중에 I/O 성공 여부를 확인합니다. 이를 통해 SQL Server는 적절한 작업을 위해 CPU 및 I/O 리소스를 모두 최대화할 수 있습니다.

참고 항목

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