TM1 Forum

Hi Guys,

I ran a chore last night and had anaother chore ran at around the same time. It appears I think to have caused a problem I cannot see my cube. I have ressurected my cube in developement and I can see it but not in production. I have done the following to try to fix the problem:

1) I have looked to see whether it might be security ( but im admin so nope) all the relevant dimensions exist etc, I have also looked at cube security and cannot see the cube.
2)However when I look in the data directory and look for the cube file I can see it, but instead of cubename.cub i see instead cubename.cub$. I can also see another cube "othercube.cub$" in there as well but its not being used anymore. I am thinking a hard reboot but this I would have though would have gotten rid of the "othercube.cub$" but it has not.

So what are my options??? I have seen this with access databases and your basically screwed when this happens. Will i need to re-create another cube and then reload the data against that one? Or is there a way of deleting this file, do I need to hard reboot ( this should have gotten rid of the othercube.cub$ i would have thought)

Thanks again for your help.

shockwave wrote:Hi Guys,

I ran a chore last night and had anaother chore ran at around the same time. It appears I think to have caused a problem I cannot see my cube. I have ressurected my cube in developement and I can see it but not in production. I have done the following to try to fix the problem:

1) I have looked to see whether it might be security ( but im admin so nope) all the relevant dimensions exist etc, I have also looked at cube security and cannot see the cube.
2)However when I look in the data directory and look for the cube file I can see it, but instead of cubename.cub i see instead cubename.cub$. I can also see another cube "othercube.cub$" in there as well but its not being used anymore. I am thinking a hard reboot but this I would have though would have gotten rid of the "othercube.cub$" but it has not.

So what are my options??? I have seen this with access databases and your basically screwed when this happens. Will i need to re-create another cube and then reload the data against that one? Or is there a way of deleting this file, do I need to hard reboot ( this should have gotten rid of the othercube.cub$ i would have thought)

I'm not clear on whether you're doing all of this after rebooting your server, or whether it's still the same session. I'm also not sure what you mean by you've "resurrected" it in development.

When TM1 does a data save it doesn't write directly to the .cub file. Instead it creates a $ file. (The extension is .cu$ in 8.2.12 but if I recall it's .cub$ in later versions.) If this finishes writing successfully, it will then delete the old .cub file and replace it with the .cu$/.cub$ file, renaming it along the way, naturally.

You'll have "left over" .cu$/.cub$ files if a data save is interrupted. (For example, if you stop a service, and the service doesn't have enough time to save all of the cubes before Windows throws a "did not respond in a timely manner" tizzy, then the cube that was being saved at the time will have a left over .cu$ file.) This is harmless in itself, assuming that all of the entries which went into the cube were logged. When the server restarts it will reload the entries from the log file. The .cu$ file will hang around until the next time you do a data save, at which time TM1 will of course create a new .cu$ file and the process will begin again. Assuming that the second save succeeds, the .cu$ file will vanish when it's renamed as .cub.

Now, are you absolutely sure that in addition to the cubename.cub$ file, there isn't also a cubename.cub file? If there is, then that's your actual cube data. If there isn't, then it SOUNDS like the data save got interrupted so badly that it failed right at the point that TM1 was deleting the .cub file to replace it with the .cub$ one. (And somehow it also unregistered the cube (not just unloaded it, actually removed it from the cubes collection) since you as an admin can't see it. This is why I was asking whether this was the same server session or not). Frankly, I've never heard of one of these things happening, much less both. Certainly not without some help from the CubeDestroy TI function, which I trust didn't make an appearance in either of your TI chores?

Though if an interrupted save IS what happened, and it happened at the point that I described, then the good news would be that the .cub$ file would be complete and not some deformed, partial and possibly corrupt data file. That would mean that in theory you could simply bring down the server, rename the .cub$ file as .cub, restart the server and you'd have your cube back.

But don't do that.

By all means, test it out in a development environment first, and if everything seems OK then you can do it in your production environment.

But I'd still look very, very closely at your data directory to see whether your .cub file is there.

Also, if it were me I'd take a copy of the data directory as it currently stands (BEFORE taking any other action), do a data save, then shut down and bring the server back up to see whether the cube is there. (If the .cub file is there, then it should be. If it's not, it won't be.) But if the cube is still in memory somewhere even if you can't see it (long odds, long, long odds) the data save MAY reconstruct the .cub file. If the .cub file really, really isn't there, then see whether the .cub$ file will load in a dev environment when renamed as .cub, and run any validation tests you can against the numbers.

Thanks Allen for your consise answer to my problem. The server is taken down for backup and restarted at 6 evey morning so this would create another session. After testing it in dev, I was able to delete the file in the backend and then reload the .cub file from backup to fix it.

Cheers

Shock

shockwave wrote:Thanks Allen

Ah PITY da foo' who has to have two Ls and an E in his name, AH PITY da foo'!

(Except for any of our august members who really DO spell their name that way, anyway. I'm talking about NON-OLAP Forums members, naturally. )

Alan, My bad. Was thinking of Ray Allen of The boston Celtics ( They should have gone through)

shockwave wrote:Alan, My bad. Was thinking of Ray Allen of The boston Celtics ( They should have gone through)

No offence taken. I'm more of a Sydney Flames kind of guy anyway.

(The view is much better....)

agree with that my friend, except skirts instead of lycra pleeease.