CubeSetLogChanges - Best Practices

[ps_in_atl]

I am just getting into disabling cube logging during large TI data loads (never had the guts to do it before). Can anyone offer up the best practices for this?

Specifically, I'm looking for advice on how to prevent user transactions from not getting logged while the process is running. Is there some magical way someone has found to disable logging only for a TI process and not for the cube as a whole?

[tomok]

Is there some magical way someone has found to disable logging only for a TI process and not for the cube as a whole?

No. The cube logging setting is all or nothing. Unless you have parallel interaction turned on then it's highly unlikely user's will be able to write to the cube while it's in the middle of being updated via a TI process. Just to be safe you should lock the cube from writing while the process is running and then unlock it. That way you won't miss any user updates.

[ps_in_atl]

Yeah, that's my concern - I definitely use parallel interaction which is why I ask.

So just lock in the process by changing access in }CubeSecurity?

[paulsimon]

Hi

As you are using version 10, another possibility is the new Cube Reservation TI Commands

Regards

Paul Simon

[ps_in_atl]

I think locking the cube before disabling logging will work. I was worried about affecting users' wait times for either read or write. But it's for a short enough amount of time that it would hardly be noticeable.

Thanks for the feedback!

[yyi]

If there is a while loop in the prolog with attrputs and the CubeSetLogChanges(' ',0); is in the same place - does it still log the cube changes?

[Alan Kirk]

If there is a while loop in the prolog with attrputs and the CubeSetLogChanges(' ',0); is in the same place - does it still log the cube changes?

WHICH cube are you talking about? You can't use an empty string in CubeSetLogChanges as you have there to act as some sort of magic bullet to turn off all logging. If you try that all you'll get is a process error.

If you explicitly turn off logging on the attributes cube for the dimension then no, those AttrPutS changes won't be logged. (Which I wouldn't normally regard as being a good practice.)

However that has nothing to do with logging on the data cube that you're subsequently uploading to (if any), and conversely changing the logging status of a data cube will have no bearing on whether the attribute changes are logged.

[tomok]

I think the OP is asking whether CubeSetLogChanges acts on just the Data tab, or is it applicable to all activity in the TI process, specifically the prolog tab. The answer is it will turn on or off logging for ALL changes, regardless of interface.

[PlanningDev]

If im not mistaken the OP said they had PI turned on.

In this case I was under the impression that your logging cube settings were also held in a parallel copy untill your TI finished. In this case anyone else that tried to write to the cube during your TI Load would be looking at the original logging settings and therefore logging would be on for those data entries. In a way I beieve you turn logging off in parallel copy then run your TI with logging off then turn logging back on and data is committed for your logging cube and data cube. Your logging cube essentially doesn't change in this case for the base data.

I might be wrong here but PI is kind of like using a sandbox to do all your work and then commit back the data. All processes that run and use PI pull changes into a sandbox like copy untill they are completed in which case all changes are committed back.

[yyi]

Sorry Guys, I should have elaborated further. Yes, it's true PI is on but not concerned about that because they're mostly after-hours chore(s).
Object was to clean up the log files which were including logs from processes, and it made looking for real user changes difficult when the file size is really big.
I thought I'd switched off cube logging before the TI loads stuff and then turn them back on afterward, but the next day still found a big chunk of logs written by chores. There is one process that writes to "}ElementAttributes_Department" which is done from the prolog within a 'While - End' loop instead of the other tabs so I was wondering if turning off the logging in the prolog was effective in this case or the CubeSetLogChanges actually happen after the prolog tab...

[Alan Kirk]

so I was wondering if turning off the logging in the prolog was effective in this case or the CubeSetLogChanges actually happen after the prolog tab...

No, as I said originally:

If you explicitly turn off logging on the attributes cube for the dimension then no, those AttrPutS changes won't be logged.

But for the sake of clarity, I re-emphasise that it's the element attributes cube that you have to turn the logging off for, not the data cube that contains the dimension. (Which is presumably what you're writing to in the Data tab.)

As Tomok also said, the CubeSetLogChanges function doesn't care which of the tabs it's on.

[buncikp]

Just for sure - if you will use replication in your model against star server, you should have cube logging turned on on each star cube that is being replicated to your planets. The point is that replication of data is based on cube logs / timestamps. I think it is necessary to have cube log turned on even during data load to your star cube.