데이터베이스는 항상 복구 모드에서 시작

서버를 다시 시작할 때마다 데이터베이스는 항상 복구 모드에 있으며 정상적으로 작동하는 데 약 20 분이 걸립니다. 이것은 항상 서버를 다시 시작할 때만 발생하므로 몇 가지 질문이 있습니다 ...

1. 큰 로그 파일로 인해 발생할 수 있다고 들었습니다. 맞습니까? 그렇지 않다면 다른 원인은 무엇입니까?
2. 복구를 방지하기 위해 로그 파일의 공간을 줄여야합니다. 더 나은 방법 : 축소 또는 잘림?
3. 로그 파일 / 데이터베이스를 축소하거나 잘라서 크기를 줄이려면 어떻게해야합니까? 구문은 무엇입니까?

현재 Microsoft SQL Server 2008을 사용하고 있습니다.

나는 같은 문제가 있고 그것을 해결했다고 생각하지만 그것을 확인하기 위해 완전히 테스트 할 수는 없었습니다.

문제는 로그 파일에있는 VLF 수와 관련이 있으며 크기는 아닙니다. 로그 파일이 크면 자동 증가 이벤트를 통해 유기적으로 증가했으며 의도적으로 계획된 성장이 아니었을 수 있습니다. 이 경우 로그 파일 내에 수천 개의 VLF가있을 수 있습니다.

여기에 내가 사용한 VLF 수를 확인하는 쿼리가 있습니다 .

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

VLF에 대한 자세한 설명은이 링크를 참조하십시오 .

문제는 VLF가 너무 많아서 SQL 서버가 상태를 평가 한 다음 데이터베이스를 복구하는 데 오랜 시간이 걸린다는 것입니다. 로그 파일을 가능한 가장 작은 크기, 종종 로그 파일에서 생성 된 첫 번째 VLF의 크기로 축소하면 즉시 의도적으로 다시 커져서 올바른 수의 VLF를 생성 할 수 있습니다. 16).

이것이 완료되면 데이터베이스 복구 속도가 훨씬 빠르다는 것을 알 수 있습니다.

자체 VLF 문제를 해결 한 후 프로덕션 인스턴스의 장애 조치를 테스트 할 기회가 없었으므로 이것이 문제의 근본 원인인지 확인할 수 있으면 매우 궁금합니다. 실험적으로 나는 스테이징 환경에서 복원하는 데 걸리는 시간이 이렇게 희망적으로 크게 줄어드는 것을 보았습니다.

이 MSDN 기사에서 :

커밋되지 않은 장기 트랜잭션은 모든 유형의 검사 점에 대한 복구 시간을 증가시킵니다.

일반적으로 프로덕션 데이터베이스에서 모든 종류의 DBCC 축소 ​​파일을 실행하지 않는 것이 좋습니다. 또한 로그 잘림 동작 HAS가이 블로그에 따라 이전 버전에서 2008로 변경되었습니다 (@Edward 덕분에) .

trucate_only를 사용하는 백업 로그는 SQL 2008에서 더 이상 지원되지 않습니다. 데이터베이스가 대량 로그 또는 전체 복구 모델 인 경우 정기적으로 T-Log 백업을 예약하면 t-log 모양이 유지됩니다.

다시 말하지만, 얼마나 자주 데이터베이스를 백업합니까? 일반적으로 정기적 인 백업은 로그 크기를 가장 잘 관리합니다.

온라인 트랜잭션 로그의 크기를 줄이면 문제가 해결 될 수 있습니다. 즉, 데이터베이스가 온라인 상태가되는 속도가 빨라지지만이를 수행하기 전에 재해 복구에 대해 고려해야합니다. 단순 복구 모델 인 경우 특정 시점으로 복원 할 수 없습니다. 반면 전체 복구 모델을 사용하는 경우 온라인 트랜잭션 로그의 크기를 유지하는 가장 좋은 방법은 정기적으로 트랜잭션 로그 백업을 만드는 것입니다 (스케줄).

트랜잭션 로그를 자르더라도 실제 하드 디스크 공간은 확보되지 않으며 SQL Server는 마지막 CHEKPOINT (마지막 트랜잭션 로그 백업 이후) 이후 발생한 트랜잭션에 대해서만 해당 공간을 재사용 할 수 있습니다.

데이터베이스를 축소하면 파일 크기가 줄어 듭니다. MyDB 데이터베이스를 15 % 줄이려면 다음을 수행하십시오.

DBCC SHRINKDATABASE (MyDB, 15); 가다