매일 SQL Server 재생성 계획


14

프로덕션 환경에서이 문제가 있습니다.

Windows NT 6.1 (빌드 7601 : 서비스 팩 1)의 Microsoft SQL Server 2008 R2 (SP1)-10.50.2500.0 (X64)-Enterprise Edition (64 비트)

SQL Server는 이전 실행 계획을 모두 (거의 100 %) 삭제하고 매일 밤 11 시부 터 오전 8 시까 지 매일 다시 만듭니다. 이것은 '자동 업데이트 통계'가 비활성화 상태 일 때도 발생했습니다. 지난 2-3 주 동안 '자동 업데이트 통계'를 사용 설정했습니다. 그러나 여전히 일어나고 있습니다.

우리는이 계획의 재생성을 유발하는 요소를 실제로 알지 못하지만 수동으로하지는 않을 것입니다.

실제로 재생성 계획의 타이밍과 일치하는 유일한 것은 DB 유지 관리 작업입니다. 일일 인덱스 재구성 (분할이 5-30 % 인 경우) 및 일일 인덱스 재구성 (분할이 30 % 이상인 경우) ) 직업. 일반적으로이 일일 유지 보수 작업은 재구성 만 수행합니다 (인덱스 조각화는 매일 30 %를 넘지 않기 때문에).

타격:

새로 생성 된 계획은 일부 UDF 호출 / 쿼리 호출 (UI / 웹 페이지에서 호출)을 더 오래 (1 초 미만이 아닌 몇 분) 더 오래 걸리게하므로 CPU를 90 % 가까이 가져 가서 세션이 쌓입니다. .

문제가 발생한 세션이 DB 측에서 강제로 삭제되는 순간 (1), 해당하는 모든 실행 계획이 수동으로 (쿼리의 경우) 또는 2) UDF가 변경된 경우 (기능의 경우)에는 문제가 해결됩니다. 그 순간부터 SQL Server가 만든 새로운 계획은 하루 종일 완벽하게 작동하여 다음날 아침 같은 문제가 발생합니다. 또한이 동작은 100 % 일관성이 없으며 매일 아침마다 표시되지 않습니다. 그러나 4 ~ 5 일 동안 지속적으로보고있는 기간이있었습니다.

업무 시간에 문제가 발생합니다. UI / 웹 페이지에 더 집중적으로 액세스하는 것 같습니다.

누구나이 문제의 원인 과이 문제를 해결하는 방법에 대한 단서가 있습니까? 도움을 주시면 감사하겠습니다.


3
시스템이 메모리 부족 상태이거나 설정을 db 레벨로 변경 한 경우 plancache를 해제 할 수 있습니다. (변경 db). "수동으로"삭제하지 않는다고 말했기 때문에 메모리가 부족할 수 있습니다. 기계의 메모리 용량은 얼마입니까? 최대 메모리 설정은 무엇입니까? 가상 환경과 전체적으로 할당 된 RAM이 있습니까?
RayofCommand

6
왜 SP1에 있습니까? 어떤 작업을 수행하기 전에 SP3을 적용하십시오. SQL Server는 메모리가 부족한 경우 큰 테이블이있는 경우 인덱스 재 구축의 페이지를 수용하기 위해 더 많은 메모리가 필요한 경우 계획을 강제 실행할 수 있습니다. 인덱스 재 구축은 가능한 한 많은 페이지를 가져 오려고합니다. MP 사용을 중단하고 Ola Hallengren 솔루션을 사용하여 이것이 도움이되는지 확인하십시오. 최대 서버 메모리 란 무엇입니까?
Shanky

1
여러분, 저는 DBA가 아니며 SQL 개발자 일뿐입니다. 나는 꽤 오랫동안 진행되어 왔기 때문에이 모든 것을 요구하고 있습니다. 귀하의 의견에 감사드립니다. 지금은 따르기가 어렵다는 것을 알지만 모든 의견에 답변하려고 노력할 것입니다. MP 란?
peter.petrov

1
@ peter.petrov 우리는 당신의 환경을 알게함으로써 당신을 돕기 위해 노력하고 있습니다. MP = 유지 보수 계획.
Kin Shah

1
실제 문제는 쿼리 계획이 너무 취약하다는 것입니다. 재 컴파일은 하루 중 언제라도 발생할 수 있습니다. 보장하지 않습니다. 계획이 안정되도록 쿼리를 수정하십시오. 알 수없는 옵션의 권장 사항 또는 최적화 방법은 적절하고 신속하게 해결할 수있는 슬레지 해머 방식입니다.
usr

답변:


2

글쎄, 나는이 행동을 일으킬 수있는 몇 가지 아이디어가 있습니다.

  1. 기억력을 모니터링합니까? 쿼리가 일정 한도를 설정하면 계획 캐시가 비워 질 수 있습니다. 응용 프로그램을 모르지만 프런트 엔드 서버의 로그와 일치합니까? 이 시간에도 압력이 있습니까?
  2. 전용 SQL Server가 있거나 서버가 다른 프로세스 / 서비스와 하드웨어를 공유합니까? 그렇지 않은 경우 대신 SQL Server를 전용 컴퓨터로 아웃소싱하는 것을 고려하십시오. 다른 서비스의 부작용을 줄일 수 있습니다.
  3. 을 사용 optimize for ad hoc workloads하면 계획 스텁을 저장하고 필요한 경우 컴파일합니다. 이렇게하면 plancache의로드가 줄어들어 plancache가 플러시 될 가능성이 줄어 듭니다. 을 사용하여 활성화 할 수 있습니다 sp_configure 'optimize for ad hoc workloads',1; reconfigure. advanced optionsusing 을 활성화 한 경우이 작업을 수행 할 수 있습니다 sp_configure 'show advanced options',1; reconfigure.
  4. 또 다른 아이디어는 백업이 될 수 있습니다. 간단한 백업. 공격적으로 공격을 받으면 장비에 압력이 가해질 수 있습니다. 언급 한 시간은 백업을 계획하기에 좋은 시간 간격처럼 들립니다.
  5. 아마도 유지 보수 스크립트의 버그 일 것입니다. 스크립트가 기준과 일치하는 인덱스 대신 모든 인덱스를 다시 작성하게하는 논리적 문제가 있는지 확인 했습니까? 이로 인해 발생할 수도 있습니다.

그냥이 모든 가능성 옆에, 일부 옵션의 변경 사항에 대한 로그 파일을 확인하는 것이 유용 할 수 있습니다 affinity mask, affinity I/O mask그들의 64 파트너. 또 다른 것은 MAXDOP인스턴스 옵션의 변경 일 수 있습니다 . 로그도 확인하십시오. plancache도 플러시해야합니다.

마지막으로 서버 측 추적을 실행할 수 있습니다 (프로파일 러를 사용하여 설정, 시작, 중지 및 sql 명령을 사용하여 서버 측에서 다시 시작). 그 옆에 perfmon당신의 친구가 있습니다. 한동안 성능 값을보고 모니터링 할 수 있습니다. 서버에서 특정 작업을 수행 할 때 압력이 가중되어 해당 플러시가 발생할 수 있습니다.

답이 조금 후에도 도움이되기를 바랍니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.