Hello again SAP BW enthusiasts!
Recently, I wrote about the activation process of ADSOs and highlighted that an additional remodeling task is often necessary if the ADSOs contains data (see my previous blog). Today I would like to share the good news that SAP has provided a framework which improves flexibility and offers a lever to avoid remodeling tasks for some cases.
In a nutshell, my previous blog elaborated on the cases when changes to an ADSO with data require additional remodeling tasks to be executed manually in order to activate the object properly. This also applies to the transport management when you provision these changes to the PROD-system finally. The separate remodeling job´s role is to keep the activation time to a minimum and thus to avoid terminations during the direct execution (e.g. time-outs). This safety belt is justified, because changes to ADSOs with a lot of data might result in a huge amount read and write operations to the existing transactional data in the ADSO.
The new framework differentiates between
Let´s start with case 1: These operations remain unchanged. For instance, when you create a new column and you would like to fill it with a value at the same time, remodeling cannot be avoided (e.g. change the Master Data Check to “Persist SID in DataStore”). The same is true for modifications to the key fields or properties related to inventory key figures, data tiering, partitions, or indices as they usually require technical adaptions to the ADSO core tables on the SAP HANA database level.
The good news is that there is now more flexibility regarding operations related to case 2:
All ADSO changes which result in read-only operations on the ADSO data provide the option to avoid the separate remodeling task. Some common scenarios are:
Important! There is the precondition, that the largest ADSO table is smaller than a predefined threshold which is currently set to 100 million records. As stated above already, this upper limit is intended to prevent the execution from taking too long and avoid terminations.
There is a new RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD available to reduce this predefined limit. Why would you do this? Well, let´s take following scenario:
Initially, there will be no remodeling request in DEV and QA, but when you import the transport to Production, manual remodeling will be unavoidable. The parameter mentioned above enables you to enforce the remodeling the QA-system as well for the purpose to be able to test this process before you set it live.
To be clear – the parameter is not meant to increase the limit above the 100 million value, but the RSADMIN-value needs to be less this limit, for instance it could be set to 500’000 for the scenario above to enable to test the manual remodeling in QA-environment as well. After this setting, the transport to the QA-system will generate a remodeling request instead of activating the ADSO in the after-import directly.
The new framework is available with SAP note 3006437 (ADSO: Online Execution of Remodeling Operations) which applies to both SAP BW 7.5 SP21 and SAP BW/4HANA 2.0 SP08.
Additional references:
Okumaya devam et...
Recently, I wrote about the activation process of ADSOs and highlighted that an additional remodeling task is often necessary if the ADSOs contains data (see my previous blog). Today I would like to share the good news that SAP has provided a framework which improves flexibility and offers a lever to avoid remodeling tasks for some cases.
In a nutshell, my previous blog elaborated on the cases when changes to an ADSO with data require additional remodeling tasks to be executed manually in order to activate the object properly. This also applies to the transport management when you provision these changes to the PROD-system finally. The separate remodeling job´s role is to keep the activation time to a minimum and thus to avoid terminations during the direct execution (e.g. time-outs). This safety belt is justified, because changes to ADSOs with a lot of data might result in a huge amount read and write operations to the existing transactional data in the ADSO.
The new framework differentiates between
- Read AND Write operations to the ADSO data, and
- Read ONLY operations on the ADSO data.
Let´s start with case 1: These operations remain unchanged. For instance, when you create a new column and you would like to fill it with a value at the same time, remodeling cannot be avoided (e.g. change the Master Data Check to “Persist SID in DataStore”). The same is true for modifications to the key fields or properties related to inventory key figures, data tiering, partitions, or indices as they usually require technical adaptions to the ADSO core tables on the SAP HANA database level.
The good news is that there is now more flexibility regarding operations related to case 2:
All ADSO changes which result in read-only operations on the ADSO data provide the option to avoid the separate remodeling task. Some common scenarios are:
- Add compounding child while compounding parent is already in ADSO and contains values: In this case the existing parent-child value combinations have to be identified in the ADSO and corresponding SID entries need to be created in the master data.
- Change Validity Characteristics if ADSO is Inventory-Enabled:
In this case the ADSO Validity table is recreated based on the ADSO data. - Add InfoObject/Field “Criteria”:
In this case the ADSO data is validated whether it meets the new criteria and in the negative case an error message is generated and the activation of the object is denied.
Important! There is the precondition, that the largest ADSO table is smaller than a predefined threshold which is currently set to 100 million records. As stated above already, this upper limit is intended to prevent the execution from taking too long and avoid terminations.
There is a new RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD available to reduce this predefined limit. Why would you do this? Well, let´s take following scenario:
- You modify an existing ADSO and the change refers to case 2
- Your ADSO contains no data in your DEV-system, 600’000 records in the QA-system
and 500 million records in Production.
Initially, there will be no remodeling request in DEV and QA, but when you import the transport to Production, manual remodeling will be unavoidable. The parameter mentioned above enables you to enforce the remodeling the QA-system as well for the purpose to be able to test this process before you set it live.
To be clear – the parameter is not meant to increase the limit above the 100 million value, but the RSADMIN-value needs to be less this limit, for instance it could be set to 500’000 for the scenario above to enable to test the manual remodeling in QA-environment as well. After this setting, the transport to the QA-system will generate a remodeling request instead of activating the ADSO in the after-import directly.
The new framework is available with SAP note 3006437 (ADSO: Online Execution of Remodeling Operations) which applies to both SAP BW 7.5 SP21 and SAP BW/4HANA 2.0 SP08.
Additional references:
- 2769125 – Composite Note: RSADMIN Parameters for SAP BW/4HANA
- 0912367 – Composite Note: RSADMIN Parameters for SAP BW 7.x
Okumaya devam et...