크기가 2GB 인 데이터 파일이있는 SQL Server 2008 데이터베이스가 있지만 로그 파일이 8GB를 초과합니다. 2008 년 이전 데이터베이스에서는 '백업 로그'와 TRUNCATE_ONLY옵션을 사용할 수 있었지만 2008 이상 데이터베이스에서는 더 이상 사용할 수 없습니다.
로그 파일을 자르는 스크립트가 있습니다.
USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO로그 파일이 완전히 잘리지 만 내 질문은 다음과 같습니다. 성능에 영향을 미칩니 까?
매일 두 번의 전체 백업을 수행하므로 데이터 롤 포워드와 관련하여 로그가 실제로 필요하지 않아야합니다.
답변:
Paul S. Randal 의 적절한 트랜잭션 로그 크기 관리의 중요성을 읽는 것이 좋습니다 .
가장 중요한 것은 트랜잭션 로그 처리 를 수행하는 두 가지 실제로 좋은 방법이 있다는 것입니다 .
정기적 인 LOG 파일 백업을 사용하면 LOG 파일은 각 LOG 백업 후 공간을 재사용하고 무한정 커지지 않습니다. 또는
SIMPLE 복구 모델을 사용하면 정기적 인 전체 백업을 수행 할 때 LOG 파일 크기를 신경 쓸 필요가 없습니다.
LOG 파일 잘림 및 성능과 관련된 것은 LOG 파일을 늘릴 때 항상 성능에 영향을 미친다는 것입니다 (위의 링크 된 블로그 게시물에서 인용).
로그를 축소하면 다시 커질 것입니다. VLF 조각화가 발생하고 로그가 커지는 동안 워크로드가 일시 중지되어 로그가 즉시 초기화되지 않습니다. [...]
업데이트 : DATA 파일 축소를 위해 LOG 파일 잘림을 실수하지 마십시오. DATA 파일 축소 가 실제로 나쁩니다. 자세한 내용 은 데이터 파일 을 축소해서는 안되는 이유를 참조 하십시오.
먼저 예, 문제 발생시 리보 커를 사용하려면 매일 전체 백업을 수행해도 로그가 필요합니다. 트랜잭션 로그는 15 분마다 백업됩니다. 문제는 트랜잭션 로그를 백업하지 않기 때문에 로그가 크게 커지는 이유입니다. 올바른 트랜잭션 로그 백업을 수행하는 경우 트랜잭션 로그를 축소 할 필요가 거의 없습니다.
로그를 자르기 전에 데이터베이스를 백업해야합니다. 백업과 잘림 사이에 새 데이터가 삽입되지 않도록 근무 외 시간에 수행하는 것이 좋습니다. 그런 다음이 문제가 다시 발생하지 않도록 적절한 트랜잭션 로그 백업을 설정하십시오.
시스템 하드웨어 및 사용법에 대한 세부 정보를 모르면 성능에 영향을 미치는 것은 말하기 어렵습니다.
트랜잭션 로그가 얼마나 빨리 커 집니까? 속도가 빠르면 다시 성장하는 데 시간이 걸리므로 성능을 거의 아무것도 줄이지 않습니다. 그렇다고 수시로 축소해서는 안되지만 최소 크기로 축소하기보다는 크기 문제를 고려해야합니다. 퍼포먼스가 거대합니까? 아마도 그렇지는 않지만 서버의로드 (트랜잭션 수 등)에 따라 다릅니다.
내가 문제를 발견 한 한 가지는 "매일 2 개의 전체 백업을 수행하므로 데이터 롤 포워드와 관련하여 로그가 실제로 필요하지 않아야합니다."입니다. 로그는 전체 백업 사이의 지점에 매우 중요합니다. 읽기 전용 데이터베이스가 아니라면 하루에 두 번이라도 재해 복구를위한 로그 파일이 필요하지 않습니다 (그렇다면 로그 파일이 크게 증가하지는 않습니다).