다음을 통해 공유


데이터베이스에서 쿼리 알림을 사용하는 경우 복원 또는 복구에 실패하거나 시간이 오래 걸릴 수 있습니다.

이 문서는 데이터베이스에서 쿼리 알림을 사용하는 경우 복원 또는 복구가 실패하거나 시간이 오래 걸릴 수 있는 문제를 resolve 데 도움이 됩니다.

원래 제품 버전: SQL Server
원본 KB 번호: 2483090

증상

쿼리 알림 구독에 대해 구성된 데이터베이스에서 다음 증상 중 하나 이상을 확인할 수 있습니다.

  • 증상 1: 복원 작업 중에 NEW_BROKER 옵션을 지정하면 백업에서 데이터베이스를 복원하는 데 1205 오류 메시지가 표시될 수 있습니다. 또한 덤프 파일은 SQL Server Errorlog 폴더에 생성됩니다.

  • 증상 2: 백업에서 데이터베이스 복원이 실패하고 데이터베이스가 오프라인 상태가 되는 경우 또한 다음 메시지는 SQL Server 오류 로그에 기록됩니다.

    <Datetime> spid61 오류: 9768, 심각도: 16, 상태: 1.
    <Datetime> spid61 보안 대화와 연결된 데이터베이스 사용자가 자격 증명을 먼 엔드포인트와 교환하기 전에 삭제되었습니다. 대화가 만들어지는 동안에는 DROP USER를 사용하지 마십시오.
    <Datetime> spid61 데이터베이스를 열 때 다음 오류로 인해 데이터베이스 "5"에서 보류 중인 쿼리 알림을 검사 못했습니다. '자격 증명을 먼 엔드포인트와 교환하기 전에 보안 대화와 연결된 데이터베이스 사용자가 삭제되었습니다. 대화가 만들어지는 동안에는 DROP USER를 사용하지 마십시오. 쿼리 알림 구독 정리 작업이 실패했습니다. 자세한 내용은 이전 오류를 참조하세요.'.
    <Datetime> spid61 오류: 9001, 심각도: 16, 상태: 5.
    <Datetime> spid61 데이터베이스 'Test'에 대한 로그를 사용할 수 없습니다. 이벤트 로그에서 관련 오류 메시지를 확인합니다. 오류를 해결하고 데이터베이스를 다시 시작합니다.
    <Datetime> spid61 오류: 3314, 심각도: 21, 상태: 4.
    <Datetime> spid61 데이터베이스 'Test'에서 기록된 작업을 실행 취소하는 동안 로그 레코드 ID(1835:7401:137)에서 오류가 발생했습니다. 일반적으로 특정 오류는 이전에 Windows 이벤트 로그 서비스의 오류로 기록됩니다. 백업에서 데이터베이스 또는 파일을 복원하거나 데이터베이스를 복구합니다.

    참고

    데이터베이스의 복구 단계에서 문제가 발생할 수 있습니다. 데이터베이스가 온라인 상태가 되면 데이터베이스에서도 복구가 실행되고 서버가 다시 시작됩니다.

  • 증상 3: 백업에서 데이터베이스를 복원하는 데 시간이 오래 걸릴 수 있으며 다음과 유사한 메시지가 SQL Server 오류 로그에 기록됩니다.

    날짜 시간 SPID 쿼리 알림 배달이 대화 상자 '{ 대화 ID }.'에 메시지를 보낼 수 없습니다. 알림 '에 대한 배달이 실패했습니다.<qn:QueryNotification xmlns:qn="https://schemas.microsoft.com/SQL/Notifications/QueryNotification" id="2881" type="change" source="database" info="restart" database_id="7" sid="0x010500000000000515000000FA48F22A6990BA52422C73DFF9030000"><qn:Message>4a4c696b-645c-40fd-bfef-4f2bc7c599b4; eb99973e-3cc9-4c7e-b4b9-47d8cf590c43</qn:Message></qn:QueryNotification>' 서비스 브로커에서 다음 오류로 인해 '대화 핸들 "<대화 처리기>"를 찾을 수 없습니다.'

    참고

    데이터베이스의 복구 단계에서 문제가 발생할 수 있습니다. 데이터베이스가 온라인 상태가 되면 데이터베이스에서도 복구가 실행되고 서버가 다시 시작됩니다.

원인

증상 1의 원인: 복원 작업 중에 NEW_BROKER 옵션을 지정하면 SQL Server 모든 Service Broker 관련 테이블을 자르려고 시도합니다. 잘림하려면 잘린 개체에 대한 SCH_M 잠금이 필요합니다. 따라서 기본 트랜잭션은 sysdesend에 대한 SCH_M 잠금을 보유합니다. 데이터베이스를 복구하거나 복원하는 경우 기본적으로 SQL Server 처리 중인 모든 쿼리 알림을 실행하려고 시도합니다. 이 경우 행(메시지)을 sysdesend 테이블에 삽입해야 합니다. 이 작업을 수행하려면 테이블에 대한 SCH_S 잠금이 필요합니다. 그러나 이 작업은 다른 트랜잭션에서 발생하며 첫 번째 트랜잭션에서 보유한 SCH_M 잠금에 의해 SCH_S 잠금을 획득하려는 시도가 차단됩니다. 결과적으로 복원을 실행하는 스레드는 이제 자체 교착 상태라고 하는 리소스에서 차단됩니다. 교착 상태가 교착 상태 모니터에 의해 검색되고 스레드가 종료되어 복원 작업이 종료됩니다.

잠금에 대한 자세한 내용은 잠금 모드를 참조하세요. 증상 섹션에서 설명하는 다른 증상은 아래 해결 섹션에 언급된 수정 문서에 설명된 알려진 문제로 인해 발생합니다.

해결 방법

증상 1에 대한 해결 방법: 복원 작업을 시도하기 전에 세션 수준 추적 플래그 9109를 사용하도록 설정하여 문제를 해결할 수 있습니다. 예제 스크립트는 다음과 같습니다.

dbcc traceon (9109)
go
RESTORE DATABASE [Test] 
FROM DISK = N'C:\TestBackup.bak' WITH FILE = 1, 
MOVE N'test_Data' TO N'C:\test.mdf', 
MOVE N'test_Log' TO N'C:\test_1.ldf', 
NOUNLOAD, 
STATS = 1, 
NEW_BROKER
go
dbcc traceoff (9109)
go

참고

데이터베이스가 완전히 복원되거나 복구되면 쿼리 알림이 실행되도록 검사 것이 좋습니다. 이 작업을 수행하는 가장 쉬운 방법은 데이터베이스의 상태 읽기 전용으로 변경하고 다시 읽기/쓰기로 변경하는 것입니다. 이를 위해 검사 수 있는 몇 가지 다른 방법으로는 데이터베이스 분리 및 다시 연결, SQL Server 다시 시작 등이 있습니다.

또한 복원 작업에서 NEW_BROKER 옵션을 지정하지 않고 데이터베이스가 복원된 후 NEW_BROKER 옵션과 함께 를 사용하여 ALTER DATABASE 를 지정하지 않음으로써 문제를 완전히 방지할 수 있습니다.

자세한 내용은 DBCC TRACEON - 추적 플래그(Transact-SQL)를 참조하세요.