Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

If you are a regular user of the SAP EarlyWatch Alert Workspace in SAP for Me, then you probably know the app 2 Billion Record Limit.

The app forecasts the number of entries in SAP HANA tables, which are restricted to two billion rows per partition. In case a table is approaching this limit, you have to take actions depending on the corresponding table. Use the app to get an overview which tables are approaching the limit including a prediction when the limit is reached (itemized into a mean, best-case and worst-case scenario). For an introduction, see Forecast in SAP EarlyWatch Alert Workspace: How to Avoid a Table in a SAP HANA Database Reaching its....

Usually, the algorithm for the forecast is reliable. But forecasting has its limitations when the underlying data relate to different boundary conditions. This is the case if the table growth changes, e.g. due to a reorganization of the dataset or sudden changes in the generation of new records. As everywhere, “Garbage in - Garbage out” also applies here.

Until now, the forecast was based on all available measurements by default; you could, however, restrict the measurements used for the forecast manually:

As you can see, the forecast can change significantly when you restrict the measurements used for it. Therefore, until now, checking which measurements to use for the forecast has been a necessary manual step.

This behavior has been changed - the forecast is now based on the optimal selection of the previous measurements. This means that if the system detects a change in growth behavior at a given time (we call this a “change point”), the forecast is based only on the measurements after this point. Otherwise, everything remains as before and all available measurements are used for the forecast.

So for reliable forecasts, you can now mostly save the manual step mentioned - that of scanning your tables for characteristic kinks or breaks (these very change points) and accordingly restricting the data points to be used for the forecast.

In the UI, you can recognize such automatically set change points by the fact that the date for this point is labeled with Reset Automatically and only the measurements after this limit are used for the forecast. You can, however, still restrict the measurements used for the forecast manually.

So the artificial intelligence is not limited to create a forecast based on the available measurements, but checks these measurements itself to improve the forecast further.