Diagnosi dei problemi di performance di Financial Reporting
Report di Financial Reporting progettati in modo inadeguato possono essere la causa di numerose richieste di espressioni multidimensionali (MDX) o di query Oracle Essbase che determinano un dispendio di preziose risorse di Oracle Enterprise Performance Management Cloud. Un eccessivo consumo di risorse provoca un calo nelle performance quando più utenti accedono contemporaneamente a tali report.
La presenza di diversi segmenti nel report è la causa principale della generazione di un numero elevato di richieste MDX. In questa sezione viene spiegato come aumentare l'efficienza dei report di Financial Reporting riducendo il numero di segmenti.
Riprogettazione di report: un caso d'uso
Report originale
Nella figura seguente è riprodotta la progettazione del report originale:
In questa figura relativa al report vengono mostrati gli elementi di progettazione descritti di seguito.
- Più righe per ogni membro Entity 100, 200, 403 e 500.
- Ogni membro Entity è dotato di 8 righe per conti diversi.
Nella tabella seguente viene presentata una vista generale in cui sono affiancate la progettazione del report originale e la progettazione ottimizzata.
| Progettazione del report originale | Progettazione ottimizzata |
|---|---|
Più righe per ogni membro Entity:
|
I membri
|
|
Ogni membro
|
Tutti i segmenti vengono combinati in un solo segmento:
|
Il report ottimizzato
L'illustrazione seguente mostra la progettazione del report ottimizzata che riduce il numero di segmenti. Questa riduzione velocizza l'esecuzione del report riducendo il numero di richieste MDX:
Altre importanti considerazioni sulla progettazione di report
- Se possibile, progettare i report in base ai cubi ASO. Progettare i report in base ai cubi BSO solo se non sono disponibili cubi ASO.
- Selezionare sempre Blocchi mancanti in Soppressione per assicurarsi che i blocchi mancanti non vengano inclusi nel report.
- Ridurre il numero di righe e colonne. Procedura consigliata: utilizzare dimensioni dense per le colonne e dimensioni sparse per le righe.
- Progettare i report in modo che le query vengano eseguite al livello figli dei membri richiesto anziché al livello padre.
- Se i membri di livello 0 sono contrassegnati come Calcolo dinamico ma non includono una formula, rimuovere il tag Calcolo dinamico oppure creare una formula. Non è possibile caricare dati nei membri di livello 0 contrassegnati come Calcolo dinamico. Non possono visualizzare valori perché sono contrassegnati come Calcolo dinamico ma non includono una formula per calcolare i valori. Questo tipo di membri ha un impatto negativo sulle performance del recupero.
- Se possibile, evitare report di tipo relazionale, ovvero con più dimensioni riga espanse mediante funzioni, che presentano una combinazione elevata di membri. I report di grandi dimensioni possono avere tempi di esecuzione prolungati o addirittura non essere eseguiti. Le dimensioni di un report vengono considerate elevate quando le celle sono più di 10.000. È come se Financial Reporting venisse utilizzato come strumento di estrazione dei dati su larga scale, cosa che non è.
- Evitare report con un numero elevato di celle con funzioni di testo (ad esempio,
CellText,PlanningAnnotationseListOfCellDocuments) che recuperano ulteriori metadati dall'origine dati. - Utilizzare il punto di vista corrente, i prompt o i registri invece della dimensione Pagina. Tutti i membri Pagina vengono recuperati simultaneamente quando il report viene eseguito.
- Valutare e testare l'impatto della formattazione e della soppressione condizionali, che possono incidere sulle performance a seconda delle dimensioni del report. Le performance sono subordinate al tipo di criteri e alla frequenza con cui vengono utilizzati all'interno del report. Il rendering dei criteri che rientrano nella query su metadati o dati, ad esempio valore dati, nome membro e alias o descrizione membro, è più veloce. Nei report di grandi dimensioni, ridurre al minimo l'utilizzo dei criteri che non fanno parte delle normali query su metadati o dati. Tra gli esempi di tali criteri figurano generazione, livello, tipo di conto e valore attributo.
- Considerare il layout dimensioni. Ad esempio, analizzare cosa può essere spostato dal punto di vista o dalla pagina nel corpo del report.
- Progettare sempre un report simmetrico (piuttosto che asimmetrico). Le query Essbase possono essere simmetriche o asimmetriche. Nelle query simmetriche, i membri sottoposti a query su righe o colonne hanno un layout tridimensionale. Nelle query asimmetriche, il layout tridimensionale dei membri sottoposti a query cambia nelle righe o nelle colonne.
Quando riscontra una query asimmetrica, il motore di query ibride Essbase, che elabora solo le griglie simmetriche, la scompone automaticamente in più griglie simmetriche. Queste griglie simmetriche vengono elaborate una per volta e quindi vengono restituite nel form asimmetrico originale, che rende il processo meno efficiente.
Risolvere i problemi delle performance di recupero di Financial Consolidation and Close
Fare riferimento alla sezione Risoluzione dei problemi delle prestazioni di recupero di Financial Consolidation and Close per informazioni sulla risoluzione dei problemi di performance dei report negli ambienti Financial Consolidation and Close.
Revisione delle modifiche recenti dell'applicazione
Stabilire se il rallentamento nella generazione del report è causato da modifiche recenti all'applicazione. È possibile eseguire questa verifica confrontando le informazioni nella tabella delle dimensioni dell'applicazione nel report attività corrente con le informazioni del report attività in una data precedente al momento in cui il report funzionava correttamente. Rivedere inoltre eventuali modifiche recenti alla progettazione e all'utilizzo del report per verificare che non abbiano prodotto conseguenze.