트랜잭션 로그 물리 아키텍처

업데이트: 2006년 4월 14일

데이터베이스의 트랜잭션 로그는 하나 이상의 물리적 파일에 매핑됩니다. 개념상으로 로그 파일은 로그 레코드의 문자열입니다. 실제로 로그 레코드의 시퀀스는 트랜잭션 로그를 구현하는 물리적 파일 집합에 효율적으로 저장됩니다.

SQL Server 데이터베이스 엔진은 내부적으로 각 물리 로그 파일을 여러 개의 가상 로그 파일로 나눕니다. 가상 로그 파일의 크기는 고정되어 있지 않으며 물리 로그 파일에 대해 고정된 수의 가상 로그 파일이 있는 것도 아닙니다. 데이터베이스 엔진은 로그 파일을 만들거나 확장할 때 동적으로 가상 로그 파일의 크기를 선택합니다. 데이터베이스 엔진은 적은 수의 가상 파일을 유지하려고 합니다. 로그 파일 확장 후 가상 파일 크기는 기존 로그 크기와 새 파일 증가 크기를 합한 크기입니다. 관리자가 가상 로그 파일의 크기 또는 수를 구성하거나 설정할 수 없습니다.

작은 size 및 growth_increment 값으로 로그 파일을 정의하는 경우에만 가상 로그 파일이 시스템 성능에 영향을 줍니다. 수많은 작은 증가값으로 인해 로그 파일이 크게 증가하는 경우 가상 로그 파일이 많이 생성됩니다. 이로 인해 데이터베이스 시작뿐 아니라 로그 백업 및 복원 작업이 느려질 수 있습니다. 필요한 최종 크기에 가까운 size 값을 로그 파일에 할당하고 growth_increment 값을 비교적 크게 지정하는 것이 좋습니다.

트랜잭션 로그는 순환 파일입니다. 예를 들어 데이터베이스에 4개의 가상 로그 파일로 나뉜 물리 로그 파일이 한 개 있다고 가정합니다. 이 데이터베이스가 생성될 때 물리 로그 파일의 시작 부분에서 논리 로그 파일이 시작됩니다. 새 로그 레코드는 논리 로그의 끝 부분에 추가되며 물리 로그의 끝 방향으로 확장됩니다. 로그 잘림을 수행하면 모든 레코드가 MinLSN(최소 복구 로그 시퀀스 번호) 앞에 있는 가상 로그에 대한 공간이 확보됩니다. MinLSN은 성공적인 데이터베이스 수준 롤백에 필요한 가장 오래된 로그 레코드의 로그 시퀀스 번호입니다. 예제 데이터베이스의 트랜잭션 로그는 다음 그림의 로그와 유사합니다.

논리 로그의 끝 부분이 물리 로그 파일의 끝 부분에 도달하면 새 로그 레코드는 물리 로그 파일의 시작 부분으로 순환됩니다.

이러한 순환은 논리 로그 끝 부분이 논리 로그의 시작 부분에 도달하지 않는 한 계속 반복됩니다. 다음 검사점까지 생성되는 모든 새 로그 레코드를 위해 항상 충분한 공간이 남을 만큼 기존 로그 레코드가 자주 잘리면 로그는 가득 차지 않습니다. 그러나 논리 로그의 끝 부분이 논리 로그의 시작 부분에 도달하면 다음 두 가지 상황 중 하나가 발생합니다.

• 로그에 대해 FILEGROWTH가 설정되어 있고 디스크에 사용할 수 있는 공간이 있으면 파일은 growth_increment에 지정된 크기만큼 확장되며 새 로그 레코드가 확장 부분에 추가됩니다. FILEGROWTH 설정에 대한 자세한 내용은 ALTER DATABASE(Transact-SQL)를 참조하십시오.
• FILEGROWTH가 설정되어 있지 않거나 로그 파일이 있는 디스크의 사용 가능한 공간이 growth_increment에 지정된 크기보다 적으면 9002 오류가 생성됩니다.

로그에 물리 로그 파일이 여러 개 있으면 논리 로그는 모든 물리 로그 파일을 거친 후 첫 번째 물리 로그 파일의 시작 부분으로 순환됩니다.

참고 항목

개념

로그 잘림을 지연시킬 수 있는 요소
트랜잭션 로그 논리 아키텍처
트랜잭션 로그 백업 작업
트랜잭션 로그 소개

관련 자료

트랜잭션 로그 아키텍처 이해

도움말 및 정보

SQL Server 2005 지원 받기

변경 내역