SQL Server 트랜잭션 로그를 지우려면 어떻게합니까?


577

저는 SQL 전문가가 아니며 기본 이외의 작업을 수행해야 할 때마다 사실을 상기시킵니다. 크기가 크지 않은 테스트 데이터베이스가 있지만 트랜잭션 로그는 확실합니다. 트랜잭션 로그를 지우려면 어떻게합니까?



3
Managment Studio에는 "Click to Shrink Log"라는 명령이 있어야합니다.
frenchie 2016 년

답변:


749

로그 파일을 더 작게 만들면 예상치 못한 증가가 다시 발생할 것으로 예상되는 시나리오를 위해 예약해야합니다. 로그 파일이 다시 같은 크기로 커지면 임시로 축소하여 크게 수행되지 않습니다. 이제 데이터베이스의 복구 목표에 따라 수행해야 할 조치입니다.

먼저 전체 백업을 수행하십시오.

문제가 발생했을 때 복원 할 수 있는지 확인하지 않고 데이터베이스를 변경하지 마십시오.

특정 시점 복구에 관심이있는 경우

그리고 특정 시점 복구의 경우 전체 또는 차등 백업 이외의 다른 것으로 복원 할 수 있다는 점을 의미합니다.

데이터베이스가 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는 로그 파일을 즉시 축소 할 수없는 이유를 포함하여 이러한 측면 중 일부를 다루는 훌륭한 답변을 제공합니다 .


5
특정 시점 복구가 전체 복구 모델을 사용하는 유일한 이유는 아닙니다. 주된 이유는 데이터 손실을 방지하기위한 것입니다. 데이터 손실 가능성은 백업 간격입니다. 매일 백업 만 수행하는 경우 데이터 손실 가능성은 24 시간입니다. 30 분마다 로그 백업을 추가하면 데이터 손실 가능성이 30 분이됩니다. 또한 모든 종류의 단편 복원 (예 : 손상 복구)을 수행하려면 로그 백업이 필요합니다.
Robert L Davis

9
그 외에도, 이것은이 페이지에서 제공되는 가장 완전하고 정확한 답변입니다.
Robert L Davis

11
또한 로그 (전체 또는 대량 로그 복구) 또는 검사 점 (간단 복구)을 백업하여 로그 지우기를 수행하고 싶다고 덧붙이고 싶습니다. 그러나 로그 파일을 축소해야하는 상황이라면 충분하지 않습니다. 현재 활성화 된 VLF가 로그 파일의 시작 부분으로 돌아가도록해야합니다. 두 개의 로그 백업 또는 체크 포인트를 연속으로 실행하여 SQL 2008 이상에서이를 강제 실행할 수 있습니다. 첫 번째는 그것을 지우고 두 번째는 파일의 시작 부분으로 순환합니다.
Robert L Davis

2
@Doug_Ivison 어느 시점에서든 로그 레코드를 제거 할 수 있기 때문입니다. 불완전한 로그를 백업 할 수있는 시점은 무엇입니까? 간단한 복구에서 로그는 실제로 트랜잭션 롤백을 허용하는 데만 사용됩니다. 트랜잭션이 커밋되거나 롤백되면 다음에 로그에서 사라질 수 있습니다.
Aaron Bertrand

3
@zinczinc 좋아요, 의견 주셔서 감사합니다. 내가 대답을 먼저하고 나중에 설명 할 때 보게되는 문제는 중요한 부분을 읽지 않을 것이라는 점입니다. 내가 독자들과 익사 한 강의는 실제로 끝의 답보다 훨씬 중요하며, IMHO가 제공하는 배경은 그러한 선택을하는 데 매우 중요합니다. 그러나 OP에 더 좋다고 생각하여 한 줄 답변을 제출하려면 내 답변의 해당 부분을 사용하여 우리 모두가 배울 수있는 더 나은 답변을 만드십시오.
Aaron Bertrand

201
-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

보낸 사람 : DBCC SHRINKFILE (Transact-SQL)

먼저 백업하고 싶을 수도 있습니다.


감사합니다 Maimonides, 그것의 문서에서, 그래서 나는 그것이 최고라고 말하고 싶습니다 : P 특히 나에 의해 발명되지 않았기 때문에 :)
Rui Lima

1
그 후에도 로그 크기가 조금 바뀌지 않았습니다. 내가 뭐 잘못 했어요?
chester89

1
이 접근 방식은 복구 유형이 이전의 다른 유형 인 경우에도 복구 유형을 "FULL"로 설정합니다.
Vil

1
마술처럼 일했다! 로그 파일의 이름은 실제로 논리적 이름 (db-> properties-> files에서 찾을 수 있음)
Bizhan

2
이 스크립트에 BACKUP DATABASE 절을 포함 시켰으므로 아무도이 부분을 잊을 수 없습니다. 몇 년 전에 여유 공간이 너무 적은 디스크의 데이터베이스를 축소했기 때문에 이것을 말합니다. 축소 프로세스에서 파일이 커지고 공간 부족 오류가 발생했습니다. 결과 : 데이터베이스가 손실되었습니다. Luckly는 관용성을 잃은 로그 데이터베이스였습니다.
Cesar

185

면책 조항 : 아래의 의견을주의 깊게 읽으십시오. 허용 ​​된 답변을 이미 읽은 것으로 가정합니다. 거의 5 년 전에 말했듯이 :

이것이 적절하거나 최적의 솔루션이 아닌 상황에 추가 할 의견이 있으면 아래에 의견을주십시오


  • 데이터베이스 이름을 마우스 오른쪽 버튼으로 클릭하십시오.

  • 작업 → 축소 → 데이터베이스를 선택하십시오.

  • 그런 다음 OK!를 클릭하십시오 .

일반적으로 데이터베이스 파일이 포함 된 Windows 탐색기 디렉토리를 열면 즉시 효과를 볼 수 있습니다.

실제로 이것이 효과가 있다는 사실에 놀랐습니다! 일반적으로 나는 전에 DBCC를 사용했지만 그저 시도했지만 아무것도 축소하지 않았으므로 GUI (2005)를 사용해 보았고 10 초 만에 17GB를 확보했습니다.

전체 복구 모드에서는 작동하지 않을 수 있으므로 먼저 로그를 백업하거나 단순 복구로 변경 한 다음 파일을 축소해야합니다. [@onupdatecascade 감사합니다]

-

추신 : 나는 이것의 위험에 대해 어떤 사람들이 논평 한 것에 감사하지만, 내 환경에서는 항상 전체 백업을 먼저 수행하기 때문에 특히 나 자신에게 문제가 없었습니다. 따라서 환경이 무엇인지, 그리고 계속하기 전에 이것이 백업 전략 및 작업 보안에 미치는 영향을 고려하십시오. 내가했던 것은 사람들이 Microsoft에서 제공하는 기능을 가리 키도록하는 것입니다!


50
전체 복구 모드에서는 작동하지 않을 수 있으므로 먼저 로그를 백업하거나 단순 복구로 변경 한 다음 파일을 축소해야합니다.
onupdatecascade

7
@onupdatecascade-전체 복구 트릭에 대한 좋은 전화. 거대한 로그가있는 다른 데이터베이스가 있습니다 : 단순으로 전환 한 다음 데이터베이스를 축소하고 다시 전체로 전환하십시오. 500kb까지 로그 파일!
Simon_Weaver

26
죄송합니다. 그러나이 답변은 더 이상 잘못 될 수 없습니다. 데이터베이스를 축소하면 트랜잭션 로그 파일이 커집니다. SQL Server 데이터베이스에서 데이터를 이동할 때마다 로그 파일이 부풀어 오르는 로깅이 필요합니다. 로그 크기를 줄이려면 DB를 단순 복구로 설정하거나 로그 된 데이터를 관리 / 필요한 경우 거의 항상 프로덕션 환경에서 로그를 백업하십시오. 이 간단한 무료 비디오에 대한 자세한 내용은 다음과 같습니다. sqlservervideos.com/video/logging-essentials sqlservervideos.com/video/sql2528-log-files
Michael K. Campbell

30
와우,이 답변에 대해 1300 명 이상의 담당자를 얻는 것에 대한 찬사이지만 실제로는 끔찍한 조언입니다.
Aaron Bertrand

8
다음은 어떤 일이 일어나고 있으며 왜 수축이 주기적으로 절대적으로 중요한지를 보여주는 과장입니다. 레코드 A는 백업이 완료되기 전에 백만 번 변경되었습니다. 로그에 무엇입니까? 관련이없는 999,999 개의 데이터. 로그가 축소되지 않으면 데이터베이스의 실제 운영 비용이 무엇인지 알 수 없습니다. 또한 SAN에서 귀중한 리소스를 사용하고있을 가능성이 높습니다. 축소는 유지 관리가 잘되고 환경과의 연락을 유지합니다. 절대 축소해서는 안된다고 생각하는 사람을 보여 주시면 환경을 무시하는 사람을 보여 드리겠습니다.
Newclique

54

아래는 트랜잭션 로그를 축소하는 스크립트이지만 트랜잭션 로그를 축소하기 전에 백업하는 것이 좋습니다.

파일을 축소하면 재난 발생시 생명을 구할 수있는 많은 양의 데이터가 손실됩니다. 트랜잭션 로그에는 타사 트랜잭션 로그 판독기를 사용하여 읽을 수있는 유용한 데이터가 많이 포함되어 있습니다 (수동으로 읽을 수는 있지만 많은 노력을 기울임).

트랜잭션 로그는 특정 시점으로 복구해야 할 때도 반드시 필요하므로 버리지 말고 미리 백업하십시오.

사람들이 트랜잭션 로그에 저장된 데이터를 사용하여 복구를 수행 한 게시물은 다음과 같습니다.

 

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

위의 명령을 실행할 때 다음과 같은 오류가 발생할 수 있습니다

“파일 끝에있는 논리 로그 파일이 사용 중이므로 로그 파일 (로그 파일 이름)을 축소 할 수 없습니다”

이는 TLOG가 사용 중임을 의미합니다. 이 경우 연속으로 여러 번 실행하거나 데이터베이스 활동을 줄이는 방법을 찾으십시오.


30

간단하고 매우 우아 하고 잠재적으로 위험한 방법이 있습니다.

  1. 백업 DB
  2. DB 분리
  3. 로그 파일 이름 바꾸기
  4. DB 첨부
  5. 새로운 로그 파일이 재생성됩니다
  6. 이름이 바뀐 로그 파일을 삭제하십시오.

로그 백업을 수행하지 않는 것 같습니다. 로그를 자릅니다. 내 조언은 복구 모델을 전체 에서 단순 으로 변경하는 것 입니다. 이렇게하면 로그 팽창이 방지됩니다.


15
각각 로그를 삭제 / 이름 바꾸기 / 다시 작성 / 교체하는 것은 매우 나쁜 생각입니다. 수축은 덜 위험해야하며, 매우 간단합니다.
onupdatecascade

12
+1-우아하지 않은지 여부에 관계 없이이 방법은 전체 디스크를 채운 데이터베이스 로그로 두 번 뜨거운 물에서 빠져 나와 수축 명령조차도 실행할 수 없습니다.
Shaul Behr

3
로그에 검사되지 않은 트랜잭션이 존재할 위험이 있습니까?
Paul

소규모 DB의 경우에도 문제가되지 않지만 3TB 또는 4TB DB가있는 경우 최상의 솔루션이 아닐 수 있습니다.
Jaques

오랫동안 시스템을 개발하고 개발 기간 동안 수천 개의 레코드를로드 / 삭제 한 경우에는 괜찮습니다. 그런 다음이 데이터베이스를 사용하여 라이브로 배포하려는 경우 기록 된 테스트 / 개발 데이터가 중복되므로 손실 여부는 중요하지 않습니다.
JsonStatham

28

복원에 트랜잭션 로그를 사용하지 않는 경우 (즉, 전체 백업 만 수행하는 경우) 복구 모드를 "단순"으로 설정할 수 있으며 트랜잭션 로그가 매우 짧아지고 다시 채워지지 않습니다.

SQL 7 또는 2000을 사용하는 경우 데이터베이스 옵션 탭에서 "로그온 검사 점 잘라 내기"를 활성화 할 수 있습니다. 동일한 효과가 있습니다.

특정 시점으로 복원 할 수 없으므로 프로덕션 환경에서는 권장되지 않습니다.


1
복구 모드를 단순으로 설정해도 자체적으로 트랜잭션 로그가 축소되지는 않습니다.
Aaron Bertrand

@Aaron 자체가 아닙니다. OP가 테스트 데이터베이스를 사용한다고 가정했기 때문에 "트랜잭션 로그가 매우 짧아 질 것"이라고 생각하지만 부작용이 더 많다는 것이 맞습니다. 단순 복구 모드는 아마도 축소로 이어질 것입니다 거래 기록 곧
조나단

" Simple... 그리고 다시는 채우지 마십시오"– 사실이 아닙니다. 복구 모델이 "SIMPLE"로 설정된 데이터베이스에서 (지난 48 시간 동안) 발생했습니다. 로그 파일의 파일 크기가 "제한됨"으로 설정되어 있고, 우리는 그것에 대해 엄청난 활동을하고있었습니다. (디스크 공간이 충분한 상황에서 로그 파일 크기를 늘리고 로그 파일 파일 크기를 "제한되지 않음"으로 설정했습니다. 변경 후 인터페이스 버그는 "제한됨"으로 표시됩니다. "최대 크기는 2,097,152MB입니다.)
Doug_Ivison

2
@Doug_Ivison 예, 트랜잭션 로그에는 트랜잭션이 열려 있지만 체크 포인트가 수행되면 간단한 모드로 제거됩니다. 이 답변은 단지 "개발 / 테스트 상자에 큰 트랜잭션 로그가 있고, 너무 멀리 가기 때문에 너무 자주 걱정할 필요가 없습니다"라는 것입니다. 환경. 다시 반복하려면 : 프로덕션 환경에서는이 작업을 수행하지 마십시오 .
Jonathan

1
그것은 모두 사실이며, 그것이 개발 전용 빠른 접근 방식이라는 것을 알게되었습니다. 내가 언급 한 이유 : 그것이 일어날 때까지, 나는 실제로 간단한 복구 모델이 절대로 채워질 수 없다고 생각했습니다. 그리고 알아 내기 / 해결하는 데 시간이 더 걸린다고 생각합니다.
Doug_Ivison

9

John이 권장하는이 기술은 데이터베이스가 로그 파일없이 연결될 것이라는 보장이 없으므로 권장되지 않습니다. 데이터베이스를 전체에서 단순으로 변경하고 체크 포인트를 강제 실행 한 후 몇 분 정도 기다리십시오. SQL Server는 로그를 지우고 DBCC SHRINKFILE을 사용하여 축소 할 수 있습니다.


...하지만 문제없이 수십 번 해냈습니다. 아마도 db가 다시 연결되지 않는 이유를 설명 할 수 있습니다.
Johnno Nolan

로그 파일이 삭제 될 때 SQL Server가 데이터베이스를 데이터베이스에 다시 연결할 수없는 경우가 종종있었습니다. 이로 인해 쓸모없는 MDF 파일이 남습니다. 문제를 일으킬 수있는 몇 가지 가능성이 있습니다. 롤백 보류중인 트랜잭션이 떠 오릅니다.
mrdenny

4
이 전략에 동의하지만 예상치 못한 및 / 또는 특별한 이벤트로 인해 로그가 폭발 한 경우에 예약해야합니다. 매주이 작업을 수행하면 매우 잘못되고 있습니다.
Aaron Bertrand

2
아론
mrdenny

예, 이것은 우리에게 일어난 일입니다. 데이터베이스를 이동하기 전에 데이터를 백업 했으므로 20G의 로그 파일을 버리고 싶었습니다. MSSQL을 사용하면 엄청난 로그 파일없이 새 데이터베이스를 다시 연결할 수 없습니다.
조지 M 복원 모니카

9

지금까지 대부분의 답변은 실제로 트랜잭션 로그 파일이 필요하지 않다고 가정하지만 데이터베이스가 FULL복구 모델을 사용 하고 데이터베이스를 복원 해야하는 경우 백업을 유지하려는 경우 데이터베이스를 자르거나 삭제 하지 마십시오 . 이 답변 중 다수가 제안하는 방식으로 로그 파일을 작성하십시오.

로그 파일을 자르거나, 버리고, 지우는 등을 통해 로그 파일을 제거하면 백업 체인이 손상되고 마지막 전체, 차등 또는 트랜잭션 로그 백업 이후의 다음 전체 시점까지 복원 할 수 없습니다. 또는 차등 백업이 이루어집니다.

보내는 사람 에 대한 Microsoft 기사BACKUP

트랜잭션 로그를 수동으로 자르기 위해 NO_LOG 또는 TRUNCATE_ONLY를 사용하지 않는 것이 좋습니다. 로그 체인이 손상되기 때문입니다. 다음 전체 또는 차등 데이터베이스 백업까지는 데이터베이스가 미디어 장애로부터 보호되지 않습니다. 매우 특수한 상황에서만 수동 로그 잘림을 사용하고 즉시 데이터 백업을 작성하십시오.

이를 방지하려면 로그 파일 축소하기 전에 디스크에 백업하십시오 . 구문은 다음과 같습니다.

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

3
, 1)부분을 제외하고 귀하의 답변에 동의합니다 . 문제는 1MB로 줄이면 정상적인 로그 크기로 이어지는 증가 이벤트 는 비용이 많이 들며 증가 속도가 기본값 인 10 %로 유지되면 그 수가 많아 질 것 입니다.
Aaron Bertrand

9

원치 않는 증가를 방지하려면 SQL Server 트랜잭션 로그를 올바르게 유지 관리해야합니다. 이는 트랜잭션 로그 백업을 자주 실행하는 것을 의미합니다. 그렇게하지 않으면 트랜잭션 로그가 가득 차서 커질 위험이 있습니다.

이 질문에 대한 답변 외에도 트랜잭션 로그 일반적인 신화를 읽고 이해하는 것이 좋습니다. 이 판독 값은 트랜잭션 로그를 이해하고이를 "삭제"하는 데 사용할 기술을 결정하는 데 도움이 될 수 있습니다.

에서 10 개의 가장 중요한 SQL Server 트랜잭션 로그 신화 :

오해 : SQL 서버가 너무 바쁩니다. SQL Server 트랜잭션 로그 백업을 만들고 싶지 않습니다.

SQL Server에서 가장 큰 성능 집약적 인 작업 중 하나는 온라인 트랜잭션 로그 파일의 자동 증가 이벤트입니다. 트랜잭션 로그 백업을 자주 수행하지 않으면 온라인 트랜잭션 로그가 가득 차서 커져야합니다. 기본 성장 크기는 10 %입니다. 데이터베이스 사용량이 많을수록 트랜잭션 로그 백업을 만들지 않으면 온라인 트랜잭션 로그가 더 빨리 커집니다. SQL Server 트랜잭션 로그 백업을 만들면 온라인 트랜잭션 로그가 차단되지 않지만 자동 증가 이벤트는 발생합니다. 온라인 트랜잭션 로그의 모든 활동을 차단할 수 있습니다

에서 트랜잭션 로그 신화 :

오해 : 정기적 인 로그 축소는 좋은 유지 관리 방법입니다

그릇된. 새로운 청크를 제로화해야하기 때문에 로그 증가는 매우 비쌉니다. 제로화가 완료 될 때까지 해당 데이터베이스에서 모든 쓰기 작업이 중지되며 디스크 쓰기 속도가 느리거나 자동 증가 크기가 클 경우 일시 중지가 커질 수 있으며 사용자는이를 알 수 있습니다. 이것이 성장을 피하려는 이유 중 하나입니다. 로그를 줄이면 로그가 다시 커지고 불필요하게 줄어드는 게임에서 디스크 작업을 낭비하게됩니다.


5

먼저 데이터베이스 복구 모델을 확인하십시오. 기본적으로 SQL Server Express Edition은 간단한 복구 모델에 대한 데이터베이스를 만듭니다 (실수하지 않은 경우).

Truncate_Only를 사용한 백업 로그 DatabaseName :

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile은 논리 로그 파일 이름을 제공합니다.

인용하다:

SQL Server 데이터베이스의 전체 트랜잭션 로그에서 복구

데이터베이스가 전체 복구 모델에 있고 TL 백업을 수행하지 않는 경우 SIMPLE로 변경하십시오.


이것이 dev 상자에서 로그 파일을 지우는 방법입니다. 모든 관련 백업 전략 등을 갖춘 입증 된 환경 나는 DBA에 맡긴다 :-)
Joon

TRUNCATE_ONLY는 더 이상 현재 버전의 SQL Server에서 옵션이 아니며이를 지원하는 버전에서는 권장되지 않습니다 ( Rachel의 답변 참조 ).
Aaron Bertrand

5

DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)명령을 사용하십시오 . 이것이 테스트 데이터베이스이고 공간을 절약 / 재생하려는 경우 도움이됩니다.

TX 로그에는 자라날 일종의 최소 / 안정 상태 크기가 있습니다. 복구 모델에 따라 로그를 축소하지 못할 수 있습니다. FULL 상태에서 TX 로그 백업을 발행하지 않으면 로그를 축소 할 수 없습니다. 영원히 커질 것입니다. TX 로그 백업이 필요하지 않은 경우 복구 모델을 단순으로 전환하십시오 .

어떤 상황에서도 로그 (LDF) 파일을 삭제하지 마십시오. 거의 즉각적인 데이터베이스 손상이 발생합니다. 요리! 끝난! 데이터가 손실되었습니다! "복구되지 않은"상태로두면 주 MDF 파일이 영구적으로 손상 될 수 있습니다.

트랜잭션 로그를 절대 삭제하지 마십시오. 데이터가 손실됩니다! 데이터베이스의 일부 를 효과적으로 삭제 하는 TX 로그 파일을 분리하고 "이름을 바꾸는 경우"(복구 모델에 관계없이) TX 로그에 데이터 일부가 있습니다.

TX Log를 삭제 한 사용자의 경우 더 많은 데이터를 잃기 전에 몇 가지 checkdb 명령을 실행하고 손상을 수정하는 것이 좋습니다.

바로이 주제에 폴 랜달의 블로그 게시물을 확인 나쁜 조언 .

또한 일반적으로 데이터를 심각하게 조각화 할 수 있으므로 MDF 파일에서 shrinkfile을 사용하지 마십시오. 자세한 내용은 잘못된 조언 섹션을 확인하십시오 ( "데이터 파일을 축소해서는 안되는 이유")

Paul의 웹 사이트를 확인하십시오-그는 이러한 질문을 다룹니다. 지난 달 그는 Myth A Day 시리즈 에서 이러한 많은 문제를 다루었습니다 .


+1 이것이 좋은 생각이 아니라는 것을 언급 한 첫 번째 답변이 되었기 때문에! OP는 테스트 데이터베이스를 지정하지만 더 일반적인 경우에는 가치가 있습니다.
Martin Smith

TX 로그를 삭제 한 경우-업데이트 이력서 추가했습니다!
ripvlan

4

로그 파일을 자르려면

  • 데이터베이스 백업
  • Enterprise Manager를 사용하거나 다음을 실행하여 데이터베이스를 분리하십시오. Sp_DetachDB [DBName]
  • 트랜잭션 로그 파일을 삭제하십시오. (또는 경우에 따라 파일 이름을 바꿉니다)
  • Sp_AttachDB [DBName]을 사용하여 데이터베이스를 다시 연결하십시오 .
  • 데이터베이스가 연결되면 새 트랜잭션 로그 파일이 작성됩니다.

로그 파일을 축소하려면

  • No_Log를 사용한 백업 로그 [DBName]
  • 다음 중 하나를 수행하여 데이터베이스를 축소하십시오.

    엔터프라이즈 관리자 사용 :-데이터베이스, 모든 작업, 데이터베이스 축소, 파일, 로그 파일 선택, 확인을 마우스 오른쪽 버튼으로 클릭하십시오.

    T-SQL 사용 : -Dbcc 축소 파일 ([Log_Logical_Name])

sp_helpdb를 실행하거나 Enterprise Manager에서 데이터베이스 속성을 확인하여 로그 파일의 논리적 이름을 찾을 수 있습니다.


트랜잭션 로그를 절대 삭제하지 마십시오. 데이터의 일부가 로그에 있습니다. 삭제하면 데이터베이스가 손상됩니다. 나는 투표를 거절하지 않습니다.
ripvlan

4

대부분의 SQL Server에서 경험 한 바에 따르면 트랜잭션 로그 백업은 없습니다. 전체 백업 또는 차등 백업은 일반적이지만 트랜잭션 로그 백업은 거의 없습니다. 따라서 디스크가 가득 찰 때까지 트랜잭션 로그 파일이 영구적으로 커집니다. 이 경우 복구 모델 은 " 단순 " 으로 설정해야합니다 . 시스템 데이터베이스 "model"및 "tempdb"도 수정하는 것을 잊지 마십시오.

데이터베이스 "tempdb"의 백업은 의미가 없으므로이 db의 복구 모델은 항상 "단순"해야합니다.


데이터베이스를 단순으로 설정하면 현재 상태에 관계없이 로그 파일이 축소되지 않습니다. 데이터베이스가 더 이상 커지지 않도록 할 수는 있지만 여전히 가능합니다.
Aaron Bertrand

4
  1. MDB 파일을 백업하십시오.
  2. SQL 서비스 중지
  3. 로그 파일 이름 바꾸기
  4. 서비스 시작

시스템이 새 로그 파일을 작성합니다.

이름이 바뀐 로그 파일을 삭제하거나 이동하십시오.


3

데이터베이스 로그 파일의 크기는 28GB였습니다.

이것을 줄이기 위해 무엇을 할 수 있습니까? 실제로 로그 파일은 트랜잭션이 발생할 때 SQL Server가 유지하는 파일 데이터입니다. 트랜잭션을 처리하기 위해 SQL Server는 동일한 페이지를 할당합니다. 그러나 거래가 완료된 후에는 같은 거래가있을 수 있기를 바라면서 갑자기 출시되지 않습니다. 이것은 공간을 유지합니다.

1 단계 : 먼저 데이터베이스 쿼리 탐색 검사 점에서이 명령 실행

2 단계 : 데이터베이스를 마우스 오른쪽 버튼으로 클릭 작업> 백업 백업 유형을 트랜잭션 로그로 선택 백업 주소를 유지하려면 대상 주소와 파일 이름을 추가합니다 (.bak).

이 단계를 다시 반복하고 이때 다른 파일 이름을 지정하십시오.

여기에 이미지 설명을 입력하십시오

3 단계 : 이제 데이터베이스로 이동 데이터베이스를 마우스 오른쪽 버튼으로 클릭

작업> 축소> 파일 사용되지 않은 공간을 해제하여 파일 형식을 로그 축소 작업으로 선택하십시오.

여기에 이미지 설명을 입력하십시오

4 단계 :

SQL 2014에서 정상적으로 로그 파일을 확인하십시오.

C : \ Program Files \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA

제 경우에는 28GB에서 1MB로 줄었습니다.


2

이 시도:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

TRUNCATE_ONLY는 더 이상 현재 버전의 SQL Server에서 옵션이 아니며이를 지원하는 버전에서는 권장되지 않습니다 ( Rachel의 답변 참조 ).
Aaron Bertrand

그것은 MSSQL Server 2005 Standard edition을 사용하여 저에게 효과적입니다
bksi

2

데이터베이스 → 특성 → 파일을 마우스 오른쪽 단추로 클릭 하고 다른 이름의 다른 로그 파일을 추가하고 다른 파일 이름의 이전 로그 파일과 동일한 경로를 설정하십시오.

데이터베이스는 새로 작성된 로그 파일을 자동으로 선택합니다.


1
  1. 백업 DB
  2. DB 분리
  3. 로그 파일 이름 바꾸기
  4. DB 연결 (이름이 바뀐 .ldf (로그 파일) 제거를 첨부하는 동안 선택하고 제거 버튼을 눌러 제거)
  5. 새로운 로그 파일이 재생성됩니다
  6. 이름이 바뀐 로그 파일을 삭제하십시오.

이것은 작동하지만 먼저 데이터베이스를 백업하는 것이 좋습니다.


1

다른 답변 중 일부는 저에게 효과가 없었습니다. 거래 로그가 가득 찼기 때문에 데이터베이스가 온라인 상태 일 때 체크 포인트를 만들 수 없었습니다 (얼마나 아이러니합니다). 그러나 데이터베이스를 비상 모드로 설정 한 후 로그 파일을 축소 할 수있었습니다.

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

0

예:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

TRUNCATE_ONLY는 더 이상 현재 버전의 SQL Server에서 옵션이 아니며이를 지원하는 버전에서는 권장되지 않습니다 ( Rachel의 답변 참조 ).
Aaron Bertrand

질문은 도움말 센터에 정의 된 스택 오버플로에 대한 주제가 아닙니다 . 그러한 질문에 대답하지 마십시오. 대신주의를 기울여 플래그를 지정해야하며 닫히거나 적절하게 마이그레이션됩니다.
Toby Speight

0

MSSQL 2017 및 SQL Server Management Studio 사용에 대한 약간의 답변. 나는 대부분이 지시에서 갔다 https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

최근 DB 백업이 있었으므로 트랜잭션 로그를 백업했습니다. 그런 다음 좋은 측정을 위해 다시 백업했습니다. 마지막으로 로그 파일을 축소하고 20G에서 7MB로갔습니다. 데이터 크기와 훨씬 비슷합니다. 2 년 전에 설치 한 이후로 트랜잭션 로그가 백업 된 적이 없다고 생각합니다.


-1

최소 크기로 DB 트랜잭션 로그 축소 :

  1. 백업 : 트랜잭션 로그
  2. 파일 축소 : 트랜잭션 로그
  3. 백업 : 트랜잭션 로그
  4. 파일 축소 : 트랜잭션 로그

여러 DB에서 테스트했습니다. 이 시퀀스는 작동합니다. .

일반적 으로 2MB로 줄어 듭니다 .

또는 스크립트로 :

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO

1
TRUNCATE_ONLY는 더 이상 현재 버전의 SQL Server에서 옵션이 아니며이를 지원하는 버전에서는 권장되지 않습니다 ( Rachel의 답변 참조 ).
Aaron Bertrand
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.