MySQL Bugs: #14798: Restore Analysis stops for no reason

Bug #14798	Restore Analysis stops for no reason
Submitted:	9 Nov 2005 17:23	Modified:	6 Dec 2005 7:22
Reporter:	Jake Day	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Administrator	Severity:	S3 (Non-critical)
Version:	1.1.4	OS:	Windows (Win XP SP2)
Assigned to:		CPU Architecture:	Any

Description:
This is a duplicate of bug #6433, which has been closed. But the issue is still occuring, with the latest version of Administrator.

During restore of a schema the analyser stops with the message "Analysis completed successfully", but there is nothing to restore. 

Analysis has to be run countless times (last restore took 37 attempts at Analysis, before it completed properly....sadly i counted...) - When it does complete properly, the Restore data directory is populated and restore can begin.

How to repeat:
Backing up a schema using Admin 1.1.4 - InnoDB Online Backup, (3 check boxes - Add drop statements, Complete inserts and disable keys - are all checked - think this is default.) Server is MySQL 5.0.

Move file to alternative server. Set restore options as create new schema, ignore errors, create database if they don't exist. 

I've tried both char sets utf8 and latin1, and have more success with latin1...but it still fails to properly analyse the file (20 of the 37 restores were with latin1 - which was the char set i used when the analyser finally completed.

Database is approx 400MB and does have one field with TEXT values in. 

Apologies if this isn't enough information, but please ask if you require any more and i'll help in any way i can.

Hi, 

Just wondered if there was any extra information you required on this to help to resolve it? 

I'm still suffering from the that i cannot backup my data (actually had to give up on the "file analysis" last time i tried after 100 attempts still didn't complete properly.)

Thanks

jake

Thank you for a problem report. 

Personally I had not thought out any good idea on how to repeat the problem you have. 400Mb database is not appropriate for bug verification... I can ask several more questions: How many tables do you have in your database? (I'll ask about the show create table results for them, if there are few...) Are you sure your dump file is always OK? How much memory and free disk space do you have while trying?

Valeriy, Thanks for your response. In answer to your questions. 

a) I have 16 tables in my schema. One table is 326MB, one is 35MB, one is 23.5MB and the rest are less than 5MB - haven't looked at the "show create" table results for them?

b) I've no idea how to analyse the "dump" file, so can't assure you that its ok. 

c) As for the Laptop i'm backing them up to, its got 256MB Ram, and about 40GB spare capacity on the hard disk. 

FYI, i actually managed to make a successful restore yesterday. I repeated the analysis around 80 times and finally it completed successfully. The restore then worked without issue.

However, your response made me think and you may have given the answer. I wonder what levels of RAM others use. I just tried to do the restore on my main machine, (2GB RAM) and the analysis worked first time. I've no idea why this would be the case, but if this is a possibility, then I could invest in some more RAM for my second machine? If you can confirm that there is a plausible reason that lack of RAM could cause the issue, then i'll purchase some more to see if that resolves the issue? 

Please let me know - and if I can provide any further information please feel free to contact me.

Jake

Please, try to monitor the memory usage by MySQL Administrator during the analysis (use Task Manager for that). If all the available virtual memory is used whan analysis stops, then we found the immediate reason. So, how much virtual memory (RAM + swap) do you have and how much is used when you try to restore?

Valeriy, 

I've just tried that and it doesn't look like its a memory problem(from what little i can see...), the Mem Usage in MySQL Administrator stayed at 15,956kb (processes tab). 
The available system memory remained fairly constant at 120,000kb 

Thinking logically about this, I suspect its not a memory issue as if it was it would usually "stop" (with the analyze operation successful message) in roughly the same place each time, however, i've just run three tests and with a total number of bytes to be analysed of 395,545,098

the analyzer stopped at :-
50,580,522 bytes
2,519,359 bytes
27,547,875 bytes

completely random intervals.........

two questions. 

1) what exactly does the analyser do? does it look at every byte of data? or is there a random selection of some sort that could cause it to randomly fail or succeed?

2) the other unanswered question is that when i have the Administrator window non-maximised, occassional numbers appear in the top-left corner of the desktop, which correspond to the number of bytes that the analyser has processed. This is completely uncontrolled and whilst it doesn't tell us whats wrong, might be a symptom of the bug that is causing the failure?

Apologies that this second part seems a bit "unscientific", but i can send you some screen shots if you wish? - might be worth that anyway, to prove that the problem exists and i'm not simply wasting your time??

thanks again for your help.

jake

Hi, 

I,have a same problem with a catalog 240 Mo, 50 Tables.

10 Attemps and teh counter stop and the dialog box say analys succefully .

But the counter  stop never at the same time. 

I have tested on two PC. 

One of these PC has 2 Go RAM and 200 Go HD FREE SPACE

The processor utilisation goes to 65 % and the space free memory is 1,3Go

Hi,

I encountered the same problem too. I wasnt patient enough to try it 37 times or anything... but it failed at least 10 times.

I have a normal mysql dump I had done using DBManager. I looked at it and its just a few MyISAM tables and some inserts of data. The file is around 64Kb.

The effect is that it says that 'The analyze operation was finished successfully.' but restore is never done.

I tried the following combinations, all failed:
 - With Target Scheme 'New Schema...'
 - Creating a new schema myself and selecting it from Target Schema.
 - With or Without Ignore Errors.
 - With or Without Create Database(s) if they don't exist.
 - With Character Set UTF8 and Latin1

All the same effect.

Another strange thing I noticed is that when the Analyse process finishes the total bytes is smaller than the processed bytes! How can that be?

Total number of Bytes: 64941
Number of Bytes processed: 88723

Josef (or anybody):

If you can provide a small dump (up to 200 K) created by MySQL Administrator that can not be successfully analized and/or restored, please, upload it to this bug report using the File tab. You may upload it as private file, if you want.

Valeriy, 

Hopefully Josef will provide a sample, as his analysis seems to be stopping on a much smaller data size than mine. My analyser seems to nearly always get through at least 1MB before it fails. 

I will however upload some screen-shots today, so that you can see the problem for yourself. And also it will show the "mysterious" dump of data into the top left corner of the screen. 

It may be possible if you get no further info from anyone else that I can copy my DB to a CD and "post" it to you? Anything I can do that will resolve this problem i'm more than happy to try as it is causing me a fair bit of aggravation. (Even more problematic now, i'm finding that the "restore" function is also now stopping early without completing, but i'm guessing that if we fix the first issue the second issue may disappear.)

One other thing that i've spotted that may be related (as it could be data corruption on my db)  - is that occassionally when selecting from tables i get the following warning message - 

"Access violation at address 00583612 in module 'MySQLQueryBrowser.exe'. Read of address 06E60020   ....... (read address is always different locations).

Not sure if this is related or not, but i've repaired all of my tables?

Apologies for the random presentation of facts, just trying to give you all the information I have to hand, in the hope that something I specify might start of a "train of thought" that leads to the solution :)

Cheers

jake

Jake,

I'll be waiting for the additional information frou you both. As for that access violation:

"Access violation at address 00583612 in module 'MySQLQueryBrowser.exe'. Read of address 06E60020   ....... ."

Please, open a separate bug report - it is about MySQL Query Browser, really. Let us not mix things, that already are too complicated...

Valeriy, 

I've taken screen shots of the analysis failing (and more worryingly the restore failing to complete(but hoping that the two are tied together, so solve one and we solve both.) However, the screenshots are 4MB each, and the upload limit on the files is only 200KB...I can't reduce the resolution that much, so was thinking about emailing you directly? 

Can you let me know how you wish to proceed? You should have my email address on file, so can email me with an address that i can send them too?

First analysis restore attempt fails

Attachment: First Run.zip (application/x-zip-compressed, text), 162.22 KiB.

Notice top left corner of screen - number of bytes appears uncontrolled

Attachment: Top Left Corner.zip (application/x-zip-compressed, text), 163.04 KiB.

10th attempt - finally successful analysis

Attachment: Success.zip (application/x-zip-compressed, text), 164.74 KiB.

Restore fails - very worrying

Attachment: Restore Fails.zip (application/x-zip-compressed, text), 171.49 KiB.

Valeriy, ignore my previous inadequacies...i zipped the files and posted them without issue.......

Thank you for the additional information. I had found a couple of other bug reports very similar to this one. Can you, please, look at the following reports and check which one of them is most similar to your situation:

http://bugs.mysql.com/bug.php?id=14236
http://bugs.mysql.com/bug.php?id=15260

Valeriy, 

Bug 15260 is the same issue - so therefore is the closest in relation to my bug. 

The person that raised this specifies that it is a repost of bug 14798(my bug issue) within the text. 

The other bug number is unrelated.

Please let me know if you require further information.

Cheers

jake

Bug #15260 (the same, but with 1.1.5) is verified already on a small dump provided by the reporter. It means that the developers of MySQL Administrator will fix it soon. So, I'll mark your bug report as a duplicate of that one.

Valeriy,

Ok. Thanks for that. I'll keep an eye on that bug and once its resourced and resolved, I'll check again and post on both bug threads to let you know that my issue has also be solved.

Thanks again for your help.

Jake