Hi Brainstrust,
I have a modest sized file (3.2GB) that I can install/replace just fine it but refuses to Migrate. It was damaged at some point and has gone through the standard recovery process with a clean bill of health according to the log and Damage Detector. It gets to the Starting Migration step and then sits there. My experience with other files (smaller) is that the migration beghins and the detailed log starts outputing results within a couple of minutes.
Being a big file it might take longer to get it’s head around before starting but
I’ve let it run through to time out on one run, 7+ hours, and I’ve let it run to an hour a number of times.
I’ve tried numerous permutations such as:
Whole File > Whole File
Clone > Whole File
Clone > Compacted File
Clone > Clone
All Container Fields Externalised > All Container Fields Externalised
All Container Fields Externalised Clone > All Container Fields Externalised
*I THINK I’ve done all these but it’s all become bit of a muddle, so if there’s a particular combo you think I should re-try, please say so
I can DMT the file on my local machine without any problem.
3 other files common to both servers migrate just fine.
We are experiencing occaisional FMS crashes with this file so I do suspect there may be some damage hiding away in there, so if there are any addtional tools / techniques of recvoery I should try…
Linux Servers
FMS 20.3.2.205
FMP 20.3.2.201 (on MacOS 14.3.1)
OttoFMS 2.30
OttoDeploy: 1.2.1
please halp?
Hello Sam,
Well the good news is you can perform a data migration on your desktop. That is a good sign. I would try to do a manual migration, but on the linux box, using the DMT in the bin folder of the FMS install. If the file is damaged, it could be that the DMT on linux is susceptible to it in a way that it isn’t on your mac or windows desktop. It would be good to rule that out.
Next, I would like to see what the otto_info.log looks like for the time period that the migration is going on. Can you send that to me. You can use a Direct Message to do that.
Let us know what you find out.
Thanks
Todd
1 Like
@toddgeist , that sounds awfully familiar to us. The migration tool was working on a Windows desktop, but not on the windows server. @sam_teamDF, to fix our troubled file(s) we did the following. First, Recovered the data file. find out what failed from the log. Fix all the things remove all the “recovery tables” etc. Repeat until clean recovery.
Next venture to your source (schema) file. Let’s just clone get a clone of it. and recover that file, fixing it, and then recovering until all happy.
Now you can put those files back up in on their designated server(s) and proceed with the migration. We did this with multiple 30 GB files over a weekend. Yes it was painful and time consuming, but it worked.
1 Like
@Operadad
Thanks so much for the response here. Very helpful. I may pull this info into our support docs.
Thanks
Todd
1 Like
Thank you both, we are going to have a look at things this morning (AU time) so I’ll let you know how we go on weach of these fronts. And Todd I’ll get those log files to you shortly too.
Sam.
We’ve run the DMT on the linux server this morning and that was successful.
@Operadad with regards to your suggestion - we have undertaken recoveries of the file and each time the log no errors. Given other files migrate fine then my feeling is that it coud well be an as yet undetected error causing the issue. I’ve tried Damage Detector and that has not yielded anything - are there any other tools or techniques I should be trying?
Hello,
The logs you sent clearly show the data migration tool encountering a lot of errors. You will see logs like this.
2024-04-14 20:21:30.275 +1200 [Main_7fb7a9a09780] ***ReadPage invalid slot table, pageNum: 553, file: FILENAME 3_otto_migrated.fmp12
Here is another one with a clue
2024-04-14T17:43:43.791Z error DeploymentError: DATA_MIGRATION_ERROR - Command was killed with SIGTERM (Termination)
That may mean that the DataMigration Tool was killed by the operating system, which can happen when the system runs out of memory.
Any chance this is small server, with no Swap file configured? Servers should have at least 8GBs of RAM, 4CPU’s and have a Swap File configured. If it has less than that or if it doesn’t have swap file, it will crash the DMT when it tries to migrate large files.
Here are our base level specs.
Any chance that is it.
Thanks
Todd
2 Likes