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)에 백업하는 것은 도움이 되지 않습니다.머신이 폭발하면 데이터베이스와 백업이 손실되기 때문입니다.네트워크 인프라스트럭처에 따라서는 로컬로 백업한 후 백그라운드에서 다른 위치로 전송하는 것이 더 합리적일 수 있습니다.어느 경우든 프라이머리 데이터베이스 머신에서 최대한 빨리 꺼내는 것이 좋습니다.
로그 백업을 정기적으로 실행한 후에는 로그 파일을 지금까지보다 더 합리적인 수준으로 축소하는 것이 합리적입니다.이것은 실행을 의미하는 것이 아닙니다.SHRINKFILE로그 파일이 1MB가 될 때까지 반복해서 로그 파일을 백업합니다. 로그를 자주 백업하더라도 발생할 수 있는 모든 동시 트랜잭션의 합계를 수용해야 합니다.로그 파일 자동 로그 이벤트는 비용이 많이 듭니다. 즉석 파일 초기화가 활성화되어 있는 데이터 파일과 달리 SQL Server는 파일을 0으로 만들어야 하며 이 동안 사용자 트랜잭션을 기다려야 하기 때문입니다.이 성장-수축-수축-수축-수축 루틴을 가능한 한 적게 하고 싶으시다면 사용자에게 비용을 지불하게 하고 싶지는 않을 것입니다.
축소하려면 로그를 두 번 백업해야 할 수 있습니다(감사합니다. 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.
다음으로, 로그의 증가는, 통상의 일상 사용이 아니고, 비정상 이벤트(예를 들면, 매년 봄의 클리닝이나 가장 큰 인덱스의 재구축)에 의한 것이었는지를 절대 확인할 필요가 있습니다.로그 파일을 터무니없이 작은 크기로 축소하여 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옵션은 더 이상 사용되지 않으며 현재 버전의 SQL Server에서 더 이상 사용할 수 없습니다. 번째, 째에 약에 있어요.FULL이 경우 로그 체인이 파괴되고 새로운 전체 백업이 필요합니다.데이터베이스를 분리하고 로그 파일을 삭제한 후 다시 연결합니다.이게 얼마나 위험할 수 있는지 강조할 수 없어요.데이터베이스가 복구되지 않거나 의심스러운 것으로 표시될 수 있으며 백업(있는 경우)으로 복구해야 할 수도 있습니다.
"데이터베이스 축소" 옵션을 사용합니다.
DBCC SHRINKDATABASE특히 로그 문제만 해결하면 되는 경우 유지보수 플랜 옵션은 좋지 않습니다.을 대상으로 하여 합니다.DBCC SHRINKFILE★★★★★★★★★★★★★★★★★」ALTER DATABASE ... MODIFY FILE(일부러)로그 파일을 1MB로 축소합니다.SQL Server를 사용하면 특정 시나리오에서 실행할 수 있고 여유 공간이 얼마나 되는지 알 수 있기 때문에 매력적으로 보입니다.데이터베이스가 읽기 전용으로 되어 있지 않은 경우(읽기 전용으로 되어 있는 경우),
ALTER DATABASE복구 모델에 관계없이 로그는 현재 트랜잭션을 수용해야 하기 때문에 불필요한 확장 이벤트만 많이 발생합니다.SQL Server가 이 공간을 천천히 고통스럽게 되돌릴 수 있도록 일시적으로 공간을 확보하는 것이 무슨 의미가 있습니까?두 번째 로그 파일을 만듭니다.이렇게 하면 디스크를 가득 채운 드라이브를 일시적으로 완화시킬 수 있지만, 이는 마치 반창고로 구멍이 난 폐를 고치는 것과 같습니다.문제가 있는 로그 파일은 다른 잠재적인 문제를 추가하는 것이 아니라 직접 처리해야 합니다.트랜잭션 로그의 액티비티를 다른 드라이브로 리다이렉트 하는 것 외에, 한 번에 사용할 수 있는 파일은 1개뿐이기 때문에(두 번째 데이터 파일과 달리) 두 번째 로그 파일은 실제로 아무런 도움이 되지 않습니다.Paul Randal은 여러 로그 파일이 나중에 문제가 될 수 있는 이유에 대해서도 설명합니다.
적극적으로 대처하다
로그 파일을 작은 양으로 축소하여 항상 작은 속도로 자동 로그로 만드는 것이 아니라 적당한 크기(동시 트랜잭션의 최대 합계를 수용할 수 있는 크기)로 설정하고 적절한 자동 로그 설정을 폴백으로 설정합니다.따라서 단일 트랜잭션을 충족하기 위해 여러 번 확장할 필요가 없으며, 정상적인 비즈니스 운영 중에 확장할 필요가 있는 경우는 거의 없습니다.
여기서 가장 나쁜 설정은 1MB 증가 또는 10% 증가입니다.이상하게도 SQL Server의 디폴트값입니다(데이터 파일의 경우 1MB, 로그 파일의 경우 10%).전자는 요즘 시대에 너무 작으며 후자는 매번 더 길고 긴 이벤트로 이어집니다(예를 들어 로그 파일은 500MB, 첫 번째 증가량은 50MB, 다음 증가량은 55MB, 다음 증가량은 60.5MB 등). 그리고 느린 I/O에서는 이 곡선을 볼 수 있습니다.
추가 정보
여기서 그치지 마십시오. 로그 파일 축소에 대한 대부분의 조언은 본질적으로 좋지 않고 잠재적으로 심각한 문제가 될 수 있지만, 디스크 공간을 확보하는 것보다 데이터 무결성에 더 신경을 쓰는 사람도 있습니다.
2009년에 쓴 블로그의 투고가 있는데, 그 때, 「로그 파일을 축소하는 방법」의 투고가 몇개인가 있었습니다.
4년 전 블로그 게시물 Brent Ozar는 SQL Server Magazine 기사에 대해 여러 리소스를 지적하면서 발표하지 말았어야 했다고 말했습니다.
Paul Randal의 블로그 투고에서는 t-log 유지보수가 중요한 이유와 데이터 파일을 축소해서는 안 되는 이유를 설명하고 있습니다.
Mike Walsh는 로그 파일을 즉시 축소할 수 없는 이유 등 이러한 측면에 대한 훌륭한 답변을 가지고 있습니다.
-- 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 SHROCKFILE (Transact-SQL)
먼저 백업을 하는 것이 좋습니다.
면책사항: 이 답변의 아래에 있는 코멘트를 주의 깊게 읽어 보시고, 반드시 수락된 답변을 확인하시기 바랍니다.거의 5년 전에 말했듯이:
이 솔루션이 적절하지 않거나 최적의 솔루션이 아닌 상황에 대해 코멘트를 추가할 수 있는 사람은 아래 코멘트를 해 주십시오.
알고보니 :-)
원답:
데이터베이스 이름을 오른쪽 클릭합니다.
작업 → 축소 → 데이터베이스 선택
그런 다음! 을 클릭합니다.
보통 데이터베이스 파일이 들어 있는 Windows 탐색기 디렉토리를 열어서 바로 효과를 볼 수 있습니다.
사실 이게 먹혀들어서 놀랐어요!평소에는 DBCC를 사용한 적이 있습니다만, DBCC를 사용해 본 결과 아무것도 줄어들지 않았기 때문에 GUI(2005)를 사용해 보니 17GB의 용량을 10초 만에 확보할 수 있었습니다.
전체 복구 모드에서는 이 작업이 작동하지 않을 수 있으므로 먼저 로그를 백업하거나 단순 복구로 변경한 다음 파일을 축소해야 합니다.[고맙다 @onupdatecascade]
--
PS: 이 문제의 위험성에 대한 일부의 의견은 감사하지만, 제 환경에서는 특히 항상 풀백업을 먼저 하기 때문에 제가 직접 이 작업을 수행하는 데 아무런 문제가 없었습니다.따라서 계속 진행하기 전에 귀사의 환경이 무엇인지, 그리고 이것이 백업 전략과 작업 안정성에 미치는 영향을 고려하십시오.제가 하고 있던 일은 Microsoft가 제공하는 기능을 사람들에게 알려준 것뿐이에요!
아래는 트랜잭션 로그를 축소하는 스크립트입니다만, 축소하기 전에 트랜잭션 로그를 백업하는 것이 좋습니다.
파일을 축소하는 것만으로 대량의 데이터가 손실되어 재해 시 생명을 구할 수 있습니다.트랜잭션 로그에는 타사 트랜잭션 로그 판독기를 사용하여 읽을 수 있는 유용한 데이터가 많이 포함되어 있습니다(수동으로 읽을 수는 있지만 매우 많은 노력을 들여야 함).
트랜잭션 로그는 특정 시점 복구에 있어서도 필수적이므로 폐기하지 말고 미리 백업해야 합니다.
다음은 사람들이 트랜잭션 로그에 저장된 데이터를 사용하여 복구를 수행한 게시물입니다.
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 연결
- 새 로그 파일이 다시 생성됩니다.
- 이름이 변경된 로그 파일을 삭제합니다.
로그 백업을 하고 있지 않은 것 같습니다.(로그가 잘립니다).복구 모델을 완전에서 단순으로 변경하는 것이 좋습니다.이렇게 하면 로그가 부풀어 오르는 것을 방지할 수 있습니다.
트랜잭션 로그를 복원에 사용하지 않는 경우(즉, 전체 백업만 수행함) 복구 모드를 "Simple"로 설정할 수 있습니다. 그러면 트랜잭션 로그가 매우 짧은 시간 내에 축소되어 다시 꽉 차지 않습니다.
SQL 7 또는 2000을 사용하는 경우 데이터베이스 옵션 탭에서 "체크포인트에서 로그 삭제"를 사용할 수 있습니다.이것도 같은 효과가 있습니다.
특정 시점으로 복원할 수 없기 때문에 프로덕션 환경에서는 이 방법을 권장하지 않습니다.
SQL Server 트랜잭션 로그는 원치 않는 증가를 방지하기 위해 적절하게 관리해야 합니다.따라서 트랜잭션 로그 백업을 충분히 자주 실행할 수 있습니다.이렇게 하지 않으면 트랜잭션 로그가 꽉 차서 커질 위험이 있습니다.
이 질문에 대한 답변 외에도 트랜잭션 로그의 일반적인 속설을 읽고 이해하는 것이 좋습니다.이러한 판독치는 트랜잭션 로그를 이해하고 트랜잭션 로그를 "삭제"하기 위해 사용할 기술을 결정하는 데 도움이 될 수 있습니다.
SQL Server 트랜잭션 로그의 가장 중요한 10가지 신화:
속설: SQL Server 사용률이 너무 높습니다.SQL Server 트랜잭션 로그 백업을 만들지 않음
SQL Server에서 가장 퍼포먼스가 높은 작업 중 하나는 온라인 트랜잭션 로그 파일의 자동 확장 이벤트입니다.트랜잭션 로그 백업을 자주 하지 않으면 온라인 트랜잭션 로그가 꽉 차서 커져야 합니다.기본 증가 크기는 10%입니다.데이터베이스 사용량이 많을수록 트랜잭션 로그 백업이 생성되지 않으면 온라인 트랜잭션 로그가 더 빨리 증가 SQL Server 트랜잭션 로그 백업을 생성해도 온라인 트랜잭션 로그는 차단되지 않지만 자동 확장 이벤트가 발생합니다.온라인 트랜잭션 로그의 모든 액티비티를 차단할 수 있습니다.
트랜잭션 로그 속설:
통념: 정기적인 로그 축소는 유지 보수에 도움이 됩니다.
FALSE. 새 청크를 지워야 하므로 로그 증가 비용이 많이 듭니다.제로잉이 완료될 때까지 모든 쓰기 작업은 데이터베이스에서 중지됩니다. 디스크 쓰기가 느리거나 자동 경로 크기가 크면 이 일시 중지가 엄청날 수 있으며 사용자가 알아차릴 수 있습니다.성장을 피하고 싶은 이유 중 하나입니다.로그를 축소하면 로그가 다시 커지기 때문에 불필요한 축소 및 성장 게임에 디스크 조작을 낭비하게 됩니다.
로그 파일 없이 데이터베이스가 첨부된다는 보장은 없으므로 John이 권장하는 이 기술은 권장하지 않습니다.데이터베이스를 완전에서 단순으로 변경하고 체크포인트를 강제 적용한 후 몇 분간 기다립니다.SQL Server가 로그를 지우고 DBCC SHROCKFILE을 사용하여 로그를 축소할 수 있습니다.
까지의 대부분의 파일이 만, 가 이 을 사용하고 있는 는, 이 파일을 사용해 주세요.FULL데이터베이스를 복원해야 할 경우에 대비하여 백업을 보관하고 이러한 답변의 많은 방법에서 제시된 대로 로그 파일을 잘라내거나 삭제하지 마십시오.
로그 파일을 삭제하면(잘라내기, 폐기, 삭제 등을 통해) 백업 체인이 끊어지고 다음 전체 또는 차등 백업이 수행될 때까지 마지막 전체, 차등 또는 트랜잭션 로그 백업 이후 시점으로 복원할 수 없습니다.
다음 MicrosoftBACKUP 기사 참조
로그 체인이 끊어지므로 트랜잭션로그를 수동으로 절단할 때는 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)
하다를 사용하세요.DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)명령어를 입력합니다.이것이 테스트 데이터베이스이며 공간을 절약/재청구하려는 경우 도움이 됩니다.
단, TX 로그는 확장 가능한 최소/안정 상태 크기를 가집니다.리커버리 모델에 따라서는 로그를 축소할 수 없는 경우가 있습니다.완전 상태로 TX 로그 백업을 발행하지 않으면 로그는 축소할 수 없습니다.영원히 증가합니다.TX 로그 백업이 필요하지 않은 경우 복구 모델을 단순으로 전환하십시오.
또한 어떤 경우에도 로그(LDF) 파일을 삭제하지 마십시오.즉석에서 데이터베이스가 손상됩니다.익었어!완료! 데이터 손실!"복구되지 않은" 상태로 두면 메인 MDF 파일이 영구적으로 손상될 수 있습니다.
트랜잭션 로그를 절대 삭제하지 마십시오. 데이터가 손실됩니다.데이터 일부가 TX 로그에 있습니다(복구 모델에 관계없이).데이터베이스의 일부를 효과적으로 삭제하는 TX 로그 파일을 분리하여 "이름 변경"한 경우.
TX 로그를 삭제한 사용자의 경우 몇 가지 checkdb 명령을 실행하여 더 많은 데이터가 손실되기 전에 손상을 복구하는 것이 좋습니다.
Paul Randal의 블로그 투고에서 바로 이 주제에 대한 잘못된 조언을 확인하세요.
또한 일반적으로 MDF 파일에는 shrink 파일을 사용하지 마십시오.데이터가 심각하게 fragment화될 수 있습니다.자세한 내용은 "Bad Advisor" 섹션을 참조하십시오("데이터 파일을 축소하면 안 되는 이유").
폴의 웹사이트를 확인해 보세요. 폴은 바로 이런 질문들을 다룹니다.지난 달, 그는 그의 Myth A Day 시리즈에서 이러한 이슈들 중 많은 것을 살펴보았다.
데이터베이스 로그파일이 28GB인 경우는 이쪽에서 발생했습니다.
이를 줄이기 위해 무엇을 할 수 있을까요?실제로 로그 파일은 트랜잭션이 발생할 때 SQL 서버가 보관하는 파일 데이터입니다.트랜잭션을 처리하기 위해 SQL 서버는 동일한 페이지를 할당합니다.그러나 거래가 완료된 후 같은 거래가 있을 수 있다는 희망을 가지고 갑자기 출시되는 것은 아닙니다.이렇게 하면 공간이 꽉 차요.
순서 1: 먼저 데이터베이스 쿼리 탐색 체크 포인트에서 이 명령어를 실행합니다.
순서 2: 데이터베이스 태스크 우클릭> 백업 유형을 트랜잭션로그로 선택백업 데이터(.bak)를 보존할 수신처 주소와 파일명을 추가합니다.
이 단계를 반복한 후 다른 파일 이름을 지정하십시오.
3단계: 데이터베이스로 이동 데이터베이스 우클릭
[태스크] > [축소] > [파일] : [로그 축소]액션으로서 미사용 영역을 해방하는 파일유형을 선택합니다.
순서 4:
SQL 2014의 로그 파일을 정상적으로 체크합니다.이 파일은 다음 웹 사이트에서 찾을 수 있습니다.
C:\Program Files\Microsoft SQL Server\MSQL12.MSQL 2014 EXPRESS\MSSQL\DATA
내 경우 28GB에서 1MB로 감소
로그 파일을 잘라내려면:
- 데이터베이스 백업
- Enterprise Manager를 사용하거나 Sp_DetachDB [DBName]를 실행하여 데이터베이스를 분리합니다.
- 트랜잭션 로그 파일을 삭제합니다.(혹시 파일 이름 변경)
- Sp_AttachDB [DBName]를 사용하여 데이터베이스를 다시 연결합니다.
- 데이터베이스가 연결되면 새 트랜잭션 로그 파일이 생성됩니다.
로그 파일을 축소하려면:
- No_Log 백업로그 [DBName]
다음 중 하나로 데이터베이스를 축소합니다.
엔터프라이즈 관리자 사용:- 데이터베이스를 마우스 오른쪽 버튼으로 클릭합니다. 모든 작업, 데이터베이스 축소, 파일, 로그 파일 선택, OK.
T-SQL 사용 :- Dbcc Shrink file ([Log_Logical_Name])
로그 파일의 논리명은 sp_helpdb를 실행하거나 Enterprise Manager에서 데이터베이스 속성을 확인하여 확인할 수 있습니다.
먼저 데이터베이스 복구 모델을 확인합니다.기본적으로 SQL Server Express Edition은 단순 복구 모델용 데이터베이스를 생성합니다(틀리지 않은 경우).
백업 로그 DatabaseName with Truncate_한정:
DBCC ShrinkFile(yourLogical_LogFileName, 50)
SP_helpfile은 논리 로그 파일 이름을 제공합니다.
참조처:
SQL Server 데이터베이스의 전체 트랜잭션 로그에서 복구
데이터베이스가 전체 복구 모델이고 TL 백업을 수행하지 않는 경우 단순으로 변경합니다.
대부분의 SQL Server에서는 트랜잭션 로그 백업이 없습니다.전체 백업 또는 차등 백업은 일반적인 작업 방식이지만 트랜잭션 로그 백업은 거의 없습니다.따라서 트랜잭션 로그 파일은 디스크가 가득 찰 때까지 계속 커집니다.이 경우 복구 모델을 "단순"으로 설정해야 합니다.시스템 데이터베이스 "model"과 "tempdb"도 수정해야 합니다.
데이터베이스 "tempdb"의 백업은 의미가 없으므로 이 DB의 복구 모델은 항상 "단순"해야 합니다.
- MDB 파일을 백업합니다.
- SQL 서비스 중지
- 로그 파일 이름 변경
- 서비스를 시작합니다.
(새로운 로그 파일이 생성됩니다).
이름이 변경된 로그 파일을 삭제하거나 이동합니다.
Database → Properties → file → 다른 이름의 다른 로그 파일을 마우스 오른쪽 버튼으로 클릭하고 다른 파일 이름의 이전 로그 파일과 경로를 동일하게 설정합니다.
데이터베이스는 새로 생성된 로그 파일을 자동으로 선택합니다.
이것을 시험해 보세요.
USE DatabaseName
GO
DBCC SHRINKFILE( TransactionLogName, 1)
BACKUP LOG DatabaseName WITH TRUNCATE_ONLY
DBCC SHRINKFILE( TransactionLogName, 1)
GO
MSSQL 2017 및 SQL Server 관리 스튜디오에 대한 약간 업데이트된 답변입니다.저는 주로 이 설명서에서 따왔습니다.https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/
최근에 DB 백업이 있어서 트랜잭션 로그를 백업했습니다.그리고 나서 나는 그것을 다시 백업했다.마지막으로 로그 파일을 축소하여 데이터 크기에 맞게 20G에서 7MB로 늘렸습니다.2년 전 설치 이후 트랜잭션 로그가 백업된 적이 없었던 것 같습니다.집안일을 달력에 올려놔야 해요.
- 백업 DB
- DB 분리
- 로그 파일 이름 변경
- DB를 첨부합니다(첨부하는 동안 이름이 변경된 .ldf(로그 파일)를 삭제합니다).선택한 후 Remove(삭제) 버튼을 눌러 삭제합니다.)
- 새 로그 파일이 다시 생성됩니다.
- 이름이 변경된 로그 파일을 삭제합니다.
이렇게 하면 작동하지만 먼저 데이터베이스를 백업하는 것이 좋습니다.
다른 답변 중 일부는 나에게 효과가 없었습니다.트랜잭션 로그가 가득 찼기 때문에 db가 온라인 상태일 때 체크포인트를 작성할 수 없었습니다.그러나 데이터베이스를 긴급 모드로 설정한 후 로그 파일을 축소할 수 있었습니다.
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
'code' 카테고리의 다른 글
| PowerShell: 텍스트 파일 내용 전체를 변수에 저장 (0) | 2023.04.08 |
|---|---|
| HTML: 유효한 ID 속성 값입니까? (0) | 2023.04.08 |
| 빌드 후 이벤트 실행 PowerShell (0) | 2023.04.08 |
| 다른 div 내부의 div를 수직으로 중심 맞춤 (0) | 2023.04.08 |
| 정적 HTML 페이지에 favicon 추가 (0) | 2023.04.08 |