증상
Microsoft SQL Server 2012 또는 Microsoft SQL Server 2014에서 데이터베이스 미러링을 사용 하는 경우 assert 조건을 적중 하 고 데이터베이스 미러링이 일시 중단 상태로 전환 될 수 있습니다.
원인
새 페이지를 할당할 때 SQL Server가 새 페이지에 대 한 X 잠금을 획득 하기 때문에이 문제가 발생 합니다. SQL Server는 잠금 요청에 새 페이지가 속한 hobt_id (힙 또는 B-트리 ID)를 설정 합니다. 그러나 SQL Server는 미러링 로그에 hobt_id를 삽입할 수 없으며 기본 및 미러 간의 잠금 동작이 서로 다르게 발생 합니다. 다음과 같이 자세히 설명할 수 있습니다.
-
T1에서 페이지 P1에 대 한 IX 잠금을 유지 합니다.
-
T2는 P1에서 페이지 분할을 수행 하 고, 새 페이지 P2를 할당 하 고, 시스템 트랜잭션 TX를 사용 하 여 P2에 X 잠금을 유지 합니다. 여기에 나와 있는 SQL Server는 hobt_id를 미러링 로그에 넣지 않았습니다.
-
TX는 T1에 대 한 잠금 마이그레이션을 수행 하 여 IX를 P1에서 P2로 이동 합니다.
-
TX 커밋, 이제 T2는 P2 페이지를 사용할 수 있으며 T2는 P2 페이지에서 다른 IX 잠금을 가져옵니다.
-
T1이 커밋 되었고 이제 T2는 P2에 대 한 IX 잠금을 보유 한 유일한입니다.
-
삽입이 많아 잠금 에스컬레이션이 발생 하는 경우, T2에서는 P2에 대 한 IX를 해제 하지만 미러에서는 잠금 에스컬레이션 중에 T2가 IX 잠금을 해제 하지 않았습니다.
-
삭제를 수행한 후 P2 페이지는 비어 있고 할당이 취소 됩니다.
-
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 누적 업데이트에서 처음 수정 되었습니다.
SQL Server 2014 누적 업데이트 1 /en-us/help/2931693
SQL Server 2012 SP1 용 누적 업데이트 9 /en-us/help/2931078
각각의 새로운 새 누적 업데이트에는 이전 누적 업데이트에 포함 된 모든 핫픽스와 모든 보안 수정 사항이 포함 되어 있습니다. SQL Server에 대 한 최신 누적 업데이트를 확인 하세요.
해결 방법
이 문제를 해결 하려면 미러를 다시 초기화 하 여 일시 중단 상태를 종료 합니다.
상태
Microsoft는 "적용 대상" 절에 나열한 제품에서 이 문제를 확인했습니다.
