SAP Datasphere bietet integrierte Monitoring-Funktionen, um Speicherverbrauch, Task-Ausführung und die allgemeine Systemaktivität zu überprüfen. Das ist für die tägliche Administration nützlich, allerdings beantworten die Monitoring-Screens allein nicht immer die längerfristigen Fragen, denen technische und fachliche Teams nachgehen möchten, zum Beispiel:
Welche SQL-Statements verbrauchen wiederholt die meiste Zeit oder den meisten Speicher?
Nehmen Performance-Probleme nach einem Release, einer Änderung am Data Load oder einer neuen Reporting-Anforderung zu?
Welche Workloads sollten untersucht, optimiert oder über die Zeit hinweg beobachtet werden?
Lassen sich technische Monitoring-Daten mit operativem oder fachlichem Kontext in einem Analytic Model (AM) kombinieren?
Ein praktikabler Weg ist es, ausgewählte Monitoring-Daten aus dem SAP HANA SYS Schema in einem SAP Datasphere Space als Data Assets verfügbar zu machen.
Das SYS Schema enthält System- und Monitoring-Views, die sowohl strukturelle als auch Laufzeitinformationen über die zugrunde liegende SAP HANA Datenbank bereitstellen.
Manche Views liefern relativ stabile Metadaten, etwa Tabellen- oder Spalteninformationen. Andere geben Einblick in Workload und Performance, darunter:
M_EXPENSIVE_STATEMENTS
M_MULTIDIMENSIONAL_STATEMENTS
M_MULTIDIMENSIONAL_STATEMENT_STATISTICS
M_SQL_PLAN_STATISTICS
und viele weitere.
Diese Views sind für die technische Analyse überaus nützlich. Sie stehen jedoch nicht automatisch als wiederverwendbare Reporting-Objekte in einem Datasphere Space zur Verfügung. Hinzu kommt, dass Monitoring-Informationen flüchtig sein können: Datensätze werden möglicherweise gelöscht, überschrieben oder sind nach Systemereignissen oder beim Erreichen von Retention-Grenzen nicht mehr verfügbar.
Das erschwert ein historisches Reporting, sofern die Daten nicht bewusst gesichert werden.
Da es nicht praktikabel ist, das komplette SYS Schema bereitzustellen, wird mit einem Datenbankbenutzer eine kontrollierte Wrapper View im Schema angelegt. Der Wrapper kann genau die Felder bereitstellen, die für das jeweilige Reporting- oder Monitoring-Szenario benötigt werden.
Ein Datenbankbenutzer kann beispielsweise eine View über M_SQL_PLAN_STATISTICS anlegen:
CREATE VIEW "NL_GENERAL#MANTOUSIS"."MONITORING_SQL_PLAN_STATS" AS
SELECT
*
FROM "SYS"."M_SQL_PLAN_STATISTICS";
Für den produktiven Einsatz sollte SELECT * durch eine explizite Liste der benötigten Spalten ersetzt werden. Das macht das Objekt wartungsfreundlicher, reduziert die unnötige Offenlegung von Daten und unterstützt ein Least-Privilege-Design.
Sobald die View erstellt ist und die erforderlichen Berechtigungen vorliegen, kann sie dem betreffenden Datasphere Space bereitgestellt werden - in unserem Szenario NL_GENERAL. Die View erscheint anschließend als Quelle unterhalb des Datenbankbenutzers im Sources Browser, wenn eine neue View angelegt wird.
Ab diesem Punkt lassen sich die System-Monitoring-Daten wie jede andere Datasphere-Quelle nutzen.
Eine Datasphere View auf Basis des Wrappers schafft unmittelbare Transparenz über Expensive Statements, SQL-Plan-Aktivität oder das Verhalten multidimensionaler Abfragen. Zusätzlich bietet sie eine flexible Möglichkeit, das Monitoring beliebig zu erweitern.
So lassen sich gezielte Monitoring-Dashboards auf Basis der eigenen KPIs, Schwellwerte und operativen Prozesse aufbauen, statt sich ausschließlich auf die Standard-Monitoring-Screens zu verlassen.
System-Monitoring-Daten können außerdem mit technischem oder fachlichem Kontext kombiniert werden. SQL-Plan-Trends ließen sich zum Beispiel nach Berichtsperiode, Projekt-Release, Data-Load-Fenster, Applikation oder Geschäftsprozess auswerten.
Indem hierfür der Standard-Modellierungsansatz genutzt wird, der in einem Analytic Model mündet, kann dieses Reporting wie jedes andere konsumiert werden: in SAC mit einer eigenen Story bzw. einem eigenen Dashboard.
Live-Monitoring-Views sind nicht als langfristiger Historien-Layer gedacht. Um SQL-Plan-Statistiken über die Zeit hinweg vorzuhalten, kann beispielsweise ein eingeplanter Data Flow erstellt werden, der die Datasphere View liest und die Ergebnisse in eine lokale History-Tabelle schreibt.
In diesem Beispiel kann der Data Flow DF_MONITORING_SQL_PLAN_STATS täglich laufen und einen datierten Snapshot der View MONITORING_SQL_PLAN_STATS ablegen.
M_SQL_PLAN_STATISTICS → MONITORING_SQL_PLAN_STATS → DF_MONITORING_SQL_PLAN_STATS → MONITORING_SQL_PLAN_STATS_HISTORY
Die History-Tabelle sollte einen Snapshot-Timestamp enthalten, damit jede Ausführung im Kontext ausgewertet werden kann. Dazu wird der Data Flow so konfiguriert, dass er Datensätze anfügt statt sie zu überschreiben, um ein tägliches Log aufzubauen.
So entsteht ein verlässlicher historischer Layer, um wiederkehrende SQL-Plan-Muster zu identifizieren, das Systemverhalten vor und nach Änderungen zu vergleichen und langfristige Performance-Trends zu untersuchen.
Hinweis: Je nach Quelldaten kann es notwendig sein, den Current System Timestamp als Calculated Field hinzuzufügen und diesen als zusätzlichen Primary Key in der Zieltabelle zu definieren, um einen täglichen Snapshot zu erreichen.
Eine gute Implementierung bleibt selektiv, sicher und wartbar:
Nur die SYS Views und Felder bereitstellen, die für den Use Case benötigt werden.
Nicht benötigte technische Datensätze oder Spalten so früh wie möglich filtern.
SQL-Text und benutzerbezogene Felder sorgfältig behandeln, da sie sensible Informationen enthalten können.
Eine Retention Policy für die History-Tabelle definieren, um unnötiges Speicherwachstum zu vermeiden.
Einen geeigneten Deduplication Key vorsehen, falls der Data Flow mehr als einmal pro Tag ausgelöst werden kann.
Custom monitoring in SAP Datasphere: Unser Fazit
Das Standard-Monitoring von SAP Datasphere liefert nützliche operative Transparenz. Ausgewählte SYS Monitoring Views können jedoch deutlich mehr Mehrwert stiften, wenn sie kontrolliert in den Analytics Layer geholt werden.
Indem relevante SYS Views über einen Datenbankbenutzer gewrappt, einem Datasphere Space bereitgestellt und ausgewählte Snapshots über Data Flows wie DF_MONITORING_SQL_PLAN_STATS persistiert werden, gelangen Organisationen von einem punktuellen Monitoring zu wiederverwendbarem Reporting und historischer Analyse. Ein darauf aufbauendes Analytic Model und eine SAC Story bringen weitere Vorteile.
Das Ergebnis ist eindeutig: Monitoring-Daten werden zu einem governten Analytics Asset und lassen sich flexibel erweitern – genau wie jedes andere Reporting auch.
Bleiben Sie gespannt auf einen Folgebeitrag, in dem wir noch einen Schritt weiter gegangen sind und für einen Kunden eine Custom-Monitoring-Lösung mit Dynamic SQL umgesetzt haben, um Datenqualität und Load-Verhalten auszuwerten.
Möchten Sie tiefere Einblicke in Ihre Systemperformance gewinnen, dynamische SQL-Analysen automatisieren oder Ihre Monitoring-Daten nahtlos in SAP Analytics Cloud integrieren?Sprechen Sie mit unserem Experten-Team und lassen Sie uns gemeinsam eine maßgeschneiderte Monitoring-Strategie für Ihre Systemlandschaft entwickeln.