- 핫스팟이란 무엇입니까?
Aaron은 정확하고 위에서 말한 것을 다시 해치지 않을 것이지만 디스크 IO에 관한 것이 아닙니다. 대부분의 사람들이 TempDB에서 문제를 일으키는 주요 부분은 특정 추적 구조에 대한 경합 때문입니다.
여러 tempdb 파일을 사용하면 비례 채우기 및 라운드 로빈 알고리즘이 할당에서 "공정한"상태로 효과적으로 발생할 수 있으므로 할당없이 새 파일을 추가하면 파일이 조금씩 사라집니다. PAGELATCH_*새 파일에서 기다리거나 다른 파일에서 기다리지 않으면 "치킨 작은"경고 (아래 제품 업데이트 참조)에 동의하지 않습니다. 이는 일반적으로 TempDB 활동이 많고 이미 하나 이상의 파일이있는 시스템에서 발생합니다.
SQL Server 2019에는 일부 기본 시스템 테이블을 메모리 내 테이블로 변경 하는 옵션이 있으며, 이는 메모리 내 개체가 디스크 베이크 테이블과 다르게 할당되므로 개선 될 수 있습니다. 디스크 기반 테이블은 수년 동안 우리 모두가 작업해온 전통적인 테이블입니다. SQL Server 2014에는 메모리 최적화 테이블이 도입되었습니다 . SQL Server 2019는 메모리 최적화 테이블에서 일부 할당 메타 데이터를 처리 할 수 있습니다.
동시 PFS 변경을 지원하기 위해 SQL Server 2019에서 또 다른 변경이 이루어졌습니다. 이는 일반적으로 할당시 메모리 내 구조에 대한 경합이 PAGELATCH_*대기하는 것입니다.
- hot spotting은 tempdb에서 상황을 훨씬 더 악화시키는 것은 무엇입니까?
아무것도 IMHO. 예, TempDB에는 직접 사용하지 않고 쓰기를 유발할 수있는 더 많은 항목이 있으므로 일부 항목을 방해 할 수 있습니다. 그러나 데이터 변경 속도 측면에서 매우 바쁜 사용자 데이터베이스는 그다지 좋지 않습니다. TempDB에만 국한되지 않습니다.
- DB의 어떤 특정한 것들이 훨씬 더 나빠질까요?
나는 Aaron의 비유를 정말로 좋아한다! 그것이 무슨 일이 일어나고 있는지의 본질입니다. 실제로 악화되는 것은 데이터베이스의 객체에 대한 공간 할당 및 추적입니다. 사용자 데이터베이스가 대부분 정적이거나 (변화율이 낮음) TempDB를 실제로 사용하지 않는 경우 아무 것도 알 수 없습니다. 그러나 상당히 바쁜 서버 인 경우 페이지 래치 대기를 시작하거나 악화시켜 호송대를 막을 수 있습니다.
Aaron은 이미 이전 버전에는 균일 한 범위를 사용하고 파일 그룹의 모든 파일이 함께 성장하도록 추적 플래그가 있음을 지적했습니다 (Aaron은 2016+의 NOP 인 1117과 1118을 지적합니다). 내가 다시 지적하고 싶은 또 다른 것은 이것은 TempDB뿐만 아니라 모든 데이터베이스를위한 것이며 물리적 레이아웃은 필요에 따라 생각되어야한다는 것입니다.
이는 핫스팟 문제 일뿐 아니라 백업 / 복원, 파일 관리, 파일 시스템 메타 데이터 조각화 등과 같은 시스템의 다른 부분에도 적용 할 수 있으며, 여러 파일을 사용하면 도움이 될 수 있습니다.
waitresourcePFS 페이지 (1 페이지 후 8088 페이지마다) 를 찾아 할당 구조 경합을 볼 수 있습니다 . 동일한 파일 (2 : file : page)에 모두있는 경우 이것이 발생하고 있음을 알 수 있습니다.