SQL Server 페이지 및 익스텐트 아키텍처(4/4)

– 수정된 익스텐트 추적

• Version : SQL Server 2005, 2008, 2008R2, 2012

페이지 및 익스텐트 아키텍처의 마지막 챕터 이다.

지금까지는 페이지 및 익스텐의 구조, 익스텐트에 대한 할당 관리, 공간관리 등에 대해서 살펴 보았다.

• 페이지 및 익스텐트 이해 : http://sqlmvp.kr/140186753568
• 익스텐트 할당 미 및 빈 공간 관리 : http://sqlmvp.kr/140186842239
• 개체에서 사용하는 공간 관리 : http://sqlmvp.kr/140186908637

이번 시간에는 수정된 익스텐트 추적에 대해서 알아 보도록 한다. 수정된 익스텐트에 대한 이해는 백업과도 큰 관련이 있다. 백업이 이루질 때 백업에 대한 전략을 고민해 볼 수 있다.

SQL Server는 DCM, BCM 내부 데이터 구조를 사용하여 대량 복사 작업에 의해 수정된 익스텐트와 마지막 전체 백업 이후에 수정된 익스텐트를 추적 할 수 있다. 추적 방법은 GAM(전역 할당 맵)과 SGAM(공유 전역 할당 맵) 페이지의 비트로 확인 한다.

이 두 개의 데이터 구조를 이해하면 차등 백업의 속도 및 대량 로그 작업에서의 성능 향상을 이해 할 수 있다.

[DCM(Differential Change Map : 차등 변경 맵)]

마지막 Backup Database 문 이후에 변경된 익스텐트를 추적 한다. 익스텐의 비트가 1인 경우는 Backup Database 이후 수정된 것이다. 비트가 0인 것은 수정 되지 않은 것이다.

차등 백업의 경우 DCM 페이지만 읽고도 어떤 익스텐트가 수정되었는지 알 수 있다. 이를 통해 차등 백업이 검색 해야 하는 페이지의 수가 상당히 줄어 든다. 차등 백업이 실행되는 시간의 길이는 데이터베이스의 전체 크기가 아니라 마지막 Backup Database문 이후에 수정된 익스텐트 수에 비례한다.

[BCM(대량 변경 맵)]

마지막 Backup Log 문 이후에 대랑 로그 작업에 의해 수정된 익스텐트를 추적 한다. 익스텐트의 비트가 1인 경우 익스텐트는 마지막 Backup Log 문 이후에 대량 기록 작업에 의해 수정된 것이다. 비트가 0인 경우는 수정되지 않은 거이다.

BCM 페이지가 모든 데이터베이스에 표시 되더라도 데이터베이스가 대량 로그 복구 모델을 사용할 때만 적절하다. 이러한 복구 모델에서 Backup Log가 수행되면 백업 프로세스는 수정된 익스텐트의 BCM을 검색하고 이런 익스텐트를 로그 백업에 포함시킨다.

단순 복구 모델의 경우 대량 로그 작업이 기록되지 않음으로 BCM 페이지가 적절하지 않다. 전체 복구 모델의 경우에도 대량 로그 작업을 전체 로그 작업으로 취급하므로 전체 복구 모델을 사용하는 데이터베이스에서도 BCM 페이지는 적절 하지 않다.

[BCM, DCM 물리적 위치]

아래 그림을 보면 DCM 페이지와 BCM 페이지 사이의 간격은 GAM, SGAM과 동일하게 64,000개의 익스텐트와 동일하다. 물리적인 위치는 GAM, SGAM 뒤에 위치 한다.

다음 실습은 백업 후 데이터변경을 통하여 DCM 익스텐트 상태를 확인 한다.

우선 데이터베이스 전체 백업을 진행 한다. 그리고 DBCC TRAACE ON (3604)를 활성화 하여 PAGE의 정보를 확인 한다. 현재 페이지의 상태는 전체 백업 이후 변경된 것이 없는 상태이다.

데이터를 변경 후 페이지의 정보를 확인 하자. 백업 이후 수정된 익스텐트에 대해서 확인 할 수 있다.

[참고자료]

http://msdn.microsoft.com/ko-kr/library/ms190950(v=sql.105).aspx

http://colleenmorrow.com/2011/07/11/sql-server-a-to-z-backups/

강성욱 / jevida@naver.com
Microsoft SQL Server MVP
Blog : http://sqlmvp.kr
Facebook : http://facebook.com/sqlmvp