Aggregation Recommendations

• When defining the Aggregation Horizon for aggregation processing, the horizon should ideally be around 7 days or less (barring specific requirements that call for an longer horizon, such as in the case of some final settlement calculations).

  For each day in the horizon the system aggregates each day that many times. For example, setting the Aggregation Horizon to 30 means that each day is aggregated 30 times. The benefit of aggregating a day multiple times is that each day the quality of the data could improve if initial measurements arrive late. However there is a cost associated with a large horizon because the system is aggregating a much larger set of measurement data to catch a statistically smaller amount of changes the further into the past a day is.

• A short Aggregation Horizon is recommended in particular when configuring Measurement Quality and Timeliness aggregations used with Oracle Utilities Analytics Visualization. Refer to Configuring Timeliness and Quality Aggregation for Use with Oracle Utilities Analytics Visualization for more information.

  The Aggregation Horizon is defined on Master Measurement Aggregator Type (D2-MasterMsrmtAggregatorType).

• Dynamic Aggregation is intended to combine large populations of measuring components, devices, service points, or usage subscriptions into substantially fewer aggregation measuring components. Detailed aggregation, such as at the service point or usage subscription level, is supported for small populations but does not scale to large ones, and is generally not recommended.

  Each foundation or composite layer creates and stores its own measuring components and measurements. Before deployment, estimate the number created at each layer; configurations approaching the source population size can duplicate large volumes of data and cause excessive scanning, processing, storage, and re-aggregation.