SQL Server 트랜잭션 로그를 지우려면 어떻게합니까?
저는 SQL 전문가가 아니며 기본 이외의 작업을 수행해야 할 때마다 사실을 상기시킵니다. 크기가 크지 않은 테스트 데이터베이스가 있지만 트랜잭션 로그는 확실합니다. 트랜잭션 로그를 지우려면 어떻게합니까?
로그 파일을 더 작게 만들면 예상치 못한 증가가 다시 발생할 것으로 예상되는 시나리오를 위해 예약해야합니다. 로그 파일이 다시 같은 크기로 커지면 임시로 줄임으로써 크게 달성되지 않습니다. 이제 데이터베이스의 복구 목표에 따라 수행해야 할 조치입니다.
먼저 전체 백업을 수행하십시오.
문제가 발생한 경우 복원 할 수 있는지 확인하지 않고 데이터베이스를 변경하지 마십시오.
특정 시점 복구에 관심이있는 경우
특정 시점 복구의 경우 전체 또는 차등 백업 이외의 다른 것으로 복원 할 수 있다는 것을 의미합니다.
데이터베이스가 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. CHECKPOINTevents는 로그를 제어하는 데 도움이되며 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 년 전에 말했듯이 :
이것이 적절하거나 최적의 솔루션이 아닌 상황에 대해 추가 할 의견이 있으면 아래에 의견을주십시오.
데이터베이스 이름을 마우스 오른쪽 버튼으로 클릭하십시오.
작업 → 축소 → 데이터베이스를 선택하십시오.
그런 다음 OK!를 클릭하십시오 .
일반적으로 데이터베이스 파일이 포함 된 Windows 탐색기 디렉토리를 열면 즉시 효과를 볼 수 있습니다.
나는 이것이 실제로 효과가 있다는 것에 놀랐다! 일반적으로 나는 전에 DBCC를 사용했지만 그저 시도했지만 아무것도 축소하지 않았으므로 GUI (2005)를 사용해 보았고 10 초 만에 17GB를 확보했습니다.
전체 복구 모드에서는 작동하지 않을 수 있으므로 먼저 로그를 백업하거나 단순 복구로 변경 한 다음 파일을 축소해야합니다. [@onupdatecascade 감사합니다]
-
추신 : 나는 이것의 위험에 대해 어떤 사람들이 논평 한 것에 감사하지만, 내 환경에서는 항상 전체 백업을 먼저 수행하기 때문에 특히 나 자신에게 문제가 없었습니다. 따라서 환경이 무엇인지, 그리고 계속하기 전에 이것이 백업 전략 및 작업 보안에 미치는 영향을 고려하십시오. 내가했던 것은 사람들이 Microsoft에서 제공하는 기능을 가리 키도록하는 것입니다!
-- 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)
먼저 백업하고 싶을 수도 있습니다.
아래는 트랜잭션 로그를 축소하는 스크립트이지만 트랜잭션 로그를 축소하기 전에 백업하는 것이 좋습니다.
파일을 축소하면 재난 발생시 생명을 구할 수있는 많은 데이터가 손실됩니다. 트랜잭션 로그에는 타사 트랜잭션 로그 판독기를 사용하여 읽을 수있는 유용한 데이터가 많이 포함되어 있습니다 (수동으로 읽을 수는 있지만 많은 노력을 기울임).
트랜잭션 로그는 특정 시점으로 복구해야 할 때도 반드시 필요하므로 버리지 말고 미리 백업하십시오.
사람들이 트랜잭션 로그에 저장된 데이터를 사용하여 복구를 수행 한 게시물은 다음과 같습니다.
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가 사용 중임을 의미합니다. 이 경우 연속으로 여러 번 실행하거나 데이터베이스 활동을 줄이는 방법을 찾으십시오.
간단하고 매우 우아 하고 잠재적으로 위험한 방법이 있습니다.
- 백업 DB
- DB 분리
- 로그 파일 이름 바꾸기
- DB 첨부
- 새로운 로그 파일이 재생성됩니다
- 이름이 바뀐 로그 파일을 삭제하십시오.
로그 백업을 수행하지 않는 것 같습니다. 로그를 자릅니다. 내 조언은 복구 모델을 전체 에서 단순 으로 변경하는 것 입니다. 이렇게하면 로그 팽창이 방지됩니다.
복원에 트랜잭션 로그를 사용하지 않는 경우 (즉, 전체 백업 만 수행하는 경우) 복구 모드를 "단순"으로 설정할 수 있으며 트랜잭션 로그가 매우 짧아지고 다시 채워지지 않습니다.
SQL 7 또는 2000을 사용하는 경우 데이터베이스 옵션 탭에서 "로그온 검사 점 잘라 내기"를 활성화 할 수 있습니다. 이것은 동일한 효과가 있습니다.
특정 시점으로 복원 할 수 없으므로 프로덕션 환경에서는 권장하지 않습니다.
지금까지 대부분의 답변은 실제로 트랜잭션 로그 파일이 필요하지 않다고 가정하지만 데이터베이스가 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)
원치 않는 증가를 방지하려면 SQL Server 트랜잭션 로그를 올바르게 유지 관리해야합니다. 이는 트랜잭션 로그 백업을 자주 실행하는 것을 의미합니다. 그렇게하지 않으면 트랜잭션 로그가 가득 차서 커질 위험이 있습니다.
이 질문에 대한 답변 외에도 트랜잭션 로그 일반적인 신화를 읽고 이해하는 것이 좋습니다. 이 판독 값은 트랜잭션 로그를 이해하고이를 "삭제"하는 데 사용할 기술을 결정하는 데 도움이 될 수 있습니다.
에서 10 개의 가장 중요한 SQL Server 트랜잭션 로그 신화 :
오해 : SQL 서버가 너무 바쁩니다. SQL Server 트랜잭션 로그 백업을 만들고 싶지 않습니다.
SQL Server에서 가장 큰 성능 집약적 인 작업 중 하나는 온라인 트랜잭션 로그 파일의 자동 증가 이벤트입니다. 트랜잭션 로그 백업을 자주 수행하지 않으면 온라인 트랜잭션 로그가 가득 차서 커져야합니다. 기본 성장 크기는 10 %입니다. 데이터베이스 사용량이 많을수록 트랜잭션 로그 백업을 만들지 않으면 온라인 트랜잭션 로그가 더 빨리 커집니다. SQL Server 트랜잭션 로그 백업을 만들면 온라인 트랜잭션 로그가 차단되지 않지만 자동 증가 이벤트가 발생합니다. 온라인 트랜잭션 로그의 모든 활동을 차단할 수 있습니다
에서 트랜잭션 로그 신화 :
통념 : 정기적 인 로그 축소는 좋은 유지 관리 방법입니다
그릇된. 새로운 청크를 제로화해야하기 때문에 로그 증가는 매우 비쌉니다. 제로화가 완료 될 때까지 해당 데이터베이스에서 모든 쓰기 작업이 중지되고 디스크 쓰기 속도가 느리거나 자동 증가 크기가 클 경우 일시 중지가 커져 사용자가 알 수 있습니다. 그것이 성장을 피하고 싶은 이유 중 하나입니다. 로그를 줄이면 로그가 다시 커지고 불필요하게 줄어드는 게임에서 디스크 작업을 낭비하게됩니다.
John이 권장하는이 기술은 데이터베이스가 로그 파일없이 연결될 것이라는 보장이 없으므로 권장되지 않습니다. 데이터베이스를 전체에서 단순으로 변경하고 체크 포인트를 강제 실행 한 후 몇 분 정도 기다리십시오. SQL Server는 로그를 지우고 DBCC SHRINKFILE을 사용하여 축소 할 수 있습니다.
먼저 데이터베이스 복구 모델을 확인하십시오. 기본적으로 SQL Server Express Edition은 간단한 복구 모델에 대한 데이터베이스를 만듭니다 (실수하지 않은 경우).
Truncate_Only를 사용한 백업 로그 DatabaseName :
DBCC ShrinkFile(yourLogical_LogFileName, 50)
SP_helpfile은 논리 로그 파일 이름을 제공합니다.
인용하다:
SQL Server 데이터베이스의 전체 트랜잭션 로그에서 복구
데이터베이스가 전체 복구 모델에 있고 TL 백업을 수행하지 않는 경우 SIMPLE로 변경하십시오.
DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)명령을 사용하십시오 . 이것이 테스트 데이터베이스이고 공간을 절약 / 재생하려는 경우 도움이됩니다.
TX 로그에는 자라날 일종의 최소 / 안정 상태 크기가 있습니다. 복구 모델에 따라 로그를 축소하지 못할 수 있습니다. FULL 상태에서 TX 로그 백업을 발행하지 않으면 로그를 축소 할 수 없습니다. 영원히 커질 것입니다. TX 로그 백업이 필요하지 않은 경우 복구 모델을 Simple로 전환하십시오 .
어떤 상황에서도 로그 (LDF) 파일을 삭제하지 마십시오. 거의 즉각적인 데이터베이스 손상이 발생합니다. 요리! 끝난! 데이터가 손실되었습니다! "복구되지 않은"상태로두면 주 MDF 파일이 영구적으로 손상 될 수 있습니다.
트랜잭션 로그를 절대 삭제하지 마십시오. 데이터가 손실됩니다! 데이터베이스의 일부 를 효과적으로 삭제 하는 TX 로그 파일을 분리하고 "이름을 바꾸는 경우"(복구 모델에 관계없이) TX 로그에 데이터 일부가 있습니다.
TX Log를 삭제 한 사용자의 경우 더 많은 데이터를 잃기 전에 몇 가지 checkdb 명령을 실행하고 손상을 수정하는 것이 좋습니다.
바로이 주제에 폴 랜달의 블로그 게시물을 확인 나쁜 조언 .
또한 일반적으로 데이터를 심각하게 조각화 할 수 있으므로 MDF 파일에서 shrinkfile을 사용하지 마십시오. 자세한 내용은 잘못된 조언 섹션을 확인하십시오 ( "데이터 파일을 축소해서는 안되는 이유")
Paul의 웹 사이트를 확인하십시오-그는 이러한 질문을 다룹니다. 지난 달 그는 Myth A Day 시리즈 에서 이러한 많은 문제를 다루었습니다 .
로그 파일을 자르려면
- 데이터베이스 백업
- Enterprise Manager를 사용하거나 다음을 실행하여 데이터베이스를 분리하십시오. Sp_DetachDB [DBName]
- 트랜잭션 로그 파일을 삭제하십시오. (또는 경우에 따라 파일 이름을 바꿉니다)
- Sp_AttachDB [DBName]을 사용하여 데이터베이스를 다시 연결하십시오 .
- 데이터베이스가 연결되면 새 트랜잭션 로그 파일이 작성됩니다.
로그 파일을 축소하려면
- No_Log를 사용한 백업 로그 [DBName]
다음 중 하나를 수행하여 데이터베이스를 축소하십시오.
엔터프라이즈 관리자 사용 :-데이터베이스, 모든 작업, 데이터베이스 축소, 파일, 로그 파일 선택, 확인을 마우스 오른쪽 버튼으로 클릭하십시오.
T-SQL 사용 : -Dbcc Shrinkfile ([Log_Logical_Name])
sp_helpdb를 실행하거나 Enterprise Manager에서 데이터베이스 속성을 확인하여 로그 파일의 논리적 이름을 찾을 수 있습니다.
대부분의 SQL Server에서 경험 한 바에 따르면 트랜잭션 로그 백업은 없습니다. 전체 백업 또는 차등 백업은 일반적이지만 트랜잭션 로그 백업은 거의 없습니다. 따라서 디스크가 가득 찰 때까지 트랜잭션 로그 파일이 영구적으로 커집니다. 이 경우 복구 모델 은 " 단순 " 으로 설정해야합니다 . 시스템 데이터베이스 "model"및 "tempdb"도 수정하는 것을 잊지 마십시오.
데이터베이스 "tempdb"의 백업은 의미가 없으므로이 db의 복구 모델은 항상 "단순"해야합니다.
- MDB 파일을 백업하십시오.
- SQL 서비스 중지
- 로그 파일 이름 바꾸기
- 서비스 시작
시스템이 새 로그 파일을 작성합니다.
이름이 바뀐 로그 파일을 삭제하거나 이동하십시오.
이 시도:
USE DatabaseName
GO
DBCC SHRINKFILE( TransactionLogName, 1)
BACKUP LOG DatabaseName WITH TRUNCATE_ONLY
DBCC SHRINKFILE( TransactionLogName, 1)
GO
데이터베이스 → 특성 → 파일을 마우스 오른쪽 단추로 클릭 하고 다른 이름의 다른 로그 파일을 추가하고 다른 파일 이름의 이전 로그 파일과 동일한 경로를 설정하십시오.
데이터베이스는 새로 생성 된 로그 파일을 자동으로 선택합니다.
- 백업 DB
- DB 분리
- 로그 파일 이름 바꾸기
- DB 연결 (이름이 바뀐 .ldf (로그 파일) 제거를 첨부하는 동안 선택하고 제거 버튼을 눌러 제거)
- 새로운 로그 파일이 재생성됩니다
- 이름이 바뀐 로그 파일을 삭제하십시오.
이것은 작동하지만 먼저 데이터베이스를 백업하는 것이 좋습니다.
데이터베이스 로그 파일의 크기는 28GB였습니다.
이것을 줄이기 위해 무엇을 할 수 있습니까? 실제로 로그 파일은 트랜잭션이 발생할 때 SQL Server가 유지하는 파일 데이터입니다. 트랜잭션을 처리하기 위해 SQL Server는 동일한 페이지를 할당합니다. 그러나 거래가 완료된 후에는 같은 거래가있을 수 있기를 바라면서 갑자기 출시되지 않습니다. 이것은 공간을 유지합니다.
1 단계 : 먼저 데이터베이스 쿼리 탐색 검사 점에서이 명령 실행
2 단계 : 데이터베이스를 마우스 오른쪽 버튼으로 클릭 작업> 백업 백업 유형을 트랜잭션 로그로 선택 백업 주소를 유지하려면 대상 주소와 파일 이름을 추가합니다 (.bak).
이 단계를 다시 반복하십시오. 이때 다른 파일 이름을 지정하십시오.
3 단계 : 이제 데이터베이스로 이동 데이터베이스를 마우스 오른쪽 버튼으로 클릭
작업> 축소> 파일 사용되지 않은 공간을 해제하여 파일 형식을 로그 축소 작업으로 선택하십시오.
4 단계 :
SQL 2014에서 정상적으로 로그 파일을 확인하십시오.
C : \ Program Files \ Microsoft SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA
제 경우에는 28GB에서 1MB로 줄었습니다.
예:
DBCC SQLPERF(LOGSPACE)
BACKUP LOG Comapny WITH TRUNCATE_ONLY
DBCC SHRINKFILE (Company_log, 500)
DBCC SQLPERF(LOGSPACE)
다른 답변 중 일부는 저에게 효과가 없었습니다. 거래 로그가 가득 찼기 때문에 데이터베이스가 온라인 상태 일 때 체크 포인트를 만들 수 없었습니다 (얼마나 아이러니합니다). 그러나 데이터베이스를 비상 모드로 설정 한 후 로그 파일을 축소 할 수있었습니다.
alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);
최소 크기로 DB 트랜잭션 로그 축소 :
- 백업 : 트랜잭션 로그
- 파일 축소 : 트랜잭션 로그
- 백업 : 트랜잭션 로그
- 파일 축소 : 트랜잭션 로그
여러 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
참고 URL : https://stackoverflow.com/questions/56628/how-do-you-clear-the-sql-server-transaction-log
'Programing' 카테고리의 다른 글
| 메소드 리턴 유형을 일반으로 만들려면 어떻게해야합니까? (0) | 2020.02.09 |
|---|---|
| 프로그램 내에서 64 비트 JVM 또는 32 비트 JVM에서 실행 중인지 어떻게 알 수 있습니까? (0) | 2020.02.09 |
| 배경 아래에 나타나는 부트 스트랩 모달 (0) | 2020.02.09 |
| JavaScript를 통해 도메인 간 POST 요청을 보내려면 어떻게합니까? (0) | 2020.02.09 |
| WPF에서 x : Name과 Name 특성의 차이점은 무엇입니까? (0) | 2020.02.09 |