KB2653893-FIX: SQL Server 2008 R2 또는 SQL Server 2008 또는 sql 2012에서 데이터베이스를 복원 하는 데 시간이 오래 걸림

증상

Microsoft SQL Server 2008 R2 또는 Microsoft sql Server 2008 또는 Microsoft sql Server 2012에서 데이터베이스를 복원 하는 데 시간이 오래 걸릴 수 있습니다.

원인

이 문제는 데이터베이스에 VLFs 많은 경우 가상 로그 파일 (VLF) 목록을 빌드하는 데 시간이 오래 걸리기 때문에 발생 합니다.

해결 방법

상태

Microsoft는 "적용 대상" 절에 나열한 제품에서 이 문제를 확인했습니다.

추가 정보

SQL 오류 로그 파일을 검토 한 다음 각 트랜잭션 로그 백업 파일의 LSN (로그 시퀀스 번호)을 찾아 VLF 세그먼트 수를 확인할 수 있습니다. LSNs에서 콜론 기호 앞의 첫 번째 숫자는 LSN의 번호와 일치 합니다. 예를 들어 LSN에 대 한 첫 번째 정보 메시지의 첫 번째 번호는 1입니다. 그러나 LSN에 대 한 두 번째 정보 메시지의 첫 번째 번호는 100001입니다. 이 시나리오에서는 첫 번째 정보 메시지와 두 번째 정보 메시지의 시간 사이에 사용 되는 10만 VLFs 있습니다. 따라서 많은 VLFs (가상 로그 파일)가 포함 된 로깅된 조각난 트랜잭션 로그가 다음과 유사 합니다.

{Log! ' 로그를 백업 했습니다. 데이터베이스: mydbname, 만든 날짜 (시간): 2010/07/08 (12:36:46), 첫 번째 LSN: 1:5068:70, 마지막 LSN: 1:5108:1, 덤프 장치 수: 1, 장치 정보: (파일 = 1, TYPE = DISK: {' C:\folder\logbackup1.trn '}). 이 메시지는 정보 제공 용입니다. 사용자 작업은 필요 하지 않습니다. 로그가 백업 되었습니다. 데이터베이스: mydbname, 만든 날짜 (시간): 2010/07/08 (15:36:46), 첫 번째 LSN: 100001:5108:1, 마지막 LSN: 100002:5108:1, 덤프 장치 수: 1, 장치 정보: (파일 = 2, TYPE = DISK: {' C:\folder\logbackup2.trn '}). 이 메시지는 정보 제공 용입니다. 사용자 작업은 필요 하지 않습니다.}

참조

LSN (로그 시퀀스 번호)에 대 한 자세한 내용은 다음 MSDN 웹 사이트를 방문 하세요.

로그 시퀀스 번호에 대 한 일반 정보

로그 파일 구조가 데이터베이스 복구 시간에 영향을 주는 방법에 대 한 자세한 내용은 다음 MSDN 웹 사이트를 방문 하세요.

로그 파일 구조가 데이터베이스 복구 시간에 영향을 줄 수 있는 방법트랜잭션 로그 VLFs에 대 한 자세한 내용은 다음 MSDN 웹 사이트를 방문 하세요.

트랜잭션 로그 파일에 대 한 일반 정보

해결 방법

• 복원 또는 복구 작업이 완료 될 때까지 대기데이터베이스를 복원 하거나 복구할 때 성능이 느려지는 데이터베이스가 복구 되지 않은 경우 복원 또는 복구 작업이 완료 될 때까지 기다려야 할 수 있습니다. 예를 들어 복구 되지 않은 데이터베이스에 대 한 오프 라인 상태 또는 SSMS (SQL Server Management Studio)의 복구 상태가 표시 될 수 있습니다. SQL Server를 중지 하면 일반적으로 느린 복구에 대 한 릴리프를 제공 하지 않으며 동일한 복구 분석 단계, 다시 실행 단계 또는 실행 취소 단계를 반복 하는 데 더 많은 시간이 걸릴 수 있습니다.

• 수천 개의 VLFs 포함 된 트랜잭션 로그 시퀀스 복원 방지백업 파일을 사용 하 여 데이터베이스를 복원 하 고 복구 하는 동안 성능이 느려지는 문제를 경험 하는 경우 수천 개의 VLFs 포함 된 트랜잭션 로그 시퀀스가 복원 되지 않도록 할 수 있습니다. 가장 많은 가상 로그 파일이 기록 된 백업 파일을 식별 하려면 다음 명령문을 사용 하 여 로그 백업 파일의 FirstLSN 및 LastLSN 열을 확인 합니다. DISK에서 HEADERONLY RESTORE = ' C:\folder\file.trn '에서는 로그 백업 파일 복원이 방지 되도록 결정할 수 있습니다. 또는 복원 명령에서 STOP AT 문을 사용 하 여 트랜잭션 로그의 심하게 조각난 부분을 피할 수 있습니다. 실패 복구 시나리오에서 최신 시점까지 로그 시퀀스를 완전히 복원 하지 않으면 데이터베이스 SQL Server에서 데이터 손실이 발생 합니다. 이 데이터 손실은 일부 트랜잭션을 유지 하지 않기 때문에 발생 합니다. 따라서 비즈니스 절충 결정이 있습니다. 심하게 조각난 트랜잭션 로그를 완전히 복원할 수 있습니다. 그러나이 작업에는 몇 시간이 걸릴 수 있습니다. 또는 복구의 중지 명령문을 사용 하 여 매우 조각화 된 로그 부분 이전에 복구를 중지할 수 있습니다. 그러나 생략 한 누락 된 트랜잭션은 손실 됩니다.참고 이 핫픽스를 설치 하지 않은 경우에는 일반적으로 SQL Server를 다시 시작한 후 복구할 수 있는 안전한 recourse 없습니다. SQL Server는 로그 파일을 분석 하는 VLFs 목록을 찾고, 완료 된 트랜잭션을 다시 실행 하 고, 복구를 완료 하기 위해 완료 되지 않은 트랜잭션을 취소 하 여 데이터베이스를 안전 하 게 온라인 상태로 만듭니다. 복구 하는 동안에는 트랜잭션을 안전 하 게 건너뛸 수 없습니다.