Optimizing Version Data Load

When you are working with data models, whether they are built for data visualization or planning, there are many best practices that apply to both. For this reason, it’s important that you have completed Optimizing Performance in Data Loading unit in the Optimizing Performance in SAP Analytics Cloud Story Design course.

In that unit, we explore how data is loaded in SAP Analytics Cloud from single and multiple data sources, data loading optimization settings, controlling data loading on widget level with data refresh settings, and other features and functionality that can optimize performance in data loading.

In this lesson, we focus specifically on version data load and the ways that you can optimize the planning model.

When you start a data input session for the first time, public data is (behind the scenes) copied to a dedicated private version. This private version allows you modify the data without interfering with the original version until it has been published. The name, edit mode, suggests that you are working on the public data directly, but in reality you're working on a copy, a private version of the data container that is only visible for you. These private versions, created invisibly during a public edit mode, are known sources for potentially high memory consumption and expensive query processing because of the large amount of data being copied.

If the edit state of a version becomes too large, it may cause operations, like publish, to reach operation-specific limits, independent of the overall system memory available. You may have to undo changes in the version history, however, if the version becomes so large that this is no longer possible to undo changes and it has become generally unusable, then you may have to revert the version (for public edits) or delete the version (for private versions).

It's important that version sizes are monitored using the Private Versions Statistics and Analysis tool. This tool displays versions by size, allowing you to make version creators aware of their versions size and the potential high memory consumption they might cause.

By tracking version sizes, you can identify and address data growth patterns, optimize housekeeping, and implement data archiving or purging strategies to ensure efficient storage utilization. If there is a lack of overall system memory, versions that are not needed should be deleted. Large private versions created by other users may also impact performance, so a good housekeeping strategy is a must. Regularly deleting unused private versions and reverting edits, as needed, will help maintain system efficiency.

Although planning on private versions isn’t restricted, you might want to consider other ways to better control the performance for these versions. To start, consider the model design, so that the versions of the model are smaller - understand the requirement, plan it, then build it. Some best practice tips for optimizing version size include:

Use a planning area. If public version sizes cannot be reduced, it is strongly recommended to use a planning area for public edit versions. We cover planning areas in a separate lesson, but to put it simply, planning areas can be configured to reduce version size by only putting the data in the planning area into edit mode, reducing memory usage.

Create a performance parameter. Configure a private version performance parameter. The default parameter is 5 million database records but this can be changed to meet your needs. If you create a data snapshot that exceeds the configured parameter, for example, while creating a private version or starting to edit a public version, then you are notified. We cover this setting in the lesson on planning areas.

Set filters before copying. To reduce the size of the version, create a private version with appropriate filters before you copy the data. Working with this type of private version results in noticeable performance gains when entering new data as only a subset of data is copied, resulting in very noticeable performance gains when entering new data. The more discriminating these filters are, the better!

Use separate versions for process steps. Use smaller, separate versions for your planning topics, for example cost center and profitability planning. Instead of executing all planning steps of a planning topic in one large version, use separate versions for optimistic and pessimistic planning, before copying to your final version that best represents your planned year.

Plan better data actions. Rethink data action designs so that the data actions create fewer records. We cover optimizing data actions later in this course.

Define read data access control on the model. This ensures that non-admin planners will create private versions or edit public versions with a configured restricted data snapshot. The more restrictive a user’s data access, the better the performance since the query output will only return data that a user is allowed to view or edit. Use Read data access control and locking features to restrict data regions. Only use Write on dimensions when it's really needed and choose Read and Write wisely on large versions (for example, actuals) to fewer users.

For more information on data access control, see the Securing Data in SAP Analytics Cloud unit in the Managing Security and Administration in SAP Analytics Cloud learning journey.