SSRS 성능

Question

저장 프로 시저를 사용하여 55000 개의 레코드를 검색하는 SSRS 보고서를 만들었습니다. Stored Proc에서 을 실행하면 3 초가 걸리지 만 SSRS 보고서를 실행하면 1 분 이상 걸립니다. 이 문제를 어떻게 해결할 수 있습니까?

Answer 1

추가 시간은 데이터를 쿼리하는 것 외에 보고서를 렌더링하는 Reporting Services 때문일 수 있습니다. 예를 들어 보고서에 대해 55,000 개의 행이 반환 된 경우 보고서 서버는 해당 행을 그룹화, 정렬 및/또는 필터링하여 보고서를 렌더링해야하므로 추가 시간이 소요될 수 있습니다.

보고서에서 데이터를 그룹화하고 필터링하는 방법을 살펴본 다음 저장 프로 시저를 검토하여 일부 처리를 SQL 코드에 오프로드 할 수 있는지, 어쩌면 일부 매개 변수를 사용하여 확인할 수 있습니다. 보고서로 반환되는 행의 양을 보고서를 렌더링하는 데 필요한 최소 수준으로 줄이고 보고서에서 그룹화 및 필터링을하지 않는 것이 좋습니다.

Answer 2

ReportServerDB에는 ExecutionLog라는 테이블이 있습니다. 보고서의 카탈로그 ID를 찾아보고 최신 실행 인스턴스를 확인해야합니다. 이것은 데이터 수집, 처리, 렌더링 등을위한 시간의 단축을 말해 줄 수 있습니다.

Answer 3

분명히 보고서를 올바르게 실행하는 것 (즉, SSMS와 동일한 시간 순서로 데이터를 선택하는 것))가 좋지만 해결 방법은 보고서가 실행 스냅 샷 (즉, 매개 변수가 없거나 보고서에 매개 변수 기본값이 저장 됨)을 지원합니까?

이렇게하면 데이터의 예약 된 스냅 샷을 미리 검색하고 저장할 수 있으므로 SSRS는 사용자가 열 때 보고서를 처리하고 렌더링하면됩니다. 대기 시간을 몇 초로 줄여야합니다 (보고서 처리에 따라 YMMV, 성능 향상 여부를 테스트).

보고서 관리자의 보고서 속성 탭으로 이동하여 실행을 선택하고 보고서 실행 스냅 샷에서이 보고서 렌더링으로 변경하고 일정을 지정합니다.

Answer 4

SSRS Performance Dashboard 보고서를 사용하여 문제를 디버깅하십시오.

Answer 5

내 SP에서 스니핑하는 매개 변수 때문에 이러한 문제가 발생했습니다. SQL Management Studio에서 SP를 실행할 때 새로운 실행 계획으로 다시 작성했지만 호출 속도가 빨랐습니다. 그러나 다른 보고서의 매개 변수에 대한 잘못된 계획이 사용되어로드 시간이 SQL MS보다 훨씬 길었습니다.

Answer 6

과속 SSRS 보고서의 기본 솔루션은 캐시 보고서입니다. 예를 들어, 오전 7시 30 분에 캐시를 미리로드하거나 보고서를 캐시하면로드 속도가 크게 향상됩니다.

나는이 매일 전문적으로 및 않는 단순히 SSRS에 캐싱 SSRS

에

시적 왁싱하고 있지 않다 유의하시기 바랍니다 http://msdn.microsoft.com/en-us/library/ms155927.aspx

사전로드 당신이 경우 캐시 http://msdn.microsoft.com/en-us/library/ms155876.aspx

을 초기 보고서가 오래 걸리거나 데이터가 정적 인 일일 총계정 원장 등이 싫어서 데이터가 하루 중 비교적 정적 인 것을 의미합니다. 캐시 수명을 늘릴 수 있습니다.마지막으로

, 비즈니스 관리자 대신 그들에게보다 쉽고 체계적으로 찾을 수 있습니다 시간 Excel 보고서에서 포인트를 보내드립니다 이메일 구독를 통해이 보고서를받을 수 있도록 당신은 또한 선택할 수 있습니다.

또한 SSRS의 매개 변수를 사용하여 사용자 및 빠른 쿼리가 쉽게 구문 분석 할 수 있습니다. 매개 변수화하려는 필터 빌더 유형 IN (@SSN) 유형에서, BIDS GUI의 왼쪽 상단에있는 데이터 소스 바로 위에있는 매개 변수 폴더에서 작성된 것을 찾으십시오. [SSRS에서 데이터 원본 섹션이 보이지 않으면 Ctrl + Alt + D를 누릅니다. 1. 보고서 관리자에 캐싱을 활성화하고 새로 고침 기간을 설정합니다 Performance Issuses with SSRS

Answer 7

몇 가지 다음과 같습니다 보고서의 성능을 향상시키기 위해 수행 할 수 있습니다

여기에 거의 동일한 질문을 참조 은닉처. 2. 저장 프로 시저가 이미 데이터를 렌더링하는 데 소요되는 시간이 매우 짧지 만 인덱싱을 적용하더라도 백엔드 수준에서 성능을 더 향상시킬 수는 있지만 보고서의 소스로 사용되는 모든 백엔드 데이터베이스 테이블에 인덱싱을 적용하십시오. 3. 보고서에 포함 된 데이터 집합 대신 공유 데이터 집합을 사용하고 이러한 모든 데이터 집합에도 캐싱을 적용합니다. 4. 가능한 경우 매개 변수를 기본값을로드하도록 설정합니다. 5. 저장 프로 시저에서 선택한 데이터를 줄이려 시도하십시오. 보고서에 사용하지 않는 기록 데이터가 포함 된 경우 필터를 추가하여 해당 데이터를 제외 할 수 있습니다.

Answer 8

같은 문제가 발생했습니다. 질의는 SQL에서 정상적으로 실행되었지만 SSRS에서는 아무것도 느리지 않았습니다. 데이터 세트에서 SSRS 매개 변수를 사용하고 있습니까? 특정 쿼리에서 보고서 매개 변수를 직접 사용하면 엄청난 성능 저하가 있음을 발견했습니다. 당신은 데이터 집합의 @reportParam라는 보고서 매개 변수를 가지고있는 경우

대신, 간단하게 다음을 수행하십시오

declare @reportParamLocal int 
set @reportParamLocal = @reportParam 

select * from Table A where A.field = @reportParam 

그것은 좀 이상하다. 나는 그것이 왜 작동하는지 잘 모르지만 그것은 나를 위해 않습니다.

Answer 9

보고서에서 요소가 실행 속도를 늦출 수 있는지 여부를 살펴 보는 것이 좋습니다.

예를 들어 나는 dateTimes 사이에 변환 할 때 거대한 실행 시간 차이를 발견했습니다. 보고서의 모든 요소가 CDate 함수를 사용합니까? 그렇다면 SQL 레벨에서 형식화를 수행하는 것이 좋습니다.

일반적으로 변환은 엄청나게 느려질 수 있으므로 데이터 세트를 살펴본 후 문제가 무엇인지 확인하십시오.

Answer 10

위의 답변이 약간 섞여 있지만 가장 간단하고 가장 완성 된 형식으로 저장 프로 시저에서 데이터를 다시 가져 오는 것이 가장 좋습니다. 나는 모든 정렬, 그룹화 및 서버에서 필터링을 수행합니다. 이 서버는 서버용으로 제작되었으므로보고 서비스가 멋진 디스플레이 작업을 수행하도록합니다.

Answer 11

나는 동일한 문제가있었습니다 ... 실제로 렌더링 시간 이었지만 더 구체적으로는 SORT가 SSRS에 있기 때문이었습니다. 저장 프로 시저로 정렬을 이동하고 SSRS 보고서에서 SORT를 제거하십시오. 55K 행에서 이것은 극적으로 향상됩니다.

Answer 12

고고 학적 질문이지만 일종의 반복적 인 일이기 때문에 대기업 환경에서 완벽하게 작동하는 SSRS를 개선하기위한 "빠르고 지저분한"솔루션 (매일 최대 100.000 개 이상의 라인을 가질 수있는 보고서를 렌더링하는 것입니다)은 페이지의 InteractiveSize을 올바르게 설정하십시오 (예 : A4 크기 -21cm로 설정). InteractiveSize가 0으로 설정되면 모든 결과가 단일 페이지로 렌더링되므로 문자 그대로 SSRS의 성능이 저하됩니다. 그런 경우 DB에서 몇 초가 걸릴 수있는 쿼리를 렌더링하는 데 오래 걸릴 수 있습니다 (또는 SSRS 서버에 중복 H/W가없는 한 메모리 부족 예외가 발생할 수 있음). 직접 호출에서 비교적 빠르게 실행되고 많은 수의 행을 검색하는 쿼리/SP의 경우 InteractiveSize를 설정하면 더 정교한 다른 솔루션을 사용하지 않아도됩니다. @ RomanBadiornyi의 대답 또한

Answer 13

는 저장 프로 시저에 메인 쿼리의 끝에

OPTION (RECOMPILE) 

를 추가하려고합니다.

이렇게하면 다른 매개 변수가 다른 실행 계획을 필요로 할 때마다 다른 매개 변수에 대해 쿼리가 매번 다시 컴파일되도록 할 수 있습니다.

Answer 14

비슷한 문제점이 있습니다. 4,000 개의 행을 반환하고 1 초 만에 실행되는 쿼리는 SSRS에서 시간이 너무 오래 걸렸습니다.

SSRS에서 다중 값 매개 변수를 처리하는 방식으로 인해 문제가 발생한 것으로 나타났습니다. 흥미롭게도 사용자가 여러 값을 선택하면 보고서가 빠르게 렌더링되고 (~ 1 초), 단일 값만 선택하면 보고서를 렌더링하는 데 몇 분이 걸립니다. 여기

는 것보다 렌더링 이상 100 배 많은 시간이 소요 된 원래 쿼리입니다 :

SELECT ... 
FROM ... 
WHERE filename IN (@file); 
-- @file is an SSRS multi-value parameter passed directly to the query 

나는 문제가 SSRS (1 백만 행 이상) 전체 소스 테이블에 가져 오는 것을이었다 의심하고 그런 다음 클라이언트 측 필터를 수행합니다.

이 문제를 해결하기 위해 필터를 직접 제어 할 수 있도록 표현식을 통해 쿼리에 매개 변수를 전달했습니다.

=JOIN(Parameters!file.Value,",") 

(나는 또한 그 결과 새 이름 준 : 파일 목록)를 그리고 그 "매개 변수"화면에서 "데이터 집합 속성"창에서, 나는이 식을 매개 변수 값을 대체 그때는 다음과 같이 할 수있는 쿼리를 업데이트 :

SELECT ... 
FROM ... 
WHERE ',' + @filelist + ',' LIKE '%,' + FILENAME + ',%'; 
-- @filelist is passed to the query as the following expression: 
-- =JOIN(Parameters!file.Value,",") 

내가 저장 프로 시저에 쿼리를 이동하는 것도 SSRS는 기본적으로 동일한 다중를 전달하기 전에 가입 않기 때문에 (문제를 완화 할 수있는 효과적인 방법이 될 것이라고 생각 것 저장 프로 시저에 대한 - value 매개 변수). 그러나 제 경우에는 보고서에서 모든 것을 처리하는 것이 더 간단했습니다.

마지막으로, LIKE 연산자는 항목 목록에서 필터링하는 가장 효율적인 방법이 아닐 수도 있지만 split-string 방식보다 훨씬 간단하게 코드를 작성할 수 있습니다. 보고서는 이제 두 번째로, 문자열을 분할하는 것은 여분의 노력의 가치가없는 것처럼 보입니다.