Symptom
One or more of the following symptoms are observed on view persistency
- View execution suddenly becomes slower
- Memory consumption increases
- Same result set but much higher peak memory
Environment
SAP Datasphere
Cause
The symptoms can have different causes. Possible contributing factors include:
- Changes to the persistence state of dependent Views, including View recreation, automatic invalidation, refresh, persistence rebuild, or removal of persisted data.
- Changes to the View model or dependent objects
- Changes in source data volume, distribution, or statistics
- Changes in filter pushdown or remote-source performance
- A different execution plan or increased intermediate result size, for example due to join cardinality, partition predicates, or row multiplication
- Changes in tenant workload, workload management configuration, or available resources
Resolution
SAP Support may investigate execution errors, sudden performance regressions, abnormal differences between comparable runs, and suspected product malfunctions. Whenever possible, provide a comparable successful run and problematic run for analysis.
By contrast, performance optimization that aims to determine the optimal customer-specific model, capacity, configuration, or throughput target normally requires iterative analysis, testing, measurement, and adjustment, and is therefore a consulting activity.
Nevertheless, the following check points may be helpful:
- Check for recent model and dependency changes: If behavior changed suddenly, use the Audit Log and Lineage Graph to identify whether the affected View, or any table or view it depends on, was changed, recreated, or redeployed between the successful and problematic runs. Also review the Persistency Job History for 'Persist Data', refresh, or 'Remove Persisted Data' events affecting dependent Views
- Check the persistence state of dependent Views: Review the Persistency Job History of the affected View and its dependencies. A change in the persistence state of a dependent View can significantly alter the execution path and resource consumption, even if the final result set remains similar.
- Check for recent changes in base-table data volume or distribution: Compare source-table row counts and historical growth trends. A similar final result set does not necessarily indicate that the same amount of data was processed internally.
- Check workload-management and resource changes: Tenant vCPU upsizing, workload-class changes, thread-allocation changes, or differences in concurrent workloads may affect query parallelism, execution time, and memory consumption.
- Check for broader tenant resource pressure: Check whether the tenant was under broader resource pressure during the affected period. When comparing runs, consider whether the successful run and the problematic run occurred under comparable tenant workload conditions.
Understanding memory consumption
The number of rows returned by a View is not necessarily indicative of the amount of intermediate data processed during execution. Memory consumption is primarily driven by intermediate processing steps within the execution plan. Views containing large joins, UNION operations, window functions, calculated join keys, or other complex transformations may process substantially larger intermediate result sets than the final output returned to the consumer. As a result, two executions that produce similar result sets may require significantly different amounts of memory and CPU resources.
See Persisted Views and Memory Consumption | SAP Help Portal
Information for run comparison
For Support analysis, provide one successful run and one problematic run where the affected View and its dependent Views have NOT changed and the data volume is comparable.
The most useful comparison is between runs where:
- The same View was executed
- The dependent objects were unchanged
- Comparable input data volumes were processed
- Comparable parameters were used
- Tenant workload conditions were similar
Differences in any of these factors may significantly affect execution time, memory consumption, and execution plans, making run-to-run comparisons inconclusive.
Support and consulting scope
Based on the results of these checks:
- If the collected evidence indicates an execution error, sudden performance regression, abnormal difference between comparable runs, or suspected product malfunction, SAP Support can continue the investigation.
- If no product-related malfunction can be identified and the objective is to determine the optimal model design, persistence strategy, capacity, configuration, or customer-specific throughput target, the request falls outside the normal scope of SAP Support. Such activities typically require iterative analysis, testing, measurement, and optimization and are therefore considered consulting services.
Similarly, requests for end-to-end performance optimization, performance tuning recommendations, architecture reviews, sizing exercises, or customer-specific best-practice guidance are generally consulting activities because the appropriate solution depends on the customer's individual data model, workload characteristics, business requirements, and system landscape.
For issues that fall within SAP Support scope, create a support case and follow the recommendations described KBA 2854764 to ensure SAP can get a solution to you in the shortest possible time.
Keywords
KBA , DS-DI-VIW , View Persistency and Runtime , Problem
SAP Knowledge Base Article - Public