SQL 오류 로그 상수 FlushCache 메시지
SQL 2017 상시 가동 가용성 그룹 (BAG)의 일부인 서버 이러한 메시지가 증가하는 것을 확인했습니다. 2012 년 이후 (2012 년 이전의 추적 플래그) 로그에 표준으로 표시되는 메시지이지만 지난 2 일 동안 몇 분마다 표시되며 현재 실행중인 백업이나 유지 관리 작업이 없음을 이해합니다.
서버가 읽을 수없는 보조 장애 조치 파트너 역할을하고 있으며 기본 서버가 동일한 동작을 나타내지 않습니다.
09/04/2020 10 : 52 : 24, spid82s, Unknown, FlushCache : db 7 : 0에 대해 81090ms (11 개의 새로운 더티 버퍼 방지)에서 1881 개의 쓰기로 2303 개의 bufs를 정리했습니다. 2020 년 9 월 4 일 10:52:07, spid52s, 알 수 없음, 처리되지 않은 마지막 대상 : 2 avgWriteLatency 86 09/04/2020 10 : 52 : 07, spid52s, Unknown, 초당 평균 쓰기 : 17.70 쓰기 / 초 평균 처리량 : 0.19MB / 초 I / O 포화 : 13073 컨텍스트 스위치 15434
또한 FlushCache 메시지가 증가한 이후 가용성 그룹이 장애 조치 된 몇 초 후 디스크 문제에 대한 시스템 오류 로그에 경고가 있습니다.
비슷한 경험이 있거나 조언이있는 사람이 있습니까? 제 시스템 관리자는 SAN 및 VMware 자산도 검토하고 있습니다.
이것이 자동 성장 활동으로 인해 발생할 수 있다고 갑자기 생각 했습니까?
답변
간접 체크 포인트로 전환합니다 (일반적으로 최소한 사용자 데이터베이스의 경우 복구 간격 시간을 60 초로 설정).
나는이 문제에 대해 여기 와 여기에 썼고 , 당신은 변경하기 전에 그 포스트를 전부 읽어야합니다.
우리 환경에 미치는 영향은 과감하고 즉각적이었으며 변화가 책임이 있음을 증명하는 것은 간단했습니다. 증상이있는 모든 데이터베이스는 30-60 초 체크 포인트와 이러한 메시지로 가득 찬 오류 로그에서 1 초 미만의 체크 포인트로 이동했으며 더 이상 오류 로그 항목이 없습니다.
워크로드에 대한 완화 기술도있을 수 있습니다. 예를 들어 Itzik Ben-Gan의이 게시물을 참조하십시오. 하지만 체크 포인트를보다 효율적으로 만드는 것이 더 빠르고 쉬운 방법입니다. 하지만 여러분의 스토리지와 VM 직원은 문제가되지 않습니다. 분명히 해결해야 할 디스크 문제가 있습니다 (하지만 이러한 FlushCache 메시지가 장애 조치 의 근본 원인 이라는 데 동의하지 않습니다. 다른 희생자 / 증상 일 가능성이 높습니다).
최근에 펌웨어 업데이트가 있거나 스토리지 하위 시스템에 최신 펌웨어 업데이트가 필요한지 스토리지 관리자에게 확인하십시오. SQL 환경에서이 메시지를 여러 번 보았고 한 가지 볼 수있는 것은 스토리지 계층 구성입니다 (이것은 일반적인 원인입니다). 또한 perfmon을 사용하여 디스크 성능을 모니터링하는 한 가지. 디스크 카운터는 당신이에 초점을 맞출 필요가 : avg disk sec/Read, avg disk sec/Write, avg disk sec/Transfer.
아래에서 볼 수있는 다음 링크를 확인할 수 있습니다.
- 작동 방식 : FlushCache 메시지는 언제 SQL Server 오류 로그에 추가됩니까?
- https://techcommunity.microsoft.com/t5/sql-server-support/how-it-works-when-is-the-flushcache-message-added-to-sql-server/ba-p/317038
스토리지 계층이라고하면 다음을 확인하십시오. HBA / CNA, 파이버 케이블, FC 스위치, 포트, 스토리지 컨트롤러, 소프트웨어 (MPIO 드라이버)-모든 구성
마지막으로 이벤트 로그의 경고 / 오류 메시지를 항상 확인하고 조사하는 것이 좋습니다. 이런 종류의 메시지는 장기적인 영향을 미치므로 전달하지 마십시오 .