내 앱의 마지막 릴리스에서 Service Broker 큐에 무언가가 도착할 때까지 기다리라는 명령을 추가했습니다.
WAITFOR (RECEIVE CONVERT(int, message_body) AS Message FROM MyQueue)DBA는 추가 이후 로그 크기가 지붕을 통과했다고 말합니다. 이것이 맞습니까? 아니면 다른 곳을보아야합니까?
내 앱의 마지막 릴리스에서 Service Broker 큐에 무언가가 도착할 때까지 기다리라는 명령을 추가했습니다.
WAITFOR (RECEIVE CONVERT(int, message_body) AS Message FROM MyQueue)DBA는 추가 이후 로그 크기가 지붕을 통과했다고 말합니다. 이것이 맞습니까? 아니면 다른 곳을보아야합니까?
답변:
열려있는 모든 활성 트랜잭션은 로그를 고정하여 잘림을 방지하고 결국 성장을 유발합니다. 트랜잭션을 시작하고 로그에 기록한 다음 메시지가 결국 깨어날 수 있기를 바라면서 영원히 기다리면 로그를 고정하여 커지게됩니다.
최근에 사람들에게 루프와 함께 WAITFOR를 활성화 된 절차로 피하도록 권장하기 시작했습니다. RECIEVe를 발행하고 완료하기 만하면 활성화 메커니즘이 사용자를 위해 반복되도록하고 대기하지 말고 그냥 RECEIVE하십시오.
RECEIVE의 WAITFOR 플레이버는 내부적으로 저장 점을 만듭니다. 이렇게하면 로그 (최소 3 개의 로그 레코드)가 생성되고 대기하는 동안 실제로 로그가 고정됩니다. WAITFOR 타임 아웃 시간이 길거나 (무한한 경우는 무한한) 매우 나쁜 습관입니다.
WAITFOR (RECEIVE...당신이 확장 수 있을까? 아마도 오해했을 것입니다.
begin transaction; waitfor(receive...)대기하는 동안 로그 레코드를 생성하지 않고 (트랜잭션을 '활성화'하지 않음) 로그를 고정하지 않습니다. 만 begin transaction;[insert|update|delete];waitfor(receive...)기다리는 동안 실제로 로그를 핀 것 때문에 (로그 레코드를 생성) '활성화'로 거래를 일으킬 것입니다.
SQL Server 2008 R2에서 WAITFOR (RECEIVE)를 실행 한 다음 DBCC OPENTRAN을 실행하면 이전 업데이트가없는 경우에도 트랜잭션이 활성으로 표시됩니다.
WAITFOR (...) TIMEOUT 3600000문제를 해결? 예를 들어 매시간 릴리스.