로그 파일을 더 작게 만들면 예상치 못한 증가가 다시 발생할 것으로 예상되는 시나리오를 위해 예약해야합니다. 로그 파일이 다시 같은 크기로 커지면 임시로 축소하여 크게 수행되지 않습니다. 이제 데이터베이스의 복구 목표에 따라 수행해야 할 조치입니다.
먼저 전체 백업을 수행하십시오.
문제가 발생했을 때 복원 할 수 있는지 확인하지 않고 데이터베이스를 변경하지 마십시오.
특정 시점 복구에 관심이있는 경우
그리고 특정 시점 복구의 경우 전체 또는 차등 백업 이외의 다른 것으로 복원 할 수 있다는 점을 의미합니다.
데이터베이스가 FULL복구 모드에있을 수 있습니다. 그렇지 않은 경우 다음을 확인하십시오.
ALTER DATABASE testdb SET RECOVERY FULL;
정기적 인 전체 백업을 수행하더라도 로그 백업 을 수행 할 때까지 로그 파일이 커지거나 커 집니다. 이는 디스크 공간을 불필요하게 먹지 않도록 보호하기위한 것입니다. 복구 목표에 따라 이러한 로그 백업을 자주 수행해야합니다. 예를 들어, 재난 발생시 15 분 이상의 데이터를 잃을 수있는 비즈니스 규칙이있는 경우 15 분마다 로그를 백업하는 작업이 있어야합니다. 다음은 현재 시간을 기반으로 타임 스탬프가 지정된 파일 이름을 생성하는 스크립트입니다 (그러나 유지 관리 계획 등을 사용하여이 작업을 수행 할 수도 있습니다. 유지 관리 계획에서 축소 옵션을 선택하지 않으면 끔찍합니다).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
참고 \\backup_share\다른 기본 저장 장치를 나타내는 다른 시스템에 있어야한다. 이러한 머신을 동일한 머신 (또는 동일한 기본 디스크를 사용하는 다른 머신 또는 동일한 물리적 호스트에있는 다른 VM)에 백업하는 것은 실제로 도움이되지 않습니다. 머신이 고장 나면 데이터베이스를 잃어 버렸기 때문입니다 그리고 백업. 네트워크 인프라에 따라 로컬로 백업 한 다음 장면 뒤의 다른 위치로 전송하는 것이 더 합리적 일 수 있습니다. 두 경우 모두 가능한 빨리 기본 데이터베이스 시스템에서 제거하려고합니다.
이제 정기적 인 로그 백업을 실행 한 후에는 로그 파일을 지금까지 해본 것보다 더 합리적인 것으로 축소하는 것이 합리적입니다. 이는 로그 파일이 1MB가 될 때까지 반복 해서 실행되는 것을 의미 하지는 않습니다SHRINKFILE . 로그를 자주 백업하더라도 발생할 수있는 동시 트랜잭션의 합계를 수용해야합니다. 로그 파일 자동 증가 이벤트는 SQL Server가 파일을 제로화해야하고 (즉석 파일 초기화가 활성화 된 경우 데이터 파일과는 달리)이 문제가 발생하는 동안 사용자 트랜잭션을 기다려야하기 때문에 비용이 많이 듭니다. 이 성장-축소-수축-축소 루틴을 가능한 한 적게하고 싶으며, 사용자가 비용을 지불하고 싶지는 않습니다.
축소가 가능하기 전에 로그를 두 번 백업해야 할 수도 있습니다 (Robert 덕분에).
따라서 로그 파일의 실제 크기를 만들어야합니다. 여기에 아무도 당신의 시스템에 대해 더 많이 알지 않고도 그것이 무엇인지 알 수는 없지만 로그 파일을 자주 축소하고 다시 커지면 워터 마크가 가장 큰 것보다 10-50 % 높을 것입니다 . 200MB가되고 후속 자동 증가 이벤트가 50MB가되게하려면 다음과 같이 로그 파일 크기를 조정할 수 있습니다.
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
로그 파일이 현재 200MB를 초과하면 먼저이 파일을 실행해야합니다.
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
특정 시점 복구에 관심이없는 경우
이 데이터베이스가 테스트 데이터베이스이고 특정 시점 복구에 관심이없는 경우 데이터베이스가 SIMPLE복구 모드 인지 확인해야 합니다.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
데이터베이스를 SIMPLE복구 모드로 설정하면 SQL Server가 로그 를 백업 할 때까지 복구 와 같이 모든 트랜잭션 의 기록을 유지하기 위해 증가하지 않고 로그 파일의 일부 (필수적으로 비활성 트랜잭션 제거)를 재사용해야합니다 FULL. CHECKPOINT이벤트는 로그를 제어하는 데 도움이되며 CHECKPOINTs 사이에 많은 t-log 활동을 생성하지 않으면 커질 필요가 없습니다 .
다음으로,이 로그 증가는 정상적인 일상적인 사용이 아니라 비정상적인 이벤트 (예 : 연간 봄 청소 또는 가장 큰 지수 재 구축)로 인한 것인지 절대적으로 확인해야합니다. 로그 파일을 엄청나게 작은 크기로 축소하고 SQL Server가 정상적인 활동을 수용하기 위해 다시 커야한다면 무엇을 얻었습니까? 임시로 확보 한 디스크 공간을 사용할 수 있었습니까? 즉각적인 수정이 필요한 경우 다음을 실행할 수 있습니다.
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
그렇지 않으면 적절한 크기와 성장률을 설정하십시오. 특정 시점 복구 사례의 예에 따라 동일한 코드와 논리를 사용하여 적절한 파일 크기를 판별하고 합리적인 자동 증가 매개 변수를 설정할 수 있습니다.
원하지 않는 것들
와 로그를 백업 TRUNCATE_ONLY한 후 옵션SHRINKFILE . 우선이 TRUNCATE_ONLY옵션은 더 이상 사용되지 않으며 현재 버전의 SQL Server에서 더 이상 사용할 수 없습니다. 둘째, FULL복구 모델 인 경우 로그 체인이 손상되고 새로운 전체 백업이 필요합니다.
데이터베이스를 분리하고 로그 파일을 삭제 한 후 다시 첨부하십시오 . 이것이 얼마나 위험한지 강조 할 수 없습니다. 데이터베이스가 백업되지 않거나 의심스러운 것으로 표시 될 수 있으며 백업이있는 경우 백업으로 되돌려 야 할 수도 있습니다.
"데이터베이스 축소"옵션을 사용하십시오 . DBCC SHRINKDATABASE특히 로그 문제 문제를 해결해야하는 경우에는 유지 관리 계획 옵션을 사용하는 것이 좋지 않습니다. 조정하려는 파일을 대상으로하고 DBCC SHRINKFILE또는 ALTER DATABASE ... MODIFY FILE(위의 예)를 사용하여 독립적으로 조정하십시오 .
로그 파일을 1MB로 줄 입니다. SQL Server가 특정 시나리오에서 수행하고 사용 가능한 모든 공간을 볼 수있게 해줄 것입니다. 데이터베이스가 읽기 전용이 아니라면 (을 사용하여 표시해야 함 ALTER DATABASE) 로그가 복구 모델에 관계없이 현재 트랜잭션을 수용해야하기 때문에 불필요한 증가 이벤트가 발생할 수 있습니다. SQL Server가 천천히 고통스럽게 되돌릴 수 있도록 그 공간을 일시적으로 비우는 시점은 무엇입니까?
두 번째 로그 파일을 작성하십시오 . 이렇게하면 디스크를 가득 채운 드라이브가 일시적으로 완화되지만 구멍이 뚫린 폐를 반창고로 고치는 것과 같습니다. 다른 잠재적 인 문제를 추가하는 대신 문제가있는 로그 파일을 직접 처리해야합니다. 일부 트랜잭션 로그 활동을 다른 드라이브로 경로 재지 정하는 것 외에 두 번째 로그 파일은 한 번에 하나의 파일 만 사용할 수 있으므로 실제로 두 번째 데이터 파일과 달리 아무 것도 수행하지 않습니다. Paul Randal은 또한 여러 개의 로그 파일이 나중에 물릴 수있는 이유를 설명합니다 .
능동적으로 행동하십시오
로그 파일을 적은 양으로 축소하고 자체적으로 작은 비율로 지속적으로 자동 증가시키는 대신, 합당한 큰 크기 (최대 동시 트랜잭션 세트의 합계를 수용 할 수있는 크기)로 설정하고 합리적인 자동 증가를 설정하십시오. 단일 트랜잭션을 만족시키기 위해 여러 번 성장할 필요가없고 정상적인 비즈니스 운영 중에 성장하는 것이 상대적으로 드물게되도록 대체로 설정합니다.
여기서 최악의 설정은 1MB 증가 또는 10 % 증가입니다. 재미있는만큼, 이들은 (I 대해 불평 한 SQL Server의 기본값입니다 아무 소용이 변경 요구는 ) - 데이터 파일 1 MB, 및 로그 파일에 대한 10 %. 전자는이 날과 나이에 너무 작으며 후자는 매번 더 길고 더 긴 이벤트로 이어집니다 (예 : 로그 파일은 500MB, 첫 번째 성장은 50MB, 다음 성장은 55MB, 다음 성장은 60.5MB 등-그리고 느린 I / O에서 나를 믿으십시오. 실제로이 곡선을 알 수 있습니다).
추가 자료
여기서 멈추지 마십시오. 로그 파일 축소에 대한 많은 조언이 본질적으로 나쁘고 재앙이 될 수 있지만 디스크 공간을 확보하는 것보다 데이터 무결성에 더 관심이있는 사람들이 있습니다.
2009 년에 쓴 블로그 게시물에서 몇 가지 "로그 파일을 축소하는 방법"게시물이 생겼습니다 .
브렌트 오자 (Brent Ozar)는 4 년 전에 게시 하지 말아야 할 SQL Server Magazine 기사에 대한 답변으로 여러 리소스를 지적한 블로그 게시물을 작성 했습니다 .
t-log 유지 보수가 중요한 이유 와 데이터 파일을 축소하지 않아야하는 이유를 설명하는 Paul Randal의 블로그 게시물 .
Mike Walsh는 로그 파일을 즉시 축소 할 수없는 이유를 포함하여 이러한 측면 중 일부를 다루는 훌륭한 답변을 제공합니다 .
