Financial Reporting 보고서 성능 이슈 진단

잘못 디자인된 Financial Reporting 보고서는 여러 개의 MDX(Multidimensional Expression) 요청 또는 Oracle Essbase 쿼리를 생성하여 상당한 Oracle Enterprise Performance Management Cloud 리소스를 사용할 수 있습니다. 동시 사용자가 해당 보고서에 액세스하면 과도한 리소스 사용으로 인해 성능이 저하됩니다.

보고서에 여러 개의 세그먼트가 있는 경우 다수의 MDX 요청이 생성되는 주된 이유가 됩니다. 이 섹션에서는 세그먼트 수를 줄여 Financial Reporting 보고서의 효율성을 개선하는 방법을 설명합니다.

보고서 디자인 변경: 사용 사례

원본 보고서

다음 그림은 원본 보고서 디자인을 보여 줍니다.
원본 보고서 디자인 예

이 보고서 그림은 다음 디자인 요소를 보여 줍니다.

각 엔티티 멤버 100, 200, 403 및 500에 대해 여러 개의 행이 있습니다.
각 엔티티 멤버의 계정마다 8개의 행이 있습니다.

다음 테이블은 원본 보고서 디자인과 최적화된 디자인을 개괄적으로 보여 줍니다.

원본 보고서 디자인 최적화된 디자인

원본 보고서 디자인	최적화된 디자인
각 `엔티티` 멤버에 대해 여러 개의 행이 있습니다. `100` `200` `300` `400`	`엔티티` 멤버를 하나의 세그먼트로 결합합니다. `100, 200, 403, 500`
각 `엔티티` 멤버의 계정마다 8개의 행이 있습니다. 멤버 100의 예는 다음과 같습니다. `100 = Children of 1100` `100 = 1100` `100= Children of 1200` `100=1200` `100 = Children of 1300` `100 = 1300 100 =Children of 1400` `100 = 1400`	모든 멤버의 모든 세그먼트를 하나의 세그먼트로 결합합니다. `Entity members 100,200,403,500=Children of 11`

각 엔티티 멤버에 대해 여러 개의 행이 있습니다.

100

200

300

400

엔티티 멤버를 하나의 세그먼트로 결합합니다.

100, 200, 403, 500

각 엔티티 멤버의 계정마다 8개의 행이 있습니다. 멤버 100의 예는 다음과 같습니다.

100 = Children of 1100

100 = 1100

100= Children of 1200

100=1200

100 = Children of 1300

100 = 1300 100 =Children of 1400

100 = 1400

모든 멤버의 모든 세그먼트를 하나의 세그먼트로 결합합니다.

Entity members 100,200,403,500=Children of 11

최적화된 보고서

다음 그림은 세그먼트 수를 줄이는 최적화된 보고서 디자인을 보여 줍니다. 세그먼트 수를 줄이면 MDX 요청 수가 감소하여 보고서가 더 빠르게 실행됩니다.
다시 디자인된 보고서 예

기타 중요 보고서 디자인 고려사항

가능한 경우 ASO 큐브에 대해 보고서를 디자인합니다. ASO 큐브를 사용할 수 없는 경우에만 BSO 큐브에 대해 보고서를 디자인합니다.
제외에서 누락된 블록을 항상 선택하여 누락된 블록이 보고서에 포함되지 않도록 합니다.
행과 열 수를 최소화합니다. 모범 사례: 열에는 밀집 차원을 사용하고 행에는 희소 차원을 사용합니다.
상위 레벨이 아니라 멤버의 필수 1차 하위 레벨에서 쿼리하도록 보고서를 디자인합니다.
레벨 0 멤버가 동적 계산으로 태그 지정되었으나 공식이 없는 경우 동적 계산 태그를 제거하거나 공식을 생성합니다. 동적 계산으로 태그 지정된 레벨 0 멤버에 데이터를 로드할 수 없습니다. 동적 계산으로 태그가 지정되지만 값을 계산할 공식이 없으므로 값을 표시할 수 없습니다. 이러한 멤버는 검색 성능에 부정적인 영향을 미칩니다.
가능한 경우, 대규모 멤버 조합을 포함하는 관계형 보고서(함수를 사용하여 확장된 여러 행 차원이 있는 보고서)를 사용하지 않습니다. 큰 보고서는 실행하는 데 상당한 시간이 걸리거나 실행되지 않을 수 있습니다. 셀 수가 10개를 초과하면 큰 보고서로 간주됩니다. 실제로 그렇지 않은데 Financial Reporting을 대규모 데이터 추출 툴로 취급하는 것과 비슷합니다.
데이터 소스에서 추가 메타데이터를 검색하는 텍스트 함수(예: CellText, PlanningAnnotations 및 ListOfCellDocuments)가 포함된 셀이 많은 보고서는 사용하지 마십시오.
페이지 차원 대신 현재 POV, 프롬프트 또는 장부를 사용합니다. 모든 페이지 멤버는 보고서를 실행할 때 한 번에 검색됩니다.
보고서의 크기에 따라 성능에 영향을 줄 수 있는 조건부 형식 지정 및 조건부 숨김의 영향을 고려하고 테스트합니다. 성능은 보고서에서 사용되는 기준 및 빈도 유형에 따라 달라집니다. 메타데이터 또는 데이터 쿼리의 일부인 기준(예: 데이터 값, 멤버 이름, 멤버 별칭 또는 설명)은 빠르게 렌더링됩니다. 큰 보고서에서는 일반적인 메타데이터 또는 데이터 쿼리의 일부가 아닌 기준 사용을 최소화합니다. 이러한 기준의 예로 세대, 레벨, 계정 유형, 속성 값 등이 있습니다.
차원 레이아웃을 고려합니다. 예를 들어 POV 또는 페이지에서 보고서 본문으로 이동할 수 있는 항목을 분석합니다.
항상 대칭(및 비대칭) 보고서를 디자인합니다. Essbase 쿼리는 대칭 또는 비대칭일 수 있습니다. 대칭 쿼리는 행 또는 열의 쿼리된 멤버가 교차 차원 레이아웃인 쿼리입니다. 비대칭 쿼리는 쿼리되는 멤버의 교차 차원 레이아웃이 행 또는 열에서 변경되는 쿼리입니다.
비대칭 쿼리가 발생하면 대칭 그리드만 처리하는 Essbase 하이브리드 쿼리 엔진이 자동으로 해당 쿼리를 여러 대칭 그리드로 분할합니다. 이러한 대칭 그리드는 한 번에 하나씩 처리된 후 원래 비대칭 양식으로 반환되므로 프로세스의 효율성이 저하됩니다.

Financial Consolidation and Close 검색 성능 문제해결

Financial Consolidation and Close 환경에서 보고서 성능 문제를 해결하는 방법에 대한 자세한 내용은 Financial Consolidation and Close 검색 성능 문제해결을 참조하십시오.

최근 애플리케이션 변경사항 검토

애플리케이션의 최근 변경사항 때문에 보고서 생성 속도가 느려지는지 확인합니다. 현재 활동 보고서의 애플리케이션 크기 테이블에 있는 정보를 보고서가 제대로 작동한 이전 날짜의 활동 보고서에 있는 정보와 비교하면 됩니다. 또한 보고서 디자인 및 사용의 최근 변경사항을 검토하여 이러한 변경사항이 보고서에 영향을 주지 않았는지 확인합니다.