Skip to main content

13.3 — Performance & Pipeline Analysis

13.19 View Analyzer​

View Analyzer examines a view and the entities it consumes.

It can help identify:

  • expensive dependencies;
  • local tables;
  • remote sources;
  • persistence candidates;
  • memory implications;
  • model complexity.

Current SAP documentation also describes Explain Plan and SQL Analyzer plan-file options.

Use View Analyzer when the question is:

Which part of this model is responsible for the runtime or memory behavior?

13.20 Explain Plan versus View Analyzer​

Use the tools for different questions.

ToolBest question
Runtime MetricsHow is this view behaving now?
Explain PlanWhat is the execution structure?
View AnalyzerWhich model components contribute to the workload?
SQL Analyzer plan fileHow can the execution be analyzed in greater detail?
Data Pipeline AnalyzerWhere in the data pipeline is a transfer problem?
Remote QueriesWhat is happening across federation boundaries?

Do not use every tool for every incident.

13.21 Data Pipeline Analyzer​

Current SAP documentation describes Data Pipeline Analyzer as a tool for viewing and analyzing errors, warnings, or data discrepancies for a selected object.

It is especially valuable when the question is:

Where in the upstream pipeline did the problem begin?

Conceptual flow:

Analytic Model | v View | v Local Table | v Flow | v Remote Source

The analyzer helps navigate this dependency chain and identify the problematic point.

13.22 Data Pipeline Analyzer troubleshooting pattern​

For a wrong or missing dataset:

  1. Start at the affected consumption object.
  2. Open the pipeline analysis.
  3. Follow upstream dependencies.
  4. Find the first object with an error or discrepancy.
  5. Inspect its runtime details.
  6. Compare expected and actual data.
  7. Correct the causal object.
  8. Re-run the minimum necessary scope.
  9. Validate downstream results.

This is usually faster than opening objects randomly.

13.23 Remote query monitoring​

Current SAP documentation provides a Remote Queries monitor for queries sent through the federation layer to connected remote source systems.

Use it when:

  • a federated query is unexpectedly slow;
  • source latency is suspected;
  • remote execution is high;
  • the source is overloaded;
  • pushdown behavior needs investigation.

A federated query is a distributed execution problem.

13.24 Federation troubleshooting​

Use this path:

Consumer | v Semantic model | v Graphical/SQL view | v Remote table | v Federation layer | v Source system

Measure each boundary.

Possible root causes:

  • source database performance;
  • network latency;
  • unsupported pushdown;
  • large transferred result;
  • missing source statistics;
  • high concurrency;
  • remote authorization;
  • source maintenance.

13.25 Data Provisioning Agent monitoring​

For landscapes using a Data Provisioning Agent, current SAP documentation provides monitoring of agent resource information and connection usage.

Relevant signals include:

  • free physical memory;
  • used physical memory;
  • swap memory;
  • last connection time;
  • number of connections;
  • active real-time replication usage.

An agent issue can look like a Datasphere replication issue even when the Datasphere model itself is healthy.

13.26 Data Provisioning Agent logs​

Agent logs can be reviewed and filtered by:

  • search text;
  • time;
  • message type;
  • log file.

Use the agent log when the failure boundary is:

Datasphere | v Data Provisioning Agent | v On-premise source

Do not diagnose the on-premise connector only from the Datasphere task message.

13.27 Expensive statements​

Expensive statement monitoring is useful when SQL execution is consuming significant resources.

Investigate:

  • statement duration;
  • frequency;
  • resource usage;
  • affected object;
  • user or workload context;
  • recent model changes.

An expensive statement is a symptom to correlate with model design and workload behavior.

13.28 Memory incidents​

A memory incident should be investigated systematically.

Memory pressure | +--> Which task? +--> Which view? +--> Which source? +--> How many rows? +--> How many columns? +--> Which join? +--> Which aggregation? +--> What persistence mode? +--> What concurrency? +--> What changed?

Possible remedies:

  • reduce input volume;
  • project fewer columns;
  • filter earlier;
  • correct join cardinality;
  • aggregate earlier where valid;
  • partition suitable tables;
  • persist an appropriate layer;
  • change execution strategy;
  • stagger workloads.

13.29 Performance regression​

A regression is:

Old baseline = 40 seconds New runtime = 4 minutes

Do not immediately blame infrastructure.

Check:

  • model change;
  • data-volume change;
  • source latency;
  • cardinality change;
  • statistics;
  • persistence state;
  • partition distribution;
  • concurrency;
  • schedule overlap.

The regression may be caused by data growth rather than code change.