페이지 및 익스텐트 아키텍처 가이드
적용 대상: 
SQL Server Azure SQL 데이터베이스 Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform 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 데이터베이스의 데이터 파일에서 사용되는 페이지 유형을 보여 줍니다.
| 페이지 유형 | 콘텐츠 |
|---|---|
| 데이터 | 행의 text가 ON으로 설정된 경우 text, ntext, image, nvarchar(max), varchar(max), varbinary(max) 및 xml 데이터를 제외한 모든 데이터가 있는 데이터 행입니다. |
| 인덱스 | 인덱스 항목입니다. |
| 텍스트/이미지 | 큰 개체 데이터 형식, 즉 text, ntext, image, nvarchar(max), varchar(max), varbinary(max) 및 xml입니다. 데이터 행이 8KB를 초과하는 경우의 가변 길이 열(varchar, nvarchar, varbinary 및 sql_variant)입니다. |
| GAM(Global Allocation Map) SGAM(Shared Global Allocation Map) |
익스텐트가 할당되었는지 여부에 대한 정보 |
| PFS(페이지 사용 가능한 공간) | 페이지에서 사용할 수 있는 페이지 할당 및 사용 가능한 공간에 대한 정보입니다. |
| IAM(Index Allocation Map) | 할당 단위당 테이블 또는 인덱스에 사용되는 익스텐트에 대한 정보입니다. |
| BCM(Bulk Changed Map) | 할당 단위당 마지막 BACKUP LOG 문 이후 대량 작업으로 수정된 익스텐트에 대한 정보입니다. |
| DCM(Differential Changed Map) | 할당 단위당 마지막 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는 열을 원래 데이터 페이지로 동적으로 다시 변경합니다.
행 오버플로 고려 사항
행은 여러 페이지에 상주할 수 없으며, 가변 길이 데이터 형식 필드의 결합된 크기가 8,060바이트 한도를 초과할 경우 오버플로가 발생할 수 있습니다. 이를 설명하기 위해 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 할당 단위에 있는 경우에는 데이터를 행 외부로 밀어넣는 열에 대한 후속 삽입 또는 업데이트 동작이 실패합니다. 할당 단위에 대한 자세한 내용은 SQL Server 및 Azure SQL 인덱스 아키텍처 및 디자인 가이드를 참조하세요.
행 오버플로 데이터가 있는 열을 비클러스터형 인덱스의 키 열이나 키가 아닌 열로 포함할 수 있습니다.
스파스 열을 사용하는 테이블의 레코드 크기 제한은 8,018바이트입니다. 변환된 데이터와 기존 레코드 데이터가 8,018바이트를 초과하면 MSSQLSERVER ERROR 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페이지에 속하는 할당을 제외하고 균일한 익스텐트를 사용하는 것입니다. master, msdb 및 model 데이터베이스의 할당은 여전히 이전 동작을 유지합니다.
참고 항목
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 옵션을 참조하세요.
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 시스템 함수를 사용할 수 있으며 이 함수는 데이터베이스의 페이지에 대한 정보를 반환합니다. 이 함수는 object_id, index_id, partition_id를 포함하여 페이지의 헤더 정보를 포함하는 하나의 행을 반환합니다. 대부분의 경우 이 함수를 사용하면 DBCC PAGE를 사용할 필요가 없습니다.
익스텐트 할당 및 사용 가능한 공간 관리
익스텐트 할당을 관리하고 빈 공간을 추적하는 SQL Server 데이터 구조는 비교적 단순합니다. 이 경우 다음과 같은 이점이 있습니다.
빈 공간 정보는 빽빽하게 묶여 있으므로 이 정보를 포함하는 페이지의 수는 비교적 적습니다.
이렇게 하면 할당 정보를 검색하는 데 필요한 디스크 읽기 수가 줄어들어 속도가 높아집니다. 이렇게 하면 할당 페이지가 메모리에 남아 있고 더 많은 읽기가 필요하지 않을 가능성이 높아집니다.
대부분의 할당 정보는 서로 연결되어 있지 않으므로 유지 관리가 간편합니다.
각 페이지 할당 또는 할당 취소 작업을 신속하게 수행할 수 있으므로 이렇게 하면 페이지를 할당하거나 할당 취소해야 하는 동시 작업 간의 경합이 줄어듭니다.
익스텐트 할당 관리
SQL Server는 다음의 두 가지 형식의 할당 맵을 사용하여 익스텐트의 할당을 기록합니다.
GAM(Global Allocation Map)
GAM 페이지는 할당된 범위를 기록합니다. 각 GAM은 64,000개의 익스텐트 또는 거의 4GB(기가비트)의 데이터를 처리합니다. GAM은 처리 간격으로 각 익스텐트에 대해 1비트를 갖습니다. 비트가
1이면 익스텐트가 사용 가능한 상태이고, 비트가0이면 익스텐트가 할당된 상태입니다.SGAM(Shared Global Allocation Map)
SGAM 페이지는 현재 혼합 익스텐트로 사용 중인 익스텐트도 기록하며, 하나 이상의 사용되지 않은 페이지도 있습니다. 각 SGAM은 64,000개의 익스텐트 또는 거의 4GB의 데이터를 처리합니다. SGAM은 처리 간격으로 각 익스텐트에 대해 1비트를 갖습니다. 이 비트가
1인 경우 익스텐트가 혼합 익스텐트로 사용되고 있고 빈 페이지를 가지고 있는 상태입니다. 이 비트가0인 경우 익스텐트가 혼합 익스텐트로 사용되지 않거나, 혼합 익스텐트이고 모든 페이지가 사용되는 상태입니다.
각 익스텐트는 현재 사용 상태에 기반하여 GAM 및 SGAM에 설정된 다음의 비트 패턴을 갖습니다.
| 현재 익스텐트 사용 | GAM 비트 설정 | SGAM 비트 설정 |
|---|---|---|
| 비어 있음, 사용 중이지 않음 | 1 | 0 |
| 균일한 익스텐트 또는 전체 혼합 익스텐트 | 0 | 0 |
| 사용 가능한 페이지가 있는 혼합 익스텐트 | 0 | 1 |
이러한 복잡함 때문에 단순한 익스텐트 관리 알고리즘의 필요성이 부각되었습니다.
- 데이터베이스 엔진은 단일 익스텐트를 할당하기 위해
1비트에 해당하는 GAM을 검색하고 이를0으로 설정합니다. - 사용 가능한 페이지가 있는 혼합 익스텐트를 찾기 위해 데이터베이스 엔진은 SGAM에서
1비트를 검색합니다. - 데이터베이스 엔진은 혼합 익스텐트를 할당하기 위해
1비트에 해당하는 GAM을 검색하고 이를0으로 설정한 다음 SGAM의 해당 비트를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(Index Allocation Map) 페이지는 할당 단위에 사용되는 데이터베이스 파일의 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 페이지는 각 비트가 하나의 익스텐트를 나타내는 대형 비트맵을 갖습니다. 맵의 첫째 비트는 범위의 첫째 익스텐트를 나타내고 둘째 비트는 둘째 익스텐트를 나타냅니다. 비트가 0인 경우 해당 익스텐트는 IAM을 소유하는 할당 단위에 할당되지 않은 것입니다. 비트가 1인 경우 해당 익스텐트는 IAM 페이지를 소유하는 할당 단위에 할당된 것입니다.
데이터베이스 엔진이 새 행을 삽입해야 하고 현재 페이지에서 사용할 수 있는 공간이 없는 경우, IAM 및 PFS 페이지를 사용하여 할당할 페이지를 찾거나 힙 또는 텍스트/이미지 페이지의 경우 행을 저장할 충분한 공간이 있는 페이지를 찾습니다. 데이터베이스 엔진은 IAM 페이지를 사용하여 할당 단위에 할당된 익스텐트를 찾습니다. 데이터베이스 엔진은 각 익스텐트마다 PFS 페이지를 검색하여 사용할 수 있는 페이지가 있는지 확인합니다. 각 IAM 및 PFS 페이지는 많은 수의 데이터 페이지를 포함하므로 데이터베이스에는 IAM 및 PFS 페이지가 거의 없습니다. IAM 및 PFS 페이지는 일반적으로 SQL Server 버퍼 풀의 메모리에 있으므로 신속하게 검색할 수 있습니다. 인덱스의 경우 새 행의 삽입 지점은 인덱스 키에 의해 설정되지만, 새 페이지가 필요한 경우 이전에 설명한 프로세스가 발생합니다.
데이터베이스 엔진은 삽입되는 행을 보관하기에 충분한 공간을 가진 기존 익스텐트에서 페이지를 빠르게 찾을 수 없을 때만 할당 단위에 새 익스텐트를 할당합니다.
비례 채우기 할당
데이터베이스 엔진은 비례 채우기 할당 알고리즘을 사용하여 파일 그룹에서 사용할 수 있는 파일의 익스텐트를 할당합니다. 두 개의 파일이 있는 동일한 파일 그룹에서 한 파일의 사용 가능한 공간이 다른 파일의 두 배인 경우, 한 파일에서 두 페이지가 할당되고 다른 파일에서 할당된 모든 페이지에 대해 사용 가능한 공간이 할당됩니다. 즉, 파일 그룹의 모든 파일이 비슷한 비율의 공간을 사용하게 됩니다.
수정된 익스텐트 추적
SQL Server에서는 두 개의 내부 데이터 구조를 사용하여 대량 복사 작업에 의해 수정된 익스텐트와 마지막 전체 백업 이후에 수정된 익스텐트를 추적할 수 있습니다. 이러한 데이터 구조는 차등 백업 속도를 크게 개선합니다. 또한 데이터베이스가 대량 로그 복구 모델을 사용하는 경우 대량 복사 작업의 로깅 속도를 높입니다. 이러한 구조들은 GAM과 SGAM 페이지처럼 각 비트가 단일 익스텐트를 표시하는 비트맵에 해당합니다.
DCM(Differential Changed Map)
마지막
BACKUP DATABASE문 이후에 변경된 익스텐트를 추적합니다. 익스텐트의 비트가1경우 익스텐트가 마지막BACKUP DATABASE문 이후 수정된 것입니다. 비트가0인 경우 익스텐트가 수정되지 않은 것입니다.차등 백업은 DCM 페이지를 읽어 수정된 익스텐트만 확인합니다. 따라서 차등 백업에서는 검색해야 하는 페이지 수가 크게 줄어듭니다. 차등 백업이 실행되는 시간의 길이는 데이터베이스의 전체 크기가 아니라 마지막
BACKUP DATABASE문 이후에 수정된 익스텐트의 수에 비례합니다.BCM(Bulk Changed Map)
마지막
BACKUP LOG문 이후에 대량 로그 작업에 의해 수정된 익스텐트를 추적합니다. 익스텐트의 비트가1경우 익스텐트가 마지막BACKUP LOG문 이후 대량 로그 작업에 의해 수정된 것입니다. 이 비트가0인 경우 익스텐트는 대량 로그 작업에 의해 수정되지 않은 것입니다.BCM 페이지는 모든 데이터베이스에 표시되지만, 데이터베이스가 대량 로그 복구 모델을 사용하는 경우에만 연관성이 있습니다. 이 복구 모델에서
BACKUP LOG가 수행되는 경우 백업 프로세스는 BCM에서 수정된 익스텐트를 검색합니다. 이런 익스텐트를 로그 백업에 포함시킵니다. 이는 데이터베이스 백업 및 트랜잭션 로그 백업 시퀀스에서 데이터베이스를 복원하는 경우, 대량 로그 작업을 복구합니다. 대량 로그 작업이 로깅되지 않으므로 BCM 페이지는 단순 복구 모델을 사용하는 데이터베이스에서 연관성이 없습니다. 복구 모델은 대량 로그 작업을 완전하게 로깅된 작업으로 처리하므로, 전체 복구 모델을 사용하는 데이터베이스에서는 연관성이 없습니다.
DCM 페이지와 BCM 페이지 사이의 간격은 GAM 페이지와 SGAM 페이지 사이의 간격(64,000개 익스텐트)과 동일합니다. DCM 페이지와 BCM 페이지는 다음과 같이 물리적 파일의 GAM 페이지와 SGAM 페이지 뒤에 있습니다.
