데이터베이스 개발자 Tip & 강좌

SQLER의 개발자들이 만들어가는 데이터베이스 사용자 Tip & 강좌 게시판입니다. SQL서버, Oracle, MySQL 등 여러 클라우드/오픈소스 기반 데이터베이스 개발 및 운영 관련 팁과 쿼리 노하우를 이곳에서 가장 먼저 접하실 수 있습니다. 많은 도움 되시길 바랍니다.

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

– 수정된 익스텐트 추적

 

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

 

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

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

 

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

 

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의 정보를 확인 한다. 현재 페이지의 상태는 전체 백업 이후 변경된 것이 없는 상태이다.

BACKUP DATABASE [SW_TEST] TO DISK = N'C:\SQL_Backup\SW_TEST.bak'

WITH NOFORMAT, INIT,

NAME = N'SW_TEST Full Database Backup',

SKIP, NOREWIND, NOUNLOAD, STATS = 10

GO

 

DBCC TRACEON (3604)

DBCC PAGE('SW_TEST',1,6,3)

GO

 

 

 

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

update TBL_B set name = name + ' Good Day'

go

 

DBCC TRACEON (3604)

DBCC PAGE('SW_TEST',1,6,3)

GO

 

 

 

 

[참고자료]

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

No. Subject Author Date Views
1771 SQL Server 쿼리 처리 아키텍처 _ SQL 문 처리 (4/4) – 분산형 분할 뷰(View) 확인 jevida(강성욱) 2016.09.27 1337
1770 SQL Server 쿼리 처리 아키텍처 _ SQL 문 처리 (3/4) – 뷰(View)의 인덱스 확인 jevida(강성욱) 2016.09.27 973
1769 SQL Server 쿼리 처리 아키텍처 _ SQL 문 처리 (2/4) – 뷰(View) 확인 jevida(강성욱) 2016.09.27 1447
1768 SQL Server 쿼리 처리 아키텍처 _ SQL 문 처리 (1/4) – SQL 문 최적화 및 Worktables jevida(강성욱) 2016.09.27 933
1767 SQL Server DMV를 이용한 통계 정보 확인 jevida(강성욱) 2016.09.27 1487
1766 DMV를 이용한 플랜 캐시 사용 정보 확인 jevida(강성욱) 2016.09.27 1172
1765 SQL Server 테이블 및 인덱스 구조 아키텍처(4/4) – 비클러스터형 인덱스 구조 jevida(강성욱) 2016.09.27 1066
1764 SQL Server 테이블 및 인덱스 구조 아키텍처(3/4) – 클러스터형 인덱스 구조 jevida(강성욱) 2016.09.27 1370
1763 SQL Server 테이블 및 인덱스 구조 아키텍처(2/4) – 힙 구조 jevida(강성욱) 2016.09.27 1069
1762 SQL Server 테이블 및 인덱스 구조 아키텍처(1/4) – 테이블 및 인덱스 구성 jevida(강성욱) 2016.09.27 1127
1761 SQL Server 트랜잭션 로그 아키텍처(4/4) – 미리 쓰기 트랜잭션 로그 jevida(강성욱) 2016.09.27 1537
1760 SQL Server 트랜잭션 로그 아키텍처(3/4) – 검사점 및 로그의 활성 부분 jevida(강성욱) 2016.09.27 1048
1759 SQL Server 트랜잭션 로그 아키텍처(2/4) – 트랜잭션 로그 물리 아키텍처 jevida(강성욱) 2016.09.27 1096
1758 SQL Server 트랜잭션 로그 아키텍처(1/4) – 트랜잭션 로그 논리 아키텍처 jevida(강성욱) 2016.09.27 1254
1757 파일 및 파일 그룹 아키텍처 jevida(강성욱) 2016.09.27 801
» SQL Server 페이지 및 익스텐트 아키텍처(4/4) – 수정된 익스텐트 추적 jevida(강성욱) 2016.09.27 1130
1755 SQL Server 페이지 및 익스텐트 아키텍처(3/4) – 개체에서 사용하는 공간 관리 jevida(강성욱) 2016.09.27 975
1754 SQL Server 페이지 및 익스텐트 아키텍처(2/4) – 익스텐트 할당 및 빈공간 관리 jevida(강성욱) 2016.09.27 1457
1753 SQL Server 페이지 및 익스텐트 아키텍처(1/4) – 페이지 및 익스텐트 이해 jevida(강성욱) 2016.09.27 3318
1752 SQL Server Error Log 보관 주기 설정 jevida(강성욱) 2016.09.15 2184





XE Login