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

적용 대상:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics AnalyticsPlatform System(PDW)

이 페이지는 SQL Server의 데이터 스토리지의 기본 단위입니다. 익스텐트는 물리적으로 연속된 8페이지의 컬렉션입니다. 익스텐트에서 페이지를 효율적으로 관리할 수 있습니다. 이 가이드에서는 모든 버전의 SQL Server에서 페이지 및 익스텐트 관리에 사용되는 데이터 구조를 설명합니다. 페이지 및 익스텐트 아키텍처를 이해하는 것은 효율적으로 수행되는 데이터베이스를 디자인하고 개발하는 데 중요합니다.

페이지 및 익스텐트

SQL Server의 데이터 스토리지의 기본 단위는 페이지입니다. 데이터베이스의 데이터 파일(.mdf 또는 .ndf)에 할당된 디스크 공간은 논리적으로 0 에서 n까지 연속적으로 번호가 매겨진 페이지로 나뉩니다. 디스크 I/O 작업은 페이지 수준에서 수행됩니다. 즉, SQL Server는 전체 데이터 페이지를 읽거나 씁니다.

익스텐트는 실제로 연속하는 8페이지를 모은 것으로 페이지를 효율적으로 관리하는 데 사용됩니다. 모든 페이지는 범위로 구성됩니다.

페이지

일반 책에서 모든 콘텐츠는 페이지에 기록됩니다. 책과 마찬가지로 SQL Server는 페이지에 모든 데이터 행을 쓰고 모든 데이터 페이지는 크기가 8KB입니다. 책에서 대부분의 페이지에는 책의 기본 콘텐츠인 데이터가 포함되며 일부 페이지에는 콘텐츠에 대한 메타데이터(예: 목차 및 인덱스)가 포함됩니다. SQL Server도 다르지 않습니다. 대부분의 페이지에는 사용자가 저장한 실제 데이터 행이 포함됩니다. 이를 데이터 페이지 및 텍스트/이미지 페이지라고 합니다(특수한 경우). 인덱스 페이지에는 데이터가 있는 위치에 대한 인덱스 참조가 포함되어 있습니다. 마지막으로 데이터 구성에 대한 다양한 메타데이터를 저장하는 시스템 페이지 가 있습니다.

각 페이지는 96바이트 머리글로 시작하는데 이 머리글은 페이지에 대한 시스템 정보를 저장하는 데 사용됩니다. 페이지 번호, 페이지 유형, 해당 페이지의 사용 가능한 공간 크기 그리고 해당 페이지를 소유하고 있는 개체의 할당 단위 ID와 같은 정보를 저장합니다.

다음 표에서는 SQL Server 데이터베이스의 데이터 파일에 사용되는 페이지 형식을 보여줍니다.

페이지 유형	콘텐츠
데이터	행의 텍스트가 ON으로 설정된 경우 텍스트, ntext, image, nvarchar(max), varchar(max), varbinary(max) 및 xml 데이터를 제외한 모든 데이터가 있는 데이터 행입니다.
Index	인덱스 항목입니다.
텍스트/이미지	큰 개체 데이터 형식: text, ntext, image, nvarchar(max), varchar(max), varbinary(max) 및 xml 데이터입니다. 데이터 행이 8KB(varchar, nvarchar, varbinary 및 sql_variant)를 초과하는 경우의 가변 길이 열입니다.
전역 할당 맵(GAM) SGAM(공유 전역 할당 맵)	익스텐트가 할당되었는지 여부에 대한 정보
PFS(페이지 사용 가능한 공간)	페이지에서 사용할 수 있는 페이지 할당 및 사용 가능한 공간에 대한 정보입니다.
인덱스 할당 맵(IAM)	할당 단위당 테이블 또는 인덱스에 사용되는 익스텐트 정보입니다.
BCM(대량 변경 맵)	할당 단위당 마지막 BACKUP LOG 문 이후 대량 작업으로 수정된 익스텐트 정보입니다.
DCM(차등 변경 맵)	할당 단위당 마지막 BACKUP DATABASE 문 이후 변경된 익스텐트 정보입니다.

참고 항목

로그 파일에는 페이지가 없습니다. 고정 크기가 없는 일련의 로그 레코드가 포함됩니다.

데이터 행은 머리글 바로 뒤부터 페이지에 직렬로 저장됩니다. 행 오프셋 테이블은 페이지 끝에서 시작하는데 각 행 오프셋 테이블에는 해당 페이지에 있는 각 행에 대한 항목이 하나씩 있습니다. 각 행 오프셋 항목은 페이지 시작부터 행의 첫 번째 바이트가 얼마나 멀리 떨어져 있는지를 저장합니다. 따라서 행 오프셋 테이블의 함수는 SQL Server가 페이지에서 행을 빠르게 찾을 수 있도록 하는 것입니다. 행 오프셋 테이블의 항목은 페이지의 행 시퀀스에서 역순으로 표시됩니다.

큰 행 지원

행은 페이지에 걸쳐 있지 않습니다. 그러나 행의 일부가 행의 페이지에서 이동될 수 있으므로 행이 매우 클 수 있습니다. 페이지의 단일 행에 포함된 데이터 및 오버헤드의 최대 크기는 8,060바이트입니다. 텍스트/이미지 페이지 형식에 저장된 데이터는 포함되지 않습니다.

이 제한은 varchar, nvarchar, varbinary 또는 sql_variant 열을 포함하는 테이블에 대해 완화됩니다. 테이블에 있는 모든 고정 열과 변수 열의 총 행 크기가 8,060 바이트 제한을 초과하면 SQL Server는 너비가 가장 큰 열부터 시작하여 하나 이상의 가변 길이 열을 ROW_OVERFLOW_DATA 할당 단위의 페이지로 동적으로 이동합니다.

이 작업은 삽입 또는 업데이트 작업으로 행의 총 크기가 8,060 바이트 제한을 초과할 때마다 수행됩니다. 열이 ROW_OVERFLOW_DATA 할당 단위의 페이지로 이동하면 IN_ROW_DATA 할당 단위에 있는 원래 페이지의 24바이트 포인터가 그대로 유지됩니다. 후속 작업으로 행 크기가 줄어들면 SQL Server는 열을 원래 데이터 페이지로 동적으로 다시 이동합니다.

행 오버플로 고려 사항

행은 여러 페이지에 상주할 수 없으며 가변 길이 데이터 형식 필드의 결합된 크기가 8060 바이트 제한을 초과하는 경우 오버플로할 수 있습니다. 이를 설명하기 위해 varchar(7000)와 다른 varchar(2000)의 두 열로 테이블을 만들 수 있습니다. 개별적으로 두 열 모두 8060바이트를 초과하지는 않지만 각 열의 전체 너비가 채워지면 이 작업을 수행할 수 있습니다. SQL Server는 varchar(7000) 가변 길이 열을 ROW_OVERFLOW_DATA 할당 단위의 페이지로 동적으로 이동할 수 있습니다. 행당 8,060바이트를 초과하는 varchar, nvarchar, varbinary 또는 sql_variant 또는 CLR 사용자 정의 형식 열을 결합하는 경우 다음을 고려합니다.

• 큰 레코드를 다른 페이지로 이동하는 작업은 업데이트 작업에 따라 레코드가 길어짐에 따라 동적으로 발생합니다. 업데이트 작업에 따라 레코드가 짧아지는 경우 해당 레코드는 IN_ROW_DATA 할당 단위에 있는 원래 페이지로 다시 이동할 수도 있습니다.

  행 오버플로 데이터가 포함된 큰 레코드의 정렬 또는 조인과 같은 다른 선택 작업을 쿼리하고 수행하면 이러한 레코드가 비동기적으로 처리되지 않고 동기적으로 처리되므로 처리 시간이 느려집니다.

  따라서 여러 varchar, nvarchar, varbinary 또는 sql_variant 또는 CLR 사용자 정의 형식 열이 있는 테이블을 디자인할 때 흐름 가능성이 있는 행의 비율과 이 오버플로 데이터를 쿼리할 가능성이 있는 빈도를 고려합니다. 행 오버플로 데이터의 여러 행에 대한 쿼리가 자주 발생하는 경우 일부 열이 다른 테이블로 이동되도록 테이블을 정규화하는 것이 좋습니다. 그런 다음 비동기 JOIN 작업에서 쿼리할 수 있습니다.

• 개별 열의 길이는 varchar, nvarchar, varbinary 또는 sql_variant 및 CLR 사용자 정의 형식 열의 경우 여전히 8,000바이트 이내여야 합니다. 결합된 길이만 테이블의 8,060 바이트 행 제한을 초과할 수 있습니다.

• char 및 nchar 데이터를 포함한 다른 데이터 형식 열의 합계는 8,060 바이트 행 제한에 속해야 합니다. 큰 개체 데이터도 8,060 바이트 행 제한에서 제외됩니다.

• 클러스터형 인덱스의 인덱스 키는 ROW_OVERFLOW_DATA 할당 단위에 기존 데이터가 있는 varchar 열을 포함할 수 없습니다. varchar 열에 대한 클러스터형 인덱스를 만들고 기존 데이터가 IN_ROW_DATA 할당 단위에 있는 경우에는 데이터를 행 외부로 밀어넣는 열에 대한 후속 삽입 또는 업데이트 동작이 실패합니다. 할당 단위에 대한 자세한 내용은 인덱스 아키텍처 및 디자인 가이드를 참조 하세요.

• 행 오버플로 데이터가 있는 열을 비클러스터형 인덱스의 키 열이나 키가 아닌 열로 포함할 수 있습니다.

• 스파스 열을 사용하는 테이블의 레코드 크기 제한은 8,018바이트입니다. 변환된 데이터와 기존 레코드 데이터가 8,018바이트를 초과하면 MSSQLSERVER 오류 576 이 반환됩니다. 스파스와 비파스 형식 간에 열이 변환되면 데이터베이스 엔진은 현재 레코드 데이터의 복사본을 유지합니다. 그러면 레코드에 필요한 스토리지가 일시적으로 두 배가 됩니다.

• 행 오버플로 데이터가 포함될 수 있는 테이블이나 인덱스에 대한 정보를 얻으려면 sys.dm_db_index_physical_stats 동적 관리 함수를 사용합니다.

Extents

익스텐트는 공간 관리의 기본 단위입니다. 익스텐트는 물리적으로 인접한 8개 페이지 또는 64KB입니다. 즉, SQL Server 데이터베이스에는 메가바이트당 16개의 익스텐트가 있습니다.

SQL Server에는 다음 두 가지 유형의 익스텐트 유형이 있습니다.

• 균일 한 익스텐트에서는 단일 개체가 소유하며, 익스텐트 내의 8페이지는 모두 소유 개체에서만 사용할 수 있습니다.
• 혼합 익스텐트까지 최대 8개의 개체가 공유합니다. 익스텐트 내의 8개 페이지는 각각 다른 개체가 소유할 수 있습니다.

SQL Server 2014(12.x)까지 데이터베이스 엔진은 적은 양의 데이터가 있는 테이블에 전체 범위를 할당하지 않습니다. 새 테이블 또는 인덱스는 일반적으로 혼합 익스텐트에서 페이지를 할당합니다. 테이블 또는 인덱스가 8페이지가 있는 지점까지 증가하면 이후 할당에 균일한 익스텐트 사용을 전환합니다. 인덱스에 8페이지를 생성하기에 충분한 행이 있는 기존 테이블에 인덱스를 만드는 경우 인덱스에 대한 모든 할당은 균일한 범위에 있습니다.

SQL Server 2016(13.x)부터 사용자 데이터베이스의 대부분의 할당에 대한 기본값이며 tempdb IAM 체인의 처음 8페이지에 속하는 할당을 제외하고 균일한 익스텐트를 사용하는 것입니다. 및 msdbmodel 데이터베이스에 대한 master할당은 여전히 이전 동작을 유지합니다.

참고 항목

SQL Server 2014(12.x)까지 SQL Server에서 TF(추적 플래그) 1118을 사용하여 항상 균일한 익스텐트 사용을 위해 기본 할당을 변경할 수 있습니다. 이 추적 플래그에 대한 자세한 내용은 DBCC TRACEON - 추적 플래그를 참조 하세요.

SQL Server 2016(13.x)부터 TF 1118에서 제공하는 기능은 모든 사용자 데이터베이스에 tempdb 대해 자동으로 사용하도록 설정됩니다. 사용자 데이터베이스의 경우 이 동작은 기본값이 OFF로 설정된 옵션ALTER DATABASE에 의해 SET MIXED_PAGE_ALLOCATION 제어되며 TF 1118은 효과가 없습니다. 자세한 내용은 ALTER DATABASE SET 옵션(Transact-SQL)을 참조하세요.

SQL Server 2012(11.x) sys.dm_db_database_page_allocations 부터 시스템 함수는 데이터베이스, 테이블, 인덱스 및 파티션에 대한 페이지 할당 정보를 보고할 수 있습니다.

Important

sys.dm_db_database_page_allocations 시스템 함수는 문서화되지 않으며 변경될 수 있습니다. 호환성은 보장되지 않습니다.

SQL Server 2019(15.x) 부터 sys.dm_db_page_info 시스템 함수를 사용할 수 있으며 데이터베이스의 페이지에 대한 정보를 반환합니다. 이 함수는 페이지의 머리글 정보를 포함하는 행 1개(예: 및 index_id.)를 object_id반환합니다partition_id. 이 함수는 대부분의 경우 사용 DBCC PAGE 필요성을 대체합니다.

익스텐트 할당 및 여유 공간 관리

익스텐트 할당을 관리하고 사용 가능한 공간을 추적하는 SQL Server 데이터 구조에는 비교적 간단한 구조가 있습니다. 이 경우 다음과 같은 이점이 있습니다.

• 빈 공간 정보는 빽빽하게 묶여 있으므로 이 정보를 포함하는 페이지의 수는 비교적 적습니다.

  이렇게 하면 할당 정보를 검색하는 데 필요한 디스크 읽기 수를 줄여 속도를 높입니다. 이렇게 하면 할당 페이지가 메모리에 남아 있고 더 많은 읽기가 필요하지 않을 가능성이 높아질 수 있습니다.

• 대부분의 할당 정보는 함께 연결되지 않습니다. 유지 관리가 간편합니다.

  각 페이지 할당 또는 할당 취소 작업을 신속하게 수행할 수 있으므로 이렇게 하면 페이지를 할당하거나 할당 취소해야 하는 동시 작업 간의 경합이 줄어듭니다.

익스텐트 할당 관리

SQL Server는 두 가지 유형의 할당 맵을 사용하여 익스텐트 할당을 기록합니다.

• GAM(전역 할당 맵)

  GAM 페이지는 할당된 범위를 기록합니다. 각 GAM은 64,000개의 익스텐트 또는 거의 4GB(기가비트)의 데이터를 처리합니다. GAM에는 각 익스텐트 간격에 대해 1비트가 있습니다. 비트가 1면 익스텐트가 무료이고, 비트가 0있으면 익스텐트가 할당됩니다.

• SGAM(공유 전역 할당 맵)

  SGAM 페이지는 현재 혼합 익스텐트로 사용 중인 익스텐트도 기록하며 하나 이상의 사용되지 않은 페이지가 있습니다. 각 SGAM은 64,000개의 익스텐트 또는 거의 4GB의 데이터를 처리합니다. SGAM에는 포함하는 간격의 각 익스텐트당 1비트가 있습니다. 비트인 1경우 익스텐트는 혼합 익스텐트로 사용되며 사용 가능한 페이지가 있습니다. 비트인 0경우 익스텐트가 혼합 익스텐트로 사용되지 않거나 혼합 익스텐트이며 모든 페이지가 사용되고 있습니다.

각 익스텐트는 현재 사용 상태에 기반하여 GAM 및 SGAM에 설정된 다음의 비트 패턴을 갖습니다.

현재 익스텐트 사용	GAM 비트 설정	SGAM 비트 설정
비어 있음, 사용 중이지 않음	1	0
균일한 익스텐트 또는 전체 혼합 익스텐트	0	0
사용 가능한 페이지가 있는 혼합 익스텐트	0	1

이러한 복잡함 때문에 단순한 익스텐트 관리 알고리즘의 필요성이 부각되었습니다.

• 균일한 익스텐트를 할당하기 위해 데이터베이스 엔진은 GAM에서 비트를 1 검색하여 설정합니다 0.
• 사용 가능한 페이지가 있는 혼합 익스텐트를 찾기 위해 데이터베이스 엔진은 SGAM을 약간 검색합니다 1 .
• 혼합 익스텐트를 할당하기 위해 데이터베이스 엔진은 GAM에서 비트를 1 검색하고 이를 설정하며 0SGAM 1의 해당 비트를 설정합니다.
• 익스텐트를 할당 취소하기 위해 데이터베이스 엔진은 GAM 비트가 설정 1되고 SGAM 비트가 로 설정되어 있는지 확인합니다 0.

데이터베이스 엔진이 데이터베이스에 데이터를 균등하게 분산하기 때문에 데이터베이스 엔진에서 내부적으로 사용하는 알고리즘은 이 문서에 설명된 것보다 더 정교합니다. 그러나 익스텐트 할당 정보의 체인을 관리할 필요가 없으므로 실제 알고리즘도 간소화됩니다.

사용 가능한 공간 추적

PFS(페이지 사용 가능한 공간) 페이지는 각 페이지의 할당 상태, 개별 페이지 할당 여부 및 각 페이지의 여유 공간 양을 기록합니다. PFS는 각 페이지에 대해 1 바이트를 가지며, 페이지가 할당되었는지 여부를 기록하고, 비어 있는지 여부, 1~50% 전체, 51~80% 전체, 81~95% 전체 또는 96~100% 가득 찼습니다.

개체에 익스텐트를 할당한 후 데이터베이스 엔진은 PFS 페이지를 사용하여 할당되거나 무료인 페이지를 기록합니다. 이 정보는 데이터베이스 엔진에서 새 페이지를 할당해야 하는 경우에 사용됩니다. 페이지의 여유 공간 크기는 힙 및 텍스트/이미지 페이지에 대해서만 유지 관리됩니다. 데이터베이스 엔진이 새로 삽입된 행을 저장할 수 있는 여유 공간이 있는 페이지를 찾아야 하는 경우에 사용됩니다. 인덱스는 새 행을 삽입할 지점이 인덱스 키 값에 의해 설정되므로 페이지 사용 가능한 공간을 추적할 필요가 없습니다.

추적되는 모든 추가 범위에 대해 데이터 파일에 새 PFS, GAM 또는 SGAM 페이지가 추가됩니다. 따라서 첫 번째 PFS 페이지 뒤에 8,088페이지의 새 PFS 페이지가 있고, 그다음에는 8,088페이지 간격으로 추가 PFS 페이지가 나옵니다. 즉, 페이지 ID 1이 PFS 페이지이고, 페이지 ID 8088이 PFS 페이지이며, 페이지 ID 16176이 PFS 페이지입니다.

첫 번째 GAM 페이지 다음에 새로운 GAM 페이지 64,000 익스텐트가 있으며 그 다음 64,000 익스텐트를 추적합니다. 시퀀스는 64,000 익스텐트 간격으로 계속됩니다. 마찬가지로 첫 번째 SGAM 페이지 이후의 새 SGAM 페이지 64,000 익스텐트 및 후속 64,000 익스텐트 간격의 추가 SGAM 페이지가 있습니다.

다음 그림은 익스텐트 할당 및 관리를 위해 데이터베이스 엔진에서 사용하는 페이지 순서를 보여 줍니다.

개체에서 사용하는 공간 관리

IAM(인덱스 할당 맵) 페이지는 할당 단위에서 사용하는 데이터베이스 파일의 4GB 부분에 있는 익스텐트를 매핑합니다. 할당 단위의 유형은 다음 3가지가 있습니다.

• In_row_data

  힙 또는 인덱스의 파티션을 보유합니다.

• LOB_DATA

  xml, varbinary(max) 및 varchar(max)와 같은 LOB(큰 개체) 데이터 형식을 보유합니다.

• ROW_OVERFLOW_DATA

  8,060바이트 행 크기 제한을 초과하는 varchar, nvarchar, varbinary 또는 sql_variant 열에 저장된 가변 길이 데이터를 보유합니다.

힙 또는 인덱스의 각 파티션에는 적어도 하나의 IN_ROW_DATA 할당 단위가 있습니다. 또한 힙 또는 인덱스 스키마에 따라 LOB_DATA 또는 ROW_OVERFLOW_DATA 할당 단위도 포함될 수 있습니다.

IAM 페이지는 파일에서 4GB 범위를 처리하며 이는 GAM 또는 SGAM 페이지와 동일합니다. 할당 단위에 둘 이상의 파일 또는 둘 이상의 4GB 범위 파일의 익스텐트를 포함하는 경우 IAM 체인에 여러 IAM 페이지가 연결됩니다. 따라서 각 할당 단위에는 익스텐스가 있는 각 파일에 대해 하나 이상의 IAM 페이지가 있습니다. 할당 단위에 할당된 파일의 익스텐트 범위가 단일 IAM 페이지가 기록할 수 있는 범위를 초과하는 경우 파일에 둘 이상의 IAM 페이지가 있을 수도 있습니다.

IAM 페이지는 각 할당 단위에 필요한 대로 할당되며 파일에 임의로 배치됩니다. sys.system_internals_allocation_units 시스템 뷰는 할당 단위의 첫 번째 IAM 페이지를 가리킵니다. 해당 할당 단위의 모든 IAM 페이지는 IAM 체인에 연결됩니다.

Important

시스템 뷰는 sys.system_internals_allocation_units 내부용으로만 사용되며 변경될 수 있습니다. 호환성은 보장되지 않습니다. 이 보기는 Azure SQL Database에서 사용할 수 없습니다.

IAM 페이지에는 IAM 페이지에서 매핑된 익스텐트 범위의 시작 범위를 나타내는 헤더가 있습니다. 또한 IAM 페이지는 각 비트가 하나의 익스텐트를 나타내는 대형 비트맵을 갖습니다. 맵의 첫째 비트는 범위의 첫째 익스텐트를 나타내고 둘째 비트는 둘째 익스텐트를 나타냅니다. 비트인 경우 나타내는 범위는 0IAM을 소유하는 할당 단위에 할당되지 않습니다. 비트인 1경우 나타내는 범위는 IAM 페이지를 소유하는 할당 단위에 할당됩니다.

데이터베이스 엔진이 새 행을 삽입해야 하고 현재 페이지에서 사용할 수 있는 공간이 없는 경우 IAM 및 PFS 페이지를 사용하여 할당할 페이지를 찾거나, 힙 또는 텍스트/이미지 페이지의 경우 행을 저장할 충분한 공간이 있는 페이지를 찾습니다. 데이터베이스 엔진은 IAM 페이지를 사용하여 할당 단위에 할당된 익스텐스를 찾습니다. 각 익스텐트마다 데이터베이스 엔진은 PFS 페이지를 검색하여 사용할 수 있는 페이지가 있는지 확인합니다. 각 IAM 및 PFS 페이지에는 많은 데이터 페이지가 포함되어 있으므로 데이터베이스에는 IAM 및 PFS 페이지가 거의 없습니다. 즉, IAM 및 PFS 페이지는 일반적으로 SQL Server 버퍼 풀의 메모리에 있으므로 신속하게 검색할 수 있습니다. 인덱스의 경우 새 행의 삽입 지점은 인덱스 키에 의해 설정되지만 새 페이지가 필요한 경우 이전에 설명한 프로세스가 발생합니다.

데이터베이스 엔진은 삽입할 행을 저장할 충분한 공간이 있는 기존 익스텐트에서 페이지를 빠르게 찾을 수 없는 경우에만 할당 단위에 새 익스텐트를 할당합니다.

비례 채우기 할당

데이터베이스 엔진은 비례 채우기 할당 알고리즘을 사용하여 파일 그룹에서 사용할 수 있는 익스텐트를 할당 합니다. 두 개의 파일이 있는 동일한 파일 그룹에서 한 파일의 여유 공간이 다른 파일과 두 배인 경우 파일에서 두 페이지가 할당되고 다른 파일에서 할당된 모든 페이지에 대해 사용 가능한 공간이 할당됩니다. 즉, 파일 그룹의 모든 파일은 비슷한 비율의 공간을 사용해야 합니다.

수정된 익스텐트 추적

SQL Server는 두 개의 내부 데이터 구조를 사용하여 대량 복사 작업으로 수정된 익스텐트와 마지막 전체 백업 이후 수정된 익스텐트 추적을 수행합니다. 이러한 데이터 구조는 차등 백업 속도를 크게 향상합니다. 또한 데이터베이스가 대량 로그 복구 모델을 사용하는 경우 대량 복사 작업의 로깅 속도를 향상합니다. GAM 및 SGAM 페이지와 마찬가지로 이러한 구조체는 각 비트가 단일 익스텐트를 나타내는 비트맵입니다.

• DCM(차등 변경 맵)

  마지막 BACKUP DATABASE 문 이후에 변경된 익스텐트를 추적합니다. 익스텐트 비트인 1경우 익스텐트는 마지막 BACKUP DATABASE 문 이후 수정되었습니다. 비트인 0경우 익스텐트가 수정되지 않았습니다.

  차등 백업은 DCM 페이지만 읽고 수정된 익스텐트만 확인합니다. 이렇게 하면 차등 백업에서 검색해야 하는 페이지 수가 크게 줄어듭니다. 차등 백업이 실행되는 시간은 데이터베이스의 전체 크기가 아니라 마지막 BACKUP DATABASE 문 이후 수정된 익스텐트 수에 비례합니다.

• BCM(대량 변경 맵)

  이는 마지막 BACKUP LOG 문 이후 대량 로그 작업에 의해 수정된 범위를 추적합니다. 익스텐트 비트인 1경우 익스텐트는 마지막 BACKUP LOG 문 이후의 대량 로그 작업에 의해 수정되었습니다. 비트인 0경우 대량 로그 작업으로 익스텐트가 수정되지 않았습니다.

  BCM 페이지는 모든 데이터베이스에 표시되지만 데이터베이스가 대량 로그 복구 모델을 사용하는 경우에만 관련이 있습니다. 이 복구 모델 BACKUP LOG 에서 수행되는 경우 백업 프로세스는 BCM에서 수정된 익스텐트를 검색합니다. 이런 익스텐트를 로그 백업에 포함시킵니다. 데이터베이스 백업 및 트랜잭션 로그 백업 시퀀스에서 데이터베이스를 복원하는 경우 대량 로그 작업을 복구합니다. 대량 로그 작업이 기록되지 않으므로 BCM 페이지는 단순 복구 모델을 사용하는 데이터베이스에서 관련이 없습니다. 복구 모델은 대량 로그 작업을 완전히 기록된 작업으로 처리하므로 전체 복구 모델을 사용하는 데이터베이스에서는 관련이 없습니다.

DCM 페이지와 BCM 페이지 사이의 간격은 GAM 페이지와 SGAM 페이지 사이의 간격(64,000개 익스텐트)과 동일합니다. DCM 및 BCM 페이지는 다음과 같이 물리적 파일의 GAM 및 SGAM 페이지 뒤에 있습니다.

참고 항목

• sys.allocation_units(Transact-SQL)
• 힙(클러스터형 인덱스가 없는 테이블)
• sys.dm_db_page_info
• 페이지 읽기
• 페이지 쓰기