Repartitioning

Merging and Adding Partitions

When you merge and add partitions, DataStore object partitions are either merged at the bottom end of the partitioning schema (merge), or added at the top (split).

Ideally, this operation is only executed for the database catalog. This is the case if all the partitions that you want to merge are empty and no data has been loaded outside of the time period you initially defined. The runtime of the action is only a few minutes.

If there is still data in the partitions you want to merge, or if data has been loaded beyond the time period you initially defined, the system saves the data in a shadow table and then copies it back to the original table. The runtime depends on the amount of data to be copied.

Complete Partitioning

When complete partitioning is performed, the tables of the DataStore object are completely converted. The system creates shadow tables with the new partitioning schema and copies all of the data from the original tables into the shadow tables. As soon as the data is copied, the system creates indexes and the original table replaces the shadow table. After the system has successfully completed the partitioning request, the tables exist in the original state (shadow table), as well as in the modified state with the new partitioning schema (original table). You can manually delete the shadow tables after repartitioning has been successfully completed to free up the memory. Shadow tables have the namespace /BIC/4F<Name of DataStore object> and /BIC/4E<Name of DataStore object>.

Monitoring

You can monitor the repartitioning requests using a monitor. The monitor shows you the current status of the processing steps. When you double-click, the relevant logs appear. The following functions are available in the context menu of the request or editing step:

• Delete: You delete the repartitioning request. It no longer appears in the monitor and you cannot restart. All tables remain in their current state. The DataStore objet may be inconsistent.

• Reset Request: You reset the repartitioning request. This deletes all the locks for the DataStore object and all its shadow tables.

• Reset Step: You reset the canceled editing steps so that they are reset to their original state.

• Restart: You restart the repartitioning request in the background. You cannot restart a repartitioning request if it still has status Active (yellow) in the monitor. Check whether the request is still active (transaction SM37) and, if necessary, reset the current editing step before you restart.

Background Information About Copying Data

By default, the system copies a maximum of six processes in parallel. The main process splits dialog processes in the background. These dialog processes each copy small data packages and finish with a COMMIT. If a timeout causes one of these dialog processes to terminate, you can restart the affected copy operations, after you have altered the timeout time. To do this, choose Restart Repartitioning Request.

Background Information About Error Handling

Even if you can restart the individual editing steps, you should not reset the repartitioning request or the individual editing steps without first performing an error analysis.

During repartitioning, the relevant DataStore object is locked against modifying operations to avoid data inconsistencies. In the initial dialog, you can manually unlock objects. This option is only intended for cases where errors have occurred and should only be used after the logs and datasets have been analyzed.

Transport

Since the metadata in the target system is adjusted without the DB tables being converted when you transport DataStore objects, repartitioned DataStore objects may only be transported when the repartitioning has already taken place in the target system. Otherwise inconsistencies that can only be corrected manually occur in the target system.