Custom SYS Monitoring in SAP Datasphere

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.

Was sind SAP Datasphere SYS Monitoring Views und wie funktionieren sie?

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.

Ansatz: wrappen, bereitstellen und konsumieren

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.

Wrapper View, angelegt im SAP HANA Database Explorer 

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.

SYS Wrapper View als Quelle in SAP Datasphere

Ab diesem Punkt lassen sich die System-Monitoring-Daten wie jede andere Datasphere-Quelle nutzen.

Sehen Sie sich die Aufzeichnung unseres Webinars an: 
"SAP Datasphere and the Databricks Lakehouse Approach"

Reporting auf das aktuelle Systemverhalten

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.

Eine historische Sicht mit Data Flows aufbauen

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.

Data Flow DF_MONITORING_SQL_PLAN_STATS lädt täglich SQL-Plan-Statistiken in eine lokale History-Tabelle.

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.

Welche Sicherheits- und Governance-Aspekte gelten für SYS Views?

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.

• Für jedes Objekt einen kurzen Machbarkeitstest einplanen, da der Zugriff von SAP blockiert sein 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.