빠른 쿼리는 SSRS에서 느리게 실행됩니다.

저장 프로 시저를 호출하는 SSRS 보고서가 있습니다. 쿼리 창에서 직접 저장 프로 시저를 실행하면 2 초 이내에 반환됩니다. 그러나 2005 SSRS 보고서에서 동일한 쿼리를 실행하면 완료하는 데 최대 5 분이 걸립니다. 이것은 첫 번째 실행에서만 발생하는 것이 아니라 매번 발생합니다. 또한 다른 환경에서는 이와 동일한 문제가 발생하지 않습니다.

이 특정 환경에서 SSRS 보고서가 그렇게 느리게 실행되는 이유에 대한 아이디어가 있습니까?

여기에 제공된 제안에 감사드립니다. 우리는 해결책을 찾았고 매개 변수와 관련된 것으로 밝혀졌습니다. SQL Server는 '매개 변수 스니핑'으로 인해 SSRS 보고서에서 실행될 때 복잡한 실행 계획을 생성했습니다. 해결 방법은 저장 프로 시저 내에서 변수를 선언하고 들어오는 매개 변수를 변수에 할당하는 것입니다. 그런 다음 쿼리는 매개 변수가 아닌 변수를 사용했습니다. 이로 인해 SQL Server 관리자에서 호출하든 SSRS 보고서를 통해 호출하든 쿼리가 일관되게 수행되었습니다.

프로 시저 끝에 다음을 추가하십시오. option(recompile)

이렇게하면 보고서가 저장 프로시 저만큼 빠르게 실행됩니다.

비 저장 프로 시저 쿼리에서 동일한 문제가 있었다고 덧붙일 것입니다. 이를 수정하기 위해 데이터 세트 SQL 문 내에서 변수를 선언하고 SSRS 매개 변수와 동일하게 설정했습니다.

얼마나 성가신 해결 방법입니까! 그래도 대답에 가깝게 해주셔서 감사합니다!

나는 같은 문제가 있었는데, 여기에 문제에 대한 설명이 있습니다.

"저는 2200 개의 행을 생성하고 거의 2 초만에 실행되는 저장 프로 시저를 만들었지 만 SSRS 2008에서 저장 프로 시저를 호출하고 보고서를 실행 한 후 실제로 실행되지 않았으며 궁극적으로 BIDS (Business Intelligence Development Studio)를 종료해야합니다. 작업 관리자에서 ".

내가 시도한 것 : reportuser Login에서 SP를 실행 해 보았지만 SP도 해당 사용자에 대해 정상적으로 실행되고 있었으며 Profiler를 확인했지만 아무런 문제가 없었습니다.

해결책:

실제로 문제는 SP가 결과를 생성하지만 SSRS 엔진이 이러한 많은 행을 읽고 다시 렌더링하는 데 시간이 걸린다는 것입니다. 그래서 SP에 WITH RECOMPILE 옵션을 추가하고 보고서를 실행했습니다. 기적이 일어나고 문제가 해결되었습니다.

동일한 시나리오가 발생했습니다. 매우 기본적인 보고서 인 SP (1 개의 매개 변수 만 필요)는 10K 레코드를 다시 가져 오는 데 5 초가 걸리지 만 보고서를 실행하는 데 6 분이 걸립니다. 프로파일 러와 RS ExecutionLogStorage 테이블에 따르면 보고서는 쿼리에 모든 시간을 소비했습니다. Brian S.의 의견으로 해결책을 찾았습니다. SP의 AS 문 앞에 WITH RECOMPILE을 추가했습니다. 이제보고 시간이 SP 실행 시간과 거의 일치합니다.

Tablix 속성에서 '각 페이지의 헤더 열 반복'을 선택 취소했습니다.

저장 프로 시저가 연결된 서버 또는 openquery를 사용하는 경우 자체적으로 빠르게 실행될 수 있지만 SSRS에서 렌더링하는 데 시간이 오래 걸립니다. 몇 가지 일반적인 제안 :

• 연결된 서버를 사용하여 데이터를 검색하는 대신 다른 데이터 원본을 사용하여 데이터가 저장된 서버에서 직접 데이터를 검색합니다.
• 보고서를 실행하기 전에 원격 서버에서 로컬 테이블로 데이터를로드하여 보고서 쿼리를 단순하게 유지합니다.
• 테이블 변수를 사용하여 먼저 원격 서버에서 데이터를 검색 한 다음 연결된 서버와의 조인을 직접 반환하는 대신 로컬 테이블과 조인합니다.

질문에 대한 답변이 확인되었으며, 누군가 이와 동일한 문제가있는 경우를 대비하여 추가하는 것입니다.

32000 행을 검색하는 보고서에서 보고서 html 출력 문제가 발생했습니다. 쿼리는 빠르게 실행되었지만 웹 브라우저로의 출력은 매우 느 렸습니다. 제 경우에는 사용자가 첫 페이지를보고 Excel 파일을 생성 할 수 있도록“Interactive Paging”을 활성화해야했습니다. 이 솔루션의 장점은 첫 페이지가 빠르게 나타나고 사용자가 Excel 또는 PDF로 내보내기를 생성 할 수 있다는 것입니다. 단점은 사용자가 현재 페이지 만 스크롤 할 수 있다는 것입니다. 사용자가 더 많은 콘텐츠를 보려면 그리드 위의 탐색 버튼을 사용해야합니다. 제 경우에는 Excel로 내보내기가 더 중요했기 때문에 사용자가이 동작을 수락했습니다.

"대화 형 페이징"을 활성화하려면 보고서 창의 빈 영역을 클릭하고 속성 창의 보고서 수준에서 "InteractiveSize"\ "Height"속성을 변경해야합니다. 이 속성을 0과 다르게 설정합니다. 제 경우에는 8.5 인치로 설정했습니다. 또한 테이블 릭스 수준에서 "가능한 경우 한 페이지에 함께 유지"속성을 선택 취소했는지 확인합니다 (테이블 릭스를 마우스 오른쪽 단추로 클릭 한 다음 "Tablix 속성", "일반"\ "페이지 나누기 옵션").

Management Studio에서 빠르게 실행되지만 SSRS에서 매우 느리게 실행되는 내 저장 프로 시저의 유사한 문제를 발견했습니다. 오랜 노력 끝에 저장 프로 시저를 물리적으로 삭제하고 다시 생성하여이 문제를 해결했습니다. 그 뒤에있는 논리는 확실하지 않지만 저장 프로 시저에서 사용되는 테이블 구조의 변경 때문이라고 가정합니다.

나는 같은 문제에 직면했다. 나에게는 옵션을 푸는 것이 었습니다.

테이블 릭스 속성 => 페이지 나누기 옵션 => 가능한 한 한 페이지에 함께 유지

SSRS 보고서. 여러 페이지를 만드는 대신 모든 레코드를 같은 페이지에 넣으려고했습니다.

매개 변수 스니핑 문제를 제외하고는 SSRS가 일반적으로 (제 경우) Crystal 보고서보다 클라이언트 쪽 처리에서 느리다는 것을 발견했습니다. SSRS 엔진은 로컬로 필터링하거나 집계 할 행이 많을 때 성능이 떨어지는 것 같습니다. 물론, 이러한 문제는 자주 해결할 수있는 결과 집합 디자인 문제이지만 (드릴 다운에 세부 정보가 필요한 경우에는 항상 그런 것은 아니지만) 좀 더 성숙한 ...보고 엔진이 더 관대합니다.

제 경우에는 SSMS를 분리하고 연결해야했습니다. 쿼리를 프로파일 링했고 쿼리 자체가 2 초 미만으로 실행 되더라도 실행 시간이 1 분으로 표시되었습니다. 연결을 다시 시작하고 다시 실행했는데 이번에는 기간이 올바른 실행 시간을 표시했습니다.

실제 보고서를 실행하지 않고 수행 할 수있는 몇 가지 작업은보고 서비스의 데이터 탭에서 sproc을 실행하기 만하면됩니다. 아직도 시간이 걸리나요? 또 다른 옵션은 SQL 프로필러를 사용하여 데이터베이스 시스템에서 들어오고 나가는 항목을 확인하는 것입니다.

매개 변수없이 간단한 보고서를 다시 작성하기 위해 테스트 할 수있는 또 다른 방법입니다. 보고서를 실행하고 차이가 있는지 확인하십시오. RS 보고서가 손상되었거나 형식이 잘못되어 렌더링 속도가 매우 느려질 수 있습니다.

동일한 문제가 발생했으며 공유 데이터 세트에 기본 매개 변수를 제공하고보고 서버에서 해당 데이터 세트를 업데이트하여 문제를 해결했습니다.

SSRS 테이블에서 "그룹 별"을 사용합니까?

필드별로 그룹화 된 3 개의 보고서가 있는데 검색 필드에서 값을 입력 할 수없는 지점까지 간단한 쿼리에도 불구하고 보고서가 매우 느리게 실행되는 것을 확인했습니다.

그룹을 제거하고 이제 보고서가 몇 초 안에 올라가고 모든 것이 즉시 작동합니다.

하단에서 [& TotalPages] 내장 필드를 제거하여이 문제를 해결할 수있었습니다. 몇 분에서 1 초 미만으로 다운되는 시간입니다.

내가 결정할 수 없었던 이상한 점이 총 페이지 계산에 영향을 미쳤다는 것입니다.

SSRS 2012를 사용하고있었습니다.

우리의 경우에는 코드가 필요하지 않았습니다.

헬프 데스크의 참고 사항 : "인터넷 설정을 지우면이 문제가 해결됩니다."

"캐시 지우기"를 의미 할 수도 있습니다.