Page 1 of 1
Trigger for Control Objects to Update
Posted: Tue Nov 04, 2008 10:58 pm
by Eric
Here is the situation.
I placed holds on a cube that did not have any holds before. As you all know this creates a new cube }Hold_User_Cube. I wanted to see how much memory the holds were requiring. So I went into }StatsbyCube to take a look, but the element }Hold_User_Cube did not exist. I disconnected and reconnected to the server and still nothing.
Can I do something update this DIM or can someone let me know what has to happen to trigger the DIM to update?
TIA
Re: Trigger for Control Objects to Update
Posted: Wed Nov 05, 2008 12:52 am
by Alan Kirk
Eric wrote:Here is the situation.
I placed holds on a cube that did not have any holds before. As you all know this creates a new cube }Hold_User_Cube. I wanted to see how much memory the holds were requiring. So I went into }StatsbyCube to take a look, but the element }Hold_User_Cube did not exist. I disconnected and reconnected to the server and still nothing.
Can I do something update this DIM or can someone let me know what has to happen to trigger the DIM to update?
Looks like it requires a server reboot; the dim is presumably only updated on server load. (Or possibly on manual creation of a new data cube; I haven't tested that.)
I created a hold cube for our Training cube, but couldn't get the dim to update to show it no matter what; not after a data save, not after repeated refreshes of the dimension, not after logging off and back on.
Then a little while later our server had some kind of memory trauma, the {bleeping} piece of {bleep}.
Anyway, when I brought the server back up the hold cube was in the dimension.
Re: Trigger for Control Objects to Update
Posted: Wed Nov 05, 2008 4:46 am
by Alan Kirk
Alan Kirk wrote:Eric wrote:Here is the situation.
I placed holds on a cube that did not have any holds before. As you all know this creates a new cube }Hold_User_Cube. I wanted to see how much memory the holds were requiring. So I went into }StatsbyCube to take a look, but the element }Hold_User_Cube did not exist. I disconnected and reconnected to the server and still nothing.
Can I do something update this DIM or can someone let me know what has to happen to trigger the DIM to update?
Looks like it requires a server reboot; the dim is presumably only updated on server load. (Or possibly on manual creation of a new data cube; I haven't tested that.)
It appears that I have to modify that answer for later versions.
What I described in the earlier post was of course from 8.2.12. After the server was restarted, the Hold cube was in the dimension.
However by 9.1 SP4, it appears (and this does indeed make sense when you think about it) that the server does a little housekeeping when you take it down and restart it. Specifically, it deletes any holds when the server is rebooted. (Actually I just found where this behaviour started; it's mentioned as fix 270567 in the 8.3.1 release notes.)
However the hold cube still doesn't appear in the }PerfCubes dimension when it's created, and nor do any manually created cubes. In the case of the latter cubes, it still takes a server bounce subject to my comments below.
That means that a hold cube will NEVER appear in the }PerfCubes dimension unless you modify that dimension manually. And since you can't manually modify a system dim using the dimension editor (as far as I can tell; the option's certainly not available when you right click), you'd need to create an .xdi.
Now I did that (in a test system obviously), and I got numbers for the Hold cube after I did that.
But is hacking a system dim with an .xdi something that I'd recommend in a production system?
Probably not.
Also, the }PerfCubes dimension is regenerated when you start the server, so if you did go down the .xdi path you'd need to do it after evvvvery restart.
Re: Trigger for Control Objects to Update
Posted: Wed Nov 05, 2008 1:33 pm
by Eric
That is what I thought ....grrr
Re: Trigger for Control Objects to Update
Posted: Wed Nov 05, 2008 1:49 pm
by Steve Vincent
Grr yes, but it saves it from recording stats on objects the user has no control over, so in *theory* the user shouldn't be bothered about them. In theory...