SQL 로그 파일 크기를 유지하는 가장 좋은 방법

저는 다소 새로운 DBA이며 상당한 양의 활동이있는 SQL Server 2012 인스턴스를 관리하고 있습니다. 특정 시점 복구가 필요하기 때문에 전체 복구 모드에서 실행 중입니다.

지금은 매일 오전 5시에 데이터베이스와 로그를 전체 백업합니다. 일부 로그 파일은 최대 300GB로 확장되었으며 백업을 수행 한 후에도 크기가 줄어들지 않습니다. 다음과 비슷한 것을 실행하여 크기를 줄일 수 있습니다.

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

백업 파일의 LSN을 확인하면 다음과 같은 내용이 표시됩니다.

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

로그 파일을 축소하여 로그 체인을 깨고 있다고 생각하지 않습니다. 이것에 대해 읽으면 축소 된 로그 파일이 다시 커져야하기 때문에 성능이 저하된다고 생각합니다.

질문 :

1. 백업 후 로그 파일이 축소되지 않는 이유는 무엇입니까? 커밋되지 않은 트랜잭션이 있기 때문입니까?
2. 처음에는 오전 5시 백업 후 로그 파일을 축소해야한다고 생각했습니다. 성능이 어떻게 나빠지는지에 대해 읽은 후에는 하루 중 몇 시간마다 정기적 인 로그 백업을 수행해야한다고 생각합니다. 그 맞습니까?
3. 데이터베이스 / 로그의 정상적인 전체 백업은 매일 오전 5시에 발생하며 때로는 3 시간이 걸립니다. 1 시간마다 로그 백업이 수행되도록 예약하면 로그 백업이 오전 5시 백업과 충돌하면 어떻게됩니까?

1. 백업 후 로그 파일이 축소되지 않는 이유는 무엇입니까? 커밋되지 않은 트랜잭션이 있기 때문입니까?

실제 NTFS 로그 파일은 트랜잭션 로그 백업에서 "축소"되지 않지만 트랜잭션 로그 내의 VLF (가상 로그 파일)는 재사용 가능으로 표시됩니다 (이제 미디어에 백업되고 지속되기 때문에). 트랜잭션 로그를 사용하여 발생합니다. 트랜잭션 로그를 백업하지 않거나 빈번하지 않은 경우 사용 가능한 VLF가 없으므로 추가 트랜잭션 로그 항목을 수용 할 수 있도록 트랜잭션 로그가 커지도록 (자동 증가가 설정된 경우) 발생합니다.

2. 처음에 오전 5시 백업 후 로그 파일을 축소해야한다고 생각했습니다. 성능이 어떻게 나빠지는지에 대해 읽은 후에는 하루 중 몇 시간마다 정기적 인 로그 백업을 수행해야한다고 생각합니다. 그 맞습니까?

일상적이고 예약 된 파일 축소는 좋은 생각이 아닙니다. 필요한 공간을 많이 확보해야 할 때만 고려해야합니다 DBCC SHINKFILE. 또한 트랜잭션 로그를 지속적으로 늘리는 경우 데이터베이스 복구와 같은 다른 사항을 방해 할 수 있습니다. 트랜잭션 로그에 VLF가 너무 많으면 (트랜잭션 로그가 적은 스토리지 증분만으로 증가 할 때 발생하는 일반적인 문제) 데이터베이스 복구 시간이 원하는 것보다 길 수 있습니다.

3. 데이터베이스 / 로그의 정상적인 전체 백업은 매일 오전 5시에 발생하며 때로는 3 시간이 걸립니다. 1 시간마다 로그 백업이 수행되도록 예약하면 로그 백업이 오전 5시 백업과 충돌하면 어떻게됩니까?

아무 일도 일어나지 않을 것입니다. 그것은 완전히 법적인 운영입니다. MSDN 에서 아래 그래프를 참조하십시오 . 검은 점이있는 경우이 두 가지 작업을 동시에 수행 할 수 없습니다. 보시다시피 데이터베이스 백업과 트랜잭션 로그는 동시에 허용됩니다.

여기서의 설명은 트랜잭션 로그를 더 자주 백업해야한다는 것입니다. NTFS 파일 증가는 트랜잭션 로그를 더 자주 백업하지 않아 발생할 수있는 유일한 문제는 아닙니다. 스토리지 장애가 발생하여 트랜잭션 로그가 유실 된 경우 마지막 트랜잭션 로그 백업 시점으로 만 복원 할 수 있습니다. 트랜잭션 로그가 유실되면 로그의 테일을 백업하고 실패 시점으로 복원 할 수 없습니다. 귀하의 경우 24 시간 분량의 데이터가 손실 될 수 있습니다. 그러나 트랜잭션 로그를 30 분마다 백업하면 최대 데이터 손실은 30 분이됩니다. 이 경우 트랜잭션 로그가 사라지고 전체 백업과 손상되지 않은 로그 체인이 있으면 해당 마지막 로그 백업으로 복원 할 수 있습니다.

트랜잭션 로그 잘림에 대한 TechNet 설명서

다루고있는 주요 문제는 하루에 한 번 로그를 백업한다는 것입니다. 엔진의 동작은 로그 파일 내의 로그 레코드 (사용 된 공간)는 로그 백업에 성공한 후에 만 ​​제거됩니다. 이 공간은 검사 점이 발생 하면 회수 되지만 데이터베이스가 전체 / 대량 로그 복구 상태 인 경우 로그 레코드는 성공적으로 백업 된 경우에만 제거됩니다.

로그 백업은 전체 백업과 함께 사용하기위한 것이며 전체 백업간에 정기적으로 실행되어야합니다. 이 간격은 모든 기간이 될 수 있지만 일반적으로 15 분마다 로그 백업을 실행했습니다. 간격은 RPO (Recovery Point Objective) 및 복구시 손실 될 수있는 데이터 양에 따라 다릅니다.

정기적 인 로그 백업을 수행하는 경우 강제로 커지기 전에 로그 파일 공간을 관리하므로 정기적 인 파일 축소를 수행하지 않아도됩니다.

전에도 같은 문제가 발생했습니다. 매일 밤마다 전체 데이터베이스 백업을 사용하는 대신 내 로그 파일이 항상 증가합니다. 그래서 여기 내 해결책이 있습니다 :

1. 현재 로그 파일을 백업하십시오.

2. 데이터베이스를 단순 복구로 설정

   • 전체 복구-> 로그 파일은 커밋 된 트랜잭션을 삭제하지 않으므로 데이터를 다시 정렬하기 만하면됩니다.-> Shink 파일은 크게 영향을받지 않습니다.

3. 로그 파일을 1MB 이하로 쉰다.

4. 데이터베이스를 다시 전체 복구로 설정하십시오.

도움이 되길 바랍니다.

퐁 트란