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

빠른 쿼리는 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 엔진은 로컬로 필터링하거나 집계 할 행이 많을 때 성능이 떨어지는 것 같습니다. 물론, 이러한 문제는 자주 해결할 수있는 결과 집합 디자인 문제이지만 (드릴 다운에 세부 정보가 필요한 경우에는 항상 그런 것은 아니지만) 좀 더 성숙한 ...보고 엔진이 더 관대합니다.

---

In my case, I just had to disconnect and connect the SSMS. I profiled the query and the duration of execution was showing 1 minute even though the query itself runs under 2 seconds. Restarted the connection and ran again, this time the duration showed the correct execution time.

---

Couple of things you can do, without executing the actual report just run the sproc from within the data tab of reporting services. Does it still take time? Another option is to use SQL Profiler and determine what is coming in and out of the database system.

Another thing you can do to test it, so to recreate a simple report without any parameters. Run the report and see if it makes a difference. It could be that your RS report is corrupted or badly formed that may cause the rendering to be really slow.

---

Had the same problem, and fixed it by giving the shared dataset a default parameter and updating that dataset in the reporting server.

---

DO you use "group by" in the SSRS table?

I had a report with 3 grouped by fields and I noticed that the report runed very slowly despite having a light query, to the point where I can't even dial values in the search field.

Than I removed the groupings and now the report goes up in seconds and everything works in an instant.

---

I was able to solve this by removing the [&TotalPages] builtin field from the bottom. The time when down from minutes to less than a second.

Something odd that I could not determined was having impact on the calculation of total pages.

I was using SSRS 2012.

---

In our case, no code was required.

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

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

참고 URL : https://stackoverflow.com/questions/2283943/fast-query-runs-slow-in-ssrs