Aufgrund schlecht konzipierter Financial Reporting-Berichte können mehrere Multi-Dimensional Expression-(MDX-)Anforderungen oder Oracle Essbase -Abfragen generiert werden, die zu einem erheblichen Ressourcenverbrauch in Oracle Enterprise Performance Management Cloud führen können. Ein übermäßiger Ressourcenverbrauch führt zu Performanceeinbußen, wenn mehrere Benutzer gleichzeitig auf solche Berichte zugreifen.
Wenn im Bericht mehrere Segmente vorhanden sind, ist dies die Hauptursache dafür, dass zahlreiche MDX-Anforderungen generiert werden. In diesem Abschnitt wird erläutert, wie die Effizienz von Financial Reporting-Berichten gesteigert werden kann, indem die Anzahl der Segmente reduziert wird.
Berichte neu entwerfen: ein Anwendungsfall
Der ursprüngliche Bericht
In der folgenden Abbildung ist der ursprüngliche Berichtsentwurf dargestellt:
In dieser Berichtsabbildung werden diese Entwurfselemente angezeigt:
- Mehrere Zeilen für jedes Entity-Element 100, 200, 403 und 500.
- Jedes Entity-Element weist jeweils 8 Zeilen für verschiedene Konten auf.
Die folgende Tabelle enthält eine allgemeine Übersicht über den ursprünglichen Berichtsentwurf und den optimierten Entwurf:
Der optimierte Bericht
In der folgenden Abbildung ist der optimierte Berichtsentwurf dargestellt, mit dem die Anzahl der Segmente reduziert wird. Eine geringere Anzahl an Segmenten ermöglicht eine schnellere Berichtsausführung, indem die Anzahl an MDX-Anforderungen reduziert wird:
Sonstige wichtige Aspekte zum Entwerfen von Berichten
- Entwerfen Sie nach Möglichkeit Berichte für ASO-Cubes. Entwerfen Sie Berichte für BSO-Cubes nur, wenn keine ASO-Cubes verfügbar sind.
- Wählen Sie immer unter Unterdrückung Fehlende Blöcke aus, um sicherzustellen, dass fehlende Blöcke nicht in den Bericht aufgenommen werden.
- Minimieren Sie die Anzahl der Zeilen und Spalten. Best Practice: Verwenden Sie dicht besetzte Dimensionen für Spalten und dünn besetzte Dimensionen für Zeilen.
- Entwerfen Sie Berichte, um Abfragen auf der erforderlichen untergeordneten Ebene der Elemente anstatt auf der übergeordneten Ebene durchzuführen.
- Wenn Elemente der Ebene 0 mit "Dynamische Berechnung" gekennzeichnet sind, aber keine Formel angegeben ist, entfernen Sie entweder die Kennzeichnung "Dynamische Berechnung", oder erstellen Sie Formeln für die Elemente. Sie können keine Daten in Elemente der Ebene 0 laden, die mit "Dynamische Berechnung" gekennzeichnet sind. Diese Elemente können keine Werte anzeigen, weil sie mit "Dynamische Berechnung" gekennzeichnet sind, aber keine Formel zur Berechnung von Werten vorhanden ist. Solche Elemente wirken sich negativ auf die Abrufperformance aus.
- Verwenden Sie nach Möglichkeit keine relationalen Berichte (Berichte mit mehrzeiligen Dimensionen, die durch Funktionen erweitert sind) mit vielen Elementkombinationen. Die Ausführung großer Bericht kann sehr viel Zeit in Anspruch nehmen (oder die Berichte werden nicht ausgeführt). Ein Bericht gilt als groß, wenn mehr als 10.000 Zellen enthalten sind. Dies ist etwa so, als würde man Financial Reporting als umfassendes Datenextraktionstool behandelt, was es nicht ist.
- Verwenden Sie nach Möglichkeit keine Berichte, die eine große Anzahl an Zellen mit Textfunktionen enthalten (z.B.
CellText
, PlanningAnnotations
und ListOfCellDocuments
), mit denen zusätzliche Metadaten aus der Datenquelle abgerufen werden.
- Verwenden Sie den aktuellen POV, Prompts oder Bücher anstelle der Page-Dimension. Alle Elemente der Page-Dimension werden beim Ausführen des Berichts gleichzeitig abgerufen.
- Berücksichtigen und testen Sie die Auswirkung der bedingten Formatierungen und der bedingten Unterdrückung. Diese können sich je nach Größe des Berichts negativ auf die Performance auswirken. Die Performance ist abhängig von der Art der Kriterien und von der Häufigkeit, mit der die Kriterien im Bericht verwendet werden. Kriterien, die Teil von Metadaten- oder Datenabfragen sind, wie z.B. Datenwert, Elementname und Elementalias oder -beschreibung, werden schnell wiedergegeben. Reduzieren Sie in großen Berichten die Verwendung von Kriterien, die nicht Teil der regulären Metadaten- oder Datenabfrage sind. Zu solchen Kriterien gehören beispielsweise Generation, Ebene, Kontentyp und Attributwert.
- Beachten Sie das Dimensionslayout. Beispiel: Analysieren Sie, was aus dem POV oder der Seite in den Berichthauptteil verschoben werden kann.
- Entwerfen Sie immer einen symmetrischen (im Vergleich zu einem asymmetrischen) Bericht. Essbase-Abfragen können sowohl symmetrisch als auch asymmetrisch sein. Symmetrische Abfragen sind Abfragen, bei denen Elemente in Zeilen und Spalten dimensionsübergreifend abgefragt werden. Asymmetrische Abfragen sind Abfragen, bei denen das dimensionsübergreifende Layout der abgefragten Elemente sich entweder in den Zeilen oder den Spalten ändert.
Die Essbase-Engine für hybride Abfragen, die ausschließlich symmetrische Raster verarbeitet, schlüsselt eine asymmetrische Abfrage automatisch in mehrere symmetrische Raster auf. Diese symmetrischen Raster werden nacheinander verarbeitet und anschließend wieder in das ursprüngliche asymmetrische Formular gebracht, wodurch der Prozess weniger effizient wird.
Kürzlich vorgenommene Anwendungsänderungen prüfen
Ermitteln Sie, ob kürzlich vorgenommene Änderungen an der Anwendung zu einer langsameren Berichtsgenerierung führen. Vergleichen Sie hierzu die Informationen in der Tabelle "Anwendungsgröße" des aktuellen Aktivitätsberichts mit den Informationen in einem früheren Aktivitätsbericht, als der Bericht ordnungsgemäß funktioniert hat. Prüfen Sie außerdem Änderungen, die kürzlich an Berichtsentwurf und -verwendung vorgenommen wurden, um sicherzustellen, dass sich diese Änderungen nicht auf den Bericht ausgewirkt haben.