Performance and availability history table partitioning
This topic describes history partitioning for performance and availability history data processes for DB2 LUW and Oracle EE with the Oracle Partitioning option. This feature is not available for Microsoft SQL Server.
Due to its table and index partitioning feature, it is recommended that the Enterprise Server Edition of DB2 LUW 9.7 or later be installed when using native partitioning.
To enable partitioning, you must contact BMC Support to receive a script that converts the tables created by default to partitioned versions. Only after running this script does partitioning work properly. Do not attempt to configure partitioning without first contacting BMC Support.
TrueSight Middleware and Transaction Monitor (TMTM) can use native partitioning features of DB2 v9 ESE. To enable partitioning, modify the TMTM History Service parameters in services.cfg to configure the number of partitions you would like to use. Partitioning should be considered by installations that plan to collect large amounts of performance and availability history data.
There are four parameters that affect partitioning:
The total number of partitions is determined by the following formulas. The maximum number of partitions should not exceed 32000 for DB2 LUW and 1000000 for Oracle. The total number of partitions is per table.
Set a value for amount_of_hires_per_partition for high resolution history partitioning, and/or set a value for amount_of_lowers_per_partition for low resolution history partitioning. The partitioning is on the hddatetime column. A value of zero for either parameter turns partitioning off.
The values can be expressed in hours or days (for example: 10H, 10D, 10d, 10h), but each partition is partitioned to hold a certain number of hours. The name of the partition indicates the upper boundary for the value in the column hddatetime for that partition. The base partition is always 2001010100.
The table below is a partitioned high resolution history table storing four hours in each partition (amount_of_hires_per_partition=4H).
The table below is a partitioned low resolution history table storing one day in each partition (amount_of_lowres_per_partition=1D).
Because partitions are added and dropped, the TMTM user requires the authority to do so. There is no process within TMTM to migrate nonpartitioned history data to partitions.