Diagnosis
It is not possible to transfer changes of the partitioning by means of anormal activation if InfoCubes already contain data.
In principle, if InfoCubes already contain data, you are no longerpermitted to change the partitioning using the InfoCube maintenance inthe system. You can, however, import changes from the upstream test anddevelopment systems by using transports if
a) the InfoCube in the upstream systems does not contain any data and itwas therefore possible to change the partitioning in these systems usingthe InfoCube maintenance
or
b) the partitioning was changed in the upstream systems using therepartitioning tool.
The partitioning of InfoCubes is a property local to thesystem, which cannot be transported for the following reasons:
In a productive system with a large volume of data, you will often wantto use different partitioning to that used in the development system(which has a smaller volume of data), because partitioning can becounter-productive if there is only a small volume of data.
Changing the partitioning usually means reorganizing the fact tables,that is, all data records must be copied. Since the runtime on thedatabase depends linearly on the size of the InfoCube in the targetsystem and can last several hours, such actions should be scheduled, andexecuted at times at which there is less burden on the system, forexample on weekends. Otherwise, there can be a significant negativeimpact on the runtime behavior of the entire productive system.
During the reorganization, all data records are copied, indexes arerebuilt, and database statistics are calculated. Additional memory isrequired for this, which could potentially not be available. This canlead to the system being terminated.
During the reorganization, the InfoCubes involved are always lockedagainst all modifying actions (loading data, deleting data, compressing,rolling up in aggregates, building aggregates, change runs, and so on);this is the only way to ensure the consistency of the data. These downtimes must be planned.
Changes to the partitioning could enter the productive system byaccident by means of transport requests. Example: Person Achanges the partitioning of InfoCube CUBE in the developmentsystem, but does not write this change to a transport request, since heknows the consequences for the productive system. Person B addsan additional key figure to the InfoCube CUBE and writes theInfoCube to a transport request so that the change becomes active in thedownstream systems. The change to the partitioning would then also enterthe productive system with this transport request, without theconsequences being clear to person B, who triggered the transportrequest.
Changes to the partitioning of InfoCubes by means of transports are onlytransferred if InfoCubes in the target system do not contain any data.This behavior is an exception to the concept of properties ofpartitioning that are local to the system, but should support BIadministrators in broadcasting all settings of an InfoCube overthe system landscape when a new InfoCube is created. If an InfoCubealready exists in the target system and does not contain any data, bothfact tables of the InfoCube are deleted during the import and arerecreated according to the new description (including the modifiedpartitioning).

System Response
The changes to the partitioning are not transferred to the activeInfoCube. All other changes are activated. There is no negative impacton the productive system. The InfoCube can continue to be used withoutrestrictions.

Procedure
If you want to adjust the partitioning of the InfoCube in the system, dothis using the repartitioning function (transaction RSA1 Administration(bottom left) Repartitioning). Before doing this, you must read thedocumentation and SAP Note 1008833.