LOGGING for }StatsBy Control Cubes

[Adam]

I was debugging some rules in dev and I find a nice fat 32Mb tm1s.log with thousands of line items for }StatsByCube and }StatsByRule, etc.

My dev box:
-- PA 2.0.9.1 (TM1 Build Number: 11.8.00000.33)
-- PerformanceMonitorOn=T
-- In }CubeProperties, I have
---- LOGGING set to YES for non-control cubes, and have blanks for control cubes
---- RULE_STATS set to YES for non-control cubes, and have blanks for control cubes

IBM Documentation makes it seem like a blank is a NO but should I be explicitely putting NO for my }StatsByX control cube to prevent unnecessary transaction logging? Is this a new default for 2.0.9.1?

Appreciate your thoughts in advance. Thanks!

[tomok]

Unless IBM has changed something recently then blank means YES for logging purposes.

[Adam]

tomok, thank you!

If a blank means YES for logging purposes, then it's doing what is intended.

By the way, would you say it's a good practice to set any control cube, esp. }StatsByX to NO for logging?

[tomok]

I can't think of any reason why you would want to log the activity in the {StatsXXX cubes because they are already set up to capture history. As to the other control cubes it depends on what type of activity you want to be able to track. I generally have logging set to YES for control cubes.

[Wim Gielis]

Control cubes like }ElementAttributes: I usually have logging turned on but when TI processes update a lot of attribute values, I tend to turn off logging while the process is running.

I never log stats cube values and most of the time I use them when I need to investigate a certain performance issue.

[scrumthing]

I generally have logging set to YES for control cubes.

I agree. There are so many things in control cubes of which I want to keep track. But the stats cubes are not. There you definitely need no logging.

[Steve Rowe]

On the logging for the stats cube it can be very useful to have the logging on in specific circumstances.

If you are trying to track an issue or a specific event over a long time period and want granular stats then you can do some nice analysis from the transaction log by just taking the information from the LATEST reference on the time interval dimension. This extra granularity also allows you to cross reference the stats cube information with other events in the message log or external events.

This provides greater utility than the stats cube itself as the time interval dimensions granularity decreases the older the data.

You do need to make sure you have plenty of disc space available though.

[Wim Gielis]

You can easily export the data: viewtopic.php?t=15342