TM1 Forum

Ok, so I've just made the rookie mistake of attaching a leaf element to another leaf element that already had data in it - thereby making it a consolidation and losing all the cube data associated with it

Any ideas on what the best way is to recover everything?

Thankfully I did a Save data several minutes before the error, so I was considering bringing the service down, renaming the last backup dimension file (with the date extension) to the main file, then restarting the service ( i.e. rename "ProductProcessor.dim.20141128024359" to "ProductProcessor.dim" )

...anyone have other thoughts, or is this the only way to go...?

Regards,

Matt

Must say it's a terrible mistake. You probably realized by now by changing the element back to N doesn't get back you data. Hence by restarting and revert the dimension changes will not help either.

You can't use transaction log as you have no idea how far back to apply restore using transaction log.

Only choice to me is to find the latest backup of the cube backup and restore the cube. But before that make sure you revert the dimension changes as well.

hehe yes, I am a little red faced...

What I did was NOT to Save Data before shutting down the service (as I'd already saved data a few minutes prior to the change), I then reverted back to yesterday's backup .dim file, then restarted the service.

Luckily there had been no Leaf changes to the dimension file this morning, so no cube data was invalidated... phew... close call =)

kangkc wrote:Must say it's a terrible mistake. You probably realized by now by changing the element back to N doesn't get back you data. Hence by restarting and revert the dimension changes will not help either.

... not necessarily ....
If a save data had been done with the old dimension structure and the dimension then changed to convert N to C then this doesn't re-write the .cub and .feeders files. If the server was brought down (with no action in-between to cause a data change to any affected cubes) and the .dim file replaced with the old one then the server brought back up then this would in theory restore the data. I have seen this work before. (also in a backwards and unintended fashion where dimension elements were deleted as a shortcut to deleting data as cubes were very large and so zeroouts took too long, after elements were re-inserted and the server restarted data reappeared in cubes where there had been no data change and update of the .cub file)

So restore from this scenario *can* be quite simple and quick but it depends very much how soon the error is realized and action taken. Recovery fro something like this is never without risk.

It's all about the time stamp of the .cub file. If this one is older than your change, which has damaged the .dim, you will be able to recover your data as lotsaram described it.

lotsaram wrote:

kangkc wrote:Must say it's a terrible mistake. You probably realized by now by changing the element back to N doesn't get back you data. Hence by restarting and revert the dimension changes will not help either.

... not necessarily ....
If a save data had been done with the old dimension structure and the dimension then changed to convert N to C then this doesn't re-write the .cub and .feeders files. If the server was brought down (with no action in-between to cause a data change to any affected cubes) and the .dim file replaced with the old one then the server brought back up then this would in theory restore the data. I have seen this work before. (also in a backwards and unintended fashion where dimension elements were deleted as a shortcut to deleting data as cubes were very large and so zeroouts took too long, after elements were re-inserted and the server restarted data reappeared in cubes where there had been no data change and update of the .cub file)

So restore from this scenario *can* be quite simple and quick but it depends very much how soon the error is realized and action taken. Recovery fro something like this is never without risk.

Well..I remember having this working as what you have described in 9.x world.

Before replying fleaster I did a test on 10.2.2 to make sure.
But on 10.2.2 I am not seeing the same behaviour. I did a change from N to C, and from C back to N, all N data was wiped out.
No save data, data input, restart in between. It's a simple element property change.

I went on further testing by using rule to override the N element with dummy data. As soon as rule statement is removed, I get back my original N level entered data. Similar mistake but different results.
Confusing enough but this is what I am seeing in 10.2.2.

That's why I suggested to change from C back to N to see if fleaster managed to get back the data, else restore cub seems to be the only way out.

kangkc wrote: That's why I suggested to change from C back to N to see if fleaster managed to get back the data, else restore cub seems to be the only way out.

Hi kangkc, I did try changing it back from C to N, but no success - the data was already gone.

However, I was able to recover everything by immediately bringing down the server and restoring a backup .dim file - and found that the cube data was all ok (nothing missing).

However, as lotsaram & Gabor alluded to earlier, this was only successful for me because:
1. I detected the mistake within a few minutes of the dimension maintenance
2. A save data had been done earlier in the day
3. No cube data had changed between #1 and #2

...so I was lucky to dodge this bullet