이 질문을 읽으면 얼마 전에 있었던 질문이 떠 올랐습니다.
RAM이 512GB 인 SQL Server가 있고 주 데이터베이스는 450GB입니다. 우리는 TempDB에서 꽤 많은 행동을 봅니다 (오케이, 나는 그것이 아주 많은 행동이라고 생각합니다. 그렇지 않을 수도 있습니다!). RamDisk Plus Server의 데모 버전을 설치하고 50GB 램 드라이브를 생성하고 TempDB를 지정했으며 성능이 전혀 향상되지 않았습니다.
TempDB에 쓰는 경우 항상 실제 디스크에 실제 쓰기가 발생합니까, 아니면 Windows 파일 시스템 캐시에서와 같이 쓰기 지연을 위해 SQL Server가 TempDB 쓰기를 캐시합니까?
이 시나리오에서 램 디스크가 의미가 없습니까?
SQL Server 6.5가 TempDB-In-Ram을 지원한다는 것을 알고 있지만 오래 전에 중단되었습니다.
답변:
TempDB에 쓰는 경우 항상 실제 디스크에 실제 쓰기가 발생합니까, 아니면 Windows 파일 시스템 캐시에서와 같이 쓰기 지연을 위해 SQL Server가 TempDB 쓰기를 캐시합니까?
항상 그래요? 가장 확실하지 않습니다. 그들은 적이 있습니까? 네,하지만 일반적인 메커니즘의 결과는 아닙니다. 여기에서 참조는 tempdb에 대한 검사 점이 무엇입니까? .
"잘 작동 된"시스템에서 사용자 데이터베이스 파일에 대한 쓰기는 검사 점에서 발생합니다. 잘못 작동하는 시스템에서 lazywriter가 다른 페이지를위한 공간을 확보하기 위해 버퍼 풀에서 페이지를 플러시해야 할 때 쓰기도 발생합니다.
검사 점은 tempdb 로그 파일이 70 % 가득 찼을 때 tempdb에 대해서만 수행됩니다. 이는 가능한 경우 tempdb 로그가 커지는 것을 방지하기위한 것입니다. 사용자 데이터베이스에서와 같이).
그러나 응급 복구는 tempdb에서 실행되지 않으므로 항상 시작할 때 다시 생성되므로 tempdb를 디스크로 플러시 할 필요가 없습니다.
충돌시 Tempdb는 복구되지 않으므로 lazywriter 프로세스 (버퍼 풀의 일부)가 다른 데이터베이스의 페이지를위한 공간을 만들어야하는 경우를 제외하고, 더티 tempdb 페이지를 디스크로 강제 실행할 필요가 없습니다.
이것은 놀랍게도 (나에게 놀랐습니다) tempdb 페이지가 디스크에 기록되는 유일한 메커니즘입니다. 버퍼 풀 압력이 있으면 tempdb 페이지가 디스크로 플러시 될 수 있습니다. 없는 경우 발생하지 않아야합니다.
편집 : "잘못된 동작"이 체크 포인트 외부에서 페이지를 작성하는 사용자 데이터베이스에 대한 적절한 설명인지 여부에 대해 논란의 여지가 있습니다. 비정상적이거나 비정형 적이거나 이상적이지 않은가?
추가 편집 (@PaulWhite와의 의견 / 채팅에 이어) :
위의 눈부신 누락은 임시 테이블이 tempdb 트래픽의 유일한 소스가 아니라는 것입니다. 해시, 정렬 및 교환 유출 이벤트 이해 에서 인용 :
특정 SQL Server 쿼리 실행 작업은 중간 정도의 대용량 메모리를 중간 저장소로 사용하여 최상의 성능을 발휘하도록 교정됩니다. Query Optimizer는 계획을 선택하고이 메모리 스크래치 패드를 사용하여 이러한 연산자를 기반으로 비용을 추정합니다. 그러나 이것은 물론 추정치 일뿐입니다. 실행시 추정치가 잘못 될 수 있으며 메모리가 충분하지 않더라도 계획을 계속해야합니다. 이러한 경우 이러한 운영자는 디스크에 유출됩니다.
필자는 유출 작업에 대한 물리적 쓰기의 메커니즘이 앞에서 설명한 것과 정확히 동일하다고 가정했습니다. 즉, 버퍼 풀에 압력이 가해지면 tempdb 페이지를 디스크에 강제로 기록하는 지연 기록기 (유출로 인한)입니다.
@PaulWhite는 내가 잘못한 곳을 설명했습니다 (Paul에게 감사합니다!).
쿼리가 메모리 내 tempdb를 사용하는 대신 작업 공간 메모리 부여를 초과 할 때 실제 tempdb 활동이 발생하는 이유를 묻는 것 같습니다. 그렇다면 쿼리가 부여보다 많은 메모리를 사용하여 메모리 제한의 포인트를 잃어 버릴 것입니다. 우선 보조금.
유출은 실제로 저장소를 통해 서면으로 특별합니다. 실제 tempdb 활동은 여유 메모리가 부족하고 tempdb에 대한 압력이없는 경우에도 유출시 나타납니다.
Paul은 또한 자신의 블로그 게시물 Advanced TSQL Tuning : 왜 내부 지식이 중요한지에 대해 설명했습니다. 여기에는 유출을 시연하기위한 예제 스크립트가 포함되어 있습니다.