ILM - Partition Key Turnaround

The system executes a Partition Key Turnaround when the maximum RunID of tasks or statistical records is reached. How quickly this limit is reached depends on the number of tasks that start regularly. Automation Engine systems with a low number of regularly executed tasks rarely reach this limit. Systems with many daily activities (approximately 1,000,000) reach the limit after a few years.

This page includes the following:

Overview

Statistical entries for executed tasks are stored in the AH table. The corresponding RunIDs are also included in the AH_Idnr column. This column stores 32-bit values up to a maximum value of 2,147,483,647.

Note: The permitted range of RunIDs of statistical records is 1,000,000 through 2,147,483,647. Values below 1,000,000 are reserved for specific processes.

When you install ILM while setting up your AE, the complete database is used as the first partition P1. However, P1 does not use the logical minimum 0 because the minimum value for RunIDs is 1,000,000.

When you switch to ILM in an existing AE system, all existing data, such as static entries in the AH table, are stored in P0 before creating the partition P1. P0 behaves as any other partition that is dropped (Oracle) / switched out (MS SQL) and is archived.

Example

P0 containing all data prior to ILM and P1 with range up to the maximum.

Working with Partitions

As a system administrator, you use the parameter ONLINE_PARTITIONS in the UC_ILM_SETTINGS variablewith ILM to determine how many online partitions are available in the database. Partitions that are not being used are limited by a maximum key value. The partition currently being used is not limited and uses a virtual value that is database-specific:

  • MS SQL: NULL
  • Oracle: MAXVALUE

Changing a partition implies that a new partition is inserted in the (virtual) upper limit of the current partition, and that the oldest partition is deleted.

Note: In Oracle, you can directly delete the partition. The MS SQL Server requires a staging table for this purpose.

The system checks the maximum RunID of the partition currently being used and multiplies it by the value that is specified in the PARTITION_SIZE_MULTIPLICATOR parameter in the UC_ILM_SETTINGS variable. If the database has enough space available, the system performs a partition change. If the result of the calculation exceeds the limit of the database, the system automatically activates the Partition Key Turnaround mode.

For more information, see UC_ILM_SETTINGS - Settings for Partitioning with ILM.

Changing Partitions

You have been working with a partition and want to change partitions. To create the new partition, the system checks the highest RunID in the current partition and multiplies it by the value that you specified in the PARTITION_SIZE_MULTIPLICATOR parameter in the UC_ILM_SETTINGS variable. This behavior continues for every partition change. For more information, see UC_ILM_SETTINGS - Settings for Partitioning with ILM.

Example

Note: For the sake of clarity, the minimum RunID value of 1,000,000 is not considered.

In this example, the parameter PARTITION_SIZE_MULTIPLICATOR is set to two (2).

Example of creation of a fifth partition by multiplying the highest RunID of the current partition by two.

  • P1

    269,125,000

  • P2: P1*2

    Highest RunID in P1=269,175,000

    P2=538,350,000

  • P3: P2*2

    Highest RunID in P2=403,725,000

    P3=807,450,000

  • P4: P3*2

    Highest RunID in P3=538,725,000

    P4=1,077,450,000

Changing partitions again is not possible because the space required to create partition P5 exceeds the limit of the database. In this case, the key turnaround mode is activated and older partitions are dropped/switched out to make space for the new partition.

Dropping (Oracle) / Switching Out (MS SQL) Partitions

Dropping/switching out partitions is necessary to use the key turnaround mode. The system drops/switches out older partitions to make space in your database for the new ones, according to the settings of the UC_ILM_SETTINGS variable. For more information, see UC_ILM_SETTINGS - Settings for Partitioning with ILM.

Different databases handle this in different ways:

  • Oracle: When you drop a partition, all data records available in the partition are removed from your system. Thus, the partition is deleted permanently.

  • MS SQL: When you switch out a partition, the data is archived in the database, not deleted. However, you need to restore the partition to have access to the data after the partition has been switched out.

    You can Check and Drop/Switch out a partition directly from the Partitions list in the Administration perspective. For more information, see Managing ILM Partitions.

Important! It is recommended to backup your data before dropping/switching out a partition, thus allowing you to restore a partition at a later point in time, if required.

Example

P1 is dropped and the space is lost.

Partition P1 is the oldest partition and it is the first to be dropped/switched out. Therefore, the space used by P1 is now unused and that P2 is bigger than before. However, in the IPH table, the minimum RunID for P2 is still 269.125.000.

Partition Turnaround

When the turnaround mode is active, the new partition is inserted in the lower number range (starting with 1,000,000) and RunID numbering starts from the beginning. The turnaround mode remains active until all partitions that include the upper number ranges are removed and a constant value range from up to 2,147,483,647 is available again.

Example

Note: For the sake of clarity, the minimum RunID value of 1,000,000 is not considered.

In this example, the parameter PARTITION_SIZE_MULTIPLICATOR is set to two (2).

Partition P7 is active. Partitions P1, P2, and P3 have been dropped/switched out and partitions P4, P5, and P6 are online. P4 seems to be bigger than before but, in the IPH table, the minimum RunID for P4 is still 807,450,000. The space before P4 is unused at the moment. Before changing to the next partition and creating P8, the system checks if the turnaround mode must be activated.

Not enough space after checking for turnaround before changing partitions to P8.

The database space that remains is not large enough for the new partition P8. To accommodate P8, the system splits the oldest partition P4 at its minimum RunID 807,450,00. As a result, the space that was unused is now free to accommodate the new active partition P8. The database space after P7 that was not large enough for P8 is lost until P7 is dropped/switched out.

P8 is active. The space after P7 is unused.

After the turnaround, the same behavior applies. To change partitions, the oldest partition is dropped/switched out and split to get unused space.

The oldest partition P4 is dropped and split.

The unused space available after dropping/switching out the oldest partition becomes a temporary partition until the active partition is merged into it.

The unused space available after dropping P4 is a temporary partition.

After they have been merged, they both use the name of the active partition.

The active partition P9 is merged into the temporary partition and both become P9.

This pattern repeats itself when P7 is dropped/switched out. However, because the maximum RunID of P7 is the same as the highest RunID allowed in the database, the new partition P12 created when P7 is dropped/switched out also has the highest value allowed.

The partition with the highest RunID possible is dropped.

The unused space after P7 becomes a temporary partition.

The unsued space after dropping the partition with the highest RunID possible becomes temporary partition.

P12 is merged into the temporary partition and both become P12 with a maximum RunID value equal to the maximum RunID allowed in the database.

Active partition is merged into temporary partition and has the highest RunID value allowed in the database.

See also: