Deleting a small(ish) cube takes how long?

[jim wood]

Guys,

I am slowly but surely replacing all the cubes and dimensions on our production server. Once I have replaced a cube I have been leaving it up for a few days. I have (Like the true coward I am) started with the smaller cubes first. I have just tried to delete a cube and it seems to be taking forever. Has anybody else experienced this problem?

Jim.

PS. I am using 9.1 U1.

[Marcus Scherer]

Jim,
deleting a cube in the production environment sounds strange. Why don't you make all the preparation steps on your dev system test it and copy the whole data directory to prod and restart services.

M.

[David Usherwood]

Might be quicker to rename the .cub files in the server directory to (say) .cu1 and bounce the server. Then, if you want them back, rename them back to .cub, rinse and repeat.

[Alan Kirk]

Guys,
I am slowly but surely replacing all the cubes and dimensions on our production server. Once I have replaced a cube I have been leaving it up for a few days. I have (Like the true coward I am) started with the smaller cubes first. I have just tried to delete a cube and it seems to be taking forever. Has anybody else experienced this problem?
Jim.
PS. I am using 9.1 U1.

I just deleted a 60k (on disk) cube on 9.1SP3 and it happened almost instantly. However I have to go with David on this one; I always take out the files in the directory while the server's down rather than deleting through the UI.

The reason is that even if you delete the cube via the UI, TM1 doesn't blow away the public views folder, or the private views folders, or if the dimension is unique to that cube the .dim file, or the dimension subsets folder, or....

This leaves your data folder cluttered with an ever-increasing array of junk.

(Kinda like the way TM1 doesn't blow away, or at least archive, the private folders of users who you've deleted.)

I therefore make judicious use of the Windows search function to terminate all of the related files and folders as well as the .cub file while the server's down. (After backing up, it goes without saying.)

[jim wood]

Guys,

In repsonse to your points:

1) I did complete a test delete on our development server first. It went well and only took a minute or 2.

2) The reason I deleted the cube on the production is that once a week the cubes are copied to a backup server so the production server is the source.

3) I ended up deleting the files and bouncing teh server. I did this because the delete via the UI had already taken 5 hours and I needed the server back in the morning.

4) I was watching tm1top and it actually displayed deleting views from folders etc. I think it was attempting to do what Alan has suggested it doesn't, hence the amount of time taken.

I think that covers everything. The only other poin to bare in mind is that are running on Unix not Windows. We do have Samaba shares running to access some folders but I am little more limited when it comes to searching for files,

Jim.

[Alan Kirk]

{Snippedy}
4) I was watching tm1top and it actually displayed deleting views from folders etc. I think it was attempting to do what Alan has suggested it doesn't, hence the amount of time taken.

I think that covers everything. The only other poin to bare in mind is that are running on Unix not Windows.

That could be the difference. When I did the test on 9.1U3 this morning I checked and confirmed that the .vue files and folders were left in place, and they were. Of course, that's also a different version to you as well. (I know for certain from long and semi-bitter (well, mildly irritating rather than bitter) experience that 8.2.12 doesn't remove the files.)

Actually I can understand the .dims and corresponding subs being left in place; even if you aren't currently using them, TM1's got no way of knowing whether you WILL want to use them in the future. The .vues, on the other hand; I can't think of a reason why they should be left.