SQL Server는 버퍼 캐시에 공간이 충분하지 않은 쿼리의 데이터를 어떻게 처리합니까?

내 질문은 SQL Server가 사용 가능한 공간보다 많은 양의 데이터를 버퍼 캐시로 가져와야하는 쿼리를 어떻게 처리합니까? 이 쿼리에는 여러 개의 조인이 포함되므로 결과 집합이 디스크에 이미이 형식으로 존재하지 않으므로 결과를 컴파일해야합니다. 그러나 컴파일 후에도 여전히 버퍼 캐시에서 사용할 수있는 것보다 더 많은 공간이 필요합니다.

예를 들어 보겠습니다. 사용 가능한 총 6GB의 버퍼 캐시 공간이있는 SQL Server 인스턴스가 있다고 가정하십시오. 7GB의 데이터를 읽는 여러 조인으로 쿼리를 실행하면 SQL Server가이 요청에 어떻게 응답 할 수 있습니까? tempdb에 데이터를 임시로 저장합니까? 실패합니까? 디스크에서 데이터를 읽고 한 번에 세그먼트를 컴파일하는 작업을 수행합니까?

또한 7GB의 총 데이터를 반환하려고하면 SQL Server에서 처리하는 방식이 변경됩니까?

이미이 문제를 해결하는 여러 가지 방법을 알고 있으며 SQL Server 가이 요청을 내부적으로 처리 할 때 어떻게 처리 해야하는지 궁금합니다.

또한이 정보가 어딘가에 있다고 확신하지만 찾지 못했습니다.

사용 가능한 여유 메모리가 없으면 수정되지 않은 가장 오래된 페이지가 들어오는 페이지로 바뀝니다.

이는 메모리에 들어갈 수있는 것보다 더 많은 데이터가 필요한 쿼리를 실행하면 많은 페이지가 메모리에서 매우 짧은 수명을 유지하므로 많은 I / O가 발생한다는 것을 의미합니다.

Windows 성능 모니터의 "페이지 수명 예상"카운터를 보면이 효과를 볼 수 있습니다. 봐 https://sqlperformance.com/2014/10/sql-performance/knee-jerk-page-life-expectancy 그 카운터에 대한 몇 가지 좋은 내용은.

주석 에서 쿼리 결과 가 사용 가능한 버퍼 공간보다 클 때 어떤 일이 발생하는지 구체적으로 물었습니다 . 가장 간단한 예를 들어, select * from some_very_big_table;테이블이 32GB이고 max server memory (MB)24GB로 구성되어 있다고 가정하십시오 . 테이블 데이터의 모든 32기가바이트은 한 번에 하나의 버퍼 페이지의 페이지로 읽을 수 있습니다 래치네트워크 패킷으로 포맷되어 유선을 통해 전송됩니다. 이것은 페이지 단위로 발생합니다. 300 개의 쿼리를 동시에 실행할 수 있으며 차단이 발생하지 않는다고 가정하면 각 쿼리의 데이터는 한 번에 한 페이지 씩 페이지 버퍼 공간으로 읽혀지고 클라이언트가 할 수있는 한 빨리 와이어에 연결됩니다 데이터를 요청하고 소비합니다. 각 페이지의 모든 데이터가 유선으로 전송되면 페이지가 래칭되지 않고 디스크의 다른 페이지로 매우 빠르게 대체됩니다.

예를 들어 여러 테이블에서 결과를 집계하는 것과 같이보다 복잡한 쿼리의 경우 페이지가 쿼리 프로세서에 필요한대로 정확하게 위와 같이 메모리로 가져옵니다. 쿼리 프로세서가 결과를 계산하기 위해 임시 작업 공간이 필요한 경우 쿼리 계획을 컴파일 할 때이를 미리 알고 SQLOS에 작업 공간 (메모리)을 요청합니다 . SQLOS는 어느 시점에서 ( 시간이 초과 되지 않는다고 가정 ) 쿼리 처리기에 해당 메모리를 부여하면이 시점에서 쿼리 처리가 다시 시작됩니다. 쿼리 프로세서가 SQLOS에 요청해야 할 메모리 용량을 잘못 추정 한 경우 "디스크 유출" 을 수행해야 할 수 있습니다.데이터가 중간 형식으로 tempdb에 임시로 쓰여지는 작업. tempdb에 작성된 페이지는 다른 페이지를 메모리로 읽을 수있는 공간을 만들기 위해 tempdb에 작성된 후에 래치 해제됩니다. 결국 쿼리 프로세스는 tempdb에 저장된 데이터로 돌아가서 래칭을 사용하여 버퍼링 된 페이지를 사용 가능한 것으로 표시된 페이지로 페이징합니다.

위 요약에서 매우 기술적 세부 사항이 많이 누락되었지만 SQL Server가 메모리에 넣을 수있는 것보다 더 많은 데이터를 처리하는 방법의 본질을 포착한다고 생각합니다.

이 시나리오에서 쿼리가 정확히 무엇을 할 지 말할 수는 없지만 SQL Server에는 필요한 양에 따라 몇 가지 옵션이 있습니다.

• 데이터가 TempDB에 "유출"될 수 있습니다. 이것은 디스크를 사용하는 것입니다
• 이전 페이지는 버퍼 캐시에서 푸시 될 수 있습니다
• SQL Server는 일부 페이지를로드하여 캐시를 버퍼링 한 다음 사용하여 새 페이지를

발생하는 상황을 확인하는 가장 좋은 방법은 개발 환경에서 시나리오를 만들고 알아내는 것입니다.

내 질문은 SQL Server가 더 많은 양의 데이터를 버퍼 캐시로 가져와야하는 쿼리를 처리하는 방법이며 사용 가능한 공간이 있습니다.

이 특정 부분에 대답하기 위해 이것이 어떻게 관리되는지 알려 드리겠습니다. 페이지 크기는 8KB입니다. 큰 데이터 세트를 요청하고 많은 페이지를 메모리로 가져와야하는 쿼리를 실행할 때 SQL Server는 모든 페이지를 한 번에 가져 오지 않습니다 . 특정 페이지를 찾아 하나의 8KB 페이지를 메모리에 가져 와서 데이터를 읽은 다음 결과를 얻습니다. 이는 메모리가 적은 경우에 이전 페이지가 플러시되는 상황에 직면한다고 가정합니다. @Max와 같은 디스크가 지적했습니다. 올바르게 짐작 했듯이이 낮은 메모리는 오래된 페이지를 제거하는 데 시간이 걸리기 때문에 속도가 느려질 수 있습니다. 이것은 검사 점과 지연 기록기입니다사진에 온다. Lazywriter는 디스크에 새 페이지를 가져 오기 위해 항상 사용 가능한 메모리가 있는지 확인합니다. 여유 공간이 부족하면 버퍼가 트리거되고 여유 공간이 새 페이지가됩니다.

편집하다

나는 그것을 얻지 만 조금 방해하는 부분은 \ filtering 데이터를 결합하고 그 결과가 캐시 크기를 초과하면 발생하는 것입니다.

조인 및 필터링을위한 메모리는 쿼리가 실행되기 전에도 결정되며 실제로 메모리 크런치가 있고 작업을 실행하는 데 필요한 메모리를 사용할 수 없다고 가정하면 SQL Server 프로세서는 "필수 메모리"를 부여합니다.

필요한 메모리 : 정렬 및 해시 조인을 실행하는 데 필요한 최소 메모리. 이 메모리를 사용할 수 없으면 쿼리가 시작되지 않기 때문에 필수라고합니다. SQL Server는이 메모리를 사용하여 정렬 및 해시 조인을 처리하기위한 내부 데이터 구조를 만듭니다.

따라서 적어도 쿼리가 실행되기 시작하지만 런타임 중에 중간 결과가 Tempdb에 유출되어 속도가 느려질 수 있습니다. 쿼리 메모리 부여 이해 를 읽는 것이 좋습니다.