TM1 Forum

Dear all,

Symptom:
- I encountered this line below in the tm1server.log file on start up. Actual description is as follows:
- 3692 [] ERROR 2015-05-27 03:16:14.623 TM1.Cube Cannot load <cubename> : File Format is too old
- The TM1 service started up successfully eventually, but with a set of cubes missing. All the missing cubes have the above line in the TM1Server.log file.
- Further investigation into the log file showed that the TM1server.log file had a large area of complete blank space between 2015-05-24 until the 2015-05-27
- Effectively, nothing was logged in the tm1server.log for the above stated period of time.

Background:
- The service restart attempt was triggered by feedback from users that they couldnt access the system.
- System administrators couldnt even RDP into the application server - thus had to do a hard reset of the VM instance that the application server was running on
- System administrators also found that they had issues retrieving windows log as well, and found a virtual disk service stopped issue.
- The tm1server.log file started having entries after the hard reset of the VM application server instance.
- It would appear that some form of disk corruption might have set in on those set of cubes that had changes done during the above mentioned period.
- However, the log itself seem to suggest some old format issue, and we cant help but wonder if it has anything to do with an upgrade done earlier in the year.
- The upgrade done early this year (January 2015 completed) was from TM1 9.5.2 to the current version of TM1 10.2.2
- The upgrade went smoothly with no such issues and all necessary cubes deployed successfully, with successful usage of the system from Feb 2015 till now.

Remedy Attempts:
- We tried 2 different methods in an attempt to get those cubes, with their data back online.
- We move the set of cubes and all necessary dim files to another TM1 10.2.2 install (development environment) to try and see it helps, same log entry in tm1server.log appeared.
- We move the set of cubes and all necessary dim files back to the TM1 9.5.2 version install to see if it can be revived, same log entry again.
- We are now retrieving a 2015-05-22 VM restore back from tape (seriously) in a bid to get the cub files from that restore - it has been restoring for the past 28 hours.
- By doing so, at least it is not a complete loss of data and only 5 days of data loss for those cubes.

Mayday (literally):
- Meanwhile, I have pretty much run out of ideas. Like to seek help from the community on the following:
- Whether any one has encountered similar issues on the log file entries as my searches online returned nothing much.
- Also, if any one has any ideas on reviving the cubes.

Specifications:
- OS: WinServer 2008 R2 64bit
- Client: Excel Perspectives deployed over Citrix Zenapp
- App Server RAM: 128GB
- App Server HDD: 350GB
- App Server Core: Intel, 8 Cores, 2.0ghz
- Previous version TM1 9.5.2 (no FP Applied)
- Current version TM1 10.2.2 (no FP applied)
- Relevant Config: Multiplecubeloadthread = 7

One thing you could do is to look into some working .cub files with a hex editor and see if there is a common byte pattern at the front, which would probably be some sort of internal file format/version stamp. If you find that all the valid .cub files start with the same few bytes you could look at the invalid ones to see if they all show the same pattern or not.

By playing around with creating some simple cubes and looking at their .cub files in a hex editor you can possibly work out what the internal format is and try to work out where the invalid ones have gone wrong. This kind of thing is normally quite a lot of work though and it's quite easy to get carried away.

Hi Duncan P

Thanks for your reply.

Will find some time to go try out the hex editor method.

Your suggestion is much appreciated.

Remember - take backups before you change anything, and don't get sucked in to spending too much time.

https://xkcd.com/356/