보고서 성능 문제 해결
새 설치: 2008년 11월 17일
이 항목에서는 보고서 성능을 높일 수 있는 여러 가지 방법에 대해 설명합니다.
보고서 성능 문제를 해결하려면 Reporting Services 로그 파일을 사용하여 데이터 검색, 보고서 레이아웃 처리 또는 보고서 렌더링 중 어느 과정에 대부분의 시간이 소요되는지 확인합니다. 자세한 내용은 보고서 문제 해결을 참조하십시오.
대부분의 시간이 소요되는 작업을 확인한 후에는 다음 섹션을 통해 구체적인 문제를 해결할 수 있습니다.
데이터 검색 성능 향상
보고서 처리 성능 향상
보고서 렌더링 성능 향상
데이터 검색 성능 향상
보고서 데이터 양이 많을수록 더 많은 리소스와 저장소를 사용하고 더 많은 네트워크 트래픽이 발생하며 필요한 처리 시간이 길어집니다. 적절한 양의 데이터를 포함하고 너무 복잡하지 않은 보고서를 디자인하면 보고서 성능을 제어하는 데 도움이 됩니다. 예를 들어 1000페이지짜리 보고서를 보고자하는 사용자는 그리 많지 않습니다. 테이블이 너무 많이 중첩되어 있으면 드릴다운 보고서의 컨텍스트를 유지하기 어렵고 테이블에 열이 너무 많으면 테이블을 검색하기 어렵습니다. 수백 개의 조각으로 된 원형 차트는 보기에 복잡할 뿐만 아니라 읽기도 어렵습니다. 보고서의 요구 사항을 신중하게 분석하여 필요한 데이터의 양을 결정한 후 보고서 데이터 원본에서 해당 데이터만 검색해야 합니다.
다음 섹션의 정보를 참조하면 보고서의 데이터를 검색하는 데 소요되는 시간을 줄일 수 있습니다.
필요 이상의 데이터 검색
데이터 양이 많은 경우 데이터 처리 과정에서보다는 데이터 원본에서 데이터를 필터링하고 정렬하고 집계하는 것이 더 효율적입니다. 보고서에 표시할 데이터만 반환하도록 쿼리를 작성합니다. 요약 데이터만 표시할 계획이면 데이터 원본에서 집계를 계산하고 세부 데이터는 검색하지 마십시오. 다음 목록에는 보고서의 각 보고서 쿼리를 평가하는 방법을 제시합니다.
- 보고서에 표시할 내용으로만 데이터를 제한하는 WHERE 절이나 HAVING 절을 사용하여 쿼리를 작성합니다. 런타임에 검색되는 데이터를 제한하는 쿼리 매개 변수를 사용합니다. 자세한 내용은 WHERE 및 HAVING을 사용하여 행 필터링을 참조하십시오.
데이터를 필터링하는 보고서 매개 변수가 포함된 스냅숏 보고서를 작성할 경우에는 보고서에 표시될 수 있는 모든 데이터를 스냅숏에 저장해야 합니다. 이 경우에는 데이터 집합 쿼리에 쿼리 매개 변수를 사용하는 대신 원하는 보고서 데이터를 사용자가 지정할 수 있도록 필터 식에 사용할 보고서 매개 변수를 직접 만드십시오. - ORDER BY 절을 사용하는 쿼리를 작성하여 보고서용으로 검색되는 데이터를 미리 정렬합니다. 이때 보고서에서 정렬할 순서대로 데이터를 정렬합니다. 데이터를 미리 정렬하면 데이터가 메모리에 저장된 방식 때문에 보고서 처리 시간이 줄어듭니다. 대부분의 보고서 처리 작업에서는 데이터를 처리하기 전에 정렬하지 않아도 됩니다. 예를 들어 SUM은 정렬 순서에 영향을 받지 않습니다. 그룹 인스턴스 내의 데이터는 자동 정렬되지 않습니다. 정렬된 데이터가 보고서에 필요하지 않은 경우에는 데이터 집합이나 데이터 영역에 정렬 식을 설정하지 마십시오. 자세한 내용은 ORDER BY 절(Transact-SQL) 및 보고서에서 데이터 정렬을 참조하십시오.
그룹을 정렬하거나 집계 값을 기준으로 정렬하는 작업은 쿼리에서 수행하는 것보다 보고서에서 수행하는 것이 더 간단합니다. 쿼리에서 그룹을 정렬하는 것보다 보고서에서 그룹을 정렬하는 것이 더 효율적인 경우가 많습니다. - GROUP BY를 사용하는 쿼리를 작성하여 데이터 원본에서 값을 집계합니다.
대부분의 경우에는 값을 집계하고 요약 정보를 표시하는 것이 가장 효과적인 정보 전달 방법입니다. 데이터 원본에서 일정 수준의 집계를 계산한 후 데이터 집합에서 이를 검색할 수 있습니다. 그러면 데이터 원본에서 계산된 집계가 데이터 집합의 "세부" 데이터로 표시됩니다. 쿼리에서 집계하는 방법에 대한 자세한 내용은 쿼리 결과 요약(Visual Database Tools)을 참조하십시오.
이와 같이 미리 집계된 값이 보고서에 있는 경우 SUM과 같이 수학적으로 전이적인 집계 함수를 사용하면 값을 계속해서 집계할 수 있습니다. 예를 들어 1, 2, 3, 4, 5, 6이라는 6개의 값으로 된 집합이 있다고 가정해 보겠습니다. 값을 두 개씩 묶으면 3, 7, 11이라는 3개의 값으로 된 집합이 만들어집니다. 이 경우 첫 번째 집합과 두 번째 집합의 합계를 구할 수 있으며 이 두 집합의 합은 그룹화 여부에 관계없이 모두 21로 같습니다. AVG 함수를 사용하여 두 집합의 값에 대한 평균을 구하는 경우에는 각 집합의 결과가 다르게 나타납니다. 값이 6개로 이루어진 집합의 평균은 21/6, 즉 3.5이고, 값이 3개로 이루어진 집합의 평균은 21/3, 즉 7입니다. AVG는 전이 함수가 아닙니다. - 데이터 원본에서 쿼리 성능을 분석 및 최적화하는 것이 좋습니다. SQL Server 2005 쿼리 최적화 프로그램에 대한 자세한 내용은 쿼리 성능 및 단일 SQL 문 처리를 참조하십시오.
- 차트에 필요한 데이터의 양을 고려합니다. 꺾은선형 차트의 경우 모니터의 몇 개 픽셀에 수백 개의 점을 그리면 성능이 떨어지고 그래픽의 시각적 표시 수준도 좋지 않게 됩니다. 원형 차트의 경우에는 조각을 7-8개보다 많이 사용하지 않는 것이 좋습니다.
- 조건부로 표시되는 보고서 항목이 있으면 처음에 최상위 데이터만 표시되더라도 보고서 처리기에서는 그룹, 정렬 및 필터링 식을 적용해야 합니다. 따라서 사용자가 세부 데이터를 가끔만 보는 경우에는 드릴스루 보고서를 사용하는 것이 더 낫습니다. 드릴스루 보고서는 사용자가 주 보고서의 드릴스루 링크를 클릭하기 전에는 실행되지 않습니다. 드릴다운 보고서 또는 포함된 보고서에서는 데이터가 처음에 숨김 상태인 경우에도 모든 데이터가 처리됩니다. 자세한 내용은 보고서에 링크 추가를 참조하십시오.
- 보고서 실행 스냅숏을 작성할 수도 있습니다. 보고서 스냅숏에는 보고서 정의에서 데이터 집합을 위해 검색된 모든 보고서 데이터가 포함됩니다. 자세한 내용은 보고서 스냅숏을 참조하십시오.
많은 양의 네트워크 트래픽으로 인한 대기 시간 증가
많은 양의 데이터를 전달하여 네트워크 트래픽이 증가하면 사용자의 대기 시간이 길어질 수 있습니다. 예상되는 사용자 수와 예상되는 보고서 보기의 양을 알고 있으면 보고서 서버 구성 요소를 배포할 적절한 방식을 선택할 수 있습니다.
사용자의 대기 시간을 줄이려면 다음과 같은 전략을 고려해 보십시오.
- 보고서 서버 데이터베이스와 보고서 서버를 같은 컴퓨터에 둡니다.
보고서 서버 데이터베이스 tempdb는 각 데이터 집합 쿼리를 통해 검색되는 보고서 데이터를 관리합니다. tempdb를 보고서 서버에 유지하면 보고서 실행 속도에 영향을 주는 네트워크 트래픽을 줄일 수 있습니다. - 데이터 웨어하우스 데이터 원본의 경우 데이터 웨어하우스를 보고서 서버 이외의 서버에 둡니다.
네트워크에서 데이터를 검색하면 보고서를 실행하는 데 추가적인 작업이 필요하지만 데이터 웨어하우스와 Reporting Services를 같은 서버에 두면 서로 메모리를 사용하기 위해 경쟁하므로 성능이 저하될 수 있습니다.
자세한 내용은 Reporting Services 배포 계획을 참조하십시오.
쿼리 제한 시간
데이터를 검색하기 전에 데이터 집합 쿼리의 제한 시간이 초과될 경우 보고서에 제한 시간 값을 지정할 수 있습니다. 기본적으로 이 값은 30초로 설정되어 있습니다. 데이터 집합 쿼리의 제한 시간 값을 설정하려면 방법: 데이터 집합 만들기(보고서 디자이너)를 참조하십시오. 자세한 내용은 보고서 실행에 대한 제한 시간 값 설정을 참조하십시오.
보고서 처리 성능 향상
보고서 처리는 보고서 데이터 집합 및 보고서 매개 변수의 데이터가 검색된 후에 실행됩니다. 보고서 처리기는 보고서 레이아웃과 데이터를 결합하여 중간 보고서 형식을 만들고, 이 중간 보고서 형식은 보고서 렌더러에 전달됩니다. 보고서 처리 시간은 보고서 레이아웃, 페이징 및 인스턴스가 많은 보고서 항목의 복잡한 식에 따라 달라질 수 있습니다. 이 섹션을 참조하면 보고서 처리 성능을 향상시키는 데 도움이 됩니다.
적절한 데이터 영역 선택
가능하면 테이블 데이터 영역 및 목록 데이터 영역을 사용합니다. 행렬을 처리하는 것보다 테이블이나 목록을 처리하는 것이 더 효율적입니다. 테이블 및 목록 데이터 영역에서는 행에 대해서만 동적 요소가 지원되는 반면 행렬 레이아웃에서는 행과 열 모두에 대해 동적 요소가 지원되기 때문에 레이아웃 구조가 더 복잡해집니다.
실제 페이지 렌더러의 경우 페이지 머리글이나 바닥글에 전체 페이지 수 사용 안 함
PDF 또는 이미지와 같이 실제 페이지의 번호를 매기는 레이아웃 렌더링 확장 프로그램을 사용하여 보고서를 렌더링할 경우 전역 필드 TotalPages에 대한 참조가 있으면 보고서 처리 성능에 영향을 줄 수 있습니다. 렌더러에 대한 자세한 내용은 보고서 렌더링 시 디자인 고려 사항을 참조하십시오.
복잡한 데이터 영역 그룹화 및 집계 함수 사용
테이블이나 행렬 데이터 영역의 그룹이 너무 많이 중첩되어 있으면 보고서 처리 성능에 영향을 줄 수 있습니다. 그룹화 수준과 그룹 인스턴스의 수뿐만 아니라 그룹, 필터링 및 정렬 식을 적용한 후 평가해야 하는 집계 함수의 사용을 모두 고려해야 합니다.
정렬 후 집계는 사용하지 마십시오. 정렬 후 집계는 정렬 순서에 따라 달라지며 여기에는 Previous, First, Last 및 RunningValue 함수가 포함됩니다. 식에 이러한 함수 중 하나 이상을 포함하면 보고서 처리기에서 함수를 적용하기 전에 대상 데이터를 정렬해야 합니다. 다중 중첩 그룹 또는 인접 그룹과 같이 그룹 정의가 복잡한 행렬 레이아웃에서는 가능하면 식에 정렬 후 집계를 포함하지 않는 것이 좋습니다.
보고서 디자인을 평가하여 일부 데이터 집계를 데이터 원본에서 실행할 수 있는지 확인합니다. 집계 함수 호출을 변경할 필요 없이 보고서의 데이터 양을 줄이는 것만으로도 적정 수준의 성능을 유지할 수 있습니다.
집계 함수에 대한 자세한 내용은 식에 보고서 함수 사용(Reporting Services)을 참조하십시오.
식에 불필요한 재귀 지정
관리자와 직원을 표시하는 조직 보고서와 같이 재귀 계층을 정의하는 경우에만 그룹에 대해 부모 식을 지정합니다. Parent 속성은 재귀 데이터에만 적용됩니다. 중첩 그룹의 부모-자식 관계에는 Parent 속성이 적용되지 않습니다.
여러 행이 포함된 데이터 영역에서 포함된 보고서 사용
포함된 보고서를 사용할 경우의 장점과 단점을 이해합니다. 각 포함된 보고서 인스턴스는 별도의 쿼리 실행 및 보고서 처리 작업입니다.
- 포함된 보고서 인스턴스 수가 적은 경우에만 포함된 보고서를 데이터 영역에 사용합니다.
- 포함된 보고서 인스턴스가 여러 개인 경우에는 포함된 보고서를 데이터 영역 그룹에 사용하지 않습니다. 예를 들어 각 고객에 대해 판매 및 수익 목록을 표시하려면 드릴스루 보고서를 사용하는 것이 좋습니다. 고객 데이터를 판매 및 수익 데이터와 조인하는 쿼리를 작성한 후 고객 ID로 그룹화할 수 있는지 여부를 고려하십시오.
- 주 보고서와 다른 데이터 원본을 사용하는 포함된 보고서는 사용하지 않습니다. 성능이 문제가 되는 경우에는 다음과 같은 방법 중 하나를 사용하여 주 보고서에서 데이터 집합 쿼리를 변경하십시오.
- 데이터 웨어하우스의 데이터를 수집하고 데이터 웨어하우스를 단일 데이터 집합의 데이터 원본으로 사용합니다.
- SQL Server 연결된 서버를 사용하고 여러 데이터베이스에서 데이터를 검색하는 쿼리를 작성합니다.
- OPEN ROWSET 기능을 사용하여 여러 데이터베이스를 지정합니다.
대화형 정렬 사용
사용자가 보고서에서 데이터 정렬 순서를 직접 변경할 수 있어야 하는 경우를 제외하고는 대화형 정렬 단추를 사용하지 않습니다.
이미지 사용
이미지에 필요한 리소스 요구 사항을 이해합니다.
- 배경 이미지를 포함하여 큰 이미지는 사용하지 않습니다. 큰 이미지를 사용하면 메모리, 처리 및 렌더링 리소스가 필요하며 이러한 이미지가 PDF, 인쇄 또는 문서 이미지와 같은 하드 카피 렌더러에 렌더링되는 경우에는 특히 그렇습니다.
- 데이터베이스나 서버에서 KPI(핵심 성과 지표)와 같은 작은 이미지의 인스턴스를 여러 개 가져오지 않습니다. 이러한 이미지는 포함 이미지로 보고서에 삽입하는 것이 좋습니다.
- 이미지가 여러 개 포함된 보고서의 경우 이미지에 대해 AutoSize를 Fit과 같은 다른 값으로 설정합니다.
보고서 서버에서 동일한 메모리를 사용하기 위해 경쟁하는 프로세스
보고서 서버에서 동일한 메모리 리소스를 사용하기 위해 경쟁하는 응용 프로그램이 여러 개 있으면 보고서 처리에 영향을 줄 수 있습니다.
시스템 관리자에게 문의하여 메모리 관리 모델이 현재의 보고서 서버 용도에 적합하게 구성되었는지 확인합니다. 자세한 내용은 Reporting Services를 위한 사용 가능한 메모리 구성을 참조하십시오.
보고서 실행 제한 시간
큰 보고서를 실행하려면 보고서 실행 제한 시간과 ASP.NET 제한 시간이라는 두 가지 제한 시간을 조정해야 합니다.
보고서 실행 제한 시간 값은 보고서 서버에서 지정합니다. 자세한 내용은 보고서 실행에 대한 제한 시간 값 설정을 참조하십시오.
ASP.NET 제한 시간 정책은 보고서 서버 구성 파일을 통해 제어합니다. 이 파일의 기본 위치는 <drive>:\Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportServer\web.config입니다. 요청을 실행할 수 있는 최대 시간(초)을 설정하려면 초 단위의 제한 시간 값을 httpRuntime 요소에 설정합니다. 다음 XML 조각은 구성 파일에서 이 요소를 추가할 위치를 보여 줍니다.
<configuration>
. . .
<system.web>
. . .
<httpRuntime executionTimeout="90"/>
. . .
</system.web>
. . .
</configuration>
장시간 실행되는 쿼리나 복잡한 보고서의 경우에는 몇 시간을 나타내는 값을 지정해야 할 수 있습니다.
보고서 렌더링 성능 향상
보고서 렌더링은 데이터와 레이아웃이 결합되어 렌더링 확장 프로그램에 전달된 이후에 수행됩니다. 렌더링 시간은 데이터의 양, 보고서 항목 인스턴스의 수 및 페이지 크기에 따라 달라집니다. 한 페이지에 표시할 수 있는 데이터의 양은 보고서 렌더러에서 결정합니다. 페이지에 대한 정의는 렌더러마다 다릅니다. Excel 렌더러의 경우 페이지는 워크시트이고, 보고서를 출력할 수 있는 PDF 렌더러의 경우 페이지는 실제 페이지입니다. HTML 뷰어의 경우에는 보고서 전체가 한 페이지일 수 있습니다. 인쇄된 페이지의 보고서 디자인은 온라인에서 보기 위한 보고서의 디자인과 다를 수 있습니다. 대상 사용자가 보고서를 특정 형식으로 볼 것으로 예상되는 경우에는 해당 형식으로 보고서를 디자인합니다. 자세한 내용은 보고서 렌더링 시 디자인 고려 사항을 참조하십시오.
다음 표에서는 보고서 렌더링 성능을 향상시키는 데 도움이 되는 여러 가지 방법을 제시합니다.
렌더링 형식 | 설명 |
---|---|
모두 |
|
Excel |
|
HTML |
|
이미지 TIFF 인쇄 |
|
특정 형식으로 보고서를 렌더링하는 데 문제가 있으면 CSV와 같이 더 작은 파일을 생성하는 형식을 선택하십시오. 게시된 보고서의 경우 렌더링 형식을 URL에 지정할 수 있습니다. 자세한 내용은 Specifying a Rendering Format in a URL을 참조하십시오.
보고서 도구 모음을 사용할 수 없어서 다른 형식을 선택할 수 없으면 렌더링 형식을 설정하는 구독을 정의하고 파일 공유에 정적 문서로 보고서를 배달할 수 있습니다. 자세한 내용은 Reporting Services의 파일 공유 배달을 참조하십시오.
참고 항목
개념
Reporting Services 로그 파일
큰 보고서 처리
관련 자료
Reporting Services 문제 해결
Reporting Services 오류 및 이벤트
보고서 문제 해결