4HANA
4HANA
Environment
SAP S/4HANA
Business Suite powered by SAP HANA
SAP HANA
Cause
1 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
23. Is it possible to add a different partitioning on top of Data Aging?
24. What re-partitioning possibilities exist for aging/TIME SELECTION partitioned tables?
25. Should Aging partitions be on first level or on second level?
26. When to create a new partition for the cold data?
27. Why is the uniqueness check for cold data switched off in SAP HANA per default?
28. Is there a need to adapt the current backup strategy to include cold partition(s)?
29. Is there a need to adapt the current system replication configuration to include cold partition(s)?
30. How to undo a Data Aging Run?
31. How to check the successful Data Aging configuration per table on database level?
Resolution
Data Aging is a Suite-tailored data management concept for reducing the SAP HANA memory footprint,
based on a Data Aging Framework provided by SAP NetWeaver ABAP. Data Aging is available for SAP
Business Suite on HANA and SAP S/4HANA applications and offers the option of moving large amounts of
data within SAP HANA in order to gain more working memory. Data Aging differentiates between
operationally relevant data (Hot/Current), and data that is no longer accessed during normal operation
(Cold/Historical). The data temperature can be used to horizontally partition the tables (taking part in Data
Aging) for optimizing resource consumption and performance - moving data between the different partitions
(i.e. from hot to cold partitions). Hot data resides within SAP HANA main memory, whereas cold data stays
primarily stored on disk, but remains accessible via SQL on request.
2 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
For application documentation about Data Aging, see SAP NetWeaver Library on SAP Help Portal -> SAP
NetWeaver Platform -> e.g. SAP NetWeaver 7.5 -> Function-Oriented View -> Solution Life Cycle
Management -> Data Aging.
3. What are the benefits of Data Aging in SAP HANA within SAP S/4HANA?
3 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
The goal of aging is to both reduce the main memory footprint and speed up database queries by only
keeping operationally relevant (hot) data in main memory. In contrast to this, cold data is placed primarily on
(less expensive but usually slower) secondary storage and accessible via SQL on request.
4. What is the difference between Archiving and Data Aging in SAP S/4HANA?
4 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
In SAP HANA, Data Aging is different than Archiving in the sense that cold data is still kept within the SAP
HANA Database and remains accessible via SQL in the very same table as the hot data (yet in another
partition). Whereas archived data - strictly read-only - is written to an archive file and deleted from the
database and needs additional access paths (address information or archive indexes) to be read. Aging
targets the main memory footprint reduction whereas archiving is the basis for ILM, covering the full life cycle
up to the destruction of information.
Data Aging offers you the option of moving operationally less relevant data within a database so as to gain
more working memory. You use the relevant SAP applications, particularly data aging objects to move data
from the current area to the historical area. The move influences the visibility when data is accessed. This
means that you can perform queries of large amounts of data in current area in a shorter time. This also
means that careful testing is required to ensure that the change of visibility is in line with the business
processes requirements.
To be able to apply Data Aging to your data, you need to fulfill certain requirements regarding the database
5 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
and the application.
Data Archiving is used to remove data from the database and store it outside in a consistent and secure
manner. The archived data is stored in a file system and from there can be moved to other, more cost-
efficient and long-term storage system via the ArchiveLink interface or the ILM interface.
Data Aging in only available in SAP Business Suite on HANA and S/4HANA Applications (starting with SAP
NetWeaver 7.4 SP05). To apply Data Aging in SAP HANA there are only certain prerequisites on ABAP side:
SAP HANA is already ready to handle Data Aging without any further configuration. Further prerequisites are
summarized in the SAP Help Portal Data Aging - Prerequisites for Data Aging.
No, data aging is not a licensed product. The Data Aging framework is available with NetWeaver release 740
SP05 onwards.
7. Are there any prerequisites for a table to participate in Data Aging in SAP S/4HANA?
6 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
A table can participate in Data Aging in case it is part of one or many Data Aging Objects (Transaction
DAGOBJ) and it is part in one Partition Object (Transaction DAGPTC). Additionally, it has to have the
additional column _DATAAGING, which is the basis for the time selection partitioning.
For more information about authorizations and roles look into the SAP Help Portal.
The potential on how much the SAP HANA memory footprint can be reduced by the usage of Data Aging is
estimated by the sizing report available in SAP Note 1872170 - Business Suite on HANA and S/4HANA
sizing report. As the visibility of aged data changes, please check carefully if the residence time used for the
calculation of the size estimation is acceptable for your business processes and requirements.
10. How to include Data Aging statistics into the Early Watch Alert (EWA)?
A chapter on data aging was designed, which displays the activation status and the ratio between current
7 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
(hot) and historical (cold) data. This ratio will give an indication in which extent data aging is implemented.
The prerequisite is having software component ST-PI with Support Package 4 or higher. For earlier support
packages it is required to implement SAP Note 2237911.
Current data is the data relevant to the operations of application objects, needed in day -to day-business
transactions. The application logic determines when current data turns historical by using its knowledge about
the object’s life cycle. The application logic validates the conditions at the object level from a business point
of view, based on the status, execution of existence checks, and verification of cross-object dependencies.
8 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
Current data is stored in the current area.
Examples of current data: Open FI items, items cleared only a few months ago, undelivered purchase orders,
sales documents of sales cycle that is still in progress, documents for an ongoing project, and IDocs that
need to be processed.
Historical data is data that is not used for day-to day-business transactions. By default, historical data is not
visible to ABAP applications. It is no longer updated from a business point of view. The application logic
determines when current data turns historical by using its knowledge about the object’s lifecycle. The
application logic validates the conditions at object level from a business point of view, based on the status,
executing existence checks, and verifying cross object dependencies. Historical data is stored in historical
area.
Examples of historical data: Cleared FI items posted two years prior to the current fiscal year, material
documents one period older than the current closed period, processed IDocs, and application logs after X
number of days.
The data aging mechanism for ABAP applications is based on a data aging framework provided by SAP
NetWeaver ABAP. ABAP developers use this framework to specify the data aging objects that are aged as
one unit, to identify the involved tables, and to implement the logic for determining the data temperature. The
data temperature is set via an additional data temperature column '_DATAAGING' (type
DATA_TEMPERAT URE with ABAP date format “YYYYMMDD”), which is added to all participating tables.
The data temperature can be used to horizontally partition the application data with time selection partitioning
(a.k.a. "aging") on the column '_DATAAGING' for optimizing resource consumption and performance. Only
one partition contains the hot data (represented by the value “00000000”) and the other partition(s) contain
cold data with different data temperature ranges.
By default, only hot data is accessed. As the hot data is located in a separate partition, SAP HANA should
only load that partition into memory during normal operation. If required, ABAP developers can set the data
temperature context to switch between accessing only hot data, all data, and all data above a specified data
temperature.
The SAP HANA-specific database shared library (DBSL) in the ABAP server adds a corresponding clause to
the SQL statements that are sent to SAP HANA. By adding the clause WITH RANGE RESTRICT ION
('CURRENT') to a SQL statement, SAP HANA restricts the operation to the hot data partition only. Instead of
'CURRENT' also a concrete value can be specified. This restricts the operation to all partitions with data
temperatures above the specified value. The clause WITH RANGE RESTRICT ION ('20100101'), for
example, tells SAP HANA to search the hot partition and all cold partitions that contain values greater or
equal than '20100101'. Range restriction can be applied to SELECT, UPDATE, UPSERT, DELETE
statements and to procedure calls.
All other clients that want to access these Data Aging tables with proper filtering, the same generic syntax
extension may be used.
The application knows which business objects are closed and may hence be moved to cold partitions.
Therefore the application actively sets values in this column to a date to indicate that the object is closed and
the row shall be moved to the Cold partition(s) during an Aging Run. Since the table is partitioned by the
temperature column, the rows are automatically moved then to a cold partition. The move influences the
visibility of the data and its accessibility. Several configuration steps/prerequisites need to be administered to
be able to execute a Data Aging Run (-> "How and when will the data be moved from the hot partition to the
cold partition(s)?").
9 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
In SAP Business Suite on HANA only Basis Documents are available for Data Aging like e.g. Application Log,
IDocs, and Workflow. In SAP S/4HANA Basis and Application Documents are available for Data Aging like
e.g. FI Document, Material Document, and Billing Document. A complete list of all available objects can be
found in the SAP Help Portal Data Aging - Available Data Aging Objects and under ABAP transaction
DAGOBJ.
15. What are typical tools to administer Data Aging in SAP S4/HANA?
Several ABAP transactions are available for Data Aging. A detailed list can be found in the SAP Help Portal
Data Aging - Data Aging Transactions.
Additionally Data Aging can be administered via the following Fiori applications:
You can enable data access from historical area by using the classes
CL_ABAP_SESSION_TEMPERATURE and CL_ABAP_STACK_TEMPERATURE.
Yes, you can modify historical data. But usually, business complete data is aged, so modifications are
exceptionally rare.
18. If cold data is accessed, will the partition(s) be loaded to the in-memory part of SAP
HANA?
Relevant cold data will be loaded in a buffer cache, which is dedicated memory section and separated from
the normal column store memory.
19. How and when will the data be moved from the hot partition to the cold
partition(s)?
The application logic determines when current data turns historical by using its knowledge about the object’s
life cycle. The application logic validates the conditions at the object level from a business point of view,
based on the status, execution of existence checks, and verification of cross-object dependencies.
The data will be moved during a Data Aging Run. To set up an Aging Run several tasks need to be fulfilled
upfront:
• Determining the data: The application-specific runtime class can be used to determine the data for
which Data Aging is intended. The SAP application assigns these runtime classes to the relevant Data
Aging object so that the runtime class can be called and processed in a Data Aging run.
• Managing Partitions: To be able to move the data from the HOT partition of the database to the
COLD partition(s) according to the specified partitioning objects and partitioning groups, all of the
participating tables must be partitioned for Data Aging. For each system, you need to define the
partitions for corresponding tables of a Data Aging object (DAGPTM), this setting is not transportable. If
the conditions are not fulfilled, the Data Aging run is not started. There should be at least one cold
10 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
partition covering todays date and for multiple partitions on one table the intervals can have no gaps.
• Activating Data Aging Objects: After the partitions have been defined, choose transaction Data
Aging Objects (DAGOBJ) to activate the Data Aging object. The system runs through various checks
on each table belonging to the Data Aging Object so that the Data Aging object can be used for the
run.
• (specific Settings for Data Aging Objects)
• Managing Data Aging Groups: Define Data Aging Groups via transaction DAGOBJ -> Goto -> Edit
Data Aging Groups and select all Data Aging Objects to be processed in one Group.
For scheduling Data Aging Runs go to transaction DAGRUN and select a Data Aging Group, Maximum
Runtime and Start Date/Time to schedule the run. The same transaction can be used to monitor Data Aging
Runs as the initial screen shows a list of runs with the details, such as, the Data Aging Groups, Start
date/time, Duration, and Job name.
Further details on the Data Aging Run can be found in the SAP Help Portal Data Aging – Data Aging
Procedure (Runtime).
20. Will the Data Aging Framework decide to move the data from the hot partition to
the cold partition(s) automatically?
The application logic determines when current data turns historical by using its knowledge about the object’s
life cycle. The application logic validates the conditions at the object level from a business point of view,
based on the status, execution of existence checks, and verification of cross -object dependencies. The
framework executes the move.
The SAP HANA database offers a special time selection partitioning scheme, also called aging. Time
selection or aging allows SAP Business Suite application data to be horizontally partitioned in to different
temperatures like hot and cold. The partitioning of tables that participate in Data Aging is administered on the
ABAP layer (Transaction DAGPTM).
Partitioning needs to be done in each system individually as partitions are not transportable. Alternately,
Partition Ranges can be maintained in customizing under SAP Netweaver > Application Server > Basis
Services > Data Aging > Maintain Partition Ranges. Partition Objects must be defined to combine several
tables that should be partitioned together according to the same schema (Transaction DAGPTC). Usually
SAP applications suggest partitioning objects that can be applied. All participating tables belonging to the
data aging objects and enhancements must be assigned to a partitioning object. A table is assigned to
exactly one partitioning object and cannot occur in more than one partitioning object. If the assignment of a
table to a partitioning object does not fulfill customers’ requirements, they can create customer -specific
partitioning groups without making modifications. Partitioning Groups override the assignment of tables to
partitioning objects if a partitioning object as well as a partitioning group contains the same table.
The partitioning gets active only after the next Data Aging Run.
Initially all Tables participating in Data Aging have an additional column _DATAAGING, which is the basis for
the time selection partitioning. The default value of this column is ‘00000000’. When the time selection
(=RANGE) partitioning is performed on this column, all records will remain in the hot partition - no data has to
be moved. The cold partitions (=new time RANGEs) will be added empty one by one - again no data has to
be moved during partitioning itself.
Only during the Data Aging Run column _DATAAGING is filled and the aged data will be moved from the hot
partition to the cold partition(s).
11 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
It is possible to add a partitioning on top of Data Aging/after having introduced Data Aging. However, the
preferred way is to start the other way round, in order to not move around massive amounts of aged data
again.
So it is highly recommended to start with Hash (or Range) on first level, and then add the time selection
partitioning using the quick-partitioning possibility on second level. Think upfront about the right partition size,
as the second level partitioning will split the data further into smaller chunks.
Nevertheless, see the following example for adding a HASH partitioning after having introduced Data Aging
already:
To add additional 1-level HASH 2 partitioning with key column A on top of the Data Aging RANGE partitioning
use:
It is crucial to always provide all Data Aging sub partitions (RANGES) within the ALTER TABLE statement.
Otherwise the re-partitioning can fail with errors. See SAP Note 2044468, Q 35. Which errors can happen in
relation to partitioning? for details.
With SAP HANA 2 SPS03 some new options have been introduced to convert/re-partition TIME SELECTION
partitioned tables. See Time Selection Partitioning (Aging) for details.
In former SAP HANA revisions it was already possible to re-partition aging partitioned tables e.g. from
HASH/Aging(RANGE) to another HASH/Aging(RANGE).
Example:
Table TAB_DATAAGING is 1-level HASH 2 partitioned on column B and 2-level Aging (RANGE)
partitioned with the hot partition (00000000) and one cold partition (20100101-20110101)
It is crucial to always provide all Data Aging sub partitions (RANGES) within the ALTER TABLE statement
and not only use:
12 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
Otherwise the re-partitioning will fail with one of the following errors:
SAP DBTech JDBC: [7]: feature not supported: not allowed on table having page loadable column
SAP DBTech JDBC: [2048]: column store error: fail to alter partition: [2593] Error during
split/merge operation;If a table is partitioned with Time Selection, it is not allowed to
repartition to non Time Selection table except for merging Time Selection range partitions.
Data Aging Partitioning can only be done on first level without any second level or used as a second -level
below a hash- or range-partition. If there is any risk that the remaining amount of records in “current” partition
after Data Aging can approach the two billion records limit in the future, choose a two -level approach with
aging being the second level. Take future volume growth into consideration as well as residence times for
Data Aging.
We create a new partition range when data to be aged is not covered by an existing partition range in
historical area. A new partition range can also be created when the maximum capacity threshold for an
existing partition is reached soon.
27. Why is the uniqueness check for cold data switched off in SAP HANA per default?
For ABAP applications using the Data Aging Framework, the default is set to “no uniqueness check” by SAP
HANA.
Unique constraints for primary keys or unique indexes are normally checked across all partitions in case the
partitioning is done over the artificial temperature that is not part of the primary key column of a table. This
means that the cold partitions have to be accessed whenever data is inserted or updated. To prevent a
negative impact on performance, a database application can switch off the uniqueness check for cold data by
setting an option in the partition specification. With this relaxation, it is up to the application to either prevent
duplicates (e.g. via GUIDs or number ranges) or to cope with duplicates. If uniqueness checks for cold data
are switched off, SAP HANA only ensures unique values in the hot partition. Conflicts between records in hot
and cold, between two cold partitions, and between records in the same cold partition, are not prevented on
database level in that case.
28. Is there a need to adapt the current backup strategy to include cold partition(s)?
No changes need to be done to the current backup strategy as the cold partitions are belonging to the table
itself as all other partitions and will be backed up together with the rest of the table.
29. Is there a need to adapt the current system replication configuration to include
cold partition(s)?
No changes need to be done to the current system replication configuration as the cold partitions are
belonging to the table itself as all other partitions and will be replicated to the replication side together with the
rest of the table.
If you want to undo a Data Aging Run and move back cold/aged data to the HOT partition you can use
transaction DAGRUN -> Goto -> Undo Mode and schedule a new "undo" Job for a specific Data Aging
Object.
13 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
For the Data Aging Objects Change Document and IDOC this standard undo process is not possible and
results in an error as they have been developed already before the implementation of the UNDO interface.
As a workaround two reports have been provided to undo a Data Aging Run for these two objects:
31. How to check the successful Data Aging configuration per table on database level?
Additionally the so called LOAD_UNIT can be checked per partition (PART_ID) of the different columns
(COLUMN_NAME) of the aged table (TABLE_NAME) within the View M_CS_ALL_COLUMNS. This column
is determining if a column/partition is fully loaded into memory upon access or is loaded page-wise. For cold
partition(s) the LOAD_UNIT should be configured as "PAGE", for the hot partition as "COLUMN".
Known Issues:
Impacted
Details
Revisions
SAP HANA
'LOAD_UNIT' for 'PARTITION_SPEC_SET_RANGE' syntax cannot be handled correctly
2.00.040 -
as well as the added partition is not paged as expected (SAP Note 2876629)
2.00.045
Keywords
Data Aging, SAP HANA, SAP Business Suite on HANA, SoH, SAP Business Suite for SAP HANA, SAP
S/4HANA, Archiving, COLD, HOT, Aging Run, aged data, data temperature, time selection partitioning, WITH
RANGE RESTRICT ION, paged attributes, page-loadable column, Data Aging Framework, Data access
restricted to hot storage, quick partitioning, TIME SELECTION partitioning, re-partitioning, repartitioning,
14 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
15 of 11
SAP HANA Data Aging in SAP S/4HANA By Irshad Rather
16 of 11