Cube logging: what's not a good idea?

[image2x]

Recommendations on what control cubes should not be set for logging?

Thanks,
-- John

[Alan Kirk]

Recommendations on what control cubes should not be set for logging?

Depends on your needs.

The only hard and fast rule IMHO is never, EVER log the four }Stats cubes which are used by Performance Monitor. They will bloat the log file by literally gigabytes if you let them. If you need to keep the data from those cubes, periodically snapshot it to a text file with a TI and ASCIIOutput.

Other than that I'd tend to use the same rule of thumb as I use for data cubes. If I'm repeatedly blowing away data and refreshing it from scratch, I'd have logging turned off. Suppose for example that you have a seriously long Customers dimension and, for whatever reason, you were deleting all of the attributes every night and refreshing them from your CRM system. That could well be a candidate for having logging turned off though even then I'd probably only turn it off for the life of the TI that does the updating. At least that way you can still see if someone is stuffing around with the attributes manually during the day.

I haven't looked at the newer control cubes in 9.4+ in any great detail yet so there may be some others that I've yet to discover, but in general I don't see any reason to turn logging off for most control cubes; in most models they probably don't change often enough to cause log file bloat, and the logging helps identify any security gaps that you may have with regard to access to the cubes.

[image2x]

Thanks Alan. That seems like reasonable advice.

[jim wood]

An add on to Alan's point. Putting logging on the stats cube also increases the chances of a crash. As you may have seen from my post a write failure to the log files causes the software to go down. You may also want to consider this for your busiest cubes,

Jim.

[Martin Erlmoser]

everything but stats cubes and cubes which contain temp data

[Kyro]

I reccomend a simple rule.
"Try use cube logging only to capture user input, because thats all you'd ever want to restore."

Anything else data wise is typically TI (which can be reloaded) or rules (Which dont 'dissapear' anyway).

[belair22]

I reccomend a simple rule.
"Try use cube logging only to capture user input, because thats all you'd ever want to restore."

Anything else data wise is typically TI (which can be reloaded) or rules (Which dont 'dissapear' anyway).

Assume you mean LOGGING ON as default and then you logging switch LOGGING OFF during TI data loads?

Personally I'm not a fan of toggling LOGGING OFF during TI's - there's always a small chance a TI might bomb out part way through or a user may tip over the server - potential for that LOGGING to remain OFF and you may be none the wiser.

[Kyro]

As always it depends on the implementation. I've had allocation processes that take three days to run go to 3 hours just by disabling logging.

[Alan Kirk]

I reccomend a simple rule.
"Try use cube logging only to capture user input, because thats all you'd ever want to restore."

Anything else data wise is typically TI (which can be reloaded) or rules (Which dont 'dissapear' anyway).

Assume you mean LOGGING ON as default and then you logging switch LOGGING OFF during TI data loads?

Personally I'm not a fan of toggling LOGGING OFF during TI's - there's always a small chance a TI might bomb out part way through or a user may tip over the server - potential for that LOGGING to remain OFF and you may be none the wiser.

If you're refreshing a GL cube from the GL system every 15 minutes you could end up with some pretty grotesque log file sizes, especially when all it takes to fix the crashed out chore is to run it again.

But I do take your point; the way we get around that is by always having a process at the end of our chores which (as the first thing it does in the Prolog tab) switches logging back on for all data cubes that were affected by any earlier processes of the chore. Though I grant you that it's still wise (and necessary, in the absence of "On Event" TIs) to check the logging status of the cubes manually after a crash. (Or write a chore/process to set the logging and run it manually after each crash.)

[mattgoff]

In you replicate you also need to have logging on for all replicated cubes. We refresh from the GL every hour, so unfortunately for us that means a lot of logging....

Matt