트랜잭션 로그 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.