버퍼 관리

• 데이터 블록은 버퍼링 → 로그도 버퍼링
  • LogBuffer이 꽉 차면 전부 완전 저장 장치로 써짐
  • log force operation 나오면 이것도 전부 써짐
• Log force : commit 된 경우 무조건 나옴
  • 보통 그래서 Group commit 을 함. (full 될때까지 모았다가 감)
  • disk의 접근을 줄임.
• 반드시 지켜야될 사항
  • 순서대로 되야함
  • <Ti commit> log가 작성되야만 commit 가능
  • 데이터가 변경될 사항이 있으면 log가 먼저 가고 데이터 변경
    • Write-ahead logging (WAL) rule
• latch : 잠시 사용하는 lock (=pinned)
  • 데이터가 log 하기 전에 변경되는 것을 막음
  • deadlock 발생 X

버퍼 교체 정책

• 버퍼 관리의 핵심
• 블록 내용이 변경되었을 경우 디스크에 그 내용을 반영하고 버퍼에서 뻄
• 가장 오랫동안 사용되지 않은 블록을 교체하는 LRU(Least Recently Used)
  • 가장 널리 사용됨
  • 블록에 대한 과거 접근 패턴으로 미래 패턴 예측
  • 반복 데이터 스캔에는 별로
  • qurey optimizer 가 제공 → Mixed strategy
• Toss-immediate 전략:
  • 버퍼 블록의 마지막 튜플이 처리되면 해당 블록이 차지하고 있던 공간을 즉시 해제하는 전략입니다.
  • 해당 블록을 앞으로 참조할 필요없을 경우에 효과적
• 가장 최근에 사용된 것을 교체 (MRU) 전략:
  • 최근에 사용된 블록을 교체하는 전략으로, 전체적으로 반복적인 스캔이 필요한 경우에 효과적입니다.
• 통계적 정보 활용:
  • 버퍼 관리자는 통계적 정보를 사용할 수 있습니다.
  • 예를 들어, 데이터 사전(data dictionary)은 자주 접근되므로, 데이터 사전 블록을 메인 메모리 버퍼에 유지하는 것이 유리합니다.
• forced out-put 기능
  • 버퍼 관리자들은 복구 목적
  • DBMS가 원하는 시점에 특정 블록을 디스크에 즉시 쓰는 기능

데이터 페이지 버퍼링

• virtual memory를 사용
  • Dual paging 이 발생가능
    • swap space에 들어가버리면 이중 IO 발생가능

슬롯 페이지 구조

• 운영체제라고 보면은 여러가지 페이지가 모아서 하나의 페이지로 보이게 한다.
• DB → 여러개의 페이지를 묶어서 하나의 페이지기 때문에 이걸 단위로 진행된다.
• 페이지 헤더에는 각종 정보가 들어간다.