테스트용으로 만든 10000건이 들어가있는 테이블을 조회하니 아래와 같은 결과가 나왔습니다. 아무런 인덱스가 없는 테이블이구요.
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
명령어를 주었습니다.
테이블 'TEST_T'. 검색 수 1, 논리적 읽기 수 419, 물리적 읽기 수 3, 미리 읽기 수 426, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
도움말에는
|
|
|
|
|
|
|
|
|
이렇게 되어있는데요.
그렇다면 물리적읽기수와 논리적 읽기수와는 같아야 되는거 아닌가요?
실제 테이블이 차지하고잇는 페이지는 sys.dm_db_index_physical_stats 로 확인결과 419개 페이지 입니다.
아래 링크에
글을 보면 순차미리읽기에 관한 내용입니다. 자세한 내용은 이해를 못했지만 대략 내용은 테이블 스캔같이 앞에 데이터를 당연히 읽어들어야 할때는 8K단위로 IO를 하는게 아니고 OS에서 지원하는 더큰 IO단위로 데이터를 퍼올린다. 이런 내용같습니다.
즉 위 SET STATISTICS IO ON 내용에서 최초 디스크를 단 3번의 물리적 IO를 통해서 426개의 페이지를 읽어들인후 419개 페이지에서 데이터를 조회하는가 싶습니다. 근데 도움말에는 물리적읽기수가 디스크를 읽은 페이지수 라구 해서 혼동되는군요.
정확한 물리적읽기수와 미리읽기수의 정의에 대해 알고싶습니다.
Comment 3
-
catchv
2013.06.18 12:41
-
맨즈밤
2013.06.18 13:56
답변 진심으로 감사드립니다. 최소 IO단위는 제가 잘못 알고있었네요...
계속 생기는 의문이 과연 물리적 읽기수는 과연 페이지수인가 하는것입니다. 아무리 봐도 물리적 읽기 시도횟수 같은데 말이죠.
말씀하신걸 토대로
DBCC TRACEON(652, -1)
CHECKPOINT 1
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE이렇게 총 4개 설정을 실행해두고 했습니다. 힙이나 유니크클러스터나 IO결과는 거의 같더라구요.
테이블 'CLIENT_T_HIP'. 검색 수 1, 논리적 읽기 수 419, 물리적 읽기 수 54, 미리 읽기 수 0, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
물리적 읽기수가 시도 횟수라면 54개의 익스텐트를 읽으니 54*8=432 즉 432개 페이지를 디스크에서 읽고 419개의 해당테이블의 페이지를 읽었다는 뜻으로 해석됩니다. 미리읽기를 켜고 나온 결과인테이블 'CLIENT_T_HIP'. 검색 수 1, 논리적 읽기 수 419, 물리적 읽기 수 3, 미리 읽기 수 426, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
물리적 읽기 한번에 미리읽을 페이지까지 포함한거로 보입니다. "미리 읽기를 통해서 물리적 읽기의 내용이 read 될 수 있습니다" 이게 그뜻이죠? 대략 한번 물리적읽기수에 18개의 익스텐트를 읽어들인것으로 보입니다.음냐..어렵네요...맞는지도 모르겠구.. 시간이 될때 말씀하신대로 PAGE 단위대로 추적을 해봐야 알듯싶습니다.
-
minsouk
2013.06.19 18:53
테스트로는 규정하기 힘들어요 버전마다 다르고 하드웨어 지원에 따라 틀리며 병렬처리와도 다릅니다 엔터프라이즈는 1024 페이지까지 한번에 버퍼로 올릴수 있습니다
DBCC TRACEON(652, -1) 을 이용해서 미리읽기는 꺼두고 테스트 해보세요.
미리 읽기를 통해서 물리적 읽기의 내용이 read 될 수 있습니다.
그리고 IO의 최소 단위는 Extend ( Page 8K, Extend 8K * 8) 입니다.
그리고 UNIQUE CLUSTERED INDEX를 만들어서 정확한 페이지 트리 구조를 파악하고 Page단위의 조건으로
해보시면 Logical과 Physical의 Reads 수를 계산하기 더 쉽습니다.
-- catchv