답변:
나의 충고:
sp_updatestats데이터베이스의 모든 테이블에 대한 모든 통계를 업데이트하지만 저장된 proc 재 컴파일도 발생하므로 신중하게 시간을 선택하십시오 (즉 sp_updatestats, 월말보고가 아마도 최적이 아닌 경우).인덱스 유지 관리 / 재 구축 통계를 실행해야하는 빈도는 데이터베이스로드, 특히 데이터 수정 빈도 (예 : INSERT/ UPDATE/ DELETE)에 따라 다릅니다 . 쇼 전체에서 데이터를 수정하는 경우 (예 : 주간 배치 프로세스를위한 준비 테이블) 통계를 업데이트하거나 야간에 인덱스를 재구성 할 수 있습니다. 데이터가 좀 더 정적 인 경우 주별 또는 격주로 예약 할 수 있습니다.
힙을 잘못 인덱싱하고 ETL이 많은 나쁜 앱으로 한 번만 보았습니다.
이것은 쓰레기 였고 다행히 내 것이 아닙니다.
그렇지 않으면 이유가 없습니다.
부적절한 시간에 통계 업데이트를받는 경우 잘못된 인덱스 / 통계 유지 관리를 수행 중이거나 임계 값에 도달하는 대규모 삭제 /로드가 있음을 의미합니다.
SQL Server 2005+를 사용하면 통계 업데이트를 연기 할 수 있습니다. "동기 또는 비동기 통계 업데이트 사용시기"를
참조하십시오.
그들이 선택한 기사를 보거나이 선택을하기 위해 읽은 것은 흥미로울 것입니다 ...
예전 (SQL Server 2000)에서 자동 업데이트 통계 설정을 사용하면 SQL이 통계 업데이트를 수행하기로 결정할 때 OLTP 응용 프로그램에서 "일시 중지"가 발생할 수 있습니다.
SQL Server 2005부터는 통계가 오래되어 다시 컴파일 될 때 "일시 중지"되지 않는 비동기 옵션이 있습니다. 통계는 다음에 필요할 때 비동기 적으로 재 컴파일됩니다.
대규모 데이터 세트의 경우 비효율적 인 쿼리 계획으로 쿼리가 기하 급수적으로 길어질 수 있으므로 현재 데이터가 최신 통계를 고려할 수 있습니다.
또한 증명이 푸딩에 있다고 말한 것처럼 SQL Server에서 게시 한 perfmon 카운터를 사용하여 초당 재 컴파일 수 및 기타 중요한 성능 메트릭을 모니터링 할 수 있습니다 .
시스템이 얼마나 활발합니까?
이들이 대부분 읽기 시스템 인 경우 데이터를 변경할 때 (삽입, 업데이트, 삭제) 수동으로 수행하는 경우 업데이트하지 않고 얻을 수 있습니다.
그러나 모범 사례를 위해서는 성능 문제가 거의 없기 때문에 원인을 유지하는 것이 좋습니다. 아마 그들에게 기사와 블로그 게시물을 남길 것이라고 제안 할 것입니다. 킴벌리 트립 에는 좋은 것들이 있습니다.
MrDenny는 어떤 식 으로든 모순되거나 의도적으로 반대하지는 않지만 (자신의 지식과 커뮤니티에 대한 기여에 대해 너무 많은 존경을 표함) 자동 업데이트 통계를 해제 할 것을 권장하는 MS 설명서를 보았습니다.
에서 저장 및 SQL Server 용량 계획 및 구성 (SharePoint Server 2010)을 MS가를 설정할 것을 권장합니다.
또한 이전 버전의 SP에 대한 MS의 동일한 권장 사항을 읽었지만 지금은 링크를 찾을 수 없습니다.
그러나 저는 SP 전문가 DBA가 아니기 때문에 MS Permier Field Engineer 인 Chun Liu가 SharePoint의 Chun Liu 에서 이에 대해 말한 내용을 확인하거나이 게시물을 무시하고 그대로두기를 원할 수도 있습니다 .