Note 1008833 supplementary sap note about repartitioning

SAP Note 1008833 - Supplementary SAP Note about repartitioning Note Language: English Version: 15 Validity: Valid Since 08.04.2009 Summary Symptom You want to subsequently change or introduce the partitioning of InfoCubes. Clarification: When changes to partitioning are mentioned in this note and other notes concerning repartitioning, they are always referring to the E table of a SAP BW InfoCube, and not the F table of the particular SAP BW InfoCube. Only the partitioning of the E table can be changed, not that of the F table. Therefore, for safety, only the partitioning of the E table of a BW InfoCube is changed, and not that of the F table. Other terms Repartitioning, partitioning, fragmentation, multidimensional clustering (MDC), InfoCube, database (DB), storage parameter, E table, not the F table Reason and Prerequisites BI 7.00 Solution Background SAP BI supports the partitioning (fragmentation in Informix, MDC in IBM DB2 for UNIX, Linux and Windows) of InfoCubes to improve the runtime during read and delete operations on the database. On Oracle and MSSQL, the F fact table is always partitioned dynamically using the package dimension. The partitioning of the E fact table is static and it can be done using the maintenance interface before you activate the InfoCube. You can select calendar month or fiscal period as the partitioning criteria. The master data IDs (SIDs) of these two partitioning characteristics are added to the two fact tables as additional columns and are filled according to the entries in the time dimension when you load new data requests. Since the fiscal variant influences the fiscal period, the E fact tables should only be partitioned if the fiscal variant for the InfoCube is set to a constant value. If data has already be uploaded, you can no longer change the partitioning properties of an InfoCube using the maintenance interface. However, due to the following reasons, you may need or prefer to make changes: 1. Partitioning has become available for the database used. You therefore want to partition existing InfoCubes subsequently so that you can benefit from the advantages of partitioning for the existing data set (complete repartitioning). 2. Partitioning is already used, but you want to adjust it because the 26.08.2010 Page 1 of 8

SAP Note 1008833 - Supplementary SAP Note about repartitioning original partitioning schema no longer meets your requirements. For example, there may now be too much data in a partition because data growth has increased over time (complete repartitioning). 3. The time period for partitioning is too small. When you activate an InfoCube, partitions are created for the time period January 2000 to December 2006, for example. To ensure that data for 2007 is not only gathered in the overflow partition, you want to extend the partitioning schema until December 2007 (adding partitions). 4. Several partitions contain no data records, or very few data records. When you activate an InfoCube, partitions are created for the time period January 2000 to December 2008, for example. At the end of 2006, the data for 2000 and 2001 is archived. To ensure that the empty partitions for 2000 and 2001 do not unnecessarily increase the database system catalog, these partitions should be merged in an underflow partition (merging partitions). To meet these requirements, as of SAP BI 7.00 we provide a tool that you can use to repartition InfoCubes. Basically, we differentiate between three types of repartitioning: a) complete repartitioning, b) adding partitions to an E fact table that is already partitioned and c) merging empty or almost empty partitions of an E fact table that is already partitioned. Unlike complete repartitioning, in which the data from E or F fact tables must be completely copied and converted, the actions 'add partitions' and 'merge partitions' involve only a sequence of database catalog operations if there is no data in the overflow partition yet or if the partitions to be merged are empty. The runtime for these database catalog operations is just a few minutes. Complete repartitioning always requires additional disk space, in line with the size of the InfoCube that you want to repartition. Since data is physically copied, new indexes created and table statistics calculated, this action may take several hours, depending on the size of the InfoCube. Complete repartitioning is suitable for general use and you can use it both for creating partitions for the first time and for adding and merging partitions. The partitioning of InfoCubes is a system-local property that cannot be transported for the following reasons: 1. It is usually better to use another partitioning in the production system with a lot of data than in the development system with a small quantity of data since partitioning can be counterproductive with a small quantity of data. 2. Making changes to partitioning usually leads to a reorganization of the fact tables. That means that all data records must be copied. Since the runtime on the database is directly proportional to the size of the InfoCube in the target system and can take several hours, you should schedule and execute such actions at a time when the system load is low, for example on the weekend. Otherwise the runtime behavior of the whole production system may be impaired significantly. 3. During the reorganization, all data records are copied, indexes are rebuilt and database statistics are calculated. Additional disk space is also required and this may not be available. This can cause terminations. 26.08.2010 Page 2 of 8

SAP Note 1008833 - Supplementary SAP Note about repartitioning 4. During the reorganization, the InfoCubes in question are always locked against all modifying actions (loading data, deleting data, compressing, rolling up into aggregates, creating aggregates, change runs and so on) since this is the only way to guarantee data consistency. You should schedule these 'down-times'; they should not simply occur accidently by transports. 5. A transport request to the production system could unintentionally cause partitioning to change. For example: Person A changes the partitioning of InfoCube CUBE in the development system but does not write this change to a transport request since he knows what this will mean for the production system. Person B attaches another key figure to the same InfoCube (CUBE) and writes the InfoCube to a transport request so that the change is active in the subsequent systems. This transport request to the production system would then cause the partitioning to change without Person B who triggered the transport being fully aware of the consequences. Changes to the partitioning of InfoCubes using a transport are only transferred if InfoCubes in the target system do not contain any data. Although this behavior constitutes a break in the concept of the 'system-local properties' of partitioning, BI administrators should allow all settings to be distributed among the system landscape when an InfoCube is recreated. If an InfoCube already exists in the target system and does not contain any data, both fact tables of the InfoCube are deleted during the import and they are recreated according to the new description, including the changed partitioning. Up to BI 7.00 Support Package 12, you must not transport repartitioning, otherwise inconsistencies will occur in the target system. Only as of BI 7.00 Support Package 13 is activating changed partitioning properties for InfoCubes that are already filled in the target system automatically prevented. Always execute partitioning individually with identical parameters in each system of the system landscape. Your production system must be set to 'Changeable' to do this. This procedure does not comply with the concept that only consolidated changes may be transported to the production system. However, due to the problems mentioned above that can occur by automatically activating changed partitioning properties in the production system, local processing of partitioning properties is currently optimal. Below, we describe the complete repartitioning of InfoCubes in detail. The chapters also contain a list of known problems that occur during repartitioning and references to the relevant correction notes. Complete repartitioning To partition InfoCubes, the fiscal variants (if they are used in the InfoCube), must be set to a constant value. For empty, inactive InfoCubes, you can do this in the maintenance interface using transaction RSA1. If data has already been loaded to the InfoCube, you can no longer change it 26.08.2010 Page 3 of 8

SAP Note 1008833 - Supplementary SAP Note about repartitioning in the maintenance interface. You should then use program RSDU_SET_FV_TO_FIX_VALUE to set the fiscal variant to a fixed value, provided all data records loaded to date are assigned to just one fiscal variant. If this is not the case, subsequent partitioning is not possible. Program RSDU_SET_FV_TO_FIX_VALUE is first delivered with Support Package 13. Complete repartitioning is, for the most part, independent of the database platform used. The processing steps described below are therefore database-independent. If there are special features for different database platforms, these are explained within the individual processing steps. a) CREA_SHD_EFACT Create an empty shadow table for the E fact table. The empty shadow table already has the structure of the E fact table after repartitioning. It contains an additional column for the partitioning characteristic, if it does not already exist, and the required table partitions. The naming convention for the shadow table is /BI<x>/4E<infocube>. b) CREA_SHD_FFACT Create an empty shadow table for the F fact table. The empty shadow table already has the structure of the F fact table after repartitioning. It contains an additional column for the partitioning characteristic, if it does not already exist, and the necessary table partitions. The naming convention for the shadow table is /BI<x>/4F<infocube>. c) SPACE_CHECK Check if there is sufficient free disk space to execute the repartitioning. This step is only necessary on some database platforms, as the memory space is allocated dynamically on most database platforms. d) COPY_TO_SHD_EFACT Copy the data records from the E fact table /BI<x>/E<infocube> to the shadow table /BI<x>/4E<infocube>. Copying occurs in several parallel processes using disjunct values in the time dimension column. e) COPY_TO_SHD_FFACT Copy the data records from the F fact table /BI<x>/F<infocube> to the shadow table /BI<x>/4F<infocube>. Copying occurs in several parallel processes using disjunct values in the package dimension column. f) CREA_IDX Create an index on both shadow tables. g) SET_READ_LOCK 26.08.2010 Page 4 of 8

SAP Note 1008833 - Supplementary SAP Note about repartitioning Set a read lock for the InfoCube because as of now, correct results during reading can no longer be guaranteed. h) INA_AGGR Deactivate all aggregates for the InfoCube. i) DELETE_FACTVIEW Delete the view of E and F fact tables. j) CHECK_EFACT Check if data records have been completely copied from the E fact table to the corresponding shadow table /BI<x>/4E<infocube>. k) CHECK_FFACT Check if data records have been completely copied from the F fact table to the corresponding shadow table /BI<x>/4F<infocube>. l) SWITCH_EFACT (critical processing step) Replace the E fact table with the corresponding shadow table /BI<x>/4E<infocube> and rename the indexes. For this, the original E fact table /BI<x>/E<infocube> is first renamed to temporary table BIC/01..<number>. Then the shadow table /BI<x>/4E<infocube> is renamed to table /BI<x>/E<infocube> and the temporary table /BIC/01..<number> (formerly original E fact table) is renamed to the shadow table. This ends the processing step and once again, there are two tables. Table /BI<x>/E<infocube> now has the new structure and table /BI<x>/4E<infocube> has the original structure. If terminations occur during this processing step, this may result in inconsistencies. Therefore, this processing step has been classified as critical and cannot be reset. If terminations do occur, you should always send a message to SAP and we will correct error situations manually. Using the wrong corrective measures in this case could result in a loss of data. m) SWITCH_FFACT (critical processing step) As for SWITCH_EFACT, but for F fact tables. n) CREA_FACTVIEW Create the views of the E and F fact tables. o) POST_ACT Adjust the BW meta data, activate the update rules, generate and activate the load program. p) REPA_IDX Check if all indexes were created correctly. Missing or incorrect indexes are recreated or repaired. 26.08.2010 Page 5 of 8

SAP Note 1008833 - Supplementary SAP Note about repartitioning q) ANALYZE Calculate database statistics for E and F fact tables. r) RELEASE_READ_LOCK Release the read lock. When you do so, the InfoCube is available for reporting again. s) Cleanup Various clean up operations. The shadow tables /BI<x>/4F<infocube> and /BI<x>/4E<infocube>, as the original fact tables are now called, are not deleted automatically, so that they can be reset and analyzed if errors occur. You can reset a repartitioning request without any problems in the processing steps before SWITCH_EFACT, because up to this point, you are only working on shadow tables and aggregates. Inactive aggregates and the view of E and F fact tables must be reactivated if necessary. The processing steps SWITCH_EFACT and SWITCH_FFACT are critical and if errors occur, they must be corrected manually by SAP Support. It is therefore not possible to reset these processing steps. After processing step SWITCH_FFACT, the fact tables have the target structure, however the BW meta data has not yet been adjusted. Therefore, as of the processing step CREA_FACTVIEW, you should only recover forwards. After processing step POST_ACT, the BW metadata is consistent with the new structure of the fact tables. The subsequent processing steps are not critical and you can execute them manually if necessary. You can reset or delete the repartitioning request, however it does not make sense to do so at this point because the repartitioning is almost complete. Starting the background job for repartitioning: You normally start the repartitioning from the BW Admin Workbench (Data Warehousing Workbench) using the context menu; under the additional functions, you choose repartitioning. Alternatively, you start the program RSDU_REPART_UI. On the screen that is then displayed, enter the InfoCube name and choose the required type of repartitioning. When you choose "Initialize", the system asks you whether the InfoCube was saved in a backup. Afterwards, the system starts the parameters for the relevant partitioning and issues the dialog box with which the background job is scheduled. The program RSDU_REPART_UI does not execute the repartitioning. This program only controls the process. It is therefore not useful to schedule RSDU_REPART_UI for background processing. The "Execute" pushbutton for RSDU_REPART_UI is also displayed in the monitor because this is the most sensible location. After background processing is started, RSDU_REPART_UI is mainly used to access the monitor, where you can monitor the repartitioning that runs in the background. Corrections 26.08.2010 Page 6 of 8

SAP Note 1008833 - Supplementary SAP Note about repartitioning o DB2 on z/OS If you use DB2 on z/OS, see Note 946641, which describes the particular features for this platform. o DB2 on UNIX, Linux and Windows If you use DB2 on UNIX, Linux or Windows, see Note 1019826, which describes the particular features for this platform. DB2 for UNIX, Linux and Windows uses multi-domensional clustering (MDC). On this database platform, complete repartitioning is called 'reclustering'. Adding or merging partitions is not necessary if you are using MDC, therefore this is not offered. o MS SQL server If you use an SQL Server database and you have a Support Package level lower than Support Package 9, you must implement Note 943088 to allow you to use the repartitioning tool. You must also implement the corrections from Note 1006262 if you have a Support Package level lower than Support Package 12 and SQL Server. Removing partitions by deselecting all partition columns is not currently supported on SQL Server. This function is provided in one of the next Support Packages and in the form of correction instructions. Note 1006262 o All database platforms. Note 951380 up to and including Support Package 10. Note 998902 up to and including Support Package 13. Note 949479 up to and including Support Package 07. Note 999064 up to and including Support Package 10. Note 1047903 up to and including Support Package 13. Header Data Release Status: Released for Customer Released on: 08.04.2009 07:38:56 Master Language: German Priority: Recommendations/additional info Category: Help for error analysis Primary Component: BW-SYS-DB BW Database Platforms 26.08.2010 Page 7 of 8

SAP Note 1008833 - Supplementary SAP Note about repartitioning Valid Releases Software Component Release From To and Release Release Subsequent SAP_BW 70 700 700 Related Notes Number Short Text 1277442 No new data after repartitioning (SID field is empty) 1029254 Repartitioning terminates at step CHECK_EFACT 1019826 DB6: Supplementary note about repartitioning (reclustering) 1019728 MSSQL: Supplementary note about repartitioning: Merging 1019725 MSSQL: Supplementary SAP Note for repartitioning: Amendments 1016185 ORA Repartitioning: Merging partitions 1016184 ORA repartitioning: Attaching partitions 1013912 FAQ: Oracle BW performance 1006262 Repartitioning job fails in step SWITCH_EFACT 949479 Repartitioning job is canceled in step POST_ACT 946641 DB2-z/OS: BW: Repartitioning composite SAP note 943088 Repartitioning feature is not accessible from RSA1 815186 System i: Table partitioning in BW 26.08.2010 Page 8 of 8

http://itpe.me	11
http://www.itpe.me	4
http://neoni0106.tistory.com	1

Note 1008833 supplementary sap note about repartitioning

by Donghoon Woo on Aug 26, 2010

Accessibility

Upload Details

Usage Rights

3 Embeds 16

Statistics

Note 1008833 supplementary sap note about repartitioning — Document Transcript