Diagnóstico de Problemas de Desempenho de Relatórios do Financial Reporting
Os relatórios do Financial Reporting mal projetados podem gerar diversas solicitações MDX (Multi-Dimensional Expression) ou consultas do Oracle Essbase que causam o consumo de recursos significativos do Oracle Enterprise Performance Management Cloud. O consumo excessivo de recursos resulta na degradação de desempenho quando usuários simultâneos acessam tais relatórios.
A presença de vários segmentos no relatório é o principal motivo para geração de um grande número de solicitações MDX. Esta seção explica como tornar mais eficientes os relatórios do Financial Reporting com a redução do número de segmentos.
Reformulação de Relatórios: um Caso de Uso
O Relatório Original
A ilustração a seguir mostra o design do relatório original:
Essa ilustração de relatório mostra estes elementos de design:
- Várias linhas para cada membro Entity 100, 200, 403 e 500.
- Cada membro Entity tem 8 linhas cada para diferentes contas.
A tabela seguinte apresenta uma exibição detalhada do design de relatório original e o design otimizado:
| Design de Relatório Original | Design Otimizado |
|---|---|
Várias linhas para cada membro Entity:
|
Combina membros
|
|
Cada membro
|
Combina todos os segmentos de todos os membros em um único segmento:
|
O Relatório Otimizado
A ilustração a seguir mostra o design de relatório otimizado, que reduz o número de segmentos. A redução do número de segmentos agiliza a execução do relatório ao diminuir o número de solicitações MDX:
Outras Considerações Importantes sobre o Design do Relatório
- Se possível, projete relatórios com base em cubos ASO. Crie relatórios com base em cubos BSO somente se não houver cubos ASO disponíveis.
- Sempre selecione Blocos Ausentes em Supressão para garantir que blocos ausentes não sejam incluídos no relatório.
- Minimize o número de linhas e colunas. Melhor prática: use dimensões densas para colunas e dimensões esparsas para linhas.
- Projete relatórios para consultar no nível filho obrigatório dos membros, em vez de no nível pai.
- Se os membros de nível 0 forem marcados como Cálculos Dinâmicos, mas não tiverem uma fórmula, remova a marcação de Cálculo Dinâmico ou crie fórmulas para eles. Não é possível carregar dados em membros de nível 0 marcados como Cálculo Dinâmico. Eles não podem mostrar valores porque são marcados como Cálculo Dinâmico, mas não têm fórmulas para calcular valores. Tais membros afetam negativamente o desempenho de recuperação.
- Se possível, evite relatórios do tipo relacional (relatórios com várias dimensões de linha expandidas usando funções) com uma grande combinação de membros. A execução de relatórios grandes pode levar muito tempo (ou eles podem nem ser executados). Um relatório é considerado grande quando o número de células passa de dez mil. É como tratar o Financial Reporting como uma ferramenta de extração de dados de larga escala, o que ele não é.
- Evite relatórios com um grande número de células com funções de texto (por exemplo,
CellText,PlanningAnnotationseListOfCellDocuments) que recuperam metadados adicionais da origem de dados. - Use o PDV atual, prompts ou livros, em vez da dimensão Page; todos os membros de Page são recuperados de uma vez na execução do relatório.
- Considere e teste o impacto da Formatação Condicional e Supressão Condicional, que podem afetar o desempenho, dependendo do tamanho do relatório. O desempenho é condicionado aos tipos de critério e à frequência com a qual eles são usados no relatório. Os critérios que fazem parte dos metadados ou da consulta de dados, por exemplo, valor de dados, nome do membro e alias ou descrição do membro, são renderizados rapidamente. Com relatórios grandes, minimize o uso dos critérios que não fazem parte dos metadados regulares ou da consulta de dados. Os exemplos de tais critérios incluem geração, nível, tipo de conta e valor do atributo.
- Considere o layout da dimensão. Por exemplo, analise o que pode ser movido do PDV ou da página para o corpo do relatório.
- Sempre elabore um relatório simétrico (em vez de assimétrico). As consultas do Essbase podem ser simétricas ou assimétricas. As consultas simétricas são aquelas em que os membros consultados em linhas ou colunas têm layout de dimensões cruzadas. As consultas assimétricas são aquelas em que o layout de dimensões cruzadas dos membros que estão sendo consultados muda nas colunas ou nas linhas.
Ao encontrar uma consulta assimétrica, o mecanismo de consulta híbrida do Essbase, que processa apenas grades simétricas, quebra-a automaticamente em várias grades simétricas. Essas grades simétricas são processadas uma a uma e depois retornadas no formulário assimétrico original, o que torna o processo menos eficiente.
Solucionar problemas do desempenho de recuperação do Financial Consolidation and Close
Consulte Solução de Problemas do Desempenho de Recuperação do Financial Consolidation and Close para obter informações sobre como solucionar o desempenho do relatório nos ambientes do Financial Consolidation and Close.
Revisar Alterações de Aplicativo Recentes
Identifique se as alterações recentes no aplicativo fazem com que a geração de relatório fique lenta. Isso pode ser feito comparando as informações na tabela Tamanho do Aplicativo no Relatório de Atividades atual com as informações no Relatório de Atividades de uma data anterior, quando o relatório estava funcionando bem. Revise também as alterações recentes feitas no design e no uso do relatório, a fim de verificar se tais alterações não afetaram o relatório.