고유 한 클러스터 된 인덱스가있는 테이블이 있다고 가정합니다. 인덱스 키 값을 사용하여 해당 테이블의 행을 쿼리합니다. SQL Server는 관련 데이터 페이지를 찾기 위해 인덱스 찾기를 사용합니다.SQL Server는 특정 범위에 할당 된 디스크 클러스터를 어떻게 알 수 있습니까?
그러나 SQL Server는 file_id : page_id를 가진 후 물리적 디스크에서 이러한 데이터 페이지를 어떻게 읽습니까? 디스크 섹터/클러스터의 위치를 어떻게 알 수 있습니까?
SQL Server는 디스크 섹터/클러스터를 처리하지 않습니다. 논리적으로 pages (8Kb)로 나누어 진 files에서 읽습니다. Extent은 8 연속 페이지입니다.
모든 테이블에는이 테이블에 할당 된 모든 범위가 나열된 IAM 페이지가 있습니다. 비트 맵 페이지는 비트 맵 페이지로 1은 익스텐트가 0을 의미하는 객체에 할당되었음을 나타냅니다.
SQL Server는 첫 번째 IAM 페이지에 대한 내부 포인터와 힙의 첫 번째 데이터 페이지 인 을 유지 관리합니다. 이러한 포인터는 시스템보기 sys.system_internals_allocation_units에서 찾을 수 있습니다.
클러스터 된 인덱스의 경우 모든 데이터는 평소대로 페이지에 저장되며 IAM 페이지를 사용하여 읽을 수 있지만 인덱스 인 binary tree을 사용하여 "정렬 된"방식으로 액세스 할 수도 있습니다.
이는 데이터 (인덱스 리프 페이지) 서버가 페이지로 구성되는 추가 검색 구조를 빌드 함을 의미하며, 루트 페이지는 클러스터 된 인덱스 키의 기본 인덱스 수준을 낮추도록 지시합니다.
결론 : 인덱스 페이지에 제시된 모든 주소는 클러스터/섹터가 아닌 file_id:page_id으로 구성됩니다.
감사합니다. 나는 인덱스 페이지에 제시된 모든 주소가 file_id : page_id로 구성된다는 사실에 전적으로 동의했습니다. 그러나 file_id와 page_id는 모두 SQL OS에서 내부적으로 사용됩니다. 물리 디스크의 할당 단위는 섹터 또는 클러스터입니다. SQL 확장 또는 SQL 데이터 페이지가 물리적으로 디스크 섹터 또는 클러스터에 저장됩니다. 데이터 페이지를 읽으려면 SQL은 해당 페이지를 저장하는 클러스터를 알아야합니다. –
절대적으로 아니오, 파일을 클러스터/섹터로 변환하는 것은 OS (Windows)입니다. Windows 응용 프로그램 중 어느 것도 directlly 않습니다. 내부 코드는 항상 Windows API 함수를 사용합니다. SQL Server는 어셈블러가 아닌 C로 작성되었습니다. – sepupic
C에서 파일을 읽는 간단한 프로그램을 작성한 적이 있습니까? 특정 오프셋에서 읽을 수 있지만 실제로 섹터에 해당하는 섹터를 볼 수는 없습니다. 해당 기능에 전달하는 파일 경로/이름 및 오프셋은 모두 – sepupic