보고서 문제 해결: 보고서 성능
보고서를 볼 때 첫 페이지가 표시되는 데 오랜 시간이 걸리는 경우가 있습니다. 보고서 처리 시간이 오래 걸리는 이유를 확인하려면 보고서 문제 해결 기술을 참조하십시오. 데이터 검색, 보고서 처리 또는 보고서 렌더링 중 시간이 지연되는 이유가 무엇인지 확인한 후 이 항목을 사용하여 문제를 해결하십시오.
데이터 검색 시간이 너무 오래 걸리는 경우
보고서 처리 시간이 너무 오래 걸리는 경우
보고서 렌더링 시간이 너무 오래 걸리는 경우
보고서 처리를 최적화하기 위한 디자인 팁
데이터 검색 시간이 너무 오래 걸리는 경우
보고서 데이터가 많을수록 리소스, 네트워크 트래픽, 처리 시간 및 저장소가 더 많이 필요합니다. 보고서에서 발생한 문제를 분석하여 필요한 데이터의 양을 확인한 다음 보고서 데이터 원본에서 해당 데이터만 검색하십시오.
보고서에서 필요한 것보다 많은 데이터가 검색되는 경우
필터, 정렬 및 집계는 보고서 처리 중에 사용하는 것보다 데이터 원본에서 사용하는 것이 더 효율적입니다. 보고서에 표시하려는 수준까지만 정보를 반환하도록 쿼리를 작성하십시오. 다음 목록에서는 보고서에서 각 보고서 쿼리를 평가하는 방법을 제안합니다.
WHERE 절 또는 HAVING 절을 사용하여 사용자가 보고서에서 확인해야 하는 데이터만 반환하는 쿼리를 작성합니다. 쿼리 매개 변수를 사용하여 런타임에 검색되는 데이터를 제한합니다. 쿼리 매개 변수는 해당하는 보고서 매개 변수에 자동으로 바인딩되고 사용자가 원하는 데이터를 지정할 수 있게 해 줍니다. 자세한 내용은 WHERE 및 HAVING을 사용하여 행 필터링을 참조하십시오.
데이터를 필터링하는 보고서 매개 변수가 포함된 스냅숏 보고서를 만들 때는 보고서에 표시할 수 있는 모든 데이터를 스냅숏에 저장해야 합니다. 이 경우에는 데이터 집합 쿼리에서 쿼리 매개 변수를 사용하지 마십시오. 대신 사용자가 원하는 보고서 데이터를 지정할 수 있도록 필터 식에서 사용할 수 있는 보고서 매개 변수를 수동으로 만드십시오.
ORDER BY 절을 사용하여 보고서에서 검색되는 데이터를 미리 정렬하는 쿼리를 작성합니다. 보고서에서 정렬하려는 순서대로 데이터를 정렬합니다. 데이터를 미리 정렬하면 해당 순서대로 데이터가 메모리에 저장되기 때문에 보고서 처리 시간이 단축됩니다. 데이터를 처리하기 전에 미리 정렬해야 하는 보고서 처리 태스크는 많지 않습니다. 예를 들어 SUM은 순서가 중요하지 않습니다. 그룹 인스턴스 내의 데이터는 자동으로 정렬되지 않습니다. 보고서의 데이터를 정렬하지 않아도 되는 경우에는 데이터 집합 또는 데이터 영역에 정렬 식을 설정하지 마십시오. 자세한 내용은 ORDER BY 절(Transact-SQL) 및 보고서에서 데이터 정렬을 참조하십시오.
그룹 정렬 또는 집계 값 기준 정렬은 쿼리보다 보고서에서 수행하는 것이 훨씬 더 간단하며 더 효율적인 경우가 많습니다.
GROUP BY를 사용하여 데이터 원본의 값을 집계하는 쿼리를 작성합니다.
대부분의 경우 정보를 전달하는 가장 효율적인 방법은 값을 집계하고 요약 정보를 표시하는 것입니다. 데이터 원본에서 집계 수준을 계산하고 데이터 집합에서 이를 검색할 수 있습니다. 데이터 집합의 자세히 데이터는 데이터 원본에서 계산된 집계를 나타냅니다. 자세한 내용은 쿼리 결과 요약(Visual Database Tools)을 참조하십시오.
이렇게 미리 집계된 값이 보고서에 있으면 SUM과 같이 전이적인 집계 함수를 사용하여 값을 집계할 수 있습니다. 예를 들어 1, 2, 3, 4, 5, 6이라는 6개의 1, 2, 3, 4, 5, 6. 값을 두 개씩 그룹화하면 3, 7, 11이라는 3개의 값이 됩니다. 6개 값의 합계를 계산하거나(21) 3개 값의 합계를 계산하거나(21) 그 결과는 동일합니다. 그러나 AVG 함수를 사용하여 평균을 계산하면 두 경우의 결과가 달라집니다. 앞의 경우는 평균이 21/6 즉, 3.5가 되고 두 번째 경우는 21/3 즉, 7이 됩니다. AVG는 전이적 함수가 아닙니다.
차트 또는 계기에 필요한 데이터의 양을 고려하십시오. 모니터에서 픽셀 몇 개에 수백 개의 점을 그리면 성능이 저하되고 그래픽의 시각적인 표시 효과도 향상되지 않습니다. 원형 차트당 조각 개수는 7~8개 이하로 줄이는 것이 좋습니다. 자세한 내용은 차트 데이터 영역에 표시하기 위한 데이터 준비를 참조하십시오.
보고서 처리기는 조건부 표시 유형이 적용된 보고서 항목이 처음에 데이터의 최상위 수준만 표시되더라도 이러한 보고서 항목에 그룹화 식, 정렬 식 및 필터링 식을 적용해야 합니다. SQL Server 2008 Reporting Services의 요청 시 처리 기능은 표시되는 데이터만 처리하여 데이터 평가를 최적화할 수 있지만 모든 가능한 데이터도 보고서에 포함됩니다. 세부 데이터를 거의 보지 않는 경우에는 드릴스루 보고서가 더 효과적입니다. 자세한 내용은 보고서 유형을 참조하십시오.
보고서의 실행 스냅숏 생성을 고려하십시오. 보고서 스냅숏에는 보고서 정의의 데이터 집합에 대해 검색된 모든 보고서 데이터가 포함됩니다. 자세한 내용은 보고서 기록에서 스냅숏 만들기, 수정 및 삭제를 참조하십시오.
쿼리 제한 시간
쿼리 제한 시간 값은 보고서를 작성하는 동안 데이터 집합을 정의할 때 지정됩니다. 제한 시간 값은 쿼리의 Timeout 요소에 보고서와 함께 저장됩니다. 기본적으로 이 값은 30초로 설정됩니다. 자세한 내용은 보고서 처리에 대한 제한 시간 값 설정을 참조하십시오.
데이터 집합 쿼리에 대한 제한 시간 값을 설정하려면 방법: 데이터 집합 만들기(Reporting Services)를 참조하십시오.
대량 네트워크 트래픽으로 사용자의 대기 시간 발생
네트워크 트래픽으로 전달되는 데이터 양이 많을 경우 사용자의 대기 시간이 발생할 수 있습니다. 예상되는 사용자 기반 및 예상되는 보고서 보기 볼륨에 따라 적절하게 보고서 서버 구성 요소의 배포 방식을 선택할 수 있습니다. 자세한 내용은 배포 토폴로지 계획을 참조하십시오.
예를 들어 다음과 같은 전략으로 사용자의 대기 시간을 줄일 수 있습니다.
보고서 서버와 동일한 컴퓨터에 보고서 서버 카탈로그를 보관합니다.
보고서 서버 데이터베이스인 tempdb에서는 보고서 정의의 각 데이터 집합 쿼리에서 검색한 보고서 데이터를 관리합니다. 보고서 데이터를 보고서 처리기와 함께 보관하면 보고서 실행 속도를 저하시키는 네트워크 트래픽을 줄일 수 있습니다.
데이터 웨어하우스 데이터 원본의 경우 보고서 서버와 다른 별도의 서버에 데이터 웨어하우스를 보관합니다.
네트워크에서 데이터를 검색하려면 보고서 실행 시 태스크를 하나 더 추가하면 되지만 Reporting Services와 데이터 웨어하우스가 동일 서버의 메모리를 사용하기 위해 경합하면 성능이 저하될 수 있습니다.
보고서 처리 시간이 너무 오래 걸리는 경우
보고서 처리는 보고서 데이터 집합에서 데이터를 검색한 후 보고서 처리기가 보고서 레이아웃 및 데이터를 조합하여 이후에 보고서 렌더러로 전달되는 중간 보고서 형식을 만들 때 발생합니다. 일반적으로 보고서 처리기는 사용자에게 표시되는 현재 페이지의 데이터 및 레이아웃만 조합합니다. 보고서 처리 시간은 보고서 영역에서 인스턴스 개수가 많은 보고서 레이아웃, 페이지 나누기 및 복잡한 식 등의 영향을 받을 수 있습니다.
이 섹션에서는 보고서 처리 성능을 개선하는 방법에 대해 설명합니다.
페이지 머리글 또는 바닥글의 식으로 모든 페이지를 강제로 처리
기본 제공 필드 [&TotalPages]에 대한 참조를 포함하는 경우 보고서 처리기는 첫 번째 페이지를 렌더링하기 전에 전체 보고서에 페이지를 매겨야 합니다. [&TotalPages]에 대한 참조가 없는 경우 첫 번째 페이지를 렌더링한 후 나머지 페이지를 처리하지 않고도 이를 사용자에게 즉시 반환할 수 있습니다. 또한 보고서 처리기는 페이지 머리글 또는 바닥글에 있는 복잡한 식에 [&TotalPages]에 대한 직접 또는 간접 참조가 포함되어 있는 것으로 가정합니다.
보고서 처리기가 긴 보고서에 페이지를 매기지 않도록 하려면 페이지 머리글 및 페이지 바닥글에 [&TotalPages]에 대한 참조 또는 복잡한 식을 포함하지 마십시오.
페이지 나누기가 없는 보고서
사용자가 보고서 페이지를 이동할 때 보고서 처리기는 각 보고서 페이지의 데이터와 보고서 레이아웃 정보를 조합하고 해당 페이지를 보고서 렌더러에 전달합니다. 페이지 나누기가 없는 보고서의 경우에는 사용자가 첫 번째 페이지를 보기 전에 전체 보고서가 처리되어야 합니다.
HTML 뷰어와 같은 소프트 페이지 나누기 렌더러는 페이지 나누기를 자동으로 처리합니다. 보고서 속성 InteractiveHeight를 0으로 설정하면 이러한 자동 동작을 재정의하고 보고서를 1페이지로 된 보고서로 설정할 수 있습니다. 하드 페이지 나누기 렌더러의 경우 페이지 나누기를 수동으로 추가해야 합니다. 렌더러 유형에 대한 자세한 내용은 렌더링 동작 이해를 참조하십시오.
InteractiveHeight가 0이 아니고 적절한 페이지 크기로 설정되어 있는지(예: 8.5 in) 확인하십시오. 보고서를 여러 페이지로 구성할 수 있도록 보고서 항목 또는 테이블릭스 그룹에 페이지 나누기를 추가하십시오. 이렇게 하면 각 페이지에서 처리해야 하는 데이터 양을 줄일 수 있습니다. 자세한 내용은 방법: 페이지 나누기 추가(Reporting Services)를 참조하십시오.
복잡한 테이블릭스 데이터 영역 그룹화 및 집계 함수
테이블릭스 데이터 영역에 있는 여러 수준의 중첩 그룹 및 인접 그룹은 보고서 처리 성능에 영향을 줄 수 있습니다. 그룹화 수준, 그룹 인스턴스 수 및 그룹, 필터, 정렬 식이 적용된 후 평가가 필요한 집계 함수의 사용을 고려하십시오. 예를 들어 Previous는 데이터 영역의 정렬된 요소에 따라 값이 달라지므로 '비용이 많이 드는' 집계 함수이지만 Sum은 순서가 중요하지 않으므로 필요한 리소스가 적습니다. 정렬이 필요한 다른 집계 함수로는 First 및 Last가 있습니다. 자세한 내용은 식에서 기본 제공 보고서 및 집계 함수 사용(Reporting Services)을 참조하십시오.
보고서의 보고서 디자인을 평가하고 일부 데이터 집계가 데이터 원본에서 발생할 수 있는지를 고려하십시오. 집계 함수 호출을 변경하지 않고 보고서에서 사용되는 데이터 양을 줄이는 것만으로도 충분히 적정 수준의 성능을 제공할 수 있습니다.
테이블릭스 데이터 영역에 포함된 보고서의 인스턴스가 많으면 보고서 성능이 느려지는 경우
포함된 보고서를 사용하는 데 따른 장점과 단점을 이해해야 합니다. 각 포함된 보고서 인스턴스는 별개의 쿼리 실행 태스크와 별개의 보고서 처리 태스크를 나타냅니다.
포함된 보고서 인스턴스가 몇 개 안 될 경우에는 포함된 보고서를 사용하십시오.
그룹 인스턴스가 많을 때는 그룹 내에 포함된 보고서를 사용하지 마십시오. 예를 들어 각 고객에 대한 판매 및 반품 목록을 모두 표시하려면 드릴스루 보고서를 사용하는 것이 좋습니다. 고객을 판매 및 반품 정보와 조인한 다음 고객 ID를 기준으로 이를 그룹화하는 쿼리를 작성할 수 있는지 여부를 고려하십시오.
포함된 보고서에서 주 보고서와 다른 데이터 원본을 사용하는 경우에는 포함된 보고서를 사용하십시오. 하지만 성능이 문제가 될 경우에는 다음과 같은 완화 전략 중 하나를 사용하여 주 보고서의 데이터 집합 쿼리를 변경하는 것이 좋습니다.
데이터 웨어하우스에서 데이터를 수집하고 데이터 웨어하우스를 단일 데이터 집합에 대한 데이터 원본으로 사용합니다.
SQL Server의 연결된 서버를 사용하고 여러 데이터베이스에서 데이터를 검색하는 쿼리를 작성합니다.
OPEN ROWSET 기능을 사용하여 여러 데이터베이스를 지정합니다.
보고서 서버에서 동일한 메모리를 사용하기 위해 프로세스가 경합하는 경우
보고서 서버에서 동일한 메모리 리소스를 사용하기 위해 여러 응용 프로그램이 경합하는 경우 보고서 처리에 영향을 줄 수 있습니다.
시스템 관리자에게 문의하여 메모리 관리 구성이 보고서 서버를 사용하는 데 올바른 모델인지 확인하십시오. 자세한 내용은 보고서 서버 응용 프로그램을 위한 사용 가능한 메모리 구성을 참조하십시오.
보고서 실행 제한 시간
큰 보고서를 실행하려면 보고서 실행 제한 시간과 ASP.NET 제한 시간이라는 두 가지 제한 시간을 조정해야 합니다.
보고서 실행 제한 시간 값은 보고서 서버에 지정되어 있습니다. 자세한 내용은 보고서 처리에 대한 제한 시간 값 설정을 참조하십시오.
ASP.NET 제한 시간 정책은 보고서 서버 구성 파일에 의해 제어됩니다. 이 파일의 기본 위치는 <drive>:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\web.config입니다. 요청을 실행할 수 있는 최대 시간(초)을 설정하려면 이 파일에 httpRuntime 요소를 추가합니다.
<configuration>
. . .
<system.web.
. . .
<httpRuntime executionTimeout="90"/>
. . .
</system.web.
. . .
</configuration>
보고서 크기에 따라 이 값을 몇 시간으로 늘려야 할 수도 있습니다.
보고서 렌더링 시간이 너무 오래 걸리는 경우
보고서 렌더링은 데이터와 레이아웃이 중간 형식으로 조합된 다음 렌더링 확장 프로그램으로 전달된 후에 발생합니다. 렌더링 시간은 데이터 양, 보고서 항목의 인스턴스 수 및 페이지 나누기에 의해 영향을 받을 수 있습니다. 보고서를 내보낼 때는 중간 형식을 특정 렌더러로 전달합니다. 사용자에게 보고서가 어떤 형식으로 표시되는지 알고 있는 경우 해당 렌더러에 맞게 보고서를 최적화해야 합니다. 자세한 내용은 보고서 내보내기 및 렌더링 동작 이해를 참조하십시오.
이 섹션에서는 보고서의 렌더링 성능을 개선하는 방법에 대해 설명합니다.
선택한 렌더링 형식에 맞게 보고서가 최적화되지 않는 경우
렌더러에 따라 일부 기능이 지원되지 않을 수 있습니다. 보고서를 표시하는 데 사용되는 기본 형식이 특정 파일 형식인 경우 사용자의 보고서 표시 환경을 최적화기 위해 보고서 디자인을 수정해야 할 수 있습니다.
필요한 경우 페이지 나누기를 추가합니다. 예를 들어 Excel에서 각 페이지 나누기는 새 시트를 정의합니다. 각 시트는 최대 65000개의 행을 포함할 수 있습니다. 보고서에서 페이지 나누기를 설정할 때는 이러한 제한을 고려하십시오.
Excel로 내보낼 경우 테이블릭스 데이터 영역에서 셀을 병합하지 마십시오. 자유 형식 보고서에서는 보고서 항목을 세로로 맞추십시오. 병합된 셀과 정렬되지 않은 보고서 항목은 내보낸 보고서에서 Excel 기능을 방해합니다.
HTML 파서는 큰 HTML 페이지를 렌더링하는 데 효율적이지 않습니다. 보고서 렌더링에 문제가 있으면 작은 파일을 만드는 형식(예: CSV)을 선택하십시오. 보고서 도구 모음을 사용할 수 없어 다른 형식을 선택할 수 없으면 렌더링 형식을 설정하는 구독을 정의하고 파일 공유에 정적 문서로 보고서를 배달할 수 있습니다. 자세한 내용은 Reporting Services의 파일 공유 배달을 참조하십시오.
보고서 처리를 최적화하기 위한 디자인 팁
보고서 성능이 가장 중요한 경우 다음 정보에 따라 보고서를 처리하는 데 필요한 시간을 최적화할 수 있습니다.
입력란의 인스턴스가 많은 보고서의 경우 입력란의 CanGrow 및 CanShrink를 FALSE로 설정합니다. 기본적으로 테이블릭스 데이터 영역의 각 셀에는 입력란이 포함되므로 렌더링해야 하는 전체 입력란의 수가 빠르게 증가할 수 있습니다.
이미지가 많은 보고서의 경우 이미지의 AutoSize를 Fit와 같은 다른 값으로 설정합니다.
입력란의 경우 TextAlign 속성을 General로 설정하지 마십시오. 이 값을 사용하는 경우에는 입력란 내용에 따라 조건부 처리를 수행해야 합니다.
필요하지 않은 경우에는 가로 페이지 나누기를 사용하지 마십시오. 보고서의 여백, 열 너비 및 공백을 검토하십시오. 예를 들어 보고서를 .TIFF 파일로 렌더링하고 Microsoft Windows 사진 및 팩스 뷰어를 통해 추가 페이지를 렌더링해야 하는지 확인하십시오.
테이블릭스 데이터 영역에 대한 특정 렌더링 동작을 제어해야 하는 경우에만 테이블릭스 멤버에 KeepTogether 속성을 설정합니다. KeepTogether 기능을 사용하는 경우에는 페이지 나누기를 계산할 때 추가 처리가 필요합니다.