Applies ToSQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Standard SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

증상

Microsoft SQL Server 2012 또는 Microsoft SQL Server 2014에서 데이터베이스 미러링을 사용 하는 경우 assert 조건을 적중 하 고 데이터베이스 미러링이 일시 중단 상태로 전환 될 수 있습니다.

원인

새 페이지를 할당할 때 SQL Server가 새 페이지에 대 한 X 잠금을 획득 하기 때문에이 문제가 발생 합니다. SQL Server는 잠금 요청에 새 페이지가 속한 hobt_id (힙 또는 B-트리 ID)를 설정 합니다. 그러나 SQL Server는 미러링 로그에 hobt_id를 삽입할 수 없으며 기본 및 미러 간의 잠금 동작이 서로 다르게 발생 합니다. 다음과 같이 자세히 설명할 수 있습니다.

  1. T1에서 페이지 P1에 대 한 IX 잠금을 유지 합니다.

  2. T2는 P1에서 페이지 분할을 수행 하 고, 새 페이지 P2를 할당 하 고, 시스템 트랜잭션 TX를 사용 하 여 P2에 X 잠금을 유지 합니다. 여기에 나와 있는 SQL Server는 hobt_id를 미러링 로그에 넣지 않았습니다.

  3. TX는 T1에 대 한 잠금 마이그레이션을 수행 하 여 IX를 P1에서 P2로 이동 합니다.

  4. TX 커밋, 이제 T2는 P2 페이지를 사용할 수 있으며 T2는 P2 페이지에서 다른 IX 잠금을 가져옵니다.

  5. T1이 커밋 되었고 이제 T2는 P2에 대 한 IX 잠금을 보유 한 유일한입니다.

  6. 삽입이 많아 잠금 에스컬레이션이 발생 하는 경우, T2에서는 P2에 대 한 IX를 해제 하지만 미러에서는 잠금 에스컬레이션 중에 T2가 IX 잠금을 해제 하지 않았습니다.

  7. 삭제를 수행한 후 P2 페이지는 비어 있고 할당이 취소 됩니다.

  8. T3에는 새 페이지가 필요 하며, P2를 할당 하는 데 X 잠금이 필요 하지만, 6 단계 때문에이 단계는 미러 서버에서 실패 했습니다.

미러에서는 잠금 블록의 hobt_id이 올바르지 않으므로 미러의 경우 6 단계는 IX 잠금을 해제 하지 않습니다. 이 잘못 된 hobt_id는 2 단계에서 제공 되며, SQL Server가 미러링 로그에 hobt_id를 배치 하지 않기 때문에 일반적으로 문제가 표시 되지 않습니다. 2 단계의 TX는 매우 짧고 잘못 된 hobt_id 있는 잠금 블록이 커밋될 때 해제 됩니다. 그러나 step3의 잠금 마이그레이션과 다음 단계 (4 및 5)로 인해 잘못 된 hobt_id 있는이 잠금 블록이 보존 되며 최종적으로 문제가 발생 합니다. 2 단계에서 올바른 hobt_id를 사용 하기 때문에 기본 문제는이 문제가 발생 하지 않습니다. 그러나 로그 레코드에 올바른 hobt_id 없습니다.

각각의 새로운 새 누적 업데이트에는 이전 누적 업데이트에 포함 된 모든 핫픽스와 모든 보안 수정 사항이 포함 되어 있습니다. SQL Server에 대 한 최신 누적 업데이트를 확인 하세요.

해결 방법

이 문제를 해결 하려면 미러를 다시 초기화 하 여 일시 중단 상태를 종료 합니다.

상태

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

도움이 더 필요하세요?

더 많은 옵션을 원하세요?

구독 혜택을 살펴보고, 교육 과정을 찾아보고, 디바이스를 보호하는 방법 등을 알아봅니다.

커뮤니티를 통해 질문하고 답변하고, 피드백을 제공하고, 풍부한 지식을 갖춘 전문가의 의견을 들을 수 있습니다.