이 문서에서는 트랜잭션 로그가 허용할 수 없는 한계까지 커질 경우에 수행해야 할 작업을 설명합니다. 트랜잭션 로그가 커지면 Microsoft SQL Server 데이터베이스를 사용할 수 없게 됩니다. 이 문서에서는 또한 트랜잭션 로그 크기가 예기치 않게 커지는 것을 막기 위해 사용할 수 있는 옵션에 대해서도 설명합니다.

위로 가기

SQL Server 2000 및 SQL Server 2005에서 각 데이터베이스에는 데이터 파일과 트랜잭션 로그 파일이 하나 이상 포함되어 있습니다. SQL Server는 데이터를 데이터 파일에 물리적으로 저장합니다. 트랜잭션 로그 파일은 SQL Server 데이터베이스에 수행한 모든 수정 작업의 세부 정보와 각 수정 작업을 수행한 트랜잭션의 세부 정보를 저장합니다. 트랜잭션 무결성은 SQL Server의 근본적이고 본질적인 특성이므로 SQL Server에서는 트랜잭션의 세부 정보를 로깅하는 기능을 해제할 수 없습니다.

트랜잭션 로그 파일은 논리적으로 가상 로그 파일이라고 하는 보다 작은 세그먼트로 나뉘어집니다. SQL Server 2000에서는 필요한 경우 트랜잭션 로그 파일 크기가 커지도록 구성할 수 있습니다. 트랜잭션 로그 크기가 커지도록 사용자가 제어하거나, 사용 가능한 모든 디스크 공간을 사용하도록 구성할 수도 있습니다. 트랜잭션 로그 파일을 자르거나 늘리는 등 SQL Server에서 트랜잭션 로그 파일 크기를 수정하는 모든 작업은 가상 로그 파일 단위로 수행됩니다.

트랜잭션 로그 파일이 자동으로 커지도록 옵션을 설정한 상태에서 SQL Server 데이터베이스의 해당 트랜잭션 로그 파일이 채워지면 트랜잭션 로그 파일은 가상 로그 파일 단위로 커집니다. 트랜잭션 로그 파일 크기가 아주 커져서 디스크 공간이 부족해질 수도 있습니다. 트랜잭션 로그 파일이 사용 가능한 디스크 공간을 모두 사용하여 더 이상 커질 수 없어지면 데이터베이스에서 데이터를 더 이상 수정할 수 없습니다. 또한 트랜잭션 로그 크기 증가에 따른 공간 부족으로 인해 SQL Server가 데이터베이스를 주의 대상으로 표시할 수 있습니다.

트랜잭션 로그 파일 크기가 예기치 않게 커질 수 있는 시나리오에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

위로 가기

트랜잭션 로그 크기 줄이기

트랜잭션 로그 크기가 허용할 수 없는 한계까지 커지는 상황에서 복구하려면 트랜잭션 로그 크기를 줄여야 합니다. 이렇게 하려면 트랜잭션 로그에서 비활성 트랜잭션을 잘라내고 트랜잭션 로그 파일을 축소해야 합니다.

참고 트랜잭션 로그는 데이터베이스의 트랜잭션 무결성을 유지하는 데 매우 중요합니다. 따라서 데이터베이스와 트랜잭션 로그의 백업 복사본을 만든 후에도 트랜잭션 로그 파일을 삭제하지 않아야 합니다.

트랜잭션 로그에서 비활성 트랜잭션 잘라내기

트랜잭션 로그 크기가 허용할 수 없는 한계까지 커지면 즉시 트랜잭션 로그 파일을 백업해야 합니다. 트랜잭션 로그 파일의 백업 복사본을 만드는 동안 SQL Server는 트랜잭션 로그의 비활성 부분을 자동으로 잘라냅니다. 트랜잭션 로그 파일의 비활성 부분에는 완료된 트랜잭션도 포함되므로 복구 프로세스 동안 SQL Server는 더 이상 트랜잭션 로그 파일을 사용하지 않습니다. 또한 트랜잭션 로그 크기가 계속 커져서 추가 공간을 사용하도록 허용하는 대신 이렇게 잘라낸 트랜잭션 로그의 비활성 공간을 재사용합니다.

트랜잭션 로그의 백업 복사본을 만들 때 고려해야 할 문제와 트랜잭션 로그 백업을 복원할 때 고려해야 할 문제에 대한 자세한 내용은 SQL Server 온라인 설명서의 다음 항목을 참조하십시오.

•	트랜잭션 로그 백업
•	트랜잭션 로그 백업 및 복원

또한 Truncate 메서드를 사용하여 트랜잭션 로그 파일에서 비활성 트랜잭션을 삭제해도 됩니다. 트랜잭션 로그를 자르는 방법에 대한 자세한 내용은 SQL Server 온라인 설명서의 "트랜잭션 로그 잘라내기" 항목을 참조하십시오.

중요 수동으로 트랜잭션 로그 파일을 자른 후에는 트랜잭션 로그 백업을 만들기 전에 전체 데이터베이스 백업을 만들어야 합니다.

트랜잭션 로그 파일을 자를 때 발생할 수 있는 문제에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

트랜잭션 로그 파일 축소

백업 작업이나 Truncate 메서드는 로그 파일 크기를 줄이지 않습니다. 트랜잭션 로그 파일의 크기를 줄이려면 트랜잭션 로그 파일을 축소해야 합니다. 요청한 크기로 트랜잭션 로그 파일을 축소하고 사용하지 않는 페이지를 제거하려면 DBCC SHRINKFILE 연산을 사용해야 합니다. DBCC SHRINKFILE Transact-SQL 문은 로그 파일 내부의 비활성 부분만 축소할 수 있습니다.

참고 DBCC SHRINKFILE Transact-SQL 문은 단독으로 로그를 자르고 로그 파일 내부에서 사용된 공간을 축소하지 못합니다.

트랜잭션 로그 파일을 축소하는 방법에 대한 자세한 내용은 SQL Server 설명서의 다음 항목을 참조하십시오.

•	트랜잭션 로그 축소
•	DBCC SHRINKFILE

SQL Server 2000에서 트랜잭션 로그 파일을 축소하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오. 트랜잭션 로그 파일을 축소할 때 발생할 수 있는 문제에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

위로 가기

트랜잭션 로그 파일이 예기치 않게 커지는 것을 막기

트랜잭션 로그 파일이 예기치 않게 커지는 것을 막으려면 다음 방법 중 하나를 사용하십시오.

•	트랜잭션 로그 파일이 자동으로 커지지 않도록 트랜잭션 로그 파일 크기를 큰 값으로 설정합니다.
•	최적의 메모리 크기를 철저하게 계산한 후 백분율 대신 메모리 단위를 사용하여 트랜잭션 로그 파일의 자동 증가 옵션을 구성합니다. 자동 증가 옵션을 구성할 때 고려해야 할 문제에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오. 315512 (http://support.microsoft.com/kb/315512/) INF: SQL Server에서 자동 증가와 자동 축소 구성을 위한 고려 사항
•	복구 모델을 변경합니다. 재해나 데이터 손상이 발생한 경우에는 데이터베이스의 트랜잭션 무결성과 데이터 일관성이 유지되도록 데이터베이스를 복구해야 합니다. 데이터베이스에 있는 데이터의 중요도에 따라 아래의 복구 모델 중 하나를 사용하여 데이터 백업 방법과 어떤 것이 데이터 손실에 노출되는지 확인할 수 있습니다. • 단순 복구 모델 • 전체 복구 모델 • 대량 로그 복구 모델 단순 복구 모델을 사용하면 데이터베이스의 최신 백업으로 데이터베이스를 복구할 수 있습니다. 전체 복구 모델이나 대량 로그 복구 모델을 사용하면 트랜잭션 로그 파일 백업으로 데이터베이스를 복원하여 실패가 발생한 시점으로 데이터베이스를 복구할 수 있습니다. 기본적으로 SQL Server 2000 및 SQL Server 2005에서는 SQL Server 데이터베이스에 대한 복구 모델이 전체 복구 모델로 설정되어 있습니다. 전체 복구 모델에서는 트랜잭션 로그 파일 크기가 데이터베이스 크기와 불균형적으로 커지는 것을 막기 위해 트랜잭션 로그를 정기적으로 백업합니다. 그러나 트랜잭션 로그를 정기적으로 백업하지 않으면 트랜잭션 로그 파일 크기가 디스크를 채울 정도로 커져서 SQL Server 데이터베이스에서 데이터를 수정하지 못할 수 있습니다. 재해 복구 작업 동안 트랜잭션 로그 파일을 사용하지 않으려면 전체 복구 모델에서 단순 복구 모델로 변경할 수 있습니다.
•	정기적으로 트랜잭션 로그 파일을 백업하여 트랜잭션 로그에서 비활성 트랜잭션을 삭제합니다.
•	트랜잭션을 작게 설계합니다.
•	커밋되지 않은 트랜잭션이 무기한 계속 실행되지 않도록 합니다.
•	매일 실행되도록 통계 업데이트 옵션을 예약합니다.
•	프로덕션 환경에서 작업 부하 성능을 향상시키기 위해 인덱스 조각을 모으려면 DBCC DBREINDEX Transact-SQL 문 대신 DBCC INDEXDEFRAG Transact-SQL 문을 사용합니다. SQL Server 데이터베이스가 전체 복구 모드에 있을 때 DBCC DBREINDEX 문을 실행하면 트랜잭션 로그가 상당히 증가할 수 있습니다. 또한 DBCC INDEXDEGRAG 문은 DBCC DBREINDEX 문과 달리 잠금을 장시간 유지하지 않습니다. SQL Server 2000에서 인덱스 조각을 모으는 방법에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오. http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx)(영문) 데이터베이스 유지 관리 계획의 일부 작업으로 DBCC DBREINDEX 문을 실행해야 할 경우에는 이 작업을 여러 개의 작업으로 나누어야 합니다. 또한 각 작업 실행 사이에 자주 트랜잭션 로그를 백업해야 합니다.

위로 가기

복구 프로세스 동안 추가 디스크 공간 요구 문제를 해결하는 방법에 대한 자세한 내용은 SQL Server 온라인 설명서의 "디스크 공간 부족" 항목을 참조하십시오. 트랜잭션 로그 아키텍처에 대한 자세한 내용은 SQL Server 온라인 설명서의 다음 항목을 참조하십시오.

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

SQL Server 2000의 복구 모델에 대한 자세한 내용은 SQL Server 온라인 설명서의 다음 항목을 참조하십시오.

•	복구 모델 선택
•	단순 복구
•	전체 복구
•	대량 로그 복구
•	복구 모델 전환

Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹 (http://support.microsoft.com/newsgroups/default.aspx)에 참여하시기 바랍니다.

위로 가기