Introduction
Custom aggregation allows the user to aggregate the existing instance data in custom manner and expose this data to BAM Reporting services (PRS) users.
BAM Implementation guides for D6.6 (and earlier) provides the instructions for building custom aggregations that are tied to the specific scheduler job according to the desired time granularity (i.e. 5m, QH, HH, H, D, W, M, Q, Y). For example a custom daily aggregation will be tied to "AggrCustomD" job. In case of problem with one of the custom aggregations in this implementation the entire batch of custom aggregations for cretain time granularity and also hanging of all dependent (child) aggregations will stop working.
The problem
All custom aggregations for certain period of time are executed by BAM server in single transaction, i.e. if two custom daily aggregations (CA1_D, CA2_D) have been defined they will be associated with single scheduler job called "AggrCustomD". The scheduled job executes ALL aggregations in one single database transaction. Prior to exiting each scheduled job updates its timestamp (so-called LAST_PIPE_RUN) in the databse in order to continue its next iteration from that point in time. As result of that once an issue happens in one custom aggregation (incorrect syntax, data integrity violation, DB lock, etc.) the entire "AggrCustomD" job will stop working (i.e. will not move its LAST_PIPE_RUN forward)
Solution (Best Practice)
Follow this link
