Skip to end of metadata
Go to start of metadata

Consistency of Time Dimension



The consistency of the time dimension is extremely important for non-cumulative Cubes and partitioned InfoCubes. In case of inconsistencies it may happen that queries display wrong data. It's possible to check the time dimension with the help of transaction RSRV: All Elementary Tests -> Transaction Data -> Consistency of the Time Dimension for an InfoCube. If inconsistencies are found, the message RSCV061 (and/or RSCV054, RSTIME002, DBMAN062, screenshotRSTIME002) is issued and the field TIMDIM_INCON is set to X in the table RSMDATASTATE. The query always checks this field during runtime:

  • Partitioned Cubes: if the query contains time restrictions the system tries to derive the relevant filters for the characteristic used for defining the partitions (0calmonth or 0fiscper). In case the time dimension has inconsistencies it may happen that wrong restrictions are derived and the query displays wrong data (since the wrong partition is accessed). Please see note 568597 for further details. Queries on such providers always check the field TIMDIM_INCON. If it is set to true, no such derivation is carried out! This guarantees correct data, but it may lead to a performance decrease since the system doesn't have the information any longer which partitions have to be read (see example below).
  • Inventory Cubes: queries on cubes with non-cumulative key figures also check whether the field TIMDIM_INCON of the table RSMDATASTATE is set to true. If yes, the warning DBMAN 284 is displayed requesting the user to run the RSRV check. Inventory cubes need in general a consistent time dimension (see note 1548125) and hence for such cubes this problem has to be resolved. The repair function of RSRV can be used to correct the inconsistency.
  • 'Normal Basis Cubes': no action is required for BW systems < BW74. Nevertheless, an inconsistent time dimension may lead to problems and confusion when running queries. As of BW74 semantically partition providers (please see multiprovider pruning) may also use the time dimension to derive time restrictions. Hence, in genreal, the time consistency check is also relevant in this case.


  • in case queries on partitioned cubes display wrong(no) data please always check the time dimension in RSRV
  • due to program errors it may happen that the field TIMDIM_INCON isn't set correctly. Hence it may make sense to check this field explicitly in transaction SE16.
  • RepairMode: Only for Inventory cubes the system tries to correct the inconsistencies automatically (for such cubes its always guaranteed that the values for all time characteristcs can be derived from the value of the ncum 'time reference characteristic' - see also note 1548125). When running this function the system displays the proposal how to correct the affected data record of the time dimension (e.g. screenshot). In case the inconsistent records are not booked in the cube, the record is deleted in the repair mode (see aslo RSCV061). You can also run the check 'Unused entries in InfoCube dimension' and delete all unused records of the time dimension. In general, follow the descritpion of note 622450 to solve the inconsistency.
  • RSRV always offers to delete entries that are no longer in use from the time dimension table. Hence, inconsistent data records in the time dimension which are not used in the cube, can always easily be removed.
  • Data load: the 'Consistency Check' is always carried out when records are added to the time dimension (during loading). Due to performance reasons only the 'new' records are checked, if you want to check the entire time dimension you need to to this with transaction RSRV. Please note the following
    • up to BW73: only partitioned and inventory cubes are checked, only for invnetory cubes the loading process terminates in case of inconsistencies
    • as of BW74: 'normal' basis cubes are checked as well; if a inconsistency exists
      • partitioned cube ->  the loading process terminates with error message RSCV054 (DBMAN062); sreenshotRSCV054
        • in case the cube contains already inconsistent time relations
          • if TIMDIM_INCON = ' ' (no RSRV check done so far), data can be loaded without errors(see above)
          • if TIMDIM_INCON = X, the loading process terminates with the error RSDD551 (scrennshotRSDD551)
      • normal basis cubes ->  field TIMDIM_INCON is set to X
      • inventory cube -> since in this case the entries of the time dimension are derived from the value of the time reference characteristic, an inconsistency should actually never occur. If it happens, the loading process terminates
    • see also note 2314464 - Loading process terminates since time characteristic consistency check found errors 
  • in case a consistent time dimension is needed it may be necessary to delete the content (or some requests) of the cube (with entries in dimension) and then reload the data.  In general, follow the descritpion of note 622450 to solve the inconsistency.
  • if you repair the time dimension by hand, you need to run the RSRV check afterwards in order to update the field TIMDIM_INCON again.
  • in case e.g. a cube is partitioned regarding calmonth, the fact tables get an additional column where the SIDs of calmonth are stored (name of the field: SID_0CALMONTH; only the E-table gets partitioned!). Only restrictions regarding this column can be used by the data base in order to access the right partitions. If the characteristic calmonth is filtered in the query the system can easily determine the corresponding restriction for 'SID_0CALMONTH'. However, if e.g. the query is restricted to days then the DataManger has to derive the corresponding months: e.g. (01.03.2012 - 15.05.2012) -> (03.2012-05.2012). As mentioned above, if TIMDIM_INCON=X, such kind of derivations are not done and the data base needs to scan all partitions. Hence, in general its important for partitioned cubes that the time dimension is consistent. See also See also  Query Pruning.
  • You can set RSADMIN parameter RSDD_PARTITION_ALLOW_TIM_INCON as explained in SAP note 2289880 in oder to avoid the termination(error RSDD551) of the loading process (correction of SAP note 2325103 needs to be implemented as well). However, this is not the recommended option (see SAP note 2289880) and should only be used in exceptional cases!
  • BW based on HANA: a HANA optimized InfoCube does not support the feature 'Partitioning' (E-table Partitioning) any longer. Hence, if you convert a partitioned Infocube to a Hana optimized cube, the partitioning is removed. This also implies that the loading process does not terminate any longer in case of records with inconsistencies regarding the time characteristics.

SAP Notes

  • 2314464 - Loading process terminates since time characteristic consistency check found errors 
  • 2325103  Partitioned cubes with inconsistent time dimension
  • 622450   - DBMAN284 with queries; RSRV check of time dimension negative
  • 1977449 - Loading processes in InfoCubes terminate with errors in time consistency check
  • 1772036 - Inconsistent Time Dimensions
  •  2289880 - Allowing time dimension inconsistecy for partitioned cubes

SAP Online Documentation


Classic and 'advanced' DataStore Objects


In case BW is based on Hana, you can create advanced DataStore Objects (ADSOs) with database partitions. If the partitions are defined regarding a time charcteristic we have a similar situation as with a partitioned InfoCube. Although an ADSO does not have a Time Dimension, the consistency between the values of different time characteristics plays the same role as for partitioned cubes and can also be checked in RSRV:

If inconsistencies are found, the following field is uptaed:

  • table RSOADSOLOC
  • field TIME IS CONS  = ' ' (means that ADSO is inconsistent)

If you load inconsistent records into such a ADSO, the loading process does not terminate but the following warning is written into the log

  • Time inconsistency found in package. Property reset for DataStore.
  •  Message no. RSDSO_UPDATE005

As a consequence, as for Cubes, a query does not use any time derivation in order to determine the affected partitions. See also  Query Pruning.

Classic DSO

The situation is basically the same as for ADSOs. It is possible to load records with inconsistent time values into a partitioned DSO, but then the following field is set to ' '

  • ODS TIME CONS = ' ' (means that DSO is inconsistent)

and a query does not use any time derivation in order to determine the affected partitions.


There is no Pruning done for a PartDSO(of an HCPR) with inconsistent 'time dimension': 

Example P8: report RSPP_PART_MAINTAIN - HCPR with two DSOs; Discussion of 'Time Derivation of Time Restrictions' 



  • No labels