Log files

If you have a consolidation that does not run as desired, first obtain a log file. Then, inspect each of the lines listed below, and compare the time for each line to the total consolidation time (the elapsed time line). If the line in question represents a significant portion of the total time, take the specified action:

• foundDatatime (SelectFirstNode portion)

  If most of the time is spent in foundDataTime (SelectFirstNode portion), then it is probably an index problem. If the database is Oracle, be sure the SQLHintsAllowed parameter is set to 1 (default).

• foundDatatime (Total)

  If the total for foundDataTime is large but the above SelectFirstNode portion is small, then reduce the value of the CrossProductThreshold parameter to improve the data retrieval efficiency in the consolidation engine.

• WriteBack time

  If most of the consolidation time is spent on the Writeback time line, it is probably an index problem. The Writeback time line reveals if the consolidation was a worst-case scenario in terms of inserts vs. updates. Inserts take longer but are only done the first time leaf data is consolidated for a given subcube. If there are many inserts, you can expect subsequent consolidations of the same subcube to take less time.

• #cr:

  If this number is greater than 1, try increasing the value of the MaxOSRCacheRecords parameter from its default value.

• SelectDataPoint

  If most of the time is spent in SelectDataPoint, there are probably too many off-sheet references. Off-sheet references are (1) references to lines in other schedules and (2) cross-dimensional references ("of" clauses). To resolve this problem:

  • Reorganize schedules so that formulas only reference other lines on the same schedule. This can mean building a super-schedule that includes the lines from several schedules and is only used for consolidation.
  • Minimize the number of cross-dimensional references in the formulas.
  • Simplify formulas as much as possible.