Disks and files

platters가 돈다.
arm assembly가안팎으로 움직이면서 헤드를 원하는 track 위에 올려놓는다.
헤드들 밑에 놓은 트랙들은 cylinder라고 한다.
한번에 one head만 읽고 쓸 수 있다.
block size는 여러개의 sector size이다.

seek time : arm으로 head를 원하는 트랙위에 위치시키는데 걸리는 시간.
rotational delay : 원하는 block에 도착할때까지 회전하는 시간.
transfer time: data 전송시간
i/o cost를 줄이려면 seek time과  rotational delay를 줄인다.
파일의 block들을 디스크에 연속적으로 저장한다.
같은 트랙의 블락 -> 같은 실린더의 블락 -> 인접한 실린더의 블락 순으로.
연속적인 스캔을 할 때, 미리 몇개의 페이지를 메모리로 불러오는 pre-fetching은 성능항상에 도움이 된다.

RAID
여러개의 디스크를 사용해서 하나의 큰 디스크로 추상화.
성능항상과 신뢰성을 위해 사용.
data striping(data를 쪼개서 저장), redundancy(fail을 대비해서 데이터를 중복해서 저장)
 
Disk space management
페이지를 할당하고 해제하는 역할.
페이지를 읽고 쓰는 역할을 한다.

buffer management
메인메모리의 크기가 상대적으로 디스크보다 작기때문에
메인메모리에 버퍼풀을 유지. 디스크로부터 필요한 프래임을 가져온다.
replacement policy를 통해 어떤 페이지가 교체될 것인지 정한다.
교체될 때 교체되는 frame이 수정되었을 경우(dirty) 디스크에 반드시 쓴다.
새로 불러온 페이지는 pin count를 하나 증가시킨다. 다른 사용자가 그 페이지를 요청할 때 pin count는 하나씩 증가한다.
pin count가 0인 것들만 교체할 수 있다.

buffer replacement policy
LRU, Clock, MRU등이 쓰인다.
LRU가 항상좋은 것은 아니다.
스캔을 할 때, 버퍼풀에 10개 프레임이 있고, 스캔할 파일의 페이지 수가 11개 일때,
파일을 스캔할 때마다 모든 페이지를 디스크로부터 읽어야 하는 문제가 발생한다. (sequential flooding)

왜 OS 파일 시스템을 사용하지 않고 독자적인 파일 시스템을 사용하는가?
OS에 독립적으로 동작하기 위해서.
그리고  DB 연산들은 패턴이 있어서 다음에 어떤 페이지가 올지 예측할 수 있다. 그래서 page를 미리 불러올 수 있다. (pre-fetch)
 
Record format
레코드길이가 고정일 경우.
system catalog에 필드 사이즈 정보가 저장되어서, 이를 참조하여 특정 필드의 위치를 계산할 수 있다.
필드사이즈가 고정이 아닐 경우
필드 사이에 특별한 문자를 넣어서 필드를 구별하는 방법이 있다. 특정 필드 찾아내려면 레코드를 처음부터 읽어야 한다.
필드앞에 각 필드의 위치 정보를 담은 디렉토리를 사용하는 방법이 있다. 약간의 공간 오버헤드가 있지만 특정 필드를 찾기 쉽다.

page format
record id = <page id, slot #>
1) 레코드 길이가 고정일 때
i) 레코드들을 연속적인 slot에 모아두는 방법. 삭제될 때 마지막 slot이 삭제되는 slot으로 이동. 이동되는 레코드가 외부에서 참조될 때 문제.
ii) 비트맵을 유지하는 방법. 
2) 레코드 길이가 고정이 아닐 때
레코드 오프셋, 레코드 길이로 구성된 slot directory를 만든다. rid를 바꾸지 않고도 record들을 이동할 수 있다.

DBMS의 윗 레벨에서는 페이지와 블락을 모른다. 레코드와 레코드의 집합인 파일을 안다.

unordered(heap) file

정렬되어 있지 않은 단순한 파일 구조.
파일에 페이지가 할당되거나 해제된다.
파일내의 페이지, 페이지내의  빈공간, 페이지내의 레코드 위치를 추척할 수 있어야 한다.
i) 빈공간을 가진 페이지의 List와 레코드로 꽉 찬 리스트를 가지는 방법
ii) 디렉토리를 이용해서 힙파일을 만드는 방법.