로그 파일을 축소해도 크기가 줄어들지 않습니다


23

350MB 데이터 파일 (.mdf)과 4.9GB 로그 파일 (.ldf) 이있는 데이터베이스가 있습니다 . 복구 모델이로 설정되었습니다 FULL.

로그 파일을 축소하려고하면 축소되지 않습니다.

데이터베이스 축소가 좋지 않아서 수행하면 안된다는 것을 알고 있습니다. 그러나 여전히 로그 파일을 축소하기 위해 노력하고 있습니다.

내가 달릴 때

DBCC SQLPerf(logspace) 

나는 로그 크기가 발견 4,932메가바이트 및 사용 로그 공간이 98.76 % !

그런 다음이 명령을 시도했습니다

USE <databasename>;
DBCC loginfo;

이제 거의 모든 VLF는 "상태 2"이므로 모두 사용 중입니다.

로그 백업을 시도한 다음 로그 파일을 축소하려고했습니다. 축소해도 크기가 줄어들지 않았습니다.

복구 모델을 변경하고 SIMPLE다시 축소를 시도했지만 도움이되지 않았습니다.

미결 거래를 확인했습니다

DBCC opentran (database);

거래가 현재 열려 있지 않은 것을 발견했습니다.

로그 파일 축소를 방해하는 이유는 무엇입니까? 이 문제를 어떻게 해결할 수 있습니까?

답변:


12

여기 내 질문에 대한 답이 있습니다.

아래 쿼리를 실행하여 로그 파일의 재사용 대기에 대한 정보를 얻으십시오.

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DBName'

나는 다음과 같은 결과를 얻었다 :

log_reuse_wait_desc
-------------------
REPLICATION 

복제를 제거한 후에도 데이터베이스에 일부 복제 관련 개체가 남아 있습니다.

데이터베이스에서 복제를 제거하려면 sp_removedbreplication사용할 수 있습니다. 그러나 당시에는 복제가 활성화되지 않았고 실제로 복제가 오래 전에 제거되었으므로 우리에게는 효과가 없었습니다.

해결책은 SQL Server의 가져 오기 옵션을 사용하여 데이터베이스 내용을 다른 데이터베이스로 가져 오는 것입니다.


나는 같은 문제가 있었고 이것을 사용하여 db에 활성 트랜잭션이 있음을 알았습니다. log_reuse_wait_desc주었다 ACTIVE_TRANSACTION. 거래가 완료 되 자마자 축소가 제대로 작동했습니다.
squillman 2016 년

10

로그 축소 단계는 다음과 같습니다.

SSMS 또는 T-SQL을 통한 트랜잭션 로그 백업 후 축소 수행

데이터베이스 이름을 마우스 오른쪽 단추로 클릭하면 SSMS 명령이 작업 아래에 있습니다.

BACKUP LOG <Databasename> TO DISK N'<path\database_log.ldf';
GO

DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS

아마이 작업을 여러 번해야 할 것입니다

조치를 차단하는 트랜잭션 또는 작업이있는 경우 활동 모니터를 사용하여 프로세스를 식별하고 종료하거나 SQL 에이전트 작업 활동 모니터를 사용하여 작업을 종료하십시오.

출처 : http://support.microsoft.com/kb/907511


그러나 내가 직면 한 문제는 다릅니다. 아래 내 답변을 참조하십시오
Navaneet

업데이트 해 주셔서 감사합니다. 업데이트 해 주셔서 감사합니다.
Cougar9000

잘못된 구문-등호가 없습니다. BACKUP LOG <데이터베이스 이름> TO DISK = N '<경로 \ database_log.ldf';
리버스 엔지니어

9

읽기 SQL 서버 로그를 축소하는 방법 로그의 원형 자연이 절단 후 수축을 방지 할 수있는 방법에 대한 설명. 마지막 LSN 지점을 LDF 의 끝에 있는 VLF에 로그인 할 수 있습니다 . 직관적으로 카운터를 사용하면 로그 쓰기를 생성하여 로그를 축소 할 수 있도록 로그를 진행시켜야합니다.


0

데이터베이스를 축소하기 전에 데이터베이스에 대해 설정된 백업 모델에 따라 백업을 먼저 작성해야합니다.

이것을 시도해 볼 수 있습니다.

USE <databasename>
GO

BACKUP DATABASE <databasename> TO DISK '<absolute path goes here>\<databasename>.bak';
GO

또는 SSMS에서이를 수행하고 사용 가능한 그래픽 도구를 사용할 수 있습니다 (자세한 내용은 http://msdn.microsoft.com/en-us/library/ms187510.aspx 참조 ).

데이터베이스를 백업하면 압축 할 수 있습니다. 그러나 인덱스를 많이 조각화하면 데이터 검색 속도가 느려지므로 데이터베이스 축소는 좋은 생각이 아닙니다.

이것이 도움이되기를 바랍니다.


백업을 수행하고 로그를 자르고 로그 파일 크기를 줄이는 방법을 알고 있습니다. 그러나이 데이터베이스의 경우 문제가 있습니다. 이름 = 'dbname'인 sys.databases에서 query select log_reuse_wait_desc를 실행했는데 복제로 인해 문제가 발생하는 것을 발견했습니다.하지만 복제본이 설정되어 있지 않습니다. 그렇다면 로그 재사용 wait_desc에 표시된이 db에서 응답을 제거하는 방법은 무엇입니까?
Navaneet

어떤 SQL Server 버전을 사용하고 있습니까?
Toni Kostelac

복제가 작업으로 설정되어있을 수 있으므로 SQL Server 에이전트 폴더를 열고 작업 폴더를 펼치고 복제 작업 설정이 있는지 확인한 후 마우스 오른쪽 단추를 클릭하고 작업 중지
Toni를

SQL Server 2005 이상을 사용하는 경우 sp_removedbreplication 'DB_NAME'은 복제를 제거합니다. SQL Server 2000의 경우 blogs.msdn.com/b/repltalk/archive/2010/11/17/…을
Kin Shah

그러나 내가 직면 한 문제는 다릅니다.
제발

0

트랜잭션 로그가 실제로 크기를 줄이려면 데이터베이스와 트랜잭션 로그 모두에 대해 2 또는 3 개의 백업을 수행해야한다는 것을 알았습니다. 전체 복구 모델로 만든 데이터베이스가 있습니다. 매일 밤 데이터베이스와 트랜잭션 로그의 백업을 수행하지만 필연적으로 트랜잭션 로그는 2-3 주에 걸쳐 계속 커지는 것 같습니다. 남은 디스크 공간이 1GB가되면 트랜잭션 로그가 약 30GB임을 알 수 있습니다. 나는 Microsoft가 권장하는 단계를 따랐으며 데이터베이스와 트랜잭션 로그를 모두 백업하는 4 번째 또는 5 번째 반복 후에는 트랜잭션 로그가 추가 공간을 해제하고 축소됩니다. 그런 다음 돌아가서 내가 만든 여러 백업을 삭제합니다.


당신이 뭔가 잘못하고 있다고 생각합니다. 로그 백업을 올바르게 수행하면 사용하지 않는 로그가 잘립니다. 내 질문에 주어진 명령은 문제를 해결하는 데 도움이 될 수 있습니다.
Navaneet

-8

축소 로그 파일을 차단하는 복제에 대한 내 해결책은 다음과 같습니다.

  1. DB 복구 모델을 단순으로 설정
  2. DB를 오프라인으로 전환
  3. 만일을 대비하여 로그 파일 백업 생성
  4. 로그 파일 삭제
  5. DB를 온라인으로 전환

제 경우에는 효과가있었습니다. DB 온라인 로그를 가져온 후 자동으로 생성되고 크기는 70GB 대신 512kb입니다. 그러나 이것은 해결 방법 일뿐입니다. 근본 문제는 해결되지 않았습니다. 제 경우에는 복제를 사용하고 있습니다.


4
이것은 끔찍한 충고입니다. 거래 로그를 절대 삭제하지 마십시오. 모든 종류의 문제는 손상과 같은 문제에서 비롯 될 수 있습니다.
Tom V-Team Monica
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.