Page 1 of 1
CubeSetLogChanges - Best Practices
Posted: Thu Aug 02, 2012 2:45 pm
by 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?
Re: CubeSetLogChanges - Best Practices
Posted: Thu Aug 02, 2012 2:53 pm
by tomok
ps_in_atl wrote: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.
Re: CubeSetLogChanges - Best Practices
Posted: Thu Aug 02, 2012 3:28 pm
by 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?
Re: CubeSetLogChanges - Best Practices
Posted: Thu Aug 02, 2012 3:50 pm
by paulsimon
Hi
As you are using version 10, another possibility is the new Cube Reservation TI Commands
Regards
Paul Simon
Re: CubeSetLogChanges - Best Practices
Posted: Thu Aug 02, 2012 4:18 pm
by 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!
Re: CubeSetLogChanges - Best Practices
Posted: Wed Feb 13, 2013 5:39 am
by 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?
Re: CubeSetLogChanges - Best Practices
Posted: Wed Feb 13, 2013 9:33 am
by Alan Kirk
yyi wrote:
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.
Re: CubeSetLogChanges - Best Practices
Posted: Wed Feb 13, 2013 1:25 pm
by 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.
Re: CubeSetLogChanges - Best Practices
Posted: Thu Feb 14, 2013 12:09 am
by 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.
Re: CubeSetLogChanges - Best Practices
Posted: Thu Feb 14, 2013 3:14 am
by 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...
Re: CubeSetLogChanges - Best Practices
Posted: Thu Feb 14, 2013 3:25 am
by Alan Kirk
yyi wrote: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:
I wrote: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.
Re: CubeSetLogChanges - Best Practices
Posted: Thu Feb 14, 2013 4:51 pm
by 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.