저장 프로 시저에 대한 실행 계획이 없습니다.


12

저장 프로 시저의 캐시에서 계획이 누락 된 이유는 무엇입니까?

  1. WITH RECOMPILE
  2. 동적 SQL
  3. 암호화 된 코드
  4. 중요한 데이터 변경
  5. 통계 업데이트
  6. 또 뭐요?

리소스를 많이 사용하는 저장 프로 시저에 대한 캐시 계획이없는 최근에 2 대의 서버 (SQL Server 2008 R2 및 SQL Server 2012)에서 작업했습니다. 저장 프로 시저 내부의 많은 명령문도 캐시에 계획이 없었습니다. 저장 프로 시저 중 일부는 초당 몇 번처럼 자주 실행됩니다.

메모리 압력이 전혀 없습니다. 서버 중 하나에 필요한 것보다 훨씬 많은 하드웨어가 있습니다.

누락 된 계획은 저장 프로 시저 중간에 임시 테이블이 생성 되었기 때문에 SQL Server 2000 이전 버전의 오래된 정보 인 것 같습니다. SQL Server 2005부터는 DDL 이후 명령문의 명령문 레벨에서 재 컴파일이 발생합니다. 모든 경우에 해당됩니까 아니면 최신 버전에서도 계속 발생할 수 있습니까?

누락 된 계획의 원인은 무엇입니까? 이 주제에 관한 몇 가지 기사를 훑어 보았지만 아무것도 맞지 않는 것 같습니다.

이번 주에보고있는 서버에서 임시 작업에 대한 최적화 가 활성화되었습니다. 저장 프로 시저 중 하나는 하루에 한 번만 실행됩니다. 그 코드가 있습니다. 분당 100 회 이상 실행되는 코드는 없지만 얻을 수 있습니다. 코드를 게시 할 수 없지만 내 질문과 관련하여 코드를 설명 할 수 있습니다.

누구도 프로 시저 캐시를 비우거나 클린 버퍼를 삭제한다고 생각하지 않습니다. 이 클라이언트는 Solarwinds DPA를 모니터링 도구 중 하나로 사용하고 있습니다. DPA는 하루에 한 번 호출되는 스토어드 프로 시저의 명령문에 대한 실행 계획 중 하나를 캡처했습니다. 이 구문은 비파괴 적 WHERE절로 인해 많은 양의 읽기가 수행 됩니다. DPA가 명령문을 캡처 한 경우 예상 계획이며 한 번에 계획 캐시에있었습니다. 우리가 문제를 해결할 때 존재하지 않습니다. sp_WhoIsActive테이블에 로깅 을 시작하도록하겠습니다 .

을 사용하고 sp_BlitzCache있습니다. (Brent Ozar Unlimited에서 일합니다.) 이것은 전체 저장 프로 시저에 대한 계획과 개별 진술에 대한 계획이있는 경우이를 보여줍니다. 존재하지 않는 경우 "이 쿼리에 대한 계획을 찾을 수 없습니다. 가능한 이유는 동적 SQL, RECOMPILE힌트 및 암호화 된 코드가 있습니다." 라는 경고가 표시 됩니다. 그리고 그 경고는 진술에도 있습니다.

TF 2371이 제자리에 없습니다. 대기 통계를보고 있습니다. 서버가 지루합니다. PLE은 130,000이 넘습니다.

이제 2 개의 저장 프로 시저에 대한 코드가 있습니다. 그중 하나는 동적 SQL을 사용하여 exec (@sql)계획이없는 이유를 알 수 있습니다. 그러나 다른 하나는 분당 100 회 이상 실행되는 것입니다. 그중에서 눈에 띄는 유일한 것은 임시 테이블이 1000 줄 이상의 코드 중간에 만들어지고 있다는 것입니다. 자식 저장 프로시 저도 호출합니다.

SQL Server 2008의 계획 캐싱 과 관련하여 리터럴이 8k보다 크지 않지만 저장 프로 시저 중 하나는 다른 저장 프로 시저를 호출하기 직전에 대량 삽입에 대한 주석이 있습니다. 그러나 대량 삽입은 내가보고있는 외부 저장 프로 시저에 나타나지 않습니다. 이 기사의 "재 컴파일 임계 값"섹션이 흥미 롭습니다. 내가 임시 테이블에보고있는 것은 수많은 INSERT (수백만 행을 초래할 수 있음), 일부 업데이트 및 삭제입니다. 임시 테이블에 많은 데이터가 변경되었습니다. 수백만.


문제를 재현하는 저장된 procs가 있으므로 문제를 재현하는 최소한의 예제를 작성하여 문제를 찾을 수 있습니까?
— Martin Smith

답변:


3

두 가지 계획 캐시 DMF가 있습니다.

sys.dm_exec_query_plan- 캐시 된 계획을 XML 형식으로 반환하지만 특정 크기까지만 (SQL Server에서 XML로 형식을 지정할 수있는 경우에만 최대 128 개의 중첩 된 수준을 의미)

sys.dm_exec_text_query_plan- 캐시 된 계획을 모든 크기의 텍스트 형식으로 반환합니다. 그러나 계획이 크면 SQL Server에서 XML로 변환 할 수 없으며 XML이 null을 반환하므로 TRY_CONVERT조차도 단점입니다.

sp_BlitzCache는 이전 DMV에만 적용됩니다 (모든 종류의 슬라이싱 및 다이 싱을 수행하기 위해 쿼리 계획을 XML로 분석해야하기 때문에). Github 문제 # 838 을 개선하여 최소한 사용자에게 sys.dm_exec_text_query_plan을 확인하도록 경고했습니다 더 큰 쿼리. 그래도 여전히 XML 분석을 수행 할 수는 없습니다.


또한 동일한 이유 sys.query_store_plan.query_plan는 nvarchar(MAX)XML 이 아니라 (SQL 퀴즈)입니다.
— Remus Rusanu

@RemusRusanu ooo, 큰 계획이 거기에 나타납니다! 좋은.
— 브렌트 오자르

누락 된 계획이 귀하가 찾은 것으로 인한 것인지 확인하고 있습니다. 답장을 받으면 업데이트를 게시합니다.
— Tara Kizer

고객으로부터 답장을받지 못했지만 답변으로 표시하고 있습니다. 남은 것은 유일하게 남은 일이며 엄청난 쿼리가 주어지면 말이됩니다. 변경 사항이 있으면 업데이트를 게시하겠습니다.
— Tara Kizer

@TaraKizer 당신은 당신의 분기 별 검토가오고 있기 때문에 단지 이것을하고 있습니까? 난 당신이 무슨 짓을했는지 참조. 보너스가 잠금 해제되었습니다.
— 브렌트 오자르

0

SSMS에서 표로 반환 할 수있는 XML의 최대 크기를 조정해야합니까?


Tara가 지적했듯이 테이블에 쓰고 길이를 확인하더라도 데이터가 다시 나타나지 않습니다.
— 브렌트 오자르
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.