트랜잭션 로그 log_reuse_wait_desc를자를 수 없습니다-AVAILABILITY_REPLICA


9

오늘 아침에 나는 우리 데이터베이스 중 하나에 대한 트랜잭션 로그 전체 경고로 깨어났다. 이 서버는 Alwayson 클러스터이자 트랜잭션 복제 구독자입니다. log_reuse_wait_desc를 확인하고 logbackup을 표시했습니다. 누군가 4 일 전에 실수로 로그 백업 작업을 비활성화 한 경우 로그 백업 작업을 다시 활성화하면 로그가 지워졌습니다. 오전 4시 이후로 나는 그날 아침에 사무실에 가서 400GB로 늘어 났을 때 로그를 thought을 것이라고 생각했다.

사무실에 오전 10시-나는 수축하기 전에 로그 사용량을 확인하고 약 16 %였습니다. 나는 놀랐고 log_reuse_wait_desc를 확인했다. 이것이 복제 가입자이기 때문에 혼란 스러웠습니다. 그런 다음 DBC가 CDC에 사용 가능하고 그 원인 일 수 있다고 생각하여 CDC를 사용 불가능하게했으며 이제 log_reuse_wait_desc에 AVAILABILITY_REPLICA가 표시됩니다.

한편 로그 사용량은 여전히 ​​꾸준히 증가하고 있으며 현재 17 %입니다. Alwayson 대시 보드를 확인하고 전송 및 재실행 대기열을 확인하며 둘 다 실제로 0입니다. 로그 재사용이 AVAILABILITY_REPLICA로 표시되고 로그를 지울 수없는 이유를 잘 모르겠습니다.

왜 이런 일이 일어나는지 아십니까?

답변:


7

이렇게하면 :

SELECT * FROM sys.databases

그리고 log_reuse_wait_desc는 AVAILABILITY_REPLICA를 표시합니다. 즉, SQL Server가 Always On 가용성 그룹 복제본 중 하나로 로그 데이터를 보내기 위해 대기하고 있음을 의미합니다. 네트워크 속도가 느려 복제본 중 하나가 지연되거나 완전히 다운되었을 수 있습니다.

AG 대시 보드를 확인했는데 대기열이 표시되지 않으면 스레드가 소모 된 것일 수 있습니다. 작업자 스레드 소진 후 AG 대시 보드가 업데이트를 중지하는 것은 알려진 문제입니다 . 기본에 의존하지 않고 각 복제본의 상태를 직접 확인해야합니다. Connect 항목에 따르면 Nick은 복제본의 속성을 변경하여 복제를 다시 시작할 수 있지만 항상 작동하지는 않습니다 (특히 대량의 데이터를 전송해야하는 복제본에 수백 개의 데이터베이스가있는 경우) 복제를 다시 시작하면 작업자 스레드가 다시 소모 될 수 있습니다.)

마지막 사람이 AG 복제본을 설정했는데 더 이상 존재하지 않으면 AG 및 / 또는 복제본을 제거해야합니다. SQL Server에 연결하기 위해 앱이 리스너 이름을 가리 키지 않도록주의하십시오.


보조 장치가 비동기 모드로 설정되어 있습니까? 보조가 OFF (고정 대기 중)이면 기본 로그가 계속 커 집니까? 감사!
Michael

보조가 여전히 AG에있는 한 (켜지거나 끄거나, 동기화 또는 비 동기화) 로그 데이터는 계속 쌓입니다. 결국 보조 전원을 다시 켤 때 어딘가에서 데이터를 가져와야합니다. 그렇기 때문에 일정 기간 동안 고장난 경우 일반적으로 AG에서 제거하고 백업에서 다시 초기화하는 것이 좋습니다.
Brent Ozar
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.